淺談分散式數據網格(Data Mesh）
微服務和大數據共同的未來數據管理架構
這些年談及數位轉型（Digital Transformation）不外乎兩條路線，一條是以應用服務為主的「微服務架構（Microservices Architecture）」，另一條就是以挖掘資料價值為主的「大數據（Big Data）」。不管是哪一條路線，最終要實現數位轉型，都必須面對跨系統、規模化數據整合的問題。為此，數據網格（Data Mesh）將會是未來數據大統一管理架構的重點方向。
雲原生（Cloud Native）的服務網格（Service Mesh）方興未艾，各界頭痛之際，對於開發者和資料管理人員來說，數據網格（Data Mesh）將是另一個迫切要實現的架構和概念。尤其對於在 IT 早已深根多年企業來說，有太多舊系統、舊資料需要與新服務進行整合，以提供更多的新的數位服務，其中的資料庫系統，往往就是一切的瓶頸，其過往老舊或是高耦合的架構，使得效能、擴展性都不能滿足如今數位轉型的需要。
本文將淺談什麼是 Data Mesh，探討未來數位時代中需要的資料管理架構。
Data Mesh 概念的出現
早在 2019 年左右，ThoughWorks 和知名軟體架構師 Martin Fowler 網站上，就已經有相關的文章開始出現 Data Mesh 的討論：「How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh」。討論著如何從一個耦合度極高的中心化資料湖，轉移到分散式的 Data Mesh。
由於傳統中心化驅動的資料管理架構，無論是資料庫系統、資料倉儲、資料湖，將所有數據揉合在一處，這使得所有的實際應用在使用資料時，必須依賴著特定單一資料庫的表現。雖然當需求單純或數量不多時，不會有太大問題，但是當外部需求量變大、有各種不同條件的存取需求時，傳統的集中式資料管理系統，便開始出現各種效能、擴展性和管理面問題。
與微服務架構一樣，為了讓各類應用需求從不同角度、面向來高效率使用數據以滿足業務目的，勢必要採分散式系統的設計，去存取數據和資料。而 Data Mesh，就是在實現圍繞應用設計數據需求的前提之下，需要被落實的分散式數據管理方法。
在國內，類似的資料管理架構更常出現「數據中台（Data Middle Platform）」一詞，但根本的原理和概念相差不遠。因為若將 Data 之間的管線管理，以中介層（Middleware）來看待，也是一種詮釋的角度。若有興趣暸解更多，引伸閱讀舊文：「淺談微服務架構的資料快取和發佈策略」。
現今資料庫系統和數據平台所遭遇的實際問題
數位轉型下，無論是不是做微服務架構，隨著各類數位服務、數位資料、線上應用和 IT 系統的蓬勃發展，最終都因為巨量大大小小的業務需求，遭遇到了許多系統整合問題，例如：資料的交換、應用與數據的連結、跨系統的資料查詢需求。
對於應用開發者來說，需要滿足大量業務需求的應用服務，除了要解決自身的資料庫效能問題，也須需要查詢並提取資料倉儲的數據，甚至是整合其他服務的資料。有主動查詢需求、有被動被推送的需求、有即時的需求，形形色色的資料的存取動作，讓整個系統效能出現了嚴重的狀況。
而對於數據平台的管理者來說，各種大量應用場景的出現，不單是總資料量快速增長，也為數據平台帶來了許多威脅。除之前提及的效能問題外，如何快速依照需求設計出各式供應資料的介面讓應用服務使用，高速擴展資料的供應平面，更是一大痛點。
例如：傳統的集中式 ETL 工具，或許能依照不同需求去客製化提供資料給應用服務，但資料供應效率、擴展性、部署敏捷性，仍然不易滿足應用的需要。此外，不只是系統、技術集中化本身會帶來問題，開發管理的場景下，原本負責管理數據的人員，在面對終端應用服務多變的需求，也會手忙腳亂，資料供應的建置週期也會拖慢開發效率。
試想，當我們有成千上萬個微服務、應用系統，對應著成千上萬的資料供應管線，要有多少數據平台的管理人員才能建立並維運這些管線？又要多少人投入才能滿足應用開發人員每天都在更新的資料需求？最重要的是，這一切前提是要保證資料庫系統維持一定的效能表現。
Data Infra as a Platform 的概念
在前面提及的文章中，給出了一個大概的示意圖，描述了當有許多不同的應用需求需要存取資料、交換資料及分享資料時，我們該建置一個 Data Infra as a Platform 的設計，讓各個 Domain 的應用可以輕易自助搭建資料管線架構，針對資料類別、需求進行設計和控制，實現資料發佈和讓各式應用服務能取得自己所需的資料。
在這樣的架構下，資料不再只限於儲存在特定單一的資料庫系統中，而是依照資料歸屬權，以資料產品（Data Product）的形式分散在各個系統身上，由各系統去分散管理。因為資料分散在各處，所以也必須微服務架構一樣，同樣實現資料發現（Discovery）等機制。
在該文章中，也給出了幾條新的資料治理準則供參考：
- 資料服務供應重於攝取
- 資料的發現和使用重於提取和載入
- 發佈事件流重於中心化資料管線的資料流
- 資料集生態重於中心化數據平台
簡單來說，就是依照應用需求，由數據源出發來主動供應所需要的資料，而不是被動讓應用服務去爬取資料。讓應用服務能專心在使用數據和資料，並且利用分散式的資料流管線，讓資料更貼近應用。
未來可預見的多層、多向資料發佈管線
一旦實現 Data Mesh，從應用端出發的資料和數據需求，皆可以用分散式的資料管線進行管理，甚至隨著應用的發展和成長，逐漸變成多層架構，資料擁有權開始變得清晰，符合微服務的需要，更能配合領域驅動設計所帶來的架構規劃。
落實 Data Mesh 的關鍵技術：Kubernetes
可以說，雲原生（Cloud Native）並不是隨便一個平台就能扛得起的招牌，Kubernetes 之所以被視為未來數位轉型的關鍵雲端平台技術，除了容器技術之外，更重要的是將「雲端資源管理概念」納入平台之內，讓相關生態得以在這平台上蓬勃發展。
尤其是藉由其中 CRD（Custom Resource Definition）的機制，我們可以將大量分散式架構所需要的資源彙整進入 Kubernetes，並利用 Kubernetes 完整的管理機制，實現分散式部署、各類分散式資源的管理平面（Control Plane），簡化了過去設計叢集系統、分散式系統的大量工作。
從這個角度來看，利用 Kubernetes 管理分散式的資料管線，就是一個絕佳的解決方案。
在沒有 Kuberentes 這樣的資源管理平台之前，分散式的 Data Mesh 很難被落實，光是部署無數的資料管線，就是一大麻煩。若採用中心化的傳統管理方案來實現 Data Mesh，又會失去了分散架構的優點和好處，更可能成為整體系統的最大瓶頸。中心化的架構，未來甚至很難跨雲、實現混合雲架構，例如過去的 ESB、EAI 系統，就是典型的例子。
Data Mesh 能解決什麼樣的具體問題？
Data Mesh 最終當然能在維持一定效能表現的前提下，解決全面性的資料供應需求，除了滿足微服務需要，也能滿足大數據領域的需要。但這對很多企業來說，仍然看不見一個近期的具體效益。難道 Data Mesh 只能是一個需要硬著頭皮做的長期投資嗎？
其實 Data Mesh 的資料管理和設計概念，可以從一些新舊系統整合的地方尋找導入的空間，並具體解決一些場景下的問題，例如許多企業內的 IT 系統常出現這樣的場景：
某新、舊系統資料介接時，一方先定期產生資料以資料檔，另一放定期主動來爬資料檔。而因為是週期性批次處理，在極端的情況下，系統資料管線有可能花近兩倍週期時間的長度，來完成一次資料轉手。除了資料傳遞不夠即時，更要實現一個足夠穩定的批次處理機制或爬蟲。更大的問題是，這樣的特定時間點的大量批次處理，可能造成兩個系統的效能衝擊。
運用 Data Mesh 去快速搭建資料管線，讓分散在系統兩端的資料管線，從資料源主動流向目標，而無需進行額外程式開發。使原本需要週期性批次處理的工作，變成碎片化降低處理量的峰值，並實現即時資料傳遞和後續處理，讓終端應用服務表現更為快速。
此外，當有第二個系統需要同樣的資料時，甚至無須再從原始的資料源取得過於原始的資料（Raw Data），也不用實現第二次的週期性輪詢機制，減少更多系統的負擔。
對 Data Mesh 有更多興趣嗎？本文相關資料和素材，出自 Brobridge Gravity 數據中台解決方案，此產品用於解決企業跨系統資料交換、微服務架構資料供應和 AIoT 數據平台，協助 IT 人員、開發者實現最佳化的資料交換架構，滿足各類數位轉型的需求。如果您也有相關問題或需求，可以與我們寬橋（Brobridge）聯絡。
