データ基盤にはいろいろな種類がある。その結果、データ基盤のイメージは人によって様々である。時代の流れとともにデータ量が増え、ニーズも変わりデータ基盤の構成も進化した。
ニーズの変化と対応するデータ基盤の進化の関係を理解すればニーズに合わせてどのようなデータ基盤が必要か判断できる。データ基盤の進化とニーズおよび課題の関係を整理した。
尚、データ連携基盤とデータ分析基盤を合わせてデータ基盤と呼ぶこととする。
データウェアハウス ← ニーズ：基幹系システムで蓄積したデータを活用したい
データハブ ← ニーズ：各部署で蓄積したデータを共有して活用したい。
ビックデータ基盤 ← 課題：スマフォやIoTの普及でデータ爆発が発生。
ストリーム処理 ← ニーズ：リアルタイムにデータを活用したい。
データ仮想化 ← 課題：ビッグデータ基盤のデータを共有したいが大きすぎて連携が困難
データメッシュ ← 課題：データ連携が複雑化してデータマネジメントが困難
データウェアハウス
とてもシンプルで基幹系システムのデータを情報系システムに送る。基幹システムのデータを分析して業務に活用するニーズに対応するための仕組み。
データハブ
基幹システムがメインフレームからオープンシステムに移行していくうちにサーバーが増え、オペレーションシステムからデータ分析基盤や他のシステムにデータを連携する必要が出てきた。
ビックデータ基盤
スマフォやIoTの影響でデータ量が爆発的に増え、これまでのデータウェアハウスの仕組みでは対応できなくなった。その結果、非常に多くのデータを蓄積する仕組みが必要となった。
ストリーム処理
組織のデータ活用が進むにつれ、リアルタイムにデータを活用したいという要望が出てきた。例えば、ユーザーの購入状況によってリアルタイムにカスタマイズされたレコメンデーション、センサーデータの収集等である。通常のRDBによるオンライントランザクション処理もリアルタイム処理であるが、ストリーム処理との違いは？と思われるかもしれない。
違いは主に誰が大量データのインプットの負荷を吸収するかによる。通常のデータベースシステムではクライアントアプリ＋データベースが大量のトランザクションを並列化やインデックスの工夫等によりさばくことになる。ストーム処理では下記のようなキューシステム＋ETLが負荷を吸収する。キューシステムは入力データを一旦、受け入れること集中することで確実に受け入れを成功させる。次にETL処理はデータベース処理に負荷がないように、グループ化、無駄な項目の削除等の加工をした後に投入する。
しかし、エラーデータのリカバリ処理が困難等、難易度、運用負荷が高いので対投資効果を考慮して導入するべきである。
データ仮想化
データレイクのデータ量が多すぎてデータ連携基盤でデータを転送するのに時間がかかりすぎるようになった。大量データを転送するのではなく、必要なデータのみを転送するデータ仮想化の仕組みが必要となった。データ仮想サーバーではデータを持たずにビューのみを持つ。異なるシステムのデータをJOINできるのが特徴である。
データメッシュ
データ仮想化を進化させたデータメッシュという考え方が出て来た。基本的な技術はデータ仮想化と同じだが、データ連携基盤はデータの仮想化のみではなく、様々な機能を提供する。例えば、認証、データカタログ、暗号化等である。
また、プロダクトという概念が取り入れられている。入力元のデータは製品のように利用しやすいように整備されており、加工は必要とされないという考え方である。データ連携基盤側の担当者は入力元システムのデータに詳しくないことがほとんどであり、データのマネジメントは困難である。データ仕様に詳しいプロダクト側でデータは整備するべきという考え方である。
