データファブリックとデータメッシュ：どこが違うのか？

こちらのVentureBeat記事の翻訳です。(2022/4/8)
データメッシュでのドメイン間接続でDelta Sharingが話題になることが多いので、この記事が目につきました。

パンデミック時にますます多くのプロセスがオンライン化される中、企業は業務に対するより高い洞察力を得るためにアナリティクスを導入しています。StarburstとRedHatが委託した2021年の調査によると、53%の企業がパンデミック期間中、データアクセスが「より重要になった」と考えています。この結果は、ZohoのIT部門であるManageEngineが2021年に行った世論調査で、20%以上の組織が世界平均と比較してビジネスアナリティクスの利用率を高めたという結果と一致しています。

StarburstとRedHatの調査では、回答者の35%がリアルタイムのビジネスリスクを分析することを求めていると回答し、36%が「より知的な」顧客エンゲージメントによる成長と収益創出を求めていると回答しています。しかし、分析における課題を強調するように、回答者の37%以上が、ストレージソースがばらばらであったり、データパイプラインの開発に問題があったりして、「意思決定に関係するタイムリーなデータ」にアクセスできる能力に自信がないと答えています。

データ分析・管理におけるハードルに対する答えとして、2つの新しいコンセプトが提唱されています。1つは「データファブリック」と呼ばれるデータ統合アプローチで、組織がデータをオーケストレーションするためのアーキテクチャと、そのアーキテクチャ上で動作するサービスが含まれます。もうひとつは「データメッシュ」で、分散型の接続レイヤーを提供することでデータの可用性という課題を軽減し、企業が場所を越えてさまざまなソースからデータにアクセスできるようにすることを目的としています。

データファブリックもデータメッシュも、ビジネス、技術、組織のさまざまな目的に利用することができます。例えば、データファブリックは、反復的なデータ変換作業を自動化することでデータ・サイエンティストの時間を節約し、セルフサービス型のデータアクセスツールを強化することができます。また、データファブリックとデータメッシュは、すでに使用されているデータ管理ソフトウェアを統合して補強し、費用対効果を高めることも可能です。

データファブリック

AIや機械学習などの技術を組み合わせたデータファブリックは、データのソース、種類、場所とデータにアクセスするための方法を結ぶために伸びる織物のようなものです。ガートナーでは、ローカル、エッジ、データセンター環境にわたるデータの「設計、展開、利用」をサポートするために、「既存の、発見可能で推論可能なメタデータ資産」に対する分析であると説明しています。

データファブリックは、さまざまなアプリケーションからのリアルタイムデータを継続的に識別、接続、クレンジング、エンリッチし、データポイント間の関係を発見します。例えば、データファブリックは、さまざまなデータパイプライン（ソースから生データを取り込み、宛先に移動させる一連の動作）を監視し、最も反復性の高いタスクを自動化する前に、より良い代替手段を提案することができます。また、データファブリックは、失敗したデータ統合ジョブを「修復」し、データセットの作成とプロファイリングのようなより複雑なデータ管理を行い、誰がどのデータやインフラにアクセスできるかを制限して、データを管理し保護する方法を提供することもできます。

データ間の関係を明らかにするために、データファブリックは、オブジェクト、イベント、状況、コンセプトなどのデータの説明を相互にリンクして格納するグラフを構築します。アルゴリズムは、このグラフをさまざまなビジネス分析の目的に使用することができ、例えば、予測を行ったり、以前は見つけにくかったデータセットを表示したりすることができます。

データファブリックのソリューションベンダーであるK2 Viewは、次のように説明しています。「データファブリックは、特定の顧客セグメント、製品ライン、特定の地域の全小売店など、ビジネスエンティティを360度見渡した上で、継続的にデータを提供します。洗練された機械学習モデルは、データファブリックに導入され、個々のエンティティ（顧客、製品、場所など）に対してリアルタイムに実行されます。データファブリックは、オンデマンドでリアルタイムに機械学習モデルを実行し、個々のエンティティの完全かつ最新のデータを供給します。機械学習の出力は即座に要求元のアプリケーションに返され、将来の分析のためにエンティティの一部としてデータファブリックに保存されます。」

データファブリックは、多くの場合、技術データ、ビジネスデータ、運用データなど、さまざまな種類のデータを扱います。理想的なシナリオでは、レプリケーション、ストリーミング、仮想化など、さまざまなデータ配信の「スタイル」にも対応します。さらに、優れたデータファブリック・ソリューションは、技術インフラを容易に解釈できる堅牢な可視化ツールを提供し、データやアプリケーションがどこにあっても、ストレージのコスト、パフォーマンス、効率、さらにはセキュリティを監視することができます。

データファブリックは、分析だけでなく、クラウドベンダーやコンピューティングリソース間の切り替えによる混乱を最小限に抑えるなど、多くのメリットを企業に提供します。また、データファブリックによって、企業やそこで働くデータ分析、営業、マーケティング、ネットワーク設計、セキュリティの各チームは、データの場所に関係なくインフラのエンドポイントを接続し、変化するテクノロジーニーズに基づいてインフラを適応させることができます。

フォレスターは、2020年のレポートで、IBMのデータファブリックソリューションは、データ配信を60倍加速し、投資収益率を459%増加させることができると報告しています。しかし、データファブリックにはデメリットもあり、その主なものは実装の複雑さです。例えば、データファブリックでは、異なるデータやシステムを公開し統合する必要があり、これらのシステムはしばしば異なるデータ形式をとることがあります。このような相互運用性の欠如は、データの調和や重複排除の必要性といった摩擦を生む可能性があります。

データメッシュ

一方、データメッシュは、大規模な企業データアーキテクチャを、専門チームが管理するサブシステムに分割するものです。データ配信などの推奨事項をメタデータに依存するデータファブリックとは異なり、データメッシュは、メッシュ内の「ドメイン」を監督する専門家の専門知識を活用します。

「ドメイン」は、関連するマイクロサービスの独立したクラスターで、さまざまなインターフェイスを通じてユーザーや他のドメインと通信します。マイクロサービスは、疎結合で独立配備可能な多数の小規模サービスから構成されています。

ドメインは通常、コード、ワークフロー、チーム、技術環境を含み、ドメイン内で働くチームはデータを製品として扱います。クリーンで新鮮かつ完全なデータは、権限と役割に基づいてあらゆるデータ消費者に配信され、「データ製品」は特定の分析および運用目的に使用されるように作成されます。

データメッシュに価値を与えるには、エンジニアはデータセットを深く理解する必要があります。エンジニアは、データ消費者へのサービス提供や、ドメイン周りの組織化、すなわちドメインのテスト、展開、監視、保守を担当するようになります。さらに、異なるドメインが相互運用性と一貫したデータガバナンス、標準、観測性のレイヤーで接続されていることを確認する必要があります。

データメッシュは分散化を促進し、チームは特定の問題に集中することができます。また、専門用語や技術的な知識ではなく、ビジネス的な文脈で分析を進めることができるため、分析を強化することができます。

しかし、データメッシュには欠点もあります。例えば、ドメインが知らず知らずのうちにデータを重複させ、リソースを浪費する可能性があります。データメッシュの分散構造は、データメッシュが十分にインフラに依存しない場合、集中型アプローチよりも多くの技術専門家を必要とし、スケールアップする可能性があります。また、ドメインが独自のデータパイプラインを作成するため、技術的負債が増加する可能性があります。

データメッシュとファブリックの使用

長所と短所を比較検討する際、データメッシュとデータファブリックは技術ではなく概念であり、相互に排他的ではないことを念頭に置くことが重要です。組織は、特定の部門、またはすべての部門において、データメッシュとデータファブリックの両方のアプローチを適切に採用することができます。Microsoftでビッグデータおよびデータウェアハウジングのソリューションアーキテクトを務めていたJames Serra氏は、この2つの概念の違いは、ユーザーがデータにアクセスする際に生じるものであると述べています。

「データファブリックとデータメッシュは、どちらも複数のテクノロジーやプラットフォームにまたがるデータにアクセスするためのアーキテクチャを提供しますが、データファブリックはテクノロジー中心であるのに対し、データメッシュは組織の変化に焦点を当てています」と、彼はブログ記事に書いています。「データメッシュはアーキテクチャよりも人とプロセスに関するものであり、データファブリックはデータとメタデータの複雑さにスマートな方法で取り組み、連携させるアーキテクチャのアプローチである。」

Eckerson GroupのアナリストであるDavid Wells氏は、この違いにこだわることに注意を促しています。彼は、求められるビジネス目標を達成するために必要な構成要素よりもはるかに重要度が低いと主張しています。Wells氏は、最近のブログ記事で、「これらはアーキテクチャのフレームワークであって、アーキテクチャではありません。」と書いています。「フレームワークを自社のニーズ、データ、プロセス、用語に適合させ、カスタマイズするまでは、アーキテクチャは存在しないのです。」

つまり、データファブリックとデータメッシュは、当分の間、同じように重要であり続けると言うことです。それぞれ異なる要素を含んでいますが、データ基盤が広大で、かつ拡大しつつある組織に、より優れた分析能力をもたらすという同じ目標に向かっています。