資料湖與湖倉

為了解決上述資料倉儲所遭遇之問題，工程師們發展出了資料湖 (Data Lake)這種分析架構，從上圖可以得知資料湖的特性：

• *Open file format 應用：將非結構化/半結構化資料轉換成 Open file formats 如：Avro, ORC, Parquet
• *Object storage 應用：將轉換後的非結構化/半結構化資料儲存於成本較低廉的 Object storage
• *Schema-on-read 應用：僅於查詢操作時對資料套用 Schema

*Open file format
各種開源且標準化的資料儲存格式，允許跨系統/平台做存取，幾種常見格式如下：

1. Avro:一種列儲存資料格式，易用於大量交易寫入
2. ORC:一種行儲存資料格式，擁有儲存效能佳的特性
3. Parquet:一種行儲存資料格式，常用於AI/ML資料訓練

*Object storage
一種將資料以「物件」形式儲存的格式，包含以下幾個部分：

1. Actual Data：即真實資料，可為結構化或非結構化
2. Metadata：真實資料的特性，如：資料大小、格式、權限等
3. A unique identifier：用於找尋「物件」位置的指標

*Schema-on-read
相對於 Schema-on-write 需在寫入前定義好Schema：
1.僅在查詢操作時對資料套用Schema
2.寫入時比 Schema-on-write 快速，因不必對 Schema 進行檢查
3.讀取時較 Schema-on-write 慢，因還需進行 Schema 套用

資料湖雖解決先前架構對非結構化資料沒輒的問題，也使用 Open file format 脫離 Vendor-lock-in 的魔爪，但卻未完全脫離 ETL 的束縛，所以如資料陳舊、資料品質風險等問題，依然存在於此架構。

另外也衍生了一些其他問題，如：

• 半結構化/非結構化資料無法支援 ACID 交易保證
• Schema-on-read 使查詢操作變慢 (沒有 index/partition 等設計)

要解決資料倉儲架構 ETL 流程產生的資料問題，又要使資料湖的查詢效能媲美資料倉儲，最好的辦法就是：捨棄 ETL，並且將資料湖改造成查詢效能優化的形狀，聽起來很貪心，但資料湖倉的誕生消除了大家的懷疑：

• 取消 ETL 流程：將結構/非結構化資料皆放在資料湖中
• 使用 Metadata layer：在資料湖既有 Object store 上新增 Metadata layer，用於管理資料版本、滿足交易保證及交易特性
• 使用快取 (Caching)：將經常訪問之資料放在 SSD 上快取，增加查詢效能
• 附加資料架構 (Auxiliary Data Structures)：使用如 indexes, bloom filters, partition maps, 和基本資料統計值(min, max..)增加查詢效能
• 資料佈局優化 (Data Layout Optimization)：使用如分群 (Z-Order clustering)、分區 (partitioning)、檔案壓縮等技術增加查詢效能

從倉儲到湖倉

依上節所述，資料湖倉可以算是資料工程界劃時代般的產物，但真的有那麼好？這應該是閱讀完資料的工程師們有的共同疑問，這邊分享 Databricks 與 UC berkely 共同做的實驗結果：

1. 資料倉儲：這邊使用的是四個知名的雲端資料倉儲 (名字被碼掉了)
2. 資料湖倉：這邊使用的是 Databricks 公司的 Delta Engine 搭配他們自家的 Delta Lake
3. 測試方式：使用 *TPC/DS 基準測試，用 30TB 的資料集測試 99 queries (包含匯總、子查詢等複雜 Query) 的效能
4. 測試結果：下圖紅色部分是 Delta engine 在 on-demand instance以及 spot instance下 的表現，可以看到：
   • 查詢時間：Delta engine 表現皆與四間雲端倉儲廠商持平或更優
   • 查詢成本：Delta engine 表現皆顯著低於四間雲端倉儲廠商

明日預告

系列文明日《初探Trino》，將進入本系列文的重點，資料湖倉查詢引擎-Trino，筆者會從 Trino 的定位、組成架構、對資料來源的存取與管理模式等方面，將 Trino 的輪廓較具體的描繪出來。

Know me more

My Linkedin: https://www.linkedin.com/in/benny0624/
My Medium: https://hndsmhsu.medium.com/