極点マクロ｜Amarathon 2025 振り返り 33：リアルタイム物流分析のためのストリーミング 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 書き込み。

● カスタムライター、アドホックなコンパクションジョブ、強固なベンダーロックインなしで、リアルタイム物流分析を実現する。