本文节选自数据湖技术成熟度曲线发布会圆桌整理文档，本圆桌由快手、前腾讯、平安产险等公司的专家参与讨论。
靳国卫（主持人）：数据湖技术是对数仓技术的一种补充，其目标都是为了应对实际业务中的问题。然而，在数仓体系架构发展的过程中，不同阶段会产生不同的解决方案。因此，从架构角度来看，目前大概有四种湖仓架构：湖仓一体、湖上建仓、仓上建湖、湖仓融合。请邵老师分享一下对这些模式的理解，它们分别解决了哪些核心问题，适用于哪些业务场景？
邵赛赛（前腾讯数据湖负责人）：我个人的理解是这样的，这些湖仓模式的选择，都是由现有的数据平台形态来决定的。
比如大多数互联网公司构建的数据平台是基于Hadoop这样的体系，这套Hadoop体系就是类似于一套数据湖架构，所有数据都存储在HDFS或者对象存储中。当你想要利用一些数仓的特性，比如Schema Evolution、快照或者time travel等功能时，可以引入表格式的数据来增强这些能力，这就是所谓的湖上建仓。也就是说，在现有的Hadoop体系上，通过引入像Iceberg或Hudi这样的湖格式，使得湖中的数据表具备一定的数仓能力。
另一方面，对于一些传统企业，尤其是一些大型企业，他们的数据平台通常依赖于传统的商业数仓。以金融行业为例，很多公司会选择像Teradata或Snowflake这样的商业数仓，典型架构是存储和计算一体化，即它们自己解决了所有问题，不是一个开放的架构。当这些企业希望进行更多的场景处理，比如交互式查询、机器学习或其它场景时，原有的数仓架构就无法满足需求。这时候，他们可能希望在原有数仓基础上引入数据湖格式，增强数仓的能力，这就是所谓的仓上建湖。现在像Snowflake已经可以支持类似的场景，通过支持Iceberg的Catalog服务，用户不仅限于使用Snowflake引擎，还可以利用其它引擎来查询数据。同样，StarRocks等系统也可以支持这种扩展方式。
通过这种方式，企业可以不再局限于传统的报表场景，能够满足更多业务需求，比如机器学习和数据探索。
而最终，理想的状态是达到湖仓一体的形态，即通过一套数据既能满足数仓的需求，也能满足数据湖的需求。而路径的选择，主要取决于企业现有的数据平台架构和技术选型。
靳国卫（主持人）：当前的湖仓架构与传统数仓之间有哪些差异？
邵赛赛（前腾讯数据湖负责人）：传统数仓具备大量原生数据库的能力，包括事务处理、高性能的CRUD操作，以及优良的存储布局设计。此外，传统数仓还通常拥有更丰富的缓存机制和索引结构来加速查询。
相比之下，数据湖的架构在某些能力上确实能够覆盖数仓的部分功能特性。例如，数据湖格式可以支持UPSERT和DELETE操作，具备time travel和Schema Evolution等功能。不过，数据湖实际上并不是一个完整的系统，它更像是一个表格式的实现，缺乏企业级数仓应具备的服务化能力。具体来说，比如缺少缓存层、索引层、统计信息存储等优化机制，这使得它在性能方面与传统数仓存在一定的差距。为了使数据湖具备与传统数仓相当的能力，我们需要进行大量额外的工作，包括在引擎层面上引入更快的查询引擎，并增强索引和缓存能力，从而提升整体性能，使其能够与传统企业级数仓相竞争。
本圆桌其他问答请看以下文章：
