點擊上方藍色字體，選擇“設爲星標”
回覆”面試“獲取更多驚喜
在讀本文前你應該看過這些：
本篇一個總結的增強版。
網上目前關於 Flink 集成 Hudi、IceBerg的資料較少，社區建設不夠完善。且因爲迭代版本原因，代碼過期嚴重。後面我會專門寫一篇Flink連接Hudi、IceBerg等的文章。
炒作概念還是未來趨勢？
數據湖是目前比較熱的一個概念，許多企業都在構建或者計劃構建自己的數據湖。但是在計劃構建數據湖之前，搞清楚什麼是數據湖，明確一個數據湖項目的基本組成，進而設計數據湖的基本架構，對於數據湖的構建至關重要。關於什麼是數據湖？有不同的定義。
Wikipedia上說數據湖是一類存儲數據自然/原始格式的系統或存儲，通常是對象塊或者文件，包括原始系統所產生的原始數據拷貝以及爲了各類任務而產生的轉換數據，包括來自於關係型數據庫中的結構化數據（行和列）、半結構化數據（如CSV、日誌、XML、JSON）、非結構化數據（如email、文檔、PDF等）和二進制數據（如圖像、音頻、視頻）。AWS定義數據湖是一個集中式存儲庫，允許您以任意規模存儲所有結構化和非結構化數據。
微軟的定義就更加模糊了，並沒有明確給出什麼是Data Lake，而是取巧的將數據湖的功能作爲定義，數據湖包括一切使得開發者、數據科學家、分析師能更簡單的存儲、處理數據的能力，這些能力使得用戶可以存儲任意規模、任意類型、任意產生速度的數據，並且可以跨平臺、跨語言的做所有類型的分析和處理。
關於數據湖的定義其實很多，但是基本上都圍繞着以下幾個特性展開。
1、 數據湖需要提供足夠用的數據存儲能力，這個存儲保存了一個企業/組織中的所有數據。
2、 數據湖可以存儲海量的任意類型的數據，包括結構化、半結構化和非結構化數據。
3、 數據湖中的數據是原始數據，是業務數據的完整副本。數據湖中的數據保持了他們在業務系統中原來的樣子。
4、 數據湖需要具備完善的數據管理能力（完善的元數據），可以管理各類數據相關的要素，包括數據源、數據格式、連接信息、數據schema、權限管理等。
5、 數據湖需要具備多樣化的分析能力，包括但不限於批處理、流式計算、交互式分析以及機器學習；同時，還需要提供一定的任務調度和管理能力。
6、 數據湖需要具備完善的數據生命週期管理能力。不光需要存儲原始數據，還需要能夠保存各類分析處理的中間結果，並完整的記錄數據的分析處理過程，能幫助用戶完整詳細追溯任意一條數據的產生過程。
7、 數據湖需要具備完善的數據獲取和數據發佈能力。數據湖需要能支撐各種各樣的數據源，並能從相關的數據源中獲取全量/增量數據；然後規範存儲。數據湖能將數據分析處理的結果推送到合適的存儲引擎中，滿足不同的應用訪問需求。
8、 對於大數據的支持，包括超大規模存儲以及可擴展的大規模數據處理能力。
綜上，個人認爲數據湖應該是一種不斷演進中、可擴展的大數據存儲、處理、分析的基礎設施；以數據爲導向，實現任意來源、任意速度、任意規模、任意類型數據的全量獲取、全量存儲、多模式處理與全生命週期管理；並通過與各類外部異構數據源的交互集成，支持各類企業級應用。
不同企業的典型應用
目前在生產上可以用的經驗不多，筆者個人在調研技術方案時參考了目前市面上公開的衆多資料，供團隊在數據架構設計和選型上進行參考。
華爲生產場景數據湖平臺建設實踐
該平臺圍繞數據分如下三大邏輯模塊：
典型數據應用場景按應用場景，對數據流程、處理平臺進行的標註：
（綠色）結構化數據通過批處理、虛擬鏡像到Hive數據，再通過Kylin預處理將數據儲存在Cube中，封裝成RESTAPI服務，提供高併發亞秒級查詢服務，監測物料質量情況；
（紅色）IoT數據，通過sensor採集上報到MQS，走storm實時分揀到HBase，通過算法模型加工後進行ICT物料預警監測；
（黃色）條碼數據通過ETLloader到IQ列式數據湖，經過清洗加工後，提供千億規模條碼掃描操作。
非結構化質檢圖片數據：
通過web前臺、數據API服務，進行圖片數據的上傳及查詢，圖片需要有唯一ID作爲標示，確保可檢索。海量圖片數據以ID爲rowkey，儲存於Hbase平臺，提供快速儲存及查詢能力。數據資產上有以下方面的構建：
統一索引描述非結構數據，方便數據檢索分析。
增加維護及更新時間作爲對象描述字段(圖片類型、像素大小、尺寸規格)。非對象方式及數字化屬性編目(全文文本、圖像、聲音、影視、超媒體等信息),自定義元數據。
不同類型的數據可以形成了關聯並處理非結構化數據。
實時金融數據湖的應用
在功能上，包括數據源、統一的數據接入、數據存儲、數據開發、數據服務和數據應用。
第一，數據源。不僅僅支持結構化數據，也支持半結構化數據和非結構化數據。
第二，統一數據接入。數據通過統一數據接入平臺，按數據的不同類型進行智能的數據接入。
第三，數據存儲。包括數據倉庫和數據湖，實現冷熱溫智能數據分佈。
第四，數據開發。包括任務開發，任務調度，監控運維，可視化編程。
第五，數據服務。包括交互式查詢，數據 API，SQL 質量評估，元數據管理，血緣管理。
第六，數據應用。包括數字化營銷，數字化風控，數據化運營，客戶畫像。
在邏輯上，實時金融數據湖的邏輯架構主要有 4 層，包括存儲層、計算層、服務層和產品層。
在存儲層，有 MPP 數據倉庫和基於 OSS/HDFS 的數據湖，可以實現智能存儲管理。
在計算層，實現統一的元數據服務。
在服務層，有聯邦數據計算和數據服務 API 兩種方式。其中，聯邦數據計算服務是一個聯邦查詢引擎，可以實現數據跨庫查詢，它依賴的就是統一元數據服務，查詢的是數據倉庫和數據湖中的數據。
在產品層，提供智能服務：包 RPA、證照識別、語言分析、客戶畫像、智能推薦。商業分析服務：包括自助分析、客戶洞察、可視化。數據開發服務：包括數據開發平臺，自動化治理。
整個實時場景架構：
數據源被實時接入到 Kafka 之後，Flink 可以實時處理 Kafka 的數據，並將處理的結果寫入到數據湖中。數據湖整體基於開源方案搭建，數據的存儲是用的 HDFS 和 S3，表格式用的是 Iceberg。Flink 讀取完 Kafka 的數據之後進行實時處理，這時候可以把處理的中間結果寫入到數據湖中，然後再進行逐步處理，最終得到業務想要的結果。處理的結果可以通過查詢引擎對接應用，包括 Flink、Spark、Presto 等。
Soul的Delta Lake數據湖應用實踐
數據由各端埋點上報至Kafka，通過Spark任務分鐘級以Delta的形式寫入HDFS，然後在Hive中自動化創建Delta表的映射表，即可通過Hive MR、Tez、Presto等查詢引擎直接進行數據查詢及分析。
我們基於Spark，封裝了通用化ETL工具，實現了配置化接入，用戶無需寫代碼即可實現源數據到Hive的整體流程接入。並且，爲了更加適配業務場景，我們在封裝層實現了多種實用功能：
實現了類似Iceberg的hidden partition功能，用戶可選擇某些列做適當變化形成一個新的列，此列可作爲分區列，也可作爲新增列，使用SparkSql操作。如：有日期列date，那麼可以通過 'substr(date,1,4) as year' 生成新列，並可以作爲分區。
爲避免髒數據導致分區出錯，實現了對動態分區的正則檢測功能，比如：Hive中不支持中文分區，用戶可以對動態分區加上'\w+'的正則檢測，分區字段不符合的髒數據則會被過濾。
實現自定義事件時間字段功能，用戶可選數據中的任意時間字段作爲事件時間落入對應分區，避免數據漂移問題。
嵌套Json自定義層數解析，我們的日誌數據大都爲Json格式，其中難免有很多嵌套Json，此功能支持用戶選擇對嵌套Json的解析層數，嵌套字段也會被以單列的形式落入表中。
實現SQL化自定義配置動態分區的功能，解決埋點數據傾斜導致的實時任務性能問題，優化資源使用，此場景後面會詳細介紹。
數據湖方案調研
1、Iceberg
Iceberg 作爲新興的數據湖框架之一，開創性的抽象出“表格式”table format"這一中間層，既獨立於上層的計算引擎（如Spark和Flink）和查詢引擎（如Hive和Presto），也和下層的文件格式（如Parquet，ORC和Avro）相互解耦。
此外 Iceberg 還提供了許多額外的能力：
ACID事務；
時間旅行（time travel），以訪問之前版本的數據
完備的自定義類型、分區方式和操作的抽象
列和分區方式可以進化，而且進化對用戶無感，即無需重新組織或變更數據文件
隱式分區，使SQL不用針對分區方式特殊優化
面向雲存儲的優化等
Iceberg的架構和實現並未綁定於某一特定引擎，它實現了通用的數據組織格式，利用此格式可以方便地與不同引擎（如Flink、Hive、Spark）對接。
所以 Iceberg 的架構更加的優雅，對於數據格式、類型系統有完備的定義和可進化的設計。
但是 Iceberg 缺少行級更新、刪除能力，這兩大能力是現有數據組織最大的賣點，社區仍然在優化中。
2、Hudi
Hudi 是什麼？
一般來說，我們會將大量數據存儲到HDFS/S3，新數據增量寫入，而舊數據鮮有改動，特別是在經過數據清洗，放入數據倉庫的場景。
且在數據倉庫如 hive中，對於update的支持非常有限，計算昂貴。
另一方面，若是有僅對某段時間內新增數據進行分析的場景，則hive、presto、hbase等也未提供原生方式，而是需要根據時間戳進行過濾分析。
Apache Hudi 代表 Hadoop Upserts and Incrementals，能夠使HDFS數據集在分鐘級的時延內支持變更，也支持下游系統對這個數據集的增量處理。
Hudi數據集通過自定義的 inputFormat 兼容當前 Hadoop 生態系統，包括 Apache Hive，Apache Parquet，Presto 和 Apache Spark，使得終端用戶可以無縫的對接。
如下圖，基於 Hudi 簡化的服務架構，分鐘級延遲。
Hudi 存儲的架構
如上圖，最下面有一個時間軸，這是 Hudi 的核心。
Hudi 會維護一個時間軸，在每次執行操作時（如寫入、刪除、合併等），均會帶有一個時間戳。
通過時間軸，可以實現在僅查詢某個時間點之後成功提交的數據，或是僅查詢某個時間點之前的數據。這樣可以避免掃描更大的時間範圍，並非常高效地只消費更改過的文件（例如在某個時間點提交了更改操作後，僅 query 某個時間點之前的數據，則仍可以 query 修改前的數據）。
如上圖的左邊，Hudi 將數據集組織到與 Hive 表非常相似的基本路徑下的目錄結構中。
數據集分爲多個分區，每個分區均由相對於基本路徑的分區路徑唯一標識。
如上圖的中間部分，Hudi 以兩種不同的存儲格式存儲所有攝取的數據。
讀優化的列存格式（ROFormat）：僅使用列式文件（parquet）存儲數據。在寫入/更新數據時，直接同步合併原文件，生成新版本的基文件（需要重寫整個列數據文件，即使只有一個字節的新數據被提交）。此存儲類型下，寫入數據非常昂貴，而讀取的成本沒有增加，所以適合頻繁讀的工作負載，因爲數據集的最新版本在列式文件中始終可用，以進行高效的查詢。
寫優化的行存格式（WOFormat）：使用列式（parquet）與行式（avro）文件組合，進行數據存儲。在更新記錄時，更新到增量文件中（avro）， 然後進行異步（或同步）的compaction，創建列式文件（parquet）的新版本。此存儲類型適合頻繁寫的工作負載，因爲新記錄是以appending 的模式寫入增量文件中。但是在讀取數據集時，需要將增量文件與舊文件進行合併，生成列式文件。
3、DeltaLake
傳統的 lambda 架構需要同時維護批處理和流處理兩套系統，資源消耗大，維護複雜。基於 Hive 的數倉或者傳統的文件存儲格式（比如 parquet / ORC），都存在一些難以解決的問題：
小文件問題
併發讀寫問題
有限的更新支持
海量元數據（例如分區）導致 metastore 不堪重負
如上圖，Delta Lake 是 Spark 計算框架和存儲系統之間帶有 Schema 信息的存儲中間層。它有一些重要的特性：
設計了基於 HDFS 存儲的元數據系統，解決 metastore 不堪重負的問題；
支持更多種類的更新模式，比如 Merge / Update / Delete 等操作，配合流式寫入或者讀取的支持，讓實時數據湖變得水到渠成；
流批操作可以共享同一張表；
版本概念，可以隨時回溯，避免一次誤操作或者代碼邏輯而無法恢復的災難性後果。
Delta Lake 是基於 Parquet 的存儲層，所有的數據都是使用 Parquet 來存儲，能夠利用 parquet 原生高效的壓縮和編碼方案。
Delta Lake 在多併發寫入之間提供 ACID 事務保證。每次寫入都是一個事務，並且在事務日誌中記錄了寫入的序列順序。
事務日誌跟蹤文件級別的寫入並使用樂觀併發控制，這非常適合數據湖，因爲多次寫入/修改相同的文件很少發生。在存在衝突的情況下，Delta Lake 會拋出併發修改異常以便用戶能夠處理它們並重試其作業。
Delta Lake 其實只是一個 Lib 庫，不是一個 service，不需要單獨部署，而是直接依附於計算引擎的，但目前只支持 spark 引擎，使用過程中和 parquet 唯一的區別是把 format parquet 換成 delta 即可，可謂是部署和使用成本極低。
數據湖技術比較
總結
Flink CDC我喫定了耶穌也留不住他！| Flink CDC線上問題小盤點
4萬字長文 | ClickHouse基礎&實踐&調優全視角解析
你好，我是王知無，一個大數據領域的硬核原創作者。
做過後端架構、數據中間件、數據平臺&架構、算法工程化。
專注大數據領域實時動態&技術提升&個人成長&職場進階，歡迎關注。
本文分享自微信公衆號 - 大數據技術與架構（import_bigdata）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。