讀資料工程之道：設計和構建健壯的資料系統27轉換

躺柒發表於2024-11-04

1. 轉換

1.1. 轉換與查詢不同

  • 1.1.1. 查詢是根據過濾和連線邏輯從各種來源檢索資料

  • 1.1.2. 轉換將結果持久化，供其他轉換或查詢使用

  • 1.1.2.1. 結果可以被短暫地或永久地儲存

  • 1.1.3. 除了永續性，轉換區別於查詢的另一個特點是複雜性

  • 1.1.3.1. 你可能會建立複雜的資料管道，結合來自多個來源的資料，併為多個最終輸出重複使用中間結果

1.2. 轉換化在很大程度上依賴於本書中的一個主要底層設計：編排

1.3. 轉換是資料管道的核心

  • 1.3.1. 轉換是為業務增加價值和投資回報率的地方

  • 1.3.2. 本質上是圍繞流資料獲取重新配置資料棧，並使資料轉換工作流更接近源系統應用程式本身

1.4. 請思考技術作為實現組織目標的工具

1.5. 把實時資料看作為了技術而技術的工程團隊將重複大資料時代的錯誤

1.6. 僱用工程師不是為了玩最新的技術，而是為了服務客戶

  • 1.6.1. 使用令人興奮的轉換技術為利益相關者服務是可行的

1.7. 資料工程師還在這個系統中實現資料模型

1.8. 重點是儘可能多地創造價值，無論是在完善系統功能還是構建可靠的和值得信賴的資料方面

2. 批次轉換

2.1. 批次轉換在離散的資料集上執行，而流式轉換是在資料到達時連續處理

  • 2.1.1. 批次ETL是一種可以追溯到關聯式資料庫早期的廣泛使用的轉換模式

  • 2.1.2. 傳統的ETL依賴於一個外部系統來拉取、轉換和清洗資料，同時為目標模式做準備

  • 2.1.3. ELT概念是隨著資料湖的出現而普及的

  • 2.1.3.1. 資料在載入時並沒有被轉換

  • 2.1.3.2. 事實上，資料可以在沒有準備和任何使用計劃的情況下載入

  • 2.1.3.3. 其假設是，轉換步驟將在未來某個未確定的時間發生

2.2. 為了支援報表、資料分析和機器學習模型，批次轉換會在固定的時間執行

2.3. 分散式連線

  • 2.3.1. 分散式連線的基本思想是將一個邏輯連線（由查詢邏輯定義的連線）分解成更小的節點連線，節點連線在叢集中的各個伺服器上執行

  • 2.3.2. 廣播連線

  • 2.3.2.1. 廣播連線的資料通常是不對稱的，一個大表分佈在各節點上，一個小表可以很容易地載入到單個節點

  • 2.3.2.2. 查詢引擎將小表廣播到所有節點，它在每個節點都被連線到大表的一部分

  • 2.3.2.3. 廣播連線的計算量遠小於洗牌雜湊連線

  • 2.3.3. 洗牌雜湊連線

  • 2.3.3.1. 如果兩個表都小到可以放在一個節點上，查詢引擎將使用洗牌雜湊連線

  • 2.3.3.2. 這種分割槽與連線鍵沒有關係

  • 2.3.3.3. 通常會使用連線鍵雜湊的方式重新劃分資料

  • 2.3.3.4. 洗牌雜湊連線通常比廣播連線耗費更多資源

2.4. 查詢最佳化器的首要任務之一是連線重排

2.5. 轉換工具

  • 2.5.1. 自從Hadoop平臺上引入Hive後，SQL已經成為大資料生態系統中的一等公民

  • 2.5.1.1. Spark SQL是Apache Spark的一個早期功能

  • 2.5.1.2. Kafka、Flink和Beam等流優先框架也支援SQL，其特點和功能各不相同

  • 2.5.2. SQL是宣告式的，但它仍然可以建立複雜的資料工作流

  • 2.5.2.1. SQL作者用集合理論語言規定他們最終資料的特徵，而不是編碼資料處理程式

  • 2.5.2.2. SQL編譯器和最佳化器決定將資料置於這種狀態所需的步驟

2.6. 業務邏輯和衍生資料

  • 2.6.1. 資料轉換最常見的用例之一是將業務邏輯翻譯成程式碼

  • 2.6.2. 衍生資料

  • 2.6.2.1. 從儲存在系統中的其他資料計算出來的資料

2.7. MapReduce

  • 2.7.1. MapReduce是大資料時代標誌性的批處理資料轉換方式，它仍然影響著許多資料工程師今天使用的分散式系統，而且對於資料工程師來說，理解它的基本概念是很有用的

  • 2.7.2. 磁碟容量和頻寬非常便宜，所以簡單地使用大量磁碟處理資料以實現超快速查詢是有意義的

  • 2.7.3. 雲服務商是更廣泛地採用記憶體快取的驅動者之一

3. 資料更新

3.1. 由於轉換會持久化資料，我們經常會在原地更新持久化後的資料

3.2. 更新資料是資料工程團隊的一個主要痛點，尤其是在資料工程技術之間過渡時

3.3. 更新模式

  • 3.3.1. 清空和重新載入

  • 3.3.1.1. 清空是一種更新模式，不更新任何東西

  • 3.3.1.2. 只是簡單地擦除舊資料

  • 3.3.1.3. 一個表被清除了資料，重新執行轉換任務然後把結果並載入到這個表中，有效地生成了一個新版本的表

  • 3.3.2. 僅插入

  • 3.3.2.1. 僅插入插入新記錄而不改變或刪除舊記錄

  • 3.3.2.2. 可用於維護最新資料的檢視

>  3.3.2.2.1. 插入新版本的記錄而不刪除舊記錄
  • 3.3.2.3. 一個查詢或檢視可以透過主鍵找到最新的記錄來呈現當前的資料狀態
>  3.3.2.3.1. 列式資料庫通常不強制要求表有主鍵

  • 3.3.2.4. 缺點是在查詢時找到最新記錄的計算成本極高

  • 3.3.2.5. 可以使用一個物化檢視​，一個維護全部記錄的僅插入表，以及一個保持服務資料最新狀態的清空和重新載入表

  • 3.3.3. 建議以定期微批或批處理的方式載入資料

3.4. 針對不頻繁寫入的一個例外

  • 3.4.1. BigQuery和Apache Druid使用的增強型Lambda架構，它將流緩衝器與列儲存混合在一起

3.5. 刪除

  • 3.5.1. 當源系統需要刪除資料以滿足最新的監管變化時，刪除就是非常重要的功能

  • 3.5.2. 在列式系統和資料湖中，刪除比插入成本更高

  • 3.5.3. 硬刪除是將一條記錄從資料庫中永久刪除

  • 3.5.3.1. 當你因為效能原因需要刪除資料時​，或者有法律或合規的原因需要這樣做時，硬刪除很有用

  • 3.5.4. 軟刪除則是將該記錄標記為“已刪除”​

  • 3.5.4.1. 當你不想永久地刪除一條記錄，但又想把它從查詢結果中過濾掉時，就可以使用軟刪除

  • 3.5.5. 插入式刪除

  • 3.5.5.1. 插入式刪除插入一條帶有deleted標誌的新記錄，而不修改該記錄的先前版本

3.6. upsert/merge

  • 3.6.1. upsert和merge模式一直是給資料工程團隊帶來最大麻煩的模式，特別是對於從基於行的資料倉儲轉換到基於列的雲系統的人來說

  • 3.6.2. 分散式列式資料系統支援本地更新命令，合併也是有代價的：更新或刪除單一記錄的效能影響可能相當大

  • 3.6.3. 和插入一樣，要注意你的更新或合併頻率

3.7. 模式更新

  • 3.7.1. 資料是會發生變化的，而且變化可能會在你無法控制或沒有你許可的情況下發生

  • 3.7.2. 在資料倉儲中作為一等公民提供的半結構化資料非常靈活，為資料分析師和資料科學家提供了新的機會，因為資料不再受限於行和列

  • 3.7.2.1. 當資料工程師必須從具有頻繁變化模式的應用程式檔案儲存中獲取資料時，這種方法效果非常好

4. 資料整理

4.1. 資料整理將混亂的、畸形的資料，變成有用的、乾淨的資料

4.2. 資料整理一直是資料工程師的主要痛點和工作的價值點

4.3. 自動化工具允許資料工程師把時間花在更有趣的任務上

  • 4.3.1. 整理工具也可以讓工程師把一些解析和獲取的工作交給分析師

  • 4.3.2. 圖形化的資料整理工具通常在一個視覺化的介面中展示資料樣本，包括推斷的型別、統計資料，包括分佈、異常資料、異常值和空值

5. 物化檢視、聯邦查詢和資料虛擬化

5.1. 檢視

  • 5.1.1. 為物化檢視做個鋪墊，讓我們回顧一下檢視

  • 5.1.2. 檢視是一個資料庫物件，我們可以像其他表一樣從中查詢

  • 5.1.3. 當我們從一個檢視中查詢時，該資料庫會建立一個新的查詢，將子查詢與我們的查詢相結合，然後，查詢最佳化器對完整的查詢進行最佳化

  • 5.1.4. 檢視可以用來幫助展示去重後的資料

  • 5.1.5. 檢視可以用來展示常見的資料訪問模式

5.2. 物化檢視

  • 5.2.1. 非物化檢視的一個潛在缺點是它們不做任何預計算

  • 5.2.2. 物化檢視提前進行了部分或全部的檢視計算

  • 5.2.3. 根據不同的資料庫，物化檢視也可以起到重要的查詢最佳化作用，即使是不直接引用它們的查詢

  • 5.2.4. 物化檢視不允許組合，也就是說，一個物化檢視不能從另一個物化檢視中查詢資料

5.3. 可組合的物化檢視

5.4. 聯邦查詢

  • 5.4.1. 聯邦查詢是資料庫的一種功能，它允許OLAP資料庫從外部資料來源查詢資料

  • 5.4.2. Snowflake支援在S3桶上定義的外部表

5.5. 資料虛擬化

  • 5.5.1. 資料虛擬化與聯邦查詢密切相關，但通常需要一個不在內部儲存資料的處理和查詢系統

  • 5.5.2. Trino（如Starburst）和Presto是比較優秀的例子

  • 5.5.3. 任何支援外部表格的查詢/處理引擎都可以作為一個資料虛擬化引擎

  • 5.5.4. 資料虛擬化最重要的考慮因素是支援外部資料來源和效能

  • 5.5.5. 一個密切相關的概念是查詢下推

  • 5.5.5.1. 詢下推的目的是將盡可能多的工作轉移到源資料庫

  • 5.5.5.2. 計算引擎可能會設法將過濾條件推送到源系統的查詢中

  • 5.5.5.3. 它減少了虛擬化層的計算量，利用了源系統的查詢效能

  • 5.5.5.4. 減少了必須透過網路推送的資料量，這是虛擬化效能的另一個關鍵瓶頸

  • 5.5.6. 資料虛擬化可以作為資料獲取和處理管道的一個組成部分

  • 5.5.7. 資料虛擬化可以被看作一種透過去除組織間資料孤島並將資料湖擴充套件到更多的資料來源的工具

6. 流轉換和處理

6.1. 流查詢動態地呈現資料的當前狀況

6.2. 流轉換的目的是為下游消費準備資料

6.3. 轉換和查詢是一個連續的過程

6.4. 在批處理中，轉換和查詢之間的界限很模糊，但在流資料領域，兩者的區別變得更細微

6.5. 流式有向無環圖

  • 6.5.1. 一個與流資料增強和連線相關的術語是流式有向無環圖

6.6. 微批處理

  • 6.6.1. 一種將面向批處理的框架應用於流的方式

  • 6.6.2. 一個微批處理可能以每兩分鐘到每秒鐘的頻率執行

  • 6.6.2.1. 一些微批處理框架（如Apache Spark Streaming）就是為這種用例而設計的，在適當分配資源的情況下，較高的批處理頻率效能會很好

6.7. 真正的流處理系統（例如Beam和Flink）一次只處理一個事件

6.8. 領域知識和實際測試是無可替代的

7. 上游利益相關者

7.1. 上游利益相關者可以分成兩大類：控制業務定義的人和控制系統生成資料的人

7.2. 當與上游利益相關者就業務定義和邏輯進行交流時，你需要了解資料來源

  • 7.2.1. 它們分別是什麼，它們如何被使用，以及涉及的業務邏輯和定義是什麼

7.3. 資料工程師需要參與到資料模型的設計中，並在以後因為業務邏輯變化或新的流程而進行更新資料模型

7.4. 上游利益相關者希望確保你的查詢和轉換對他們的系統影響最小

8. 下游利益相關者

8.1. 轉換是資料開始向下遊利益相關者提供服務的地方

8.2. 下游利益相關者

  • 8.2.1. 資料分析師、資料科學家、機器學習工程師和業務人員

  • 8.2.2. 與他們合作，確保你提供的資料模型和轉換是高效能且有用的

8.3. 在效能方面，查詢應該以最具成本效益的方式儘可能快地執行

8.4. 分析師、資料科學家和機器學習工程師應該能夠查詢資料來源，並確信資料具有最高的質量和完整性，能被整合到他們的工作流和資料產品中

8.5. 業務人員應該能夠相信轉換後的資料是準確的和可使用的

9. 底層設計

9.1. 安全

  • 9.1.1. 查詢和轉換將不同的資料集組合成新的資料集

  • 9.1.2. 如果有人確實可以訪問一個資料集，則要繼續控制誰可以有資料集的列、行和單元格級別的訪問許可權

  • 9.1.3. 在查詢時要注意針對你的資料庫的攻擊向量

  • 9.1.3.1. 對資料庫的讀寫許可權必須進行嚴格的監視和控制

  • 9.1.3.2. 對資料庫的查詢訪問的控制，必須以你的組織對系統和環境的訪問控制相同的方式進行

  • 9.1.4. 保證身份驗證資訊的隱蔽性

  • 9.1.5. 避免複製和貼上密碼、訪問令牌或其他憑證到程式碼或未加密的檔案

  • 9.1.6. 不要讓不安全或未加密的資料透過公共網際網路傳輸

9.2. 資料管理

  • 9.2.1. 儘管資料管理在源系統階段（以及資料工程生命週期的其他每個階段）是必不可少的，但在轉換階段尤其關鍵

  • 9.2.2. 讓所有的利益相關者參與到資料模型和轉換中來並管理他們的期望是至關重要的

  • 9.2.3. 正確的命名約定應該反映在易於理解的欄位名中

  • 9.2.4. 使用者也可以在資料目錄中檢視，以更清楚地瞭解欄位建立時的含義，誰在維護資料集以及其他相關資訊

  • 9.2.5. 對定義的準確性進行解釋是轉換階段的關鍵

  • 9.2.6. 資料轉換使你很難知道一個資料集是如何從同一行衍生出的

  • 9.2.6.1. 當我們轉換資料時，資料血緣工具變得非常有價值

  • 9.2.6.2. 資料血緣工具既可以幫助資料工程師在建立新的轉換時瞭解以前的轉換步驟，也可以幫助分析師在執行查詢和建立報告時瞭解資料的來源

9.3. DataOps

  • 9.3.1. 向基於SaaS的分析資料庫的轉變改變了資料消費的成本狀況

  • 9.3.2. 以實際用量為收費基礎的雲資料倉儲的資料工程師需要專注於成本管理和成本最佳化

  • 9.3.2.1. FinOps

9.4. 資料架構

  • 9.4.1. 構建健壯的能夠處理和轉換資料系統的同時保證穩定性

  • 9.4.2. 對資料獲取和儲存的技術選型將直接影響你執行可靠的查詢和轉換

  • 9.4.3. 如果獲取和儲存適合你的查詢和轉換模式，你就不會有什麼問題

9.5. 編排

  • 9.5.1. 資料團隊經常使用簡單的基於時間表的方式來管理他們的資料轉換管道

  • 9.5.2. 使用基於依賴關係的編排工具來管理複雜的管道

  • 9.5.3. 編排工具也是一種黏合劑，使我們能夠組裝跨越多個系統的管道

9.6. 軟體工程

  • 9.6.1. 資料工程師負責設定分析師和資料科學家使用的程式碼庫和CI/CD管道

  • 9.6.2. 使用一個基於圖形使用者介面的低程式碼工具，你可以得到轉換工作流的視覺化展示

  • 9.6.2.1. 瞭解幕後的程式碼將有助於除錯和效能最佳化

  • 9.6.3. 雖然簡單地在資料集上投入更多的處理資源可以在一定程度上解決問題，但知道如何編寫乾淨的、高效能的程式碼是一個更好的方法

相關文章