谈谈Databricks和云计算（二）

1. 前言
几天前写了一个帖子叫《谈谈Databricks和云计算》，写完之后发现自己混淆了一些概念，导致文章中有不少错误。我后来又看了很多技术资料以及文章，所以在这里重写一篇，希望可以总结一下我最新学习到的东西。

2. 名词缩写
这篇文章里会用到一些名词的缩写，因为很多名词没有公认的缩写，所以声明如下：

• DW - Data Warehouse
• DL - Data Lake
• LH - Data Lakehouse
  

3. Databricks是什么
我觉得我经过了这几天的学习，可以一句话总结Databricks：Databricks本质上给客户提供了一个大数据平台。Databricks现在在大力推广LH的概念，意思就是“我们这个平台的架构跟传统的DW和DL不一样，兼具了两者的优点”。但是我在这里不会过分纠结这三个概念之间的关系，我会逐个遍历Databricks的核心产品，从而更清楚地说清楚这个大数据平台是什么样的，而不是简单用LH这个大家都不懂的名词来解释。当我在遍历各个产品的时候，我会简单提到这三个概念，希望看完文章之后，大家能自然而然地对这三个概念有所了解。

现在我们已经定义了Databricks为一个大数据平台。然后我们讲讲客户使用大数据平台的两个根本目的（我这里讲的是目的，而不是用户的最常见的使用场景。最常见的使用场景应该是ETL，但是ETL最终是为了这两个根本目的服务的）：

• 分析过去：做数据分析（大多是用SQL之类的语言）来对业务作出指导
• 预测未来：做ML Modeling对未来作出预测
  

下面我会列举Databricks有哪些功能来帮助达成以上两个目的，然后说说Databricks的核心竞争力。


4. Databricks有哪些功能
4.1 Delta Lake
在讲所有其他产品（或功能）之前，我觉得第一个应该讲Delta Lake。Delta Lake是Databricks内部开发并且开源的一个数据存储层。我不了解它的细节，但是我们可以大概理解为它存储了数据的本身以及数据的metadata。Delta Lake里面的数据本身都是以Apache Parquet（一种开源的columnar storage格式）格式存储的。metadata的存在主要是为了实现ACID transaction以及对schema的支持。同时它还实现了write-ahead log从而可以支持数据的回滚。

本来数据可以以任何格式（比如Apache Parquet）存储在S3之类的object storage上面，Delta Lake只是在这上面包了一层，加入了metadata（以及其他我不懂的东西），从而支持了ACID transaction以及schema（以及各种其他特性）。而ACID transaction和schema对SQL workload是很必要的。

4.2 Databricks SQL（简称DB SQL）
DB SQL就是Databricks的SQL query engine。上面已经提到了存储层，这里的DB SQL就相当于是计算层。DB SQL支持了客户用SQL query对以Delta Lake格式存储在S3（或其他object storage）上面的数据进行操作。DB SQL的技术细节我不懂，但是它基本是由Spark支持的（似乎是把用户的SQL query解析成一个Spark execution plan）。在这里我必须提一下Photon：Photon是Databricks开发的一个execution engine。前面提到SQL query会被解析成Spark execution plan，而execution framework会执行这个plan，然后把任务分发到集群里的计算机上进行运算，而每个任务具体怎么计算是需要一个execution engine的。Photon就是Databricks开发出来优化最底层的Spark计算任务的速度的。而且去年DB SQL刚打破了TPS-DS的世界纪录。

4.3 Databricks Runtime（简称DBR）
有了DB SQL之后我们需要机器来运行这个产品，而DBR就是给客户提供这样的机器的（当然，DBR可以运行除了DB SQL以外的其他的Spark的workload，它支持用Scala、Python、SQL以及R来运行Spark指令）。如果客户不用Databricks而是自己运行Spark的话，需要自己开一个EC2的机器（假设用AWS），然后安装Spark，然后运行（中间可能还需要性能调优）。而DBR就是帮客户方便地创建机器：客户只需要在Databricks里选几个选项然后点一下鼠标，就可以有一个安装好了Spark、性能也调优过的Spark cluster可以使用了。

4.4 Notebook
Notebook就是用户跟DBR（以及各种其他runtime，比如ML runtime）交互的媒介。而且这个Notebook跟Jupyter很像，所以相信玩过数据分析的人应该都不会陌生。用户可以在Databricks Notebook里面连接到一个自己有权限的cluster（一个cluster就是一个运行着DBR的集群），然后在Notebook里面用Scala、Python、SQL以及R来运行Spark指令，对存在S3上面的Delta Lake格式的数据进行操作（当然，Spark也支持对各种其他的数据格式进行操作）。如果客户在Notebook里面用SQL，那么就是使用了DB SQL这个产品。如果某个DB SQL的query可以由Photon来完成最后底层的任务的执行（目前Photon对Spark的支持还不完全），则会自动切换到Photon获取更好的性能。

看到这里，Databricks的DW的拼图基本上我已经讲完了，因为DW的主要特点就是支持SQL的应用场景，而且DW的最主要的两个组成部分就是存储层和计算层。当然，DW还需要fine-grained access control，我后面会提到Databricks用了什么产品（Unity Catalog）来达成这个目的。这里我要着重提出的是，其他的DW产品（比如最优秀的DW：Snowflake）有自己的存储层和计算层，Databricks这里也有，但是他们还是有些区别：

• Databricks的存储层（Delta Lake）支持更flexible的schema，对semi-structured data支持更好：比如某个column可以是list里面套list，而Snowflak不支持这样的花里胡哨的column。（对semi-structured data的支持对ML workload帮助很大。）而存储层支持越flexible的schema，在此之上的query engine就越难优化。
• Delta Lake开源。一般的DW的存储层都是自研（非开源）的，这样的好处是方便优化query engine，坏处就是用户不可能用DW里面的数据做ML：用户只能用DW自己提供的对应的query engine去做查询，但是如果用户想用ETL工具（比如Spark）把DW里的数据转换成适合ML的格式，这对于大多数DW是不可能的。存储层不开源，ETL工具连它的数据格式都不认识，也就没法在DW的基础上做任何ML了。这也就是为什么DW对ML支持得不好：它很难成为ML的数据源。开源的存储层天然就对ML支持很好，但是开源的存储层（Delta Lake）使得优化query engine的难度更大。
• Databricks的计算层（DB SQL）是基于开源的Spark的。这个其实带来了一个劣势，因为Spark的启动时间太长了，从用户提交SQL query到真正开始执行用户的query，这中间实际是在做各种Spark的准备工作，因此DB SQL对小的query的性能是不如其他的主流DW的（比如，如果query只需要几分钟来运行的话，query准备时间跟query的运行时间可能一样长），但是对于大的query，Databricks做了各种优化（包括做Photon）使得DB SQL打破了TPC-DS的世界纪录（性能超过所有DW竞争产品）。
  

因此Databricks在自己的存储层schema更flexible以及开源的情况下，依然能做各种优化使得自己的计算层（DB SQL）打破TPC-DS的世界纪录，我觉得这展示出了Databricks里面那几个核心组的技术能力。关于这个世界纪录，我觉得要理性看待：

• 首先如果是data scientist做interactive SQL query（就是在Notebook里面输入query然后现场等待结果），那么性能提升50%也不过就是让他们的等待时间缩短一半，依然需要等几分钟，可能用处没那么大。（后面我们会提到Databricks如何用Serverless优化这个等待时间）
• 但是SQL workload除了interactive的，其实大多数都是以scheduled job的形式存在的，而且这些workload一般都是比较大的query。对于这种客户来说，DB SQL的性能提升对于他们来说就是实打实地省钱。对于每年在这种workload上花几十万的客户来讲，性能对于他们来说还是很重要的。
  

4.5 Workflow和Jobs

这两个都是Databricks的ETL产品。对于大多数公司来说，绝大多数ETL的pipeline都不是一次性的，一般都是隔一段时间（比如24h）跑一次把最新的数据处理一下，有时候发现错误了可能会一次性把过去一段时间的数据重新处理一下（这个一般叫backfill）。用户在Databricks里面定义一个Job之后，一般会设置定时触发，然后Job系统就会在指定时间启动一个用户设置好的Spark cluster（DBR），运行这个Job的ETL逻辑，然后关闭Spark cluster。所以用户只对Job运行期间产生的花销付费，这时候Spark cluster的性能就非常重要（所以Photon是实打实地为用户省钱）。Workflow就是Databricks提供的Job orchestration产品：用户可以用Workflow把不同的Job串起来实现复杂的ETL逻辑。值得一提的是Databricks的Jobs和Notebook集成得很好：如果一个用户在Notebook里面实验性地写了一些ETL代码，然后想productionize这个Notebook，只需要点击一下“Schedule”按钮，即可以生成一个Job，然后用户输入一些关于Job的参数（比如需要什么样的cluster，在什么时间触发Job等）就可以自动地周期性地跑这个Notebook里面的ETL代码。

4.6 Delta Live Table（简称DLT）
DLT实际上就是Workflow，只不过它相当于提供了一个“语法糖”。在实际的场景里，客户的table都是一个串一个的，每个table的上游和下游可能都有好几个其他table。DLT就支持用户用declarative的方式声明table之间的依赖关系然后自动帮用户做ETL。比如用户可以create table A，然后create delta live table B as select * from A（这里不止可以select *，也可以做各种数据转换），然后create delta live table C as select * from B（这里也可以做各种数据转换），DLT就可以自动生成table之间的依赖关系图，同时如果table A的数据有更新，会自动触发ETL的job去更新相应的下游table（这里就是会自动更新B和C）。

. 1point3acres4.7 Serverless SQL Endpoint
上面我提到DBR之后，说到了用户可以点击一下鼠标一键启动一个装好了DBR的Spark cluster，这个cluster实际上是在用户的云账户里面的（以AWS举例，用户在Databricks里启动cluster之后，需要给AWS付EC2 instance的费用，同时需要给Databricks额外付cluster的markup费用）。在用户的账户里启动cluster的缺点就是慢：一般需要等3-5分钟。就算cluster启动完成，用户每次提交一个Spark命令（普通的Spark命令或者DB SQL命令）之后，从命令提交到命令真正开始执行大概有一分钟的时间（Spark需要这个时间对每个job做准备，这就是为什么Spark对于小的query不具有优势）。很多时候用户隔一个小时跑一个小的SQL query，就意味着隔一个小时就要等这几分钟的启动时间（如果不愿意等也可以让cluster一直不关机，但是这样太浪费钱）。因此Databricks推出了这个Serverless SQL Endpoint（cluster是启动在Databricks的账户里的）来帮用户节省时间。有的人可能会说“这不就是Databricks维护一个warm pool嘛”，但其实Databricks做的远不止这些。如果只是维护一个装有Spark的warm pool，用户从提交一个job到这个job真正开始跑还是有至少一分钟（因为Spark的准备时间）。Databricks里面的Spark专家们还正在尝试优化这个“Spark的对于每个job的准备时间”，有希望做到把“从用户提交命令到命令开始执行的时间”压缩到几十秒。在没有这个Serverless SQL Endpoint的情况下，用户“冷启动一个cluster然后提交命令”到“命令开始执行”需要大于4分钟，但是现在的Serverless SQL Endpoint已经把这个时间优化到了一两分钟。以后这个时间有希望被优化到更短（比如半分钟以内）。更不用说这个东西还更省钱了。

4.8 Unity Catalog（简称UC）
UC提供了data governance（权限管理）和data lineage（数据溯源）的功能。data governance实际上是传统DW都支持的功能，但是data lineage就是一般的DW没有的功能。关于data governance，UC支持用户用树状图（想象一下在mac上查看文件夹结构）查看各种Delta table（或者不是table的各种花里胡哨格式的数据）的权限以及管理它们的权限。关于data lineage，UC支持用户查看每一个Delta table的上下游都有哪些其他table，甚至查看每个column的上下游都有哪些table的哪些column。

4.9 MLflow
说了这么多SQL Analytics和ETL，终于来到了大数据平台的另一个最常见的使用场景：ML。MLflow是几年前Databricks的团队开源的一个项目，目的是帮data scientist和ML engineer管理ML model。如果客户自己下载MLflow并安装，则可能需要自己维护一个数据库作为MLflow的后端（因为model的metadata是存在数据库里的）。对于Databricks的客户来说，他们可以直接使用Databricks里面的MLflow（即managed MLflow），其后端就是Databricks管理的数据库。下面我们从ML的几个常见场景出发讲一下Databricks的ML相关产品。

Training data generation：这个其实跟ML关系不大，本质上用户还是用ETL来做这个。
Feature Store：Databricks提供Feature Store产品，让用户可以注册、维护feature。实际上feature store的背后就是Delta table。Unity Catalog的存在可以让用户很方便地对每个feature进行溯源：每个feature来自于哪些上游table的哪些column都很清晰。
Model training：用户可以启动ML runtime（一个装好了常见的ML库的cluster，相当于ML版本的DBR）来做model training的工作，而model training的代码可以直接在Notebook里面编写。每一个model training完成之后，用户可以在Notebook里面用一行Python代码把这个run log到MLflow里面（MLflow的run的意思就是记录一个model用了哪些超参数，feature以及模型结构，然后达到了什么样的AUC以及loss等）。MLflow的界面方便用户对不同的run比较AUC以及loss（或者其他指标），用户可以挑出最喜欢的model去register成为一个MLflow model。
AutoML：Databricks提供的自动帮用户调超参数的产品。
Model serving：上面提到用户可以把一个model register成为MLflow的model。对于MLflow的model，Databricks支持用户在MLflow界面“一键部署”。用户只需要点击一个按钮，就可以将这个model部署在Databricks的环境里面，然后拿到一个URL，用户可以拿着自己的Databricks credential对这个URL发post命令来进行model inference。当前Databricks还只支持简单的model serving：QPS限制在200，没有SLA。ML Platform组已经在做production-grade model serving：QPS限制会大幅提高，同时也会像三大云平台那样，提供一个SLA。

4.10 其他产品
还有一些其他产品我没有提到。如果有特别重要的产品被我漏掉的，欢迎大家补充。

5. Databricks的核心竞争力
以上粗略介绍了Databricks的几乎所有产品，我觉得Databricks的核心竞争力就是“一个平台提供所有的这些功能，而且不同功能之间的衔接很好”。这也是Databricks宣传的LH的意义：如果客户只需要SQL Analytics，那么DW就足够；如果客户只需要ML，那么一个DL也够了。如果客户两个都需要，那么Databricks的LH就是最适合这种需求的一个系统架构。我们要注意，LH不是什么新的技术，只是一个新的系统设计理念，它的核心是使用开源的数据存储格式，使得这些数据天生就适合ML，然后在此基础上再实现DW所具有的特性（比如ACID transaction，schema，query engine，data governance），来支持SQL Analytics。希望在读完这篇文章之后，大家对“LH只是一个新的系统设计理念”这句话能有自己的认识。

下面说回Databricks的核心竞争力。以上的所有我提到的Databricks的功能，市场上都可以找到不止一个竞品，但是市场上没有第二个平台可以包含Databricks提供的所有功能。对于只需要SQL Analytics的用户，DW就可以满足需求，Snowflake对于他们可能是最好的选择。对于只需要ML的用户，市场上还有Dataiku、DataRobot、Datadog这种managed ML platform来对标Databricks的【MLflow + Notebook + DBR】。但是对于二者都需要的用户，他们可以选择同时使用Snowflake这样的DW加Dataiku这样的ML platform（需要维护两套系统，数据也需要在两个系统之间移动），也可以选择只用Databricks。对于那些选择在某个云平台（比如AWS）上面搭建自己的LH的用户，则他们会需要把更多（不止两套）的产品拼起来完成Databricks具有的功能。一般“把不同产品集成起来”需要花Data engineer团队大量的时间（后续还需要继续花时间维护），并且拼起来的不同产品不会有“产品之间无缝衔接”的体验。Databricks就帮这类客户解决了这个问题：这些产品天然在Databricks里面互相集成，不需要工程师花时间集成以及维护，同时Databricks的不同产品之间衔接的体验很好（比如一个ML engineer可以在同一个Databricks的Notebook里面用SQL完成数据分析、用Spark完成training data generation、用Python完成model training以及注册到MLflow，然后切换到MLflow里面一键enable model serving）。Databricks的另一个小的核心竞争力就是ETL的性能和大的SQL query的性能。Databricks的核心团队在不断优化Spark，对于那些用Spark做ETL的客户，如果他们切换到Databricks，不但不需要维护自己的Spark cluster，而且还可以实打实地省钱。所以综上来说，对于特定的客户来说，用Databricks可以省去他们的工程师团队管理以及集成不同系统的时间，同时也可以在某些workload（比如ETL）上面省钱。

最后说一下“三大云平台随便发力就可以复制出一个Databricks”这种论调：每次我看到有人说这个，我只能说这种人对“软件工程”毫无了解。我不反驳这种论调，但是我反问这些人一个问题：Snowflake的DW比Databricks的LH架构可是简单多了，而且事实上三大云平台都有自己的DW，那么为什么Snowflake还发展这么好？三大云平台已经在DW上发过力了都没干掉Snowflake，他们如何“随便发力”干掉Databricks？


. .и

评论区那些从文化或者技术上说Databricks这个公司不行的人，我觉得都没问题，但是你们要言之有物啊。什么干货都没有只是说一句“culture奇差的一家公司”或者“你说的这些aws， azure都有，甚至更好”，我都没法接你们的话。

当然Databricks是有各种问题的，但是不管你说一个东西好还是不好，都得拿出点干货吧？

zzz6222 发表于 2022-2-24 15:21
“semi-structured data的支持对ML workload帮助很大”
ML的workload为什么需要这种JSON一样的文件， ML也 ...

你说的图像和视频都属于non-structured data。

semi-structured data就是花里胡哨格式的：比如list里面套struct里面再套list。

想象一下这样一个user table：
user_id: int
user_purchased_items: list of UserPurchasedItems

然后UserPurchasedItems是这种格式：
item_id: int
item_category: list of int
price: double

所以某条数据可能长这样：
user_id: 123
user_purchased_items:
  {item_id: 111, item_category: 222, price: 0.5}
  {item_id: 112, item_category: 223, price: 0.6}
  {item_id: 113, item_category: 224, price: 0.7}

然后对这个user table进行建模。如果放在DW里面，“user_purchased_items”这个list只能被扔到某个column里面，里面的item_id和item_category都不能放进schema里面，所以丢失了一些信息。如果用Delta Lake格式（或者Iceberg等其他类似的格式）存储，可以支持在schema里面对这个list里面套struct的数据类型进行建模。最厉害的就是：用Delta Lake格式存储这个数据以后，你可以直接用SQL query这个table，问“多少用户买的东西加起来超过5块钱”这种问题。而DW直接丢失了list里面的item_id，item_category，以及price的信息，所以也不可能支持这样的query。如果你做过ML就知道，这样的table是非常常见的。

cynthiazhxu 发表于 2022-2-24 10:34
听LZ的介绍Delta Live Table跟PostgreSQL，SQL Server的materialized view好像是同一个东西。为什么要取一 ...

我的理解是这样的（说得不对请指正）：
materialized view是专属于Database的概念，但是我们这里说的Delta Table跟Database没什么关系。Delta Table虽然也是table，但是它是用来在S3上面存储大数据的，虽然它也有ACID transaction和schema的支持，但是它跟传统数据库还是区别很大的（就是OLTP跟OLAP的区别）。

因此你可以说“materialized view”之于Database就是Delta Live Table之于Delta Table（虽然这样类比可能也不严谨）。因此我觉得纠结于这些概念没有用，我们只需要知道Delta Live Table可以帮你省去一些手动做ETL的工夫就行了。

zzz6222 发表于 2022-2-24 16:41
你给的例子，我觉得如果要用table存也可以。难点就是需要做schema design，一个用户多个购买记录，normal ...

DW里面是很少做normalize的，因为这里的数据真的很大，而且在上面跑SQL的时候往往要扫过大量的row（比如Data Scientist需要知道昨天有多少用户给我们系统付费了），所以不同table之间join特别贵。

你说的在Database里面做normalize是另外一个故事：那个一般是针对online使用场景的Database。Online的SQL query的特点是很少需要扫过大量的row，一般都是针对某个用户进行单个row的查询或者插入，而且Database的存储比DW的存储要贵多了。为了解决这些问题我们会在Database里面谈论normalize这个话题。
另外在DW里面一般也不用foreign key的（我甚至不知道主流DW是否支持foreign key）

cynthiazhxu 发表于 2022-2-25 02:34
听LZ的介绍Delta Live Table跟PostgreSQL，SQL Server的materialized view好像是同一个东西。为什么要取一 ...

Databricks这个公司喜欢发明一些看起来特别新的名词。我之前看这个公司发布的一些新东西，怀着好奇心了解了一下，发现只是换个名词而已。

并非贬义，仅仅是陈述客观情况。

culture奇差的一家公司. 技术再牛逼进去也是遭罪

写的太好了！！！

赞z s z s

仿佛回到了当年在人人都是产品经理上挖到绝世好文的日子。先马后看～

楼主，请问可以加下微信吗？暑假去databricks实习，想了解下 databricks 的各个组怎么样

Mark一下， 谢谢楼主！

你说的这些aws， azure都有，甚至更好。而且他们还有一堆其他的cloud services助阵。好比一个人仅会拈花指，而他的竞争对手七十二绝技全会，孰牛逼，一目了然。

听LZ的介绍Delta Live Table跟PostgreSQL，SQL Server的materialized view好像是同一个东西。为什么要取一个新名字而不直接用materialized view这个已经存在名词？还是说不是同一个东西？