Adam Bellemare, Confluentの主要技術者 生成型AIの出現は、長い間議論されていた質問を再現しました:どのようにしてあなたはあなたのシステムやサービスに彼らの仕事をするために必要なデータを得るのですか? 最も一般的にマイクロサービスを求められ、データ湖を埋め込む間、生成型AIはこのリストの最前線にその道を押し上げました。 データにアクセスするための主要な問題は、データの元のレコードを作成するサービスが必ずしもそれにアドホックアクセスをホストするのに最適ではないということです. あなたのサービスは、実際のビジネス責任を果たすことができるかもしれませんが、潜在的なクライアントにそのデータを提供することはできません. While you can expose the data using an interface, the service may not be able to handle the query volume, or the types of queries that are expected. データアナリストは数十年前、この問題に直面したが、元の記録システム(データアナリスト)は データエンジニアは、元のレコードシステムからデータを抽出し、それをロードします。 ツールとテクノロジーは数十年にわたって変化してきたが、真髄は同じである:オペレーティングスペースから分析スペースにデータをコピーする。 OLTPデータベース OLAPデータベース フィグ1 : 単純な Extract-Transform-Load (ETL) ワークで、オペレーティング ドメインから分析ドメインにデータをコピーします。 フィグ1 マイクロサービスは同じ問題を抱えています。どのように彼らが必要なデータを得るのですか? 一つの一般的な選択肢は、HTTP、SOAP、またはRPCを介して、例えば、元のレコードシステムへの直接のクエリです。データアナリストのケースと同様に、同じ制限が適用されます。サービスは、アクセスパターン、遅延要件、および他の依存サービスがそれに課した負荷を処理できないので。 Fig 2 : 他のサービスは、データを必要とし、独自のビジネス使用ケースを解決し、ポイント対ポイント接続のウェブを生み出します。 Fig 2 : 問題のクロスは、 このオープンエンドの要件は、サービスが直接のビジネス責任を果たすために良い仕事をしなければならず、また、直接のビジネス使用事例を超えるデータアクセスパターンをサポートする必要があります。 the services that create the data must also provide access to it for external systems データを作成したアプリケーションは、他のすべてのサービスのオンデマンドデータクエリを満たすことも責任を負います。 Fig 3: サービス、システム、AIへのデータアクセスを提供するソリューションは、 , only responsible for the circulation and distribution of data across an organization. これが組織全体のデータの流通と配布の責任です。 入る(たまに知られることもある) ( ) dedicated data communications layer data streaming event streaming 要するに、サービスは重要なビジネスデータを持続可能な、スケーラブルで再生可能なデータストリームに公開します。その他のサービスは、そのデータを必要とし、関連するデータストリームにサブスクリプトし、データを消費し、ビジネスニーズに応じてそれに反応することができます。 データ ストリームによって提供される専用のデータ コミュニケーション レイヤーは、組織全体でデータの交換を簡素化します。 Fig 4: データストリーミングは、あらゆるサイズ(マイクロやマクロ)のサービスをパワーアップし、データ湖やその他の分析エンドポイントを埋め込み、ビジネス全体でAIアプリケーションやサービスをパワーアップすることができます。 サービスは、すべてのデータをデータストリームに書き込む必要はありませんが、他の人にとって有用なものだけです。始めるには、サービスが処理するリクエスト、例えば GET リクエストを調査することです。 他のサービスは、データストリームからデータを読み取って、独自の状態のストアを更新し、独自のビジネス論理を適用し、独自のストリームに発表する結果を生成することによってそれに反応します。 彼らはもはや生産者サービスからアドホックデータを要求しません - 代わりに、彼らは新しいデータ、削除されたデータ、およびデータの変更を含むすべてのデータをデータストリームを通じて取得します。 彼らはもはや要求に応じてデータを要求しないので、彼らは彼ら自身のデータストア内で気にする状態のレプリカを維持しなければなりません(注:彼らはすべてのデータを保存する必要はありません。 消費者は、データストリームでデータが利用可能である限り、独自のパフォーマンス指標の責任を負い、その負荷を処理したり、そのSLAを満たすことはもはや生産者に依存しない。 データストリーミングは、マイクロサービス、AI、およびアナリティクスに大きな利点を提供します。 システム、プロセス、またはサービスに必要なデータを提供します. ストリームに書かれたデータは組織全体で広く利用できます. プロデューサーサービスはデータを一度書き込み、消費者は必要な限り頻繁にデータを読み取ることができます. 安価なディスクおよびクラウドストレージを使用すると、必要な限りストリームでデータを保持できます(無限の保存を含む!) 生産者と消費者の間の依存性を簡素化するプロデューサーは、データに依存するプロデューサーのクエリパターンを処理する責任を負いません 消費者は、ビジネスのニーズを満たすために、プロデューサーのコンピューティングおよびストレージのパフォーマンスに依存していません。 割り当て:消費者サービスは、サービスの大幅な悪化なしに生産者の停止を容認できますが、データストリームはもはや更新されなくなり、最終的に停滞します。 パワーオペレーティング(OLTPベース)システム: データストリームは、データを消費し、自身のデータをストリームに書き込むイベント駆動(マイクロ)サービスを構築することを可能にします。 リアルタイムおよびバッチ分析の両方にパワー:Analyticsは、リアルタイムの分析のために、またはバッチベースの分析のためにIcebergまたはDeltaテーブルを構築するためのソースとして、同じデータストリームを使用することができます。 Fuel Gen AI および AI エージェント: 同じストリームが生成型 AI を動かすこともできます. データ ストリームは、低遅延検出拡張生成(RAG)とコンテキストビルディングを可能にしますので、あなたの AI クエリには常に最も関連性があり、最新の情報があります。 悪いデータを一度修正し、あらゆる場所に拡散する:悪いデータをソースで修正し、データストリームを通じてすべてのダウンストリームの消費者に拡散することができます。 ポイント対ポイントリクエスト/応答接続を使用することもできます. It is not a all or nothing proposition. You can gradually migrate some services and workloads to data streaming, while leaving others to rely on their existing request-response architectures. あなたは、いくつかのサービスやワークロードを徐々にデータストリーミングに移行することができます。 データ ストリームは、同一のデータ ソースからすべての操作、分析、AI をパワーアップできます。データ コミュニケーション レイヤーとして、同僚とそのサービスがビジネス用例に必要なデータを見つけて使用することを容易にします。 最後の大きな利点の1つは戦略的な利点です。この利点は定量化しにくいが、間違いなく最も重要な利点の1つです。データストリーミングレイヤーに投資することで、データを稼働させるための幅広い可能性が開きます。 Apache Kafkaは、データストリーミングのための人気のある選択肢で、あらゆる種類のシステムやサービスと統合するためのコネクタの幅広い範囲を提供しています。あなたはもはや、データ湖のオファーに統合されたAIや、すべての分析データを格納しているクラウドサービスプロバイダーに付属するAIのみを使用することに制限されていません。代わりに、すべての種類のプロバイダーからのモデルを簡単に試すことができます。 データについて考えること、それにアクセスする方法、そしてそれが必要な場所にアクセスする方法は常に課題であり、特に運用/分析の格差に関してです。しかし、GenAIの登場により、この古い問題を解決するための重さと重要性をさらに高めました。その核心は単純な原則です - あなたのビジネスサービスがビジネス用例に焦点を当てて、データ通信層が遅延データストリーミングを通じてそれを必要とするすべての人にデータを提供するようにしてください。