“数据湖”、“湖仓一体”及“流批一体”等概念，是近年来大数据领域热度最高的词汇，在各大互联网公司掀起了一波波的热潮，各家公司纷纷推出了自己的技术方案。

在2020年末，袋鼠云技术团队做了众多技术方案的调研，包括包括Delta Lake、Hudi、Iceberg，我们最终选用了Iceberg，在落地过程中深度使用了Iceberg并进行了部分改造，在这个过程中，我们积累出了一些经验和探索实践，和大家共同讨论讨论。

为什么选择Iceberg

Iceberg作为Apache基金会下的一个顶级项目，是业界公认的开源数据湖实现方案之一，考虑到任何概念的提出本质上是源于底层软硬件技术或架构上取得了新的突破，我们首先站在技术演进的角度对Iceberg的出现契机和应用场景进行分析。

大数据存储技术现状

2006年Hadoop框架横空出世，改变了企业对数据的存储、处理和分析的认知，加速了大数据的发展，形成了完善的生态圈。工程师们将庞杂的历史数据存在分布式文件系统HDFS中，通过Hive、Spark等进行加速计算处理。至今为止，HDFS已然成为广泛应用的大数据基础组件。

在这个大数据技术发展过程中，也面临着一些问题。在Hive中，将表绑定为HDFS上的一个目录，通过HiveMetaStore记录其绑定的存储位置，计算引擎查询数据时请求主节点获取文件并读取，这天然缺少事务保证：某个用户写入的文件其他用户立即可见，没有隔离性；即便先写入到隐藏文件中，待事务提交后再全部改名可见，因为一批文件的改名不是原子操作，这只能保证分区级别的原子性。随着对象存储的广泛应用，通过主节点去获取全部文件有比较大的性能损耗，因为对象存储的“List”性能较差。

经过以上分析，我们发现Hive中这种设计的缺陷在于缺乏对表数据文件的管理维护：对于表中不同时刻包含的数据文件，都要即时访问HDFS主节点获取，这样子就造成了比较大的资源浪费。

而数据湖却能很好的解决这一问题，数据湖是一个集中各种形式和来源数据的存储区域，存储内容虽然种类繁多却管理有序，对数据文件的组织维护能够高效地帮助我们对接各类底层存储和上层计算。

数据湖技术选型——Iceberg

我们知道问题的关键在于“对表数据文件的管理维护”，基于此就可以开展技术选型了。在2020年末，技术团队做了众多技术方案的调研，包括包括Delta Lake、Hudi、Iceberg，我们最终选用了Iceberg。

而选择Iceberg的原因，正是基于袋鼠云的技术栈的具体情况做了充足考虑：袋鼠云中的离线计算、实时计算、智能标签等应用，在计算层需要依托Spark、Flink、Trino等多种引擎为客户解决不同的业务诉求，在底层则可能需要对接客户自建云、公有云等混合存储。这就要求所选择的技术方案必须能满足对接多种类型的需求。

Iceberg具备接口开放、易于拓展的优点，十分符合我们的选型要求。在存储层HDFS上增加一个中间层Iceberg以跟踪数据文件，不必改变其他层的架构设计，就可以享受到Iceberg对数据文件管理带来的极速体验与美妙特性。下图展示了袋鼠云基于Iceberg框架的数据湖架构设计：

基于前述关键点，我们介绍下Iceberg的设计，参考下图所示：

Iceberg在数据文件的基础上增加了文件清单和文件快照等索引，通过这些索引我们就能跟踪到每张表在当前时刻有哪些数据文件，这就解决了前文提到的Hive中的设计缺陷：某个用户写入的临时文件不会被其他用户读取到，因为这些文件没有被快照记录；每个事务修改跟踪的数据文件时，需要向锁服务进行申请，成功获取到锁许可之后可以更新快照内容，一次快照修改可以增加多个文件，这样就保证原子性；预先记录好目录下的每个数据文件可以避免对HDFS主节点的多次访问，对云存储友好。

想了解更多数据湖、湖仓一体解决方案，可以点击查看，免费试用https://www.dtstack.com/dtengine/easylake

免责申明：

本文系转载，版权归原作者所有，如若侵权请联系我们进行删除！

《数据治理行业实践白皮书》下载地址：https://fs80.cn/4w2atu

《数栈V6.0产品白皮书》下载地址：https://fs80.cn/cw0iw1

想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友，浏览袋鼠云官网：https://www.dtstack.com/?src=bbs

同时，欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术群」，交流最新开源技术信息，群号码：30537511，项目地址：https://github.com/DTStack