1. 數(shù)據(jù)問責制
1.1. 數(shù)據(jù)問責制意味著分配一個人來管理一部分數(shù)據(jù)
1.1.1. 負責人協(xié)調(diào)其他利益相關(guān)者的治理活動
1.1.2. 如果沒有人對相關(guān)數(shù)據(jù)負責，那么管理數(shù)據(jù)質(zhì)量就會很困難
1.1.3. 負責數(shù)據(jù)的人不一定是數(shù)據(jù)工程師
1.1.4. 負責人可能由軟件工程師、產(chǎn)品經(jīng)理或其他角色擔任
-
1.1.5. 負責人通常不具備維護數(shù)據(jù)質(zhì)量所需的所有資源
- 1.1.5.1. 他們與所有接觸數(shù)據(jù)的人協(xié)調(diào)，包括數(shù)據(jù)工程師
1.2. 數(shù)據(jù)問責制可以發(fā)生在各個層面
- 1.2.1. 問責制可以發(fā)生在表或日志流的級別，但也可以是與出現(xiàn)在多個表中的單個字段實體一樣的細粒度級別
2. 數(shù)據(jù)質(zhì)量
2.1. 數(shù)據(jù)質(zhì)量是數(shù)據(jù)向理想狀態(tài)的優(yōu)化
2.2. 數(shù)據(jù)工程師確保整個數(shù)據(jù)工程生命周期中的數(shù)據(jù)質(zhì)量
- 2.2.1. 涉及執(zhí)行數(shù)據(jù)質(zhì)量測試，并確保數(shù)據(jù)符合模式預期、數(shù)據(jù)完整性和精度
2.3. 準確性
2.3.1. 收集到的數(shù)據(jù)是否真實？是否有重復值？數(shù)值準確嗎？
2.3.2. 任何機器人生成的事件都被錯誤分類為人類存在的數(shù)據(jù)準確性問題，反之亦然
2.4. 完整性
- 2.4.1. 記錄是否完整？所有必填字段都包含有效值嗎？
2.5. 及時性
- 2.5.1. 記錄是否及時可用？
2.6. 數(shù)據(jù)質(zhì)量跨越了人類和技術(shù)問題的邊界
- 2.6.1. 數(shù)據(jù)工程師需要強大的流程來收集有關(guān)數(shù)據(jù)質(zhì)量的可操作的人工反饋，并使用技術(shù)工具在下游用戶看到之前先檢測出質(zhì)量問題
2.7. 主數(shù)據(jù)管理
2.7.1. 主數(shù)據(jù)是有關(guān)業(yè)務實體的數(shù)據(jù)，例如員工、客戶、產(chǎn)品和位置
-
2.7.2. 主數(shù)據(jù)管理(Master Data Management，MDM)是構(gòu)建一致的實體定義（稱為黃金記錄）的實踐
2.7.2.1. 黃金記錄協(xié)調(diào)整個組織及其合作伙伴的實體數(shù)據(jù)
2.7.2.2. MDM是一種通過構(gòu)建和部署技術(shù)工具來促進的業(yè)務運營流程
3. DataOps
3.1. DataOps將敏捷方法、DevOps和統(tǒng)計過程控制(Statistical Process Control，SPC)的最佳實踐映射到數(shù)據(jù)
3.1.1. DevOps旨在提高軟件產(chǎn)品的發(fā)布和質(zhì)量
3.1.2. DataOps則針對數(shù)據(jù)產(chǎn)品也是做同樣的事情
3.2. 數(shù)據(jù)產(chǎn)品與軟件產(chǎn)品的區(qū)別在于數(shù)據(jù)的使用方式
3.2.1. 軟件產(chǎn)品為終端用戶提供特定的功能和技術(shù)特性
3.2.2. 數(shù)據(jù)產(chǎn)品是圍繞合理的業(yè)務邏輯和指標建立的，其用戶可以做出決策或構(gòu)建執(zhí)行自動化操作的模型
3.3. 數(shù)據(jù)工程師必須了解構(gòu)建軟件產(chǎn)品的技術(shù)方面以及將創(chuàng)建優(yōu)秀數(shù)據(jù)產(chǎn)品的業(yè)務邏輯、質(zhì)量和指標
3.4. 實現(xiàn)
3.4.1. 快速創(chuàng)新和實驗，以更快的速度為客戶提供新的見解
3.4.2. 極高的數(shù)據(jù)質(zhì)量和極低的錯誤率
3.4.3. 跨復雜的人員、技術(shù)和環(huán)境陣列進行協(xié)作
3.4.4. 結(jié)果的清晰測量、監(jiān)控和透明度
3.5. DataOps是一套文化習慣
3.5.1. 數(shù)據(jù)工程團隊需要采用與業(yè)務溝通和協(xié)作、打破孤島、不斷從成功和錯誤中學習以及快速迭代的循環(huán)
3.5.2. 只有這些文化習慣養(yǎng)成后，團隊才能從技術(shù)和工具中獲得最好的結(jié)果
3.6. DataOps具有三個核心技術(shù)要素：自動化、可觀測性和監(jiān)控以及事件響應
- 3.6.1. 建議首先從可觀測性和監(jiān)控開始，了解系統(tǒng)性能，然后添加自動化和事件響應
3.7. 自動化
3.7.1. 自動化可確保DataOps流程的可靠性和一致性，并允許數(shù)據(jù)工程師快速部署新產(chǎn)品功能和對現(xiàn)有工作流程進行改進
3.7.2. DataOps成熟度較低的組織通常會嘗試使用cron作業(yè)來安排數(shù)據(jù)轉(zhuǎn)換過程的多個階段
3.7.3. 隨著組織數(shù)據(jù)成熟度的增長，數(shù)據(jù)工程師通常會采用編排框架，可能是Airflow或Dagster
3.7.4. 數(shù)據(jù)工程師意識到Airflow會帶來操作負擔，但編排的好處最終會超過其復雜性
3.7.5. 每個作業(yè)都可以在上游數(shù)據(jù)準備就緒后立即開始，而不是在固定的、預先確定的時間開始
3.8. “擁抱變化”
- 3.8.1. 并不意味著為了改變而改變，而是以目標為導向的改變
3.9. 可觀測性和監(jiān)控
3.9.1. 數(shù)據(jù)是一個無聲的殺手
-
3.9.2. 可怕的故事是為報告創(chuàng)建數(shù)據(jù)的系統(tǒng)隨機停止工作，導致報告延遲數(shù)天
3.9.2.1. 數(shù)據(jù)團隊在利益相關(guān)者詢問為什么報告延遲或產(chǎn)生陳舊信息之前并不知情
3.9.2.2. 各個利益相關(guān)者對核心數(shù)據(jù)團隊的能力失去了信任，開始了自己的分裂團隊
3.9.2.3. 其結(jié)果是許多不同的不穩(wěn)定系統(tǒng)、不一致的報告和孤島
3.9.3. 如果你不觀測和監(jiān)控你的數(shù)據(jù)和生成數(shù)據(jù)的系統(tǒng)，你將不可避免地經(jīng)歷自己的數(shù)據(jù)恐怖故事
3.9.4. 可觀測性、監(jiān)控、日志記錄、警報和跟蹤對于在數(shù)據(jù)工程生命周期中提前解決任何問題都是至關(guān)重要的
3.10. 事件響應
3.10.1. 使用DataOps的高效數(shù)據(jù)團隊將能夠快速交付新的數(shù)據(jù)產(chǎn)品
3.10.2. 數(shù)據(jù)工程師必須為災難做好準備，以盡可能迅速且有效地做出響應
-
3.10.3. 數(shù)據(jù)工程師應該在業(yè)務報告問題之前主動發(fā)現(xiàn)問題
- 3.10.3.1. 失敗發(fā)生了，當利益相關(guān)者或終端用戶看到問題時，他們會提出問題
3.10.4. 事件響應既是對事件的追溯響應，也是在事件發(fā)生之前主動解決事件
4. 數(shù)據(jù)架構(gòu)
4.1. 數(shù)據(jù)架構(gòu)反映了支持組織長期數(shù)據(jù)需求和戰(zhàn)略的數(shù)據(jù)系統(tǒng)的當前和未來狀態(tài)
4.2. 數(shù)據(jù)工程師應該首先了解業(yè)務需求并收集新用例的需求
4.2.1. 數(shù)據(jù)工程師需要將這些需求轉(zhuǎn)化為設(shè)計新方法去捕獲和提供數(shù)據(jù)，并在成本和操作簡單性之間取得平衡
4.2.2. 并不意味著數(shù)據(jù)工程師就是數(shù)據(jù)架構(gòu)師，因為兩者通常是兩個獨立的角色
4.3. 如果數(shù)據(jù)工程師與數(shù)據(jù)架構(gòu)師一起工作，則數(shù)據(jù)工程師應該能夠交付數(shù)據(jù)架構(gòu)師的設(shè)計并提供架構(gòu)反饋
5. 編排
5.1. 編排不僅是DataOps的核心流程，也是數(shù)據(jù)作業(yè)工程和部署流程的關(guān)鍵部分
5.2. 編排是協(xié)調(diào)許多作業(yè)以盡可能快速且高效地按照預定節(jié)奏運行的過程
5.3. 允許編排系統(tǒng)在沒有人為干預的情況下持續(xù)感知和監(jiān)控，并隨時運行在部署的新作業(yè)
5.4. 編排系統(tǒng)還構(gòu)建作業(yè)歷史記錄功能、可視化和警報
- 5.4.1. 高級編排引擎可以在新的DAG或到DAG添加單個任務時回填
5.5. 編排一直是數(shù)據(jù)處理的關(guān)鍵功能，但除了大公司以外，通常不是最重要的，也不是任何人都可以使用的
5.6. Apache Oozie在21世紀10年代非常流行，但它是為在Hadoop集群中工作而設(shè)計的，很難在更加異構(gòu)的環(huán)境中使用
5.7. Facebook在21世紀00年代后期開發(fā)了供內(nèi)部使用的Dataswarm
- 5.7.1. 這激發(fā)了Airflow等流行工具的靈感，Airbnb于2014年推出了該工具
5.8. Airflow從一開始就是開源的，并被廣泛采用
5.8.1. 它是用Python編寫的，因此可以高度擴展到幾乎任何可以想象的用例
5.8.2. Airflow的到來恰逢數(shù)據(jù)處理變得更加抽象和易于訪問，工程師們對協(xié)調(diào)跨多個處理器和存儲系統(tǒng)的復雜流程越來越感興趣，尤其是在云環(huán)境中
5.9. 編排嚴格來講是一個批處理的概念
5.9.1. 編排任務DAG的流式替代方案是流式DAG
5.9.2. 流式DAG的構(gòu)建和維護仍然具有挑戰(zhàn)性，但Pulsar等下一代流式平臺旨在顯著減輕工程和運營負擔
6. 軟件工程
6.1. 軟件工程一直是數(shù)據(jù)工程師的一項核心技能
- 6.1.1. 應該精通軟件工程以理解API、提取和轉(zhuǎn)換數(shù)據(jù)、處理異常等
6.2. 核心數(shù)據(jù)處理代碼仍然需要編寫，并且貫穿于整個數(shù)據(jù)工程生命周期
- 6.2.1. 無論是在獲取、轉(zhuǎn)換還是數(shù)據(jù)服務方面，數(shù)據(jù)工程師都需要精通和高效地使用Spark、SQL或Beam等框架和語言
6.3. 重點已經(jīng)從直接的數(shù)據(jù)處理轉(zhuǎn)移到抽象的階梯上
6.4. 流數(shù)據(jù)處理本質(zhì)上比批處理更復雜，而且工具和范式可以說還沒有那么成熟
- 6.4.1. 隨著流數(shù)據(jù)在數(shù)據(jù)工程生命周期的每個階段變得越來越普遍，數(shù)據(jù)工程師面臨著有趣的軟件工程問題
6.5. 窗口化允許實時系統(tǒng)計算有價值的指標，如尾隨統(tǒng)計數(shù)據(jù)
- 6.5.1. 數(shù)據(jù)工程師有許多框架可供選擇，包括用于處理單個事件的各種函數(shù)平臺(OpenFaaS、AWS Lambda、Google Cloud Functions)或用于分析流以支持報告和實時處理的專用流處理器（Spark、Beam、Flink或Pulsar）
6.6. 基礎(chǔ)設(shè)施即代碼(Infrastructure as Code，IaC)將軟件工程實踐應用于基礎(chǔ)設(shè)施的配置和管理
6.7. 流水線即代碼是當今編排系統(tǒng)的核心概念，它涉及數(shù)據(jù)工程生命周期的每個階段
6.8. 無論數(shù)據(jù)工程師采用哪種高級工具，他們都會在整個數(shù)據(jù)工程生命周期中遇到極端情況，這些情況要求他們解決所選工具范圍之外的問題并編寫自定義代碼
