エンタープライズ・データ・アーキテクチャーの進化の歴史

記事をシェアする:

生物学者や遺伝学者が自然界で何度も観察してきた進化のパラドックスに、地理的に離れた別々の地域にほぼ同じ2つの種が生息している場合があります。例えば、ホジソンフロッグマウスとスリランカフロッグマウスは、それぞれインドの2つの地域に生息しています。多くの場合、気候変動によって、かつては連続した生息地であった場所が複数の生態系に分断され、種が進化的に異なる道を歩むようになったために、このような状況が生じたのです。

企業データ管理の歴史においても、同様の現象が起きています。エンタープライズ・データ基盤は、その当初から、企業全体でデータを利用できるようにするための中央リポジトリーとして機能することが意図されていました。しかし、ビジネス環境の変化と進化の圧力により、分析データとトランザクション・データは別種のデータのように見えるほど孤立してしまいました。

しかし、現代の企業でビジネスデータの価値を最大限に引き出すには、より包括的で融通の利くデータアーキテクチャーを構築する必要があります。

島を形成する: データ基盤の進化

エンタープライズ・データ管理は、複数の別々のトランザクション・システムからデータを一元化し、統合する必要性から生まれました。データウェアハウスとして知られる第一世代のデータ基盤は、統合されたトランザクション・データを特定の分析目的で利用できるようにするために構築されました。

しかし、10年も経たないうちに、企業のデータは大量かつ多様になり、データウェアハウスはもはや保存と管理のニーズを満たすことができなくなりました。その結果、多くの企業がデータレイクと呼ばれる第二世代のデータ基盤に目を向けました。

しかし、データウェアハウスもデータレイクも、問題を解決するには十分ではありませんでした。データの起点となるトランザクションの世界と、データを洞察に変換する分析の世界との間のギャップは広がり続けているのです。企業のデータは基本的にどこでも同じですが、分析用と取引用で管理方法が異なることが多くなってきました。

この二項対立は、さまざまな問題を引き起こしました。

• トランザクション・システムと分析システムの間をデータが行き来する場合、データを取り込み、統合し、変換する必要がありますが、多くの場合、複数回行わなければなりません。つまり、データが作成されてから分析に使用できるようになるまでに、常にタイムラグがあるのです。その結果、分析では本質的に古い情報を利用することになり、ビジネスの意思決定に信頼性のない根拠を与えることになります。
• エンタープライズ・アナリティクス・ソリューションは、主に不活性な洞察を作成し、人間の専門家がそれを解釈する必要があります。このように人間に依存することで、2つ目のタイムラグが発生します。
• データを扱うには専門的なスキルが必要です。データ・アーキテクチャーとアルゴリズムは依然として複雑であり、データから洞察を得るには、アプリケーション統合、データ・エンジニアリング、機械学習（ML）、DataOps、MLOpsなどの分野の専門知識が必要です。一般的なビジネス・ユーザーはこれらのスキルを持ち合わせていないため、企業内のビジネス部門とテクノロジー部門の間にギャップが生じ、しばしば不信感を抱かせることになります。

レイクハウス：データレイクで当座の問題を解決する

従来のデータウェアハウスでは、データを取り込むためにETL（Extract-Transform-Load）プロセスを使用していましたが、データレイクは代わりにELT（Extract-Load-Transform）プロセスに依存しています。複数のソースから抽出されたデータは、安価なBLOBストレージにロードされ、その後、高価なブロック・ストレージを使用するデータウェアハウスに変換され、永続化されます。

このストレージ・アーキテクチャーは柔軟性に欠け、非効率的です。BLOBとデータウェアハウスのストレージを同期させるために変換を継続的に行わなければならず、コストがかさみます。また、継続的な変換にはやはり時間がかかります。データを分析できるようになる頃には、そのデータから得られる洞察は、トランザクション・システムの現状と比較して古くなってしまうでしょう。

さらに、データウェアハウスのストレージは、モデルのトレーニングに膨大な量のデータを必要とする人工知能（AI）やMLのようなワークロードをサポートすることができません。このようなワークロードの場合、データレイク・ベンダーは通常、データをフラットファイルに抽出し、モデルのトレーニングやテストにのみ使用することを推奨しています。これではETLのステップが追加され、データがさらに陳腐化してしまいます。

第3世代のデータ基盤であるレイクハウスは、これらの問題を解決するために生まれました。レイクハウスのアーキテクチャーでは、データウェアハウスのストレージ・レイヤーは削除され、代わりにBLOBストレージ内で継続的なデータ変換が実行されます。複数のAPIが追加され、異なるタイプのワークロードがすべて同じストレージ・バケットを使用できるようになりました。AWS S3やAzure DLS2が必要なストレージを提供できるため、このアーキテクチャーはクラウドに適しています。

しかし、これらの解決策は中途半端なものに過ぎません。レイクハウス・アーキテクチャーはデータレイク内のサイロを解消しますが、それでも中央集権的でモノリシックなものであることに変わりはありません。どちらかといえば、レイクハウスは、効率的とはいえ、企業のデータ基盤の風景に別のノードを追加したに過ぎません。現代の企業全体でデータ管理を真に統一するには、さらに革命的な変化が必要です。

エンタープライズ・データ・ファブリック：データ管理の変革

データ・ファブリックは、第4世代のデータ基盤アーキテクチャーを象徴しています。データ・ファブリックの目的は、必要なときにいつでもどこでもデータを利用できるようにすることであり、データの移動、変換、統合に伴う技術的な複雑さを抽象化して、誰もがデータを利用できるようにすることです。

本来、データ・ファブリックは

• データ基盤のネットワークで構成され、すべての基盤が相互に作用してより大きな価値を提供します。データ基盤は、企業のハイブリッドおよびマルチクラウド・コンピューティングのエコシステムに分散されています。
• データ・ファブリックの各ノードは、他のノードと異なることがあります。データ・ファブリックは、複数のデータウェアハウス、データレイク、IoT/エッジ・デバイス、トランザクション・データベースで構成されることがあります。Oracle、Teradata、Apache Hadoopから、AzureのSnowflake、AWSのRedShift、オンプレミス・データセンターのMS SQLなど、さまざまなテクノロジーを含むことができます。
• データ・ライフサイクル全体をサポートできます。データ・ファブリックは、データ – 情報 – 洞察のライフサイクルのすべてのフェーズを包含しています。データ・ファブリックのあるノードが生データを別のノードに提供すると、そのノードが今度は分析を実行します。これらの分析結果はファブリック内のREST APIとして公開され、意思決定のためにトランザクションSoR（記録システム）で利用することができます。
• 分析の世界とトランザクションの世界を統合するように設計されています。データ・ファブリックでは、すべてがノードであり、ノードはさまざまなメカニズムで相互に作用します。これらの中には、データの移動を必要とするものもあれば、移動せずにデータアクセスができるものもあります。このアーキテクチャーでは、データのサイロ化（および区別）は最終的に解消されるというのが基本的な考え方です。
• 本質的に安全。データがデータ・ファブリックの中を移動したりアクセスされたりするたびに、セキュリティーとガバナンスのポリシーが適用されます。IstioがKubernetesのコンテナにセキュリティー・ガバナンスを適用するように、データ・ファブリックは同様の原則に従ってデータにリアルタイムでポリシーを適用します。
• データ・ディスカバビリティーをサポートします。データ・ファブリックでは、データ資産をカテゴリー別に公開することができ、企業全体のデータ・マーケットプレイスを構築することができます。このマーケットプレイスでは、メタデータとナレッジグラフを活用した検索メカニズムが提供され、資産の発見が可能になります。これにより、データ・ライフサイクルのあらゆる段階でデータにアクセスすることが可能になります。

データ・ファブリックの登場は、企業文化や運用モデルを変革する新たな機会をもたらします。データ・ファブリックは分散型でありながら包括的であるため、その利用によって連携型でありながら統一されたガバナンスが促進されます。これにより、データの信頼性・確実性がより高まります。マーケットプレイスにより、ビジネス全体のステークホルダーがデータを発見し、革新のために利用することが容易になります。多様なチームがコラボレーションしやすくなり、共通の目的意識を持って共有データ資産を管理できるようになります。

データ・アーキテクチャーとしては、データ・ファブリックもレイクハウスもまだ成熟途上にあります。しかし、その将来性は明るいものです。これらの新しいテクノロジーによって、いつの日かトランザクションの世界と分析の世界が融合し、データへのアクセスが民主化され、データに基づく洞察が自由かつ迅速に行われるようになるでしょう。

製品・サービス・技術 情報

エンタープライズレベルのIBMのデータ・ファブリック ソリューションについてはこちらから

問い合わせ情報

本記事は「An evolutionary history of enterprise data architectures(written by Sandipan Sarkar)」を抄訳し、一部編集したものです。