AWS 推出了 S3云数据存储的新时代来了。后来它有了一个好听的名字Data Lake。让他名副其实的是 Parquet 数据格式。Databricks 是做 Spark 起家的自然要支持 Parquet 格式。在支持的过程中发现增删改是个问题事务也是个问题于是提出了 Delta Lake 格式。不过这也不是什么独创Iceberg、Hudi 等都有类似解决方案。概念上有这样的层次关系东西本质解决什么问题HudiLakehouseTable Format数据怎么高频 Upsert / Update / Delete尤其 CDCIcebergLakehouseTable Format怎么把 Data Lake 文件组织成可靠、可演进、适合分析的表Delta LakeLakehouseTable Format同上但深度绑定 Databricks/Spark 生态TrinoSQL Query Engine怎么高效查询这些湖上的表Databricks Lakehouse完整数据平台把存储、表格式、计算、治理、AI、ETL 等整合起来Databricks 是一家商业公司并且体量足够大所以它需要寻找足够大的市场。实时计算的市场相对于数据分析、BI 来说要小得多所以Databricks 选择 Delta Lake 是符合其商业定位的。Delta Lake 虽然支持写操作但是对于小事务支持得很不好它更舒服的写入方式是批量写入。如果你使用很多小事务则会生成大量碎片小文件影响读效率。当商业发展到一定规模增长达到一定程度时一方面能看到更多客户需求另一方面要寻找新的增长点。Streaming 自然还是会落到 Databricks 视野之中。它的解决方案是Lakebase。所谓 Lakebase实际是一个 PostgresSQL 独立进程它能将写入 PostgresSQL 的数据以 10 秒左右的延迟批量写成 Delta Lake 的格式。也就是说在分析侧可以获得延迟为 10 秒左右的实时分析能力。Databricks 的时间线大致如下