每個方案，都從一個卡住的地方開始。

批次檔交換讓每個系統看到的資料都慢了一步，點對點介面則越接越亂。以 Kafka 作為企業事件中樞，來源系統只要發布一次事件，風控、行銷、App 與報表各自訂閱，新服務上線也不必再請來源系統開新介面。

• 架構規劃：主題與分區設計、資料保留政策、Schema Registry 與相容性規則
• 高可用與災備：同機房多副本、跨機房 Cluster Linking 或 MirrorMaker 2 的主備設計
• 安全與合規：TLS 加密、SASL 認證、ACL 與 RBAC、稽核日誌
• 可觀測性：consumer lag、吞吐量與延遲的監控告警，以及容量規劃

核心系統最怕的是查詢量。透過讀取資料庫交易日誌的 CDC，把異動即時同步到查詢庫、資料湖或 Kafka，核心系統不必改程式，查詢與新應用都轉到副本上，讀寫自然分離。

雙向同步、異質資料庫型別對應與衝突處理，我們會在導入前先做可行性驗證，避免上線後才發現限制。

當業務需要的是「交易當下」的判斷，例如可疑交易、額度控管或即時推播，就需要在串流上直接運算。我們以 Flink 開發過濾、聚合、視窗統計與規則比對，輸出結構化事件回到 Kafka，交給下游系統或模型做最後決策。

• 事件過濾與擴充：只留下需要的欄位，補上客戶或商店維度資料
• 視窗聚合：每分鐘、每小時的滑動統計，作為風控與營運指標
• 敏感資料處理：在記憶體中偵測個資欄位位置，只輸出位置不保留內容
• 狀態與容錯：checkpoint 與 exactly-once 設計，確保重啟後不重複不遺漏

資料倉儲貴且封閉，傳統 Hadoop 維運又重。以開放的 Iceberg 表格式存放資料、以 Trino 查詢，資料留在企業自己的物件儲存或 HDFS，運算可以獨立擴充。亦思的 Hare Data Platform 把這套組合包裝成可交付、可維運的產品。

• 聯邦查詢：Iceberg 表、關聯式資料庫、Kafka 主題可在同一段 SQL 中 JOIN
• 資料治理：schema 演進、時間回溯、細緻的存取權限
• 工作負載管理：以資源群組分配 ETL、BI、即席查詢與服務 API 的運算資源
• 產業模組：例如醫療場域，可將臨床資料欄位對應到 Iceberg schema，作為 FHIR 之後的分析層

看 Hare Data Platform 介紹

工廠、車隊與場域設備大量使用 MQTT。以 HiveMQ 作為企業級 MQTT broker，承接大量長連線裝置，並透過 Kafka 擴充把訊息直接寫入 Kafka，MES、分析平台與告警系統就能與其他業務資料一起使用。

• 大量裝置連線、叢集化與高可用部署
• MQTT 主題與 Kafka 主題的對應設計
• 裝置認證、TLS 與權限控管
• 設備資料進入資料湖倉，與良率、品質資料一起分析

各團隊各自申請 API 金鑰、各自串不同模型，最後沒人知道誰用了多少、送出了什麼資料。以 LiteLLM 建立企業 AI 閘道，所有模型呼叫走同一個入口，雲端模型與地端模型使用相同介面。

• 統一介面：以 OpenAI 相容 API 存取多家雲端模型與地端模型
• 金鑰與額度：依部門、專案或個人發放虛擬金鑰，設定預算與速率上限
• 成本與用量：即時統計各單位的 token 用量與費用
• 可靠度與稽核：模型備援切換、請求紀錄與存取軌跡，符合內控要求