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