從單體數據湖到分佈式數據網格

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我工作過的許多公司，都把成爲數據驅動型組織設定爲它們的首要戰略目標之一。我的客戶深知AI賦能的益處：可以提供基於數據和超個性化（hyper-personalization）的最佳客戶體驗；同時通過數據驅動的優化減少運營成本和時間；還可以爲員工提供更強大的趨勢分析和BI能力。他們一直在大力投資數據和智能平臺等賦能引擎。遺憾的是，儘管這些企業在構建此類賦能平臺方面付出了更多的努力和投入，但結果往往不盡人意。我理解企業在轉變成爲數據驅動的組織的過程中面臨着多方面的難題。因爲他們從數十年的遺留系統遷移而來的同時，也會被反對依賴數據的遺留文化影響，同時，競爭激烈的業務優先級排序也阻礙了這種轉變。但是，我想分享一種導致數據平臺計劃失敗的架構視角。我將展示如何將過去十年在分佈式架構中的學習成果應到數據領域中。我也會介紹一種新的企業數據架構，稱爲數據網格(即Data Mesh)。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在閱讀之前，我的建議是暫時先放下“基於當前數據平臺體系構建範式”的假設和偏見；對從單體式和中心化數據湖轉變到數據網格架構的可能性持開放態度；擁抱數據永遠存在、無處不在、天然具有分佈性特徵的現實。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"當前的企業數據平臺架構"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"它是中心式，單體式和領域不可知的，又被稱爲數據湖。幾乎每個與我合作的客戶都在計劃或正在構建他們的第三代數據和智能平臺，同時也承認過去幾代的失敗："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"第一代：專有的企業數據倉庫和商業智能平臺；這些高價的解決方案使公司承擔了巨大的技術債務。這數千個無法維護的數據倉庫技術作業、表格和報告中的技術債務，卻只有一小部分專業人員能夠理解，這使得其對業務產生的積極影響被低估。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"第二代：以數據湖爲”特效藥“的大數據生態系統；在複雜的大數據生態系統中，超專業數據工程師團隊經過長期運行，已經創建了“數據湖怪獸”，這些龐然大物充其量可以實現大量的“研究與開發”分析，但是存在“承諾有餘、實現不足”的情況。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"第三代和當前的數據平臺或多或少與上一代相似，但在現代方向上轉變如下:（a）通過Kappa等架構進行流傳輸以實現實時數據可用性，（b）使用Apache Beam等框架統一批處理和流處理以進行數據轉換，（c）全面採用基於雲的託管服務，用於存儲，數據管道執行引擎和機器學習平臺。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"顯然，第三代數據平臺正在填補前幾代的空白，並在降低管理大數據基礎架構的成本，例如實時數據分析。但是，它同樣具有許多導致上一代失敗的潛在特徵。"},{"type":"text","marks":[{"type":"strong"}],"text":"架構故障模式"},{"type":"text","text":"爲說明各代數據平臺所面臨的潛在限制，讓我們先看一下它們的體系結構和特徵。在本文中，我以互聯網媒體流業務領域（例如Spotify，SoundCloud，Apple iTunes等）爲例來闡明一些概念。"},{"type":"text","marks":[{"type":"strong"}],"text":"中心式和單體式"},{"type":"text","text":"宏觀來看，數據平臺架構如下圖1所示。中心式架構，其目標是："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"從企業的各個角落提取數據，這些數據的範圍包括企業的運營和交易系統以及經營業務的領域，還有擴展企業知識的外部數據提供商。例如，在流媒體業務中，數據平臺負責攝取各種數據：“媒體播放器性能”，“用戶與播放器的交互方式”，“被演奏的歌曲”，“被關注的藝術家”以及作爲企業已加入的“標籤和藝術家”，與藝術家的“經濟往來”以及外部市場研究數據（例如“客戶人口統計”信息）。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"平臺清理、豐富源數據並將其轉換爲可滿足各種消費者需求的可信賴數據。在我們的示例中，其中一種轉換是將用戶交互的點擊流變成了帶有用戶詳細信息的數據。這試圖在聚合中重構用戶的行爲。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"平臺將數據集提供給具有各種需求的消費者，達到分析消費，探索數據以尋找洞見的目的，同時也可以實現基於機器學習的決策制定，撰寫總結業務績效的商業智能報告等。在我們的流媒體示例中，該平臺可以通過分佈式日誌界面（例如Kafka）提供有關全球媒體播放器的實時信息，或提供正在播放的特定藝術家靜態彙總視圖，以幫助財務理清給藝術家和唱片公司的付款。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/9c\/9c82531280c8873844f41fa4dfa4027d.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖1：宏觀視角下整體數據平臺視圖"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"一般來說，整體數據平臺會託管邏輯上屬於不同領域的數據。例如“播放事件”，“銷售KPI”，“藝術家”，“專輯”，“標籤”，“音頻”，“播客”，“音樂事件”等；來自大量不同領域的數據。在過去的十年中，儘管我們已成功將領域驅動的設計和有限的上下文應用於我們的操作系統，但我們在很大程度上忽略了數據平臺中的領域概念。我們已經從面向領域的數據所有權轉移到中心式的不可知數據所有權的域。我們以創建最大的整體（即大數據平臺）而自豪。"}]},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/57\/573c28ac18730f549782ac91f174e39b.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖2：領域數據界限和所有權不清的數據平臺"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"儘管此中心式模型可用於領域更簡單、消費案例數量較少的企業，但對於領域豐富，來源衆多且消費者多樣化的企業卻不適用。中心式數據平臺的體系結構和組織結構上存在兩個壓力點，這些壓力點通常會導致失敗："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"無處不在的數據和源擴散：隨着越來越多的數據變得無處不在，在一個平臺的控制下，在一個地方使用所有數據並進行協調的能力將減弱。想象一下，僅在“客戶信息”領域，在企業內外都有越來越多的提供有關現有和潛在客戶的信息來源。如果假設我們需要在一個地方攝取和存儲數據以從各種來源中獲取價值，我們對數據來源擴散的響應能力將被限制。我認爲需要數據用戶（例如數據科學家和分析師）以低成本來處理各種數據集，並且需要將操作系統數據使用的數據與用於分析目的的數據區分開來。但是我認爲，如果企業是具有豐富領域和不斷添加新資源的大型組織，現有的中心式解決方案不是最佳解決方案。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"組織的創新計劃和消費者激增：組織對快速試驗的需求引入了大量用例來消費平臺中的數據。這意味着數據轉換（可以滿足創新的測試和學習週期的聚合，投影和切片）的數量正在不斷增長。滿足數據消費者需求的響應時間過長一直是企業面臨的一個問題，而在現代數據平臺體系結構中仍然如此。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"儘管我現在還不想放棄我的解決方案，但我需要澄清的是，我倡導的領域數據不是隱藏在操作系統中的，分散的，孤立的，也不是難以發現，理解和使用的。我不支持技術債務中形成的分散數據倉庫。這是行業領導者的關注點。但是我認爲，解決這些問題的方法並不是建立一箇中心式的數據平臺，而是由一箇中心團隊組成來管理。正如我們在上面論證的那樣，它沒有組織化的規模。"},{"type":"text","marks":[{"type":"strong"}],"text":"耦合流水線分解"},{"type":"text","text":"傳統數據平臺體系結構的第二種故障模式與我們如何分解體系結構有關。放大中心式數據平臺後，我們發現一個圍繞攝取，清理，聚合，服務等機械功能的架構分解。企業中的架構師和技術領導者會根據平臺的增長來分解架構。如上一節所述，引入新資源或應對新消費者的需求要求平臺不斷髮展。架構師需要找到一種方法，通過將其分解爲體系結構量子來擴展系統。如《設計可進化架構》中所述，架構量子是具有高功能凝聚力的、可獨立部署的組件，其中包括系統正常運行所需的所有結構要素。將系統分解成架構量子是爲了創建獨立的團隊，團隊裏每個人都可以構建和操作架構量子。這些團隊之間的並行工作可提高的運營可擴展性和速度。鑑於前幾代數據平臺體系結構的影響，架構師將數據平臺分解爲一系列數據處理階段。這邪惡管道在高水平處理數據並實現攝取，準備，彙總，服務等功能的凝聚。"}]},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/ce\/ce2cdd0eb162af54250f4fd86bd41ca3.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖3：數據平臺的體系結構分解"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"儘管此模型通過將團隊分配到流水線的不同階段擴大了規模，但它具有一個固有的侷限性，那就是使功能交付速度變慢。它在流水線的各個階段之間具有很高的耦合度，以提供獨立的功能或價值。它與變化軸正交分解。讓我們看一下我們的流媒體示例。網絡流媒體平臺有一個強大的媒體類型領域構造。他們通常從“歌曲”和“專輯”等服務開始，然後擴展到“音樂事件”，“播客”，“廣播節目”，“電影”等。啓用單個新功能，例如“播客播放率”的可見性，則需要更改管道中的所有組件。團隊必須引入新的攝取服務，新的清理和準備工作以及用於查看播客播放率的合集。這需要在組件之間進行同步，並在團隊之間進行發佈管理。許多數據平臺提供的提取服務可以應資源添加擴展問題，以最大程度地減少開銷。但是，這並沒有從消費者角度解決端到端依賴性問題。我們看似已經達到了流水線階段的架構，但實際上整個流水線（即單體式平臺）是必須改成適應新功能的最小單元：解鎖新數據集並將其用於新的或現有的消費。這限制了我們響應新的使用者或數據源以實現更高速度和更大規模的能力。"}]},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/bb\/bb88df19eef8b82f8bb4fdb4a1654466.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖4：引入或增強功能時，架構分解與更改軸正交，從而導致耦合和交付速度降低"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"孤立和超專業的所有權"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"當今數據平臺的第三種失敗模式與我們如何組織構建平臺的團隊有關。當我們實地觀察數據平臺的人員的生活時，我們發現他們是一羣與組織運營部門隔離的超專業數據工程師；對於數據源自何處或在何處使用並付諸行動和決策制定並不知情。數據平臺工程師不僅在組織上處於孤立狀態，而且根據他們在大數據工具方面的技術專長（通常缺乏業務和領域知識）分類使得他們通常缺乏業務和領域知識。"}]},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/dd\/dde98357dd9b1a931311394bfda70bb7.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖5：孤立的超專業數據平臺團隊"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我並不羨慕數據平臺工程師的生活。他們需要消費來自團隊的數據，這個團隊通常不能提供有意義的、真實的和正確的數據。他們對生成數據的源域瞭解甚少，並且團隊中缺乏領域專業知識。他們需要針對各種操作或分析的需求提供數據，但卻不瞭解數據的應用，也無需與使用領域專家聯繫。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在媒體流領域，比如在源端，我們有跨職能的“媒體播放器”團隊，可提供有關用戶如何與他們提供的特定功能進行交互的信號，例如“播放歌曲事件”，“購買事件”，“播放音頻質量”等；另一端是消費者跨職能團隊，例如“歌曲推薦”團隊，報告銷售KPI的“銷售團隊”，根據演出計算和付款給藝人的“藝人支付團隊”等。不幸的是，位於中間的數據平臺團隊則拼命爲所有來源和消費提供合適的數據。實際上，我們還發現有的源團隊彼此沒有聯繫，有的互相爭奪，導致過度拉伸。我們創建的架構和組織結構無法擴展，並且無法實現創建數據驅動型組織所承諾的價值。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"下一代企業數據平臺架構"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"它通過分佈式數據網格包含了無處不在的數據。那麼，我們上面討論的故障模式和特徵的答案是什麼？我認爲有必要進行範式轉換，以期在大規模構建現代分佈式體系結構中發揮作用。整個技術行業都採用了這些技術，並取得了成功。我建議下一代企業數據平臺架構是分佈式領域驅動架構、自助式平臺設計以及產品思維與數據的融合。"}]},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/2a\/2a4951e47675913becffc50d84c6d8a8.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖6：融合：構建下一個數據平臺的模式轉變"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"儘管這聽起來像是一句空話，但是這些技術確實在現代化操作系統的技術基礎方面產生了具體的、令人難以置信的積極影響。讓我們來深入研究一下如何將這些方法應用於數據世界，以擺脫當前的舊範式。"},{"type":"text","marks":[{"type":"strong"}],"text":"數據和分佈式領域驅動的架構融合面向領域的數據分解和所有權"},{"type":"text","text":"埃裏克·埃文斯（Eric Evans）的著作《領域驅動設計》（Domain-Driven Design）對現代架構思想以及組織建模產生了深遠的影響。它通過將系統分解爲圍繞業務領域功能構建的分佈式服務來影響微服務體系結構。它從根本上改變了團隊的組成方式，從而使團隊可以獨立自主地擁有領域能力。儘管在實現運營功能時我們採用了定向領域分解和所有權，但奇怪的是，在涉及數據時，我們卻忽略了業務領域的概念。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"DDD在數據平臺體系結構中最接近的應用是用於源操作系統發出其業務領域事件，並用於整體數據平臺來接收它們。但是，超出攝取點的範圍，就失去了領域的概念以及不同團隊對領域數據的所有權。領域綁定上下文是一種功能強大的工具，可用於設計數據集的所有權。Ben Stopford的Data Dichotomy文章介紹了通過流共享領域數據集的概念。爲了使單體式數據平臺分散化，我們需要顛覆我們對數據本地性和所有權的看法。與其將數據從領域中流到中央擁有的數據湖或平臺中，不如說領域需要以易於使用的方式託管和服務於其領域數據集。在我們的示例中，與其想象來自媒體播放器的數據流到某個集中位置以供一個集中的團隊接收，不如想象我們有一個擁有並服務其數據集的播放器領域以滿足團隊下游使用的任何目的。數據集實際駐留的物理位置及其流動方式是“播放器領域”的技術實現。物理存儲肯定可以是諸如Amazon S3存儲桶之類的中心式架構，但播放器數據集的內容和所有權仍保留在生成它們的領中。類似地，在我們的示例中，“推薦”領域以適合其應用的格式創建數據集，例如圖形數據庫，同時消化了播放器數據集。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果還有其他領域（例如“新藝術家發現領域”）對“推薦領域”圖數據集有用，則可以選擇提取和訪問該領域。這意味着當我們將數據轉換爲適合該特定領域的形狀時，我們可能會在不同領域中複製數據。例如，與藝術家相關的時間序列播放事件的圖表。這就要求我們將思維方式從傳統上通過ETL、當前通過事件流的推入和獲取模型轉移到跨所有域的服務和提取模型。面向領域的數據平臺中的體系結構範圍是一個領域，而不是流水線階段。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/92\/925cd9585ed2e4e16e23d8719a6451bc.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖7：根據域（源域，使用者域和新創建的共享域）分解擁有數據的架構和團隊"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"面向源的領域數據"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"一些領域自然地與數據起源的源一致。源域數據集代表業務的現實情況。源域數據集捕獲與其操作系統的來源和現實關聯非常緊密的數據。在我們的示例中，諸如“用戶如何與服務進行交互”或“入職標籤流程”之類的業務事實導致領域數據集的創建，例如“用戶點擊流”，“音頻播放質量流”和“內置標籤”。這些事實是衆所周知的，並且是由起源處的操作系統生成的。例如，媒體播放器系統最瞭解“用戶點擊流”。在理想的情況下，操作系統及其團隊或組織單位不僅負責提供業務功能，而且還負責提供其業務領域的真實情況作爲源域數據集。在企業規模上，領域概念和源系統之間從來沒有一對一的映射。通常，有許多系統可以服務屬於某個領域的部分數據，其中一些是舊式的，而某些則易於更改。因此，可能會有許多源對齊的數據集（也稱爲現實數據集），最終需要將它們彙總到一個內聚的領域對齊的數據集中。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"商業事實最好以商業領域事件的形式呈現，可以將其存儲並作爲帶有時間標記的事件的分佈式日誌，以供任何授權消費者訪問。除了定時事件外，源數據域還應提供易於使用的源域數據集的歷史快照，這些密切反映其領域的更改間隔的記錄在一定時間範圍內彙總。例如，在向流媒體業務提供音樂的藝術家的“內嵌標籤”源域中，每月彙總通過入職標籤生成的事件的內嵌標籤是一種合理的視圖。請注意，源對齊領域數據集必須與內部源系統的數據集分開。領域數據集的性質與操作系統用來完成其工作的內部數據有很大不同。與它們的系統相比，它們具有更大的體積，代表着不變的定時事實，並且變化的頻率更低。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"因此，實際的基礎存儲必須適合大數據，並且必須與現有的操作數據庫分開。數據和自助平臺設計融合部分將介紹如何創建大數據存儲和服務基礎架構。源域數據集是最基礎的數據集，由於業務事實並不經常更改，所以更改頻率較低。預計這些領域數據集將被永久儲存使用，以便隨着企業發展其數據驅動和情報服務，他們始終可以返回到業務事實，並創建新的彙總或預測。請注意，源域數據集在創建時幾乎代表原始數據，並且未針對特定使用者進行擬合或建模。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"面向消費者的共享領域數據"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"一些領域與消費密切相關。消費者領域數據集和擁有它們的團隊的目的是滿足一組密切相關的用例。例如，“社交推薦領域”側重於根據用戶彼此之間的社交聯繫提供推薦，創建適合此特定需求的領域數據集；也可以通過“用戶社交網絡的圖形”表示。此數據集對於推薦用例很有用，也許對於“聽衆通知”領域也有用，該領域提供給不同聽衆發送通知的數據，比如其社交網絡中的人正在聽的內容。因此，“用戶社交網絡”有可能成爲共享的和新定義的領域數據集，供多個消費者使用。“用戶社交網絡”領域團隊專注於提供“用戶社交網絡”的最新視圖。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"消費者對齊的領域數據集與源域數據集相比具有不同的性質。它們在結構上經歷了更多的變化，並且將源域事件轉換爲聚合適合特定訪問模型的視圖和結構，例如我們在上面看到的圖形示例。面向領域的數據平臺應該能夠輕鬆地從源頭重新生成這些消費者數據集。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"分佈式管道作爲領域內部實現"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"儘管將數據集所有權從中央平臺委託給領域，但是仍然需要清理，準備，聚合和提供數據，數據管道的使用也是如此。在這種體系結構中，數據管道只是內部複雜性和數據域的實現，並在域內部進行處理。結果，我們將看到數據管道階段分佈到每個領域中。例如，源域需要包括對其領域事件的清除，重複數據刪除，擴展它們的領域以便其他領域可以使用它們，而無需複製清除。每個領域數據集都必須爲其提供的數據質量、及時性，錯誤率等建立服務水平目標：。例如，我們提供音頻“播放點擊流”的媒體播放器領域可以包括清理和標準化其領域中的數據管道，這樣就可以提供“播放音頻點擊事件”的實時數據流。同樣，我們將看到從中心式管道的聚合階段進入了消費領域的細節的實現。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/c0\/c035be745a394286327c38e595464a23.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖8：將管道分配到領域中"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"作爲第二類關注點，以及領域的內部實現細節有人可能會爭辯說，該模型可能會導致每個領域在創建自己的數據處理管道實現，技術堆棧和工具方面做出重複的努力。我將在談論數據和以自助共享數據基礎架構爲平臺的思維融合時，很快解決這個問題。"},{"type":"text","marks":[{"type":"strong"}],"text":"數據和產品思維融合"},{"type":"text","text":"將數據所有權和數據管道實施分配到業務領域中這件事引起了人們對分佈式數據集的關注可行性，可用性和協調性。在這裏，學習應用產品思維和數據資產所有權非常方便。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"領域數據作爲產品"},{"type":"text","text":"在過去的十年中，運營領域已經將產品思想融入了他們爲組織其他部門提供的能力中。領域團隊將這些能力作爲API（應用程序接口）提供給組織中其他開發人員以作爲創建更高價值和功能的基礎。這些團隊致力於爲他們的領域API（應用程序接口）創建最佳的開發人員體驗；包括可發現且易於理解的API文檔，API測試箱，同時密切跟蹤質量和應用的關鍵績效指標。爲了使分佈式數據平臺獲得成功，領域數據團隊必須以相似的嚴格度將產品思維應用於他們提供的數據集。將其數據資產視爲產品，並將組織裏的其餘數據科學家，機器學習和數據工程師視爲客戶。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/d9\/d944b744262333ce15aa41a5f4dd4e45.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖9：領域數據集"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"作爲產品的特徵回顧我們的示例，互聯網媒體流業務。它的關鍵領域之一是“播放事件”，即誰，何時，何地播放了哪些歌曲。這個關鍵的領域在組織中擁有不同的使用者；例如，近實時消費者會對用戶體驗以及可能的錯誤感興趣，因此在客戶體驗下降或客戶支持電話打入的情況下可以快速響應以恢復錯誤。還有一些消費者更喜歡每日或每月歌曲播放事件聚合的歷史記錄。在這種情況下，我們的“播放的歌曲”領域爲組織的其他部分提供了兩個不同的數據集作爲產品。在事件流上公開的實時播放事件，以及在對象存儲中作爲序列化文件公開的聚合播放事件。任何技術產品（這裏說的是領域數據產品）的一項重要素質就是使它們的消費者滿意。（這裏指的是數據工程師，機器學習工程師或數據科學家。）爲了向消費者提供最佳的用戶體驗，領域數據產品需要具有以下基本素質："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"可發現的"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據產品必須易於發現。常見的實現方式是對所有可用的數據產品及其元信息（例如其所有者，來源，樣本數據集等）編寫目錄。此中心式可發現性服務使組織裏的數據消費者，工程師和科學家能夠輕鬆找到他們需要的數據集。每個領域數據產品都必須在此中心式數據目錄中註冊以方便查詢。請注意，這裏的觀點轉變是從單一平臺提取數據，到以可發現的方式將其數據作爲產品提供到每個領域。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"可尋址的"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據產品一經發現，便應該遵循國際慣例，有一個唯一地址，以幫助其用戶以編程方式訪問它。根據數據的基礎存儲和格式，組織可以爲數據採用不同的命名約定。考慮到易用性，在分散式體系結構中，有必要制定通用的約定。不同的領域存儲和提供數據集的格式不同，事件可能通過諸如Kafka主題之類的流進行存儲和訪問，而柱狀數據集可能使用CSV文件或序列化Parquet文件的AWSS3存儲桶。多種語言環境中的數據集可尋址性標準消除了查找和訪問信息時的摩擦。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"可信賴且真實的"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"沒有人會使用他們不信任的產品。在傳統的數據平臺中，存在數據有誤、不能反映業務真相或者根本無法信任的情況。在這裏，中心式數據管道的大部分工作都集中在此，在提取數據後清理數據。如果要達到根本性的轉變，數據產品的所有者要圍繞數據的真實性提供可接受的服務，以及提供它與事件發生的真實性的接近程度。在創建數據產品時應該應用數據清理和自動數據完整性測試。提供數據源和數據沿襲作爲與每個數據產品相關聯的元數據有助於增加消費者對產品及其適用性方面的信任。數據完整性（質量）指標的目標值或範圍在領域數據產品之間有所不同。例如，“播放事件”領域可以提供兩種不同的數據產品，一種接近實時，準確性較低，包括丟失或重複的事件，而另一種則具有較長的延遲和較高的事件準確性。每個數據產品定義並保證其作爲一組SLO的完整性和真實性。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"自描述的語義和語法"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"優質的產品不需要消費者手持即可使用：它們可以被查詢，理解和消費。將數據集構建爲具有最小單元的產品，以供數據工程師和數據科學家使用，這需要對語義和語法對數據進行充分描述，理想情況下將樣本數據集作爲示例。數據模式是提供自助數據資產的起點。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"可互操作並受全球標準約束"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"分佈式領域數據體系結構中的主要問題之一是關聯跨領域數據並將其有機縫合、連接，過濾，聚合的能力。跨領域有效關聯數據的關鍵是遵循某些標準和統一規則。這樣的標準化應該用於全球治理，以實現多語言領域數據集之間的互操作性。這種標準化工作的共同關注點是字段類型格式化，跨不同領域識別多義詞，數據集地址約定，通用元數據字段，事件格式（例如CloudEvents）等。例如，在媒體流業務中，“藝術家”可能出現在不同的領域中，並且在每個領域中具有不同的屬性和標識符。“播放事件流”域對藝術家的識別可能與負責開發票和付款的“藝術家支付”領域的識別不同。但是，爲了能夠在不同領域的數據產品之間關聯藝術家的數據，我們需要就如何將藝術家識別爲多義詞達成共識。一種方法是考慮具有聯合實體的“藝術家”和“藝術家”的唯一全局聯合實體標識符，這與管理聯合身份的方式類似。受全球管轄的通信的互操作性和標準化是構建分佈式系統的基礎支柱之一。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"安全並受全局訪問控制"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"無論架構是否中心化，都必須安全地訪問產品數據集。在分散的面向領域的數據產品的世界中，對每個領域數據產品都被以更小的單元應用訪問控制。與操作領域類似，訪問控制策略可以被集中定義，但是也可以應用到每個單獨的數據集產品上。使用企業身份管理系統（SSO）和基於角色的訪問控制策略定義是實現產品數據集訪問控制的便捷方法。數據和自助服務平臺設計的融合部分描述了這一共享的基礎結構，該基礎結構可輕鬆、自動地爲每個數據產品啓用上述功能。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"領域數據跨職能團隊"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"將數據作爲產品提供的領域；需要增加新的技能：（a）數據產品所有者和（b）數據工程師。數據產品所有者根據數據產品的願景和路線圖做出決策，更多關注消費者的滿意度，並不斷衡量和提高其領域擁有和生產的數據的質量和豐富性。她負責領域數據集的生命週期，以及何時更改，修訂和淘汰數據和架構。她在領域數據使用者的競爭需求之間取得了平衡。數據產品所有者必須定義成功標準和與業務相關的關鍵績效指標（KPI）。例如，數據產品的消費者成功發現和使用數據產品的交付時間是可衡量的成功標準。爲了構建和運行領域的內部數據管道，團隊必須擁有數據工程師。這種跨職能團隊的一個奇妙的副作用是跨團隊技能互補。我目前的行業觀察是，一些數據工程師雖然能夠使用其交易工具，但在構建數據資產時缺乏軟件工程標準實踐，例如在連續交付和自動化測試方面。同樣，構建操作系統的軟件工程師通常也沒有使用數據工程工具集的經驗。消除技能孤島有助於創建更大的數據工程技能庫。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我們已經觀察到與DevOps運動相同的跨團隊技能互補，以及諸如SRE之類的新型工程師的誕生。必須將數據視爲任何軟件生態系統的基礎，因此軟件工程師和軟件通才必須將數據產品開發的經驗和知識添加到他們的工具帶中。同樣，基礎架構工程師需要增加管理數據基礎架構的知識和經驗。企業必須提供從通才到數據工程師的職業發展途徑。由於缺少數據工程的技術從而導致了之前「孤立和超專業的所有權」那節中的中心化的數據工程團的過度局部優化的問題。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/8e\/8ea9214c71409fe240deec95361b92a8.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖10：具有明確數據產品所有權的跨功能領域數據團隊"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"數據和自助平臺設計融合"},{"type":"text","text":"將數據所有權分配給領域的主要問題之一是可能存在重複工作。幸運的是，將通用基礎架構構建爲平臺已經是衆所周知的問題，並且已經得到解決。將領域不可知的基礎架構功能收集和提取到數據基礎架構平臺中，解決了重複設置數據管道引擎，存儲和流基礎架構的工作的問題。數據基礎架構團隊可以擁有並提供域發現，處理，存儲和服務其數據產品所需的必要技術。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/c0\/c09aa0edce29470bba9b079e05dc75a8.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖11：提取和收集與領域無關的數據管道基礎架構，並將工具構建到作爲平臺的獨立數據基礎架構中"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"將數據基礎架構構建爲平臺的關鍵是（a）不包含任何特定於領域的概念或業務邏輯，使其保持領域不可知性；以及（b）確保平臺隱藏了所有潛在的複雜性和提供了數據基礎架構組件自助服務的方式。自助數據基礎架構作爲平臺向用戶（領域的數據工程師）提供的功能種類繁多。這裏有幾個："}]},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"可擴展的多語言大數據存儲"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"加密靜態和動態數據"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據產品版本控制"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據產品架構"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據產品去識別"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"統一的數據訪問控制和記錄"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據管道的實現和編排"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據產品發現，目錄註冊和發佈"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據治理與標準化"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據產品沿襲"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據產品監控\/報警\/日誌"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據產品質量指標（收集和共享）"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"內存中數據緩存"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"聯合身份管理"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"計算和數據局部性"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"自助數據基礎架構的成功標準是減少“創建新數據產品的時間”。這將引導“數據產品”功能所需的自動化，這在“將領域數據作爲產品”部分中進行了介紹。例如，通過配置和腳本自動執行數據提取，將腳手架放置在適當位置的數據產品創建腳本，在目錄中自動註冊數據產品等。使用雲基礎架構作爲基礎可以減少運營成本和工作量，但是，它並沒有完全消除需要在業務環境中放置的更高的抽象。無論雲提供商如何，數據基礎架構團隊都可以使用一組豐富且不斷增長的數據基礎結構服務。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"向數據網格轉移的範式"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"讀了這麼久了，讓我們總結一下。我們研究了當前數據平臺的一些基本特徵：中心式，單體式，高度耦合的管道架構，由超專業數據工程師的獨立操作。我們介紹了作爲平臺的無處不在的數據網格的構建模塊；面向領域的分佈式數據產品，由獨立的跨職能團隊擁有，這些團隊具有嵌入式數據工程師和數據產品所有者，使用通用數據基礎結構作爲承載，準備和服務其數據資產的平臺。數據網格平臺是經過精心設計的分佈式數據體系結構，在集中管理和標準化下實現了互操作性，並通過共享和統一的自助式數據基礎結構實現了此功能。我希望，它與無法訪問的數據零散孤島的景象不同。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.geekbang.org\/infoq\/a4\/a4e3f077e46cc36e38ec4b99f890dfe9.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"圖12：俯視數據網格架構"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"那麼，數據湖或數據倉庫在此體系結構中適合什麼位置？它們只是網格上的節點。我們很有可能不需要數據湖，因爲保存原始數據的分佈式日誌和存儲是可用與從作爲產品的不同的、可尋址的、不可變的數據集中作爲產品中進行探索。但是，如果我們確實需要更改數據的原始格式以進行進一步的探索（例如標記），則有此需求的領域可能會創建自己的湖泊或數據中心。因此，數據湖不再是整個體系結構的核心。我們將繼續應用一些數據湖的原理，例如使不變的數據可用於勘探和分析用途。我們將繼續使用數據湖工具，但是將其用於數據產品的內部實施或作爲共享數據基礎結構的一部分。實際上，這使我們回到了一切的起點：2010年，James Dixon打算將一個數據湖用於單個領域，而多個數據域將形成一個“水上花園”。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"主要轉變是將領域數據產品視爲第一類關注點，而將數據湖工具和管道視爲第二類關注點-即實現細節。這將當前的思維模型從中心化式數據湖轉變爲可以很好地協同工作的數據產品生態系統，即數據網格相同的原則適用於用於業務報告和可視化的數據倉庫。它只是網格上的一個節點，並且可能位於網格的面向消費者的邊緣上。我承認，儘管我看到數據網格實踐已在我的客戶中應用，但企業規模的採用仍然有很長的路要走。我不認爲技術是這裏的侷限性，我們今天使用的所有工具都可以容納多個團隊的分配和所有權。尤其是向批處理和流傳輸以及諸如Apache Beam或Google Cloud Dataflow之類的工具統一的轉變，可以處理多種類型的數據集。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"諸如Google Cloud Data Catalog之類的數據目錄平臺提供了中心化的可發現性，訪問控制和分佈式領域數據集的治理。多種雲數據存儲選項使領域數據產品可以選擇適合用途的多語言存儲。需求是真實的，工具已經準備就緒。這需要組織的工程師和領導者來認識到，僅使用新的基於雲的工具，現有的大數據範例和一個真正的大數據平臺或數據湖就只會重複過去的失敗。這種範式轉換需要一套新的管理原則以及一種新的語言："}]},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"服務而不是提取"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"發現和使用而不是提取和載入"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"發佈事件流而不是利用中心化的管道來管理數據"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據產品生態而不是中心化數據平臺"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"讓我們將大數據單體分解爲一個統一，協作和分佈式的數據網格生態系統。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"本文轉載自：ThoughtWorks洞見（ID：TW-Insights）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"原文鏈接："},{"type":"link","attrs":{"href":"https:\/\/mp.weixin.qq.com\/s\/I3BHlE8oY06CemW6C06cSw","title":"xxx","type":null},"content":[{"type":"text","text":"從單體數據湖到分佈式數據網格"}]}]}]}