數(shù)據(jù)湖在大數(shù)據(jù)場景下應(yīng)用和實施方案調(diào)研筆記(增強版)

在讀本文前你應(yīng)該看過這些：

《我看好數(shù)據(jù)湖的未來，但不看好數(shù)據(jù)湖的現(xiàn)在》

《數(shù)據(jù)湖解決方案關(guān)鍵一環(huán)，IceBerg會不會脫穎而出？》

本篇一個總結(jié)的增強版。

網(wǎng)上目前關(guān)于 Flink 集成 Hudi、IceBerg的資料較少，社區(qū)建設(shè)不夠完善。且因為迭代版本原因，代碼過期嚴重。后面我會專門寫一篇Flink連接Hudi、IceBerg等的文章。

炒作概念還是未來趨勢？

數(shù)據(jù)湖是目前比較熱的一個概念，許多企業(yè)都在構(gòu)建或者計劃構(gòu)建自己的數(shù)據(jù)湖。但是在計劃構(gòu)建數(shù)據(jù)湖之前，搞清楚什么是數(shù)據(jù)湖，明確一個數(shù)據(jù)湖項目的基本組成，進而設(shè)計數(shù)據(jù)湖的基本架構(gòu)，對于數(shù)據(jù)湖的構(gòu)建至關(guān)重要。關(guān)于什么是數(shù)據(jù)湖？有不同的定義。

Wikipedia上說數(shù)據(jù)湖是一類存儲數(shù)據(jù)自然/原始格式的系統(tǒng)或存儲，通常是對象塊或者文件，包括原始系統(tǒng)所產(chǎn)生的原始數(shù)據(jù)拷貝以及為了各類任務(wù)而產(chǎn)生的轉(zhuǎn)換數(shù)據(jù)，包括來自于關(guān)系型數(shù)據(jù)庫中的結(jié)構(gòu)化數(shù)據(jù)（行和列）、半結(jié)構(gòu)化數(shù)據(jù)（如CSV、日志、XML、JSON）、非結(jié)構(gòu)化數(shù)據(jù)（如email、文檔、PDF等）和二進制數(shù)據(jù)（如圖像、音頻、視頻）。AWS定義數(shù)據(jù)湖是一個集中式存儲庫，允許您以任意規(guī)模存儲所有結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。

微軟的定義就更加模糊了，并沒有明確給出什么是Data Lake，而是取巧的將數(shù)據(jù)湖的功能作為定義，數(shù)據(jù)湖包括一切使得開發(fā)者、數(shù)據(jù)科學家、分析師能更簡單的存儲、處理數(shù)據(jù)的能力，這些能力使得用戶可以存儲任意規(guī)模、任意類型、任意產(chǎn)生速度的數(shù)據(jù)，并且可以跨平臺、跨語言的做所有類型的分析和處理。

關(guān)于數(shù)據(jù)湖的定義其實很多，但是基本上都圍繞著以下幾個特性展開。

1、 數(shù)據(jù)湖需要提供足夠用的數(shù)據(jù)存儲能力，這個存儲保存了一個企業(yè)/組織中的所有數(shù)據(jù)。

2、 數(shù)據(jù)湖可以存儲海量的任意類型的數(shù)據(jù)，包括結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。

3、 數(shù)據(jù)湖中的數(shù)據(jù)是原始數(shù)據(jù)，是業(yè)務(wù)數(shù)據(jù)的完整副本。數(shù)據(jù)湖中的數(shù)據(jù)保持了他們在業(yè)務(wù)系統(tǒng)中原來的樣子。

4、 數(shù)據(jù)湖需要具備完善的數(shù)據(jù)管理能力（完善的元數(shù)據(jù)），可以管理各類數(shù)據(jù)相關(guān)的要素，包括數(shù)據(jù)源、數(shù)據(jù)格式、連接信息、數(shù)據(jù)schema、權(quán)限管理等。

5、 數(shù)據(jù)湖需要具備多樣化的分析能力，包括但不限于批處理、流式計算、交互式分析以及機器學習；同時，還需要提供一定的任務(wù)調(diào)度和管理能力。

6、 數(shù)據(jù)湖需要具備完善的數(shù)據(jù)生命周期管理能力。不光需要存儲原始數(shù)據(jù)，還需要能夠保存各類分析處理的中間結(jié)果，并完整的記錄數(shù)據(jù)的分析處理過程，能幫助用戶完整詳細追溯任意一條數(shù)據(jù)的產(chǎn)生過程。

7、 數(shù)據(jù)湖需要具備完善的數(shù)據(jù)獲取和數(shù)據(jù)發(fā)布能力。數(shù)據(jù)湖需要能支撐各種各樣的數(shù)據(jù)源，并能從相關(guān)的數(shù)據(jù)源中獲取全量/增量數(shù)據(jù)；然后規(guī)范存儲。數(shù)據(jù)湖能將數(shù)據(jù)分析處理的結(jié)果推送到合適的存儲引擎中，滿足不同的應(yīng)用訪問需求。

8、 對于大數(shù)據(jù)的支持，包括超大規(guī)模存儲以及可擴展的大規(guī)模數(shù)據(jù)處理能力。

綜上，個人認為數(shù)據(jù)湖應(yīng)該是一種不斷演進中、可擴展的大數(shù)據(jù)存儲、處理、分析的基礎(chǔ)設(shè)施；以數(shù)據(jù)為導(dǎo)向，實現(xiàn)任意來源、任意速度、任意規(guī)模、任意類型數(shù)據(jù)的全量獲取、全量存儲、多模式處理與全生命周期管理；并通過與各類外部異構(gòu)數(shù)據(jù)源的交互集成，支持各類企業(yè)級應(yīng)用。

不同企業(yè)的典型應(yīng)用

目前在生產(chǎn)上可以用的經(jīng)驗不多，筆者個人在調(diào)研技術(shù)方案時參考了目前市面上公開的眾多資料，供團隊在數(shù)據(jù)架構(gòu)設(shè)計和選型上進行參考。

華為生產(chǎn)場景數(shù)據(jù)湖平臺建設(shè)實踐

該平臺圍繞數(shù)據(jù)分如下三大邏輯模塊：

典型數(shù)據(jù)應(yīng)用場景按應(yīng)用場景，對數(shù)據(jù)流程、處理平臺進行的標注：

• （綠色）結(jié)構(gòu)化數(shù)據(jù)通過批處理、虛擬鏡像到Hive數(shù)據(jù)，再通過Kylin預(yù)處理將數(shù)據(jù)儲存在Cube中，封裝成RESTAPI服務(wù)，提供高并發(fā)亞秒級查詢服務(wù)，監(jiān)測物料質(zhì)量情況；

• （紅色）IoT數(shù)據(jù)，通過sensor采集上報到MQS，走storm實時分揀到HBase，通過算法模型加工后進行ICT物料預(yù)警監(jiān)測；

• （黃色）條碼數(shù)據(jù)通過ETLloader到IQ列式數(shù)據(jù)湖，經(jīng)過清洗加工后，提供千億規(guī)模條碼掃描操作。

非結(jié)構(gòu)化質(zhì)檢圖片數(shù)據(jù)：

通過web前臺、數(shù)據(jù)API服務(wù)，進行圖片數(shù)據(jù)的上傳及查詢，圖片需要有唯一ID作為標示，確?？蓹z索。海量圖片數(shù)據(jù)以ID為rowkey，儲存于Hbase平臺，提供快速儲存及查詢能力。數(shù)據(jù)資產(chǎn)上有以下方面的構(gòu)建：

• 統(tǒng)一索引描述非結(jié)構(gòu)數(shù)據(jù)，方便數(shù)據(jù)檢索分析。

• 增加維護及更新時間作為對象描述字段(圖片類型、像素大小、尺寸規(guī)格)。非對象方式及數(shù)字化屬性編目(全文文本、圖像、聲音、影視、超媒體等信息),自定義元數(shù)據(jù)。

• 不同類型的數(shù)據(jù)可以形成了關(guān)聯(lián)并處理非結(jié)構(gòu)化數(shù)據(jù)。

實時金融數(shù)據(jù)湖的應(yīng)用

在功能上，包括數(shù)據(jù)源、統(tǒng)一的數(shù)據(jù)接入、數(shù)據(jù)存儲、數(shù)據(jù)開發(fā)、數(shù)據(jù)服務(wù)和數(shù)據(jù)應(yīng)用。

• 第一，數(shù)據(jù)源。不僅僅支持結(jié)構(gòu)化數(shù)據(jù)，也支持半結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)。

• 第二，統(tǒng)一數(shù)據(jù)接入。數(shù)據(jù)通過統(tǒng)一數(shù)據(jù)接入平臺，按數(shù)據(jù)的不同類型進行智能的數(shù)據(jù)接入。

• 第三，數(shù)據(jù)存儲。包括數(shù)據(jù)倉庫和數(shù)據(jù)湖，實現(xiàn)冷熱溫智能數(shù)據(jù)分布。

• 第四，數(shù)據(jù)開發(fā)。包括任務(wù)開發(fā)，任務(wù)調(diào)度，監(jiān)控運維，可視化編程。

• 第五，數(shù)據(jù)服務(wù)。包括交互式查詢，數(shù)據(jù) API，SQL 質(zhì)量評估，元數(shù)據(jù)管理，血緣管理。

• 第六，數(shù)據(jù)應(yīng)用。包括數(shù)字化營銷，數(shù)字化風控，數(shù)據(jù)化運營，客戶畫像。

在邏輯上，實時金融數(shù)據(jù)湖的邏輯架構(gòu)主要有 4 層，包括存儲層、計算層、服務(wù)層和產(chǎn)品層。

• 在存儲層，有 MPP 數(shù)據(jù)倉庫和基于 OSS/HDFS 的數(shù)據(jù)湖，可以實現(xiàn)智能存儲管理。

• 在計算層，實現(xiàn)統(tǒng)一的元數(shù)據(jù)服務(wù)。

• 在服務(wù)層，有聯(lián)邦數(shù)據(jù)計算和數(shù)據(jù)服務(wù) API 兩種方式。其中，聯(lián)邦數(shù)據(jù)計算服務(wù)是一個聯(lián)邦查詢引擎，可以實現(xiàn)數(shù)據(jù)跨庫查詢，它依賴的就是統(tǒng)一元數(shù)據(jù)服務(wù)，查詢的是數(shù)據(jù)倉庫和數(shù)據(jù)湖中的數(shù)據(jù)。

• 在產(chǎn)品層，提供智能服務(wù)：包 RPA、證照識別、語言分析、客戶畫像、智能推薦。商業(yè)分析服務(wù)：包括自助分析、客戶洞察、可視化。數(shù)據(jù)開發(fā)服務(wù)：包括數(shù)據(jù)開發(fā)平臺，自動化治理。

整個實時場景架構(gòu)：

數(shù)據(jù)源被實時接入到 Kafka 之后，F(xiàn)link 可以實時處理 Kafka 的數(shù)據(jù)，并將處理的結(jié)果寫入到數(shù)據(jù)湖中。數(shù)據(jù)湖整體基于開源方案搭建，數(shù)據(jù)的存儲是用的 HDFS 和 S3，表格式用的是 Iceberg。Flink 讀取完 Kafka 的數(shù)據(jù)之后進行實時處理，這時候可以把處理的中間結(jié)果寫入到數(shù)據(jù)湖中，然后再進行逐步處理，最終得到業(yè)務(wù)想要的結(jié)果。處理的結(jié)果可以通過查詢引擎對接應(yīng)用，包括 Flink、Spark、Presto 等。

Soul的Delta Lake數(shù)據(jù)湖應(yīng)用實踐

數(shù)據(jù)由各端埋點上報至Kafka，通過Spark任務(wù)分鐘級以Delta的形式寫入HDFS，然后在Hive中自動化創(chuàng)建Delta表的映射表，即可通過Hive MR、Tez、Presto等查詢引擎直接進行數(shù)據(jù)查詢及分析。

我們基于Spark，封裝了通用化ETL工具，實現(xiàn)了配置化接入，用戶無需寫代碼即可實現(xiàn)源數(shù)據(jù)到Hive的整體流程接入。并且，為了更加適配業(yè)務(wù)場景，我們在封裝層實現(xiàn)了多種實用功能：

• 實現(xiàn)了類似Iceberg的hidden partition功能，用戶可選擇某些列做適當變化形成一個新的列，此列可作為分區(qū)列，也可作為新增列，使用SparkSql操作。如：有日期列date，那么可以通過 'substr(date,1,4) as year' 生成新列，并可以作為分區(qū)。

• 為避免臟數(shù)據(jù)導(dǎo)致分區(qū)出錯，實現(xiàn)了對動態(tài)分區(qū)的正則檢測功能，比如：Hive中不支持中文分區(qū)，用戶可以對動態(tài)分區(qū)加上'\w+'的正則檢測，分區(qū)字段不符合的臟數(shù)據(jù)則會被過濾。

• 實現(xiàn)自定義事件時間字段功能，用戶可選數(shù)據(jù)中的任意時間字段作為事件時間落入對應(yīng)分區(qū)，避免數(shù)據(jù)漂移問題。

• 嵌套Json自定義層數(shù)解析，我們的日志數(shù)據(jù)大都為Json格式，其中難免有很多嵌套Json，此功能支持用戶選擇對嵌套Json的解析層數(shù)，嵌套字段也會被以單列的形式落入表中。

• 實現(xiàn)SQL化自定義配置動態(tài)分區(qū)的功能，解決埋點數(shù)據(jù)傾斜導(dǎo)致的實時任務(wù)性能問題，優(yōu)化資源使用，此場景后面會詳細介紹。

數(shù)據(jù)湖方案調(diào)研

1、Iceberg

Iceberg 作為新興的數(shù)據(jù)湖框架之一，開創(chuàng)性的抽象出“表格式”table format"這一中間層，既獨立于上層的計算引擎（如Spark和Flink）和查詢引擎（如Hive和Presto），也和下層的文件格式（如Parquet，ORC和Avro）相互解耦。

此外 Iceberg 還提供了許多額外的能力：

• ACID事務(wù)；

• 時間旅行（time travel），以訪問之前版本的數(shù)據(jù)

• 完備的自定義類型、分區(qū)方式和操作的抽象

• 列和分區(qū)方式可以進化，而且進化對用戶無感，即無需重新組織或變更數(shù)據(jù)文件

• 隱式分區(qū)，使SQL不用針對分區(qū)方式特殊優(yōu)化

• 面向云存儲的優(yōu)化等

Iceberg的架構(gòu)和實現(xiàn)并未綁定于某一特定引擎，它實現(xiàn)了通用的數(shù)據(jù)組織格式，利用此格式可以方便地與不同引擎（如Flink、Hive、Spark）對接。

所以 Iceberg 的架構(gòu)更加的優(yōu)雅，對于數(shù)據(jù)格式、類型系統(tǒng)有完備的定義和可進化的設(shè)計。

但是 Iceberg 缺少行級更新、刪除能力，這兩大能力是現(xiàn)有數(shù)據(jù)組織最大的賣點，社區(qū)仍然在優(yōu)化中。

2、Hudi

Hudi 是什么？

一般來說，我們會將大量數(shù)據(jù)存儲到HDFS/S3，新數(shù)據(jù)增量寫入，而舊數(shù)據(jù)鮮有改動，特別是在經(jīng)過數(shù)據(jù)清洗，放入數(shù)據(jù)倉庫的場景。

且在數(shù)據(jù)倉庫如 hive中，對于update的支持非常有限，計算昂貴。

另一方面，若是有僅對某段時間內(nèi)新增數(shù)據(jù)進行分析的場景，則hive、presto、hbase等也未提供原生方式，而是需要根據(jù)時間戳進行過濾分析。

Apache Hudi 代表 Hadoop Upserts and Incrementals，能夠使HDFS數(shù)據(jù)集在分鐘級的時延內(nèi)支持變更，也支持下游系統(tǒng)對這個數(shù)據(jù)集的增量處理。

Hudi數(shù)據(jù)集通過自定義的 inputFormat 兼容當前 Hadoop 生態(tài)系統(tǒng)，包括 Apache Hive，Apache Parquet，Presto 和 Apache Spark，使得終端用戶可以無縫的對接。

如下圖，基于 Hudi 簡化的服務(wù)架構(gòu)，分鐘級延遲。

1. Hudi 存儲的架構(gòu)

如上圖，最下面有一個時間軸，這是 Hudi 的核心。

Hudi 會維護一個時間軸，在每次執(zhí)行操作時（如寫入、刪除、合并等），均會帶有一個時間戳。

通過時間軸，可以實現(xiàn)在僅查詢某個時間點之后成功提交的數(shù)據(jù)，或是僅查詢某個時間點之前的數(shù)據(jù)。這樣可以避免掃描更大的時間范圍，并非常高效地只消費更改過的文件（例如在某個時間點提交了更改操作后，僅 query 某個時間點之前的數(shù)據(jù)，則仍可以 query 修改前的數(shù)據(jù)）。

如上圖的左邊，Hudi 將數(shù)據(jù)集組織到與 Hive 表非常相似的基本路徑下的目錄結(jié)構(gòu)中。

數(shù)據(jù)集分為多個分區(qū)，每個分區(qū)均由相對于基本路徑的分區(qū)路徑唯一標識。

如上圖的中間部分，Hudi 以兩種不同的存儲格式存儲所有攝取的數(shù)據(jù)。

• 讀優(yōu)化的列存格式（ROFormat）：僅使用列式文件（parquet）存儲數(shù)據(jù)。在寫入/更新數(shù)據(jù)時，直接同步合并原文件，生成新版本的基文件（需要重寫整個列數(shù)據(jù)文件，即使只有一個字節(jié)的新數(shù)據(jù)被提交）。此存儲類型下，寫入數(shù)據(jù)非常昂貴，而讀取的成本沒有增加，所以適合頻繁讀的工作負載，因為數(shù)據(jù)集的最新版本在列式文件中始終可用，以進行高效的查詢。

• 寫優(yōu)化的行存格式（WOFormat）：使用列式（parquet）與行式（avro）文件組合，進行數(shù)據(jù)存儲。在更新記錄時，更新到增量文件中（avro）， 然后進行異步（或同步）的compaction，創(chuàng)建列式文件（parquet）的新版本。此存儲類型適合頻繁寫的工作負載，因為新記錄是以appending 的模式寫入增量文件中。但是在讀取數(shù)據(jù)集時，需要將增量文件與舊文件進行合并，生成列式文件。

3、DeltaLake

傳統(tǒng)的 lambda 架構(gòu)需要同時維護批處理和流處理兩套系統(tǒng)，資源消耗大，維護復(fù)雜?；?Hive 的數(shù)倉或者傳統(tǒng)的文件存儲格式（比如 parquet / ORC），都存在一些難以解決的問題：

• 小文件問題

• 并發(fā)讀寫問題

• 有限的更新支持

• 海量元數(shù)據(jù)（例如分區(qū)）導(dǎo)致 metastore 不堪重負

如上圖，Delta Lake 是 Spark 計算框架和存儲系統(tǒng)之間帶有 Schema 信息的存儲中間層。它有一些重要的特性：

• 設(shè)計了基于 HDFS 存儲的元數(shù)據(jù)系統(tǒng)，解決 metastore 不堪重負的問題；

• 支持更多種類的更新模式，比如 Merge / Update / Delete 等操作，配合流式寫入或者讀取的支持，讓實時數(shù)據(jù)湖變得水到渠成；

• 流批操作可以共享同一張表；

• 版本概念，可以隨時回溯，避免一次誤操作或者代碼邏輯而無法恢復(fù)的災(zāi)難性后果。

Delta Lake 是基于 Parquet 的存儲層，所有的數(shù)據(jù)都是使用 Parquet 來存儲，能夠利用 parquet 原生高效的壓縮和編碼方案。

Delta Lake 在多并發(fā)寫入之間提供 ACID 事務(wù)保證。每次寫入都是一個事務(wù)，并且在事務(wù)日志中記錄了寫入的序列順序。

事務(wù)日志跟蹤文件級別的寫入并使用樂觀并發(fā)控制，這非常適合數(shù)據(jù)湖，因為多次寫入/修改相同的文件很少發(fā)生。在存在沖突的情況下，Delta Lake 會拋出并發(fā)修改異常以便用戶能夠處理它們并重試其作業(yè)。

Delta Lake 其實只是一個 Lib 庫，不是一個 service，不需要單獨部署，而是直接依附于計算引擎的，但目前只支持 spark 引擎，使用過程中和 parquet 唯一的區(qū)別是把 format parquet 換成 delta 即可，可謂是部署和使用成本極低。

數(shù)據(jù)湖技術(shù)比較

總結(jié)