Apache Iceberg筆記1_DataLake三劍客之一
一般在業界實務如果有談論到關於DataLake數據湖，通常主流想到的
三劍客為:Hudi、Delta Lake和Iceberg
數據湖一詞觀念在之前準備Data Literacy Fundamentals學習筆記有稍微提及到。
目的在處理現代組織產生的大量數據，它們提供了一種經濟且高效的方式來儲存和管理大數據。數據湖建立在分散式檔案系統(distributed file systems)之上，例如Hadoop 分散式檔案系統(HDFS)或Amazon S3，可以處理大量數據並提供高可用性和高擴展性。
數據湖通常使用於：
• 儲存原始數據供以後分析
• 執行大數據處理和分析
• 支持機器學習和人工智慧
• 儲存和處理即時串流數據
Apache Iceberg是由netflex於2018年研發並開源貢獻給Apache基金會，為數據湖三劍客之一。
2018年11月16日進入Apache孵化器，於2020年5月19日從孵化器畢業，成為Apache的top專案。
- 主要用於大數據分析高性能開放性表格形式(Table Format)。
- 表格形式(Table Format)可以這樣解釋，metadata跟數據文件一種組織方式，處於計算引擎框架(Spark、Flink....)之下，數據文件之上。
- 在數據儲存和計算引擎之間的調配問題。原理類似Hive，但Hive依賴於HDFS檔案系統。換言之他可以跟很多常見到的資料庫或大數據生態系的工具兼容，比方Hive、Spark、Flink、Presto 、Impala等等，都可以去操作IceBerg的Table。
- 提供高表達性SQL
- 支持隱藏分區
- 具有完整模式演化
- 可以對表作快照(時間旅行、回滾)
Netflex最初也是用Hive去處理海量資料，後來發覺不好用就自行研發IceBerg了。
Hive跟IceBerg其實都是在數據儲存之上和計算引擎之下，也都提供表格式存取。
Hive在之前此篇部落格文章也有紀載到。
而當時Netflex之所以覺得Hive不好用原因在於，如下幾個原因:
1. Schema 演進支援不佳（Schema Evolution Poor Support）
- Hive 表雖然支援 schema 變更（加欄位、改型態），但會導致舊資料讀取行為不一致。
- Hive 的 schema 是綁在 metadata 上，而不是每個檔案有自己的 schema 定義。
- 這會在多人共享表格、大規模數據演進時帶來困擾。
2. 查詢一致性差（Lack of Snapshot Isolation）
- Hive 沒有原生的 snapshot 機制（快照隔離），例如：寫入進行中，讀取端可能會看到部分寫入資料、多人同時查詢或修改表格，結果可能不一致。
- 對需要高一致性的大型數據平台來說，是很致命的問題。
3. Metadata 管理效率低（Inefficient Metadata Handling）
- Hive 的 metadata 存在 Hive Metastore 中，當 partition 非常多（上萬個）時：
- 管理複雜
- 查詢 metadata 開銷大，列出 partition 甚至可能超時。
- Hive 會頻繁掃描底層檔案系統來解析檔案和目錄，不符合現代數據湖架構要求。
(備註:Hive分區儲存是一個分區一個目錄)
4. 寫入性能差（Write Performance Poor）
- Hive 不支援 ACID 的寫入操作（直到後來才有限度支援，但依賴特定設置和格式）。
- Append 模式為主，無法輕鬆進行 update/delete/merge 等操作。
- 難以做流式資料 ingestion、即時更新的應用。
Hive可以分區，若用時間一天24小時，以一個小時來分區。
一天就有24個分區，一個月就是24*30個分區。在往後繼續擴展1年.....2年。就出現一個問題，分區數量會過多。雖然查metadata是快，但去回推真實數據時候就相對耗時。
Hive會有一個metadata儲存的DB通常選用MySql，但通常只記錄到分區級別。
此外Hive是一個分區一個目錄在儲存，而真實要存取的資料都是在HDFS，因此他需要到HDFS上面去掃描所有目錄，並且再去篩選想要的目錄。
別於Hive只能定位到分區(目錄)級別，Iceberg則可定位到文件級別。解決傳統Hive分區、文件掃描過慢的痛點。Hive 表是「目錄驅動」的（Directory-Driven Table），而 Iceberg 是「元資料驅動」（Metadata-Driven Table）
留言
張貼留言