學習筆記|資料分析平台轉型-從集中式datalake到分散式 data mesh
Data Mesh 實際上是一組數據平臺架構原則，融合了分佈式領域驅動的架構（Distributed Domain Driven Architecture）、自助平臺設計（Self-serve Platform Design）以及將數據視爲產品（Thinking Data as a Product）的思維
分享者: 呂欣學—Patrick Lu /Trend Micro/Global Lead Architect for data and AI/ML
為什麼我會想聽這個分享?
醫療數據累積很快，醫院端需要做研究，目前的方式大致上有兩種。
- 資訊部門直接協助 : 一種是有需要的人，直接找資訊部門，請工程師直接撈取，
- 集中式研究資料庫: 特別準備一個資料庫，將院內資料，定期備份，集中式處理至研究資料庫，有一個使用介面，讓研究使用者自己撈取，有一個 data research menamgement 來做處理，這個量少的話應該使用上還蠻方便，只是時間一旦拉常會遇到， data duplicate 的問題。
這是我觀察台灣醫院的現況，看到這講題很好奇，國外營運的公司為什麼想從集中式，改道分散式，是因為遇到怎樣的問題和挑戰，又打算怎樣解決? 這個分享很療癒，在數據激增的現在，大家都共同面臨到資料產生價值的挑戰，今天了解 data mesh 這個原則概念，雖然我是統計背景出身，對我也有很多啟發。
大家面臨到資料產生價值的挑戰
從資料產生價值的生命週期長
數據集中式管理，資料在使用上，還是有分散與孤立的問題，有了資料，但要使用資料來解決問題前，我必須要了解資料特性與來源，資料集中管理者，不一定了解資料，可能還是要回到源頭，去找業務端的開發者，才能了解資料是如何來的，有人或許會說可以看文件，但通常工程師文件不會寫太好，也不太願意寫文件。
所以如果要讓資料要能產生價值的，找到正確的 team ，問到正確的人，拿到正確的資料，如何設計出這個流程架構，來讓這個流程更容易，這是必須要面對的問題。
What is Data Mesh?
Data Mesh 這個名詞，是由 ThoughtWorks 的 Zhamak Dehghani 提出，於2018年她在部落格文章 “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh” 中，首次闡釋 Data Mesh 的概念。Zhamak Dehghani 一直從事推廣 Data Mesh 的工作，也是主要的倡導者。
Data Mesh 實際上是一組數據平臺架構原則，融合了分佈式領域驅動的架構（Distributed Domain Driven Architecture）、自助平臺設計（Self-serve Platform Design）以及將數據視爲產品（Thinking Data as a Product）的思維。[1] (這邊有很多名詞，我都不熟，就先貼上來，後續可以方便反芻。)
換句話說，就是以應用目的為終點來設計數據平台，讓數據使用者有能力獨立使用這資料，發揮數據價值的一種數據平台的設計原則，但要怎樣做，有很多做法可以執行，在分享中，Trend Micro 目前是以 Starbrust 所提供的解決方法，進行 data mesh 的 POC ，好像還有其他的公司也有類似的產品，如 Dremio 與 Databricks Lakehouse等，剛剛找到一個網頁[2]有把這三個公司進行依些比較。
統計背景的我，對於系統架構不熟，但從中仍有收穫很多。
我的三個收穫
1.以始為終的，以 data product 的角度出發，設計數據管理平台
以前大數據剛開始時，不管三七21，只要未來可能會用到的，線上線下的都收集起來，現在資料量激增，如何更有效的管理數據，讓數據能發揮價值，是大家都需要解決的問題。而 data mesh 就是基於這樣的信念下，所產生的一種資料治理的原則，以業務端的角度出發，以 data product 為單位來整理資料，讓 data consumer 可以更好的進行運用，這是一種思維上的改變，從收集的角度，轉而以應用的視角進行資料建置與處理。
2. data 是很有 power，透過好的平台架構賦能於人，讓每一個人都能進行 self-serve data analytics，加快資料產生價值的生命週期。
目前一個系統都是一個資料庫，但要將數據價值擴散，一定是要串起不同的資料庫，才能讓資料發揮效益，讓我回想起，最近公司健檢數位化的過程，因應業務需求，獨立建置了很多系統，各自系統有各自的資料庫，但要檢視整體健檢流程中，哪邊可能發生瓶頸時，讓後續的健檢流程能更好，就必須串連這些資料庫，才能觀察出端倪。
目前所有撈取資料的過程，幾乎都仰賴工程師，但是工程師或分析師，並沒有業務的背景，必須不斷地來回確認，相對耗時，如果能將這些資料庫串接起來，搭配好的工具，讓業務端能根據自己的痛點，透過資料來找出問題點，一定能加快資料產生價值的生命週期，讓業務端自己進行資料分析與應用，一定是未來的趨勢。
3.小公司雖然暫時不適合導入這樣的技術，但可以透過 SQL view 產生虛擬的 data product layer。
在資料庫系統中, 適當使用 View可以減少 Data Duplicate 的問題，也可以解決資料散落在不同資料庫的問題，對於使用者來說，不需要了解這張表的資料是從哪一個資料庫來，可以專注在思考資料特性與解決問題的任務上。
後記| 我會在公司中推廣這項技術?
要不要推動一項技術，目前會從三個面向來考量，規模化、常態化和高門檻。
1.規模化 : 數據是否達到一定的規模，當有一定的規模，才需要採用這樣的數據。
2.常態化 : 目前資料的輸入與輸出使用的頻繁程度是不是很高? 如果不是很高，或許目前集中的方式，還能負荷也不一定要導入新的技術。
3.高門檻: 運用 data mesh 這些技術必須要搭配好的資料基礎團隊來維運，且在公司文化上，必須進行從上而下，由下而上的資料思維同步，打造整個流程的作業標準，門檻是高的，如果公司在實務上有需求，在人才充足的情況下，是可以導入，解決目前資料管理上與應用上的痛點。
目前採用 Data mesh 的公司，包括Zalando、Intuit、Netflix、JPMorgan Chase 和 Trend Micro，有興趣的人可以在這些公司的分享中取經，透過規模化、常態化和高門檻來評估，我目前不會在公司採用 data mesh 這個架構，但是會想嘗試使用SQL view 產生虛擬的 data product layer，試試看將 data 是為 data product 的效果，以及是否能加快資料產生價值的生命週期。
參考資料來源:
2.Databricks Lakehouse vs. Dremio vs. Starburst Enterprise Comparison Chart
4.Data mesh: all you need to know about distributed data delivery
5.How a Data Mesh Approach for a Financial Services Organisation Put Data at the Core of Innovation
6.Data Mesh — A Data Movement and Processing Platform @ Netflix
