1. 資料問責制

1.1. 資料問責制意味著分配一個人來管理一部分資料

1.1.1. 負責人協調其他利益相關者的治理活動
1.1.2. 如果沒有人對相關資料負責，那麼管理資料質量就會很困難
1.1.3. 負責資料的人不一定是資料工程師
1.1.4. 負責人可能由軟體工程師、產品經理或其他角色擔任
1.1.5. 負責人通常不具備維護資料質量所需的所有資源
- 1.1.5.1. 他們與所有接觸資料的人協調，包括資料工程師

1.2. 資料問責制可以發生在各個層面

1.2.1. 問責制可以發生在表或日誌流的級別，但也可以是與出現在多個表中的單個欄位實體一樣的細粒度級別

2. 資料質量

2.1. 資料質量是資料向理想狀態的最佳化

2.2. 資料工程師確保整個資料工程生命週期中的資料質量

2.2.1. 涉及執行資料質量測試，並確保資料符合模式預期、資料完整性和精度

2.3. 準確性

2.3.1. 收集到的資料是否真實？是否有重複值？數值準確嗎？
2.3.2. 任何機器人生成的事件都被錯誤分類為人類存在的資料準確性問題，反之亦然

2.4. 完整性

2.4.1. 記錄是否完整？所有必填欄位都包含有效值嗎？

2.5. 及時性

2.5.1. 記錄是否及時可用？

2.6. 資料質量跨越了人類和技術問題的邊界

2.6.1. 資料工程師需要強大的流程來收集有關資料質量的可操作的人工反饋，並使用技術工具在下游使用者看到之前先檢測出質量問題

2.7. 主資料管理

2.7.1. 主資料是有關業務實體的資料，例如員工、客戶、產品和位置
2.7.2. 主資料管理(Master Data Management，MDM)是構建一致的實體定義（稱為黃金記錄）的實踐
- 2.7.2.1. 黃金記錄協調整個組織及其合作伙伴的實體資料
- 2.7.2.2. MDM是一種透過構建和部署技術工具來促進的業務運營流程

3. DataOps

3.1. DataOps將敏捷方法、DevOps和統計過程控制(Statistical Process Control，SPC)的最佳實踐對映到資料

3.1.1. DevOps旨在提高軟體產品的釋出和質量
3.1.2. DataOps則針對資料產品也是做同樣的事情

3.2. 資料產品與軟體產品的區別在於資料的使用方式

3.2.1. 軟體產品為終端使用者提供特定的功能和技術特性
3.2.2. 資料產品是圍繞合理的業務邏輯和指標建立的，其使用者可以做出決策或構建執行自動化操作的模型

3.3. 資料工程師必須瞭解構建軟體產品的技術方面以及將建立優秀資料產品的業務邏輯、質量和指標

3.4. 實現

3.4.1. 快速創新和實驗，以更快的速度為客戶提供新的見解
3.4.2. 極高的資料質量和極低的錯誤率
3.4.3. 跨複雜的人員、技術和環境陣列進行協作
3.4.4. 結果的清晰測量、監控和透明度

3.5. DataOps是一套文化習慣

3.5.1. 資料工程團隊需要採用與業務溝通和協作、打破孤島、不斷從成功和錯誤中學習以及快速迭代的迴圈
3.5.2. 只有這些文化習慣養成後，團隊才能從技術和工具中獲得最好的結果

3.6. DataOps具有三個核心技術要素：自動化、可觀測性和監控以及事件響應

3.6.1. 建議首先從可觀測性和監控開始，瞭解系統效能，然後新增自動化和事件響應

3.7. 自動化

3.7.1. 自動化可確保DataOps流程的可靠性和一致性，並允許資料工程師快速部署新產品功能和對現有工作流程進行改進
3.7.2. DataOps成熟度較低的組織通常會嘗試使用cron作業來安排資料轉換過程的多個階段
3.7.3. 隨著組織資料成熟度的增長，資料工程師通常會採用編排框架，可能是Airflow或Dagster
3.7.4. 資料工程師意識到Airflow會帶來操作負擔，但編排的好處最終會超過其複雜性
3.7.5. 每個作業都可以在上游資料準備就緒後立即開始，而不是在固定的、預先確定的時間開始

3.8. “擁抱變化”

3.8.1. 並不意味著為了改變而改變，而是以目標為導向的改變

3.9. 可觀測性和監控

3.9.1. 資料是一個無聲的殺手
3.9.2. 可怕的故事是為報告建立資料的系統隨機停止工作，導致報告延遲數天
- 3.9.2.1. 資料團隊在利益相關者詢問為什麼報告延遲或產生陳舊資訊之前並不知情
- 3.9.2.2. 各個利益相關者對核心資料團隊的能力失去了信任，開始了自己的分裂團隊
- 3.9.2.3. 其結果是許多不同的不穩定系統、不一致的報告和孤島
3.9.3. 如果你不觀測和監控你的資料和生成資料的系統，你將不可避免地經歷自己的資料恐怖故事
3.9.4. 可觀測性、監控、日誌記錄、警報和跟蹤對於在資料工程生命週期中提前解決任何問題都是至關重要的

3.10. 事件響應

3.10.1. 使用DataOps的高效資料團隊將能夠快速交付新的資料產品
3.10.2. 資料工程師必須為災難做好準備，以儘可能迅速且有效地做出響應
3.10.3. 資料工程師應該在業務報告問題之前主動發現問題
- 3.10.3.1. 失敗發生了，當利益相關者或終端使用者看到問題時，他們會提出問題
3.10.4. 事件響應既是對事件的追溯響應，也是在事件發生之前主動解決事件

4. 資料架構

4.1. 資料架構反映了支援組織長期資料需求和戰略的資料系統的當前和未來狀態

4.2. 資料工程師應該首先了解業務需求並收集新用例的需求

4.2.1. 資料工程師需要將這些需求轉化為設計新方法去捕獲和提供資料，並在成本和操作簡單性之間取得平衡
4.2.2. 並不意味著資料工程師就是資料架構師，因為兩者通常是兩個獨立的角色

4.3. 如果資料工程師與資料架構師一起工作，則資料工程師應該能夠交付資料架構師的設計並提供架構反饋

5. 編排

5.1. 編排不僅是DataOps的核心流程，也是資料作業工程和部署流程的關鍵部分

5.2. 編排是協調許多作業以儘可能快速且高效地按照預定節奏執行的過程

5.3. 允許編排系統在沒有人為干預的情況下持續感知和監控，並隨時執行在部署的新作業

5.4. 編排系統還構建作業歷史記錄功能、視覺化和警報

5.4.1. 高階編排引擎可以在新的DAG或到DAG新增單個任務時回填

5.5. 編排一直是資料處理的關鍵功能，但除了大公司以外，通常不是最重要的，也不是任何人都可以使用的

5.6. Apache Oozie在21世紀10年代非常流行，但它是為在Hadoop叢集中工作而設計的，很難在更加異構的環境中使用

5.7. Facebook在21世紀00年代後期開發了供內部使用的Dataswarm

5.7.1. 這激發了Airflow等流行工具的靈感，Airbnb於2014年推出了該工具

5.8. Airflow從一開始就是開源的，並被廣泛採用

5.8.1. 它是用Python編寫的，因此可以高度擴充套件到幾乎任何可以想象的用例
5.8.2. Airflow的到來恰逢資料處理變得更加抽象和易於訪問，工程師們對協調跨多個處理器和儲存系統的複雜流程越來越感興趣，尤其是在雲環境中

5.9. 編排嚴格來講是一個批處理的概念

5.9.1. 編排任務DAG的流式替代方案是流式DAG
5.9.2. 流式DAG的構建和維護仍然具有挑戰性，但Pulsar等下一代流式平臺旨在顯著減輕工程和運營負擔

6. 軟體工程

6.1. 軟體工程一直是資料工程師的一項核心技能

6.1.1. 應該精通軟體工程以理解API、提取和轉換資料、處理異常等

6.2. 核心資料處理程式碼仍然需要編寫，並且貫穿於整個資料工程生命週期

6.2.1. 無論是在獲取、轉換還是資料服務方面，資料工程師都需要精通和高效地使用Spark、SQL或Beam等框架和語言

6.3. 重點已經從直接的資料處理轉移到抽象的階梯上

6.4. 流資料處理本質上比批處理更復雜，而且工具和正規化可以說還沒有那麼成熟

6.4.1. 隨著流資料在資料工程生命週期的每個階段變得越來越普遍，資料工程師面臨著有趣的軟體工程問題

6.5. 視窗化允許實時系統計算有價值的指標，如尾隨統計資料

6.5.1. 資料工程師有許多框架可供選擇，包括用於處理單個事件的各種函式平臺(OpenFaaS、AWS Lambda、Google Cloud Functions)或用於分析流以支援報告和實時處理的專用流處理器（Spark、Beam、Flink或Pulsar）

6.6. 基礎設施即程式碼(Infrastructure as Code，IaC)將軟體工程實踐應用於基礎設施的配置和管理

6.7. 流水線即程式碼是當今編排系統的核心概念，它涉及資料工程生命週期的每個階段

6.8. 無論資料工程師採用哪種高階工具，他們都會在整個資料工程生命週期中遇到極端情況，這些情況要求他們解決所選工具範圍之外的問題並編寫自定義程式碼