大規模データ基盤構築: データ基盤のグランドデザイン : 分散型か集約型か

大規模データ基盤構築

データ基盤の構え方は、データ配置の観点から大きく分けて2種類あります。一つは、1か所にデータを集め、中央集権的に管理することを主とする中央集約型。もう一つは、データを分散させたまま管理を任せ、ルールとポリシーだけ共通化して公開を促す分散型です。大きな分かれ目なので最初に考えておく必要があります。

UCAの時代に優先すべきは、スケーラビリティとアジリティ

データ基盤の目指す姿として掲げたゴール(理想像、最適解)は、今時点のものです。ゴールの正しさもわからなければ、道半ばでゴール自体が変化することもあります。
ゴールの変化を与える要因には、以下のようなものがあります。

  • 市場や競合の変化
  • 事業改革
  • 予算の変動
  • 新しいテクノロジーの登場

特に5年後10年後を見据えるというのなら、ゴールが変わることを前提にしても良いくらいです。
VUCAの時代、企業で考えるべきなのは、変化に対するリスクであり、ITで言えばスケーラビリティとアジリティの確保です。特に規模の大きい企業ほど、基盤システムを考えるうえで重要になります。

コンサルタントの罠

多くのコンサルタントは、データ基盤のソリューションとして、オールインワンの製品や、一つのDBを中心にしたアーキテクチャを見せてきます。具体的には以下のようなものです:

  • 生データストアとデータベースをオールインワンにしたもの
  • AIを搭載した分析ツール
  • データレイク・データベース・ETL・カタログを組み合わせた「エンタープライズDB」

これらはいずれも会社中の全データを一つのDBに集める、という思想に基づいているものが多いのです。
しかし、これらは「わが社の製品」のスコープであったり、「我々が過去に構築したものは」を示しているに過ぎないことに注意したいと思います。彼らはまだ 1 社たりとも 10 年間追跡していません。
一方、外部業者の主張する失敗例を挙げると、以下のようなものがあります。

  • マスタは一意であるという前提で動いていたがそうではなかった
  • 表記ゆれや入力ルールが甘いためデータが統制されていなかった

これらの失敗理由を一言で言えば「お膳立てが旨くいってないから駄目でした」ということです。
しかし、我々は、お花畑の夢の国に存在しているデータ群を前提にしているわけではありません。そんな頭の中の国でデータ基盤を作りたいわけでもないのです。

従来の中央集約型の大きなデメリット

統制の取りやすさから、中央集権的な管理を考えがちですが、以下のようなデメリットがあります。

新しいテクノロジの登場に対応しづらい
中央の構造をいっぺんに変えなければならなくなったときには目も当てられません。例えば、RDBのみ考えてたところ、グラフデータベースや非構造データが主流となり対応できなくなった、AIの登場で生成データが爆発的に増え、データ収集が物量的に不可になった、等の事態が発生します。

末端の変化に合わせて逐一付き合う必要がある
変更承認、ルール再編などに時間を要するため、その結果、ユーザーは独自で様々なことを始めるようになります。

誰にでも使えて、誰にも使えないシステムが出来上がる可能性
全方向受容化という、予期しないコストを生むことがあります。たとえば「グローバルで共有するから英語を併記せよ、日本の本社で使えるよう日本語訳せよ」このような要求がいかに多くのコストを生むか想像できるはずです。
中央統制は迅速なかじ取りが可能なことを前提とするか、あるいは、ゴールが変わらないことを前提とした最適解です。

なお、AIが発達した今、ストレージ集約型にすることも一定の効果があることは断っておきます。その場合は局所的ストレージ&局所的AI+全体フェデレーション型AIという構成を考えることになります。

分散モデルをベースとすべき

大規模な企業で、データ基盤に必要なのは、統合モデルではなく参照モデルを中心とした構造です。

ドメインベースの参照アーキテクチャを考える
組織全体のデータを分散させます。逆に、考え方は一貫させます。各ドメインに対して、たとえば以下を求るようにします。

  • データ仕様
  • アクセス方法
  • 公開データの精査
  • 中央ルールの適用
  • 結合方法、利用方法、利用例の公開
  • データサンプル

各事業部署、機能部署で独立したシステムを持つ
各事業部署、機能部署で独立したシステムと独立した分析システムを持ち、それらがサイロではなく、エンタープライズ全体に公開され、容易に参照され、利用される形をイメージします。

「One Source」の正しい理解
「One Source」を掲げるコンサルタントは多いですが、「One Source」イコール「One Storage」ではありません。データリネージの先が同一であればOne Sourceです。

また、分析に取り組んでいるシステムがある場合、運用システムと分析システムが分かれていることが多いのですが、データを両方で同時に使えるようにします(過去データ含めて)。

コメント

タイトルとURLをコピーしました