今天看到一个重磅新闻，Databricks 10亿～20亿美元的金额收购了初创公司 Tabular。Tabular 是国际开源湖仓项目 Iceberg 核心创始团队 Ryan Blue 等人于 2021 年创办的公司，目前公司人员40人左右。关于这次收购和湖仓一体框架的未来，谈一谈我们的思考。
1. 生态上的思考
一直以来，Iceberg 以开放、中立的表格式，建立了强大的生态，除了 Spark、Flink、Trino、Doris 等开源数据处理引擎的适配，也吸引了商业数仓如 Snowflake 的支持。而 Databricks 自家的 Delta Lake，由于初期开源策略摇摆不定，在表格式开源生态上已经难以匹敌 Iceberg ，这可能也是 Databricks 本次收购的初衷，Databricks 在收购官宣文章中提到，双方团队未来方向是共同建立统一开放的表格式。
然而虽然 Iceberg 有很清晰的 Table Format Spec，在各个引擎的实现上却并不统一，功能并不能够完全对齐。例如由于 Iceberg 缺失 Native 实现，在 C++ 实现的查询引擎上（如 Doris、Velox），以及 Python 的接口，都是各自重新实现；在 Flink 上，Iceberg 至今不支持 CDC 读。这些问题，给 Iceberg 造成了一定程度生态上的混乱。在本次收购后，鉴于 Databricks 的商业策略已经越来越封闭（包括 Spark Streaming 的功能也长期不做更新），很多商业数仓公司如 Snowflake 是否还愿意继续支持 Iceberg，也是存疑的。
2. 技术上的思考
从技术上看，现在表格式功能方面，各个开源框架已经比较趋同了，从 Catalog 到表的增删改查，甚至都有开源项目把 Iceberg、Hudi 再封装成统一接口，Databricks 的 UniForm 也是类似的统一封装的思路。对于用户来说可能已经不会重点关注表格式到底是哪种。因此，数据湖框架未来的重点，应该是如何满足用户越来越多样化的数据管理、数据/AI 等多种计算引擎生态连接的需求。
我们一开始选择完全自研底层云原生湖仓一体框架 LakeSoul，并没有选择套壳 Iceberg，虽然过程很艰辛，但是现在看也逐步建立了几个明显优势：
1.Native IO 层实现，统一提供 Upsert 写入和 Merge on Read 读取接口，并采用 Arrow 作为数据交换格式，能够很方便地对接大数据框架、MPP 查询引擎、AI 框架，并针对云原生环境做了大量性能优化。
2.元数据服务提供了更高的并发能力、更大规模数据的管理能力。在高并发流式写入、大规模表的扫描计划（Scan Planning）生成上都有显著的性能和规模优势。
3.企业级的安全特性。支持多空间租户隔离、表级别权限控制。权限隔离实现在元数据服务和存储层上，无论是 SQL 作业，还是 Java/Python代码，均能保证权限隔离。
4.完善的数据双向集成能力。LakeSoul 提供了完全自动化的数据实时导入、导出工具。导入、导出均支持动态 Schema 变更，支持多种开源、商业数据库和消息队列的连接。
5.元数据、IO 层 Native 实现并封装上层接口，包括扫描查询计划生成、分区/数据过滤条件下推、Merge on Read，CDC 读写、权限控制。无论是大数据框架、查询引擎、AI 框架，都能保持统一的功能特性和一致的性能。
3. 未来的思考
我们认为，一套完善的云原生湖仓一体数据智能平台，不仅是需要一个统一的表格式，还需要有完善的功能体系、在云上优秀的 IO 性能和弹性计算能力，以及强大的多引擎连接能力。我们也将致力于建设新一代湖仓一体框架基础软件，成为数据和 AI 的统一底座。
关于 LakeSoul 的技术解析，我们在之前的公众号文章里做了大量介绍，可以参考之前的若干文章链接：
