データ ファブリックの謎を解く – データ ソースとワークロードの間のギャップを埋める

「データ ファブリック」という用語はテクノロジー業界全体で使用されていますが、その定義と実装はさまざまです。私はこれをベンダー全体で見てきました。昨年秋、ブリティッシュ テレコム (BT) はアナリスト イベントで自社のデータ ファブリックについて話しました。一方、ストレージ分野では、NetApp はブランドをインテリジェント インフラストラクチャに再方向付けしていますが、以前はこの用語を使用していました。アプリケーション プラットフォーム ベンダーの Appian はデータ ファブリック製品を提供しており、データベース プロバイダーの MongoDB もデータ ファブリックや同様のアイデアについて話しています。

データ ファブリックの核心は、異種のデータ ソースを抽象化および統合してシームレスなデータ レイヤーを作成する統合アーキテクチャです。原則は、異種のデータ ソースと、データへのアクセスが必要なワークロード (アプリケーション、ワークロード、さらには AI アルゴリズムや学習エンジンも増えてきています) の間に、統合された同期レイヤーを作成することです。

このようなオーバーレイが必要になる理由はたくさんあります。データ ファブリックは、汎用化された統合レイヤーとして機能し、さまざまなデータ ソースに接続したり、アプリケーション、ワークロード、モデルへのアクセスを容易にする高度な機能を追加したりすることで、同期を維持しながらそれらのソースにアクセスできるようにします。

ここまでは順調ですね。ただし、課題は、データ ファブリックの原理と実際の実装の間にギャップがあることです。人々はさまざまなことを表すためにこの用語を使用しています。 4 つの例に戻ります。

• BT は、データ ファブリックを、長距離にわたるデータ送信を最適化するために設計されたネットワーク レベルのオーバーレイとして定義します。
• NetApp の解釈では (インテリジェント データ インフラストラクチャという用語であっても) ストレージの効率性と集中管理が強調されています。
• Appian は、自社のデータ ファブリック製品をアプリケーション層でデータを統合するツールとして位置づけ、ユーザー向けツールの迅速な開発とカスタマイズを可能にします。
• MongoDB (およびその他の構造化データ ソリューション プロバイダー) は、データ管理インフラストラクチャのコンテキストでデータ ファブリックの原則を考慮しています。

これらすべてをどうやって切り抜けるのでしょうか？答えの 1 つは、さまざまな角度からアプローチできることを受け入れることです。データ ファブリックについては、データ ソースを統合する必要性を認識しながら、概念的に話すことができますが、行き過ぎないように注意してください。完全にすべてをカバーする万能の「超ファブリック」は必要ありません。代わりに、管理する必要がある特定のデータに焦点を当ててください。

数十年巻き戻すと、データベース システムからサービスの提供を切り離そうとするサービス指向アーキテクチャの原則との類似点が見えてきます。当時、私たちはサービス、プロセス、データの違いについて議論しました。同じことが現在も当てはまります。ワークロードに必要なものに焦点を当てて、サービスをリクエストしたり、データをサービスとしてリクエストしたりできます。作成、読み取り、更新、削除は、依然として最も簡単なデータ サービスです。

また、ソースに繰り返しアクセスするのではなく、データのバージョンをローカルに保持することで、キャッシュを使用してデータ転送を高速化するネットワーク アクセラレーションの起源を思い出します。 Akamai は、音楽や映画などの非構造化コンテンツを長距離にわたって効率的に転送する方法を中心にビジネスを構築しました。

これは、データ ファブリックが車輪の再発明を行っていることを示唆しているわけではありません。私たちは技術的には異なる（クラウドベースの）世界にいます。さらに、特にメタデータ管理、リネージ追跡、コンプライアンス、セキュリティ機能に関して新たな側面ももたらします。これらは、データ ガバナンス、品質、来歴がモデルのパフォーマンスと信頼性に直接影響を与える AI ワークロードにとって特に重要です。

データ ファブリックの導入を検討している場合、最適な開始点は、データが何のために必要なのかを考えることです。これは、どのような種類のデータ ファブリックが最適であるかを方向付けるのに役立つだけでなく、世界中のすべてのデータを管理しようとするという罠を回避するのにも役立ちます。代わりに、最も価値のあるデータのサブセットに優先順位を付けて、どのレベルのデータ ファブリックがニーズに最適であるかを検討できます。

1. ネットワークレベル: マルチクラウド、オンプレミス、エッジ環境全体でデータを統合します。
2. インフラストラクチャレベル: データが 1 つのストレージ ベンダーで集中管理されている場合は、一貫したデータ プールを提供するストレージ レイヤーに焦点を当てます。
3. アプリケーションレベル: 特定のアプリケーションまたはプラットフォーム用に異種のデータセットをまとめる。

たとえば、BT の場合、データ ファブリックを使用して複数のソースからのデータを統合することに内部的な価値を見出しています。これにより重複が削減され、運用が合理化され、データ管理がより効率的になります。これは明らかに、サイロを統合し、アプリケーションの合理化を改善するのに役立つツールです。

結局のところ、データ ファブリックはモノリシックで万能のソリューションではありません。これは、製品と機能によって裏付けられた戦略的な概念レイヤーであり、柔軟性を高め、データ配信を改善するのに最も合理的な場合に適用できます。デプロイ ファブリックは、「設定したらあとは忘れる」作業ではありません。ソフトウェア自体だけでなく、データ ソースの構成と統合も含めて、スコープ、デプロイ、保守を継続的に行う必要があります。

データ ファブリックは概念的には複数の場所に存在できますが、配信作業を不必要に複製しないことが重要です。したがって、ネットワーク全体、インフラストラクチャ内、またはアプリケーション レベルでデータを収集する場合でも、ニーズに最も適した場所でデータを使用し、提供するデータに応じてデータを進化できるようにするという原則は変わりません。