讀資料工程之道：設計和構建健壯的資料系統22獲取階段考慮因素

躺柒發表於2024-10-28

1. 有邊界與無邊界資料

1.1. 無邊界資料是現實中存在的資料，是事件發生時的資料，要麼是間斷的，要麼是連續的、持續的和流動的

1.2. 有邊界資料是跨越某種邊界（如時間）對資料進行歸類的一種便捷方式

  • 1.2.1. 所有的資料在有邊界之前都是無邊界的

1.3. 長期以來，業務流程透過切割離散的批次對資料施加人為的限制

  • 1.3.1. 牢記資料的真正無邊界性

1.4. 流式獲取系統是一種用於保持資料的無邊界性的工具，以便資料生命週期中的後續步驟也能連續地處理資料

2. 頻率

2.1. 資料獲取頻率

  • 2.1.1. 在較慢的一端，一家企業可能每年向會計公司傳送一次稅務資料

  • 2.1.2. 在較快的一端，變更資料捕獲系統可以每分鐘從源資料庫中檢索一次新的日誌更新

  • 2.1.3. 更快的是，系統可以連續從物聯網感測器獲取事件並在幾秒內處理這些事件

2.2. 資料獲取的頻率往往是混合的，這取決於使用場景和技術

  • 2.2.1. 獲取過程可以是批處理、微批處理或實時處理

  • 2.2.2. 沒有一個獲取系統是真正實時的

  • 2.2.2.1. 任何資料庫、佇列或管道在向目標系統提供資料時都有固有的延遲

  • 2.2.2.2. 更準確的說法是近實時

  • 2.2.3. 當事件到達時，要麼會在管道中被逐一處理，要麼會以微批（在簡短的時間間隔內批處理）的形式處理

  • 2.2.4. 即使使用流式資料獲取過程，下游使用批處理也是相對常見的

2.3. 資料在生命週期中將被分解成不同的批次

  • 2.3.1. 一旦選擇批處理，處理頻率就會成為所有下游處理的瓶頸

2.4. 流式系統是許多資料來源的最佳選擇

  • 2.4.1. 在物聯網應用程式中，典型的模式是每個感測器將事件或測量值直接寫入流式系統

  • 2.4.2. 資料也可以直接寫入資料庫，但流式獲取平臺（如Amazon Kinesis或Apache Kafka）更適合這類場景

  • 2.4.3. 在事件發生時將其寫入訊息佇列，而不是讓下游系統從後端資料庫拉取事件和狀態資訊

  • 2.4.3.1. 對於已經透過佇列交換訊息的事件驅動型架構來說效果特別好

2.5. 流式架構通常與批處理共存

3. 同步獲取與非同步獲取

3.1. 在同步獲取的情況下，資料來源、獲取過程和寫入目標有複雜的依賴關係並且是緊密耦合的

3.2. 在非同步獲取的情況下，依賴關係現在可以體現在單個事件的層面上，就像它們在由微服務構建的軟體後端一樣

  • 3.2.1. 事件一旦被獲取，就會在儲存中可用

  • 3.2.2. 當事件產生的速率變低並且管道中沒有任何積壓時，新增的事件會快速透過管道

4. 序列化與反序列化

4.1. 序列化意味著對來自源頭的資料進行編碼，這種編碼會作為傳輸和中間儲存階段的資料結構

4.2. 在獲取資料時，要確保你的下游能夠反序列化它所收到的資料

5. 吞吐量與可擴充套件性

5.1. 理論上講，資料獲取不應該是系統的瓶頸

5.2. 在實踐中，資料獲取瓶頸是相當常見的

5.3. 從哪裡獲取資料是很重要的

5.4. 處理突發性資料獲取的能力

  • 5.4.1. 資料很少以恆定的速率生成，速率往往是起伏不定的

  • 5.4.2. 系統需要內建的快取來收集高峰期的事件，以防止資料丟失

  • 5.4.3. 存在系統擴充套件時起到橋樑作用，使儲存系統在動態可擴充套件的系統中適應突發情況

  • 5.4.4. 只要有可能，就使用託管服務來處理系統擴充套件問題

6. 可靠性與永續性

6.1. 可靠性和永續性在資料管道的獲取階段是至關重要的

6.2. 可靠性意味著獲取系統的高正常執行時間和適當的故障轉移

6.3. 永續性需要確保資料不會丟失或損壞

6.4. 一些資料來源（如物聯網裝置和快取）中的資料如果沒有被正確獲取，則可能會丟失

  • 6.4.1. 資料一旦丟失，它就永遠消失了

  • 6.4.2. 資料獲取系統的可靠性會直接影響生成資料的永續性

6.5. 理論上，如果資料已經被獲取，在下游程序暫時中斷的情況下理論上可能會延遲執行

6.6. 評估風險，並根據丟失資料的影響和成本建立適當的冗餘和自我修復機制

6.7. 可靠性和永續性都有直接和間接的成本

  • 6.7.1. 沒有什麼是免費的

  • 6.7.2. 一定要不斷地評估可靠性和永續性的成本與收益

6.8. 在許多極端情況下，獲取資料實際上並不重要

  • 6.8.1. 如果網際網路癱瘓，即使你在有獨立電源的地下掩體中建立了多個空氣密封的資料中心，那麼也無法獲取資料

7. 有效負載

7.1. 有效負載是你正在獲取的資料集並且具有種類、形態、大小、模式和資料型別以及後設資料等特徵

7.2. 資料種類直接影響到它在資料工程生命週期中下游的處理方式

  • 7.2.1. 型別直接影響到資料的格式或表現形式，包括位元組、名稱和副檔名等

  • 7.2.2. 影像，它的格式是JPG或PNG，它本質上是非結構化的

7.3. 資料形態在整個資料工程生命週期中都是至關重要的

  • 7.3.1. 每個有效負載都有一個描述其維度的形態

  • 7.3.2. 表格

  • 7.3.2.1. 資料集中的行和列的數量，通常表示為M行和N列

  • 7.3.3. 半結構化的JSON

  • 7.3.3.1. 鍵值對和巢狀深度與子元素一起出現

  • 7.3.4. 非結構化文字

  • 7.3.4.1. 文字正文中的字數、字元數或位元組數

  • 7.3.5. 影像

  • 7.3.5.1. 寬度、高度和RGB顏色深度

  • 7.3.6. 無壓縮的音訊

  • 7.3.6.1. 道數（例如，兩個立體聲）

  • 7.3.6.2. ​取樣深度（例如，每樣本16位）

  • 7.3.6.3. 取樣率（例如，48kHz）

  • 7.3.6.4. 長度（例如10003s)

  • 7.3.7. 大小

  • 7.3.7.1. 據的大小描述了一個有效負載的位元組數

  • 7.3.7.2. 一個有效負載的大小範圍可能是從單個位元組到太位元組，甚至更大

  • 7.3.7.3. 一個超大的有效負載也可以被分割成若干個塊，這可以有效地將有效負載的資料減少到較小的子段中

  • 7.3.7.4. 分割是一種常見的做法，因為小檔案更容易在網路上傳輸（特別是當它們被壓縮後）​

  • 7.3.7.5. 較小的塊檔案被髮送到目的儲存，然後在所有資料到達後對它們進行重新組裝

  • 7.3.8. 模式和資料型別

  • 7.3.8.1. 大多數資料的有效負載都有相應的模式，如表格和半結構化資料

  • 7.3.8.2. 模式描述了欄位和這些欄位的資料型別

  • 7.3.8.3. 模式不僅僅是針對資料庫的

  • 7.3.8.4. 大部分從源模式中獲取資料的工作都發生在資料工程生命週期的轉換階段

  • 7.3.8.5. 溝通是理解源資料的關鍵，資料工程師也有機會扭轉溝通的方向，並幫助軟體工程師最佳化資料產生的方式

  • 7.3.8.6. 模式的變化經常發生在源系統中，而且往往不受資料工程師的控制

>  7.3.8.6.1. 新增一個新的列

>  7.3.8.6.2. 改變一個列的型別

>  7.3.8.6.3. 建立一個新的表

>  7.3.8.6.4. 重新命名一個列
  • 7.3.8.7. 越來越多的獲取工具可以自動檢測模式變化甚至自動更新目標表
>  7.3.8.7.1. 自動化是件好事，當資料發生變化時，依賴資料的分析師和資料科學家應該被告知對其工作的影響
  • 7.3.8.8. 模式登錄檔
>  7.3.8.8.1. 在流資料中，每個訊息都有一個模式，這些模式可能在生產者和消費者之間演變

>  7.3.8.8.2. 模式登錄檔是一個後設資料儲存庫，用於在不斷變化的模式面前保持模式和資料型別的完整性

>  7.3.8.8.3. 模式登錄檔還可以跟蹤模式的版本和歷史

>  7.3.8.8.4. 描述了訊息的資料模型，允許生產者和消費者之間進行一致的序列化和反序列化

>  7.3.8.8.5. 大多數主要的資料工具和雲平臺都使用了模式登錄檔
  • 7.3.8.9. 後設資料
>  7.3.8.9.1. 後設資料是關於資料的資料

>  7.3.8.9.2. 後設資料和資料本身一樣重要

>  7.3.8.9.3. 沒有對資料的詳細描述，它就可能沒有什麼價值

8. 推送、拉取與輪詢模式

8.1. 推送策略涉及源系統向目標系統傳送資料

8.2. 拉取策略則需要目標系統直接從源系統讀取資料

8.3. 與拉取有關的模式是輪詢

  • 8.3.1. 輪詢包括定期檢查資料來源的任何變化

  • 8.3.2. 當檢測到變化時，目標系統就會主動拉取資料

相關文章