1. 要點
1.1. 實現資料質量不能紙上談兵，而獲得“可靠資料”取決於資料分析和工程實踐中的其他幾個要素
1.2. 資料網格以及資料質量適用的地方
1.3. 資料質量在基於雲的資料棧旅程中的作用
1.4. 知識圖譜是更易於訪問資料的關鍵
1.5. 分散式資料架構下的資料發現
1.6. 何時開始進行資料質量控制
2. 為更高的資料質量構建資料網格
2.1. 資料團隊希望找到一種更容易的方法來管理組織日益增長的需求，不論是處理永無止境的即席查詢流，還是透過中央ETL管道處理不同的資料來源
- 2.1.1. 解決孤立的基礎設施侷限性，許多資料團隊正在向更為分散式的“聯邦治理”模型轉移，開始採用資料網格架構
2.2. 資料網格在很多方面都是微服務的資料平臺版本
-
2.2.1. 資料網格是一種資料平臺的架構型別，透過採用面向領域的自助式設計來利用企業中無處不在的資料
-
2.2.2. 資料網格架構的基礎是通用互操作性層，反映了與領域無關的標準，以及可觀測性和治理
-
2.2.3. 資料網格讓團隊能夠跨業務領域來運算元據，但同時能夠跨這些領域進行標準化治理，以保證資料質量
2.3. 資料網格概念利用了Eric Evans的領域驅動設計理論，這是一種靈活、可擴充套件的軟體開發範例，可以將程式碼的結構和語言與其相應的業務領域進行匹配
-
2.3.1. 與在一箇中央資料湖中處理資料的使用、儲存、轉換和輸出的傳統整體資料基礎設施不同
-
2.3.2. 資料網格支援分散式、特定領域的資料使用者並將“資料視為產品”，而每個領域都各自處理自己的資料管道
-
2.3.3. 連線這些領域及相關資料資產之間的紐帶是應用相同語法和資料標準的通用互操作層
2.4. 三個獨立的元件組成
-
2.4.1. 資料來源
-
2.4.2. 資料基礎設施
-
2.4.3. 由職能所有者管理的面向領域的資料管道
2.5. 面向領域的資料所有者和資料管道
-
2.5.1. 資料網格聯合了負責將資料作為產品提供的領域資料所有者之間的資料所有權，同時也促進了跨不同位置的分散式資料之間的通訊
-
2.5.2. 資料基礎設施負責為每個領域提供用於處理資料的解決方案，但領域的任務是管理資料的攝取、清洗與聚合，以生成可供商業智慧應用程式所使用的資料資產
-
2.5.2.1. 每個領域都負責擁有自己的ETL管道，但所有領域都應具有儲存、編錄和維護訪問控制原始資料的能力
-
2.5.2.2. 一旦資料被提供給一個指定的領域並由其轉換，領域所有者就可以利用這些資料來滿足其分析或運營需求
-
2.6. 自助式服務功能
-
2.6.1. 提供自助式資料平臺，允許使用者將技術複雜性抽象化並專注於他們各自的資料用例
-
2.6.2. 在每個領域中維護資料管道和基礎設施所需的工作和技能上的重複
-
2.6.3. 資料網格將與領域無關的資料基礎設施功能收集並提取到一箇中央平臺中，由該平臺來處理資料管道引擎、儲存和資料流基礎設施
-
2.6.4. 每個領域負責利用這些元件來執行自定義的ETL管道，給它們提供必要的支援來輕鬆地服務其資料並真正掌控流程所需的自主權
2.7. 互操作性與通訊標準化
-
2.7.1. 每個領域的底層都是一組通用的資料標準，這些標準有助於在必要時促進領域之間的協作
-
2.7.2. 某些資料都將對多個領域有價值
-
2.7.3. 為了實現跨領域間的協作，資料網格必須在格式、治理、可發現性和後設資料欄位以及其他資料特性方面實現標準化
-
2.7.4. 每個資料領域都必須定義並同意它們將“保證”為消費者提供的SLA和質量措施
3. 為什麼要實施資料網格
3.1. 具有實時資料可用性和流處理功能的資料湖，其目標是從集中式資料平臺攝取、豐富、轉換並提供資料
3.2. 不足
-
3.2.1. 中央ETL管道讓團隊減少了對不斷增長的資料量的控制
-
3.2.2. 隨著每個公司都成為資料公司，不同的資料用例需要不同型別的轉換，這給中央平臺帶來了沉重的負擔
3.3. 面向領域的資料架構（如資料網格）為團隊提供了兩全其美的方法
-
3.3.1. 集中式資料庫（或分散式資料湖）
-
3.3.2. 其中的領域（或業務範圍）負責處理自己的管道
3.4. 資料網格對於擁有300名以上員工的使用雲平臺的公司來說將變得越來越普遍
3.5. 資料架構可以透過分解成更小的、面向領域的元件來最容易地進行擴充套件
3.6. 資料網格為資料所有者提供了更大的自主權和靈活性，促進了更大的資料實驗和創新，同時減輕了資料團隊透過單一管道來滿足每個資料消費者需求的負擔，從而為資料湖的缺點提供瞭解決方案
3.7. 資料網格的自助服務基礎設施作為一個平臺，為資料團隊提供了一種通用的、與領域無關的、通常是自動化的方法，來實現資料標準化、資料產品沿襲、資料產品監控、警報、日誌記錄和資料產品質量指標（也就是資料的收集和共享）
- 3.7.1. 傳統資料架構通常因攝取者和消費者之間缺乏資料標準化而受到阻礙
3.8. 選不選網格
-
3.8.1. 新架構的採用也帶來了對資料網格真正本質以及如何構建資料網格的誤解
-
3.8.2. 處理大量資料來源和需要進行資料實驗（也就是快速轉換資料）的團隊最好考慮利用資料網格
3.9. 計算你的資料網格分數
-
3.9.1. 資料來源的數量
-
3.9.2. 資料團隊的規模
-
3.9.3. 資料領域的數量
-
3.9.4. 資料工程的瓶頸
-
3.9.5. 資料治理
-
3.9.6. 分數越高，則公司的資料基礎設施要求就越複雜和苛刻，而公司就越有可能從資料網格中受益
4. 資料質量在資料網格中的作用
4.1. 可以從單一解決方案構建資料網格嗎
-
4.1.1. 資料網格不是一個技術解決方案，甚至也不是技術的子集，而是我們如何管理和運算元據的組織正規化，由多種不同的技術組成，無論是開源技術還是軟體即服務
-
4.1.2. 你無法僅使用資料庫來構建微服務架構，而且你也不會只使用資料倉儲或商業智慧工具來構建資料網格
-
4.1.3. 資料網格四項基本元素
-
4.1.3.1. 將資料的所有權從一個集中的團隊下放給最適合控制它的人
-
4.1.3.2. 賦予這些團隊長期的責任感，並讓他們具備將資料視為產品的思維
-
4.1.3.3. 為團隊提供自助式資料基礎設施
-
4.1.3.4. 解決新的聯合資料治理模型可能出現的新問題
-
4.1.3.5. 確保你的資料網格從一開始就走上正確的道路
-
4.2. 資料網格是資料虛擬化的另一種表達嗎
-
4.2.1. 允許應用程式跨多個資料孤島來檢索和運算元據
-
4.2.2. 預測分析和對歷史趨勢進行建模需要的都是截然不同的資料檢視
-
4.2.3. 虛擬化位於OLTP系統和微服務或運營型資料庫之上，並按原樣公開該資料，或只是進行一些小的轉換
4.3. 每個資料產品團隊是否管理自己獨立的資料儲存
-
4.3.1. 資料儲存通常由一箇中央資料工程或資料基礎設施團隊來維護，該團隊負責確保資料網格在每個領域中都能正常執行
-
4.3.2. 不是管理資料基礎設施的人，而這些基礎設施才能讓資料分析、資料科學和機器學習成為可能
4.4. 自助式資料平臺與分散式資料網格是一回事嗎
-
4.4.1. 資料平臺經常被最佳化用於與資料網格無關的目的
-
4.4.2. 支援資料網格所構建的資料平臺若要被最佳化，應當賦予業務領域團隊自主權，並賦予通才技術人員建立資料產品的能力
-
4.4.3. 資料平臺應該讓團隊能夠擁有端到端地管理資料的能力，並直接服務於資料消費者，即資料分析師、資料科學家和其他終端使用者
4.5. 資料網格適用於所有的資料團隊嗎
-
4.5.1. 資料網格的早期採用者往往以工程為重點，並且願意投資“構建和購買技術，因為並不是所有元素都可以買到的”
-
4.5.2. 如果你的利益相關方在尋找和使用正確的資料方面遇到問題，並且創新週期正在放緩，那麼你可能是考慮採用資料網格的恰當人選
4.6. 團隊中的某個人會“擁有”資料網格嗎
-
4.6.1. 整個組織的文化支援
-
4.6.2. 當組織的首席資料官或首席資料分析官直接向CEO彙報時，該組織在大規模採用資料網格時通常會更有效
-
4.6.3. 當你嘗試在組織中採用資料網格時，你的團隊需要獲得1～3個與該願景相一致的業務領域的支援，作為推動設計和實施資料網格向前發展的倡導者
4.7. 資料網格是否會引起資料工程師和資料分析師之間的摩擦
-
4.7.1. 由於資料網格要求下放資料所有權，因此採用這種分散式的、面向領域的模型通常會在此前曾存在摩擦的領域帶來良好的協調
-
4.7.2. 資料網格的資料治理通用標準可以確保各方在圍繞資料質量、資料發現、資料產品模式以及資料健康和理解的其他關鍵要素方面能夠達成一致
-
4.7.3. 自助式服務功能
-
4.7.3.1. 靜態和動態資料加密
-
4.7.3.2. 資料產品的版本控制
-
4.7.3.3. 資料產品模式
-
4.7.3.4. 資料產品發現、目錄註冊和釋出
-
4.7.3.5. 資料治理和標準化
-
4.7.3.6. 資料生產沿襲
-
4.7.3.7. 資料產品的監控、警報和日誌記錄
-
4.7.3.8. 資料產品的質量指標
-
4.8. 很多公司應用資料網格概念的時間都比他們意識到的要長
- 4.8.1. 他們只是沒有找到合適的詞來形容它
4.9. 建立一家資料驅動型公司是一場馬拉松，而不是一場短跑
- 4.9.1. 隨著越來越多的組織採用資料網格和分散式架構，在創新、效率和可擴充套件性方面帶來的機會從未如此巨大