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文件。