hive仲元數據存在哪裡

❶ 如何查看hive的元數據存儲位置

導入數據設置HADOOP_HOME
$ HADOOP_HOME=/path/to/some/hadoop sqoop import --arguments...
下載合適的Sqoop並解壓到硬碟，所謂合適即Sqoop的版本應該和Hadoop的版本相匹配。筆者的Hadoop版本是1.03，下載的Sqoop是版本1.4.2。
$ tar zvxf sqoop-1.4.2.bin__hadoop-1.0.0.tar.gz

下載合適的JDBC驅動，將下載的JDBC的驅動放到Sqoop的lib文件夾下。
導入數據
$ sqoop import --hive-import --connect jdbc:oracle:thin:@192.168.56.111:1521:DBNAME --username USERNAME --password PASSWORD --verbose -m 1 --table TABLENAME
DBNAME：資料庫名
USERNAME：用戶名
PASSWORD：密碼
TABLENAME：表名
-m：導入數據的進程的並發數，默認是4。如果導入的數據不大的話，不妨設置成1，這樣導入更快。一般來說Sqoop會使用主鍵來平均地分割數據。並發導入的時候可以設置相關的分割列等等，具體的做法參考官方的文檔。
如果Oracle是安裝在遠程的電腦上，要確保Sqoop可以ping通Oracle所在的電腦。例如如果Oracle安裝在Win7上面，可能需要關閉Win7的防火牆。另外，需要將Oracle配置成可以遠程訪問的。

注意，用戶名和表名應該要是大寫的，除非它們在創建的時候是名字是放在引號中的大小寫混合的形式。

❷ hive的元數據存儲在derby和mysql 中有什麼區別

定義 元數據最本質、最抽象的定義為：data about data (關於數據的數據)。它是一種廣泛存在的現象，在許多領域有其具體的定義和應用。 在數據倉庫領域中，元數據被定義為：描述數據及其環境的數據。一般來說,它有兩方面的用途。

❸ hive的數據存儲

首先，Hive 沒有專門的數據存儲格式，也沒有為數據建立索引，用戶可以非常自由的組織 Hive 中的表，只需要在創建表的時候告訴 Hive 數據中的列分隔符和行分隔符，Hive 就可以解析數據。
其次，Hive 中所有的數據都存儲在 HDFS 中，Hive 中包含以下數據模型：表(Table)，外部表(External Table)，分區(Partition)，桶(Bucket)。
Hive 中的 Table 和資料庫中的 Table 在概念上是類似的，每一個 Table 在 Hive 中都有一個相應的目錄存儲數據。例如，一個表 pvs，它在 HDFS 中的路徑為：/wh/pvs，其中，wh 是在 hive-site.xml 中由 ${hive.metastore.warehouse.dir} 指定的數據倉庫的目錄，所有的 Table 數據（不包括 External Table）都保存在這個目錄中。
Partition 對應於資料庫中的 Partition 列的密集索引，但是 Hive 中 Partition 的組織方式和資料庫中的很不相同。在 Hive 中，表中的一個 Partition 對應於表下的一個目錄，所有的 Partition 的數據都存儲在對應的目錄中。例如：pvs 表中包含 ds 和 city 兩個 Partition，則對應於 ds = 20090801, ctry = US 的 HDFS 子目錄為：/wh/pvs/ds=20090801/ctry=US；對應於 ds = 20090801, ctry = CA 的 HDFS 子目錄為；/wh/pvs/ds=20090801/ctry=CA
Buckets 對指定列計算 hash，根據 hash 值切分數據，目的是為了並行，每一個 Bucket 對應一個文件。將 user 列分散至 32 個 bucket，首先對 user 列的值計算 hash，對應 hash 值為 0 的 HDFS 目錄為：/wh/pvs/ds=20090801/ctry=US/part-00000；hash 值為 20 的 HDFS 目錄為：/wh/pvs/ds=20090801/ctry=US/part-00020
External Table 指向已經在 HDFS 中存在的數據，可以創建 Partition。它和 Table 在元數據的組織上是相同的，而實際數據的存儲則有較大的差異。
Table 的創建過程和數據載入過程（這兩個過程可以在同一個語句中完成），在載入數據的過程中，實際數據會被移動到數據倉庫目錄中；之後對數據對訪問將會直接在數據倉庫目錄中完成。刪除表時，表中的數據和元數據將會被同時刪除。 External Table 只有一個過程，載入數據和創建表同時完成（CREATE EXTERNAL TABLE ……LOCATION），實際數據是存儲在 LOCATION 後面指定的 HDFS 路徑中，並不會移動到數據倉庫目錄中。當刪除一個 External Table 時，僅刪除元數據，表中的數據不會真正被刪除。

❹ 程序中的Hive具體是干什麼用的呢

Hive是基於Hadoop平台的數倉工具，具有海量數據存儲、水平可擴展、離線批量處理的優點，解決了傳統關系型數倉不能支持海量數據存儲、水平可擴展性差等問題，但是由於Hive數據存儲和數據處理是依賴於HDFS和MapRece，因此在Hive進行數據離線批量處理時，需將查詢語言先轉換成MR任務，由MR批量處理返回結果，所以Hive沒法滿足數據實時查詢分析的需求。
Hive是由FaceBook研發並開源，當時FaceBook使用Oracle作為數倉，由於數據量越來越大，Oracle數倉性能越來越差，沒法實現海量數據的離線批量分析，因此基於Hadoop研發Hive，並開源給Apacha。
由於Hive不能實現數據實時查詢交互，Hbase可提供實時在線查詢能力，因此Hive和Hbase形成了良性互補。Hbase因為其海量數據存儲、水平擴展、批量數據處理等優點，也得到了廣泛應用。
Pig與HIVE工具類似，都可以用類sql語言對數據進行處理。但是他們應用場景有區別，Pig用於數據倉庫數據的ETL，HIVE用於數倉數據分析。
從架構圖當中，可看出Hive並沒有完成數據的存儲和處理，它是由HDFS完成數據存儲，MR完成數據處理，其只是提供了用戶查詢語言的能力。Hive支持類sql語言，這種SQL稱為Hivesql。用戶可用Hivesql語言查詢，其驅動可將Hivesql語言轉換成MR任務，完成數據處理。
【Hive的訪問介面】
CLI：是hive提供的命令行工具
HWI：是Hive的web訪問介面
JDBC/ODBC：是兩種的標準的應用程序編程訪問介面
Thrift Server：提供異構語言，進行遠程RPC調用Hive的能力。
因此Hiv具備豐富的訪問介面能力，幾乎能滿足各種開發應用場景需求。
【Driver】
是HIVE比較核心的驅動模塊，包含編譯器、優化器、執行器，職責為把用戶輸入的Hivesql轉換成MR數據處理任務
【Metastore】
是HIVE的元數據存儲模塊，數據的訪問和查找，必須要先訪問元數據。Hive中的元數據一般使用單獨的關系型資料庫存儲，常用的是Mysql，為了確保高可用，Mysql元資料庫還需主備部署。
架構圖上面Karmasphere、Hue、Qubole也是訪問HIVE的工具，其中Qubole可遠程訪問HIVE，相當於HIVE作為一種公有雲服務，用戶可通過互聯網訪問Hive服務。
Hive在使用過程中出現了一些不穩定問題，由此發展出了Hive HA機制，

❺ hive 建表方式及參數詳解

   hive中有兩種表：外部表和內部表（managed and external）。可以通過 desc formatted table_name 命令來查看錶的信息，來辨別表是外部表還是內部表。 在hive默認創建到表是內部表，外部表創建需要加 EXTERNAL 命令，如： CREATE EXTERNAL table_name 。
   內部表的文件，元數據和統計信息等由hive進行管理，一般被存儲在 hive.metastore.warehouse.dir 目錄下，當表被刪除或者分區被刪除，相對應的數據和元數據就會被刪除。一般用來當做臨時表。
外部表與內部表相反，可以指定location，可以不基於hive來操作外部表文件。當表被刪除或者分區被刪除時對應的數據還會存在。只是hive刪除了其元信息,表的數據文件依然存在於文件系統中。若是表被刪除，可以重新建這個表，指定location到數據文件處，然後通過msck repair table table_name命令刷新數據的元信息到hive中，也就是恢復了數據。
   msck repair table 的詳細用法就不講了，可以參考 HIVE常用命令之MSCK REPAIR TABLE命令簡述

❻ 大數據專題--Hive 與 impala

由FaceBook開發，貢獻給APache。

Hive是基於Hadoop的一個 數據倉庫 工具，依賴HDFS完成數據存儲，依賴於MapRece處理數據。其本身並不存儲數據。Hive 定義了簡單的類 SQL 查詢語言，稱為 HQL，通過編寫HiveQL語句，運行具體的MapRece任務。

1）採用批處理方式處理海量數據。

2）提供了ETL工具。

 Hive的體系結構可以分為以下幾部分：

Hive 對外提供了三種服務模式，即 Hive 命令行模式（CLI），Hive 的 Web 模式（WUI），Hive 的遠程服務（Client）。Hive 遠程服務通過 JDBC 等訪問來連接 Hive ，這是日常中最需要的方式。 

元數據存儲在Mysql或Derby中。Hive 中的元數據包括表的名字，表的列和分區及其屬性，表的屬性（是否為外部表等），表的數據所在目錄等。

由Cloudera公司開發的新型查詢系統。

 Impala元數據存儲在Hive中，不能獨立運行，依賴Hive元數據。

Impala執行查詢時，不需要轉換成MapRece任務，可以直接與HDFS或HBase進行交互查詢，查詢效率遠遠高於Hive。

Impala採用與Hive相同的SQL語法，ODBC驅動程序和用戶介面。

Impala主要由Impalad， State Store和CLI組成，執行查詢的時候分布在多個節點上進行。

Impalad：負責協調客戶端提交變得查詢的執行，與HDFS的數據節點運行在同一節點上。

State Store：負責收集分布在集群中各個Impalad進城的資源信息用於查詢調度。

CLI： 提供給用戶查詢使用的命令行工具（Impala Shell使用python實現），同時Impala還提供了Hue，JDBC， ODBC使用介面。

DBeaver中配置的使用JDBC來訪問。

其具體執行過程如下：

1、試用場景：

Hive：跑批

Impala：實時交互

2、計算方式：

Hive：依賴於MapRece框架

Impala：直接分發執行計劃到各個Impalad執行查詢

3、資源使用情況：

Hive執行過程中，若內存放不下所有數據則會使用外存。

Impala只用內存。

❼ hive是怎麼樣保存元數據的

保存到mysql中的，也可以使用內置的derby和其他資料庫

❽ Hive精華問答 | Hive的數據模型是怎樣的

Hive是一個數據倉庫基礎工具，它是建立在Hadoop之上的數據倉庫，在某種程度上可以把它看做用戶編程介面（API），本身也並不存儲和處理數據，依賴於HDFS存儲數據，依賴MR處理數據。它提供了一系列對數據進行提取、轉換、載入的工具。依賴於HDFS存儲數據，依賴MR處理數據。

1

Q：Hive是什麼?

A： Hive是基於Hadoop的一個數據倉庫工具，可以將結構化的數據文件映射為一張資料庫表，並提供類SQL查詢功能。本質是將HQL轉換為MapRece程序。

2

Q：Hive的設計目標是什麼?

A： 1、Hive的設計目標是使Hadoop上的數據操作與傳統SQL相結合，讓熟悉SQL編程開發人員能夠輕松向Hadoop平台遷移

2、Hive提供類似SQL的查詢語言HQL，HQL在底層被轉換為相應的MapRece操作

3、Hive在HDFS上構建數據倉庫來存儲結構化的數據，這些數據一般來源與HDFS上的原始數據，使用Hive可以對這些數據執行查詢、分析等操作。

3

Q：Hive的數據模型是怎樣的？

A： Hive資料庫

內部表

外部表

分區

桶

Hive的視圖

Hive在創建內部表時，會將數據移動到數據倉庫指向的路徑，若創建外部表，僅記錄數據所在的路徑，不對數據位置做任何改變，在刪除表的時候，內部表的元數據和數據會被一起刪除，外部表只會刪除元數據，不刪除數據。這樣來說，外部表要比內部表安全，數據組織液更加靈活，方便共享源數據。

4

Q：Hive都有哪些調用方式？

A ： 1、Hive Shell

2、Thrift

3、JDBC

4、ODBC

5

Q：Hive的運行機制是什麼？

A： 1、將sql轉換成抽象語法樹

2、將抽象語法樹轉化成查詢塊

3、將查詢塊轉換成邏輯查詢計劃(操作符樹)

4、將邏輯計劃轉換成物理計劃(MRjobs)

福利

掃描添加我 微信 ，備注「 姓名+公司職位 」，加入【 雲計算學習交流群 】，和志同道合的朋友們共同打卡學習！

❾ Hive入門概述

1.1 什麼是Hive

Hive：由Facebook開源用於解決海量結構化日誌的數據統計。

Hive是基於Hadoop的一個數據倉庫工具，可以將結構化的數據文件映射為一張表，並提供類SQL查詢功能。本質是：將HQL轉化成MapRece程序

Hive處理的數據存儲在HDFS

Hive分析數據底層的實現是MapRece

執行程序運行在Yarn上

1.2 Hive的優缺點

1.2.1 優點

操作介面採用類SQL語法，提供快速開發的能力（簡單、容易上手）。

避免了去寫MapRece，減少開發人員的學習成本。

Hive的執行延遲比較高，因此Hive常用於數據分析，對實時性要求不高的場合。

Hive優勢在於處理大數據，對於處理小數據沒有優勢，因為Hive的執行延遲比較高。

Hive支持用戶自定義函數，用戶可以根據自己的需求來實現自己的函數。

1.2.2 缺點

1．Hive的HQL表達能力有限

（1）迭代式演算法無法表達

（2）數據挖掘方面不擅長

2．Hive的效率比較低

（1）Hive自動生成的MapRece作業，通常情況下不夠智能化

（2）Hive調優比較困難，粒度較粗

1.3 Hive架構原理

1．用戶介面：Client

CLI（hive shell）、JDBC/ODBC(java訪問hive)、WEBUI（瀏覽器訪問hive）

2．元數據：Metastore

元數據包括：表名、表所屬的資料庫（默認是default）、表的擁有者、列/分區欄位、表的類型（是否是外部表）、表的數據所在目錄等；

默認存儲在自帶的derby資料庫中，推薦使用MySQL替代derby存儲Metastore

3．Hadoop

使用HDFS進行存儲，使用MapRece進行計算。

4．驅動器：Driver

（1）解析器（SQL Parser）：將SQL字元串轉換成抽象語法樹AST，這一步一般都用第三方工具庫完成，比如antlr；對AST進行語法分析，比如表是否存在、欄位是否存在、SQL語義是否有誤。

（2）編譯器（Physical Plan）：將AST編譯生成邏輯執行計劃。

（3）優化器（Query Optimizer）：對邏輯執行計劃進行優化。

（4）執行器（Execution）：把邏輯執行計劃轉換成可以運行的物理計劃。對於Hive來說，就是MR/Spark。

Hive通過給用戶提供的一系列交互介面，接收到用戶的指令(SQL)，使用自己的Driver，結合元數據(MetaStore)，將這些指令翻譯成MapRece，提交到Hadoop中執行，最後，將執行返回的結果輸出到用戶交互介面。

1.4 Hive和資料庫比較

由於 Hive 採用了類似SQL 的查詢語言 HQL(Hive Query Language)，因此很容易將 Hive 理解為資料庫。其實從結構上來看，Hive 和資料庫除了擁有類似的查詢語言，再無類似之處。本文將從多個方面來闡述 Hive 和資料庫的差異。資料庫可以用在 Online 的應用中，但是Hive 是為數據倉庫而設計的，清楚這一點，有助於從應用角度理解 Hive 的特性。

1.4.1 查詢語言

由於SQL被廣泛的應用在數據倉庫中，因此，專門針對Hive的特性設計了類SQL的查詢語言HQL。熟悉SQL開發的開發者可以很方便的使用Hive進行開發。

1.4.2 數據存儲位置

Hive 是建立在 Hadoop 之上的，所有 Hive 的數據都是存儲在 HDFS 中的。而資料庫則可以將數據保存在塊設備或者本地文件系統中。

1.4.3 數據更新

由於Hive是針對數據倉庫應用設計的，而數據倉庫的內容是讀多寫少的。因此，Hive中不建議對數據的改寫，所有的數據都是在載入的時候確定好的。而資料庫中的數據通常是需要經常進行修改的，因此可以使用 INSERT INTO … VALUES 添加數據，使用 UPDATE … SET修改數據。

1.4.4 索引

Hive在載入數據的過程中不會對數據進行任何處理，甚至不會對數據進行掃描，因此也沒有對數據中的某些Key建立索引。Hive要訪問數據中滿足條件的特定值時，需要暴力掃描整個數據，因此訪問延遲較高。由於 MapRece 的引入， Hive 可以並行訪問數據，因此即使沒有索引，對於大數據量的訪問，Hive 仍然可以體現出優勢。資料庫中，通常會針對一個或者幾個列建立索引，因此對於少量的特定條件的數據的訪問，資料庫可以有很高的效率，較低的延遲。由於數據的訪問延遲較高，決定了 Hive 不適合在線數據查詢。

1.4.5 執行

Hive中大多數查詢的執行是通過 Hadoop 提供的 MapRece 來實現的。而資料庫通常有自己的執行引擎。

1.4.6 執行延遲

Hive 在查詢數據的時候，由於沒有索引，需要掃描整個表，因此延遲較高。另外一個導致 Hive 執行延遲高的因素是 MapRece框架。由於MapRece 本身具有較高的延遲，因此在利用MapRece 執行Hive查詢時，也會有較高的延遲。相對的，資料庫的執行延遲較低。當然，這個低是有條件的，即數據規模較小，當數據規模大到超過資料庫的處理能力的時候，Hive的並行計算顯然能體現出優勢。

1.4.7 可擴展性

由於Hive是建立在Hadoop之上的，因此Hive的可擴展性是和Hadoop的可擴展性是一致的（世界上最大的Hadoop 集群在 Yahoo!，2009年的規模在4000 台節點左右）。而資料庫由於 ACID 語義的嚴格限制，擴展行非常有限。目前最先進的並行資料庫 Oracle 在理論上的擴展能力也只有100台左右。

1.4.8 數據規模

由於Hive建立在集群上並可以利用MapRece進行並行計算，因此可以支持很大規模的數據；對應的，資料庫可以支持的數據規模較小。

❿ iceberg 元數據

以下為一個hive-catalog的iceberg表的所有存在hdfs目錄中的文件
包含
1.parquet數據文件
2.json元數據文件
3.avro snapshot文件
4.avro manifest文件

hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-319a206d-7ead-415d-9ec8-700c1a49b8c4-00001.parquet
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-319a206d-7ead-415d-9ec8-700c1a49b8c4-00003.parquet
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-319a206d-7ead-415d-9ec8-700c1a49b8c4-00004.parquet
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-319a206d-7ead-415d-9ec8-700c1a49b8c4-00005.parquet
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-319a206d-7ead-415d-9ec8-700c1a49b8c4-00006.parquet
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-319a206d-7ead-415d-9ec8-700c1a49b8c4-00007.parquet
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-319a206d-7ead-415d-9ec8-700c1a49b8c4-00008.parquet
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-319a206d-7ead-415d-9ec8-700c1a49b8c4-00009.parquet
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-319a206d-7ead-415d-9ec8-700c1a49b8c4-00010.parquet
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-319a206d-7ead-415d-9ec8-700c1a49b8c4-00011.parquet
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-319a206d-7ead-415d-9ec8-700c1a49b8c4-00012.parquet
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/data/00000-0-79d89118-5069-4877-8332-2a592c887fe3-00001.parquet

hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/00000-f9a42593-ab76-4933-a739-8e10b476fc85.metadata.json
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/00001-2002be31-0182-4085-9173-aee3e4facc0b.metadata.json
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/00002-2c5e9702-a908-43a6-bbe8-0f0c6582e984.metadata.json
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/00003-3db39d6b-6311-4bdb-9d7b-b56f2df74fb3.metadata.json
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/00004-a5490f98-4daf-4592-abf1-fdcc408f1b0f.metadata.json
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/00005-b13e2c1f-1383-43c3-a53c-832ed8c68fa8.metadata.json
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/00006-68ce5b89-27fb-421a-8a49-42f383dfc587.metadata.json
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/00007-b3430d66-c9fb-401c-b800-e2ea4ad70d8d.metadata.json

hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/09769592-109f-4f6e-ab46-9b597dacfd43-m0.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/1a49a079-d7cf-41a6-931d-15ad2a44914b-m0.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/1a49a079-d7cf-41a6-931d-15ad2a44914b-m1.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/2b1ddf19-5701-4c0b-ac6a-ea41fdab9c07-m0.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/2b1ddf19-5701-4c0b-ac6a-ea41fdab9c07-m1.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/bf413511-d1cf-407f-bcc9-b6960cde7898-m0.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/bf413511-d1cf-407f-bcc9-b6960cde7898-m1.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/e97d1919-f47d-40c0-9eb6-24bf68f96980-m0.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/e97d1919-f47d-40c0-9eb6-24bf68f96980-m1.avro

hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/f0bd795c-6a10-41bc-8f79-437fef1ff5f9-m0.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/f0bd795c-6a10-41bc-8f79-437fef1ff5f9-m1.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/f0bd795c-6a10-41bc-8f79-437fef1ff5f9-m2.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/f0bd795c-6a10-41bc-8f79-437fef1ff5f9-m3.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/f0bd795c-6a10-41bc-8f79-437fef1ff5f9-m4.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/f0bd795c-6a10-41bc-8f79-437fef1ff5f9-m5.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/f0bd795c-6a10-41bc-8f79-437fef1ff5f9-m6.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/f0bd795c-6a10-41bc-8f79-437fef1ff5f9-m7.avro

hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/snap-1289984099921389549-1-1a49a079-d7cf-41a6-931d-15ad2a44914b.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/snap-3921229567852426700-1-bf413511-d1cf-407f-bcc9-b6960cde7898.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/snap-5386042144404510937-1-09769592-109f-4f6e-ab46-9b597dacfd43.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/snap-7125662397327732785-1-2b1ddf19-5701-4c0b-ac6a-ea41fdab9c07.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/snap-7329471080018208648-1-f0bd795c-6a10-41bc-8f79-437fef1ff5f9.avro
hdfs://10.177.13.120:8020/user/hive/dc-warehouse/iceberg_cdc_table/metadata/snap-7377732782289998100-1-e97d1919-f47d-40c0-9eb6-24bf68f96980.avro

以下為iceberg表在hive中的建表語句
REATE EXTERNAL TABLE iceberg_cdc_table (
id string COMMENT 'unique ID',
data string)
ROW FORMAT SERDE
'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'
STORED AS INPUTFORMAT
'org.apache.hadoop.mapred.FileInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.mapred.FileOutputFormat'
LOCATION
' hdfs://test-hdfs1/user/hive/dc-warehouse/iceberg_cdc_table'
TBLPROPERTIES (
'COLUMN_STATS_ACCURATE'='false',
'metadata_location'=' hdfs://test-hdfs1/user/hive/dc-warehouse/iceberg_cdc_table/metadata/00007-b3430d66-c9fb-401c-b800-e2ea4ad70d8d.metadata.json' ,
'numFiles'='0',
'numRows'='-1',
'previous_metadata_location'=' hdfs://test-hdfs1/user/hive/dc-warehouse/iceberg_cdc_table/metadata/00006-68ce5b89-27fb-421a-8a49-42f383dfc587.metadata.json' ,
'rawDataSize'='-1',
'table_type'='ICEBERG',
'totalSize'='0',
'transient_lastDdlTime'='1619089695')

其中metadata_location為當前的元數據文件，查看該文件

其中包含了所有的snapshot信息和所有的元數據文件信息
注意sequence-number和snapshot-id，它們是強關聯的，
sequence-number在v2版本的表中會作為標識數據的序列號
讀取的時候data文件中過濾掉equility-delete數據的時候是按sequence-number過濾的
就找比data文件snapshot大的equility-delete文件

小文件合並也和入數據checkpoint一樣生成新的snapshot
如果入庫snapshot是3 然後開始小文件合並 合並過程中入庫生成snapshot 4
然後合並完成生成snapshot 5
snapshot5的文件只合並了snapshot3的文件需要對snapshot 4中的equility-delete文件進行過濾 但是因為5比4大就不會過濾了

小文件合並跨了入庫的snapshot數據就有問題了

當前的snapshotID和對應的文件，查看該文件snap-7329471080018208648-1-f0bd795c-6a10-41bc-8f79-437fef1ff5f9.avro

這其中包含了所有的manifest文件，注意content屬性，在ManifestContent 中定義了其意義，0表示新增數據Manifest，1表示刪除數據Manifest

查看manifest文件

注意status屬性，在ManifestEntry介面中定義了枚舉

1表示添加的文件，2表示已經無效需要刪除的文件

還有content屬性，在FileContent 類中定義了其意義，0表示數據文件，1表示POSITION_DELETES文件，2表示 EQUALITY_DELETES文件

上面的snapshot文件snap-7329471080018208648-1-f0bd795c-6a10-41bc-8f79-437fef1ff5f9.avro是最新的snapshot文件，有6個content為0的文件和4個content為1的文件，因為我這里是初始入了100w條cdc數據生成一個data文件，然後經歷了4次updata，生成了4個data文件和4個delete文件，最後做了一個文件合並生成一個新的data文件。

我提取了其中對應的parquet文件和其status和content信息，state狀態為1的有3個，即只有3個有效的文件，一個是進行小文件合並後生成的文件，兩個是之後入庫的更新文件，這兩個也是一個是DATA文件一個是POSITION_DELETES文件。

而在小文件合並之前則是9個有效文件，5個data文件和4個POSITION_DELETES文件。