ゼロバス・インジェスト概要

Zerobus IngestはプッシュベースのストリーミングAPIで、メッセージバスを実行せずにUnityカタログのDeltaテーブルに直接データを高速で書き込むことができます。 ワークフローは2段階で、 テーブルを作成し、それにデータをプッシュします。 Zerobus Ingestはパーティション、ブローカー、パイプラインの管理を不要にします。 これはサーバーレスのエンドポイントで、ワークスペースでデフォルトでオンになっていて、接続を増やすごとにスケールします。

高スループットとほぼリアルタイムの新鮮さを追求して構築されたZerobus Ingestは、数千クライアントから同じテーブルへの大量同時書き込みを処理し、数秒でDeltaに記録を格納するため、データは到着やほぼ即座にクエリ対応が可能です。

  • Zerobus Ingestは一部の地域で利用可能です。 ワークスペースとターゲットテーブルの両方がサポートされている領域にある必要があります。 サポートされているリージョンの一覧については 、「インジェスションの可用性」をご覧ください。

高いスケーラビリティを重視して構築されています

Zerobus Ingestは、容量を計画しなくても高いスケーラビリティを重視して設計されています。 24時間以内に1兆件以上のレコードを単一のDeltaテーブルに取り込み、数千クライアントからの大量の同時書き込みを処理しています。これは 「Incesting the Milky Way: Petabyte-Scale with Zerobus Ingest 」ブログ記事で説明されています。 デフォルトのスループットクォータについては、 Zerobus Ingest クォータを参照してください。

「Hello World」クライアントとペタバイト規模のワークロードは基本的に同じコードで動作します。 スケールはアプリケーションを書き直すのではなく、プロデューサーを増やすことで行われます。

Zerobus Ingestはサーバーレスで、負荷の変化に応じて容量を増減します。 ストリームは動的分割単位として機能し、サービスが需要の変化に応じて容量を再調整するために開閉・回転します。

Zerobus Ingestがどのようにこれを実現しているかについては、「 How Zerobus Ingestのスケールアップ」をご覧ください。

メッセージバスは不要です

多くのチームは、データが湖のハウスに送られる際にバッファリングするためだけに、プロデューサーとテーブルの間にKafkaのようなメッセージバスを設置しています。 その結果、ホップ、コスト、運用上のオーバーヘッドが増え、ブローカーのサイジング、パーティションの再バランス、そして監視すべきコンシューマーラグも増えます。 Zerobus Ingestはその中間層を取り除き、プロデューサーが直接Deltaに書き込みできるようにします。

メッセージバスを使用したインジェストでは、プロデューサーからのデータはDeltaテーブルに到達する前にブローカーとインジェストジョブを経由します。一方、Zerobus Ingestでは、プロデューサーがDeltaテーブルに直接接続されます

同じデータが多くの非レイクハウス利用者に供給される場合や、マイクロサービス間メッセージングが必要な場合、メッセージのファンアウトにメッセージバスは依然として適任のツールです。 その場合、そのデータもレイクハウスに持ちたい場合は、Azure Databricks管理のストリーミングコネクタを使ってメッセージバスからレプリケートしてください。 しかし、湖畔の家が目的地の場合、ゼロバス・インジェストはよりシンプルで直接的なルートです。

どのように機能するのか

プロデューサーはZerobus Ingestにストリームを開き、レコードをターゲットのDeltaテーブルにプッシュします。 サービスは各レコードをテーブルスキーマに対して検証し、それを耐久性のあるものにします。 レコードが持続性を持つと、Zerobus Ingestは迅速にそれを認識するため、プロデューサーは各レコードを待つことなく送り続けられます。 データはその後すぐに、通常数秒以内にテーブルに物質化されます。 Zerobus Ingestの動的でパーティションレスな設計はインジェストを柔軟にするため、サーバーレス計算はワークロードに合わせてスケールします。

Zerobus Ingestの仕組み:プロデューサーはレコードをZerobus Ingestエンドポイントにプッシュし、そこで検証、耐久性、認識、そしてUnity Catalog Deltaテーブルに具現化します

ストリームやZerobus Ingestのスケールについての詳細な説明については、 Zerobus Ingestの概念を参照してください。 非同期クライアントおよびサーバー通信モデルについては、 非同期通信を参照してください。

テーブルを作成し、その後データをプッシュします

Zerobus Ingest SDKを使用できるか、対応するAPI(gRPC、REST、OpenTelemetry)を呼び出せるアプリケーションは、データをDeltaテーブルにストリーミングできます。 テーブルのスキーマは、各レコードが何を含むべきかを定義します。 まず、ターゲットテーブルを作成します:

CREATE TABLE main.default.air_quality (
  device_name STRING,
  temp INT,
  humidity INT
);

その後、サービスプリンシパルにテーブルへのアクセスを許可した後、レコードを取り込むには数行のコードが必要です:

from zerobus.sdk.sync import ZerobusSdk
from zerobus.sdk.shared import TableProperties

sdk = ZerobusSdk(SERVER_ENDPOINT, DATABRICKS_WORKSPACE_URL)

table_properties = TableProperties("main.default.air_quality")
stream = sdk.create_stream(CLIENT_ID, CLIENT_SECRET, table_properties)

stream.ingest_record_offset({"device_name": "sensor-1", "temp": 22, "humidity": 55})
stream.close()

1つのレコードを取り込む同じコードがペタバイト単位でスケールします。つまり、より多くのプロデューサーから実行します。 全文の解説については 「Use Zerobus Ingest」をご覧ください。

Zerobus Ingestの使用時期

Zerobus Ingest を使用する場合… 別のツールを検討する場合…
レイクハウスはあなたのデータの唯一の行き先です。 同じデータを多くの湖の家以外の利用者にも広める必要があります(Kafkaのようなメッセージバスを使い、 Streamingコネクタ ーでそのデータを湖の家に複製するなど)。
高スループットで並行してDeltaテーブルに直接書き込みしたいのです。 マイクロサービス間のメッセージング(メッセージバスを使う)が必要です。
ほぼリアルタイムの新鮮度(秒単位)があなたのニーズに合っています。 処理経路には秒単位未満の運用遅延が必要です( リアルタイムモードの概念を用いてください)。
プロデューサーをコントロールし、APIにデータをプッシュできます。 すでにクラウドストレージに入ったファイルからファイルを取得しています( Auto Loaderを使え)。

設計時に考慮すべき点の一つは次のとおりです。Zerobus Ingest は ストリームごとに 順序を保証しますが、複数のストリームにまたがるグローバルな順序は保証しません。 ストリームごとの順序付けやそれに合わせた設計方法については、 Streamsをご覧ください。

一般的なユース ケース

  • IoT とデバイス テレメトリ: 大規模な分散フリートからのセンサー、車両、スマートデバイスのデータを、管理された Delta テーブルに直接ストリーミングして取り込みます。
  • オンプレミスからクラウドへ:オンプレミスとハイブリッドシステムをレイクハウスにブリッジし、その間にブローカーインフラを構築せずに済む。 プライベート接続およびファイアウォール設定については、 ネットワークの考慮事項を参照してください。
  • アプリケーションおよびクリックストリームイベント:クラウドやエッジアプリケーションからイベントをプッシュし、ほぼリアルタイムの分析を実現します。
  • 変更データキャプチャ (CDC): 運用システムからの行の変更を Delta に取り込む。
  • 観測データ:OpenTelemetryのトレース、ログ、メトリクスを所有するDeltaテーブルに送信してください。 Zerobus IngestによるOpenTelemetryデータの取り込みを参照してください。

データ送信方法

Zerobus Ingestは複数のインターフェースをサポートする1つのエンドポイントであり、各プロデューサーに最適なものを選択できます。

  • gRPC上のSDKは、Python、Java、Rust、Go、TypeScript、そして(ベータ版では)C++およびC# / .NETでの高スループットストリーミングクライアントです。 大量の順序付き取り込みに最適です。 クライアントを作成する を参照してください。
  • REST API:軽量または「チャットが多い」クライアント向けのステートレスインターフェースで、大規模なエッジデバイス群などに対応します。 クライアントを作成する を参照してください。
  • OpenTelemetry (OTLP): 既存のOpenTelemetryコレクタをZerobus Ingestに向けることで、カスタム統合を行うことなく、トレース、ログ、メトリクスを取り込めます。 Zerobus IngestによるOpenTelemetryデータの取り込みを参照してください。
  • Kafka 互換 APIBeta): Azure Databricks SDK を使用せずに、既存の Apache Kafka プロデューサーの送信先を Zerobus Ingest に指定できます。 Zerobus IngestでKafka互換APIを使う方法を参照してください。

Zerobus Ingest スケーリングアーキテクチャ:ソースはプロトコルバッファ(protobuf)、JSON、ArrowレコードをgRPC、REST、OpenTelemetry、Kafka互換API経由で送信し、これらは自動スケーリングとロードバランシングを経て、水平にスケーラブルな状態のないZerobusノードのプールへと流れます。各ノードは書き込み先行ログとLakehouseライターを持ち、LakehouseライターがUnityカタログ管理のDeltaテーブルに一括コミットします

すべてDeltaテーブルに直接書き込みます。 詳細な比較方法や選択方法については 、APIプロトコルをご覧ください。 最初のクライアントを書くには、「 Use Zerobus Ingest」をご覧ください。

費用

Zerobus Ingestの料金は「Automated Serverless」SKUに対して請求されます。 価格は 、Lakeflow Connect の価格ページで入手できます。

使用状況の監視

請求可能使用システムの表を通じて支出を監視できます。 「課金対象使用状況システム参照表」を参照してください。 次の条件を使用して、Zerobus Ingest の使用状況をフィルター処理します。

  • billing_origin_product = 'LAKEFLOW_CONNECT'
  • product_features.lakeflow_connect.zerobus_request_type データの取り込み方法を識別します: 'GRPC' (SDKストリーミング)、 'HTTP' (REST)、 'OTEL_GRPC' および 'OTEL_HTTP' (OpenTelemetry/OTLP)、または 'KAFKA' (Kafka互換API)。