データ ファブリックの謎を解く – GigaOm
「データ ファブリック」という用語はテクノロジー業界で使用されますが、その定義と実装はさまざまです。プロバイダーの間でこれを目にしたことがあります。昨秋、ブリティッシュ テレコム (BT) はアナリスト イベントで自社のデータ ファブリックについて話しました。一方、ストレージ分野では、ネットアップはインテリジェント インフラストラクチャに向けてブランドを変更していますが、以前はこの用語を使用していました。アプリケーション プラットフォーム ベンダーの Appian はデータ ファブリック製品を提供しており、データベース ベンダーの MongoDB もデータ ファブリックや同様のアイデアについて話しています。
データ ファブリックの核心は、異種のデータ ソースを抽象化および統合してシームレスなデータ レイヤーを作成する統合アーキテクチャです。原則は、異種のデータ ソースと、データへのアクセスが必要なワークロード (アプリケーション、ワークロード、さらには AI アルゴリズムや学習エンジンなど) の間に統合され同期されたレイヤーを作成することです。
このようなオーバーレイが必要になる理由はたくさんあります。データ ファブリックは、広範な統合レイヤーとして機能し、さまざまなデータ ソースに接続したり、アプリケーション、ワークロード、モデルへのアクセスを容易にする高度な機能を追加したりすることで、同期を維持しながらそれらのソースにアクセスできるようにします。
ここまでは順調ですね。ただし、課題は、データ ファブリックの原理と実際の実装の間にギャップがあることです。人々はこの用語をさまざまな意味で使用しています。 4 つの例に戻ります。
- BT は、データ ファブリックを、長距離にわたるデータ送信を最適化するために設計されたネットワーク レベルのオーバーレイとして定義します。
- NetApp の解釈では (インテリジェント データ インフラストラクチャという用語であっても) ストレージの効率性と集中管理が強調されています。
- Appian は、自社のデータ ファブリック製品をアプリケーション層でデータを統合するツールとして位置づけ、ユーザー向けツールの迅速な開発とカスタマイズを可能にします。
- MongoDB (および他の構造化データ ソリューションのプロバイダー) は、データ管理インフラストラクチャのコンテキストでデータ ファブリックの原則を検討しています。
これらすべてをどうやって切り抜けるのでしょうか？答えの 1 つは、さまざまな角度からアプローチできることを受け入れることです。データ ソースを統合する必要性を認識しながら、やりすぎないようにしながら、データの構造について概念的に話すことができます。完全にすべてをカバーする普遍的な「超ファブリック」は必要ありません。代わりに、管理する必要がある特定のデータに焦点を当ててください。
数十年巻き戻すと、サービス提供をデータベース システムから切り離そうとするサービス指向アーキテクチャの原則との類似点がわかります。次に、サービス、プロセス、データの違いについて説明しました。同じことが現在も当てはまります。ワークロードに必要なものに焦点を当てて、サービスをリクエストしたり、データをサービスとしてリクエストしたりできます。作成、読み取り、更新、削除は依然として最も単純なデータ サービスです。
また、ネットワーク アクセラレーションの起源を思い出させます。ネットワーク アクセラレーションでは、ソースに繰り返しアクセスするのではなく、データのバージョンをローカルに保持することで、キャッシュを使用してデータ転送を高速化します。 Akamai は、音楽や映画などの非構造化コンテンツを長距離にわたって効率的に転送する方法を中心にビジネスを構築しました。
これは、データ ファブリックが車輪の再発明を行っていることを示唆しているわけではありません。私たちは技術的には異なる（クラウドベースの）世界にいます。さらに、メタデータ管理、系統追跡、コンプライアンス、セキュリティ機能などの新しい側面ももたらします。これらは、データ ガバナンス、品質、出所がモデルのパフォーマンスと信頼性に直接影響する AI ワークロードにとって特に重要です。
データ ファブリックの導入を検討している場合、まず最初に、データが何のために必要なのかを考えることから始めます。これは、どのような種類のデータ ファブリックが最適であるかを示すのに役立つだけでなく、世界中のすべてのデータを管理しようとするという罠を回避するのにも役立ちます。代わりに、最も価値のあるデータのサブセットに優先順位を付けて、どのレベルのデータ ファブリックがニーズに最も適しているかを検討できます。
- ネットワークレベル: マルチクラウド、オンプレミス、エッジ環境全体でデータを統合します。
- インフラストラクチャレベル: データがストレージ プロバイダーで一元化されている場合は、一貫したデータ セットを提供するためにストレージ レイヤーに焦点を当てます。
- アプリケーションレベル: 特定のアプリケーションまたはプラットフォーム用に異種のデータセットを統合します。
たとえば、BT の場合、データ ファブリックを使用して複数のソースからのデータを統合することに内部的な価値があることがわかりました。これにより重複が削減され、運用が合理化され、データ管理がより効率的になります。これは明らかに、サイロを統合し、アプリケーションの合理化を改善するのに役立つツールです。
結局のところ、データ ファブリックはモノリシックな、万能のソリューションではありません。これは、製品と機能によってサポートされる戦略的な概念レイヤーであり、柔軟性を高め、データ配信を改善するのに最も合理的な場合に適用できます。導入ファブリックは、「設定したらあとは忘れる」作業ではありません。ソフトウェア自体だけでなく、データ ソースの構成と統合も含めて、測定、導入、保守を継続的に行う必要があります。
データ ファブリックは概念的には複数の場所に存在できますが、配信作業を不必要に複製しないことが重要です。したがって、ネットワーク全体でデータを収集する場合でも、インフラストラクチャ内でデータを収集する場合でも、アプリケーション レベルでデータを収集する場合でも、原則は同じです。つまり、ニーズに最も適した場所でデータを使用し、提供されるデータに応じてデータを進化させます。
データ ファブリックの謎を解く: データ ソースとワークロードの間のギャップを埋めるという投稿は、Gigaom に最初に掲載されました。
