Data Mesh 與微服務架構的曖昧關係
相輔相成的新一代雲原生架構
當我們談及數據網格(Data Mesh)，總是談及「分散式架構」、「去中心架構」等名詞，坊間更多是混著過往的資料平台技術（資料虛擬化、資料倉儲、ETL 管線）混為ㄧ談，模糊了數據網格的實際意義和架構。
究竟數據網格帶來的好處和意義是什麼？隔壁棚的微服務也是以「分散式架構」存在，是否和 Data Mesh 有所關聯？本文將探討這個問題，順便破解許多坊間的迷思。
Data Mesh 的基礎核心概念
事實上， Data Mesh 核心概念是將各種資料技術整合在一起協作為目的，不單只是探討多元的資料應用架構如何設計，也探討多個資料基礎設施(Data Infrastructure) 的分治及宏觀下的管理整合。
可以說在 Data Mesh 的實現下，所有的資料系統不管是採用什麼技術，都應該是共存、共通的存在，亦不會有許多應用被過度集中在一個特定的實體運算節點、系統身上，所以 Data Mesh 才會有「分散式架構」的稱呼。
欲探討 Data Mesh 實際組成，通常可以從「資料應用」和「資料基礎設施」兩個角度去分開解析，然後再綜合考量。
從資料應用去看待 Data Mesh
首先從資料應用的角度，根據麥肯錫(McKinsey) 網站上的 Data Mesh 示意圖，清楚描述資料應用場域（Use case）都需要來自不同資料領域（Data Domain）的資料，這些資料可能來自於不同業務、應用程式甚至是跨組織的系統。
利用正確的資料產品(Data Product) 設計，可以分享資料並供應給所有人使用。藉由資料產品正確且共通的介面設計，使所有人都可以輕易從不同地方、不同系統、不同業務應用中，取得自己想要的資料，並在自己的應用場域(Use case) 中使用。
雖然這裡的概念乍看下很簡單，若看的角度不夠全面，就可能存在許多錯誤迷思，導致真正在建構 Data Mesh 的架構時，最後還是回到大孤島（Silo）的處境。而主要可能的錯誤迷思有兩個：
潛在的錯誤迷思一：只要滿足跨系統資料能共通交換
許多舊的資料系統解決方案供應商在進入 Data Mesh，首先都是從這個角度切入。因為單單要滿足「跨系統資料能共通交換」這一項條件的字面上意義，非常簡單。只需要建立一座足夠大的資料庫、資料倉儲，將所有資料利用 ETL 都匯入其中即可。而所有需要資料的人，只需要在這座資料倉儲系統上使用資料，理論上就算實現了資料共通交換的目的。
而採用數據倉儲的大集中解決方案，雖看似資料來自不同系統，可實際上在進行實際應用運算處理時，單只是將所有資料集中到單一系統上運行，只有資料跨系統，但全部的運算處理還是在同一個實體節點或系統身上。
這樣的設計導致此倉儲系統壓力極高，所有應用需求在同一個系統上搶奪運算資源，而且以往倉儲系統強調的是 OLAP 能力（不是為了 OLTP 設計），面對高併發（Concurrent）的需求無法應對，所以也無法滿足許多實際應用需求，更別提近年來數位時代需要的「即時」追求。
潛在的錯誤迷思二：以資料虛擬化為主的交換資料
提到交換資料大多數人都會提及「資料虛擬化(Data Virtualization)」，因為實際應用場域都希望能直接取得具有意義、乾淨整齊的資料來使用，畢竟這些終端應用只是資料使用者，都希望以最快、有效率的形式取用資料。
傳統的資料虛擬化實際上就是一個類似資料庫裡 View 的存在，可以創造一個虛擬（實際上不存在於業務應用）的表，其整合來自不同來源的資料，然後讓使用者可以透過這個表觀察不同來源資料的聚合結果。
然而，這個 View 的運算和整備，以往都是存在於倉儲、集中化資料系統之中，如同「迷思一」所有的壓力都落於單一實體的系統上，難以撐住來自四面八方的各種應用需求。一些舊式的系統，甚至是在存取當下才去進行資料整合的工作，除了其效率、效能表現一場悲劇，其硬體成本更大幅上升。面對高併發、即時的應用需求，更是力不從心。
這樣的架構下，很多企業組織甚至都在吵一個問題：應用的資料需求升高，造成資料平台的壓力和成本大幅增加，這該由誰負責？又如何計算運算資源呢？當此平台只能透過升級特規硬體來提升效能，或是達到硬體物理極限了，又該怎麼辦呢？
註：在這種設計下，尤其對於採用雲端的企業來說，其成本甚至可能百倍成長，成本跟系統效能的轉化率相當的低。
換著從基礎設施角度看待 Data Mesh
可以說，光從資料應用角度看待 Data Mesh 無法看見全貌，而且會面對有許多迷思，各家解決方案都著重在各自的「點」上，導致「一個 Data Mesh 架構各自表述」的情況頻頻發生。不過，當我們再引入基礎設施的角度來看這件事，就能恍然大悟其中 Data Mesh 的與眾不同。
在 Data Mesh 架構中（圖右），主要探討著資料如何被「妥善交付」到應用端，資料在被訂閱之後都會落於屬於應用程式的專屬專用區，這個「資料私有化」的存在有如過去資料虛擬化，但不同的是這裡可以是「任意的資料系統解決方案(SQL/NoSQL/Streaming…)」，完全可以是獨立的資料基礎設施，而且這一層的系統由應用端所負責管轄，並且與上游完全獨立。
由於資料不再集中在特定單一的系統平台上進行運算和處理，當我們建置以 Data Mesh 架構的數據中台時，不再有非常大的運算壓力、運算成本，而主要工作「以資料交換為核心主體，不再是以運算密集為主體」，在責任歸屬上非常明確，可以完全遵循使用者付費。
在效能表現上，所有的運算因為已經脫離了特定的實體，依據業務情境被分散分流於各應用所負責的運算資源上，理論上已經不再有效能瓶頸的問題，而且有機會可以橫向擴展。
註：在系統管理角度，運算單元可能仍然由資料、數據團隊所管理，但因為運算需求已經被明確且獨立化，管理團隊在面對應用團隊時，只需要談「資源租用」的議題即可。你可以想像建構數據中台，就像自己開了一家咖啡館，以前客人都採內用形式，你的場地、清潔、器具成本需要自己吸收，現在你改為提供外帶服務，客人可自備杯具或是你收費額外提供免洗杯。
落實 Data Mesh 後最終呈現的樣貌
理論上落實 Data Mesh 後，所有的資料系統和應用系統應該會共榮共存。每個應用本該有自己「最適用情境的資料解決方案」，在這樣的分散架構下能夠發揮出每個元件設計上該有的最佳表現。而且所有的系統各自獨立，互相不干擾的情況下可以各自發展、平行運算處理，所有的業務需求不再被特定的系統綁住而限制。
也可以發現，其實引入 Data Mesh 並不會對既有系統架構造成極大的衝擊，反而是增加資料的流通性、應用多元性，並且在系統橫向擴展彈性上有極大的提升，許多大大小小的服務，都可以與之搭配運作。
仔細觀察後會發現，這個系統樣態跟隔壁棚的「微服務架構」怎麼如此相似？是的，這其實就是微服務架構的面貌，概念上並無二致。因為資料流程其實也就是業務流程，當你梳理清楚資料流程，其實你也能大概弄清楚微服務規劃的相關議題。
Data Mesh 巧合的支撐微服務架構下的資料庫私有化
從之前的圖裡我們可以發現，微服務架構(MSA, Microservice Architecture)和 Data Mesh 架構能合作無間，資料私有的狀態正好對應到微服務的資料私有化（Database per service）。資料產品訂閱機制，也正好實現了讀寫分離（CQRS）的軟體設計模式，完全符合微服務的需求。
微服務的事件驅動設計支撐 Data Mesh 的資料流程運作
微服務大量運用事件驅動架構(EDA, Event-driven Architecture)，在設計上會確認動作(Action)和事件(Event)的關係，以及事件之後的觸發行為。原先只在 MQ 或 Data Fabric 上的事件，剛好可以被收集和整合成 Data Mesh 的資料產品(Data Product)，讓某個業務流程的資料狀態可以被保存，然後供應給其他領域的應用系統所使用。
當導入 Data Mesh 實現數據中台時，理論上也伴隨著資料流程的梳理，以設計各類的資料產品、資料處理流程、資料分流機制等，而這些種種細節跟微服務架構在本質上完全相同。這也是為什麼微服務架構和 Data Mesh 是一個天生契合的存在，甚至可以說 Data Mesh 就是「資料版的微服務架構」。
那麼你可能會問，資料產品(Data Product) 機制的設計又應該如何呢？如何讓其能保存事件歷程，又要保存資料聚合狀態？該如何管理、發布和交換其資料呢？這就是另外一個議題了，待日後有機會在另外撰文討論。
