本文是一篇資料湖的面試題，同時也是資料湖知識點的講解
目錄：
一、什麼是資料湖
二、資料湖的發展
三、資料湖有哪些優勢
四、資料湖應該具備哪些能力
五、資料湖的實現遇到了哪些問題
六、資料湖與資料倉儲的區別
七、為什麼要做資料湖？區別在於？
八、資料湖挑戰
九、湖倉一體
十、目前有哪些開源資料湖元件
十一、三大資料湖元件對比
一、什麼是資料湖
資料湖是一種不斷演進中、可擴充套件的大資料儲存、處理、分析的基礎設施；以資料為導向，實現任意來源、任意速度、任意規模、任意型別資料的全量獲取、全量儲存、多模式處理與全生命週期管理；並通過與各類外部異構資料來源的互動整合，支援各類企業級應用。
用架構圖能很快說明白，用阿里的資料架構圖來說:
ODS（operational data store, staging area）儲存來自各業務系統（生產系統）的原始資料，即為資料湖。
CDM為經過整合、清洗的資料。其中的DWS彙總層，為面向主題的資料倉儲（狹義），用於BI報表出數。
簡單來說，資料湖的定義就是原始資料儲存區. 雖然這個概念國內談的少，但絕大部分網際網路公司都已經有了。國內一般把整個HDFS叫做數倉（廣義），即存放所有資料的地方。
二、資料湖的發展
資料湖最早是2011年由Pentaho的技術長James Dixon提出的一個概念，他認為諸如資料集市，資料倉儲由於其有序性的特點，勢必會帶來資料孤島效應，而資料湖可以由於其開放性的特點可以解決資料孤島問題。
為什麼不是資料河？
因為，資料要能存，而不是一江春水向東流。
為什麼不是資料池？
因為，要足夠大，大資料太大，一池存不下。
為什麼不是資料海？
因為，企業的資料要有邊界，可以流通和交換，但更注重隱私和安全，“海到無邊天作岸”，那可不行。
所以資料要能“存”，資料要夠“存”，資料要有邊界地“存”。企業級的資料是需要長期積澱的，因此是“資料湖”。
同時湖水天然會進行分層，滿足不同的生態系統要求，這與企業建設統一資料中心，存放管理資料的需求是一致的。熱資料在上層方便流通應用，溫資料、冷資料位於資料中心的不同儲存介質之中，達到資料儲存容量與成本的平衡。
但隨著資料湖在各類企業的應用，大家都覺得：嗯，這個資料有用，我要放進去；那個資料也有用，我也要放進去；於是把所有的資料不假思索地扔進基於資料湖的相關技術或工具中，沒有規則不成方圓，當我們認為所有資料都有用時，那麼所有的資料都是垃圾，資料湖也變成了造成企業成本高企的資料沼澤。
三、資料湖有哪些優勢
輕鬆地收集資料：資料湖與資料倉儲的一大區別就是，Schema On Read，即在使用資料時才需要Schema資訊；而資料倉儲是Schema On Write，即在儲存資料時就需要設計好Schema。這樣，由於對資料寫入沒有限制，資料湖可以更容易的收集資料。
從資料中發掘更多價值：資料倉儲和資料市場由於只使用資料中的部分屬性，所以只能回答一些事先定義好的問題；而資料湖儲存所有最原始、最細節的資料，所以可以回答更多的問題。並且資料湖允許組織中的各種角色通過自助分析工具，對資料進行分析，以及利用AI、機器學習的技術，從資料中發掘更多的價值。
消除資料孤島：資料湖中彙集了來自各個系統中的資料，這就消除了資料孤島問題。
具有更好的擴充套件性和敏捷性：資料湖可以利用分散式檔案系統來儲存資料，因此具有很高的擴充套件能力。開源技術的使用還降低了儲存成本。資料湖的結構沒那麼嚴格，因此天生具有更高的靈活性，從而提高了敏捷性。
四、資料湖應該具備哪些能力
資料整合能力：
需要具備把各種資料來源接入整合到資料湖中的能力。資料湖的儲存也應該是多樣的，比如HDFS、HIVE、HBASE等等。
資料治理能力：
治理能力的核心是維護好資料的後設資料（metadata）。強制要求所有進入資料湖的資料必須提供相關後設資料，應該作為最低限度的治理管控。沒有後設資料，資料湖就面臨成為資料沼澤的風險。更豐富的功能還包括：
自動提取元後設資料，並根據後設資料對資料進行分類，形成資料目錄。 自動對資料目錄進行分析，可以基於AI和機器學習的方法，發現資料之間的關係。 自動建立資料之間血緣關係圖。 跟蹤資料的使用情況，以便將資料作為產品，形成資料資產。
資料搜尋和發現能力：
如果把整個網際網路想象成一個巨大的資料湖。那麼，之所以人們可以這麼有效的利用這個湖中的資料，就是因為有了Google這樣的搜尋引擎。人們可以通過搜尋，方便地找到他們想要的資料，進而進行分析。搜尋能力是資料湖的十分重要的能力。
資料安全管控能力：
對資料的使用許可權進行管控，對敏感資料進行脫敏或加密處理，也是資料湖能商用所必須具備的能力。
資料質量檢驗能力：
資料質量是分析正確的關鍵。因此必須對進入資料湖中的資料的質量情況進行檢驗。及時發現資料湖中資料質量的問題。為有效的資料探索提供保障。
自助資料探索能力：
應該具備一系列好用的資料分析工具，以便各類使用者可以對資料湖中的資料進行自助探索。包括：
支援對流、NoSQL、圖等多種儲存庫的聯合分析能力 支援互動式的大資料SQL分析 支援AI、機器學習分析 支援類似OLAP的BI分析 支援報表的生成
五、資料湖的實現遇到了哪些問題
資料湖剛提出來時，只是一個樸素的理念。而從理念變成一個可以落地的系統，就面臨著許多不得不考慮的現實問題：
首先，把所有原始資料都儲存下來的想法，要基於一個前提，就是儲存成本很低。而今資料產生的速度越來越快、產生的量越來越大的情況下，把所有原始資料，不分價值大小，都儲存下來，這個成本在經濟上能不能接受，可能需要打一個問號。
其次，資料湖中存放這各類最原始的明細資料，包括交易資料、使用者資料等敏感資料，這些資料的安全怎麼保證？使用者訪問的許可權如何控制？
再次，湖中的資料怎麼治理？誰對資料的質量、資料的定義、資料的變更負責？如何確保資料的定義、業務規則的一致性？
資料湖的理念很好，但是它現在還缺乏像資料倉儲那樣，有一整套方法論為基礎，有一系列具有可操作性的工具和生態為支撐。正因如此，目前把Hadoop用來對特定的、高價值的資料進行處理，構建資料倉儲的模式，取得了較多的成功；而用來落實資料湖理念的模式，遭遇了一系列的失敗。這裡，總結一些典型的資料湖失敗的原因：
資料沼澤：當越來越多的資料接入到資料湖中，但是卻沒有有效的方法跟蹤這些資料，資料沼澤就發生了。在這種失敗中，人們把所有東西都放在HDFS中，期望以後可以發掘些什麼，可沒多久他們就忘那裡有什麼。
資料泥團：各種各樣的新資料接入進資料湖中，它們的組織形式、質量都不一樣。 由於缺乏用於檢查，清理和重組資料的自助服務工具，使得這些資料很難創造價值。
缺乏自助分析工具：由於缺乏好用的自助分析工具，直接對資料湖中的資料分析很困難。一般都是資料工程師或開發人員建立一個整理後的小部分資料集，把這些資料集交付給更廣泛的使用者，以便他們使用熟悉的工具進行資料分析。這限制了更廣泛的人蔘與到探索大資料中，降低了資料湖的價值。
缺乏建模的方法論和工具：在資料湖中，似乎每一項工作都得從頭開始，因為以前的專案產生的資料幾乎沒有辦法重用。 其實，我們罵資料倉儲很難變化以適應新需求，這其中有個原因就是它花很多時間來對資料進行建模，而正是有了這些建模，使得資料可以共享和重用。資料湖也需要為資料建模，不然每次分析師都得從頭開始。
缺少資料安全管理：通常的想法是每個人都可以訪問所有資料，但這是行不通的。企業對自己的資料是有保護本能的，最終一定是需要資料安全管理的。
一個資料湖搞定一切：大家都對能在一個庫中儲存所有資料的想法很興奮。然而，資料湖之外總會有新的儲存庫，很難把他們全都消滅掉。 其實，大多數公司所需的，是可以對多種儲存庫聯合訪問功能。是不是在一個地方儲存，並不是那麼重要。
六、資料湖與資料倉儲的區別
資料倉儲，準確說，是面向歷史資料沉澱和分析使用的，有三大特點：
其一是整合性，由於資料來源眾多，因而需要技術和規範來統一儲存方式； 其二是非易失和隨時間變化，資料倉儲儲存了過去每一天的快照且通常不更新，使用者可以在任一天向前或者向後對比資料的變化； 其三是面向主題，根據業務對資料進行有效的編碼，讓理論最佳值在應用中落地。
資料湖，準確說，其出發點是補全資料倉儲實時處理能力、互動式分析能力等新技術缺失的情況。其最重要的特點，就是豐富的計算引擎：批處理、流式、互動式、機器學習，該有的，應有盡有，企業需要什麼，就用什麼。資料湖也有三個特徵：
其一是靈活性，預設業務的不確定性是常態的，在無法預期未來變化時，技術設施基礎，就要具備“按需”貼合業務的能力； 其二是管理性，資料湖需要儲存原始資訊和處理後的資訊，在資料來源、資料格式、資料週期等維度上，能夠追溯資料的接入、儲存、分析和使用等流動過程； 其三是多型性，本身的引擎需要進可能的豐富，因為業務場景不固定，而多型的引擎支援、擴充套件能力，能夠較好的適應業務的快速變化。
七、為什麼要做資料湖？區別在於？
資料湖和數倉，就是原始資料和數倉模型的區別。因為數倉（狹義）中的表，主要是事實表-維度表，主要用於BI、出報表，和原始資料是不一樣的。
為什麼要強調資料湖呢？
真正的原因在於，data science和machine learning進入主流了，需要用原始資料做分析，而數倉的維度模型則通常用於聚合。
另一方面，機器學習用到的資料，也不止於結構化資料。使用者的評論、影像這些非結構化資料，也都可以應用到機器學習中。
但資料湖背後其實還有更大的區別：
傳統數倉的工作方式是集中式的：業務人員給需求到資料團隊，資料團隊根據要求加工、開發成維度表，供業務團隊通過BI報表工具查詢。
資料湖是開放、自助式的（self-service）：開放資料給所有人使用，資料團隊更多是提供工具、環境供各業務團隊使用（不過集中式的維度表建設還是需要的），業務團隊進行開發、分析。
也就是組織架構和分工的差別 —— 傳統企業的資料團隊可能被當做IT，整天要求提數，而在新型的網際網路/科技團隊，資料團隊負責提供簡單易用的工具，業務部門直接進行資料的使用。
八、資料湖挑戰
從傳統集中式的數倉轉為開放式的資料湖，並不簡單，會碰到許多問題
資料發現：如何幫助使用者發現資料、瞭解有哪些資料？
資料安全：如果管理資料的許可權和安全？因為一些資料是敏感的、或者不應直接開放給所有人的（比如電話號碼、地址等）
資料管理：多個團隊使用資料，如何共享資料成果（比如畫像、特徵、指標），避免重複開發
這也是目前各大網際網路公司都在改進的方向！
九、湖倉一體
2020年，大資料DataBricks公司首次提出了湖倉一體（Data Lakehouse）概念，希望將資料湖和資料倉儲技術合而為一，此概念一出各路雲廠商紛紛跟進。
Data Lakehouse（湖倉一體）是新出現的一種資料架構，它同時吸收了資料倉儲和資料湖的優勢，資料分析師和資料科學家可以在同一個資料儲存中對資料進行操作，同時它也能為公司進行資料治理帶來更多的便利性。
1) 目前資料儲存的方案
一直以來，我們都在使用兩種資料儲存方式來架構資料：
資料倉儲：主要儲存的是以關係型資料庫組織起來的結構化資料。資料通過轉換、整合以及清理，並匯入到目標表中。在數倉中，資料儲存的結構與其定義的schema是強匹配的。
資料湖：儲存任何型別的資料，包括像圖片、文件這樣的非結構化資料。資料湖通常更大，其儲存成本也更為廉價。儲存其中的資料不需要滿足特定的schema，資料湖也不會嘗試去將特定的schema施行其上。相反的是，資料的擁有者通常會在讀取資料的時候解析schema（schema-on-read），當處理相應的資料時，將轉換施加其上。
現在許多的公司往往同時會搭建數倉、資料湖這兩種儲存架構，一個大的數倉和多個小的資料湖。這樣，資料在這兩種儲存中就會有一定的冗餘。
2) Data Lakehouse（湖倉一體）
Data Lakehouse的出現試圖去融合數倉和資料湖這兩者之間的差異，通過將數倉構建在資料湖上，使得儲存變得更為廉價和彈性，同時lakehouse能夠有效地提升資料質量，減小資料冗餘。在lakehouse的構建中，ETL起了非常重要的作用，它能夠將未經規整的資料湖層資料轉換成數倉層結構化的資料。
下面詳細解釋下：
湖倉一體（Data Lakehouse）：
依據DataBricks公司對Lakehouse 的定義：一種結合了資料湖和資料倉儲優勢的新正規化，解決了資料湖的侷限性。Lakehouse 使用新的系統設計：直接在用於資料湖的低成本儲存上實現與資料倉儲中類似的資料結構和資料管理功能。
解釋擴充：
湖倉一體，簡單理解就是把面向企業的資料倉儲技術與資料湖儲存技術相結合，為企業提供一個統一的、可共享的資料底座。
避免傳統的資料湖、資料倉儲之間的資料移動，將原始資料、加工清洗資料、模型化資料，共同儲存於一體化的“湖倉”中，既能面向業務實現高併發、精準化、高效能的歷史資料、實時資料的查詢服務，又能承載分析報表、批處理、資料探勘等分析型業務。
湖倉一體方案的出現，幫助企業構建起全新的、融合的資料平臺。通過對機器學習和AI演算法的支援，實現資料湖+資料倉儲的閉環，提升業務的效率。資料湖和資料倉儲的能力充分結合，形成互補，同時對接上層多樣化的計算生態。
十、目前有哪些開源資料湖元件
目前開源的資料湖有江湖人稱“資料湖三劍客”的Hudi、Delta Lake和IceBerg。
1) Hudi
Apache Hudi是一種資料湖的儲存格式，在Hadoop檔案系統之上提供了更新資料和刪除資料的能力以及消費變化資料的能力。
Hudi支援如下兩種表型別：
Copy On Write
使用Parquet格式儲存資料。Copy On Write表的更新操作需要通過重寫實現。
Merge On Read
使用列式檔案格式（Parquet）和行式檔案格式（Avro）混合的方式來儲存資料。Merge On Read使用列式格式存放Base資料，同時使用行式格式存放增量資料。最新寫入的增量資料存放至行式檔案中，根據可配置的策略執行COMPACTION操作合併增量資料至列式檔案中。
應用場景
近實時資料攝取
Hudi支援插入、更新和刪除資料的能力。可以實時攝取訊息佇列（Kafka）和日誌服務SLS等日誌資料至Hudi中，同時也支援實時同步資料庫Binlog產生的變更資料。
Hudi優化了資料寫入過程中產生的小檔案。因此，相比其他傳統的檔案格式，Hudi對HDFS檔案系統更加的友好。
近實時資料分析
Hudi支援多種資料分析引擎，包括Hive、Spark、Presto和Impala。Hudi作為一種檔案格式，不需要依賴額外的服務程式，在使用上也更加的輕量化。
增量資料處理
Hudi支援Incremental Query查詢型別，可以通過Spark Streaming查詢給定COMMIT後發生變更的資料。Hudi提供了一種消費HDFS變化資料的能力，可以用來優化現有的系統架構。
2) Delta Lake
Delta Lake是Spark計算框架和儲存系統之間帶有Schema資訊資料的儲存中間層。它給Spark帶來了三個最主要的功能：
第一，Delta Lake使得Spark能支援資料更新和刪除功能；
第二，Delta Lake使得Spark能支援事務；
第三，支援資料版本管理，執行使用者查詢歷史資料快照。
核心特性
ACID事務：為資料湖提供ACID事務，確保在多個資料管道併發讀寫資料時，資料能保持完整性。
資料版本管理和時間旅行：提供了資料快照，使開發人員能夠訪問和還原早期版本的資料以進行稽核、回滾或重現實驗
可伸縮的後設資料管理：儲存表或者檔案的後設資料資訊，並且把後設資料也作為資料處理，後設資料與資料的對應關係存放在事務日誌中；
流和批統一處理：Delta中的表既有批量的，也有流式和sink的；
資料操作審計：事務日誌記錄對資料所做的每個更改的詳細資訊，提供對更改的完整審計跟蹤；
Schema管理功能：提供自動驗證寫入資料的Schema與表的Schema是否相容的能力，並提供顯示增加列和自動更新Schema的能力；
資料表操作(類似於傳統資料庫的SQL)：合併、更新和刪除等，提供完全相容Spark的Java/scala API；
統一格式：Delta中所有的資料和後設資料都儲存為Apache Parquet。
3) IceBerg
Iceberg官網定義：Iceberg是一個通用的表格式（資料組織格式），它可以適配Presto，Spark等引擎提供高效能的讀寫和後設資料管理功能。
資料湖相比傳統數倉而言，最明顯的便是優秀的T+0能力，這個解決了Hadoop時代資料分析的頑疾。傳統的資料處理流程從資料入庫到資料處理通常需要一個較長的環節、涉及許多複雜的邏輯來保證資料的一致性，由於架構的複雜性使得整個流水線具有明顯的延遲。
Iceberg 的 ACID 能力可以簡化整個流水線的設計，降低整個流水線的延遲。降低資料修正的成本。傳統 Hive/Spark 在修正資料時需要將資料讀取出來，修改後再寫入，有極大的修正成本。Iceberg 所具有的修改、刪除能力能夠有效地降低開銷，提升效率。
ACID能力，無縫貼合流批一體資料儲存最後一塊版圖
隨著flink等技術的不斷髮展，流批一體生態不斷完善，但在流批一體資料儲存方面一直是個空白，直到Iceberg等資料湖技術的出現，這片空白被慢慢填補。
Iceberg 提供 ACID 事務能力，上游資料寫入即可見，不影響當前資料處理任務，這大大簡化了 ETL；
Iceberg 提供了 upsert、merge into 能力，可以極大地縮小資料入庫延遲；
統一資料儲存，無縫銜接計算引擎和資料儲存
Iceberg提供了基於流式的增量計算模型和基於批處理的全量表計算模型。批處理和流任務可以使用相同的儲存模型，資料不再孤立；Iceberg 支援隱藏分割槽和分割槽進化，方便業務進行資料分割槽策略更新。
Iceberg遮蔽了底層資料儲存格式的差異，提供對於Parquet，ORC和Avro格式的支援。Iceberg起到了中間橋樑的能力，將上層引擎的能力傳導到下層的儲存格式。
開放架構設計，開發維護成本相對可控
Iceberg 的架構和實現並未繫結於某一特定引擎，它實現了通用的資料組織格式，利用此格式可以方便地與不同引擎對接，目前 Iceberg 支援的計算引擎有 Spark、Flink、Presto 以及 Hive。
相比於 Hudi、Delta Lake，Iceberg 的架構實現更為優雅，同時對於資料格式、型別系統有完備的定義和可進化的設計；物件導向儲存的優化。Iceberg 在資料組織方式上充分考慮了物件儲存的特性，避免耗時的 listing 和 rename 操作，使其在基於物件儲存的資料湖架構適配上更有優勢。
增量資料讀取，實時計算的一把利劍
Iceberg 支援通過流式方式讀取增量資料，支援 Structed Streaming 以及 Flink table Source。
十一、三大資料湖元件對比
1) 概覽
Delta lake
由於Apache Spark在商業化上取得巨⼤成功，所以由其背後商業公司Databricks推出的Delta lake也顯得格外亮眼。在沒有delta資料湖之前，Databricks的客戶⼀般會採⽤經典的lambda架構來構建他們的流批處理場景。
Hudi
Apache Hudi是由Uber的⼯程師為滿⾜其內部資料分析的需求⽽設計的資料湖項⽬，它提供的fast upsert/delete以及compaction等功能可以說是精準命中⼴⼤⼈民群眾的痛點，加上項⽬各成員積極地社群建設，包括技術細節分享、國內社群推⼴等等，也在逐步地吸引潛在⽤戶的⽬光。
Iceberg
Netflix的資料湖原先是藉助Hive來構建，但發現Hive在設計上的諸多缺陷之後，開始轉為⾃研Iceberg，並最終演化成Apache下⼀個⾼度抽象通⽤的開源資料湖⽅案。
Apache Iceberg⽬前看則會顯得相對平庸⼀些，簡單說社群關注度暫時⽐不上delta，功能也不如Hudi豐富，但卻是⼀個野⼼勃勃的項⽬，因為它具有⾼度抽象和⾮常優雅的設計，為成為⼀個通⽤的資料湖⽅案奠定了良好基礎。
2) 共同點
三者均為Data Lake的資料儲存中間層，其資料管理的功能均是基於⼀系列的meta⽂件。Meta⽂件的⾓⾊類似於資料庫的catalog\wal，起到schema管理、事務管理和資料管理的功能。與資料庫不同的是，這些meta⽂件是與資料⽂件⼀起存放在儲存引擎中的，⽤戶可以直接看到。這個做法直接繼承了⼤資料分析中資料對⽤戶可見的傳統，但是⽆形中也增加了資料被不⼩⼼破壞的風險。⼀旦刪了meta⽬錄，表就被破壞了，恢復難度很⼤。
Meta包含有表的schema資訊。因此係統可以⾃⼰掌握schema的變動，提供schema演化的⽀持。Meta⽂件也有transaction log的功能（需要⽂件系統有原⼦性和⼀致性的⽀持）。所有對錶的變更都會⽣成⼀份新的meta⽂件，於是系統就有了ACID和多版本的⽀持，同時可以提供訪問歷史的功能。在這些⽅⾯，三者是相同的。
3) 關於Hudi
Hudi 的設計⽬標正如其名，Hadoop Upserts Deletes and Incrementals（原為 Hadoop Upserts anD Incrementals），強調了其主要⽀持Upserts、Deletes 和 Incremental 資料處理，其主要提供的寫⼊⼯具是 Spark HudiDataSource API 和⾃⾝提供的 HoodieDeltaStreamer，均⽀持三種資料寫⼊⽅式：UPSERT，INSERT 和 BULK_INSERT。其對 Delete 的⽀持也是通過寫⼊時指定⼀定的選項⽀持的，並不⽀持純粹的 delete 接⼝。
在查詢⽅⾯，Hudi ⽀持 Hive、Spark、Presto。
在效能⽅⾯，Hudi 設計了 HoodieKey ，⼀個類似於主鍵的東西。對於查詢效能，⼀般需求是根據查詢謂詞⽣成過濾條件下推⾄datasource。Hudi 這⽅⾯沒怎麼做⼯作，其效能完全基於引擎⾃帶的謂詞下推和 partition prune 功能。
Hudi 的另⼀⼤特⾊是⽀持 Copy On Write 和 Merge On Read。前者在寫⼊時做資料的 merge，寫⼊效能略差，但是讀效能更⾼⼀些。後者讀的時候做 merge，讀效能差，但是寫⼊資料會⽐較及時，因⽽後者可以提供近實時的資料分析能⼒。最後，Hudi 提供了⼀個名為run_sync_tool 的指令碼同步資料的 schema 到 Hive 表。Hudi 還提供了⼀個命令⾏⼯具⽤於管理 Hudi 表。
4) 關於Iceberg
Iceberg 沒有類似的 HoodieKey 設計，其不強調主鍵。沒有主鍵，做 update/delete/merge 等操作就要通過 Join 來實現，⽽ Join 需要有⼀個類似 SQL 的執⾏引擎。
Iceberg 在查詢效能⽅⾯做了⼤量的⼯作。值得⼀提的是它的 hidden partition 功能。Hidden partition 意思是說，對於⽤戶輸⼊的資料，⽤戶可以選取其中某些列做適當的變換（Transform）形成⼀個新的列作為 partition 列。這個 partition 列僅僅為了將資料進⾏分割槽，並不直接體現在表的 schema中。
5) 關於Delta
Delta 的定位是流批⼀體的 Data Lake 儲存層，⽀持 update/delete/merge。由於出⾃ Databricks，spark 的所有資料寫⼊⽅式，包括基於dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是⽀持的（開源的 SQL 寫暫不⽀持，EMR 做了⽀持）。不強調主鍵，因此其 update/delete/merge 的實現均是基於 spark 的 join 功能。在資料寫⼊⽅⾯，Delta 與 Spark 是強繫結的，這⼀點 Hudi 是不同的：Hudi 的資料寫⼊不繫結 Spark（可以⽤ Spark，也可以使⽤ Hudi ⾃⼰的寫⼊⼯具寫⼊）。
在查詢⽅⾯，開源 Delta ⽬前⽀持 Spark 與 Presto，但是，Spark 是不可或缺的，因為 delta log 的處理需要⽤到 Spark。這意味著如果要⽤ Presto 查詢 Delta，查詢時還要跑⼀個 Spark 作業。更為難受的是，Presto 查詢是基於 SymlinkTextInputFormat 。在查詢之前，要運⾏ Spark 作業⽣成這麼個 Symlink ⽂件。如果表資料是實時更新的，意味著每次在查詢之前先要跑⼀個 SparkSQL，再跑 Presto。為此，EMR 在這⽅⾯做了改進可以不必事先啟動⼀個 Spark 任務。
在查詢效能⽅⾯，開源的 Delta ⼏乎沒有任何優化。
Delta 在資料 merge ⽅⾯效能不如 Hudi，在查詢⽅⾯效能不如 Iceberg，是不是意味著 Delta ⼀⽆是處了呢？其實不然。Delta 的⼀⼤優點就是與 Spark 的整合能⼒，尤其是其流批⼀體的設計，配合 multi-hop 的 data pipeline，可以⽀持分析、Machine learning、CDC 等多種場景。使⽤靈活、場景⽀持完善是它相⽐ Hudi 和 Iceberg 的最⼤優點。另外，Delta 號稱是 Lambda 架構、Kappa 架構的改進版，⽆需關⼼流批，⽆需關⼼架構。這⼀點上 Hudi 和 Iceberg 是⼒所不及的。
6) 總結
三個引擎的初衷場景並不完全相同，Hudi 為了 incremental 的 upserts，Iceberg 定位於⾼效能的分析與可靠的資料管理，Delta 定位於流批⼀體的資料處理。這種場景的不同也造成了三者在設計上的差別。尤其是 Hudi，其設計與另外兩個相⽐差別更為明顯。因此後⾯是趨同還築起各⾃專長優勢壁壘未可知。
Delta、Hudi、Iceberg三個開源項⽬中，Delta和Hudi跟Spark的程式碼深度繫結，尤其是寫⼊路徑。這兩個項⽬設計之初，都基本上把Spark作為他們的預設計算引擎了。⽽Apache Iceberg的⽅向⾮常堅定，宗旨就是要做⼀個通⽤化設計的Table Format。
它完美的解耦了計算引擎和底下的儲存系統，便於多樣化計算引擎和⽂件格式，很好的完成了資料湖架構中的Table Format這⼀層的實現，因此也更容易成為Table Format層的開源事實標準。
另⼀⽅⾯，Apache Iceberg也在朝著流批⼀體的資料儲存層發展，manifest和snapshot的設計，有效地隔離不同transaction的變更，⾮常⽅便批處理和增量計算。並且，Apache Flink已經是⼀個流批⼀體的計算引擎，⼆者都可以完美匹配，合⼒打造流批⼀體的資料湖架構。
Apache Iceberg這個項⽬背後的社群資源⾮常豐富。在國外，Netflix、Apple、Linkedin、Adobe等公司都有PB級別的⽣產資料運⾏在Apache Iceberg上；在國內，騰訊這樣的巨頭也有⾮常龐⼤的資料跑在Apache Iceberg之上，最⼤的業務每天有⼏⼗T的增量資料寫⼊。