iceberg数据湖实践踩坑记录

---

坑点描述

iceberg是Dremio公司开源的一个数据湖项目，核心思想借鉴于dremio数据湖引擎。Dremio的其商业化产品dremio是一个基于SaaS的数据服务平台(Daas)，其技术团队中有从mapr公司出来的两个技术大佬，毋庸置疑其技术实力。目前，iceberg在多家大厂也有不少成功案例。
在经过案例的研究后，决定进行iceberg数据湖实践。在实践过程中遇到的一些问题记录如下：

一、数据湖存储

由于iceberg是以jar包的形式进行使用，没有自身独立的服务接口和数据存储(依赖于hdfs和hive)，调研了具体数据存储。了解到iceberg内部管理数据的方式是以dataFile的方式，每个dataFile是单独的文件，因此会存在小文件数量增多影响读写效率的问题。从网上了解到alibaba的JindoFs是专门用于解决数据湖的数据存储的产品，因此好不犹豫的进行相关接入。

二、flink读写iceberg

内部数据处理工具使用的flink，因此参考iceberg官网开发了flink读写iceberg的插件。
在读取上，使用snapshotId进行读取数据的范围控制，这也是iceberg可以做到增量读取，读写ACID机制的原因。目前iceberg官方提供的jar(版本0.10.0)包并不支持unbounded读取，默认只读取到当前为止已提交的snapshot，因此如果需要做到iceberg的数据订阅，需要进行二次开发。
在写入上，采用异步批量写的方式，依赖于定时checkpoint进行数据快照的创建。有个低级问题是配置命名有歧义。比如write.parquet.page-size-bytes这个配置用于控制写入dataFile的page数据条数, 而不是实际的数据大小。

三、presto接入iceberg查询

目前是先通过hive查询JindoFS上的数据，然后配置presto的iceberg connector和hive metastore进行查询。这里presto是先从hive metastore获取所有分区的位置，然后再拿到所有的dataFile信息，进而进行数据查询。是否可以不依赖于hive metastore直接进行查询？

总结

目前先记录这些吧，后续遇到其他问题再进行记录