讀資料工程之道：設計和構建健壯的資料系統32序列化和雲網路

躺柒發表於2024-11-09

1. 序列化

1.1. 僅僅透過從CSV轉換到Parquet序列化，任務效能就提高了上百倍

1.2. 基於行的序列化

  • 1.2.1. 基於行的序列化是按行來組織資料

  • 1.2.2. 對於那些半結構化的資料（支援巢狀和模式變化的資料物件）​，基於行的序列化需要將每個物件作為一個單元來儲存

  • 1.2.3. CSV格式是一種典型的基於行的格式

  • 1.2.3.1. CSV：不是標準的標準

  • 1.2.3.2. CSV本質上是分隔符文字的總稱，但不同的CSV檔案在轉義、引號字元、分隔符等的使用上會有所變化

  • 1.2.3.3. 應該避免在管道中使用CSV檔案，因為它們非常容易出錯，而且效能很差

  • 1.2.3.4. 使用CSV進行歸檔，要附帶上檔案的序列化配置的完整技術描述，以便未來的資料消費者獲取資料

  • 1.2.4. XML

  • 1.2.4.1. XML是資料工程師在與傳統系統和軟體交換資料時經常必須處理的另一種標準

  • 1.2.5. JSON和JSONL

  • 1.2.5.1. JSON已經在純文字物件序列化上很大程度地取代了XML

  • 1.2.5.2. JavaScript物件表示法(JSON)已經成為透過API資料交換的新標準，以及一種非常流行的資料儲存格式

  • 1.2.5.3. JSON Lines(JSONL)是JSON的一個專門版本，用於將批次半結構化資料儲存在檔案中

  • 1.2.5.4. JSONL是一種非常有用的格式，可以在從API或應用程式獲取資料後立即儲存資料

  • 1.2.6. Avro

  • 1.2.6.1. Avro是一種面向行的資料格式，用於遠端過程呼叫和資料序列化

  • 1.2.6.2. Avro將資料編碼為二進位制格式，其模式的後設資料為JSON形式

1.3. 列序列化

  • 1.3.1. 透過列序列化，每列資料都會分為多個檔案

  • 1.3.2. 列儲存的一個明顯優勢是，它從欄位的子集中讀取資料，而不是一次性讀取整行資料

  • 1.3.2.1. 分析應用程式常用列序列化，它可以大大減少執行查詢時必須掃描的資料量

  • 1.3.3. 將資料儲存為列還可以將相似的值聚集，讓每列資料的排列更有效率

  • 1.3.4. 一種常見的壓縮技術是尋找重複的值並對其進行標記，對於有大量重複資料的列來說簡單又高效

  • 1.3.5. 列式資料庫對於事務性工作負載來說是非常不合適的，所以事務資料庫通常會利用一些面向行或記錄的儲存方式

  • 1.3.6. Parquet

  • 1.3.6.1. Parquet以列格式儲存資料，旨在實現資料湖環境中的出色讀寫效能

  • 1.3.6.2. 與CSV不同，Parquet方式儲存的資料建立在模式資訊中，並原生支援巢狀資料

  • 1.3.6.3. 與Parquet相比，雖然BigQuery和Snowflake等資料庫以專有的列格式序列化資料，併為其內部儲存的資料提供很好的查詢效能，但在與外部工具互操作時會產生巨大的效能下降

  • 1.3.6.4. 儲存的資料需要被反序列化，並重新序列化為可交換的格式，才能使用如Spark和Presto等資料湖工具操作

  • 1.3.7. ORC

  • 1.3.7.1. 行最佳化列儲存(Optimized Row Columnar，ORC)是一種類似於Parquet的列儲存格式

  • 1.3.8. Apache Arrow

  • 1.3.8.1. 利用二進位制資料格式來重新設計序列化，這種格式既適合在記憶體中處理，也適合在系統間傳輸

  • 1.3.8.2. Arrow使用列儲存，其中每一列基本上都有自己的記憶體塊

  • 1.3.8.3. 對於巢狀的資料，我們會使用一種叫作粉碎的技術，將JSON文件模式中的每個位置都對映成單獨的列

  • 1.3.8.4. 意味著資料檔案可以儲存在磁碟上，透過使用虛擬記憶體將其直接交換到程式地址空間並執行資料查詢，沒有反序列化的開銷

  • 1.3.8.5. 為各種程式語言（包括C、Go、Java、JavaScript、MATLAB、Python、R和Rust）建立了庫，允許這些語言與在記憶體中的Arrow資料互通

  • 1.3.8.6. Dremio，它是一個基於Arrow序列化，支援高速查詢的查詢引擎和資料倉儲

1.4. 混合序列化

  • 1.4.1. Hudi

  • 1.4.1.1. Hadoop Update Delete Incremental的縮寫

  • 1.4.1.2. 一種表管理技術結合了多種序列化技術，讓分析查詢擁有列式資料庫的效能，同時能進行原子式的、事務性的記錄更新

  • 1.4.2. Iceberg

  • 1.4.2.1. 一種表管理技術

2. 資料庫儲存引擎

2.1. 儲存引擎通常是獨立於查詢引擎的一個軟體層

2.2. 儲存引擎管理資料在磁碟上儲存的所有相關資訊，包括序列化方式、資料的最底層排布和索引

2.3. 另一個主要發展方向是服務於分析和資料倉儲應用程式的列儲存

  • 2.3.1. SQL Server、PostgreSQL和MySQL都有強大的列儲存支援

3. 壓縮演算法

3.1. 無失真壓縮演算法

  • 3.1.1. 用無損演算法解壓縮編碼的資料會完整恢復到原始資料

  • 3.1.2. 在對資料保真度有要求的分析序列化過程中使用無失真壓縮演算法

3.2. 音訊、影像和影片的有失真壓縮演算法旨在實現感官上的保真，解壓縮恢復的東西聽起來像或看起來像原件，但不精確

  • 3.2.1. 資料工程師可能會在媒體處理管道中使用有失真壓縮演算法

3.3. 傳統的壓縮引擎如gzip和bzip2非常適合處理文字資料

  • 3.3.1. 經常被應用於JSON、JSONL、XML、CSV和其他基於文字的資料格式

3.4. 新一代的壓縮演算法，將速度和CPU效率置於壓縮率之上

  • 3.4.1. 主要有Snappy、Zstandard、LZFSE和LZ4等

4. 雲網路

4.1. 雲網路拓撲結構描述了雲中各種元件的排列和連線方式，如雲服務、網路、位置（區域）等

4.2. 資料出口費用

  • 4.2.1. 在網路定價方面，雲提供商會讓入站流量免費但對出站流量收費

  • 4.2.2. 出站流量本身並不比入站便宜，但云提供商用這種方法在它們的服務周圍創造了一條護城河，並且增加了所儲存資料的黏性

  • 4.2.3. 資料出口費也適用於雲的可用區或區域之間的資料傳輸

  • 4.2.4. 資料出口費是阻礙互操作性、資料共享和資料向雲端移動的重要因素

  • 4.2.5. 資料出口費是雲供應商的護城河，防止公有云客戶離開或在多個雲中部署

4.3. 可用區是公有云向客戶暴露的最小的網路拓撲單元

  • 4.3.1. 一個區內的系統和服務之間一般會有最高的網路頻寬和最低的延時

  • 4.3.2. 傳送到區內虛擬機器的網路流量是免費的，但有明顯的限制：流量必須傳送到私有IP地址

4.4. 區域是兩個或多個可用區的集合

  • 4.4.1. 資料中心的執行需要依賴許多資源（電力、水等）

  • 4.4.2. 各個可用區的所用資源是獨立的

  • 4.4.3. 多區域意味著資源可以放在靠近使用者的地方

  • 4.4.4. 區域在可用區之間支援快速、低延遲的網路

  • 4.4.5. 可用區間的網路效能將比單個可用區內的差，並在虛擬機器之間產生名義上的資料輸出費用

4.5. 谷歌實際上擁有比其他雲提供商多得多的全球規模網路資源，它可以給使用者提供高階網路服務

  • 4.5.1. 高階網路的區域之間流量可以只走谷歌的網路，不走公網

4.6. 流的公有云都提供加強版連線的選項，客戶可以將自己的網路與雲的某個區域或VPC直接整合

4.7. 內容分成服務可以為向公眾或客戶傳送資料資產提供巨大的效能提升和折扣

相關文章