回眸 Databricks 历史片段

AWS 推出了 S3，云数据存储的新时代来了。后来它有了一个好听的名字，Data Lake。让他名副其实的是 Parquet 数据格式。

Databricks 是做 Spark 起家的，自然要支持 Parquet 格式。在支持的过程中发现，增删改是个问题，事务也是个问题，于是提出了 Delta Lake 格式。不过，这也不是什么独创，Iceberg、Hudi 等都有类似解决方案。

概念上，有这样的层次关系：

Databricks 是一家商业公司，并且体量足够大，所以它需要寻找足够大的市场。实时计算的市场，相对于数据分析、BI 来说要小得多，所以，Databricks 选择 Delta Lake 是符合其商业定位的。

Delta Lake 虽然支持写操作，但是对于小事务支持得很不好，它更舒服的写入方式是批量写入。如果你使用很多小事务，则会生成大量碎片小文件，影响读效率。

当商业发展到一定规模，增长达到一定程度时，一方面能看到更多客户需求，另一方面要寻找新的增长点。Streaming 自然还是会落到 Databricks 视野之中。它的解决方案是：Lakebase。

所谓 Lakebase，实际是一个 PostgresSQL 独立进程，它能将写入 PostgresSQL 的数据，以 10 秒左右的延迟批量写成 Delta Lake 的格式。也就是说，在分析侧，可以获得延迟为 10 秒左右的实时分析能力。

Databricks 的时间线大致如下：