湖仓一体雷声大雨点小？这三点需要关注

本期单口开源我们请到马进来和大家聊一聊 “湖仓一体”。

马进：网易数帆大数据实时计算技术专家湖一体项目负责人

 大家好，我是来自网易数帆的马进，今天跟大家聊聊湖仓一体。

湖仓一体是个舶来词，英文名称叫 Lakehouse，最早由 Databricks 公司在 2020 年提出。在 Databricks 的理念中，传统数据湖在批计算、AI、机器学习等领域有丰富的资源和实践，但是在流计算、数据质量和数据治理方面相较于传统数仓有较大不足。

为此，Databricks 提供了 Lakehouse 平台，基于数据湖之上，可以提供不弱于传统数仓的能力，也能享受数据湖在 AI、机器学习、批计算上的积累。

Databricks 作为一家商业化公司，讲述的 Lakehouse 的故事必然有营销的成分在，但必须承认的是，Lakehouse 这个概念已经深入人心。包括 Databricks 的老对手 Snowflake 也将自己标榜为 Lakehouse。在 Databricks 的故事里，Delta 是 Lakehouse 的存储底座，目前开源社区中，Iceberg 和 Hudi 也是和 Delta 对标的产品。所以现在行业内普遍会把 Lakehouse 与 Delta、Hudi 以及 Iceberg 关联到一起。

过去两年，我们与很多同行一起致力于将新型数据湖的技术应用到生产实践中。我们将这些项目的能力拆为两部分，第一部分是对现有方案的平替，比如说数据湖的 CDC 代替消息队列，基于数据湖的 Upsert 和读时合并代替 Kudu 这类实时数仓方案；第二部分是现有方案不具备的功能，比如时间旅行、数据回退、模式演进。

对第一部分而言，遇到最大的挑战是纯粹拿 Lakehouse 的理念去平替消息队列或者其他实时数仓的选型，在成熟度和性能上会有挑战；对第二部分的功能，比如时间旅行，对现有的用户规范或者用户的使用方式中很难起到非常大的收益。

所以，不少同行可能会有这样的感受，数据湖这个方向的技术虽然很热，但是实际上能落地的场景却不多，或者落地后能讲清楚的价值不多。

我们怎么来看待这个问题？

首先我们要相信，Lakehouse 指向的愿景，本身是非常有价值的。这个问题需要自顶向下地看。

回顾前十年的发展，在 2010 年到 2015 年间，Hadoop、Hive 这套数据湖体系在用户体量上有非常大的增长，现在基本成为离线数仓的事实标准。而围绕 Hadoop、Hive 以及在云端对象存储构建的数据研发的工作流，数据安全、数据地图、指标系统、模型以及支撑这套数据建设的方法论，大概是在 2015 年之后才逐渐成熟。

目前我们的用户基于这套数据建设的方法论，在构建离线数仓时已经形成了非常清晰的规范，用户的体量本身也会很大，但是对流和实时的场景，由于 Hive 在流事务能力上的缺失，行业内普遍采用 Kafka、Flink、Kudu、Doris，甚至一些数据库来做实时数仓的选型。而这些流程目前在数据建设的主流程里，其实是没有覆盖到的，需要用户自己去学习、理解和使用这些不同的系统。这里面会带来成本、人效、语义二义性等诸多问题。而 Lakehouse 的目标应当是将数据建设的方法论从离线拓展到流和实时，同时通过开放的表和文件格式、流批统一的数据加工流程，更好支持到AI、机器学习等领域。

从上面的分析我们可以得出三个结论：

• 用户使用 Delta、Iceberg、Hudi 这些技术的时候，要理解这三个项目，目前更多是 TableFormat 的定位，是对数据湖表格式的一层元数据封装，不等价于Lakehouse。Databricks 自己也没有说过，Delta 就是 Lakehouse。但是这三个项目所引领的表格式的功能是构建 Lakehouse的基础，而这个基础距离领先的Lakehouse实践。还差一层管理系统或者Lakehouse服务，这套服务应当在基础软件层为用户解决流式处理、数据优化、流批一体封装的问题。

• 用户在实践 Lakehouse 时，在关注新功能的同时，不应当把他当做 Hive 或者已有数据湖之外的一套东西，应当考虑怎么将现有的体系扩展到新的TableFormat之上，让现有的离线用户通过统一的交互和规范可以直接将离线产品拓展到实时和更多AI场景。在这个过程中，体系建设者要考虑兼容性问题、架构的共存问题，尤其对一些已有的离线业务去拓展实时场景，需要架构师去考虑怎么在对现有业务更小侵入的前提下把实时的方案构建出来，这样天然就是流批一体的。

 

• Lakehouse 的技术，目前还有很多不成熟的地方，比如实时写入会产生很多小文件，怎样为业务提供透明无感的数据优化服务，生产可用的读时合并应当怎么度量数据新鲜度，性能怎样保障等。

针对上面提出的问题，经过两年的探索、研发和实践，我们团队在7月底开源了流式湖仓服务 Arctic 这个项目。Arctic 是基于开源 TableFormat 之上的湖仓管理服务。对上面提出的问题，我们在这个项目中都提供了解决方案，欢迎大家来关注。

刚才提到从Hadoop生态的应用到上层建筑的完善，其实中间有至少3-5年的时间，而Lakehouse目前还处于非常早期的阶段，我们期待与行业内更多的小伙伴
一起构建领先的Lakehouse实践，欢迎大家关注和参与到我们这个项目。