30 天挑戰已經完成四分之三，是否感受到水越來越深了呢？在第三階段裡，我們更深入地討論了許多資料處理的技術。這些技術都是構建高效率且具備擴展性的衍生資料系統必須掌握的重要因子。
這些資訊已經漸漸走入資料工程的深水區，但我們換個角度，從用上每個技術的原因與時機來快速回顧一下「基礎建設篇」。

Key Takeaways | 基礎建設錦囊

Day 17 討論資料處理方式的抉擇點。當需求是快速回應和即時運用時，即時處理架構是理想選擇；而當資料量龐大且迭代頻率較低時，批量處理架構可能更合適。同時也帶出了 Lambda 和 Kappa 兩種常見的資料處理架構，說明這兩個架構如何整併 batch 與 streaming 資料。

Day 18 從即時性和可重現性切入，引入變更資料擷取 (CDC) 的概念，若能完整串接資料源變更日誌，則讓 OLAP 的建構不去影響 OLTP 的業務運作，且能完整保存任何異動歷程。

在 Day 19 我們引入了事件 (event) 的概念，應運而生的技術詞彙是訊息佇列 (message queue)、資料產製者 (producer) 和消費者 (consumer)。我們可以透過 Debezium 與 Kafka 的搭配，即時取走 CDC 資料建構一條即時處理管道 (real-time processing)，讓決策者能即時獲取重要資訊從而提升業務反應效率。

而在巨量資料的加值運算上，Day 20 以 Flink 為例，說明其分散式特性使其在處理即時資料流時，能在巨量資料湧入下仍具備一定的低延遲水準。同時透過視窗切割以及狀態保存點，確保計算結果的準確性以及故障復原的可靠性，是一個可行的分散式處理引擎解決方案。

Day 21 圍繞著衍生資料系統的核心：「為什麼要把資料從資料源串接出來？」，近一步地討論衍生資料帶來的迷思，包含無法即時的近即時 (near real-time) 特性，以及即時性帶來的成本挑戰。最後 Day 22 則是以公司各個與資料流相關的團隊面臨的跨部門溝通困境，引入了 Schema Registry 的應用場景，確保資料運補的順暢及資料完整性。

小反思｜對於即時性的追求

Q：什麼資料應該即時提供？

A：
最根本的問題應該是「即時看到資訊後，能有什麼樣的改變行為？」
以先前提到的網購服務而言，庫存顯示與消費者的訂購行為即刻相關，那麼庫存的資料流就應該以即時反應為目標。若資料運用方向是分辨客群差異化後投注對應行銷資源，因客群差異顯現需要一定時間 (天、週甚至是月)，那就應該安排對應的資料更新頻率。若為重要財務資料的核對，必須要相當精準，或許利用更長的更新頻率配合更嚴謹的回算機制來提供資料。

Catalogue | 給你的快速連結

[10/06]《資料與程式碼的交鋒》Day 22 - 資料格式管理
[10/05]《資料與程式碼的交鋒》Day 21 - 即時性的迷思
[10/04]《資料與程式碼的交鋒》Day 20 - 分散式處理引擎 Flink
[10/03]《資料與程式碼的交鋒》Day 19 - 資料異動即時串接
[10/02]《資料與程式碼的交鋒》Day 18 - 變更資料擷取 (CDC)
[10/01]《資料與程式碼的交鋒》Day 17 - 資料處理架構的抉擇