数据湖之iceberg系列(一)iceberg能做什么
1 前言 HIVE的缺陷
Hive的元數據依賴一個外部的MySQL和HDFS文件系統，通過MySQL找到相關的parition之后，需要為每個partition去HDFS文件系統上按照分區做目錄的list操作。在文件量大的情況下，這是一個非常耗時的操作。
同時，由于元數據分屬MySQL和HDFS管理，寫入操作本身的原子性難以保證。即使在開啟Hive ACID情況下，仍有很多細小場景無法保證原子性。另外，Hive Metastore沒有文件級別的統計信息，這使得filter只能下推到partition級別，而無法下推到文件級別，對上層分析性能損耗無可避免。
在處理數據的時候 hive對數據的變化沒有相應的管理, 數據的合并的抽取需要使用拉鏈表操作,操作相對比較復雜 !
雖然目前從功能上看不如前面兩者豐富，但由于它牢固堅實的底層設計，一旦功能補齊，將成為一個非常有潛力的開源數據湖方案。
當前大數據發展的三大趨勢：
數據倉庫往數據湖方向發展
批處理往流式處理發展
本地部署往云模式發展
數據湖簡介
數據湖應該具備以下功能
同時支持流批處理
支持數據更新
支持事務（ACID）
可擴展的元數據
數據質量保障
支持多種存儲引擎
支持多種計算引擎
Apache Iceberg 原理介紹
?
Apache Iceberg 是一種用于跟蹤超大規模表的新格式，是專門為對象存儲（如S3）而設計的。其核心思想：在時間軸上跟蹤表的所有變化。
快照（snapshot）表示表數據文件的一個完整集合
每次更新操作會生成一個新的快照。
Iceberg的優點
優化數據入庫流程：Iceberg 提供 ACID 事務能力，上游數據寫入即可見，不影響當前數據處理任務，這大大簡化了 ETL；Iceberg 提供了 upsert、merge into 能力，可以極大地縮小數據入庫延遲；
支持更多的分析引擎：優秀的內核抽象使之不綁定特定的計算引擎，目前 Iceberg 支持的計算引擎有 Spark、Flink、Presto 以及 Hive。
統一數據存儲和靈活的文件組織：提供了基于流式的增量計算模型和基于批處理的全量表計算模型。批處理和流任務可以使用相同的存儲模型，數據不再孤立；Iceberg 支持隱藏分區和分區進化，方便業務進行數據分區策略更新。支持 Parquet、Avro 以及 ORC 等存儲格式。
增量讀取處理能力：Iceberg 支持通過流式方式讀取增量數據，支持 Structed Streaming 以及 Flink table Source
Iceberg 的快照設計方式，主要包括快照隔離以及對于文件列表的所有修改都是原子操作。
元數據組織包括：
實現基于快照的跟蹤方式；
表的元數據是不可修改的，并且始終向前迭代；
當前的快照可以回退。
沒有使用數據湖技術，我們需要很多組件來保證 exactly-once 語義。并且利用 HDFS 的 rename 操作的原子性和復雜的命名規則來保證一致性、可見性。利用調度引擎來構建依賴關系，從而避免讀寫沖突。
上面架構存在的問題：架構比較復雜，需要不同組件之間的協調；架構的復雜會進一步導致數據的延遲。exactly-once 語義保證比較復雜，增加了運維的難度。
有了 Iceberg 之后，整體架構簡單了，而且通過簡單的架構即可實現原子語義。Iceberg 格式的數據直接可以使用 Hive、Spark 來讀取；同時，Iceberg 支持讀寫分區，寫入并且 commit 的數據下游系統立即可以使用，降低系統的整體延遲。
同時，Iceberg 技術還催生了新的架構，也就是 CDC 架構。其相比傳統的架構而言整體系統架構更加簡潔，端到端的延遲大大降低，而且支持 ACID 事務能力。
————————————————
版權聲明：本文為CSDN博主「白眼黑刺猬」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_37933018/article/details/110230440
總結
以上是生活随笔為你收集整理的数据湖之iceberg系列(一)iceberg能做什么的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 数据湖之iceberg系列(三)iceb
- 下一篇： 数据湖之iceberg系列(四)iceb