貝寶：基於DDD的下一代資料平臺是資料網格

資料平臺的演進
在深入瞭解 Data Mesh 的細節之前，讓我們回顧一下資訊行業是如何走到這種境地的。
六千五百萬年前，恐龍……不，我不會及時走那麼遠。1971 年，Edgar Codd 發明了第三正規化，即關聯式資料庫的關鍵。此後不久，企業開始看到聚合資料的好處，這為建立資料倉儲開闢了道路。
資料倉儲帶來了對資料管理更嚴格的需求：您正在為資料建立一個倉庫，因此就像在物流倉庫中一樣，通道、貨架和空間必須明確標識。您必須設計資料倉儲以容納傳入的資料並構建 ETL（提取、轉換和載入）流程來填充倉庫。企業現在能夠執行新維度的分析。不幸的是，倉庫不是很靈活，而且隨著資料來源數量的增加，入職資料變得複雜。
讓我們想象一家零售公司 Great Parts，從事 B2C 和 B2B 活動。他們在北美有幾千家商店，有一個忠誠度計劃，他們接受退貨。

​
圖 1 — 新收據、退貨和新產品的資料流。

現在想象一下 Great Parts 決定將他們的忠誠度計劃擴充套件到 B2B；您將不得不在 B2B 退貨和您的客戶空間之間建立一個 ETL 流程。如果您計劃從您的移動應用程式、Web 應用程式和 B2B 站點新增新的資料來源，例如點選流。它將變得越來越複雜，您將不得不管理 ETL 義大利麵條。
在我們的行業中，Great Parts 決定完全從資料倉儲轉移到資料湖。鐘擺劇烈地移動了。在資料湖中，您收集所需的所有資料並將其儲存。無論在哪裡。你可以看到這是怎麼回事。

​
圖 2 — 在資料湖中攝取資料比使用資料倉儲要容易得多。

現在，當您再次嘗試使用您的資料時，它變得有點棘手。儲存容易，閱讀卻很複雜。
您可以透過為分析負載建立小型資料倉儲（資料庫或資料集市）來訪問資料，但您又回到了 ETL 義大利麵。
在透過微服務進行操作處理時，也是同樣的困境。

​

圖 3 — 從資料湖中獲取價值可能有點棘手。

最近的架構，如資料湖庫，正試圖結合最好的湖和倉庫，但它們仍然缺乏資料質量、治理和自助服務功能，以確保符合企業和監管標準。

機會
不幸的是，對於一些技術人員來說，專案並不是為了技術而發生的。他們受到機遇和挑戰的驅動。貝寶也不例外。讓我們來看看 PayPal 的領導層被認為是一個新的資料平臺所帶來的機會。
PayPal 在自助分析領域處於領先地位，與許多公司相比，它為業務分析師和資料科學家提供了對我們資料倉儲的訪問許可權。這一舉措的成功，加上 PayPal 願意遷移到雲，推動了對不同型別資料平臺的需求。
除了自助服務之外，資料科學家的需求也隨著更多資料發現能力而發展。與許多公司一樣，資料來源有所增加，無論是在內部、透過收購，甚至來自資料提供商等外部來源。
隨著業務變得越來越複雜，主要驅動力是合規性和可審計性的提高，挑戰變成了將大資料、自助服務發現、實驗、合規性和治理結合起來，同時提供從資料實驗到生產的清晰路徑.

我們在 PayPal、GCSC IA（全球信用風險、賣方風險和收款、智慧自動化）的團隊選擇了資料網格正規化，因為它最適合我們的客戶需求。

資料網格的四個原則
2019 年 5 月，傑出的工程師 Zhamak Dehghani 發表了一篇強調資料網格基礎的論文。在她的論文中，Dehghani 為四項原則奠定了基礎，在過去幾年中，這些原則被提煉為資料網格的四項核心原則。我喜歡將這些原則與敏捷宣言如何破壞軟體工程中基於瀑布的生命週期進行比較。資料網格將您可能熟悉的敏捷軟體工程的許多概念引入資料工程。
讓我們一起發現這四個原則。

一、領域所有權原則
在過去的幾十年中，“領域”一詞被過度使用，其含義幾乎是胡言亂語。儘管如此，讓我們嘗試在這種情況下馴服域和所有權。
域是您關注的特定業務領域。如果您從事醫療保健行業，則可以是醫院或放射科等特定部門。識別領域設定邊界並幫助您陷入範圍蔓延的情況（例如，讓我們在專案中也包括醫院自助餐廳）。

如果你熟悉領域驅動開發，這個原則對你來說自然而然。
這是常識：不要試圖煮沸海洋。
找到最瞭解某個領域的人，並將他們與資料架構師聯絡起來。去中心化團隊擁有寶貴的領域專業知識：他們比從一個領域切換到另一個領域的中心化團隊更瞭解資料來源、資料生產者、規則、歷史和系統的演變。在組合中新增資料架構師將帶來安全性、規則和全球治理，以保持與企業策略的合規性。

二. 資料即產品原則
在軟體工程中，敏捷用產品代替了專案。資料成為一體只是時間問題。讓我們看看資料產品能帶來什麼。
專注於資料產品將使您能夠從專案規劃的角度轉變為以客戶為中心的方法。令人生畏？不，只是 DAUNTIVS，資料產品必須是：

• 可發現，
• 可定址，
• 可以理解，
• 原生可訪問，
• 誠實守信，
• 可互操作和可組合，
• 本身就有價值，並且
• 安全的。

​
圖 5 — 資料量呈六邊形，突出顯示其多個端點，允許訪問資料、後設資料、可觀察性和控制。

您可能想知道，“嘿，這與我使用幾個資料治理工具的資料湖有何不同？” 答案是規模很重要：您專注於單個域，而不是整個企業級湖。它絕對是更多的“位元組大小”和可咀嚼的。
由於其規模和範圍更小，實施速度更快，資料價值在公司中重新注入的速度也更快。

三、自助資料平臺原理
當我還是個孩子的時候，在法國，我喜歡和父母一起去當地的超市，因為那裡有一個自助餐廳，我可以把我想要的所有食物放在托盤上。自助服務使我能夠做出（糟糕的）食物選擇。但是，當涉及到資料平臺時，這意味著什麼？
自 2001 年成立以來，敏捷已被證明是一種有效的方法。敏捷軟體工程賦予軟體工程師權力。賦予資料科學家權力的方法是讓他們訪問資料。
資料科學家和分析師在資料發現階段花費（太多）時間。在許多情況下，他們會在某個表的某個隨機列中找到一條資料，並押注這就是他們需要的事實。有時它有效，有時你的 PB&J 吐司不會掉在果凍的一邊。
賦予資料科學家權力意味著您不僅必須讓他們訪問基本的欄位目錄，還要讓他們訪問精確的定義、主動和被動後設資料、反饋迴圈等等。他們是你的顧客，你想成為這個 5 星級 Yelp 自助餐廳，而不是這個糟糕的 1 星級小屋。

四. 聯邦計算治理原則
這個原則的每一個字都有非常重要的意義。讓我試著向你傳達他們的重要解釋。
資訊科技在我們的日常生活中變得無處不在。各州和政府已制定法律來管理個人資料的處理和使用方式。著名的例子包括歐洲的 GDPR (2016)、加利福尼亞的 CCPA (2018) 和法國的國家資訊與自由委員會 (1978)。當然，這些限制並不是企業治理的唯一推動力。像 PayPal 這樣的公司通常有可能超出法律要求的資料治理規則和保護措施。
但是為什麼要推動計算治理而不僅僅是資料治理呢？因為資料治理太侷限了。即使您在治理中包含後設資料（當然您也這樣做了），您仍然缺少與您的系統相關聯的整個計算資源生態系統。在基於雲的現代世界中，您必須考慮更多資產。從資料擴充套件到計算治理是有意義的。
您的資料治理團隊建立適用於整個組織的策略，域團隊將遵循這些策略來實現企業級的一致性和合規性。然而，領域團隊擁有量子級別的本地治理，最大限度地發揮團隊的專業知識。

四大原則
就像大仲馬的四個火槍手一樣，資料網格的四個原則是相互交織的。
每個原則相互影響，在設計和構建資料網格時，不能孤立地看待一個原則：您需要同時在四個方面取得進展。這比看起來容易，因為您將看到 PayPal 如何構建這樣的資料網格。

​
圖 6 - 將一個原則的影響對映到其他原則的嘗試。

構建我們的第一個資料量子
既然您已經閱讀了有關動機、機會和管理原則的內容，似乎是時候構建您的第一個資料量子了，或者更準確地說，是在實施之前對其進行架構。
在構建整個資料網格之前，您需要關注每個資料量。資料網格是資料量子的組合。

​
圖 7 — 展開資料量子，裡面是什麼？

您可以將資料量子劃分為五個子元件： • 字典， • 可觀察性平面， • 控制平面， • 資料載入，以及 • 可互操作的資料。

字典介面是您被動後設資料的寶貴芝麻。您的資料量子使用者無需身份驗證即可連線到字典。然後，他們的資料發現被極大地簡化，因為他們可以以非常互動的方式瀏覽字典，而無需特定許可權、額外描述和對資料沿襲的訪問。當他們找到他們需要的東西時，他們可以輕鬆地檢查他們是否有權訪問或請求訪問資料。

可觀察性平面在資料量子的內建可觀察性和 REST 客戶端之間提供了一個介面。這允許資料科學家衡量資料量中的資料質量，並確定資料量是否符合他們的 SLO（服務水平目標）預期。

控制平面提供對 REST API 的訪問，您可以在其中控制載入和資料儲存。如果您想在資料量子中建立資料集的新版本，那麼可以使用 API 呼叫。您是否需要控制應在資料載入中應用哪些資料質量規則？有一個 API 呼叫。該介面主要面向管理資料量的資料工程師。
可以想象，對於每個資料量子來說，這三組 API 都是相似的：不需要為每個資料量學習新的 API。為了簡化您的使用，您可以將您的 REST API 包裝在一個可透過筆記本訪問的 Python API 中。

資料載入元件是您使用類固醇的舊資料管道。在許多（如果不是全部）資料網格之前的資料工程專案中，重點是資料管道。資料網格將管道放回原處。管道很重要，但它是資料載入的一個元素，例如可觀察性或應用程式資料質量規則。在這個元件中新增所有這些功能可以保護經典的、經常失敗的、脆弱的 ETL 過程。是的，管道是球隊四分衛的日子已經過去了。

最後但並非最不重要的一點是，可互操作模型是以可消費的方式為您提供關鍵資料。我可以將此元件表示為您可以在舊架構圖中看到的經典圓柱體，但請記住，資料量子公開的資料並不總是相關的。

資料量子的承諾是將應用程式與資料分離。這會對資料量子內部的資料建模產生影響。

歡迎來到資料網格
到目前為止，您已經瞭解了很多關於資料量子（複數：data quanta）的知識。希望您能看到資料量子的價值，但是資料網格會給大量資料量子帶來什麼額外價值呢？
一組資料合約管理每個資料量：主資料合約定義了資料量與其使用者之間的關係。它還描述了可互操作模型和 SLA（服務級別協議）的詳細資訊。這種面向消費者的資料合約也可以稱為輸出或使用者資料合約。
圖 8 說明了資料契約的作用。一個資料量子可能有多個資料合約作為輸入，併為其消費者提供一個資料合約。

​
圖 8——資料契約的重要性：它定義了生產者和消費者的關係。

當資料量已網格化時，如圖 9 所示，生成的資料量會從源資料量繼承資料契約。這種機制簡化了互操作性、提高了資料質量並縮短了上市時間。

當您閱讀本文時，我們的團隊正在應對這一挑戰。

​

圖 9 - 網格化資料量增加了資料網格的交付值，而不會影響資料新鮮度。

挑戰
構建資料量子的道路充滿了好主意，但魔鬼顯然在實施中。
不過，這裡有一些建議可以幫助您入門。
與任何顛覆性技術和方法一樣，準備好引導您的使用者完成這一過渡。許多資料工程師生活在神聖不可侵犯的資料管道中，將他們的偶像簡化為網格中的一個元件可能會令人痛苦。
讓你的領導層為建立新平臺做好準備：他們不應該在你開始兩週（甚至三週……）後期待結果。
與所有產品開發一樣，清楚地確定您的使用者是誰以及他們當前使用的工具。您可能需要轉換或擴充套件他們的工具，這可能會產生摩擦和阻力。
事實是那裡沒有“資料網格產品”。可能有可以組裝的磚塊、元素或元件來幫助您構建網格（Spark 仍然是一個出色的引擎，可以大規模執行您的資料轉換——等等）。然而，沒有什麼能比得上 OTS（現成的）平臺，無論是商業的還是開源的。
該領域缺乏軟體供應商促進了創新，但同樣混亂。接下來的幾個月將告訴我們，我們是否在使用者體驗、技術選擇和實施方面做出了正確的選擇。

Jean-Georges “jgp” Perrin 是 PayPal 專注於構建創新和現代資料平臺的技術領導者，AIDAUG 總裁，Spark in Action, 2nd edition (Manning) 的作者。