Flink + Iceberg 数据湖探索与实践

导读：今天主要和大家交流的是网易在数据湖 Iceberg 的一些思考与实践。从网易在数据仓库建设中遇到的痛点出发，介绍对数据湖 Iceberg 的探索以及实践之路。

主要内容包括：
数据仓库平台建设的痛点数据湖 Iceberg 的核心原理数据湖 Iceberg 社区现状网易数据湖 Iceberg 实践之路

01 数据仓库平台建设的痛点

痛点一：

我们凌晨一些大的离线任务经常会因为一些原因出现延迟，这种延迟会导致核心报表的产出时间不稳定，有些时候会产出比较早，但是有时候就可能会产出比较晚，业务很难接受。

为什么会出现这种现象的发生呢？目前来看大致有这么几点要素：

• 任务本身要请求的数据量会特别大。通常来说一天原始的数据量可能在几十TB。几百个分区，甚至上千个分区，五万+的文件数这样子。如果说全量读取这些文件的话，几百个分区就会向 NameNode 发送几百次请求，我们知道离线任务在凌晨运行的时候，NameNode 的压力是非常大的。所以就很有可能出现 Namenode 响应很慢的情况，如果请求响应很慢就会导致任务初始化时间很长。
• 任务本身的 ETL 效率是相对低效的，这个低效并不是说 Spark 引擎低效，而是说我们的存储在这块支持的不是特别的好。比如目前我们查一个分区的话是需要将所有文件都扫描一遍然后进行分析，而实际上我可能只对某些文件感兴趣。所以相对而言这个方案本身来说就是相对低效的。
• 这种大的离线任务一旦遇到磁盘坏盘或者机器宕机，就需要重试，重试一次需要耗费很长的时间比如几十分钟。如果说重试一两次的话这个延迟就会比较大了。

痛点二：

针对一些细琐的一些问题而言的。这里简单列举了三个场景来分析：

• 不可靠的更新操作。我们经常在 ETL 过程中执行一些 insert overwrite 之类的操作，这类操作会先把相应分区的数据删除，再把生成的文件加载到分区中去。在我们移除文件的时候，很多正在读取这些文件的任务就会发生异常，这就是不可靠的更新操作。
• 表 Schema 变更低效。目前我们在对表做一些加字段、更改分区的操作其实是非常低效的操作，我们需要把所有的原始数据读出来，然后在重新写回去。这样就会非常耗时，并且低效。
• 数据可靠性缺乏保障。主要是我们对于分区的操作，我们会把分区的信息分为两个地方，HDFS 和 Metastore，分别存储一份。在这种情况下，如果进行更新操作，就可能会出现一个更新成功而另一个更新失败，会导致数据不可靠。

痛点三：

基于 Lambda 架构建设的实时数仓存在较多的问题。如上图的这个架构图，第一条链路是基于 kafka 中转的一条实时链路（延迟要求小于5分钟），另一条是离线链路（延