リアルタイム物流分析のためのストリーミング Iceberg テーブルの構築

セッションノート

現代の物流が抱える課題:

• トラック、ドライバー、ルート、燃料、メンテナンス、配送、倉庫に関する複数のストリームを管理する。
• リアルタイムの運用ビューと長期的な分析が必要。データストレージの要件:
• 即時の運用に利用できる、最新の結合済みビュー。
• 長期的な分析に Apache Iceberg を使用。テクノロジースタック:
• RisingWave: ストリーミング機能を提供するデータプラットフォーム。
• Lakekeeper: データ管理のためのオープンな REST カタログ。
• Kafka: ストリーミングデータのイベント基盤。
• オブジェクトストレージ（例: MinIO）: データのストレージソリューション。目的:
• 指定されたオープンスタックを使用してストリーミング Iceberg テーブルを構築する方法を実演する。
• 現代の物流データ管理に向けたシンプルで効果的なソリューションを提供する。物流分析の課題
• 今日の物流プラットフォームが生成するデータ:
• トラック: 車両在庫と位置
• ドライバー: 名簿と割り当て
• 配送: 出発地、目的地、重量
• 倉庫: 収容能力と拠点
• ルート: ETA と距離
• 燃料とメンテナンス: コストと信頼性のシグナル
• 課題:
• 運用チームには、これらすべてのストリームを横断する最新の結合済みビューが必要。
• データチームには、BI、AI、履歴分析のために同じデータを Iceberg 上で利用することが必要。構築するもの（ストリーミング Iceberg パターン）
• Kafka が 7 つの物流トピックを RisingWave に供給する。
• 多方向ストリーミング結合を SQL で記述し、RisingWave 内で継続的にマテリアライズする。
• その結果を RisingWave から MinIO のような S3 互換オブジェクトストアに、ネイティブの Apache Iceberg テーブルとして永続化する。
• Spark、Trino、DuckDB などのエンジンが、オープンな REST カタログ経由で同じ Iceberg テーブルをクエリする。RisingWave でストリーミング Iceberg テーブルを使用する理由
• [ 1 ] バッチ優先のワークフロー:
• 定期ジョブ、古い結合結果、負荷の高いパイプライン。
• Iceberg に書き込むための個別の ETL ツール。
• [ 2 ] RisingWave + ストリーミング Iceberg テーブル:
• RisingWave MV 内で継続的に更新される結合と集約。
• 常に「ほぼ最新」の Iceberg スナップショット。
• 1 つの RisingWave パイプラインで、リアルタイムダッシュボードとオフライン分析の両方に対応。
• 目標: ストリーミングパイプラインと Iceberg への書き込みを RisingWave に担わせ、Iceberg をデータベースのように扱えるようにする。

ハイレベルアーキテクチャ

• エンドツーエンドのスタック:
• Kafka — 7 つの物流トピックのイベント基盤。
• RisingWave（ストリーミングデータベース）— SQL で取り込み、結合、集約を行い、マテリアライズドビューを管理。
• RisingWave Iceberg Table Engine + Lakekeeper — Iceberg テーブル上のオープンな REST カタログ。
• MinIO — S3 互換オブジェクトストレージ。
• パターン: Kafka → RisingWave → MinIO 内の Iceberg → REST カタログ経由で任意のエンジンからクエリ。RisingWave 内の物流ストリームと多方向ストリーミング結合
• RisingWave の 7 つの物流ストリーム
• この例では、RisingWave のソースとなる 7 つの Kafka トピックを使用する:
• trucks — 車両在庫、積載能力、現在地。
• driver — ドライバーの詳細と assigned_truck_id。
• shipments — 出発地、目的地、重量、トラックとの紐付け。
• warehouses — 倉庫の場所と収容能力。
• route — route_id、truck_id、driver_id、ETD/ETA、distance_km。
• fuel — 給油イベント（時刻、リットル数、給油所）。
• maint — メンテナンス履歴とコスト。
• RisingWave はそれぞれをストリーミングテーブルとして扱い、シンプルな PostgreSQL スタイルの SQL で結合できる状態にする。パターン 1: RisingWave での多方向ストリーミング結合
• RisingWave では、中核となる物流ロジックを 1 つの多方向ストリーミング結合として記述する。
• 一致するトラックがないドライバーも表示されるよう、drivers → trucks を LEFT JOIN。
• ワークロードと目的地を付加するため shipments を JOIN。
• 収容能力と場所を取り込むため warehouses を JOIN。
• ETD/ETA と距離を取り込むため route を JOIN。
• コストと信頼性のシグナルを取り込むため fuel と maint を JOIN。
• これが logistics_joined_mv となる。これは RisingWave 内でトラック/ドライバー/ルートごとに継続的に更新される、非正規化された物流レコードである。

車両 KPI、ネイティブ Iceberg テーブル、クロスエンジン読み取り

パターン 2: RisingWave の車両 KPI ビュー

• 結合済み MV の上に、車両 KPI 用の別の RisingWave MV を定義する:
• トラックごとの積載能力使用率（%）。
• トラックごとの総燃料費とメンテナンス費。
• 合計運用コスト。
• 現在のルートコンテキスト（ID、ETD、ETA、distance_km）。
• 関連するドライバーの詳細。RisingWave の概要ビューは、Grafana と運用ダッシュボード向けのライブ車両パフォーマンステーブルになる。パターン 3: RisingWave からネイティブ Iceberg へのストリーミング
• カスタムライターサービスを使用する代わりに:
• [ 1 ] logistics_joined_iceberg を RisingWave が管理するネイティブ Iceberg テーブルとして定義する。
• [ 2 ] スキーマは logistics_joined_mv を反映する。
• [ 3 ] RisingWave の小規模な設定で、ストリーミングの変更を Iceberg スナップショットとしてコミットする頻度を制御する。パターン 4: REST カタログ経由のクロスエンジン読み取り
• RisingWave が作成し、Lakekeeper REST カタログに登録した Iceberg テーブルを使用すると:
• [ 1 ] Spark は lakekeeper をカタログとして接続
• [ 2 ] Trino / DuckDB / Dremio は、それぞれの Iceberg コネクターを使用して同じテーブルを読み取れる。
• [ 3 ] すべてのエンジンから、RisingWave が継続的に更新する同じ Iceberg データが見える。
• コピーも独自テーブル形式もなく、RisingWave が書き込む標準の Iceberg だけを使用する。

ローカルのノートパソコンから本番クラスターへ: デプロイオプション

• デプロイオプション: ノートパソコンからクラスターへ
• [ 1 ] ローカル（学習とプロトタイピング向け）:
• Docker で RisingWave、Kafka、MinIO、Lakekeeper を実行する。
• ノートパソコン上でストリーミング結合と Iceberg テーブルを試すのに最適。
• [ 2 ] 本番環境（実際のワークロード向け）:
• Kubernetes + Helm を使用して RisingWave と残りのスタックをデプロイする。
• 環境に適したストレージクラス、リソース制限、永続化を使用する。
• RisingWave で同じ SQL とパターンを使用しながら、耐久性、スケーラビリティ、自動化を向上できる。従来の Iceberg スタックの簡素化
• 従来の Iceberg デプロイでは、多くの場合、次のものが必要:
• 個別のストリーム処理エンジン。
• スタンドアロンの Iceberg ライタージョブ。
• 外部のコンパクションおよびメンテナンスワークフロー。
• カタログ、ライター、ストレージの整合性を保つための追加の連携処理。
• RisingWave を使用すると:
• [ 1 ] ストリーミングデータベースが、取り込み、結合、マテリアライズドビュー、Iceberg への書き込みを処理する。
• [ 2 ] REST カタログ + MinIO により、すべてを完全にオープンかつ相互運用可能な状態に保つ。
• 構成要素を減らし、運用オーバーヘッドを軽減。RisingWave を使用したリファレンスアーキテクチャ
• RisingWave を中心に、システムを 3 つのレイヤーとして捉える:
• [ 1 ] ストリーム → RisingWave テーブル。
• Kafka トピックが RisingWave のストリーミングテーブルになる。
• [ 2 ] テーブル → RisingWave マテリアライズドビュー。
• ストリーミング結合と集約がライブ MV（logistics_joined_mv、truck_fleet_overview）になる。
• [ 3 ] ビュー → ストリーミング Iceberg テーブル。
• RisingWave は、小規模な設定と INSERT....SELECT により MV をストリーミング Iceberg テーブルに変換する。
• RisingWave を「ストリーミング SQL + Iceberg エンジン」と捉えれば、このモデルを多くの分野で再利用できる。物流以外にも再利用できるパターン
• RisingWave + Iceberg パターンは次の分野に適用できる:
• E コマース: 注文、在庫、価格設定、顧客イベント。
• FinTech: トランザクション、残高、リスクシグナル。
• 産業用 IoT: 機械、センサー、アラート、メンテナンス。
• 通信: セッション、利用状況、QoS 指標。
• 複数のリアルタイムストリームがあり、オープンな長期ストレージが必要な場面なら、どこでも同じように RisingWave MV と Iceberg テーブルを使用できる。主なポイント（RisingWave + Iceberg）
• Kafka、RisingWave、REST カタログ、MinIO、Iceberg を組み合わせたリファレンスアーキテクチャ。
• 実践的なパターン: 多方向ストリーミング結合、KPI ビュー、RisingWave からのネイティブ Iceberg 書き込み。
• カスタムライター、アドホックなコンパクションジョブ、強固なベンダーロックインなしで、リアルタイム物流分析を実現する。