1.事务性

从事务性上来说，iceberg具有更高的数据质量。
因为iceberg本质是一种table format，屏蔽了底层的存储细节，写入数据时候需要严格按照schema写入。而hive可以先写入底层数据，然后使用load partition的方式来加载分区。这样就可能造成hive的实际存储数据与schema不一致。
另外，hive的分区数据生成以后，还可以直接删掉hdfs路径的文件(包括代码有bug无意中删除数据等)，这样经常会存在分区数据不存在的场景。而iceberg基于快照提供了事务处理能力，使其实现了读写分离能力。iceberg在执行delete操作或者overwrite操作时，不会将原有的数据进行直接删除，而是新增了一个snapshot，在这个snapshot中引用新的数据文件，这样就实现了事务处理。

2.降低数据pipeline延时

hive针对数据进行update操作时，需要先将数据读取出来修改后再重新写，有极大的修正成本。Iceberg 所具有的修改、删除能力能够有效地降低开销，提升效率。
同时，传统数仓从数据ETL到数据入库入仓，流程一般较长，需要后续加入一些验证逻辑保证数据的准确性。因为流程长，架构也较为复杂，所以数据入库所需时间也较长。而iceberg的事务性设计可以保证流程的简易性，降低整个数据pipeline的延时。

3.对接不同计算引擎

iceberg 上层可以支持 Spark、Flink、Presto等多种计算引擎，当只需要进行离线批处理的时候，我们可以直接将iceberg当hive 表来使用，通过 Spark + iceberg 搭建原来的离线数据计算流。

当有实时指标计算的需求时，可以使用 flink 实时计算框架，来构建近实时数仓，而且iceberg 存储全量数据，且仍然有批计算能力，可以在流式计算作业运行的同时，跑一个批作业来进行数据回溯或者数据纠正。

4.小文件处理

在传统的实时数仓中，由于列式存储相对行式存储有较高的查询性能，我们一般采用parquet，orc等列存储数据格式。但是这种列式格式无法追加，流式数据又无法等候太长时间等到文件够了一个hdfs block块大小再写入。所以不可避免的产生了一个令人头大的问题，即小文件问题。大量小文件会对namenode造成巨大的压力，极大影响hdfs服务的稳定与性能，因此如何解决小文件问题也是传统的hive数仓面临的一个重要课题。

传统的流式数据入库的过程中对小文件进行合并会产生很多问题，比如流式数据不断的往hive表进行写入，如果同时有一个合并程序进行小文件的合并，那么这时候对同一份数据进行读写。会不会产生问题。如何保证事务，出错了怎么回滚呢，这些都是很棘手的问题。

而在iceberg中，提供了相应的API来进行小文件合并。

SparkActions.get(spark).rewriteDataFiles(icebergTable).execute()

5.统一接入数据源

通过iceberg 数据湖方案构建的近实时数仓可以将基于hive 的离线数仓和基于kafka等消息队列构建的实时数仓进行统一。你可以将日志数据、changeLog数据统一存储在iceberg 中，通过 iceberg 构建数仓只需要维护一套存储，甚至是一套计算链路。
同时 iceberg 还具有很好的开放性。得益于 spark 和 flink 的丰富的生态，可以将 MySQL Binlog数据、日志数据导入到 Iceberg 进行分析，也可以将 Iceberg 中的数据导入到 Hive、Doris等其他存储中进行分析。将一份数据导入 Iceberg，你永远不用担心在使用数据的时候取不出来。