Day 20 我們說明了分散式運算引擎對即時進行資料應用的優勢之處。以 RFM 分析而言，我們把資料源的變化捕捉到 Kafka 之後，就可以接上 Flink 作為計算引擎，透過 stateful stream 的特性，資料不間斷地流入，分析結果也不間斷的更新，看起來實在太完美了！
不過，今天我們就透過幾個虛擬問答，來思考這些工具帶來的潛在迷思。

Q1：產品經理：『我們只是要運用資料，為什麼不直接從業務資料庫取資料使用就好？』

A：
這要看我們取用的方式會不會影響業務資料庫。業務資料庫為了即時事務處理需求，通常是 OLTP (參考 Day 03)。而 OLTP 目標是維護資料的最新狀態，對於歷史狀態的回溯和比對通常效能表現不會太好。

Q2：資料分析師：『可以理解為什麼要用 OLAP 來進行分析了。但為什麼小時計算的 data pipeline，在整點的時候沒辦法看到資料更新？

A：
這是 Batch Processing 的特性 (參考 Day 17)，例如，我們會在 7 點整時，針對 6 ~ 7 點之間來到資料系統的資料『開始』處理。以 RFM 分析為例，處理的時間包含上游 orders 和 users 的 ELT 耗時，以及相關資料都完備後的轉換與分析計算時間，也許是數秒到數分鐘不等。

Q3：產品經理：『好，那我們所謂的即時分析報表，為什麼仍然不是真的即時更新？』

A：
即便是從資料源透過 CDC 的方式，由 Debezium 和 Kafka Connect 送到 Kafka，再由 Flink 分散式處理運算寫入最終應用端，都還是需要數毫秒到秒不等的時間。所以我們在 Day 18 討論的衍生資料系統，就算用上即時資料處理的技術，由於資料的流轉還是需要時間，最快就是做到近即時 (near real-time)。

Q4：產品經理：『瞭解。請告訴我要實現近即時分析報表的成本。』

A：
基礎建設成本包含消化串流資料的能力如訊息佇列 Kafka，即時資料流運算引擎如 Flink，以及足夠的 CPU、記憶體與硬碟空間來支援整條即時資料運算、狀態 (states) 及資料儲存。
人力成本則是需要熟悉串流架構的工程師來設計、開發與測試系統。縱使順利上線了，相較於批量處理的資料可以在資料倉儲裡面透過 SQL 查詢掌握錯誤的資料轉換 (transform) 時間斷面，也可能透過回算機制自我修正；近即時分析的後續維運及錯誤偵查會比處理批量架構的資料流系統難度更高。
此外，資料源的開發工程師在規劃新功能時或資料遷移 (data migration)，需要考慮下游 (通常是 Data Team) 的消化能力以及變更捕捉能力，避免下游應用資料延遲或是計算錯誤。這正是資料上下游團隊的耦合性。