Skip to main content

What is Data Mesh ?

如標題所寫,這篇文章就是要跟大家解釋 Data Mesh 是什麼。其實我個人很討厭做這種 Buzzword 的內容,Date Lake, Lake House, Data Warehouse,每年都會蹦出幾個新花樣,其實只是想要框你錢買下他們的產品。

但身為一個學者,我認為這些 Buzzword 的背後,一定有一些值得學習的特點是可以做出一個真的產品的,而且是大家需要,真的能改善大家日常工作流程的那種。

順帶一題,我會把我腦子想的也跟你們分享,首先我要知道哪個網站是可以相信的,如下圖所比較

如何判讀資訊​

這種網站就是大便,因為網站建立者的意圖就是要你去點它旁邊的廣告,可想而知提供的資訊八成也是大便。(我怕毀損別人商譽,我沒有特訂針對只是個人看法而已)

下面這兩個網站就是我覺得可以相信的網站,一個是我以前量子物理的老師的網頁筆記,另外一個是 MIT 6.5840: Distributed Systems 這門我自己很喜歡的課程,看出差別了嗎,這種雖然排版配色都沒有下上面那個網站多工夫,但是你會馬上知道這!個!網!站!是!寶!

這個網站除了告訴你事實,它就沒有其他屁用。

原汁原味的 Data Mesh​

好啦!話題回歸那樣 Data Mesh 要怎麼開始研究呢?

我直接開始讀 Data Mesh 這個詞發明人 Zhamak 的文章,而且網站是不是也是個值得 “信賴” 的呢?(看看我上面風格的說明)

就她的觀察,大家比較會採用的架構就是 ETL 拉到分析的團隊和他們的基礎設施上。

阿然後你也知道,公司規模一變大就會變成這種亂七八糟的模式。

所以 Zhamak 就發現這其實是團隊結構性問題。

改成像是下面這樣,每一個 Operational Team 再提供一組 API,給內部使用,我需要用到什麼資料,我可以像是吃自助餐 Buffet,隨時選我想要的資料來使用。

美景有了,現在就剩下實作的問題,原作者也給了下圖一樣的建議,我們一一仔細說明其內容!

實作方式​

那上圖那些 API 要怎麼實作呢?

作者給出的建議是要滿足三個條件:

  • 有自己的基礎設施 (像是 運算資源 和 儲存空間)
  • 有自己邏輯該執行的 Code
  • 提供多種的資料格式

Kubernetes​

那我們就一個一個來解決吧,有自己的基礎設施最簡單的方式就是設計成 Kubernetes 的 StatefulSet 這項想要製作新的 Data Product 直接新增 YAML 就可以了。

NATS/JetStream​

接著就是我最頭疼的問題,Data 要保存在哪裡,我第一個想到的就是 NATS 這個是連台積電都再用的 CNCF 專案喔 (我甚至去聽過他們的演講)。

NATS 以前只是一個 Message Broker,直到 v2.0 之後開始做得跟 kafka 一樣的有 Exactly-Once、Pull-based…。而且最重要的 NATS Image 只有 15MB 阿!

Embedded Database Engines​

好了,我現在手上有 Stream 可以用了,我只要寫一些 Code,就可以把 Stream 儲存的格式,直接轉化成各式各樣的類別,舉例來說:Dgraph 有開源一個 Go 的 Embedded Key-Value Engine,這個可以拿來當 rocksdb 用,而且 New York Times 的工程師還公開在演討會上分享自己怎麼用這個 Key-Value Engine 來開發。

OLTP 的部分已經搞定了,解下來就是 OLAP,簡單科普一下,現代的 OLAP Engine 通常都不做 Storage 了,要分析的時候直接從像是 S3 的 Object Store 拉出來就好,像是 Trino、Velox、DuckDB。

因緣際會下,我在 Youtube 有聽了幾場 DuckDB 的演講,作者想要把 OLAP 的 SQLite 做出來,所以我也 Embed 進去我的設計裡面。

Data Product 的部分我想已經設計完成了,接著就是這些 Data Product 怎麼被管理,恰好 NATS 有 Leafnode 的功能,我直接拿來用,現成的 Hub-Leaf 網路架構幫我省了不少麻煩。

在兩個星期的努力後,我終於設計出了一個 MVP,想體驗看看可以直接 Quickstart 體驗我設計的系統一下。