iceberg上游组件将数据写入完成后，下游组件及时可读，可查询。可以满足实时场景，并且iceberg同时提供了流/批读接品、流/批写接口，可以在同个流程里，同时处理流数据和批数据，大大简化etl链路。
数据表深化（table evolution）
iceberg可以通sql的方式进行表级别模式演进，进行这些操作的时候，代价极低。不存在读出数据写入或者迁移数据这种费时费力的操作。
比如在常用的hive中，如果我们需要把一个按天分区的表，改成按小时分区，此时不能再按原表上直接修改，只能新建一个按小时分区的表，然后再把数据insert 到新的小时的分区表。而且即使我们通过rename的命令把新表的名字改为原表，使用原表的上次层应用，也可能由于分区字段修改，导致需要修改sql。这样花费的经历是非常繁琐的。
模式演化（schema evolution）
iceberg支持下面几种模式演化：
add:向表或者嵌套结构增加新列。
drop:从表中或者嵌套结构中移除一列。
rename:重命名表中或者嵌套结构中的一列。
update:将复杂结构（strucat,map<key,value>,list）中基本类型长度，比如tinyint修改为int
recorder:改变列或者嵌套结构中字段的排序顺序。
Iceberg保证模式演化（Schema Evolution）是没有副作用的独立操作流程, 一个元数据操作, 不会涉及到重写数据文件的过程。具体的如下:
Ø 增加列时候，不会从另外一个列中读取已存在的的数据
Ø 删除列或者嵌套结构中字段的时候，不会改变任何其他列的值
Ø 更新列或者嵌套结构中字段的时候，不会改变任何其他列的值
Ø 改变列列或者嵌套结构中字段顺序的时候，不会改变相关联的值
在表中Iceberg 使用唯一ID来定位每一列的信息。新增一个列的时候,会新分配给它一个唯一ID, 并且绝对不会使用已经被使用的ID。
使用名称或者位置信息来定位列的, 都会存在一些问题, 比如使用名称的话,名称可能会重复, 使用位置的话, 不能修改顺序并且废弃的字段也不能删除。
分区演化（Partition Evolution）
Iceberg可以在一个已存在的表上直接修改，因为Iceberg的查询流程并不和分区信息直接关联。
当我们改变一个表的分区策略时，对应修改分区之前的数据不会改变, 依然会采用老的分区策略，新的数据会采用新的分区策略，也就是说同一个表会有两种分区策略，旧数据采用旧分区策略，新数据采用新新分区策略, 在元数据里两个分区策略相互独立，不重合。
在查询数据的时候，如果存在跨分区策略的情况，则会解析成两个不同执行计划，如Iceberg官网提供图所示：图中booking_table表2008年按月分区，进入2009年后改为按天分区，这两中分区策略共存于该表中。
借助iceberg的隐藏分区，在写sql查询的时候，不需要在sql中特别指定分区过滤条件。iceberg会自动分区，过滤不需要的数据。iceberg分区演化同样是一个元数据操作，不会重写数据文件。
.
