隨著移動(dòng)互聯(lián)網(wǎng)，物聯(lián)網(wǎng)技術(shù)的發(fā)展，數(shù)據(jù)的應(yīng)用逐漸從 BI 報(bào)表可視化往機(jī)器學(xué)習(xí)、預(yù)測分析等方向發(fā)展，即 BI 到 AI 的轉(zhuǎn)變。

數(shù)據(jù)的使用者也從傳統(tǒng)的業(yè)務(wù)分析人員轉(zhuǎn)為數(shù)據(jù)科學(xué)家，算法工程師。

此外對數(shù)據(jù)的實(shí)時(shí)性要求越來越高，也出現(xiàn)了越來越多的非結(jié)構(gòu)化的數(shù)據(jù)。

目前的數(shù)據(jù)倉庫技術(shù)出現(xiàn)了一定的局限性，比如單一不變的 schema 和模型已經(jīng)無法滿足各類不同場景和領(lǐng)域的數(shù)據(jù)分析的要求，并且數(shù)據(jù)科學(xué)家更愿意自己去處理原始的數(shù)據(jù)，而不是直接使用被處理過的數(shù)據(jù)。

比如對于數(shù)據(jù)缺失這種情況，數(shù)據(jù)科學(xué)家會(huì)嘗試各種不同的算法去彌補(bǔ)缺失數(shù)據(jù)，針對不同的業(yè)務(wù)場景也會(huì)有不同的處理方式。

目前數(shù)據(jù)湖相關(guān)的技術(shù)是業(yè)界針對這些問題的一種解決方案。

下表展示了數(shù)據(jù)倉庫和數(shù)據(jù)湖在各個(gè)維度上的特性：

相比于數(shù)據(jù)倉庫，數(shù)據(jù)湖會(huì)保留最原始的數(shù)據(jù)，并且是讀取時(shí)確定 Schema，這樣可以在業(yè)務(wù)發(fā)生變化時(shí)能靈活調(diào)整。最原始的數(shù)據(jù)湖技術(shù)其實(shí)就是對象存儲(chǔ)，比如 Amazon S3，Aliyun OSS，可以存儲(chǔ)任意形式的原始數(shù)據(jù)，但是如果不對這些存儲(chǔ)的原始文件加以管理，就會(huì)使數(shù)據(jù)湖退化成數(shù)據(jù)沼澤（dataswamp)。

所以必須有相關(guān)的技術(shù)發(fā)展來解決這些問題。

我們都知道一個(gè)大數(shù)據(jù)處理系統(tǒng)分為：

分布式文件系統(tǒng)：HDFS，S3

基于一定的文件格式將文件存儲(chǔ)在分布式文件系統(tǒng)：Parquet，ORC， ARVO

用來組織文件的元數(shù)據(jù)系統(tǒng)：Metastore

處理文件的計(jì)算引擎，包括流處理和批處理：SPARK，FLINK

簡單的說，數(shù)據(jù)湖技術(shù)是計(jì)算引擎和底層存儲(chǔ)格式之間的一種數(shù)據(jù)組織格式，用來定義數(shù)據(jù)、元數(shù)據(jù)的組織方式。

并實(shí)現(xiàn)以下的一些功能：

支持事務(wù) （ACID）

支持流批一體

支持 schema 演化和 schema 約束

支持多種底層數(shù)據(jù)存儲(chǔ)HDFS，OSS，S3，目前并沒有針對數(shù)據(jù)湖的比較成熟的解決方案，幾個(gè)大廠在開發(fā)相關(guān)技術(shù)來解決內(nèi)部遇到的一些痛點(diǎn)后，開源了幾個(gè)項(xiàng)目，比較著名的有Databrics 的 Dalta Lake，Uber 開源的 Hudi，Netflix 開源的 Iceberg。

Delta Lake

傳統(tǒng)的 lambda 架構(gòu)需要同時(shí)維護(hù)批處理和流處理兩套系統(tǒng)，資源消耗大，維護(hù)復(fù)雜。

基于 Hive 的數(shù)倉或者傳統(tǒng)的文件存儲(chǔ)格式（比如 parquet / ORC），都存在一些難以解決的問題：

小文件問題；

并發(fā)讀寫問題；

有限的更新支持；

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

如上圖，Delta Lake 是 Spark 計(jì)算框架和存儲(chǔ)系統(tǒng)之間帶有 Schema 信息的存儲(chǔ)中間層。

它有一些重要的特性：

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

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

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

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

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

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

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

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

Apache Hudi

Hudi 是什么

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

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

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

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

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

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

Hudi 存儲(chǔ)的架構(gòu)

如下圖，最下面有一個(gè)時(shí)間軸，這是 Hudi 的核心

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

通過時(shí)間軸，可以實(shí)現(xiàn)在僅查詢某個(gè)時(shí)間點(diǎn)之后成功提交的數(shù)據(jù)，或是僅查詢某個(gè)時(shí)間點(diǎn)之前的數(shù)據(jù)。

這樣可以避免掃描更大的時(shí)間范圍，并非常高效地只消費(fèi)更改過的文件（例如在某個(gè)時(shí)間點(diǎn)提交了更改操作后，僅 query 某個(gè)時(shí)間點(diǎn)之前的數(shù)據(jù)，則仍可以 query 修改前的數(shù)據(jù)）。

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

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

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

• 讀優(yōu)化的列存格式（ROFormat）：僅使用列式文件（parquet）存儲(chǔ)數(shù)據(jù)。在寫入/更新數(shù)據(jù)時(shí)，直接同步合并原文件，生成新版本的基文件（需要重寫整個(gè)列數(shù)據(jù)文件，即使只有一個(gè)字節(jié)的新數(shù)據(jù)被提交）。此存儲(chǔ)類型下，寫入數(shù)據(jù)非常昂貴，而讀取的成本沒有增加，所以適合頻繁讀的工作負(fù)載，因?yàn)閿?shù)據(jù)集的最新版本在列式文件中始終可用，以進(jìn)行高效的查詢。
• 寫優(yōu)化的行存格式（WOFormat）：使用列式（parquet）與行式（avro）文件組合，進(jìn)行數(shù)據(jù)存儲(chǔ)。在更新記錄時(shí)，更新到增量文件中（avro），然后進(jìn)行異步（或同步）的compaction，創(chuàng)建列式文件（parquet）的新版本。此存儲(chǔ)類型適合頻繁寫的工作負(fù)載，因?yàn)樾掠涗浭且詀ppending 的模式寫入增量文件中。但是在讀取數(shù)據(jù)集時(shí)，需要將增量文件與舊文件進(jìn)行合并，生成列式文件。

Apache Iceberg

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

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

• ACID事務(wù)；
• 時(shí)間旅行（time travel），以訪問之前版本的數(shù)據(jù)；
• 完備的自定義類型、分區(qū)方式和操作的抽象；
• 列和分區(qū)方式可以進(jìn)化，而且進(jìn)化對用戶無感，即無需重新組織或變更數(shù)據(jù)文件；
• 隱式分區(qū)，使SQL不用針對分區(qū)方式特殊優(yōu)化；
• 面向云存儲(chǔ)的優(yōu)化等；

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

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

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

總結(jié)

下表從各個(gè)維度，總結(jié)了三大數(shù)據(jù)湖框架支持的特性。

如果用一個(gè)比喻來說明delta、iceberg、hudi、三者差異的話，可以把三個(gè)項(xiàng)目比做建房子。

• Delta的房子底座相對結(jié)實(shí)，功能樓層也建得相對比較高，但這個(gè)房子其實(shí)可以說是databricks的，本質(zhì)上是為了更好地壯大Spark生態(tài)，在delta上其他的計(jì)算引擎難以替換Spark的位置，尤其是寫入路徑層面。
• Iceberg的建筑基礎(chǔ)非常扎實(shí)，擴(kuò)展到新的計(jì)算引擎或者文件系統(tǒng)都非常的方便，但是現(xiàn)在功能樓層相對低一點(diǎn)，目前最缺的功能就是upsert和compaction兩個(gè)，Iceberg社區(qū)正在以最高優(yōu)先級推動(dòng)這兩個(gè)功能的實(shí)現(xiàn)。
• Hudi的情況要相對不一樣，它的建筑基礎(chǔ)設(shè)計(jì)不如iceberg結(jié)實(shí)，舉個(gè)例子，如果要接入Flink作為Sink的話，需要把整個(gè)房子從底向上翻一遍，把接口抽象出來，同時(shí)還要考慮不影響其他功能，當(dāng)然Hudi的功能樓層還是比較完善的，提供的upsert和compaction功能直接命中廣大群眾的痛點(diǎn)。

總結(jié)

以上是生活随笔為你收集整理的spark读取hdfs路径下的数据_到底什么是数据湖的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。