數據平台演進: 從數據倉儲到數據經緯

探討數據架構從集中式到分散式的演進過程，剖析數據倉儲、湖泊、網格和經緯的特點，以及如何在複雜的數據生態中找到平衡點，釋放數據潛力。

Sep 30, 2024

微服務將領域(domain)從單體中解放出來，但商業洞見需要整合的全局視野。
在邏輯的維運層面，我們有 Kubernetes (K8S) 這樣的控制平面來指揮協同。
那數據的維運層面呢 ?
”複雜的流動性” 和 ”難以界定的權責歸屬”，是數據工程之所以隱晦不明的原因。
— Browny

本期電子報，你也可以用聽的 😎 (如果開車或是搭捷運想練習聽力的話，sponsored by NotebookLM DeepDive podcast)

1×

0:00

-7:36

❏ 引言

(本文提及大量 Data 相關用語，”資料” 與 “數據” 可能交互使用，視其語境而定)

上週看到一篇標題為 “在2024年避免建立數據平台” 的文章 [1]，瞬間點燃了我的興趣。心裡面一直以來的吶喊 “No more data platform (不要再數據平台了)” 彷彿被這篇文章凝結墜落下來，振聾發聵。

過去接過太多號稱是 “數據平台” 的案子 (有時候會叫數據中台，以下統稱數據平台)，在生成式 AI 這個關鍵字尚未崛起的時候，大數據、數據平台 無疑是當時架構舞台上的主角。但，我真的曾經理解過數據平台的涵義嗎？

將數據備份上雲，算是數據平台嗎？
將數據做 ETL (Extract-Transform-Load) 然後畫個報表，算是數據平台嗎？
把數據全部集中到數據倉儲 (那些年，我們追的 BigQuery)，算數據平台嗎？

都不是！那數據平台到底是什麼？企業都在關注 AI 模型導入的現在，需要有數據平台嗎？這期和大家分享我深入挖掘這位作者的觀點並結合自己過往經驗後得出的「數據平台」。

📍 大綱

❏ 數據複雜性的根源
❏ 數據工程的迷思與真相
❏ 數據架構的演進與整合
❏ 數據驅動未來的思維轉變

《非正式寫作》著墨琢磨 技術趨勢、溝通領導、概念理解 與 生活實踐。
每週一四派送，免費訂閱起來👇

🔍 工人智慧猜你也喜歡

❏ 數據複雜性的根源

總結作者所提及 [5]，數據工程之所以變得如此複雜的原因有二：

服務解耦之後擁有各自的數據掌控權 (可想像為分地封侯)
在商業智能 (Business Intelligence) 和AI 的推波助瀾下，對 數據分析管理的需求急遽增長 (可想像為對地方活動的監控)

服務解耦源於對敏捷開發的回應，讓職責邊界更加清晰、迭代更加快速，不同服務得以選用最適合自己的技術棧，尤其是資料儲存。

交易型業務邏輯適合用關聯式資料庫；關係型業務邏輯適合用 NoSQL。資料 schema 的設計本質上反映了軟體對業務的抽象理解：資料捕捉了業務邏輯的狀態，程式構建了狀態轉換間的各種路徑，兩者其實是密不可分的。

直到有一天，我們把資料分成了 ”業務型” 和 “分析型”，業務型資料專注於滿足程式邏輯的運行，分析型資料專注在拉出報表，讓每週對高層的匯報充滿洞見。難道，我們不會拿交易資料來進行分析嗎？難道，這些分析結果不會反饋回去指導業務邏輯的選擇嗎？如果會，它不算業務型資料嗎？這種區分法充滿了餘冗和諸多隱晦不明處。

隱晦便是商機藏匿之處，”平台” 成了聰明廠商對這層隱晦華麗的包裝：

你不能再用關聯式資料庫做分析報表了，那會拖慢你的主要生意！
你需要可以容納更多的儲存，洞見來自足夠多的數據，你需要一個數據平台！
你需要一個海納百川的數據倉儲，一個更適合跨表 JOIN 的分析型資料庫！

「打破數據孤島、實現數據現代化，等等…」，雲服務和資料庫廠商異口同聲地鼓吹著。

在各行各業開始被趨勢推著導入數據平台後，我們發現：要想將企業內部的資料全集中呼吸到這個所謂的數據平台，是一個過於理想化的夢幻泡泡。我們被平台這個字眼矇蔽，在其上堆疊了過多的職責。

❏ 數據工程的迷思與真相

我提倡將數據工程重新定義為「關於數據的移動、操作和管理」。
這個定義來自 Lewis Gavin 的書《什麼是數據工程?》(O'Reilly, 2019)。
然而，與目前的做法有明顯不同的是，我們應該將操作限制在「純粹的技術範疇內」。

數據工程不應實施業務邏輯！- [5]

由於廠商的包裝，數據平台功能列表不斷擴展，導致 數據工程師 (Data Engineer) 常常在數據的移動、操作和管理過程中實現了業務邏輯。例如：

ETL 管道 (pipeline) 連接業務和分析系統，數據工程師的任務是建立和維護 ETL 管道，從業務系統提取數據，根據業務規則進行轉換，並將其載入數據倉儲 (Data Warehouse) 或數據湖 (Data lake) 以進行分析。
這通常涉及在轉換步驟中實施複雜的業務邏輯，例如資料清理、彙總和增強。例如：數據工程師可能需要編寫程式碼來根據交易的歷史紀錄來計算客戶的終身價值，這是一個業務邏輯問題，理想情況下應該由負責管理客戶資料的應用程式處理。[1]

在數據網格的背景下 (下面會再詳細介紹)，數據工程師被鼓勵將數據視為產品，並構建滿足特定數據消費者需求的數據產品。這個概念很容易誘導將數據及其產生邏輯被打包成一個獨立單元，導致數據工程師去實現業務邏輯。

例如：數據工程師可能會創建一個數據產品，該產品提供預先計算的客戶流失率，將流失預測邏輯嵌入到數據產品中，而不是留給負責客戶關係管理的應用程序。

這就是為什麼數據工程師搞到後來其實承攬了軟體工程師 (Software Engineer) 的部分工作。這就是開頭我所說的 ”難以界定的權責歸屬”。

作者認為：數據工程師可以進行的 "技術處理" 包括: 分區、分類、格式重整、標準化、索引、技術上的彙總等…，但一旦需要進行實際的業務邏輯處理，就應該交由負責相應資料集的業務領域應用程式開發人員處理。

應用程式也走過相似的路，因為容器技術和敏捷開發讓微服務架構興起，職責拆分後的眾多服務在溝通和管理上的需求加劇，於是誕生了容器託管平台 K8S。

那，數據呢？接著，我們來看看，數據倉儲(Data warehouse) → 數據湖(Data lake) → 數據網格(Data mesh) → 數據織物(Data Fabric) 一路的架構演進，反應了怎樣的商業現實和實務考量。

❏ 數據架構的演進與整合

貿易的核心不在於商品本身，而在於資訊的流動。商品只會靜靜地躺在倉庫裡，直到資訊驅使它們開始流通。 — C. J. Cherryh

✔ 數據倉儲(Data warehouse): 集中式數據管理的開端

數據倉儲，集中化管理分析數據，打破因業務解耦或服務解耦而產生的數據孤島 (Data silo)，鼓吹先將資料集中起來，才能進一步從中產生商業洞察。

起源於1980年代，旨在存儲和分析結構化數據。
專為以結構化格式存儲來自不同來源的歷史數據而設計。
優化了複雜查詢和分析流程。
通常搭配 ETL，在資料寫入前進行轉換成後續利於分析的格式。

✔ `數據湖(`Data lake): `應對數據多樣性的解決方案`

剛接觸這個名詞的時候，其實我是蠻問號的，覺得不就是 Storage + Data warehouse 嗎？以我比較熟悉的 Google Cloud 來說，就是把 GCS 和 BigQuery 打包起來，在結構化和非結構化的數據管理上做到多租戶 (Multitenancy) 和治理 (Governance)。

後來理解到，有賴資料餵養的技術相繼崛起 (像是 Deep learning, Gen AI)，越來越多用作模型訓練的資料並不是結構化的。企業當中非結構化資料 (像是影像、聲音…等) 的佔比，其實是遠大於結構化資料的。而數據倉儲的 ETL 操作會失去原始資料格式，使得其他應用難以實現。

數據湖從 ETL 轉往 ELT (Extract-Load-Transform)：先把原始資料都倒進儲存 (保留了原始資料格式)，再依照不同應用的需求對原始資料作轉換處理。

在2010年代初期開始流行。
設計用於存儲大量原始、非結構化和半結構化數據。
特點是接受所有數據類型，以原始格式存儲數據，並採用 ELT 策略。
提供更靈活的數據存儲和分析方式。
支持多種分析類型，包括機器學習和大數據處理。

✔ 數據網格(Data mesh): 走向分散式數據架構

回想當時數據倉儲、數據湖的概念出現以後，冒出許多以此為名的專案，不過真正可以在組織中具體落實的屈指可數。而且，實務推行上需要和各個不同事業單位進行的權責與安全性溝通，相當曠日廢時。若沒有組織高層由上而下的強力推動，”集中化數據管理” 是個遠比字面上困難的目標！

數據網格可以理解成數據的微服務化，其精神是分散式的 ownership (自己的資料自己管)，並且將數據視為產品，對其他單位提出的數據需求，透過嚴謹的 API 方式提供存取 (而不是直接開資料庫的查詢權限給對方)。

由Zhamak Dehghani 於 2019 年提出
Data Mesh 源於解決傳統中央化數據平台面臨的可擴展性和靈活性問題。
它強調 將數據管理責任分散到各個業務領域，將數據視為產品，並由領域專家負責管理。
Data Mesh 的好處包括提高數據可訪問性、改善分析能力、減少瓶頸，以及增強安全性和合規性。
它通過分散式所有權和自助式數據平台，使組織能更靈活高效地利用數據。

✔ 數據經緯(Data fabric): 無縫集成的新時代

Data mesh 側重組織框架，並沒有太深入討論技術上可能遭逢的挑戰，像是：

怎麼框定數據的領域？完全跟隨應用本身的粒度？如果數據被多個微服務使用那這個數據產品的 ownership 算誰的?
不同數據產品間的數據交換，API 是否應該遵循一致的規範？
如何作數據發現 (相對於服務發現)，讓組織透明了解各方有哪些數據可以取用，加速數據協同？

Data fabric 嘗試針對這些議題，提供一個統一的管理框架，以 K8S 來類比有點類似控制平面 (Control plane) 的角色：

Data fabric 架構源於解決現代企業面臨的數據分散、異質和難以整合的挑戰。
旨在跨多元數據源和位置創建統一的數據環境。
特點包括整合數據訪問、數據集成與編排、可擴展性和強大的治理機制。
利用元數據、AI和機器學習自動化數據集成和管理任務。
提供單一虛擬層來管理跨混合和多雲環境的所有數據資產。強調即時數據洞察和靈活的數據訪問。

總結一下數據管理架構的演進：

數據倉儲 滿足了集中式、結構化數據分析的需求。
數據湖 應對了不斷增長的數據量和多樣性。
數據網格 引入分散式方法，解決了可擴展性和特定領域的需求。
數據經緯 提供了全面而靈活的框架，實現了跨多元環境的無縫數據集成和訪問。

❏ 數據驅動未來的思維轉變

回到作者 “在2024年避免建立數據平台” 一文之後，興趣使然的我繼續被引領至 “數據網格的挑戰與解決方案” 三部曲 [2], [3], [4]。

其中的幾點洞察，對於理解從數據倉儲 → 數據經緯的演進過程，以及如何不被這些名詞所侷限，從這些架構想要解決的問題之中，提取出適合自己的方案，很具指導意義：

✔ 消除營運與分析資料的人為界限

將營運資料和分析資料硬性區分的做法，阻礙了資料的自由流動。作者建議將資料分為"原始資料" (新生成的) 和"衍生資料" (由現有資料轉化而來)，而非按用途分類。這種方法更注重資料的來源和演變過程，也消弭了分析數據就得透過數據倉儲的思維限制。

✔ 重新檢視 "資料即產品" 的概念

資料即產品的概念，容易讓數據與業務邏輯的耦合性更進一步增加，數據產品被賦予過多責任，導致數據工程師搞到後來其實承攬了軟體工程師的工作。

我們應該將數據與邏輯分開，關於邏輯的部分，不管是程式或是其對應的數據，由軟體工程師負責；關於衍生數據，以及不是直接與邏輯相關連的數據，由數據工程師負責。

如此一來，數據工程師才可以從 ETL or ELT 的泥淖中抽身出來，將注意力專注在打造數據平台控制平面。

✔ 促進互操作性和有效治理

以容器維運平台 K8S 來對照數據平台，我覺得更清晰地揭露了這些數據架構演進的背後意涵，也激發更進一步的思考：

數據網格 → 服務網格 (service mesh)：服務網格將服務之間的溝通工作由統一的 side car proxy 統一代理。數據網格雖然鼓吹要將數據視為產品，透過 API 互相溝通，但是並還沒有像服務網格一樣，有 istio 這樣的框架工具出現。
數據經緯 → 控制平面：K8S 的控制平面，掌管了叢集內應用程式 (Pod) 運行的狀況，軟體維運藉由遵循 K8S Object 的 YAML 規範，將應用的生命週期，交給 K8S 這個平台做一致的管理。那，數據維運呢？不同數據產品的 API，不同數據產品內的數據生命週期，我們有類似 K8S 的平台等級框架，來做到規範治理和自動化嗎？這就是數據經緯努力的目標。

❏ 結語

數據不再只是需要儲存的靜態資產，而是需要精心設計架構和治理的動態資源

在數據工程這個不斷演進的領域中，我們可以清楚地看到，從數據倉儲到數據經緯的演進過程，反映了現代企業所面臨的複雜挑戰。這種演變突顯了一個重要的思維轉變：數據不再只是需要儲存的靜態資產，而是需要精心設計架構和治理的動態資源。

數據範式沒有放諸四海皆準的解決方案。反之，組織必須根據自身獨特的需求和挑戰進行評估，從數據網格和數據經緯等概念中關注本質，而不被流行術語或供應商的承諾所束縛。

中心化與去中心化、操作數據與分析數據、技術實現與業務邏輯之間找到平衡點。未來的數據管理需要一種更加細膩的方法，強調系統間的互動、明確的數據所有權和靈活的治理機制。

最重要的問題不是「我們應該建立哪種數據平台？」，而是「我們如何創建一個數據生態系統，使我們的組織能夠做出更明智的決策並推動創新？」如此聚焦，我們才能駕馭數據管理的複雜性，釋放數據的真正潛力。

🦥 parting thoughts 🦥

Google Cloud OnBoard：Google Kubernetes Engine 入門

這期比較多技術架構的東西，如果你對 K8S 容器維運平台有興趣的話，我之前幫 Google 錄製的 Cloud OnBoard 課程也將於 2024/10/16 13:00 線上播出。對容器編排感興趣的同學歡迎 報名參加。

🔖 參考資料

[1] Avoid Building a Data Platform in 2024 - https://towardsdatascience.com/avoid-building-a-data-platform-in-2024-56f0ee95da42

[2] Challenges and Solutions in Data Mesh – Part 1 - https://towardsdatascience.com/challenges-and-solutions-in-data-mesh-part-1-24cd45290805

[3] Challenges and Solutions in Data Mesh — Part 2 - https://towardsdatascience.com/challenges-and-solutions-in-data-mesh-part-2-7dfe97aa461a

[4] Challenges and Solutions in Data Mesh — Part 3 - https://towardsdatascience.com/challenges-and-solutions-in-data-mesh-part-3-dacb917f3c91

[5] Data Engineering, Redefined - https://towardsdatascience.com/data-engineering-redefined-643249cbbadd

《非正式寫作》