Apache iceberg：Netflix 数据仓库的基石

5-year challenges

智能处理引擎

CBO，更好的join实现
缓存结果集，物化视图

减少人工维护数据

data librarian services 数据图书馆服务
declarative instead of imperative 陈述式而不是命令式

Problem Whack-a-mole

1、不安全的操作随处可见: 同时写多个分区，列重命名
2、和对象存储交互有时候会出现很大的问题: eventual consistency to performance problems(最终一致性的性能问题)、output committees can’t fix it
3、无休止的可扩展性挑战。

iceberg

在单个文件中修改或跳过数据
当然多个文件也支持这些操作

Hive 表的核心思想是把数据组织成目录树，如上所述。

如果我们需要过滤数据，可以在 where 里面添加分区相关的信息。

带来的问题是如果一张表有很多分区，我们需要使用 HMS（Hive MetaStore）来记录这些分区，同时底层的文件系统（比如 HDFS）仍然需要在每个分区里面记录这些分区数据。

这就导致我们需要在 HMS 和文件系统里面同时保存一些状态信息；因为缺乏锁机制，所以对上面两个系统进行修改也不能保证原子性。

当然 Hive 这样维护表也不是没有好处。这种设计使得很多引擎（Hive、Spark、Presto、Flink、Pig）都支持读写 Hive 表，同时支持很多第三方工具。简单和透明使得 Hive 表变得不可或缺的。

Iceberg 的目标包括：

1、成为静态数据交换的开放规范，维护一个清晰的格式规范，支持多语言，支持跨项目的需求等。
2、提升扩展性和可靠性。能够在一个节点上运行，也能在集群上运行。所有的修改都是原子性的，串行化隔离。原生支持云对象存储，支持多并发写。
3、修复持续的可用性问题，比如模式演进，分区隐藏，支持时间旅行、回滚等。

Iceberg 主要设计思想：

记录表在所有时间的所有文件，和 Delta Lake 或 Apache Hudi 一样，支持 snapshot，其是表在某个时刻的完整文件列表。每一次写操作都会生成一个新的快照。

读取数据的时候使用当前的快照，Iceberg 使用乐观锁机制来创建新的快照，然后提交。

Iceberg 这么设计的好处是：

所有的修改都是原子性的；
没有耗时的文件系统操作；
快照是索引好的，以便加速读取；
CBO metrics 信息是可靠的；
更新支持版本，支持物化视图。

Iceberg 在 Netflix 生产环境维护着数十 PB 的数据，数百万个分区。对大表进行查询能够提供低延迟的响应。

未来工作：1、支持 Spark 向量化以便实现快速的 bulk read，Presto 向量化已经支持。2、行级别的删除，支持 MERGE INTO 等