谈谈Databricks和云计算

1. 前言
写文章之前先跟大家透露一下我的个人背景：我毕业之后在某大厂工作了4年，然后半年前跳槽进入了Databricks。这篇文章我主要想讲讲入职半年以来我个人的对Databricks这个产品累积的一些看法，同时也想聊聊云计算这个行业的Data这个细分方向（主要是Cloud Data Warehouse以及Databricks主推的Lakehouse）。

由于我是Databricks的员工，我的看法肯定是很主观的，所以请大家选择性对待。同时，这篇文章我不会注重讲在Databricks工作是什么感受，而是要着重讲我个人眼中这是一个什么样的产品，以及我为什么看好Databricks以及Lakehouse的未来。


2. 我为什么加入Databricks
说来搞笑，我当时跳槽的时候最后选择加入Databricks，一个是因为我从各种途径听说这个公司business model靠谱，工程师质量贼高（因为招人标准真的高），然后各种云计算领域的公司的IPO让我觉得这个领域很热，加入Databricks说不定可以蹭一波IPO同时小赚一笔。因此在选择加入Databricks的时候，我一直都对这个产品基本毫无了解。直到加入之后我才抓住各种机会疯狂补课，不断了解Databricks到底是一个什么产品。除此之外我也很努力地了解各种竞争对手的产品，试图搞清楚云计算的Data方向到底有哪些大玩家，其中有哪些细分领域，里面有哪些小玩家，他们之间的产品是如何的关系。最近我觉得我逐渐对于Databricks这个产品以及这个行业方向有了自己的一些理解，因此在这里记录下来，一来练习我写作的能力，二来希望可以引发一些讨论，让我也能学习一些新知识。

因此，写这篇文章的人只是一个在云计算行业有半年经验的从业者，如果有太武断的观点或者明显有悖于事实的地方，希望大家指出，互相交流才能共同进步。


3. 从Data Warehouse讲起
如果想系统性地了解Databricks，故事就必须从Data Warehouse讲起（虽然Databricks现在不是做Data Warehouse的公司）。我不会花太多时间讲Data Warehouse的起源和历史，因为我懒得去查资料了，而且大多数人其实是很熟悉这个的，因为在工业界工作的人很难没接触过Data Warehouse。
如果让我用简单几句话说清楚什么是Data Warehouse：一般运行在集群上，是一个存储结构性数据的地方，数据的来源可能很多样，但是基本都是通过offline的ETL pipeline通过batch的方式插入。数据存在里面的主要目的是让数据分析人员（Data Scientist，Business Analyst等）能够在上面跑SQL query，然后生成报告，从而对业务决策作出帮助。

为了方便大家理解，这里我举一个我编造的例子：想象一下你在一个电商公司，你们某个在线server要对用户的每一个行为（点击、购买等）产生一个log，然后你们的DS需要对用户行为数据进行分析，这时候就需要Data Warehouse团队新建一个User Activity Table，然后把online server的每一个log扔给message queue，再用一个offline pipeline把message queue里面的数据进行清洗后插入到Data Warehouse里面的table。（Data Warehouse是典型的供offline使用的工具，因此message queue在这里主要是decouple了online server和offline table，缺点是会造成数据的delay，一般情况下，数据分析人员每天都只能在Data Warehouse里面看到昨天之前的数据。）

下面总结一下Data Warehouse的特点。在此之前希望大家明白，Data Warehouse本质还是一个distributed database。因此Data Warehouse的一些特点本质上就是数据库的特点。

• 只能存储结构性数据：一定要把数据组织成table，然后对每个table定义一个schema。
• 支持SQL：Data Warehouse解决的根本问题就是Data Analytics，而SQL就是数据分析最流行的语言。同时我们要注意，“支持SQL”和“结构性数据”是密不可分的，正是因为数据有了schema，才容易在table上面实现一个SQL query engine，从而支持对大量数据的快速查询。
• 支持ACID和transactions：这个特性来自数据库
• 良好的对数据权限管理的支持（X用户对Y table有read权限，对Z table有write权限等）：这个特性来自数据库
• 存储和计算强耦合：传统的Data Warehouse都是运行在集群上面的，一般一个集群由很多便宜的普通电脑组成，这些电脑的硬盘构成了Data Warehouse的存储系统，而这些电脑的compute resource用来给query engine提供算力。这种特点使得人们不容易专门针对存储或者运算加机器或者减机器（举个例子，当我没有query在运行的时候，我不希望有很多CPU在那里空转）。但其实这个缺点已经在近几年得到改善了，比如Snowflake的Data Warehouse就已经做到了存算分离，使得用户可以根据需求来增加或者减少compute resource，从而节省成本。
  

最后，提到Data Warehouse就不得不提最近大火的Snowflake。Data Warehouse已经火了这么多年了，Snowflake的厉害之处就是提供“Managed Cloud Data Warehouse”，这里的“Cloud”是区别于传统的Data Warehouse运行方式：把Data Warehouse放在云上，而不是部署在自己管理的集群上，这样省去了硬件的成本，这个就是所谓的“上云”。但是仅仅是“上云”还没有省钱到极致，因为即使在云上部署以及维护Data Warehouse集群，也需要一个有经验的工程师团队，这时候Snowflake提供的“Managed Data Warehouse”就帮中小公司省去了部署以及维护的成本，因此它广受中小公司的喜爱是很合理的。（这里肯定很多人要问了，既然Managed Cloud Data Warehouse那么赚钱，那么为什么三大云厂商自己提供的Data Warehouse比Snowflake的市场份额差那么多？其实我不了解其中的细节，所以有兴趣的人可以自己去查查资料。我道听途说的一些理由有：1）Snowflake的用户界面做得特别好，客户的onboarding experience尤其好。2）Snowflake的存算分离做得好，可以帮客户省钱。3）Snowflake有助于防止vendor lock-in，因为它支持你部署在各个主流云平台，从而不用担心自己的数据只存在某一个云平台上。4）Snowflake的query engine性能也不错。）


4. Databricks以及Data Lakehouse
说完了Data Warehouse，让我们回到本文的主题：Databricks以及Data Lakehouse。


4.1 Databricks的诞生
2013年，Databricks由伯克利AMP实验室的Spark创始团队建立。当时他们成立公司的初衷是将Spark商业化，因为当时Spark正在慢慢替代Hadoop在大数据ETL领域的垄断地位，渐渐成为数据ETL的行业标准。但是“如何商业化Spark”有两种方向：

• 主攻on-premis市场，即把优化过的Spark打包成一个安装包卖给客户，让客户去在自己的集群中安装以及使用。
• 主攻cloud市场，即让Spark运行在云上，主要服务已经上云的客户。
  

要知道，当时不像现在这样，中小企业都在想着上云，当时几个主攻on-premise市场的公司都赚得盆满钵满。但是Databricks内部支持走cloud路线的创始人（以Matei为主）最终说服了另外的人，因为他们精准判断出：对于大多数客户来说，未来上云是很自然的事情，因为可以省去硬件成本，上云之后，使用SaaS而不是自己维护各种服务或集群也是很自然的事情，因为对于多数客户来说，他们总是希望自己不要花时间维护跟核心业务无关的东西，能用“managed XXX服务”就不要自己在cloud上部署“XXX服务”。这个观点在过去几年不断得到印证，而且现在还在持续。


4.2 从Data Lake开始
其实在Databricks诞生的开始几年里，整个公司是朝着Data Lake的方向发展的，而Data Lake就是为了解决Data Warehouse的痛点而提出的一个架构。主要解决的是在Machine Learning应用场景下Data Warehouse完全不适合的情况。Data Lake的特点基本就是对Data Warehouse取反，比如：

• 数据不需要有强的schema（对semi-strucutred和non-structured数据支持比较好），本质上数据就是以某种简单格式（比如Apache Parquet）存在S3之类的blob store上，而不是像Data Warehouse那样以表的形式存在数据库里。这样很显然会导致一些问题，比如数据的质量无法保证：在Data Warehouse里面，我们可以利用数据库的特性对某些数据做出限制，从而保证数据的质量（比如user id不能为空，钱包余额必须为正等等），但是在Data Lake里面不容易对数据做出这种限制。
• 成本（相对于Data Warehouse）低：因为数据本质上存放在最便宜的blob store（比如S3）
• 读取数据的方式比较随意：对于Data Warehouse来说，你部署了哪家的产品，基本你就只能用哪家的query engine来读数据，而Data Lake架构下的数据只是简单存放在blob store上，因此你可以随意用各种大数据工具读取（比如Spark等）。
• 权限管理比较随意：因为数据本质上存在blob store，那么权限管理依靠的还是文件系统的权限，而做不到像Data Warehouse那样利用数据库的成熟的且细致的权限管理系统。
• 存算分离：Data Lake的架构是天然存算分离的，因为本质上还是一堆存在blob store的数据，因此比Data Warehouse天然地更容易通过增加或者减少存储来应对数据的增加或减少。
  

下面我们回到刚才提到的“电商公司”的例子，看看Data Lake是如何解决Data Warehouse的痛点的。刚才我们已经说过，为了让Data Scientist能够分析用户数据，我们用了一个message queue，同时在Data Warehouse里面新建了一张表，来存储用户行为信息。这时候假设我们要做一个ML Model来预测用户购买一个产品的概率。这明显是一个binary classification的model，每一条训练数据都会包含用户和商品的信息，如果最后的结果是“用户完成了购买”，label就是1，反之label就是0。那么每一个训练数据点就会包含以下feature：

• user id
• user info (age, gender, geo-location, purchase-history etc.)
• item id
• item info (item category etc.)
• user x item info (has this user seen this item before but didn't buy? etc.)
  

在实际情况下，一般我们会在message queue后面新增一个ETL pipeline，将数据清洗成这个格式放在S3上面，然后给ML Model Training系统作为输入。假设我们的情况更复杂：我们有不同的ML组，需要对不同的用户的行为数据进行ML Modeling，于是我们一般会有一个ETL pipeline负责生成user activity data存放在S3，有另一个pipeline负责生成item data存放在S3，然后不同的ML组会根据自己的业务需求自己管理自己的特定的ETL pipeline，对user activity data和item data进行join，来生成自己想要的model training data。这中间的存放在S3上面的数据，加上各种ETL pipeline，本质上构成了一个Data Lake。

现在我们已经看到，由于Data Scientist需要对数据进行分析，我们在Data Warehouse里面有user activity table（可能还有item table），供他们用SQL进行查询。同时由于ML组需要做model，我们在S3上面有一些raw data（比如最初的user data和item data）以及每个组自己的training data（join了之后生成的user-item data）。由于Analytics和ML两种workload的需求，我们不得不维护两套系统（一套Data Warehouse用来应对SQL workloads，一套Data Lake，主要由各种ETL pipeline构成，用来应对ML workloads），同时存储一些冗余的数据（Data Warehouse里面的user activity table肯定跟Data Lake里面最初的那个user activity data文件包含很多冗余信息）。

4.3 从Data Lake到Data Lakehouse
Databricks在发展的过程中，通过不断听取客户的反馈，在自己的Data Lake上面加各种功能来解决痛点。到后来各种功能做成以后，所谓的“Data Lake”已经大变了样，这时候再称呼它是“Data Lake”已经不合理了。于是在20年初，Databricks第一次提出了“Data Lakehouse”的概念，用来总结自己当前的产品特点：融合了Data Warehouse和Data Lake的优点，让用户不用维护两套系统即可以同时很好地支持Analytics和ML的workloads。下面我们先说说Data Lakehouse的特点，再回到刚才的“电商公司”的例子，看看我们如何能利用Lakehouse优化我们的架构。

Databricks的Data Lakehouse的特点：

• 数据不需要有强的schema，只是单纯存在blob store上（借鉴自Data Lake的优点）：Databricks的Lakehouse的基础数据结构是Delta Lake Format（跟Apache Parquet很像），本质上是用树状结构来描述所有数据。要注意的是，如果仅仅是用了Delta Lake Format来存储数据，跟Data Lake没什么区别（你在Data Lake里面也可以用Delta Lake Format存数据），Databricks的Lakehouse的优势在于在此基础上实现的其他东西，请继续往下看。
• 支持各种随意的方式读取数据（比如Spark等），这个跟Data Lake是一样的
• 支持SQL（借鉴自Data Warehouse的优点）：Databricks自己实现了针对Delta Lake格式的SQL query engine：Photon，从而实现了让客户对于blob store上的数据也能用SQL进行读取。这是Databricks工程师花费了巨大心血的地方，也是Data Lakehouse最大难点之一，因为传统的SQL query engine都运行在Data Warehouse里面，他们应对的都是带强schema的数据。而Databricks的Photon主要应对的是Delta Lake Format这种schema比较弱的数据格式，因此需要大量的优化才能赶上Data Warehouse的SQL性能。
• 存算分离（借鉴自Data Lake的优点）：对于Lakehouse来说，存算分离也是天然的
• 支持ACID和transactions（借鉴自Data Warehouse的优点）：在传统数据库中，这些特性是由write-ahead log实现的，因此Databricks实现了针对Delta Lake Format的write-ahead log，从而支持了ACID和transactions。
• data lineage（借鉴自Data Warehouse的优点）：write-ahead log的实现也自动解锁了这一功能。大数据的一个关键就是能够很好地track数据，比如每一张表的历史是什么样的。在Databricks里面，每张表（这里的“表”是Lakehouse中的表，有别于Data Warehouse的表）都有time travel功能，可以rollback到若干次操作之前的snapshot。
• 良好的对数据权限管理的支持（data governance和access control）：Data Lake一个很大的缺点就是不能像Data Warehouse那样实现fine-grained access control，于是Databricks做了Unity Catelog，使得用户也可以像在使用数据库那样来管理Data Lakehouse里面每张表的读写权限。
  

总结下来，我们就可以看出，Databricks是这样构建大数据平台的：Data Lake天然适合ML场景，但是缺乏Data Warehouse的各种良好特性（支持SQL、ACID、data lineage、fine-grained access control等），于是Databricks使用first principle思考了这些问题，即回到本质上对这些问题进行思考和解决。传统数据库有良好特性，但是那不是本质，本质是传统数据库利用了一些技术来解锁那些特性：比如data lineage的本质是write-ahead log，于是Databricks就实现write-ahead log，而不是思考如何把整个数据库搬进Data Lake。再比如传统数据库支持SQL，但是它的本质是一个query engine，于是Databricks就花大量精力做了Photon。

下面我们回到刚才“电商公司”的例子，看看如何用Databricks简化他们的架构，并且不失去任何功能。刚才说到我们有一些Data Scientist需要用SQL query来进行数据分析，又有ML团队需要弱结构的数据（在blob store）上进行模型训练。在Databricks里面，我们只需要维护一个user activity table，这个table可以包含所有的user activity数据。Data Scientist可以直接对这个table进行SQL query来分析数据，ML团队可以直接用ETL pipeline来抽取数据，进行清洗，生成新的table来供机器学习使用。要注意，这里的“table”本质上是以Delta Lake Format存在blob store（比如S3）上面的数据。因此我们可以看到，如果使用了Databricks的lakehouse架构，我们不再需要维护Data Lake和Warehouse两个系统，也不需要在两边存储冗余的数据。由于Databricks提供的unity catelog以及write-ahead log可以让我们对这些“table”也方便进行细致的权限管理以及data lineage，我们相当于把数据存在了便宜的地方（blob store），但是依然拥有了Data Warehouse才能提供的一些特性。




4.4 Databricks SQL的性能真的好吗？
说到这里，很多人应该有一个疑问：你把Databricks吹得神乎其神，难道你对弱结构的数据实现一个SQL query engine（Photon），就能吊打传统的Data Warehouse的SQL query engine？毕竟传统的Data Warehouse存算耦合很紧，天然就更适合对query engine进行优化，再加上这么多年的发展，他们的SQL query engine的性能能被你做了几年的东西赶超？

说实话这个疑问我也有，但是当我看到这篇文章的时候我震惊了：Databricks Sets Official Data Warehousing Performance Record。这篇文章主要就是讲Databricks SQL在TPC-DS这个纯Data Warehouse workload的benchmark上，性能超过了所有竞争对手（包括Snowflake）。要知道Databricks不是一个Data Warehouse平台，他们优化SQL query engine的难度远大于在Data Warehouse里面优化SQL query engine，但是他们能在Data Warehouse的workload上干掉所有竞争对手（性能更高，价格更低）。当一个不是Data Warehouse的平台在SQL的性能上击败了其他的Data Warehouse，这个结果应该可以让所有人信服Databricks的技术水平。

4.5 为什么我看好Databricks以及Lakehouse的未来
说到这里，我们说了Data Lakehous是如何同时很好地支持SQL Analytics以及ML应用场景的。不排除有的客户说“我们永远不做ML，所以我们只要用Data Warehouse就够了”，但是未来这样的客户会越来越少，未来的趋势是大多数需要存数据的公司都或多或少会有ML的应用场景。而对于大多数需要兼顾SQL以及ML的公司，Data Lakehouse是比Data Warehouse或者Data Lake合理得多的架构。在所有提供Data Lakehouse平台服务的公司中，Databricks是当仁不让的王者，毕竟Data Lakehouse就是Databricks提出的。对于现在需要从零开始搭建Lakehouse数据平台的公司来说，要么自己做一个in-house版本的，自己部署以及维护，要么就选择Databricks，省去维护成本。如果你想选一个Managed Data Warehouse的方案，可能你还有多种选择（其中Snowflake是大多数人的选择），但是如果你想选一个Managed Data Lakehouse的方案，除了Databricks你别无选择。


4.6 开源大部分的技术
本来写到这里，这个章节就应该结束了。但是我真的很想提一下Databricks这个公司一个鲜明的特点：开源。在整个公司创立的时候，主要的工作就是基于开源的Spark的。开源的好处是可以快速积累用户，扩大社区，从而扩大影响力。坏处也显而易见：用户如果愿意花时间，完全可以直接去Github下载代码或者安装包自己安装并且运行你的产品。事实上，在15年的时候，Databricks处在非常困难的时期，因为当时AWS在Spark上赚的钱比Databricks要多几个数量级——Databricks作为开源Spark的主要贡献者和维护者，却只能在Spark上面赚到一丁点钱，因为用户大多直接选择在AWS上运行开源的Spark。即使这样Databricks也没有在开源的方向上妥协：后面的Delta Lake（Lakehouse的存储层）以及MLflow（ML Model & Experiment Management工具），Databricks都是采取了坚持开源，积累用户的做法。对于一个主要是“做工具”的公司（比如早期的Databricks就是做Spark这个工具），开源其实是很危险的，因为用户可以轻松把工具拿去自己部署一份。而对于一个做平台的公司（现在的Databricks就是一个不折不扣的大数据平台），即使你的大多数技术都是开源的，很多用户也不会想自己去部署以及维护那么多东西，而是会想着来用你的managed的版本，只要你这个平台里有用户需要的所有功能。这也是为什么Databricks现在是一个“全家桶”式的大数据平台。写到这里我专门去看了一下Databricks的SQL query engine（Photon）是否开源，答案是不开源，虽然我不懂为什么，不过想想觉得也合理，毕竟Photon是Databricks的工程师花多年打造的产品，是公司的核心竞争力所在。


5. 加入Databricks

. .и
写了这么多，现在是广告时间：刚才说了Databricks的Lakehouse架构多么多么好，提供的功能多么多么厉害，但实际上，现在整个公司依然处在起步阶段，因为每个功能都还是需要很多打磨来提升用户体验（比如我听说有个客户把所有的ML的workload都迁移到了Databricks，然是依然选择用Snowflake做Analytics，原因就是他们觉得Databricks的access control特别难用，不如传统Data Warehouse体验好。因此“在Lakehouse实现好用的access control”听起来很轻松，但是想把这件事做好，做到让客户愿意抛弃Data Warehouse，真的需要大量打磨）。除此之外很多组都有很多新功能要做：举个小例子，比如最近的Serverless SQL Endpoint就是个很厉害的新功能。Databricks的愿景是做成一个每个小部分的体验都很好的大数据平台，从这个层面上讲，整个公司真的还处在起步阶段，有太多的事情等着做。

从成长以及规模上讲，Databricks的收入在过去几年一直是保持高速增长，而这个势头没有放缓的趋势，过去的一年员工的数量增长一倍，达到了三千多，其中工程师数量增长一倍，从小几百到了大几百人。而未来的一年整个公司的计划是工程师数量和员工数量再翻倍。

作为工程师来讲，如果一个公司的利润、用户、产品流量、工程师团队都在高速增长，意味着加入之后你能得到更多机会。具体地说，就是在技术和软技能上面都会有更多锻炼的机会：在技术上，作为普通的backend/infra engineer，最重要的就是能多参与到system design中去（只有多参与进去，多思考trade-off，多讨论，才能在技术上成长）。在软技能上，最重要的就是参与到需要很多人完成的复杂项目中去，才能锻炼自己沟通、写文档、做演讲等能力。对于以上两个方面，Databricks现在遍地都是机会。

因此有兴趣的同学可以发邮件丢简历给我，也可以发邮件跟我进行技术上的交流：邮箱是lakehouseforthewin AT GMAIL



6. 后记
写这篇文章的初衷是为了记录一下自己过去半年来的一些收获和思考。互联网上大家随手一搜就能看到很多讲Data Warehouse/Data Lake/Data Lakehouse的文章，但是他们的共同特点都是讲得太高屋建瓴了，一般都是单纯比较一下这些架构的优缺点，让人看完之后觉得自己懂了，但好像又什么都不懂。我在半年前看到这些文章的时候，总感觉如果有个人能举出一些实际例子来说明Data Warehouse/Data Lake/Data Lakehouse的优缺点，对工程师来说是更容易理解的。因此我在这篇文章中努力地举了一些（可能不是很好的）例子，希望能让不熟悉这个领域的人稍微有所收获。当然，我不是专业写作的，我也不是云计算领域资深从业者，因此文章肯定会有各种不足，希望几年之后我再写一篇可以写得更好。


补充内容 (2022-02-16 14:00 +8:00):
补充一下：经过指正，我文中对Data Lineage的理解应该是错的。它指的大概应该是从table column到table column的tracking，也就是“对数据从下游到上游的溯源”。而不是我文章中说的对一张表的历史进行追溯。

补充内容 (2022-02-17 02:40 +8:00):
补充说明一下什么是semi-structured data，以及为什么Data Warehouse对ML支持不好：举个例子说明，假设我们在Data Warehouse的user activity table里面需要记录用户购买过的商品，于是每一条用户行为数据长这样：
-user id
-item
  -item id
  -item price
  -item metadata
-item
  -item id
  -item price
  -item metadata
-...
  -...
这里面的商品（item）其实是一个不定长度的list，在Data Warehouse里面，因为对数据必须用传统的二维表的格式建模，我们只能在user activity table里面新增一个column，叫purchased_items，然后column的schema是list of variants，意思是“这个column是一个list，但是每个list我不知道里面装的是什么”。问题的本质就是ML的数据天生就是树状结构的，会有很多不定长的list（semi-structured），导致存数据库会丢失信息。

如果我们在Lakehouse里面的user activity table存以上信息，因为Delta Lake Format天生在逻辑上就是树状结构的（底层实现上是面向列的存储），所以我们可以完整地加入一个item field，而这个field的schema是list of (id field, price field, metadata field)，id field是int，price field是double，然后这里面的metadata field我们甚至可以继续展开，这样就是完整的树状结构。

所以如果这个数据存在Data Warehouse，我们没办法做这个SQL query：有多少用户买的商品总价超过50快？但是存在Lakehouse里面可以。

补充内容 (2022-02-18 14:58 +8:00):
经过我这几天的学习，发现文章中这两个概念也混淆了：schema和structured data

Data Warehouse支持数据的schema（因为它本质是数据库），Data Lakehouse也支持数据的schema（Databricks自己就不靠数据库实现了对schema的支持）。Data Lake不支持数据的schema。

而Data Warehouse支持structured data，我们勉强也可以说它支持semi-structured data（其实支持得并不好）。而Data Lakehouse和Data Lake对structured data, semi-structured data以及non-structured data都支持得很好。
. 1point 3acres
我文中扯的“弱schema”纯属瞎扯

补充内容 (2022-02-26 02:30 +8:00):
写了一篇后续：谈谈Databricks和云计算（二）

https://www.1point3acres.com/bbs ... ;page=1#pid16735380

守望者_USA 发表于 2022-2-15 20:02
不好意思打击一下lz，不否认db的技术很牛逼，但是公司给人的面试体验特别差，整个让人觉得我们牛逼上天，给 ...

“面试体验差”这个问题我已经听到几个人说过了。首先Databricks非常在意招进来的人，因此也很注意招人流程的体验。但是依然防不住有一些自我感觉良好的员工在面试的时候给人居高临下的感觉。

我个人在面试别人的时候都是努力尊重对方，让对方发挥自己最大的水平，而且我认识的同事大多数都是这样的，特别是公司的老员工以至于创始人级别的员工们。毕竟公司大了还是会有一些能力很强但是比较entitled的人进来，我个人不能代表公司，但是我不喜欢这样的人，其实我在blind上看到的很多其他同事也不喜欢这样的人。

2ndcat 发表于 2022-2-15 20:30
以前公司用过是很好用，但是想问一下楼主，很多公司最后发现从Databricks 换成三大cloud的附属产品了，虽然 ...

你的意思是说Lakehouse这种东西，三大云平台很容易就推出一个替代品然后把Databricks干掉？

但是Lakehouse里面那么多组件（SQL query engine，storage，unity catelog，ETL tool，乱七八糟其他的东西）任何一个拿出来都需要一个工程师团队做好几年，做好之后需要不断优化性能以及打磨用户体验。Databricks在这个领域有极大的先发优势，我不觉得三大云平台可以现场组建一个团队做出在性能和体验上都类似的产品。

匿名者 发表于 2022-2-16 11:34
谢谢补充。对于您举的semi structure的例子, user id, 和不确定长度的item id,我们直接将它拆成以
, 以u ...

1. 关于拆分然后存在relational/non-relation DB里面（其实就是denormalize）：我们这里讨论的是analytics database而不是供online server读写的database。如果是供online server读写的database，我们肯定需要denormalize来优化性能。Data Warehouse以及Lakehouse都面向的是analytics使用场景，这些场景的特点是数据大，跨表join贼贵，因此一般会在一张表里面存很多数据。在此基础上，如果一张表的数据既要用SQL query它，又想支持ML，理想状态就是这张表的每一行数据都对应ML model的一条training example，方便ML team直接写一个简单的ETL pipeline就能把表里的数据抽出来喂给model training system。这也就是我为什么举了user activity的那个例子，真实场景下，ML组是绝对不会考虑去denormalize那张表的。

2. “对于这些存储方式，它们既能支持ML，各种商业逻辑，也有性能保证”：这个推断太过于简单随意了。“支持ML”，“支持各种商业逻辑”，“性能保证”，随便一个拿出来都不是简单就能完成的。如果你想拿其他任何一个产品出来（比如GCP上面的各种东西）和Databricks的比较，然后论证Databricks的东西可以很容易被替代，你需要比较以下几个方面：
. Χ- feature parity（两边是否功能相同）
- user experience（用户用着爽不爽）
- performance（性能，也可以拓展一下含义，包含价格）
- 其他（还有其他细节我就不列出来了，比如跟其他产品的兼容性）
我觉得你需要深入调查才能下结论说Databricks可以很容易被XXX产品替代。

我举个例子，在Databricks里面做SQL Analytics以及ML都可以在Notebook里面完成。用那个user activity table的例子，一个ML engineer可以在Databricks里面新建一个Notebook（就像Jupyter Notebook），在Notebook里面写SQL query大概了解一下table里面有哪些数据，哪些数据能做成feature，然后跑完query直接在Notebook里面把数据可视化，了解一下feature distribution。在同一个Notebook里面，我可以用SQL写一个简单的ETL pipeline，也可以用Scala写一个复杂的ETL pipeline来把数据转换成喂给ML training framework的格式。然后在同一个notebook里面，可以继续写Python代码用各种framework（tensorflow, pytorch, sklearn etc.）train一个model，也可以直接在同一个Notebook里面启动auto ML帮你自动调参。model training完成以后可以直接在同一个notebook里面把最满意的model用一行代码register到Databricks的MLflow里面，然后直接继续在当前的notebook里面用刚才挑选的model对某张表的数据进行batch inference。注意，这里我全程都没有离开Notebook，但是完成了各种SQL和ML的workload。然后在webapp里面进入“model”这个tab（注意，这里是我们第一次离开Notebook），可以enable model serving，这时候Databricks可以自动帮我部署model，我可以拿着Databricks生成好的model inference url去做online inference。我不确定是否有任何其他产品有这么好的体验。

不好意思打击一下lz，不否认db的技术很牛逼，但是公司给人的面试体验特别差，整个让人觉得我们牛逼上天，给你面试就是天上掉下来馅饼。公司再牛逼，人不行，恐怕也是不长久的！

补充内容 (2022-02-16 12:07 +08:00):
还是感谢lz详细介绍db的领域，非常好的入门文章。

以前公司用过是很好用，但是想问一下楼主，很多公司最后发现从Databricks 换成三大cloud的附属产品了，虽然没有databricks 好用，但是因为是捆绑在GCP/AWS/Azure一并销售便宜很多，最后很多公司并不会又用三大Cloud又用Databricks。

导致最后容易像dropbox那样，被onedrive/Google Drive/icloud大厂便宜的优势弄垮？  大厂在Cloud上已经占据平台优势，databricks有什么功能大厂复制一个功能接近50-60%的东西太容易了，最后几乎免费地给已经买了他们core cloud服务的公司用， 买方因为便宜选择牺牲一点性能也太正常了，抢光databricks的市场份额不是难事？

楼主用心了！相信databricks内部应该有很多关于snowflake的竞品分析，在对snowflake的认识上可以再做做研究。云数据仓库是好几年前的概念了，现在的竞争赛道更多的是放在延展性上，即data sharing & data application。sf和db其实走的是相反的两条路，但最终的愿景是很像的，所以导致了最近这一年更加激烈的直接竞争。因为我两个产品都用过，现在sf与一线客户交流也很多，所以有很多有意思的观察，也欢迎以后继续交流。

关于data lake/data warehouse/data lakehouse的讨论，有兴趣可以看看这篇文章，也许能提供一些不一样的思路：https://jeremiahhansen.medium.co ... a-lake-38723fc1be23

同时也干脆借这个机会替snowflake打打广告:) 有志于saas云计算大数据领域的同学不妨考虑申请。

例子举得太贴切了，讲得非常清楚！感谢楼主！

楼主有心了 这么好的文章考虑自己建个博客？或者po在medium？

好文，紫薯紫薯紫薯

收藏起来

感觉楼主今晚邮箱要💥 哈哈 enjoy the CKO 👻

这么好的文章不考虑搞个blog啥的吗

有几个问题想问下楼主：
1. 存储计算分离也不是什么新概念，比如Trino/PrestoDB，是FB从12年就开始做的开源项目，后来分支了，现在相关的startup有Startburst, Ahana，做出来的东西性能很好，里面的人背景也很厉害，请问楼主关于Databricks和这些公司比较的看法？
2. Cloud datawarehouse在某些方面有一定优势的，举个例子，可以给专门的存储建立索引和聚合，这个存储和计算分离的方向就做不到，比如Firebolt，这家里面的人的背景也很强，我感觉是现有产品里面最快的，不知道从楼主的角度Databricks是怎么看待这方面的优化的局限？
3. 现在还有新方向比如从transaction/indexing起家做lakehouse的公司，比较出名的是OneHouse，前身是Apache Hudi，这个项目的名声做这方面的应该都懂，楼主对这两类产品的比较怎么看？
4. 关于Serverless Endpoint，其实就是fully managed SQL query service，这个三大云厂商都有对应的服务，真正的难点在于资源的估算、利用率和调度，这些云厂商其实内部在这方面有很大的优势，能用某些不可描述的方法大幅降低成本。如果我没猜错的话，如果Databricks在这方面刚起步，应该是亏钱的，而且是用的人越多亏的越多，请问楼主怎么看待Databricks在成本方面和这些云厂商的竞争？





..

大致看完了，有几个问题想请教一下，作为一个平台，甲方的数据存在哪？存在你们的类似s3的服务器上还是甲方自己的服务器上？；像制造业，他们有很多很多数据，但数据的格式非常奇怪，需要通过转换才能变成可读的格式，这种情况下也可以存在你们的平台上然后查询和跑ml吗？；跑ml的计算资源是你们databrick提供的嘛？谢谢

Good stuff!