數據平台之資料管道的演化：從 ETL 到 MDS，如何應用於醫療數據？

最近為了準備醫院指標平台所需的資料倉儲，我盤點目前醫院內各式各樣報表的產生方式，發現與我十幾年前使用的資料處理流程架構相同，仍以 ETL 處理為主。

過去，數位化資料量不大，主要依賴 ETL 方式處理的資料管道仍能靠人力來完成。但隨著數據量的迅速增長，物物數位化之後，報表需求如雪片般飛來。

接到打造資料倉儲的任務後，一個問題一直在我心中盤旋：「如何建立一個能夠適應未來變化的資料架構，能夠高效、可靠且可重複地為企業提供數據，並且同時符合當前的需求，進而發揮效益？如果能回推出適用場景的效益，才有機會爭取資源。」

為了回答自己心中的疑問，在如何建造資料管道前，需了解當前建立資料管道的方式有哪些種類，以及特性，與適應場景。經過盤點後，我才發現現代資料管道已經發生了很大的變化，而 ETL 只是早期資料管道的一種方式。

什麼是資料管道?

資料管道就是「將數據從一個系統移動到另一個系統的自動化流程，並在此過程中轉換數據，將準備好供業務使用，由業務單位來發揮數據的價值」。

資料管道就像一條長長的石油油管，將原油從內陸的油田輸送到海邊的港口。這個過程中，資料就像原油一樣，從企業內部各個系統中提取（如油田中的原油），經過資料管道的傳輸過程（即油管），在傳輸過程中，需要確保數據(油品)的品質，傳輸過程中要如何清理與保存，最後到達數據中台或資料倉庫（就像原油到達港口）。

在這個過程中，資料管道需要具備足夠的容量和效率，確保資料能夠源源不斷、平穩流動，就像油管需要能夠處理大量原油的輸送一樣。

資料管道的演化?

由上面原油的例子可以看出，資料管道需要４個步驟有，擷取(Extration)，載入(Load)，清理(Clean and Normalize)與轉換(Transformation)，很多人會將清理與轉換結合在同一個步驟中，統稱為轉換(Transformation)。

這四大步驟，缺一不可，會根據不同的現況與情境，調整四大步驟執行的順序，因此產生不同的資料管道，資料管道架構可以分為兩大種類， ETL與 MDS。

ETL

ETL是擷取(Extration)，轉換(Transformation)與載入(Load)三個步驟的組合，早在 1970 年代，ETL 已經在數據整合和資料倉儲領域中被廣泛應用。比爾·英蒙（Bill Inmon）和拉爾夫·金巴爾（Ralph Kimball）等資料倉儲先驅者推廣了 ETL，使其成為資料倉儲和數據處理的重要工具。

ETL 透過從來源系統中擷取資料，對其進行轉換，然後將結果載入資料倉儲，以便進行後續分析。這種由上而下的設計方式，尤其在硬體儲存成本較高的過去，是當時主流的方法。

從商業需求出發，逐步回推所需的資料，但其最大的缺點，相似的處理流程，會在不同任務中重複出現，程式碼很難管理與維護。例如，醫院每天大量病患就診，醫院需要定期生成報告來分析各科室的病患數量，就有一隻程式與排程獨立處理。下一個任務是糖尿病病患檢驗結果數據呈現，就需要另一隻程式與排程獨立處理。

ETL的優點：

1. 節省儲存空間：ETL 優勢在於，它可以在數據進入資料倉儲之前進行去重、過濾和精簡，確保只保存關鍵數據，減少儲存空間的浪費。在過去硬體儲存有限的情況下，這樣的設計受到青睞。
2. 需求產出快速：當有明確的專案需求時，ETL 允許快速依照需求進行數據擷取和處理。現有的 ETL 工具如 Informatica、Talend 等，能夠加速數據管道的開發，縮短需求到結果的時間，對於中小型數據集的運行較為順暢。
3. 高度耦合的數據：由於 ETL 是針對具體需求來設計和處理數據，因此產出的數據高度符合特定目的，這樣的耦合性確保資料集能夠精確地支持需求，不容易因修改一部分導致另一部分數據的崩潰，也就是不會改A壞B。

ETL的缺點：

1. 資料難以重複使用：高度耦合的數據設計往往意味著其針對特定需求優化，這導致在其他情境下難以重複使用。要實現數據的靈活應用，需要在耦合性和重複使用性之間取得平衡。
2. 難以管理與維護：由於追求快速實現需求，ETL 流程中的程式碼經常是臨時修補和複製貼上的結果。隨著時間推移，這會導致程式碼碎片化、重複性高，並且變得難以維護。這種技術債在大型數據項目中尤為明顯，當需求變更或系統擴展時，維護成本顯著上升。
3. 可擴展性低: 隨著數據量增加，ETL 的批次處理方式可能無法及時響應實時需求，尤其是在需要處理多個數據來源的大型數據環境下。
4. 數據治理與合規挑戰: ETL 沒有自帶的數據治理功能，這使得對敏感數據的處理、數據保留策略以及數據隱私的管理變得複雜，增加了遵循合規法規的難度。

隨著雲端運算和大數據技術的發展，ETL 的傳統方式面臨挑戰，ELT（提取、載入、轉換）逐漸成為替代方案。

MDS（Modern Data Stack）

隨著技術的進步與ETL 擴展性上的瓶頸，MDS（Modern Data Stack）概念應運而生。MDS 像堆積木一樣，將現代數據處理的技術堆疊，涵蓋數據的收集、儲存、轉換、分析與可視化等多個階段。MDS 具有高度的模組化和靈活性，企業可以根據需求選擇不同的工具和服務來構建專屬的數據管道架構。這種架構讓數據團隊能夠快速應對業務變化，並減少技術負擔。

我一直在想「為什麼需要MDS這個名詞產生，而不是單純描述從 ETL 到 ELT 而已?」 發現要從 ETL演化到 ELT的過程中，需要很多相對應的軟體或架構來輔助進行，才有可能實現 ELT的流程。最近使用 dbt 時候超有感，如果沒有 bdt 類似轉換的框架，單存用 python 來進行資料清理時，是很難實現出 ELT 的想法，下圖是Modern Data Stack 常見的組成與對應的軟體。

Modern Data Stack 的組成與對應的軟體[圖片來源: Qlik]

MDS 的優點：

1. 可擴展性（Scalability）: MDS 的其中一個主要優點是其高度的可擴展性。傳統的數據處理工具和架構往往難以應對數據量快速增長的需求，但 MDS 可以輕鬆擴展，無論是在處理更大規模的數據集還是應對更多的數據源。雖然目前醫療資料，受限法規以地端為主，當法規能允許上雲端時，MDS 架構可以快速遷移到雲端基礎設施（如 AWS、GCP、Azure）結合使用，使得 MDS 的擴展能力極為靈活。
2. 多樣化的數據來源整合: MDS 支持從多種數據來源擷取數據，這些來源可以包括結構化數據（例如 SQL 資料庫）、半結構化數據（例如 JSON、XML）和非結構化數據（例如文件、圖片、音頻等）。這讓企業能夠整合來自不同平台、應用和數據源的資訊，進一步提升數據分析的全面性。
3. 資料容易管理與維護：運用工具如 dbt（data building tool），能夠追蹤上下游的數據流程，並提供版本控制和可追溯性功能。這使得數據團隊能夠更靈活地管理數據表的變更，並降低維護成本。
4. 資料能重複使用： dbt 允許數據進行階段性拆解和處理，這大大提高了數據的重複使用率。例如，已經整理好的 APP 使用者資料可以用作多種分析需求，不必每次都從頭進行處理。

MDS 的缺點：

1. 資料儲存空間需求大，成本提高：由於所有數據都需要先載入資料倉儲，這會增加存儲需求，特別是在處理大規模未結構化數據時，存儲成本會顯著提高。
2. 初始開發時間較長：MDS 的建設需要先打好架構，這意味著在開始時可能會花費較長的時間進行數據的基礎設施建設。為了讓業務層更快體驗到數據的價值，數據團隊可以設計階段性的小型專案，以實現漸進式的價值交付。
3. 技術門檻較高：MDS 的導入需要具備深厚技術背景的數據架構師與工程師，並且要根據企業的具體需求進行定制化設計。工具如 dbt 雖然能提供優秀的數據管理功能，但仍需團隊成員具備相關技術經驗，才能充分發揮其價值。

MDS（Modern Data Stack）常見的四種類型架構：

在現代數據堆疊（MDS）中，常見的數據處理架構主要有三種類型：Batch ETL、CDC、Streaming 和 Streaming+CDC。這些架構根據不同的數據處理需求和應用場景進行選擇和部署，以下針對醫療場景為例，讓大家能夠更能具體了解這四種架構的不同。

1. Batch ETL：

Batch ETL 是一種批次數據處理架構。數據定期從來源系統提取出來，然後經過清洗與轉換，最後將處理後的數據載入到資料倉儲中。這個過程通常會結合 DBT（Data Build Tool）等工具來進行數據轉換，並將整理好的數據提供給後續的分析、報表生成或機器學習模型訓練。

• 醫療場景：在醫療系統中，Batch ETL 可以用於定期匯總醫院各科室的病患數據，如每日/每月匯總門診病人數、病房使用率、手術記錄等。這些數據在每日/每月結束後，會被批次載入資料倉儲中，然後進行清洗和轉換，以便生成報告或進行病患數量的趨勢分析。此外，這些數據還可以用來訓練醫療預測模型，從而幫助醫院進行未來的資源配置規劃。
• 優點：批次處理可以一次性處理大量數據，對於不需要即時結果的應用非常高效。
• 缺點：由於是定期處理，無法即時反映數據變化，例如無法在手術進行過程中即時更新相關數據。

2. CDC（數據變更捕捉）：

CDC（Change Data Capture）是一種即時數據變更捕捉架構。該技術能夠監控資料庫中的資料表變化，並自動捕捉新增、更新或刪除操作。CDC 會將這些變更記錄下來，並即時傳遞給下游系統或應用程式，從而實現數據的自動同步。CDC 通常與串流平台（如 Kafka）相結合，將捕捉到的變更轉換為即時訊息流，以便進行後續的處理或應用。

• 醫療場景：在醫療系統中，CDC 可以用於實時同步患者的病歷數據。當患者的病歷更新，例如新的檢驗結果、治療方案或生命體徵數據（如心率、血壓）進行變動時，CDC 會自動捕捉這些變化，並將其即時推送到電子病歷系統（EMR）或其他相關應用。這樣，醫護人員能夠在不需要手動查詢的情況下，立即查看最新的數據，從而做出快速、準確的診療決策。相比傳統的方式，系統需要不斷地透過 API 主動詢問數據是否有變化，CDC 省去了這個步驟，減少了系統負擔，同時提升了數據更新的效率和即時性。
• 優點：CDC 能夠實時捕捉資料庫中的變更，並自動將數據傳遞到下游系統，保證數據的一致性和即時性。這種架構非常適合需要快速同步數據的場景，尤其是在醫療系統中，能夠確保關鍵數據的即時更新。
• 缺點：CDC 架構的實施對基礎設施有較高要求，尤其在數據變更頻繁的情況下，會增加系統的處理負擔。此外，CDC 主要用於資料庫數據的同步，對於非資料庫數據（如 IoT 數據流）處理能力有限。

3. Streaming（流處理架構）：

Streaming 是一種實時處理數據的架構，適合應對高頻率、持續生成的數據流。它根據不同的需求，能夠將實時數據直接傳遞給相應的應用系統或數據分析平台。例如，當有 IoT 設備需要將感測數據傳遞給即時分析系統時，Kafka 會將這些數據以訊息的形式傳輸給消費者。這些數據可以用於即時決策（例如 AI 和機器學習的即時模型推論），或傳入資料湖或資料倉儲中，進行後續的視覺化分析和報告生成。

• 醫療場景：在急診室或重症監護室，IoT 設備會持續監測患者的生命體徵（如心率、血氧濃度、血壓等），這些設備會將實時數據通過 Kafka 等串流平台傳輸到醫療系統。假設某位患者的心率突然異常升高，Streaming 處理架構可以將這個數據即時推送給醫護人員的電腦或通訊軟體，幫助他們即時做出診療決策。與此同時，這些實時數據也可以直接傳輸到醫院的資料倉儲中，供後續的數據分析和報告生成。
• 優點：能夠即時處理數據，滿足高頻率數據應用需求。
• 缺點：實時處理系統複雜度較高，對於不需要即時結果的場景可能資源浪費較大。

4. Streaming + CDC（流處理 + 數據變更捕捉）：

Streaming + CDC 是結合了流式處理與數據庫同步的架構。除了處理 IoT 等設備產生的即時數據外，還能夠捕捉來自資料庫的變更事件，並將這些變更即時傳輸到下游系統中。透過 CDC（Change Data Capture）技術，資料庫中的新增、更新或刪除操作會即時被捕捉並轉換為訊息流，傳遞至 Kafka 進行後續處理。這種架構可以確保不同數據來源的即時同步和一致性。

• 醫療場景：Streaming + CDC 可以應用在醫院的電子病歷系統（EMR）中。當患者的病歷數據（例如實驗室檢驗結果或藥物處方）被更新時，CDC 技術會自動捕捉這些變更，並即時推送到其他相關系統，如醫護人員的監控系統或分析平台。當患者的檢驗結果有異常，醫護人員會立刻收到通知，而不需要通過輪詢系統或等待報告生成。這樣的架構保證了數據在不同系統之間的即時同步和高效傳遞。
• 優點：能夠即時同步來自資料庫和其他數據源的變化，適合需要保持數據一致性且需即時更新的應用。
• 缺點：系統設計與維護難度較高，對基礎架構的要求較高。

如何選擇最合適的資料管道架構?

根據當前需求與未來的擴展性選擇最合適的資料管道架構。隨著少子化問題加劇，未來人力資源將大幅減少，這使得資料架構必須能夠提高自動化和資料共享性。傳統的 ETL 流程已經無法滿足這種需求，因為它依賴批次處理，無法靈活應對即時數據的變動和報表的動態需求。

考慮了現有的技術選擇後，我問自己：「如何建立一個能夠適應未來變化的資料架構，能夠高效、可靠且可重複地為企業提供數據，並且同時符合當前的需求，進而發揮效益？」首先，資料需要具備可重複使用的特性，並且能夠在不同系統之間高效流轉。因此，考量現在的資料庫結構，我的首選技術是 dbt，因為它可以高效地管理數據轉換過程，並且提供強大的數據依賴追蹤功能，這對於高耦合的數據管道尤為重要。

接下來，需要決定使用 Batch ETL、Streaming、Streaming + CDC 還是 CDC? 為了不影響線上的資料庫效能，目前團隊使用 Airflow 將線上資料庫進行備份，但Airflow 是排程工具，在實際應用在資料管道中遇到了三個主要問題：

1. 當資料變動時，異動時間無法自動更新，這導致下游數據不同步。
2. 上游資料表的資料被刪除後，下游資料表無法即時感知這些變化，數據一致性受到影響。
3. 資料遺漏的情況時有發生，這讓我無法保證數據的完整性。

為了應對這些挑戰，我發現僅使用 Airflow 是不夠的，要確保數據的一致性和準確性，CDC（Change Data Capture）變成了必需品。通過 CDC，夠即時捕捉資料庫中的變更，確保數據在上下游之間的同步和一致。

將心中所想落成文字後，我更確認當前的策略是須將把 ETL 轉換成 MDS 架構，以 CDC 為核心，確保數據在資料庫變更時的即時同步，採用 dbt 來降低處理資料流的人力，並同時提高資料品質。且隨著需求的變化，醫療穿戴裝置使用越普及，並配合政策「在宅老化」的發展下，逐步引入 Streaming 處理技術，這樣的選擇不僅解決了當前數據流中的問題，還為未來擴展奠定了良好的基礎。

以下是我目前整理出來， MDS 不同資料框架下所用到的工具與適用的醫療場景。

資料管道的特性分析

希望這篇的內容，能對你有所幫助，看完後你覺得你的公司適合哪樣的資料管道?

歡迎跟我分享與一起學習討論。Email: suipichen@gmail.com

#數據中台
#資料管道