『壹』 行式存儲和列式存儲優缺點和paruqet文件結構
列式存儲和行式存儲是針對數據在存儲介質中的排序形式而言的，假設存在一張table，那麼：
圖1-1所示為行式存儲和列式存儲的示意圖，一張table包含5個欄位（列）即rowid、date/time、customer name以及quantity，共7行，圖中的紅色箭頭表示存儲順序。
存儲形式的差異決定了適用場景的不同：
綜合來看，列式存儲比較適合大數據量（壓縮比高）、分析型操作（針對少數幾列）；不適合頻率較高的刪除（全列檢索）、更新（重新壓縮）操作 。
圖2-1所示為列式存儲中將某張table基於字典表進行編碼壓縮的示例，圖中左邊為源表，假設該table中的customers和material欄位的取值均只有右上表所示的5種，那麼當源表的行數很大時，customers和material欄位就會存在大量重復的取值，為了節省存儲空間對這兩個欄位進行編碼，即使用一個字典表（右上圖）記錄該兩個欄位的distinct取值，又下表則用右上表欄位取值對應的index（整數1、2、3、4、5）來代替原來的string，由於string佔用的存儲空間比這幾個index佔用的存儲空間大多了，因此可以較大程度上壓縮佔用的存儲空間。
基於列式存儲的兩個典型實現是：hbase和parquet，其中：
parquet的文件結構如圖3-1所示：
從圖中可以看出，1個parquet文件由header（1個）、block（可以多個）、footer（1個）組成，分別負責：
圖3-2所示為parquet文件中，block、rowgroup、columnchunk以及page的關系：
簡而言之：
因此如果將一個parquet文件類比成一張大excel 表，那麼：
『貳』 Hive數據的序列化格式
1. TextFile
Hive數據表的默認格式，存儲方式：行存儲。
可使用Gzip,Bzip2等壓縮演算法壓縮,壓縮後的文件不支持split。
但在反序列化過程中，必須逐個字元判斷是不是分隔符和行結束符，因此反序列化開銷會比SequenceFile高幾十倍。
2. SequenceFile
Hadoop API提供的一種二進制文件，以的形式序列化到文件中，存儲方式：行存儲。
支持三種壓縮選擇：NONE，RECORD，BLOCK。
Record壓縮率低，一般建議使用BLOCK壓縮。
優勢是文件和hadoop api中的MapFile是相互兼容的。
3. RCFile
存儲方式：數據按行分塊，每塊按列存儲。結合了行存儲和列存儲的優點：
首先，RCFile 保證同一行的數據位於同一節點，因此元組重構的開銷很低；
其次，像列存儲一樣，RCFile 能夠利用列維度的數據壓縮，並且能跳過不必要的列讀取；
RCFile的一個行組包括三個部分：
第一部分是行組頭部的【同步標識】，主要用於分隔 hdfs 塊中的兩個連續行組
第二部分是行組的【元數據頭部】，用於存儲行組單元的信息，包括行組中的記錄數、每個列的位元組數、列中每個域的位元組數
第三部分是【表格數據段】，即實際的列存儲數據。在該部分中，同一列的所有域順序存儲。
從圖可以看出，首先存儲了列 A 的所有域，然後存儲列 B 的所有域等。
數據追加：RCFile 不支持任意方式的數據寫操作，僅提供一種追加介面，這是因為底層的 HDFS當前僅僅支持數據追加寫文件尾部。
行組大小：行組變大有助於提高數據壓縮的效率，但是可能會損害數據的讀取性能，因為這樣增加了 Lazy 解壓性能的消耗。而且行組變大會佔用更多的內存，這會影響並發執行的其他MR作業。 考慮到存儲空間和查詢效率兩個方面，Facebook 選擇 4MB 作為默認的行組大小，當然也允許用戶自行選擇參數進行配置。
4. ORCFile
存儲方式：數據按行分塊 每塊按照列存儲
壓縮快 快速列存取
效率比rcfile高,是rcfile的改良版本
5. 自定義格式
用戶可以通過實現inputformat和 outputformat來自定義輸入輸出格式。
6. 總結：
數據倉庫的特點：一次寫入、多次讀取，因此，整體來看， ORCFile 相比其他格式具有較明顯的優勢。
TextFile 默認格式，載入速度最快，可以採用Gzip、bzip2等進行壓縮，壓縮後的文件無法split，即並行處理
SequenceFile 壓縮率最低，查詢速度一般，三種壓縮格式NONE，RECORD，BLOCK
RCfile 壓縮率最高，查詢速度最快，數據載入最慢。
#
『叄』 hive的幾種文件格式
hive文件存儲格式包括以下幾類：
1、TEXTFILE
2、SEQUENCEFILE
3、RCFILE
4、ORCFILE(0.11以後出現)
其中TEXTFILE為默認格式，建表時不指定默認為這個格式，導入數據時會直接把數據文件拷貝到hdfs上不進行處理；
SEQUENCEFILE，RCFILE，ORCFILE格式的表不能直接從本地文件導入數據，數據要先導入到textfile格式的表中， 然後再從表中用insert導入SequenceFile,RCFile,ORCFile表中。
前提創建環境：
hive 0.8
創建一張testfile_table表，格式為textfile。
create table if not exists testfile_table( site string, url string, pv bigint, label string) row format delimited fields terminated by ' ' stored as textfile;
load data local inpath '/app/weibo.txt' overwrite into table textfile_table;
一、TEXTFILE
默認格式，數據不做壓縮，磁碟開銷大，數據解析開銷大。
可結合Gzip、Bzip2使用(系統自動檢查，執行查詢時自動解壓)，但使用這種方式，hive不會對數據進行切分，
從而無法對數據進行並行操作。
示例：
總結:
相比TEXTFILE和SEQUENCEFILE，RCFILE由於列式存儲方式，數據載入時性能消耗較大，但是具有較好的壓縮比和查詢響應。數據倉庫的特點是一次寫入、多次讀取，因此，整體來看，RCFILE相比其餘兩種格式具有較明顯的優勢。
『肆』 數據存儲形式有哪幾種
【塊存儲】
典型設備：磁碟陣列，硬碟
塊存儲主要是將裸磁碟空間整個映射給主機使用的，就是說例如磁碟陣列裡面有5塊硬碟（為方便說明，假設每個硬碟1G），然後可以通過劃邏輯盤、做Raid、或者LVM（邏輯卷）等種種方式邏輯劃分出N個邏輯的硬碟。（假設劃分完的邏輯盤也是5個，每個也是1G，但是這5個1G的邏輯盤已經於原來的5個物理硬碟意義完全不同了。例如第一個邏輯硬碟A裡面，可能第一個200M是來自物理硬碟1，第二個200M是來自物理硬碟2，所以邏輯硬碟A是由多個物理硬碟邏輯虛構出來的硬碟。）
接著塊存儲會採用映射的方式將這幾個邏輯盤映射給主機，主機上面的操作系統會識別到有5塊硬碟，但是操作系統是區分不出到底是邏輯還是物理的，它一概就認為只是5塊裸的物理硬碟而已，跟直接拿一塊物理硬碟掛載到操作系統沒有區別的，至少操作系統感知上沒有區別。
此種方式下，操作系統還需要對掛載的裸硬碟進行分區、格式化後，才能使用，與平常主機內置硬碟的方式完全無異。
優點：
1、 這種方式的好處當然是因為通過了Raid與LVM等手段，對數據提供了保護。
2、 另外也可以將多塊廉價的硬碟組合起來，成為一個大容量的邏輯盤對外提供服務，提高了容量。
3、 寫入數據的時候，由於是多塊磁碟組合出來的邏輯盤，所以幾塊磁碟可以並行寫入的，提升了讀寫效率。
4、 很多時候塊存儲採用SAN架構組網，傳輸速率以及封裝協議的原因，使得傳輸速度與讀寫速率得到提升。
缺點：
1、採用SAN架構組網時，需要額外為主機購買光纖通道卡，還要買光纖交換機，造價成本高。
2、主機之間的數據無法共享，在伺服器不做集群的情況下，塊存儲裸盤映射給主機，再格式化使用後，對於主機來說相當於本地盤，那麼主機A的本地盤根本不能給主機B去使用，無法共享數據。
3、不利於不同操作系統主機間的數據共享：另外一個原因是因為操作系統使用不同的文件系統，格式化完之後，不同文件系統間的數據是共享不了的。例如一台裝了WIN7/XP，文件系統是FAT32/NTFS，而Linux是EXT4，EXT4是無法識別NTFS的文件系統的。就像一隻NTFS格式的U盤，插進Linux的筆記本，根本無法識別出來。所以不利於文件共享。
【文件存儲】
典型設備：FTP、NFS伺服器
為了克服上述文件無法共享的問題，所以有了文件存儲。
文件存儲也有軟硬一體化的設備，但是其實普通拿一台伺服器/筆記本，只要裝上合適的操作系統與軟體，就可以架設FTP與NFS服務了，架上該類服務之後的伺服器，就是文件存儲的一種了。
主機A可以直接對文件存儲進行文件的上傳下載，與塊存儲不同，主機A是不需要再對文件存儲進行格式化的，因為文件管理功能已經由文件存儲自己搞定了。
優點：
1、造價交低：隨便一台機器就可以了，另外普通乙太網就可以，根本不需要專用的SAN網路，所以造價低。
2、方便文件共享：例如主機A（WIN7，NTFS文件系統），主機B（Linux，EXT4文件系統），想互拷一部電影，本來不行。加了個主機C（NFS伺服器），然後可以先A拷到C，再C拷到B就OK了。（例子比較膚淺，請見諒……）
缺點：
讀寫速率低，傳輸速率慢：乙太網，上傳下載速度較慢，另外所有讀寫都要1台伺服器裡面的硬碟來承擔，相比起磁碟陣列動不動就幾十上百塊硬碟同時讀寫，速率慢了許多。
【對象存儲】
典型設備：內置大容量硬碟的分布式伺服器
對象存儲最常用的方案，就是多台伺服器內置大容量硬碟，再裝上對象存儲軟體，然後再額外搞幾台服務作為管理節點，安裝上對象存儲管理軟體。管理節點可以管理其他伺服器對外提供讀寫訪問功能。
之所以出現了對象存儲這種東西，是為了克服塊存儲與文件存儲各自的缺點，發揚它倆各自的優點。簡單來說塊存儲讀寫快，不利於共享，文件存儲讀寫慢，利於共享。能否弄一個讀寫快，利 於共享的出來呢。於是就有了對象存儲。
首先，一個文件包含了了屬性（術語叫metadata，元數據，例如該文件的大小、修改時間、存儲路徑等）以及內容（以下簡稱數據）。
以往像FAT32這種文件系統，是直接將一份文件的數據與metadata一起存儲的，存儲過程先將文件按照文件系統的最小塊大小來打散（如4M的文件，假設文件系統要求一個塊4K，那麼就將文件打散成為1000個小塊），再寫進硬碟裡面，過程中沒有區分數據/metadata的。而每個塊最後會告知你下一個要讀取的塊的地址，然後一直這樣順序地按圖索驥，最後完成整份文件的所有塊的讀取。
這種情況下讀寫速率很慢，因為就算你有100個機械手臂在讀寫，但是由於你只有讀取到第一個塊，才能知道下一個塊在哪裡，其實相當於只能有1個機械手臂在實際工作。
而對象存儲則將元數據獨立了出來，控制節點叫元數據伺服器（伺服器+對象存儲管理軟體），裡面主要負責存儲對象的屬性（主要是對象的數據被打散存放到了那幾台分布式伺服器中的信息），而其他負責存儲數據的分布式伺服器叫做OSD，主要負責存儲文件的數據部分。當用戶訪問對象，會先訪問元數據伺服器，元數據伺服器只負責反饋對象存儲在哪些OSD，假設反饋文件A存儲在B、C、D三台OSD，那麼用戶就會再次直接訪問3台OSD伺服器去讀取數據。
這時候由於是3台OSD同時對外傳輸數據，所以傳輸的速度就加快了。當OSD伺服器數量越多，這種讀寫速度的提升就越大，通過此種方式，實現了讀寫快的目的。
另一方面，對象存儲軟體是有專門的文件系統的，所以OSD對外又相當於文件伺服器，那麼就不存在文件共享方面的困難了，也解決了文件共享方面的問題。
所以對象存儲的出現，很好地結合了塊存儲與文件存儲的優點。
最後為什麼對象存儲兼具塊存儲與文件存儲的好處，還要使用塊存儲或文件存儲呢？
1、有一類應用是需要存儲直接裸盤映射的，例如資料庫。因為資料庫需要存儲裸盤映射給自己後，再根據自己的資料庫文件系統來對裸盤進行格式化的，所以是不能夠採用其他已經被格式化為某種文件系統的存儲的。此類應用更適合使用塊存儲。
2、對象存儲的成本比起普通的文件存儲還是較高，需要購買專門的對象存儲軟體以及大容量硬碟。如果對數據量要求不是海量，只是為了做文件共享的時候，直接用文件存儲的形式好了，性價比高。
『伍』 C語言數據文件有幾種存儲方式每種存儲形式各有什麼特點
一、auto auto稱為自動變數。 局部變數是指在函數內部說明的變數(有時也稱為自動變數)。用關鍵字auto進7行說明, 當auto省略時, 所有的非全程變數都被認為是局部變數, 所以auto實際上從來不用。 局部變數在函數調用時自動產生, 但不會自動初始化, 隨函數調用的結束, 這個變數也就自動消失了, 下次調用此函數時再自動產生, 還要再賦值, 退出時又自動消失。 二、static static稱為靜態變數。根據變數的類型可以分為靜態局部變數和靜態全程變數。 1. 靜態局部變數 它與局部變數的區別在於: 在函數退出時, 這個變數始終存在, 但不能被其它、函數使用, 當再次進入該函數時, 將保存上次的結果。其它與局部變數一樣。 2. 靜態全程變數 Turbo C2.0允許將大型程序分成若干獨立模塊文件分別編譯, 然後將所有模塊的目標文件連接在一起, 從而提高編譯速度, 同時也便於軟體的管理和維護。靜態全程變數就是指只在定義它的源文件中可見而在其它源文件中不可見的變數。它與全程變數的區別是: 全程變數可以再說明為外部變數(extern), 被其它源文件使用,而靜態全程變數卻不能再被說明為外部的, 即只能被所在的源文件使用。 三、extern extern稱為外部變數。為了使變數除了在定義它的源文件中可以使用外, 還要被其它文件使用。因此, 必須將全程變數通知每一個程序模塊文件, 此時可用extern來說明。 四、register register稱為寄存器變數。它只能用於整型和字元型變數。定義符register說明的變數被Turbo C2.0存儲在CPU的寄存器中, 而不是象普通的變數那樣存儲在內存中, 這樣可以提高運算速度。但是Turbo C2.0隻允許同時定義兩個寄存器變數,一旦超過兩個, 編譯程序會自動地將超過限制數目的寄存器變數當作非寄存器變數來處理。因此, 寄存器變數常用在同一變數名頻繁出現的地方。另外, 寄存器變數只適用於局部變數和函數的形式參數, 它屬於auto型變數,因此, 不能用作全程變數。定義一個整型寄存器變數可寫成: register int a;
『陸』 資料庫應用系統中的數據是以表還是行還是列還是特定的形式儲存的
資料庫應用系統中的數據以二維表的方式直接存儲目標數據。
一個表由行和列組成的，行數據代表具體的生活中的實體數據，列經常被稱作是域，也就是行的某個特性，從實體對象本身出發就是對象的屬性。
表中的第一行通常稱為屬性名，表中的每一個元組和屬性都是不滲唯蔽可再分的，且元組的次序是無關緊要的。
(6)行式存儲格式擴展閱讀
行存儲和列存儲的應用場景
行存儲的適用場景：
（1）適合隨機的增、刪、改、查操作；
（叢州2）需要在行中選取所有屬性的查詢操作；
（3）需要頻繁插入或更新的操作，其操作與索引和行的大小更為相關。
列存儲的適用場景：
（1）查詢過程中，可針對各列的運算並發執行，在內存中聚合完整記錄集，降低查詢響應時間；
（2）在數據中高效查找數據，無需維護索引（任何列都能作為索引），查詢過程中能夠盡量減少無關IO，避免全表掃描；
（3）因為各列獨立存儲，且數據類型已知，可以山空針對該列的數據類型、數據量大小等因素動態選擇壓縮演算法，以提高物理存儲利用率；如果某一行的某一列沒有數據，在列存儲時，就可以不存儲該列的值，這將比行式存儲更節省空間。
『柒』 avro 和 parquet的區別和聯系
avro 和 parquet相比有哪些優勢呢？
可以跳過不符合條件的數據，只讀取需要的數據，降低IO數據量
壓縮編碼可以降低磁碟存儲空間。由於同一列的數據類型是一樣的，可以使用更高效的壓縮編碼（例如Run Length Encoding和Delta Encoding）進一步節約存儲空間
只讀取需岩廳銀要的列，支持向量運算，能夠獲取更好的掃描性能
Parquet就是基於Google的Dremel系統的數據模型和演算法實現的。核心思想是使用「record shredding and assembly algorithm」來伏畢表示復雜的嵌套數據類型，同時輔以按列的高效壓縮和編碼技術，實現降低存
與Avro之前新統計系統的日誌都是用Avro做序列化和存儲，鑒於Parquet的優勢和對Avro的兼容，將HDFS上的存儲格式改為Paruqet，並且只需做很小的改動就用原讀取Avro的API讀取Parquet，以提粗宴高近一個數量級。
Parquet文件尾部存儲了文件的元數據信息和統計信息，自描述的，方便解析
『捌』 大數據常用文件格式介紹
圖片看不見的話可以看我CSDN上的文章：
https://blog.csdn.net/u013332124/article/details/86423952
最近在做hdfs小文件合並的項目，涉及了一些文件格式的讀寫，比如avro、orc、parquet等。期間閱讀了一些資料，因此打算寫篇文章做個記錄。
這篇文章不會介紹如何對這些格式的文件進行讀寫，只會介紹一下它們各自的特點以及底層存儲的編碼格式 。
[圖片上傳失敗...(image-a5104a-1547368703623)]
使用sequencefile還可以將多個小文件合並到一個大文件中，通過key-value的形式組織起來，此時該sequencefile可以看做是一個小文件容器。
[圖片上傳失敗...(image-4d03a2-1547368703623)]
Parquet是一個基於列式存儲的文件格式，它將數據按列劃分進行存儲。Parquet官網上的文件格式介紹圖：
[圖片上傳失敗...(image-92770e-1547368703623)]
我們可以看出，parquet由幾個部分構成：
[圖片上傳失敗...(image-391e57-1547368703623)]
Orc也是一個列式存儲格式，產生自Apache Hive，用於降低Hadoop數據存儲空間和加速Hive查詢速度。
[圖片上傳失敗...(image-ba6160-1547368703623)]
目前列式存儲是大數據領域基本的優化項，無論是存儲還是查詢，列式存儲能做的優化都很多，看完上面對orc和parquet的文件結構介紹後，我們列式存儲的優化點做一個總結：
在壓縮方面 ：
在查詢方面 ：
就網上找到的一些數據來看，Orc的壓縮比會比Parquet的高一些，至於查詢性能，兩個應該不會差距太大。本人之前做過一個測試，在多數場景，hive on mr下，orc的查詢性能會更好一些。換成hive on spark後，parquet的性能更好一些
本文介紹的4種大數據存儲格式，2個是行式存儲，2個是列式存儲，但我們可以看到一個共同點：它們都是支持分割的。這是大數據文件結構體系中一個非常重要的特點， 因為可分割使一個文件可以被多個節點並發處理，提高數據的處理速度 。
另外，當前大數據的主要趨勢應該是使用列式存儲，目前我們公司已經逐步推進列式存儲的使用，本人也在hive上做過一些測試，在多個查詢場景下，無論是orc還是parquet的查詢速度都完爆text格式的， 差不多有4-8倍的性能提升 。另外，orc和parquet的壓縮比都能達到10比1的程度。因此，無論從節約資源和查詢性能考慮，在大多數情況下，選擇orc或者parquet作為文件存儲格式是更好的選擇。另外，spark sql的默認讀寫格式也是parquet。
當然，並不是說列式存儲已經一統天下了，大多時候我們還是要根據自己的使用場景來決定使用哪種存儲格式。
Sequencefile
https://blog.csdn.net/en_joker/article/details/79648861
https://stackoverflow.com/questions/11778681/advantages-of-sequence-file-over-hdfs-textfile
Avro和Sequencefile區別
https://stackoverflow.com/questions/24236803/difference-between-avrodata-file-and-sequence-file-with-respect-to-apache-sqoop
parquet
https://www.cnblogs.com/ITtangtang/p/7681019.html
Orc
https://www.cnblogs.com/ITtangtang/p/7677912.html
https://www.cnblogs.com/cxzdy/p/5910760.html
Orc和parquet的一些對比
https://blog.csdn.net/colorant/article/details/53699822
https://blog.csdn.net/yu616568/article/details/51188479
『玖』 「數據湖三劍客」Hudi、Delta Lake和Iceberg 深度對比
一個熱愛生活又放盪不羈的程序猿
本文主要講解如下內容：
一、數據湖的優點
二、目前有哪些開源數據湖組件
三、三大數據湖組件對比
數據湖相比傳統數倉而言，最明顯的便是優秀的T+0能力，這個解決了Hadoop時代數據分析的頑疾。傳統的數據處理流程從數據入庫到數據處理通常需要一個較長的環節、涉及許多復雜的邏輯來保證數據的一致性，由於架構的復雜性使得整個流水線具有明顯的延遲。
目前開源的數據湖有江湖人稱「數據湖三劍客」的 Hudi、Delta Lake和Iceberg
Iceberg官網定義：Iceberg是一個通用的表格式（數據組織格式），提供高性能的讀寫和元數據管理功能。
Iceberg 的 ACID 能力可以簡化整個流水線的設棗罩計，傳統 Hive/Spark 在修正數據時需要將數據讀取出來，修改後再寫入，有極大的修正成本。
[玫瑰]ACID能力，無縫貼合流批一體數據存儲
隨著flink等技術的不斷發展，流批一體生態不斷完善，但在流批一體數據存儲方面一直是個空白，直到Iceberg等數據湖技術的出現，這片空白被慢慢填補。
Iceberg 提供 ACID 事務能力，上游數據寫入即可見，不影響當前數據處理任務，這大大游岩梁簡化了 ETL；
Iceberg 提供了 upsert、merge into 能力，可以極大地縮小數據入庫延遲；
[玫瑰]統一數據存儲，無縫銜接計算引擎和數據存儲
Iceberg提供了基於流式的增量計算模型和基於批處理的全量表計算模型。批處理和流任務可以使用相同的存儲模型，數據不再孤立；
Iceberg 支持隱藏分區和分區進化，方便業務進行數據分區策略更新。
Iceberg屏蔽了底層數據存儲格式的差異，提供對於Parquet，ORC和Avro格式的支持。將上層引擎的能力傳導到下層的存儲格式。
[玫瑰]開放架構設計，開發維護成本相對可控
Iceberg 的架構和實現並未綁定於某一特定引擎，它實現了通用的數據組織格式，利用此格式可以方便地與不同引擎對接，目前 Iceberg 支持的計算引擎有 Spark、Flink、Presto 以及 Hive。
相比於 Hudi、Delta Lake，Iceberg 的架構實現更為優雅，同時對於數據格式、類型系統有完備的定義和可進化的設計；
面向對象存儲的優化。Iceberg 在數據組織方式上充分考慮了對象存儲的特性，避免耗時的 listing 和 rename 操作，使其在基於對象存儲的數據湖架構適配上更有優勢。
[玫瑰]增量數據讀取，實時計算的一把利劍
Iceberg 支持通過流式方式讀取增量數據，支持 Structed Streaming 以及 Flink table Source。
Apache Hudi是一種數據湖的存儲格式，在Hadoop文件系統之上提供了更新數據和刪除數據的能力以及消費變化數據的能力。
Hudi支持如下兩種表類型：
使用Parquet格式存儲數據。Copy On Write表的更新操作需要通過重寫實現。
使用列式文件格式（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變化數據的能力，可以用來優化現有的系統架構。
Delta Lake是Spark計算框架和存儲系統之間帶有Schema信息數據的存儲中間層。它給Spark帶來了三個最主要的功能：
第一，Delta Lake使得Spark能支持數據更新和刪除功能；
第二，Delta Lake使得Spark能支持事務；
第三，支持數據版本管理，運行用戶查詢 歷史 數據快照。
核心特性
Delta lake
由於Apache Spark在商業化上取得巨 成功，所以由其背後商業公司Databricks推出的Delta lake也顯得格外亮眼。在沒有delta數據湖之前，Databricks的客戶 般會采 經典的lambda架構來構建他們的流批處理場景。
Hudi
Apache Hudi是由Uber的 程師為滿 其內部數據分析的需求 設計的數據湖項 ，它提供的fast upsert/delete以及compaction等功能可以說是精準命中 民群眾的痛點，加上項 各成員積極地社區建設，包括技術細節分享、國內社區推 等等，也在逐步地吸引潛在 戶的 光。
Iceberg
Netflix的數據湖原先是藉助Hive來構建，但發現Hive在設計上的諸多缺陷之後，開始轉為 研Iceberg，並最終演化成Apache下 個 度抽象通 的開源數據湖 案。
三者均為Data Lake的數據存儲中間層，其數據管理的功能均是基於 系列的meta 件。Meta 件的 類似於資料庫的catalog，起到schema管理、事務管理和數據管理的功能。與資料庫不同的是，這些meta 件是與數據 件 起存放在存儲引擎中的， 戶可以直接看到。這個做法直接繼承了 數據分析中數據對 戶可見的傳統，但是 形中也增加了數據被不 破壞的風險。 旦刪了meta 錄，表就被破壞了，恢復難度很 。
Meta包含有表的schema信息。因此系統可以 掌握schema的變動，提供schema演化的 持。Meta 件也有transaction log的功能（需要 件系統有原 性和 致性的 持）。所有對表的變更都會 成 份新的meta 件，於是系統就有了ACID和多版本的 持，同時可以提供訪問 歷史 的功能。在這些 ，三者是相同的。
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 表。
Iceberg 沒有類似的 HoodieKey 設計，其不強調主鍵。沒有主鍵，做 update/delete/merge 等操作就要通過 Join 來實現， Join 需要有 個類似 SQL 的執 引擎。
Iceberg 在查詢性能 做了 量的 作。值得 提的是它的 hidden partition 功能。Hidden partition 意思是說，對於 戶輸 的數據， 戶可以選取其中某些列做適當的變換（Transform）形成 個新的列作為 partition 列。這個 partition 列僅僅為了將數據進 分區，並不直接體現在表的 schema中。
Delta 的定位是流批 體的， 持 update/delete/merge，spark 的所有數據寫 式，包括基於dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是 持的。
不強調主鍵，因此其 update/delete/merge 的實現均是基於 spark 的 join 功能。在數據寫 ，Delta 與 Spark 是強綁定的，這 點 Hudi 是不同的：Hudi 的數據寫 不綁定 Spark。
在查詢 ，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 是 所不及的。
三個引擎的初衷場景並不完全相同，Hudi 為了 incremental 的 upserts，Iceberg 定位於 性能的分析與可靠的數據管理，Delta 定位於流批 體的數據處理。這種場景的不同也造成了三者在設計上的差別。尤其是 Hudi，其設計與另外兩個相 差別更為明顯。
Delta、Hudi、Iceberg三個開源項 中，Delta和Hudi跟Spark的代碼深度綁定，尤其是寫 路徑。這兩個項 設計之初，都基本上把Spark作為他們的默認計算引擎了。 Apache Iceberg的 向 常堅定，宗旨就是要做 個通 化設計的Table Format。
Iceberg完美的解耦了計算引擎和底下的存儲系統，便於多樣化計算引擎和 件格式，很好的完成了數據湖架構中的Table Format這 層的實現，因此也更容易成為Table Format層的開源事實標准。另 ，Apache Iceberg也在朝著流批 體的數據存儲層發展，manifest和snapshot的設計，有效地隔離不同transaction的變更， 常 便批處理和增量計算。並且，Apache Flink已經是 個流批 體的計算引擎， 者都可以完美匹配，合 打造流批 體的數據湖架構。
Apache Iceberg這個項 背後的社區資源 常豐富。在國外，Netflix、Apple、Linkedin、Adobe等公司都有PB級別的 產數據運 在Apache Iceberg上；在國內，騰訊這樣的巨頭也有 常龐 的數據跑在Apache Iceberg之上，最 的業務每天有 T的增量數據寫 。
『拾』 hdfs 列式存儲和行式存儲的區別
列式資料庫是將同一個數據列的各個值存放在一起。插入某個數據行時，該行的各個數據列的值也會存放到不同的地方。
列式存儲： 每一列單獨存放，數據即是索引。
只訪問涉及得列，如果我們想訪問單獨一列（比如NAME）會相當迅捷。
一行數據包含一個列或者多個列，每個列一單獨一個cell來存儲數據。而行式存儲，則是把一行數據作為一個整體來存儲。
在HANA的世界中，並不是只存在列式存儲，行式存儲也是存在的。
各自的優缺點：