讀資料工程之道：設計和構建健壯的資料系統24獲取資料的方式

躺柒發表於2024-10-30

1. 資料庫直連

1.1. 資料可以透過網路連線直接從資料庫中透過查詢和讀取的方式來獲取

1.2. 使用ODBC或JDBC進行的

  • 1.2.1. JDBC和ODBC長期以來是資料庫資料獲取的黃金標準，但對於許多資料工程應用程式來說，這些連線標準已經開始顯示出它們年頭已久

  • 1.2.2. 許多資料庫現在支援本地檔案匯出，繞過了JDBC和ODBC，直接以Parquet、ORC和Avro等格式匯出資料

  • 1.2.3. ODBC使用一個部署在客戶端的驅動程式，將標準的ODBC API翻譯成向不同資料庫發出的命令

  • 1.2.4. 利用ODBC驅動的應用是一個資料獲取工具

    • 1.2.4.1. 資料獲取工具可以透過許多小的查詢或單一的大查詢來拉取資料

  • 1.2.5. ODBC驅動程式是基於作業系統和計算機架構提供的原生二進位制檔案

  • 1.2.6. 一個Java驅動程式作為標準JDBC API和目標資料庫的本地網路介面之間的轉換層連線到一個遠端資料庫

  • 1.2.7. JDBC提供了非凡的資料庫驅動程式可移植性

  • 1.2.8. Python生態系統提供翻譯工具，允許Python程式碼與執行在本地JVM上的JDBC驅動程式通訊

2. 變更資料捕獲

2.1. 面向批處理的變更資料捕獲

  • 2.1.1. 根據最後一次從表中捕獲變更的行的時間來設定過濾器的時間戳

  • 2.1.2. 這個過程允許我們拉取資料變更並增量更新目標表

2.2. 連續變更資料捕獲

  • 2.2.1. 連續變更資料捕獲捕獲表的所有歷史，並可以支援近實時資料獲取，無論是用於實時資料庫複製還是為實時流分析提供資料

  • 2.2.2. 連續變更資料捕獲不是透過執行定期查詢來獲取一批表的變化，而是將每一次對資料庫的寫入作為一個事件

  • 2.2.3. 基於日誌的變更資料捕獲

    • 2.2.3.1. 資料庫的二進位制日誌按順序記錄了資料庫的每一次變化

    • 2.2.3.2. 一個變更資料捕獲工具可以讀取這個日誌並將事件傳送到一個目的地，比如Apache Kafka Debezium流平臺

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.4. 考慮因素

  • 2.4.1. 變更資料捕獲也不是沒有代價的

  • 2.4.2. 消耗各種資料庫資源，如記憶體、磁碟頻寬、儲存、CPU時間和網路頻寬

  • 2.4.3. 在生產系統上開啟變更資料捕獲之前，資料工程師應該與業務開發團隊合作進行測試，以避免出現操作問題

  • 2.4.4. 要麼只在非工作時間執行這類查詢，要麼使用讀副本以避免給主資料庫帶來負擔

3. API

3.1. API是一個重要性和受歡迎程度不斷提高的資料

3.2. 趨勢

  • 3.2.1. 許多供應商為各種程式語言提供API客戶端庫，消除了API訪問的大部分複雜性

  • 3.2.2. 現在有許多資料聯結器平臺可以作為SaaS、開源或託管開源的形式存在

  • 3.2.3. 資料共享的出現​，即透過標準平臺（如BigQuery、Snowflake、Redshift或S3）交換資料的能力

3.3. 當無法使用資料共享且必須直接使用API訪問的時候，不要重複發明輪子

4. 訊息佇列和事件流平臺

4.1. 訊息佇列和事件流平臺是從網路和移動應用程式、物聯網感測器和智慧裝置獲取實時資料的普遍方法

4.2. 訊息是在單個事件層面上處理的，並且是短暫的

  • 4.2.1. 一旦訊息被消費，它就被確認並從佇列中刪除

4.3. 流將事件獲取到一個有序的日誌中

  • 4.3.1. 日誌會在你期望的時間內一直存在，允許在不同的範圍內對事件進行查詢、聚合，並與其他流結合，以建立可以釋出給下游消費者的新的變換

4.4. 批次獲取通常涉及靜態工作流（獲取資料、儲存資料、轉換資料和提供資料服務）​，而訊息和流是動態的

4.5. 獲取可以是非線性的，資料被髮布、消費、重新發布和重新消費

4.6. 當設計你的實時獲取工作流時，請記住資料如何流動

4.7. 實時資料管道的吞吐量

  • 4.7.1. 訊息和事件的流動應該有儘可能小的延遲，這意味著你應該提供足夠大的分割槽（或分片）頻寬和吞吐量

4.8. 管理你的流平臺可能需要大量的開銷

  • 4.8.1. 考慮為你的實時獲取管道使用託管服務，將你的注意力集中在如何從你的實時資料中獲得價值

5. 託管資料聯結器

5.1. 建議使用託管聯結器平臺，而不是自建和管理聯結器

6. 使用物件儲存移動資料

6.1. 物件儲存是一個公有云中支援儲存海量資料的多租戶系統

  • 6.1.1. 使得物件儲存成為在資料湖、團隊之間、組織之間轉移資料的理想選擇

6.2. 物件儲存是處理檔案交換的最理想和最安全的方式

6.3. 公有云儲存實現了最新的安全標準，具有強大的可擴充套件性和可靠性，接受任意型別和大小的檔案，並且提供高效能的資料移動

7. 電子資料交換（EDI）

7.1. 有些古老的檔案交換方式，如透過電子郵件或快閃記憶體驅動器

7.2. 一些資料來源由於IT系統過於老舊或人類過程限制，不支援更現代的資料傳輸手段

8. 資料庫和檔案匯出

8.1. 匯出查詢可以按照查詢鍵值範圍或一次查詢一個分割槽分解成若干個較小的匯出

8.2. 讀副本也可以減輕資料庫負載

  • 8.2.1. 如果匯出每天發生很多次，並且與源系統的高負載時間段相吻合，那麼讀副本就特別合適

8.3. 主要的雲資料倉儲對直接檔案匯出進行了高度最佳化

9. 常見檔案格式的問題

9.1. CSV不是一種統一的格式

  • 9.1.1. CSV的預設分割符是英語中最常見的字元——逗號

  • 9.1.2. CSV也沒有對模式資訊進行原生編碼或直接支援巢狀結構

  • 9.1.3. 自動檢測是許多雲環境中提供的便利功能，但不適合用於生產環境的獲取

  • 9.1.4. 工程師應該在檔案後設資料中記錄CSV編碼和模式細節

9.2. 更加強大的匯出格式包括Parquet、Avro、Arrow和ORC或JSON

  • 9.2.1. 對模式資訊進行原生編碼，並且可以無須特別干預地處理任意字串資料

9.3. 對於列式資料庫，列式格式(Parquet、Arrow、ORC)允許更有效的資料匯出，因為列可以在格式之間直接轉碼

9.4. Arrow檔案格式被設計為直接將資料對映到處理引擎記憶體中，在資料湖環境中提供高效能

10. 命令列

10.1. 命令列(shell)是一個你可以透過執行命令來獲取資料的介面

10.2. 命令列可以用來為幾乎所有的軟體工具編寫工作流，而且命令列指令碼仍然被廣泛用於資料獲取過程

10.3. 雲供應商通常提供強大的基於CLI的工具

11. SSH

11.1. SSH不是一種獲取策略，而是一種與其他獲取策略一起使用的協議

11.2. SSH可以與SCP一起用於檔案傳輸

11.3. SSH隧道被用來允許安全、隔離地連線到資料庫

11.4. 應用程式資料庫不應該直接暴露在網際網路上

  • 11.4.1. 工程師可以設定一個堡壘主機，即一個可以連線到相關資料庫的中間主機例項

  • 11.4.2. 這臺主機暴露在網際網路上，只能從指定的IP地址到指定的埠進行最小的訪問

12. SFTP和SCP

12.1. SFTP對許多企業來說仍然是一個實際的選擇

12.2. SCP是一個透過SSH連線執行的檔案交換協議

  • 12.2.1. 在配置正確的情況下，SCP可以成為一個安全的檔案傳輸選項

  • 12.2.2. 建議增加額外的網路訪問控制（深度防禦）來加強SCP的安全性

13. Webhook

13.1. 使用Webhook時，資料提供者定義了一個API請求規範，但是資料提供者進行API呼叫，而不是被呼叫

13.2. 資料消費者負責提供一個API服務端供資料提供者呼叫

13.3. 消費者負責獲取每個API請求中的資料，並對資料進行聚合、儲存和處理

13.4. 基於Webhook的資料獲取架構可能很脆弱，難以維護且低效

13.5. 使用適當的工具，資料工程師可以建立更強大的Webhook架構，並降低維護和基礎設施成本

14. 網路介面

14.1. 用於資料訪問的網路介面對資料工程師來說仍然是一個現實的選擇

15. 網路抓取

15.1. 網路抓取透過梳理網頁的各種HTML元素自動從網頁上抽取資料

15.2. 網路抓取對資料工程生命週期的處理階段有著有趣的影響

15.3. 問問你自己，你是否應該進行網路抓取，或者是否可以從第三方獲得資料

15.4. 要注意你行為的法律影響

15.5. 網頁會不斷地改變HTML元素結構，更新你的網路抓取程式會變得很麻煩

16. 用於資料遷移的傳輸裝置

16.1. 對於海量的資料（100TB或更多）​，直接透過網際網路傳輸可能是一個緩慢而高成本的過程

16.2. 最快最有效的資料傳輸方式不是透過網路，而是透過卡車來移動資料

16.3. 透過物理的“裝硬碟的箱子”傳送資料的能力

  • 16.3.1. 只需訂購一個儲存裝置（稱為傳輸裝置）從你的伺服器上載入資料，然後把它送回可以幫你上傳資料的雲供應商

16.4. 如果你的資料規模在100TB左右，那麼建議你使用一個傳輸裝置

  • 16.4.1. 用半掛車送來的傳輸裝置

16.5. 傳輸裝置對於建立混合雲或多雲很方便

16.6. 當資料量很大時，物理傳輸裝置是一個更便宜的選擇

16.7. 請記住傳輸裝置和資料遷移服務是一次性的資料獲取，不建議用於持續的獲取工作

17. 資料共享

17.1. 資料共享已經變成了消費資料的一種流行方案

17.2. 資料提供者會向第三方使用者免費或有償提供資料

17.3. 以只讀方式共享，這意味著你可以將這些資料集與你自己的資料（以及其他第三方資料集）整合，但你沒有資料的所有權

相關文章