数据湖 Table format 中个别的功能

总结下来 Table format 有四点核心特性。

第一，结构自由。像之前的 Hive 只能支持简单的加列操作，而在 Delta、Iceberg 这样的 Table format 之上用户可以自由地更改表的结构，可以加列、减列、改列，而且对数据的迁移和变更不会有要求。

第二，读写自由。因为它通过快照能够保证数据的 ACID，任何实时、离线以及 AI 的需求都可以自由地往这个表里面写数据或者读数据。

第三，流批同源。因为 Table format 核心的一个功能是可以很好地支持流场景，我们的批和流都可以往新的 Table format 去写和读。

第四，引擎平权。这点非常重要，它不能只是绑定某一个引擎，比如说像 Delta 在 1.0 时代是 Spark 生态中的一个组件，在一个月之前 Delta2.0 的发布再次向我们证明了去适配多个引擎的重要性。

在 Table format 这些项目的官网中，他们会主推一些功能主要包含 CDC、SQL 扩展，数据的 Rollback，以及 time travel，模式演进（Schema evolution）以及我们经常说的流式更新（Upsert）、读时合并（merge-on-read）的功能。

CDC 一定程度上能起到平替消息队列的作用，比如说在生产场景中，实时计算主要会用 Kafka 或者 Pulsar 做流表的选型。有了 Table format 之后，我们可以基于数据湖来实现类似于消息队列的功能，当然它的数据延迟会从毫秒或者秒级降级为分钟级别。像 Upsert、读时合并和行业内或者说很多公司去推广数据湖的主要场景，就是拿这个实时更新以及读时合并去平替 Apache Kudu、Doris、Greenplum 这些实时更新的数仓系统。

企业需要怎样的数据湖

首先一点是如果我们只是关注数据湖 Table format 中个别的功能，推广起来是非常困难的。比如说数据湖的 CDC 功能，确实在某种程度上能够平替消息队列，但是也会引入一些其他的问题：首先是延迟的问题；其次是用数据湖做消息队列可能会引入很多小文件，这个小文件谁来管理？还有第三个是比较隐形的问题，以前消息队列的成本就是挂在业务团队那边，如果我们现在用一个公共的数据湖底座，这个成本该怎么分摊？

在过去两年中，我们跟行业内很多公司交流，大体上都是在这样一种矛盾之中挣扎，想用数据湖的新技术来替代一些其他方案，对业务的吸引力是非常不足的。我们的数据湖或者 Lakehouse（湖仓一体）的技术究竟能给企业带来怎样的价值？

在我们的生产场景中，我们的整个数据平台体系在 2020 年遇到最主要的问题，就是流批平台割裂。大家知道我们围绕 Hive 这套离线数仓已经产生了非常丰富的方法论，从数据模型、数据资产到数据质量，基于数据湖的开放架构我们产生了非常好的一套规范、标准以及治理体系。

但是我们把目光切换到实时场景下，目前主要用 Flink 做实时计算，用 Kafka 作为流表的选型，当我们做流表 join 时可能单独需要从数据库那边拉一个实时同步的任务，后面如果我们做数据分析，需要比较高的数据新鲜度，需要引入 Kudu 或者 Doris 这些能够准实时或者实时更新的数仓系统。

这套东西和我们离线整套的技术选型以及工具是非常割裂的，而且没有形成比较好的规范，主要还是点对点的开发为主。

举个例子，如果我们既要做实时也要做离线，就需要拉两套链路。离线的链路根据我们整套方法论，根据离线整个流程的工作流，是能比较容易规范地定义出一套出来。实时场景下我们更多需要开发者，需要用户自己去了解 Flink 怎么玩儿，Kafka 怎么读，这个过程中序列化、反序列化怎么做，怎么在 Kudu 上建表，这一套规范给用户带来了非常大的负担。