讀資料工程之道：設計和構建健壯的資料系統05底層設計（上）

1. 主要底層設計

1.1. 以前的資料工程週期只關注技術層，而工具和實踐的持續抽象和簡化已經改變了這一重點

1.2. 資料工程現在包含的不僅僅是工具和技術

• 1.2.1. 該領域現在正在向價值鏈上游移動，將資料管理和成本最佳化等傳統企業實踐與DataOps等新實踐相結合

1.3. 底層設計

• 1.3.1. 安全

• 1.3.2. 資料管理

• 1.3.3. DataOps

• 1.3.4. 資料架構

• 1.3.5. 編排

• 1.3.6. 軟體工程

2. 安全

2.1. 安全是第一個底層設計的原因

• 2.1.1. 安全必須是資料工程師的首要考慮因素，忽視安全的人將會面臨危險

2.2. 資料工程師必須瞭解資料和訪問安全，運用最小特權原則

• 2.2.1. 最小特權原則意味著只允許使用者或系統訪問基本資料和資源以執行預期的功能

• 2.2.2. 我們在缺少安全經驗的資料工程師身上看到的一個常見反模式是向所有使用者授予管理員訪問許可權

• 2.2.3. 只為使用者提供他們今天完成工作所需的訪問許可權

• 2.2.4. 查詢具有較小角色的表時，不要使用資料庫中的超級使用者角色

• 2.2.5. 將最小特權原則強加給我們自己可以防止意外損壞，並使你保持安全第一的心態

2.3. 資料工程師必須是稱職的安全管理員，因為安全屬於他們的領域

• 2.3.1. 資料工程師應該瞭解雲和本地部署的安全最佳實踐

• 2.3.2. 瞭解使用者和身份訪問管理(Identity Access Management，IAM)角色、策略、組、網路安全、密碼策略和加密是很好的起點

2.4. 人和組織結構始終是任何公司中最大的安全漏洞

• 2.4.1. 往往會發現公司中有人忽視了基本的預防措施，成為網路釣魚攻擊的受害者，或者採取了其他不負責任的行為

2.5. 資料安全的第一道防線是建立一種貫穿整個組織的安全文化

• 2.5.1. 所有有權訪問資料的個人都必須瞭解他們在保護公司敏感資料及其客戶方面的責任

2.6. 資料安全還與時間有關

• 2.6.1. 為需要訪問資料的人和系統提供資料訪問許可權，並且僅在執行工作所需的時間內提供資料訪問許可權

• 2.6.2. 應透過使用加密、令牌化、資料遮蔽、混淆和簡單、強大的訪問控制來保護資料，使資料無論是在執行中還是在靜止狀態都不可見

3. 資料管理

3.1. 資料管理已經存在了幾十年，但直到最近才在資料工程中得到很大的關注

• 3.1.1. 資料治理、主資料管理、資料質量管理、後設資料管理

• 3.1.2. 資料工具變得越來越簡單，資料工程師要管理的複雜性也越來越低

3.2. 資料工程師管理資料生命週期，而資料管理包含資料工程師將用於在技術和戰略上完成此任務的一組最佳實踐

• 3.2.1. 如果沒有管理資料的框架，資料工程師只是在真空中操作的技術人員

• 3.2.2. 資料工程師需要更廣泛地瞭解資料在整個組織中的效用，從源系統到最高管理層，以及兩者之間的所有地方

3.3. 資料管理表明資料對日常運營至關重要，就像企業將財務資源、成品或房地產視為資產一樣

3.4. 資料管理實踐形成了一個每個人都可以採用的有凝聚力的框架，以確保組織從資料中獲取價值並適當地處理它

3.5. 內容

• 3.5.1. 資料治理，包括可發現性和問責制

  • 3.5.1.1. 資料治理首先是一種資料管理功能，可確保組織收集的資料的質量、完整性、安全性和可用性

  • 3.5.1.2. 有效的資料治理是有目的的開發並得到組織的支援

  • 3.5.1.3. 資料治理是資料驅動業務實踐的基礎，也是資料工程生命週期的一個關鍵任務部分

  • 3.5.1.4. 當資料治理得到很好的實踐時，人、流程和技術就會協調一致，將資料視為關鍵的業務驅動力，如果資料問題出現，則會及時得到處理

  • 3.5.1.5. 資料治理的核心類別是可發現性、安全性和可問責性

    3.5.1.5.1. 發現性

    3.5.1.5.1.1. 在資料驅動型公司中，資料必須可用且可發現

    3.5.1.5.1.2. 終端使用者應該能夠快速可靠地訪問他們完成工作所需的資料

    3.5.1.5.1.3. 他們應該知道資料的來源、資料與其他資料的關係，以及資料的含義

• 3.5.2. 資料建模和設計

  • 3.5.2.1. 為了透過業務分析和資料科學從資料中獲得業務洞察力，資料必須採用可用的形式

  • 3.5.2.2. 將資料轉換為可用形式的過程稱為資料建模和設計

    3.5.2.2.1. 韌體工程師為IoT裝置開發記錄的資料格式

    3.5.2.2.2. Web應用程式開發人員設計對API呼叫

    3.5.2.2.3. MySQL表模式的JSON響應

  • 3.5.2.3. 由於新資料來源和用例的多樣性，資料建模變得更具挑戰性

• 3.5.3. 資料血緣

  • 3.5.3.1. 資料血緣描述了資料在其生命週期中的審計跟蹤記錄，跟蹤處理資料的系統和它所依賴的上游資料

  • 3.5.3.2. 資料血緣有助於資料和處理資料的系統進行錯誤跟蹤、問責和除錯

  • 3.5.3.3. 具有為資料生命週期提供審計跟蹤的明顯好處，並有助於合規性

  • 3.5.3.4. 資料血緣在具有嚴格合規標準的大公司中已經存在了很長時間

  • 3.5.3.5. 資料可觀測性驅動開發(Data，Observability Driven Development，DODD)

    3.5.3.5.1. DODD一直觀測其血緣的資料

    3.5.3.5.2. DODD的目的是讓資料鏈中的每個人都能看到資料和資料應用程式，以便資料價值鏈中的每個人都能夠從獲取到轉換再到分析的每個步驟中識別資料或資料應用程式的變化，以幫助解決或防止資料問題

    3.5.3.5.3. DODD專注於使資料可觀測性成為資料工程生命週期中的首要考慮因素

  • 3.5.3.6. 在開發、測試和最終生產過程中應用此過程，以提供符合預期的質量和一致性

• 3.5.4. 儲存和操作

• 3.5.5. 資料整合和互操作性

  • 3.5.5.1. 資料整合和互操作性是跨工具和流程的整合資料的過程

  • 3.5.5.2. 隨著我們從單一棧分析方法轉向異構雲環境，該環境中的各種工具按需處理資料，整合和互操作性佔據了資料工程師工作的越來越大的比重

  • 3.5.5.3. 整合越來越多地透過通用API而不是自定義資料庫連線進行

  • 3.5.5.4. 透過與人的資料系統對話的相對簡單的Python程式碼來管理，而不是直接處理資料

• 3.5.6. 資料生命週期管理

  • 3.5.6.1. 資料湖的出現鼓勵組織忽視資料歸檔和銷燬

  • 3.5.6.2. 資料越來越多地儲存在雲端

    3.5.6.2.1. 味著我們有即付即得的儲存成本，而不是本地資料湖的大量前期資本支出

  • 3.5.6.3. GDPR和CCPA等隱私和資料保留法律要求資料工程師積極管理資料銷燬，以尊重使用者的“被遺忘權”​

    3.5.6.3.1. 資料工程師必須知道他們保留了哪些消費者資料，並且必須具有銷燬資料的程式以響應請求和合規性要求

  • 3.5.6.4. 資料銷燬在雲資料倉儲中很簡單

    3.5.6.4.1. SQL語義允許刪除符合where子句的行

    3.5.6.4.2. 資料銷燬在資料湖中更具挑戰性，其中一次寫入、多次讀取是預設的儲存模式

    3.5.6.4.3. Hive ACID和Delta Lake等工具可以允許大規模刪除事務的輕鬆管理

  • 3.5.6.5. 新一代後設資料管理、資料血緣和編目工具也將簡化資料工程生命週期的結束

• 3.5.7. 用於高階分析和機器學習的資料系統

• 3.5.8. 道德與隱私

  • 3.5.8.1. 資料會影響人

  • 3.5.8.2. 資料工程師需要在沒人注視的時候做正確的事，因為總有一天每個人都會關注

  • 3.5.8.3. 資料工程師需要確保資料集掩蓋個人身份資訊(Personally Identifiable Information，PII)和其他敏感資訊，可以在轉換資料集時識別和跟蹤偏見

4. 後設資料

4.1. 後設資料是“關於資料的資料”​，它支撐著資料工程生命週期的每個部分

• 4.1.1. 後設資料正是使資料可發現和可治理所需的資料

4.2. 自動生成的和人工生成的

• 4.2.1. 現代資料工程圍繞自動化展開，但後設資料收集通常是手動的且容易出錯

• 4.2.2. 自動化後設資料工具不應將人完全排除在外

• 4.2.3. 工具可以爬資料庫以查詢關係並監控資料管道以跟蹤資料的來源和去向

4.3. 低保真手動方法使用內部主導的努力，其中各種利益相關者在組織內眾包後設資料收集

4.4. 後設資料成為資料和資料處理的副產品

• 4.4.1. 後設資料工具的好壞取決於它們與資料系統的聯結器及其共享後設資料的能

4.5. 資料具有社會元素

• 4.5.1. 每個組織都在積累社會資本和關於流程、資料集與管道的知識

• 4.5.2. 以人為本的後設資料系統關注後設資料的社會方面

4.6. 文件和內部wiki工具為後設資料管理提供了重要基礎，但這些工具還應該與自動資料編目相整合

• 4.6.1. 應提供一個公開資料所有者、資料消費者和領域專家的場所

4.7. 業務後設資料

• 4.7.1. 業務後設資料與資料在業務中的使用方式相關，包括業務和資料定義、資料規則和邏輯、資料的使用方式和位置，以及資料所有者

• 4.7.2. 業務後設資料為資料工程師提供正確的上下文和定義以正確使用資料

4.8. 技術後設資料

• 4.8.1. 技術後設資料描述了系統在整個資料工程生命週期中建立和使用的資料

• 4.8.2. 包括資料模型和架構、資料血緣、欄位對映和管道工作流

• 4.8.3. 資料工程師使用技術後設資料在資料工程生命週期中建立、連線和監控各種系統

• 4.8.4. 技術後設資料型別

  • 4.8.4.1. 管道後設資料（通常在編排系統中產生）

    4.8.4.1.1. 編排是協調跨各種系統的工作流的中央樞紐

    4.8.4.1.2. 編排系統可以提供操作後設資料的有限情況，但後者仍然傾向於分散在許多系統中

    4.8.4.1.3. 在編排系統中捕獲的管道後設資料提供了工作流計劃、系統和資料依賴性、配置、連線細節等的詳細資訊

  • 4.8.4.2. 資料血緣後設資料

    4.8.4.2.1. 資料血緣後設資料跟蹤資料隨著時間的推移的起源和變化，以及它的依賴性

    4.8.4.2.2. 隨著資料流經資料工程生命週期，它會透過轉換和與其他資料的組合而不斷髮展

    4.8.4.2.3. 資料血緣提供了資料在各種系統和工作流中移動時演變的審計線索

  • 4.8.4.3. 模式後設資料

    4.8.4.3.1. 模式後設資料描述了儲存在資料庫、資料倉儲、資料湖或檔案系統等系統中的資料結構

    4.8.4.3.2. 是不同儲存系統的關鍵區別之一

    4.8.4.3.3. 模式後設資料必須在後設資料儲存中進行管理

    4.8.4.3.4. 雲資料倉儲在內部管理模式後設資料

  • 4.8.4.4. 操作後設資料

    4.8.4.4.1. 操作後設資料描述了各種系統的執行結果，包括程序統計、作業ID、應用程式執行日誌、程序中使用的資料和錯誤日誌

    4.8.4.4.2. 資料工程師使用操作後設資料來確定流程是成功還是失敗，以及流程中涉及的資料

    4.8.4.4.3. 對更高質量的操作後設資料和更好的後設資料管理的需求是下一代編排和後設資料管理系統的主要動機

  • 4.8.4.5. 參考後設資料

    4.8.4.5.1. 參考後設資料是用於對其他資料進行分類的資料，也稱為查詢資料

    4.8.4.5.2. 參考資料的標準示例是內部程式碼、地理程式碼、測量單位和內部日曆標準

    4.8.4.5.3. 大部分參考資料完全在內部管理，但地理程式碼等專案可能來自標準外部參考

    4.8.4.5.4. 參考資料本質上是解釋其他資料的標準，因此如果它發生變化，則這種變化會隨著時間慢慢發生