1. 資料獲取
1.1. 資料獲取是將資料從一個地方移動到另一個地方的過程
- 1.1.1. 資料獲取與系統內部獲取是不同的
1.2. 資料獲取是資料工程生命週期中將資料從源系統移入儲存的一箇中間步驟
1.3. 資料整合則是將來自不同來源系統的資料組合到一個新的資料集
1.4. 資料獲取的核心是資料管道，將管道連線到其他管道，確保資料持續安全地流向目的地
1.5. 在你作為資料工程師的工作中，資料獲取可能會消耗你很大一部分的時間和精力
2. 資料管道
2.1. 資料管道從源系統開始，但獲取是資料工程師開始投入精力設計資料管道的最初階段
2.2. 資料管道是在資料工程生命週期的各個階段用來移動資料的架構、系統和過程的組合
-
2.2.1. 一個傳統的ETL系統，資料從本地事務處理系統中獲取，透過單一的處理器，然後寫入資料倉儲中
-
2.2.2. 一個基於雲的資料管道，從100個資料來源提取資料，將其合併到20個寬表，訓練5個機器學習模型，然後再將它們部署到生產環境中，並持續監控效能
2.3. 資料管道應該足夠靈活，以適應資料工程生命週期中的需求
3. 上游利益相關者
3.1. 負責生成資料的人（通常是軟體工程師）與為分析和資料科學準備這些資料的資料工程師之間往往存在著明顯的脫節
3.2. 資料工程師可以透過邀請軟體工程師成為資料專案成果的利益相關者來提高資料質量
3.3. 絕大多數的軟體工程師都很清楚分析和資料科學的價值，但不一定有動機直接為資料工程工作做出貢獻
3.4. 簡單地改善溝通是關鍵的第一步
3.5. 資料工程師還可以向團隊成員、管理層，特別是產品經理強調軟體工程師的貢獻
3.6. 將稀缺的軟體工程師分配到與資料工程師的合作中來
4. 下游利益相關者
4.1. 資料工程師專注於資料從業者和技術領導者，如資料科學家、分析師和技術長
4.2. 將資料工程視為一項業務，並認識到你的客戶是誰
4.3. 獲取過程的自動化具有重要的價值，特別對於像市場營銷這樣控制大量預算並處於業務收入核心的部門
4.4. 資料工程師和其他資料從業者還是應該為高管提供關於資料驅動業務的最佳結構指導
4.5. 要強調降低資料生產者和資料工程師之間的障礙的價值，同時支援高管們打破孤島，建立激勵機制，形成更統一的資料驅動文化
4.6. 坦誠地與利益相關者儘早並且頻繁溝通，將很大程度上為你的資料獲取增加價值
5. 底層設計
5.1. 安全
-
5.1.1. 移動資料會帶來安全風險，因為你必須在不同地點之間傳輸資料
-
5.1.2. 最不希望的就是在移動過程中破壞資料
-
5.1.3. 在VPC內移動的資料應該使用安全的終端，並且永遠不要離開VPC的範圍
-
5.1.4. 如果你需要在雲和本地網路之間傳送資料，請使用虛擬專用網路或專用私人連線
-
5.1.5. 安全是一項好的投資。如果你的資料需要經過公共網際網路，請確保傳輸是加密的
-
5.1.6. 在網路上對資料進行加密始終是一個好的實踐
5.2. 資料管理
-
5.2.1. 資料管理自然地從資料獲取開始
-
5.2.2. 這是資料血緣和資料目錄的起點
-
5.2.3. 資料工程師需要考慮模式變化、道德、隱私和合規
-
5.2.4. 將不可避免地遇到敏感資料
-
5.2.4.1. 在確實有必要跟蹤敏感的個人資訊的時候，通常的做法是在模型訓練和分析中應用令牌化對敏感資訊做匿名處理
-
5.2.4.2. 資料工程師在某些情況下會不可避免地與高度敏感的資料打交道
-
5.2.4.3. 工程師在處理敏感資料時必須按照最高的道德標準行事
-
5.2.4.4. 在涉及敏感資料的情況下，儘可能實現無接觸生產環境
> 5.2.4.4.1. 意味著工程師可以在開發和預生產環境中用模擬或脫敏的資料來開發和測試程式碼，然後用自動化的方式將程式碼部署到生產中
- 5.2.4.5. 工程師應該努力實現無接觸生產環境的目標，但在開發和預生產環境中難免會出現問題無法完全解決的情況
> 5.2.4.5.1. 對生產環境中敏感資料的訪問至少需要兩個人批准
> 5.2.4.5.2. 種訪問應嚴格限制在特定問題上，並附有截止日期
-
5.2.4.6. 對人為問題的技術解決方案要保持警惕
-
5.2.4.7. 加密和令牌化往往被當作處理隱私資料的靈丹妙藥
> 5.2.4.7.1. 單欄位加密存在合規的用例，但要防止形式主義的加密
> 5.2.4.7.2. 在令牌化方面，使用常識並評估資料訪問情況
5.3. DataOps
-
5.3.1. 可靠的資料管道是資料工程生命週期的基石
-
5.3.2. 確保你的資料管道得到合適的監控是實現可靠性和有效的故障響應的關鍵步驟
-
5.3.3. 如果說在資料工程的生命週期中，有一個階段的監控是至關重要的，那就是獲取階段
-
5.3.4. 監控是關鍵，瞭解你所依賴的上游系統的行為以及它們如何生成資料也是關鍵
-
5.3.4.1. 正常執行時間、延遲和處理的資料量是很好的開始
-
5.3.4.2. 你應該知道你關注的每個時間間隔產生的事件數量（事件數/分鐘，事件數/秒，等等）以及每個事件的平均大小
-
5.3.4.3. 你的資料管道應該同時滿足所獲取的事件的頻率和大小的要求
-
5.3.5. 並不存在對於第三方故障的通用的響應計劃
-
5.3.5.1. 如果你可以做故障轉移，最好將服務放在另一個區域或地域
-
5.3.6. 資料質量測試
-
5.3.6.1. 資料稱為無聲的殺手
-
5.3.6.2. 如果優質且有效的資料是當今企業成功的基礎，那麼使用糟糕的資料來做決策比沒有資料要更糟糕
-
5.3.6.3. 糟糕的資料給企業帶來了難以計數的損失，這有時被稱為資料災難
-
5.3.6.4. 資料是有熵力的，它經常在沒有警告的情況下以意想不到的方式變化
-
5.3.6.5. DevOps和DataOps之間的內在區別之一是軟體迴歸只有在部署變更時才會遇到，而資料經常因為我們無法控制的事件而出現迴歸現象
> 5.3.6.5.1. DevOps工程師通常能夠使用二元條件來檢測問題
> 5.3.6.5.2. 在資料空間，迴歸往往表現為微妙的統計異常
> 5.3.6.5.2.1. 一些資料故障是立即可見的
> 5.3.6.5.2.2. 真正危險的資料故障是悄無聲息的，可能來自企業內部或外部
> 5.3.6.5.2.3. 應用程式開發人員可能會改變資料庫欄位的含義，而不與資料團隊進行充分的溝通
> 5.3.6.5.2.4. 統計資料測試是一個新領域，但在未來五年內可能會急劇增長
- 5.3.6.6. 只要有可能，就與軟體工程師一同從源頭上解決資料質量問題
> 5.3.6.6.1. 許多資料質量問題可以透過遵從軟體工程中的基本最佳實踐來處理，如記錄資料變化的歷史，檢查（空值等）和異常處理（嘗試、捕獲等)
5.4. 編排
-
5.4.1. 所謂編排工具，指的是一個能夠編排完整任務圖而不是單個任務的系統
-
5.4.2. 編排系統可以在適當的計劃時間啟動每個資料獲取任務
-
5.4.2.1. 當獲取任務完成時，下游的處理和轉換步驟會開始
-
5.4.2.2. 再往下走，處理步驟會觸發更多的處理步驟
-
5.4.3. 獲取通常位於大且複雜的資料流圖的起始位置
-
5.4.4. 由於獲取是資料工程生命週期的第一階段，獲取的資料將流入更多的處理過程，來自許多資料來源的資料將以複雜的方式組合在一起
-
5.4.5. 處於資料成熟度早期階段的組織可能會選擇將獲取過程部署為簡單的cron任務
-
5.4.6. 隨著資料管道複雜性的增加，編排工具是必要的
5.5. 軟體工程
-
5.5.1. 資料工程生命週期的資料獲取階段是工程密集型的
-
5.5.2. 避免編寫對源系統或目標系統有嚴格依賴的單體系統