認識數據網格(Data Mesh)
當我們談到微服務的時候，很多人聽過服務網格(Service Mesh)，甚至不少人透過 istio 這類工具進行實作了。但是，人們對於數據網格(Data Mesh)的理解卻知之甚少， 我們經常在介紹產品的場合中，發現很多客戶甚至聽都還沒聽過呢。
Data Mesh 的倡議者
來自 ThoughtWorks 的 Zhamak Dehghani，正式提出了 Data Mesh 這個專有名詞，2018年她在部落格文章 “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh” 中，首次闡釋 Data Mesh 的概念。自此之後，Zhamak 一直從事推廣 Data Mesh 的工作，也是主要的倡導者。
2021年4月 Zhamak 在一個 Webinar 題目 “Data as a product“ 中再次提到 Data Mesh 的核心概念:
https://www.thoughtworks.com/webinar/data-as-a-product#recording
Data Mesh 的基本概念
數據網格(Data Mesh)是一種設計和開發數據體系結構的新方法，有別於數據倉庫/數據湖的集中式整體架，數據網格是高度分散的數據架構。
結合集中式數據湖/數據倉庫，數據網格試圖解決的挑戰主要有三：
· 所有權：擁有數據的是數據源團隊還是基礎架構團隊？
· 質量：基礎架構團隊對質量負責，但對數據不甚了解。
· 組織擴展：企業數據湖/數據倉庫中央團隊逐漸成為發展瓶頸。
數據網格所提倡的資料基礎即平臺(data infrastructure as a platform)概念包含了數項功能：
· 資料儲存(storage)
· 資料管線(pipleline)
· 資料型錄(catalog)
· 存取控制(access control)
Data Mesh 的實作挑戰
然而，Zhamak 的文章與影片偏重理論闡述，對於實作則沒有太多著墨，只是蜻蜓點水式的提到即止。但這卻是人們最感興趣的部分，似乎需要完整的專有虛擬化軟體，並且處理數據虛擬化存在的許多問題。而且，在加速數據網格的實現方面，開源工具與商業軟體也存在不少差距，而且還面臨主數據管理（Master Data Management, MDM）和統一維度的挑戰。但是，我們相信持續演進的技術正在解決這個問題。
一般來說，數據網格僅對擁有大量數據域(Data Domain)的公司才有意義，同時可能存在由誰控制數據或數據主權的政治衝突。許多人認爲數據網格通常僅適用於大公司，因為設置環境可能很困難且很耗時，同時也需要非常專業的團隊才有達成的可能。然而在臺灣，能養得起如此規模的技術團隊的公司不多。除了技術養成成本也非常可觀之外，更困難的是缺乏新的資料思維來應對數據網格的顛覆性實作，無論是資料人員還是應用開發人員，都沒能跳脫傳統的集中式處理框架。
不少企業企圖透過企業服務匯流排（Enterprise Service Bus，ESB）來突破資料供應的困局。然而這一點都解決不了集中處理架構的瓶頸問題，反而隨着資料源及應用的增長，中央匯流排的瓶頸效應更是雪上加霜！
Data Mesh 的實作手法
歐洲著名的線上時裝銷售平臺 Zalando 爲我們示範了如何從資料湖過渡爲數據網格的實際經驗：
數據網格的實作關鍵就是 “去中心化” ：
· 從中央基礎架構轉爲分散式資料儲存
· 從中央控管轉爲資料所有權下放
簡而言之，就是將資料進行拆解(decompose)，沒錯，就是跟我們在微服務建置過程中常見的服務解偶(decouple)一樣的做法：將一個巨型的單體拆解爲多個微小的單元。
前幾天搜尋資料時無意間看到 Redhat Microservice Day 2018 中一段討論資料策略的影片:
原來 Redhat 早在三年前的就跟我們介紹過 Data Mesh 的概念了，只是當時簡報使用的名詞叫 Data Grid。其中提到的技術大致有 Event sourcing、 Event Stream/Replay、CQRS等等。但具體的實作需要借助如下這些產品：
· Infinispan ：用 Java 撰寫的分散式資料快取，也可以作爲 NoSQL key/value 儲存或物件資料庫
· Teiid：針對 SQL 用戶端、 OData 或 REST 提供虛擬資料存取
· Debezium：用於捕獲變更數據的開源分佈式平台
然而，以上的產品都是彼此獨立的元件。抱歉，影片並沒有告訴你，如何將這些各自爲政的工具統整爲具備完整特性的企業方案。換句話說，大家必須捲起袖子打造輪子就是了！
我們需要一個新世代的數據中臺
我們要打造一個數據中臺來處理資料供應，透過數據虛擬技術為服務應用提供資料中繼，以實現資料私有化(Database per service)。
作爲一個新世代的數據中臺，大都具備如下四個特性：
1. 資料是數據中臺的原始細胞：離開了資料數據中臺啥也不是！
2. 現代的資料架構大都符合領域驅動設計(Domain-Driver Design, DDD)。然而，DDD 的實現通常需要命令查詢職責分離(Command Query Responsibility Segregation, CQRS) 這類的模式。
3. 將數據基礎架構建置為平臺的關鍵是：
（a）不包含任何特定於領域的概念或業務邏輯，使其保持領域不可知性。
（b）確保平臺隱藏了所有潛在的複雜性並在其中提供數據基礎架構組件自助服務的方式。
4. 分散式數據平台若要獲得成功，領域數據團隊必須嚴格地將產品思維應用於他們提供的數據集上面。將其數據資產視為產品，並將資料使用者（例如數據科學家、機器學習和數據工程師）視為客戶。
作爲企業級的應用產品，我們應該盡可能的將數據供應的複雜性隱藏起來，客戶只需知道兩件事情就夠了：
· 資料來源(source)：要去哪裏抓什麼樣的資料？
· 資料目的地(destination)：要將資料以什麼格式發佈到哪裏？
對資料使用者來說，他們完全不需要操心資料的提取、更新、轉換、呈現這些發佈細節。他們唯一在意的就是資料供應鏈發布規模與效能問題而已！
假如我們告訴您：這樣的產品已經有人實作出來了，而且就在臺灣！請不要懷疑：這是真的！
倘若您需要一個新世代的資料引擎來協助您處理資料調度的議題、並協助企業加快落實數位轉型的步伐，請聯絡我們！
本文整理自寬橋（Brobridge）過往協助客戶導入資料串流架構、資料系統架構改造以及實現一些資料即時性需求的經驗，若您有相關的疑慮和困擾，歡迎 與我們直接聯繫。
