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