建置串流 Iceberg 資料表以進行即時物流分析

場次筆記

現代物流的挑戰：

• 管理卡車、駕駛、路線、燃料、維護、貨運與倉庫等多個資料串流。
• 需要即時營運檢視與長期分析。資料儲存需求：
• 提供最新且已聯結的檢視，以支援即時營運。
• 使用 Apache Iceberg 進行長期分析。技術堆疊：
• RisingWave：具備串流能力的資料平台。
• Lakekeeper：用於資料管理的開放式 REST catalog。
• Kafka：串流資料的事件骨幹。
• 物件儲存（例如 MinIO）：資料儲存解決方案。目標：
• 示範如何使用指定的開放式技術堆疊建置串流 Iceberg 資料表。
• 為現代物流資料管理提供簡單且有效的解決方案。物流分析問題
• 現今的物流平台會產生：
• 卡車：車隊清冊與位置
• 駕駛：名冊與工作指派
• 貨運：起點、目的地與重量
• 倉庫：容量與站點
• 路線：預計抵達時間（ETA）與距離
• 燃料與維護：成本與可靠性訊號
• 挑戰：
• 營運團隊需要涵蓋所有這些串流、最新且已聯結的檢視。
• 資料團隊需要將相同資料放入 Iceberg，以進行 BI、AI 與歷史分析。我們將建置的內容（串流 Iceberg 模式）
• Kafka 將七個物流主題送入 RisingWave。
• 使用 SQL 表達多路串流聯結，並在 RisingWave 內持續具體化。
• 結果會從 RisingWave 持久化為原生 Apache Iceberg 資料表，存放在 MinIO 等 S3 相容物件儲存中。
• Spark、Trino 與 DuckDB 等引擎透過開放式 REST catalog 查詢相同的 Iceberg 資料表。為何使用 RisingWave 建置串流 Iceberg 資料表？
• [ 1 ] 批次優先的工作流程：
• 週期性工作、過時的聯結結果，以及繁重的資料管線。
• 需要另外使用 ETL 工具寫入 Iceberg。
• [ 2 ] RisingWave + 串流 Iceberg 資料表：
• 在 RisingWave MV 中持續更新聯結與彙總。
• 始終「近乎即時」的 Iceberg snapshot。
• 一條 RisingWave 資料管線同時支援即時儀表板與離線分析。
• 目標：由 RisingWave 負責串流資料管線與 Iceberg 寫入，讓 Iceberg 的使用體驗如同資料庫。

高階架構

• 我們的端對端技術堆疊：
• Kafka — 7 個物流主題的事件骨幹。
• RisingWave（串流資料庫）— 使用 SQL 擷取、聯結與彙總資料；管理具體化檢視。
• RisingWave Iceberg Table Engine + Lakekeeper — Iceberg 資料表上的開放式 REST catalog。
• MinIO — S3 相容物件儲存。
• 模式：Kafka → RisingWave → MinIO 中的 Iceberg → 任何引擎皆可透過 REST catalog 查詢。RisingWave 中的物流串流與多路串流聯結
• RisingWave 中的七個物流串流
• 本範例使用七個 Kafka 主題，這些主題會成為 RisingWave 中的 source：
• 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 中，我們將核心物流邏輯表達為一個多路串流聯結。
• LEFT JOIN drivers → trucks，以保留未配對的駕駛資料。
• JOIN shipments，以附加工作負載與目的地。
• JOIN warehouses，以加入容量與位置資訊。
• JOIN route，以取得 ETD/ETA 與距離。
• JOIN fuel 與 maint，以取得成本與可靠性訊號。
• 這會成為 logistics_joined_mv — RisingWave 內針對每個卡車／駕駛／路線，持續更新且反正規化的物流紀錄。

車隊 KPI、原生 Iceberg 資料表與跨引擎讀取

模式 2：RisingWave 中的車隊 KPI 檢視

• 在已聯結的 MV 之上，我們另外定義一個用於車隊 KPI 的 RisingWave MV：
• 每輛卡車的容量使用率（%）。
• 每輛卡車的燃料總成本與維護成本。
• 合併後的總營運成本。
• 目前路線情境（ID、ETD、ETA、distance_km）。
• 相關駕駛詳細資料。RisingWave 中的 overview 會成為即時車隊效能資料表 — 供 Grafana 與營運儀表板使用。模式 3：從 RisingWave 串流至原生 Iceberg
• 不使用自訂 writer 服務，而是：
• [ 1 ] 將 logistics_joined_iceberg 定義為由 RisingWave 管理的原生 Iceberg 資料表。
• [ 2 ] 其 schema 對應 logistics_joined_mv。
• [ 3 ] RisingWave 中的一小段設定可控制串流變更提交為 Iceberg snapshot 的頻率。模式 4：透過 REST catalog 進行跨引擎讀取
• 使用由 RisingWave 建立並註冊至 Lakekeeper REST catalog 的 Iceberg 資料表：
• [ 1 ] Spark 將 lakekeeper 掛載為 catalog
• [ 2 ] Trino / DuckDB / Dremio 可使用各自的 Iceberg connector 讀取相同資料表。
• [ 3 ] 所有引擎都會看到 RisingWave 持續更新的相同 Iceberg 資料。
• 不需複製、不使用專有資料表格式 — 只有由 RisingWave 寫入的標準 Iceberg。

從本機筆電到正式環境叢集：部署選項

• 部署選項：從筆電到叢集
• [ 1 ] 本機（用於學習與原型製作）：
• 使用 Docker 執行 RisingWave、Kafka、MinIO 與 Lakekeeper。
• 非常適合在筆電上實驗串流聯結與 Iceberg 資料表。
• [ 2 ] 正式環境（用於實際工作負載）：
• 透過 Kubernetes + Helm 部署 RisingWave 與技術堆疊的其餘部分。
• 使用適合您環境的儲存類別、資源限制與持久化設定。
• 在 RisingWave 中使用相同的 SQL 與模式 — 只是更耐久、更具擴充性，也更加自動化。簡化傳統 Iceberg 技術堆疊
• 傳統 Iceberg 部署通常需要：
• 獨立的串流處理引擎。
• 獨立運作的 Iceberg writer 工作。
• 外部壓縮與維護工作流程。
• 額外的整合機制，以確保 catalog、writer 與儲存保持一致。
• 使用 RisingWave：
• [ 1 ] 串流資料庫會處理資料擷取、聯結、具體化檢視與 Iceberg 寫入。
• [ 2 ] REST catalog + MinIO 讓一切保持完全開放且可互通。
• 更少的活動元件、更低的營運負擔。使用 RisingWave 的參考架構
• 可以將系統視為以 RisingWave 為中心的三個層級：
• [ 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 模式適用於：
• 電子商務：訂單、庫存、定價、客戶事件。
• FinTech：交易、餘額、風險訊號。
• 工業 IoT：機器、感測器、警示、維護。
• 電信：工作階段、使用量、QoS 指標。
• 只要有多個即時串流，並且需要開放式長期儲存，就能以相同方式使用 RisingWave MV 與 Iceberg 資料表。重點摘要（RisingWave + Iceberg）
• 結合 Kafka、RisingWave、REST catalog、MinIO 與 Iceberg 的參考架構。
• 實用模式：多路串流聯結、KPI 檢視，以及從 RisingWave 原生寫入 Iceberg。
• 無需自訂 writer、臨時拼湊的壓縮工作或緊密的供應商綁定，即可取得即時物流分析。