API プロトコル
Zerobus Ingest は、gRPC (SDK 経由)、REST、OpenTelemetry (OTLP)、MQTT、Kafka 互換 APIs という複数の API プロトコルを持つ 1 つのエンドポイントを公開します。これらはすべて Unity Catalog の Delta テーブルに直接書き込まれるため、各プロデューサーに最適なプロトコルを選択します。
次の図は、ソースストリームおよびAPIからのレコードが、自動スケーリングおよびロードバランシングを通過して、ステートレスなZerobusノードの水平方向スケーラブルなプールにどのように流れるかを示しています。各ノードには、先行書き込みLogと、レコードをUnity Catalog管理のDeltaテーブルにバッチcommitするレイクハウスライターがあります。図のソースラベルは代表的なものです。MQTTは、ロードバランシング、耐久性のあるストレージ、およびテーブルのマテリアライズーションを通じて、同じパスをたどります。
どのプロトコルを使用すべきですか？
プロトコル | どのようなタスクにベストなのか | 理由 |
|---|---|---|
gRPC (SDK) | 大容量ストリーミングプロデューサー：チェンジデータキャプチャ、クリックストリーム、Logsおよびイベントフォワーダー。 | 永続的な接続は、最も高い持続的なthroughputを実現し、ストリームごとの順序を保持します。Python、Java、Rust、Go、TypeScript、および（ベータ版）C++ と C# / .NET で利用可能です。クライアントを記述するを参照してください。 |
REST | 頻繁にレポートを行わないエッジデバイスやIoTデバイスなど、軽量または「チャッティ（通信頻度が高い）」なクライアントの大規模なフリート。 | ステートレス：各リクエストは独立しているため、クライアントは接続を開いたままにしません。データを時折送信するデバイスにとってよりシンプルです。REST の例を参照してください。 |
OpenTelemetry (OTLP) | トレース、Logs、メトリクスをすでに送信している観測可能性パイプライン。 | カスタム統合なしで、既存の OpenTelemetry SDK またはコレクターを Endpoint に向けます。Zerobus Ingest を使用した OpenTelemetry データの取り込みを参照してください。 |
MQTT | すでに MQTT v5 メッセージをパブリッシュしている IoT、エッジ、およびテレメトリ アプリケーション。 | MQTT v5 クライアントを再利用して、JSON レコードをターゲットテーブル名にちなんだトピックにパブリッシュします。Use MQTT with Zerobus Ingest を参照してください。 |
Kafka 互換 APIs | すでに Kafka プロトコルに対応しているプロデューサーや、Kafka に出力するツールがあり、最小限のコード変更でそのデータを Delta に取り込みたい場合。 | Databricks SDK を使用せずに、既存の Kafka プロデューサーを再利用します。Endpointに向け、ターゲットテーブル名にちなんだトピックにプロデュースします。Zerobus Ingest で Kafka 互換 APIs を使用するを参照してください。 |
SDK を使用した gRPC
Zerobus SDK は、ストリームと呼ばれる永続的な双方向 gRPC 接続をラップします。接続が開いたままになるため、gRPC は最高の持続的な throughput を実現し、継続的かつ大量のインジェストに推奨されるパスとなります。各オープンストリームは長期間存続する接続であるため、クライアントの throughput は、開くストリームの数に応じてスケーリングします。
SDK は接続管理、オフセット追跡、リカバリを自動的に処理します。Python、Java、Rust、Go、TypeScript、および (ベータ版) C++ と C# / .NET で利用可能です。これらは言語間で同等の動作を提供するため、アプリケーションに適したものを選んでください。gRPC 上で、SDK は JSON、protobuf、および Apache Arrow のレコード形式をサポートしています。メッセージタイプを参照してください。
SDKを使用してクライアントを記述する方法（言語ごとの例を含む）については、「クライアントの記述」を参照してください。
REST
REST インターフェースはステートレスです。各リクエストは、開いている接続を保持することなく、単独で完了します。これにより、軽量または断続的なプロデューサーを大量に抱える環境に適しています。例えば、デバイスごとに永続的な接続を維持することが非現実的である、ステータスを頻繁に報告しないエッジデバイスや IoT デバイスなどが挙げられます。
REST取り込みは、リクエストレートのクォータによって管理されます（Zerobus Ingestのクォータを参照）。大量のデータを扱うプロデューサーの場合、個別のRESTリクエストを多数発行するよりも、gRPC経由のSDKを使用する方が高いthroughputを維持できます。頻繁に送信しない、または永続的な接続を維持できないプロデューサーには、RESTを予約してください。
OpenTelemetry (OTLP)
Zerobus Ingest には、ネイティブの OpenTelemetry Protocol Endpoint が含まれています。システムがすでに OpenTelemetry のトレース、ログ、メトリクスを生成している場合は、既存の OTLP エクスポーターまたはコレクターを Zerobus Ingest に向けることで、通常は設定を変更するだけで、そのテレメトリを所有する Delta テーブルに直接格納できます。Zerobus Ingest を使用した OpenTelemetry データの取り込みを参照してください。
MQTT
ベータ版
この機能はベータ版です。
MQTT インターフェイスは、ポート 8883 で TLS を介した MQTT v5 接続を受け付けます。1つの接続で1つのテーブルを対象とし、各メッセージには1つのUTF-8 JSONオブジェクトが含まれます。プロデューサーが耐久性のある確認応答を必要とする場合は、quality of サービス (QoS) レベル 1 を使用します。セットアップ、認証、制限事項、およびPythonの例については、Use MQTT with Zerobus Ingestを参照してください。
Kafka 互換 APIs
ベータ版
Kafka 互換の APIs はベータ版です。
Zerobus Ingest は Kafka 互換のプロデューサー APIs を提供しているため、Databricks SDK を使用せずに任意の Apache Kafka プロデューサークライアントで取り込みを行うことができます。既存の Kafka プロデューサーを Endpoint に向け、ターゲットテーブル名にちなんだトピックにプロデュースすると、レコードは Unity Catalog の Delta テーブルに格納されます。これは、すでに Kafka プロデューサー、または Kafka に出力するコレクターやエージェントを実行しており、最小限のコード変更でそのデータを Delta にルーティングしたい場合に最適です。
Kafka 互換の APIs は Kafka プロトコルのプロデューサー側のサブセットを実装しており、書き込み専用です。コンシューマー、管理、およびトランザクションの APIs は利用できません。JSONレコードのみを受け付けます。throughputは、個々の接続ではなく、ワークスペースごとのリクエストレートクォータによって管理されます。特定のクォータについては、Zerobus Ingestクォータを参照してください。最高のthroughput、レコードごとの確認応答、および自動リカバリを実現するには、代わりに gRPC 経由で Zerobus SDK を使用してください。
セットアップ、認証、およびプロデューサーの例については、Zerobus Ingest で Kafka 互換 APIs を使用するを参照してください。
関連
- メッセージタイプ：これらのプロトコルで使用可能なレコード形式。
- Zerobus Ingest の使用: SDK または REST API を使用してクライアントを作成します。
- Zerobus Ingest を使用して OpenTelemetry データをインジェストする: OpenTelemetry データをインジェストします。
- Zerobus Ingest で MQTT を使用する: MQTT v5 を使用して JSON レコードをパブリッシュします。
- Zerobus Ingest のリリースステージ: 各インターフェースおよびレコード形式のリリースステージ。
- Zerobus Ingest で Kafka 互換 APIs を使用する：Kafka 互換のプロデューサー APIs を使用します。