GAになったZerobus Ingestのディープダイブ

Deep dive on Zerobus Ingest, now GA - Databricks Community - 148385の翻訳です。

本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。

Zerobus Ingestが正式提供となり、あなたのレイクハウスのマネージドテーブルにデータをプッシュできるようになりました。Zerobus Ingestは、5秒程度のニアリアルタイムデータ取り込みを実現し、最大100MB/秒のスループット、10GB/秒を超えるテーブルスループット、および高い同時実行ワークロードをサポートします。パフォーマンスや信頼性を損なうことなしに、同じテーブルに同時に書き込みを行う数千のクライアントに対応するように設計されています。

Zerobus Ingestの動作原理

Zerobus Ingestは、最適化されたParquetファイルを用い、従来のメッセージバスレイヤーをバイパスし、Deltaテーブルに直接書き込みを行うことで、イベントストリーミングアーキテクチャを変革します。

Zerobus Ingestに送信されるレコードはテーブルにデータが到着する前にバッファされます。ACKまでの時間は約200msであり、テーブルへ書き込まれる時間は約5秒です。

パフォーマンス特性

• スループット: 接続あたり最大100MB/秒、複数の接続に対して線形にスケール
• 同時実行性: 同じDeltaテーブルに同時に書き込む数千の同時接続クライアントをサポート
• 可観測性: お使いのモニタリングスタックへのメトリクスの転送を行うためのネイティブOpenTelemetry(OTEL)サポート

本番環境のデプロイメントにおけるベストプラクティス

いつ、メッセージバスではなくZerobus Ingestを用いるのか

適切なアーキテクチャは誰がデータを必要とするのか、どれだけクイックに必要とするのかに帰着します。あなたの次のリアルタイムプロジェクトにおけるベストなパスを特定するために、このガイドをレビューください。

Zerobus Ingest: 「Deltaに直接書き込む」専門家

Zerobus Ingestはシングルシンクアーキテクチャを採用しています。一つのゴールを目標にして設計されています: イベントデータを可能な限り高速に、可能な限りシンプルにDatabricksマネージドテーブルに取り込むというものです。この直接パスによって、インフラストラクチャのオーバーヘッドを排除し、レイテンシーを削減します。最適なケース: レイクハウスが全ての下流の利用における信頼できる唯一の情報源(primary source of truth)となるテレメトリ、IoT log、クリックストリーム。

メッセージバス: 「マルチコンシューマー」ハブ

KafkaやRabbitMQのような従来のバスは、マルチシンクアーキテクチャを採用しています。複数の独立したシステム(検索インデックス、不正検知、ダッシュボードなど)が自身のペースでデータを利用できるようにするための汎用的なバッファとして動作します。最適なケース: イベント駆動マイクロサービス、リアルタイムアラートシステム、複雑なエコシステム。

本番運用における推奨技術的ガイドライン

• リキッドクラスタリングとマネージドDeltaテーブルを使いましょう: あなたのターゲットテーブルのリキッドクラスタリングを有効化しましょう。これによって、リアルタイムストリーミングによって生成される膨大なファイルは、手動のパーティショニングなしにクエリーパフォーマンスを高速化するために自動で整理されます。
• 高スループットと同時実効性を最適化しましょう: 継続的取り込みにおいては、単一かつオプンなストリームを維持しましょう。同じストリームの再利用は、新たな接続の初期化に必要な数秒の遅延を回避することでレーテンシーや内部破壊を最小化します。
• レコード、リクエスト制限に準拠しましょう:
  • 最大メッセージサイズ: それぞれ個々のメッセージは10MBに制限されます。
  • スループット制限: 接続あたり100MB/秒。負荷の高いワークロードでは複数の接続にトラフィックを分散しましょう。
• スキーマ強制: Zerobus Ingestはターゲットテーブルを決して自動で進化させません。Zerobus Ingestは、レコードがターゲットテーブルにフィットする限り継続的取り込みをサポートします。ヌル値を許可する列を持たないすべてのレコードが受け入れられますが、必要な列を持たない全てのレコードは失敗通知を受け取ります。
• マルチAZ堅牢性を確実にしましょう: 正式提供版では現状シングルAZの堅牢性をサポートしていますが、ロードマップではマルチAZのサポートが計画されています。

スキーマ戦略: 厳密な契約 vs. 「スキーマオンリード」

Zerobus Ingestの最もパワフルな機能の一つが、データ品質の厳密な強制です。後で対応するために「ガベージイン」を許可する場合のある従来のバスと異なり、Zerobusはレイクハウスに到着するものがすぐに利用できるようにします。

しかし、強制をどのように設計するのかは、あなたがあなたのデータソースをどれだけ信頼するのかに依存します。

オプションA: 厳密な契約(フォーマルなテーブル)

下流のBI、MLモデルが忠実度の高いデータに依存している場合、厳密なスキーマを定義すべきです。Zerobusは、あなたのテーブル定義に基づいてすべての到着レコードを検証します。レコードが適合しない場合、Zerobusはエラーを投げ、下流のデータ破壊を防ぎます。

• 使うタイミング: ミッションクリティカルなテレメトリ、金融トランザクション、プロダクションログ。
• NOT NULLのパワー: 厳密な契約を強制するために**必須列(NOT NULL)**を使いましょう。デバイスがdevice_idやtimestampの送信に失敗した場合、レコードは正面玄関で拒絶されます。
• メリット: あなたのデータは「到着時に綺麗な状態」になります。NULLや不正な列を除外するための複雑なSparkジョブの追加は不要です。

オプションB: 柔軟なペイロード(VARIANTタイプ)

時にはソースをコントロールできなかったり、ソースが毎週変化するメタデータの「blob」を送信することがあります。このようなシナリオにおいては、VARIANTカラムタイプを使いましょう。

• 動作原理: 主キー(idやtimestampなど)と単一のVARIANTタイプのpayload列を固定で持つテーブルを定義します。そして、この列にJSONペイロード全体をダンプします。
• 落とし穴: スキーマは柔軟ですが、フォーマットはそうではありません。Zerobusは適切であることを確認するために、依然としてJSONを解析します。ペイロードが解析可能なJSONでない場合、Zerobusはクライアントにエラーを返します。
• メリット: Delta Lakeのパフォーマンスを備えたドキュメントストアの「スキーマオンリード」の柔軟性を手に入れることができます。

プロの技: 最も成功しているアーキテクチャでは、ハイブリッドアプローチを採用しています。厳密かつ必須の列として「コア」フィールド(ID、Timestamp、User、Action、Version)を定義し、その他のすべてのためのmetadata VARIANT列を使用します。これによって、両方の世界の最高のものを手にすることができます: 信頼性のあるパーティショニングやjoinキー、時間と共に進化するデータに対する柔軟性。

Zerobus Ingesrtの詳細については以下のリソースをご覧ください。前進して構築しましょう！

• すぐにZerobusを試す: ドキュメントとクイックスタートガイドにアクセス。
• 製品ツアーに参加: Zerobus Ingestとデータ取り込み方法を学ぶためのナビゲーション。
• エンドツーエンドアプリケーションの構築: Python SDK、REST API、Databricks Apps、Databricks Asset Bundlesを用いた、船舶追跡のリアルタイム公開シミュレーター。ブログ記事をご覧ください。
• デジタルツインソリューションの構築: Databricks AppsとLakebaseを用いた運用効率性の最大化、リアルタイム洞察、予兆保全の加速について学びましょう。ブログ記事をご覧ください。

はじめてのDatabricks

はじめてのDatabricks

Databricks無料トライアル

Databricks無料トライアル

Databricks生成AIクックブックのコンテンツです。