阿尔法公社

重度帮助创业者的天使投资基金

Databricks是一家正在崛起的企业软件巨头。2021年，它连续获得两轮10亿美元级别的大额融资，估值跃升到380亿美元，它在数据和人工智能领域具有全球雄心。

Databricks是一个非典型的创业故事，它由七位联合创始人创办，其中大部分是学者。它从Spark开源项目起步，现在引领了数据湖范式，这将加速其与主要竞争对手Snowflake的竞争。

本文是投资人Matt Turck与Databricks联合创始人兼CEO Ali Ghodsi的对话实录，Matt Turck在2015年就与Databricks的联合创始人Ion Stoica有过对话，对于Databricks的情况相当熟悉。在本文中Ali Ghodsi将透露Databricks从一个开源项目到大型公司的成长经历，以及在团队，产品，进入市场，扩张等方面积累的洞见，Enjoy。

科学家创始人们推动Databricks起步

Matt Turck： 我们谈一下Databricks的起步，AMPLab、Spark和Databricks，这一切是如何开始的？

Ali Ghodsi： 我们当时正处于人工智能革新的风口浪尖：Uber刚刚起步，Airbnb、Twitter处于早期，Facebook还不是巨头。他们声称，使用20世纪70年代诞生的机器学习算法实现了很好的效果。

以当时的常识来想这不可能是真的，我们觉得那些算法不可能Work，但他们说，“不，我们得到了非常厉害的结果。”当仔细观察后，我们的想法被颠覆了——他们确实获得了惊人的结果。以现代硬件和大量数据为支撑，运用上世纪的算法依旧可以获得令人难以置信的产出，我们对此感到震惊。我们想："需要使之普适化"。例如，在Facebook，他们可以提前检测到情侣分手，如果地球上的每个企业都有这种技术，这会对现有商业产生巨大影响。这就是AMPLab的起点。

Matt Turck： 当时AMPLab的Spark是怎么来的？

Ali Ghodsi： 图灵奖得主之一戴夫·帕特森当时是伯克利的教授，他非常相信人们应该聚在一起，打破孤岛。伯克利的教授们放弃了自己的私人办公室，和所有学生一起在巨大的开放区域办公。

他们试图解决的机器学习问题以当时的技术背景来说是很有挑战性的。AMPLab里做机器学习的人，做数学的人，不得不使用Hadoop，数据的每一次迭代都必须运行MapReduce，这样光是做一次迭代就需要20到30分钟。所以当时我们决定："联合起来，建立一个反应快速的基础架构。”我们在数据上做了很多迭代。因此，不只是做一次，不只是一个SQL引擎，而是可以做递归机器学习的东西，并可以极快地找到数据中的内涵模式。

Matt Turck： Databricks创始故事的特殊之处在于，你们有七、八个联合创始人。回过头看，拥有这样一个大的创始团队利与弊是什么？

Ali Ghodsi： 肯定是有利有弊的。如果你知道如何真正让由七个人组成的紧密小组真正信任对方，并在一起工作得很好，就会发生令人惊讶的事情。我认为Databricks的成功很大程度上归因于我们互相的信任。

创业早期的创始人，即使只有两个人，他们也会争吵，然后可能会在一两年内分裂，这就是问题所在。我们找到了一种方法，使大家真正了解对方的长处和短处，使这段创业旅程成为一种乐趣。

人们总说CEO是地球上最漫长的工作，我从来没有这种感觉。我有很多联合创始人和我在一起，他们一直都在，这对我们来说绝对是一种力量。如果我们没有这些人，就不会有现在的成就。

从开源项目到公司，

从0到100万美元ARR

Matt Turck： 你们是如何从学术性的开源项目（Spark）变成一家公司，然后从0做到1000万美元ARR的？这背后是否有任何决定性的时刻，或其他特别的增长手段？

Ali Ghodsi： 我们从0到100万美元ARR的旅程非常特别，与其他的旅程非常不同。我们经历了三个阶段，第一个阶段是PMF（产品与市场契合）阶段，当你有了一个产品，你能找到它与用户之间的契合点么？这对任何公司都存在挑战。

你一旦你找到PMF，接下来就得弄清楚什么是能将该产品与市场联系起来的渠道，你的产品或许符合市场需求，但怎么通过渠道销售呢？事实上，我们一开始在这方面走了弯路，花了几年时间才确定正确的发展方向。在这几年里，为了弄清楚Databricks的正确模式我们进行了大量的实验。

接下来，让我们从产品开始，然后再谈谈渠道。

产品方面，我们有在伯克利建立的开源技术，但这不一定符合大企业的需要，因为在大企业，他们没有来自伯克利的博士。因此，我们需要为他们大简化问题，我们开始在云中托管它，但事实证明，即使是云版本对他们来说也太复杂了，无法使用。

因此，我们开始与用户一起进行迭代。我们在这之后削减了很多特性和功能，甚至可以说重新构建了一个产品。我们问自己："如果我们知道现在的一切，回去再做一次，会怎么做？"

于是，我们重新做了另一个开源项目，Delta，你可以把它看作Spark为大型企业所做的非常简单和自动化的软件。当我们在伯克利时，我们的产品设想是提供尽可能多的功能和设置项，因为可能是一个博士在用它做研究。但当我们把产品在企业中推广时，我们意识到不是每个人都有博士学位，大家不知道如何使用它。这就是早期我们遇到的问题。在渠道方面，错误在于，我们在早期真的是非常相信这种产品主导的增长。

关于销售，当时我们的设想是，有了一个简化的产品，我们把它做成基于云的产品，就会有人会使用它，会为它刷信用卡，我们会非常成功。我们可以雇用销售人员，给年轻人打电话进行推销，我们不会雇佣企业的销售人员。我们更喜欢这种模式，它更便宜，更简单。

但那是一个错误。你不能凭空选择你的渠道。你有一个产品和相应的市场，必须找到正确的渠道来连接它们。

Databricks如何开发产品，

数据仓库VS数据湖

Matt Turck： 我们一会再继续谈进入市场。现在让我们先谈谈产品，我在Databricks观察到的令人着迷的事情之一是，你们发布新产品并将其转化为一个平台的速度。从Spark到机器学习到AI工作台再到Lakehouse，请向我们介绍一下产品的思路——一个产品如何导致另一个产品的出现。

Ali Ghodsi： 我们从Spark开始起步，它让用户可以访问所有数据；于是人们开始在企业中创建数据库，并在其中积累了大量数据。但过了一段时间，企业高管会问：“我不在乎我们获得和存储了多少数据，你能用这些数据为我做什么？ ” 这就是我们试图建立其他应用程序的原因。

起初我们的收入很少，然后我们意识到它太复杂了，有太多的选项和配置。我们就问自己："如果必须重做，必须简化，会做什么？"这种思路后的第一个创新是Delta，它重新定义了Spark，以一种真正企业友好的简化方式。但最初我们没有将它开源。

接下来，我们想：“如果拓宽数据库的用途，不仅仅是数据科学家和机器学习工程师，而是真正广泛的用例，应该怎么做？ ” 这就是我们开始重视商业分析师的原因。

商业分析师习惯于像Tableau那样的操作软件。如果他们想做一些更复杂的事情，只能使用SQL。因此，我们在四年前开始致力于构建数据仓库能力，把它建立在我们称为Lakehouse的核心基础设施中，然后在前年较大规模的推广。

我们的秘诀是：看企业的问题，弄清楚那是什么，通过实际的客户问题来深入了解它，把问题带回来，解决这个问题，在云中与客户快速迭代。一旦它有了产品的市场适应性，就把它开放出来。建立巨大的开源势头，几乎像一个B2C病毒式的形式。然后，用基于云的SaaS版本将其变现。

这是受AWS的启发，当创立Databricks时，我们认为AWS是地球上最好的云计算开源公司。他们本身不进行开发，其盈利模式基于开源软件，托管它并在上面赚很多钱。我们只是在这一点上进行了调整和演变。我们认为：“这是一个伟大的商业模式。我们将在云上托管开源软件。但不同的是，我们将自己创建开源软件。这样一来，就获得了相对于其他任何想做同样事情的人的竞争优势。 ” 否则，任何人都可以建立任何开源软件并在云中托管它。

Matt Turck： 接下来，让我们从Lakehouse开始，了解一下数据湖和数据仓库的演变，以及Lakehouse是如何在这两个领域中取得最好的成绩。

Ali Ghodsi： 这很简单。人们在数据湖里存储所有的数据：数据集，视频、音频、随机文本，这既迅速又便宜。利用各种各样的数据集，你可以基于数据湖进行AI创新，AI与数据湖密切相关。如果你想做BI，而不是AI，你就使用数据仓库，数据仓库和BI有一个单独的技术堆栈，但是它其实和AI一样，有很多同样的数据集。

BI用于回答过去的问题，比如上个季度的收入是多少；AI用来问关于未来的问题，哪些客户将会回来？所以，这意味着需要两个独立的堆栈，你必须有两个数据副本，而且你必须管理它们，这造成了很多复杂性。但当年的FAANG（硅谷几个顶尖互联网巨头的联合简称）可不是这样做的，他们有一个统一的平台。所以，我们的想法是把这两个统一成一个平台—Lakehouse、人工智能数据湖--提出关于未来的问题。这两者的结合将使企业能够更快地发展。它是数据工程师、数据科学家和商业分析师的平台，这样他们就可以在整个企业内一起工作。所以这是一个用于AI和BI的数据平台。

Matt Turck： 实现这一点靠的是什么重大的技术突破么？是Delta Lake？还是Iceberg？那是如何工作的？

Ali Ghodsi： 是的， 我认为有四个技术突破是在2016、2017年同时发生的，Hudi、Hive ACID、Iceberg、Delta Lake，我们贡献的是Delta Lake。问题是这样的，在数据湖里有人们收集了所有的数据，这些数据非常有价值，但很难对它们进行结构化查询。之前的传统方式是利用SQL数据库，然后应用在BI领域。因此，你需要一个单独的数据仓库。

为什么这么难？因为数据湖是为大数据、大数据集建立的，它并不是为真正的快速查询而建立的。它太慢了，而且没有任何方法来结构化数据，并以表格的形式展现数据，这就是问题所在。那么，你如何把像一个大的数据块存储的东西，变成一个数据仓库？这就是这些项目的秘诀。我们找出了解决这些数据湖效率低下的方法，并使用户能够直接从数据湖的数据仓库中获得相同的价值。

Matt Turck： 这种方法有什么取舍吗？

Ali Ghodsi： 事实上并非如此，我们做到了鱼与熊掌可以兼得。我知道这听起来很疯狂，但试试就是如此。我们减少了很多在80、90年代由数据仓库供应商发明的技术，调整它们，使它们在数据湖上工作。你可以问：“为什么这在10或15年前没有发生？ ” 因为开放标准的生态系统并不存在，它是随着时间的推移慢慢出现的。所以，它从数据湖开始，然后有一个很大的实际技术先导突破。我们在这里谈论的，是数据的标准化格式。他们被称为Parquet和ORC，但这些是数据格式，行业要将所有的数据集标准化。

这些类型的标准化步骤是需要的，以获得数据湖的突破。这有点像USB，一旦你有了它，你就可以把任何两个设备相互连接起来。所以，正在发生的事情是，开源领域的一个生态系统正在出现，在那里你可以在数据湖的范式中做所有的分析。最终，你将不需要所有这些自八十年代以来的专有旧系统，包括数据仓库和其他类似系统。

Matt Turck： 我会针对这个再问问题，业界有很多关于Snowflake和Databricks之间即将发生大冲突的议论，作为这个领域的两个巨大的公司，你对未来的看法是，数据湖最终成为范式，然后随着时间的推移，其他一切都被吸收？还是你认为未来更多的是混合，用户可以用数据仓库做某些事情，数据湖做其他事情？

Ali Ghodsi： 我将从两个方面回答这个问题。首先，人们把这说成是零和博弈，但你认为谷歌云会淘汰AWS和微软云，还是AWS会淘汰其他云？没有人这么认为，对吧。他们会共存，都将获得成功。

数据空间是巨大的。将会有很多供应商参与其中。我认为Snowflake将获得成功，他们现在有一个伟大的数据仓库，可能是市场上最好的数据仓库。而它肯定会与Databricks共存。事实上，Databricks与Snowflake共存于可能70%的客户中。我认为这种情况将继续存在，人们将使用数据仓库进行商业智能。

但是，如果长期来看，我认为数据湖的范式将获胜。为什么？因为数据太重要了，人们所有的数据都在这些数据湖中，而且更多的数据正在进入数据湖中。公有云计算供应商也有动力推动更多的动力让人们把数据存到他们的数据湖中，因为这对他们来说是既得利益。因此，任何使其真正有价值的解决方案，都将是未来的趋势。所以，我认为从长远来看，越来越多的人将倾向于这种数据湖的范式。

为什么Databricks能够不断产出创新产品？

Matt Turck： 我想了解你的产品和工程团队是如何组织的？对于一家公司，能够在第一个产品成功的基础上做第二个产品是非常罕见的。但在这里，我们正在谈论，如何成功的做出三个、四个、五个不同的产品。你的公司是如何管理好团队组织结构和其他资源，以不断创新？

Ali Ghodsi： 我们从创立Databricks时，就在试图找到这个问题的答案。我们不想靠一个单一的产品生存。当我们有了Spark，却并没有把它当成公司的名字，因为如果Spark变得落后了，我们就会把它迭代掉，然后继续向前，我们想不断找到数据的最佳答案。那么如何不断的有创新产品出现？我认为非常重要的是，要把创新和现有的现金流业务分开。

有一本关于这个问题的好书，叫Zone To Win。书中谈到，当你创造出一些新东西时，你需要快速迭代。你需要让工程师直接与客户交谈，甚至不一定要让产品经理来做，快速的创新迭代是最要紧的。而在在企业端，你需要一个慢得多的周期来迭代。

另外，所有的工程和产品团队组织被分成两个不同的部分。一部分专注于企业客户需要的东西：加密，安全，认证，稳定性等。另一部分则专注于创新，而且你应该把这些分开，分别的投入资源，否则前者（企业那部分）将得到所有的资源。你会倾向于不断地建立那些扩大你的TAM的东西。TAM扩展实际上是安全能力，它本身并没有任何创新。

我认为，有些公司已经做得很好了，比如AWS，它不是一招鲜，亚马逊本身也不是一招鲜，它不断有新的创新。所以我们希望我们的公司也是这样的，因此取名为Databricks。

Matt Turck： MLflow Delta Lake, Koalas。这属于创新阵营还是商业阵营的子层？

Ali Ghodsi： 这些都是创新阵营。当然，其中一些项目，当他们不那么创新的时候，像Spark，会转移到维护方面，我们通常也会移动核心人员。因此，实际上是同一个人或同一拨人在不断地进行创新。我们试图培养更多的创新者，但我们试图把那种已经真正有诀窍破解从0到1的人转移到下一个问题，然后把现有的项目移交给其他人去运行，比方说Spark，这已经是一个巨大的成功项目。

当我们把已经创造出东西的人转移到别的地方去创造下一个东西，对于一个优秀人才，获得这种责任是一个很大的职业提升。而我们也会发现谁是擅长从0到1人。我们实际上是在做实验，给研发部门的人一个机会去试验从0到1的东西，他们并不总是成功。这需要几次尝试，直到他们成为真正擅长的人。所以你必须慎重考虑这种高失败的策略。

开源的商业模式，有何优越性？

Matt Turck： 如果你今天要再开一家企业软件公司，你会先去开源代码吗？

Ali Ghodsi： 是的，我认为它很优越。我认为如果你从进化的角度来考虑，它在进化上比以前的商业模式要好。为什么我这么说？因为任何专有的软件公司都是成熟的，可以被开源的竞争者破坏。因此，任何专有的东西都可以立即被颠覆，就像Windows被Linux颠覆一样。我的意思是，那是最先进的东西，是真正复杂的技术操作系统，对吗？你不会认为大学里的某个家伙会发明，然后成为工业的标准。任何专有软件都是成熟的，可以进行这样的颠覆。问题是，你能靠它赚钱吗？在红帽和所有这些做支持网络服务的公司之前，这真的很难，直到AWS破解了商业模式的密码。

商业模式是我们为你运行软件，你从我们这里租用它。这是一个优越的商业模式，因为你实际上可以拥有大量的IP，这是很难复制的。所以我认为我创办的下一家公司将是这样的。如果你要问我，我的下一次创业会在哪个领域开始，我会在人工智能方面做什么？我会认为我们现在在人工智能方面的应用还很浅层，尤其是操作性的人工智能。人工智能未来将会被嵌入到各个地方。我知道这很老套。马克·安德森说，软件正在吞噬世界。我们真的相信，人工智能将吞噬所有的软件。你拥有的任何软件，人工智能都会悄悄进入，就像软件悄悄进入你的 汽车 、冰箱和恒温器一样。所以这真的是早期的事情，我认为任何加入或创办人工智能领域公司的人，他们还在早期，他们有机会创办下一个谷歌。所以这就是我想做的。

Matt Turck： 我们谈到了开源，也继续谈进入市场的问题，在这个阶段，作为一个非常晚期的创业公司。开源在进入市场的过程中处于什么位置？你们进入市场的策略是自下而上与自上而下？你们如何分配BDR小组与AE的工作，让他们协作而不是互相拖后腿？

Ali Ghodsi： Databricks是混合模式，我们是自下而上与自上而下在同一时间结合。一开始我们是自下而上，但是也会做自上而下的事情。我们有BDRs和SDRs。这是一个从市场营销开始的筛选器。

Databricks社区版是完全免费的，你想怎么用就怎么用，永远不需要付钱，而且有完整的功能。但是从这里产生的线索会导入到SDR。因此，这也是一个非常重要的管道。我们一半的线索来自于此，这就是为什么开源对我们是一个重要的引擎。

现在，我们也有传统的企业销售动作，比如给CIO递名片，一对一的交流，但发生的情况是，开发人员在这些组织中也变得越来越强大。例如，CIO说，我与Databricks的CEO进行了一次很好的谈话，我正在 探索 这项技术，但我担心，这对我们来说是正确的选择吗？那家公司的听众中会有人说，是的，我使用社区版。我们不需要做6个月的POC。我认识这些人，他们真的非常好，或者我认识他们，他们来自伯克利。我已经使用了这些技术。我去参加了一些聚会等。

因此，这有助于证实用例，你可以消除整个POC，因为他们已经知道它是什么，而不是像10-20年前那样，一个销售人员进来，解释这个软件有多棒，但你不能相信他们。因此你就必须去做POC，然后去花时间检验这个软件是不是真的有用。我们不必这样做，我们可以穿过所有这些层次。因此，我们把自上而下和自下而上结合起来，而这两方面对于Databricks的成功都是非常必要的。

从创业公司到超级独角兽，

领导者的修炼之路

Matt Turck： 你已经把一家小型创业公司带成了超级独角兽，很快还会上市。你是如何让自己完成角色转变的，从一个讲愿景，讲故事的人，变成管理一个全球组织？

Ali Ghodsi： 其实就是如何找到你可以信任的具有领导力的帮手，并和他们建立更深的信任。我可以把我大部分时间都花在这上面，而公司能够继续正常运行。我有运行良好的销售团队，市场营销团队，工程团队，我却不需要自己直接参与其中，因为我找到了适合领导这些部门的领导者，并且花了很多时间与他们建立起信任。

这是你在早期就要开始准备的事情，早期时，你的组织规模小，你可以参与到每个环节，如臂使指。但是当团队规模扩展到150-200人直到超过邓巴数。你会感觉自己完全被淹没了。因此你必须找到可以信任的正确的领导人，而且要找到自己与组织沟通的方法，因为现在不是直接沟通，而是通过领导层间接沟通，所以帮助你与团队组织沟通的人就特别重要。

Matt Turck： 你如何找到他们？你是偏向在内部提拔人才，还是从外部引入已经获得成功的高管，哪一个效果更好？你是如何处理的？

Ali Ghodsi： 要找到与公司文化相适应的、你能与之建立强大信任的高管是非常困难的，我认为不应该排除任何选项。如果能够从内部提拔人，那很好，但是如果只是内部晋升，你就不能获得市场上已经存在的成功经验，这种经验可能是超级有价值的。

如果我们寻找外部的高管，他必须经历过我们现在所处的阶段，有实战的经验。不是说他必须从零开始创建一个估值几百亿的公司，而是建立和操作过这种阶段公司的工程等相应部门，他是否在这个过程中有第一性思考，有自己的沉淀。我认为能力和智商还是非常重要的。

文化看起来是个很复杂的东西，但是对与我，会把它分解成一连串问题：我可以和这个人相处吗？愿意每天花10个小时和他在一起工作么？当事情变得非常棘手和困难的时候，我们能一起去解决问题么？所以你要做的就是花大量时间与这个人相处，然后问自己是否喜欢他们，就像婚姻一样。你可以问他们一些困难的问题，与他们争论或者听取他们的意见，直到确定这就是正确的人。如果你感觉到自己无法和某个人一起好好工作，那他就可能是文化不匹配。

本文编译整理自Matt Turck个人博客，略有删节。

关于阿尔法公社

阿尔法公社（Alpha Startup Fund）是中国领先的早期投资基金，由曾带领公司在纳斯达克上市的许四清和前创新工场联合管理合伙人蒋亚萌在2015年共同创立。

阿尔法公社基金的三大特点是系统化投资、社交化创业者社区运营和重度产业资源加速成长。专注在半导体、企业服务软件、人工智能应用、物联网技术、金融 科技 等 科技 创新领域进行早期投资。目前已经在天使轮投资了包括白山云 科技 、领创集团(Advance Intelligence Group)、Zenlayer、帷幄 科技 、所思 科技 等为数众多的优秀项目。

数据管理和分析趋势正在改变世界

编译：诚历，阿里巴巴计算平台事业部 EMR 技术专家，Apache Sentry PMC，Apache Commons Committer，目前从事开源大数据存储和优化方面的工作。

像公有云数据湖和 Delta Lake 这样的平台指出了一个中央数据枢纽的趋势，用来支持决策和AI驱动的自动化决策。

数据仓库是否再次加入这股浪潮呢，或者会逐渐消亡？

如果你不清楚这个问题的答案也很正常。数据仓库在一方面目前仍处于热门阶段。笔者作为一个长期的行业观察者，看到了在不断创新和创业活动浪潮下行业的快速发展。

这种趋势基本上始于十年前标准设备进入数据仓库主流，然后随着市场向新一代云数仓转移逐渐获得了新动力。在过去几年中，一个云数仓供应商（Snowflake） 在市场上获得了非常多的支持。

但在另一方面，数据仓库也不断被行业中的新事物所冲击，例如大数据、机器学习和人工智能。这种趋势造成了数据仓库在企业IT优先级下降的印象，但事实上大多数组织至少有一个或者多个数据仓库服务于各种下游应用程序。

数据仓库一直作为企业核心工作服务，是几年前我觉得数据仓库远未消亡的原因，这也可能解释了为什么其他观察者认为他们必须重新定义数据仓库的概念，以使其在数据湖和云计算时代保持相关性。

许多人认为“数据湖”正在迅速发展成为下一代数据仓库。对于那些不熟悉这个概念的人来说，数据湖是多结构数据的系统或存储库，它们以原始格式和模式存储，通常作为对象“blob”或文件存储。

数据湖通常用作所有企业数据的单个存储，包括源系统数据的原始副本和用于生成报告，可视化，数据分析和机器学习等任务的转换数据。它们包含分布式文件或对象存储，机器学习模型库以及高度并行化的处理和存储资源集群。并且，数据库通常在读取时使用模式，并使用统计模型从中提取有意义的相关性和模式，而不是对它们存储的对象强制执行通用模式和语义。

这些都与Inmon和Kimball核心概念不一致，这些概念为大多数专业人员的数据仓库方法提供了信息。从根本上说，一个数据仓库主要用来聚合，保留和管理官方认可的“单一版本的真实”数据记录。此概念与所管理数据的特定应用程序域以及使用它的特定用例无关。

如果你怀疑我在那个分数上说的话，请看看Bill Inmon对数据仓库的定义以及Inmon和Ralph Kimball框架的比较。数据仓库通常都是关于数据驱动的决策支持，这使得它可以很好地扩展到AI驱动的推理的新世界。

在过去的一年中，一些备受瞩目的行业公告标志着数据仓库角色的转变。尽管决策支持（也称为商业智能，报告和在线分析处理）仍然是大多数数据仓库的核心用例，但我们看到了其向决策自动化的稳步转变。换句话说，数据仓库现在正支持着数据科学管道，为数据驱动的推理构建了机器学习应用程序。

新一代数据仓库实际上是数据湖，对那些用于构建和训练机器学习模型的清洗，整合和验证的数据进行管理。例如，去年秋天在Amazon re：Invent 大会上，亚马逊网络服务公布了AWS Lake Formation。这种新的托管服务的明确目的是简化和加速安全数据湖的设置。然而，AWS Lake Formation 拥有云数据仓库的所有特点，尽管AWS并没有这样称呼它，实际上已经提供了一个面向决策支持应用程序的经典数据仓库。

AWS Lake Formation的架构和功能类似于数据仓库。实际上，AWS以这种方式来描述它：“数据湖是一个集中的，策划的和安全的存储库，它以原始形式存储所有数据并为分析做好准备。通过数据湖，您可以分解数据孤岛并组合不同类型的分析，以获商业洞察力并指导更好的业务决策。“

另一个例子是 Databricks 最近宣布的 Delta Lake开源项目。 Delta Lake的明确目的（现在可以在Apache 2.0许可下使用）类似于AWS Lake格式：通过对数据湖中维护的数据集的聚合，清洗，管理和治理，以支持机器学习。

Delta Lake 位于现有的内部部署或云数据存储平台之上，可以从Apache Spark访问，例如HDFS，Amazon S3或Microsoft Azure blob存储。 Delta Lake将数据存储在Parquet中，以提供Databricks所称的“事务存储层”.Parquet是一种开源的列式存储格式，无论数据处理框架的选择如何，都可用于Hadoop生态系统中的任何项目。它通过乐观并发可串行化，快照隔离，数据版本控制，回滚和模式实施来支持ACID事务。

Delta Lake和AWS Lake Formation之间的一个关键区别是 Delta Lake 处理该管道中的批量和流数据。另一个是Delta Lake支持所有数据的ACID事务，允许数百个应用程序同时进行多次写入和读取。此外，开发人员可以访问每个Delta Lake的早期版本，以进行审计，回滚或重现其MLFlow机器学习实验的结果。

在最广泛的层面上，Delta Lake似乎与使用最广泛的开源数据仓库项目 Apache Hive 竞争，尽管 Hive 完全依赖基于 HDFS 的存储，并且直到最近才解决对ACID交易的支持。Hive 3一年前被宣布终于为基于Hadoop的数据仓库提供ACID支持。 Hive 3使用delta文件为事务CRUD（创建读取更新删除）表提供操作的原子性和快照隔离。

这些最近的行业公告 - AWS Lake Formation，Delta Lake和Hive 3预测是数据湖成为所有决策支持和决策自动化应用以及所有交易数据应用的治理中心的日子。为了加速这些趋势，Hive 3和Delta Lake等开源项目需要在供应商和用户之间获得更广泛的吸引力。

“数据仓库”这一术语可能主要指的是商业智能结构化数据的受管理的多域存储。但是，底层数据平台将继续发展，为基于云的人工智能管道提供核心数据治理基础。

AI而非BI正在推动企业数据仓库的发展。

作者：EMR

“数据湖三剑客”Hudi、Delta Lake和Iceberg 深度对比

数据管理和分析趋势正在改变世界

现在的数据世界正在发生什么，它将如何影响2018年的市场?比如这些头条新闻:人工智能无处不在，并将改变一切企业继续将他们的基础设施和数据转移到云端GDPR将使数据保护成为每个公司的首要任务。你知道这些，但也许会对这种夸大其词的说法有点怀疑。

那么到底发生了什么实质性的变化?在制定架构和采购策略并在这些领域做出决策时，你需要注意什么?接下来我们会讨论在分析领域发生的7个影响深远的变化，并将它们一一呈现。

Hadoop始终是根基

是的，那些大数据项目的失败率很高；并且Spark在某种程度上已经取代了Hadoop，越来越多的客户开始独立运行它，所以业界开始指责Hadoop…并且不再提到它的名字。所以你认为Hadoop一定已经过时了，对吧?

错!现在每个人都在谈论数据湖，很多时候，那只是Hadoop的代码。而且，虽然许多公司正在云存储中实现他们的数据湖，也经常使用Hadoop生态系统技术来分析这些数据。除此之外，当开始使用云存储来模拟HDFS、Hadoop的文件系统时，你就会意识到云数据湖和Hadoop数据湖并没有本质区别。

好消息是，今年Hadoop将会做它一直应该做的事情:低调地被很多企业接受，并将成为众多数据工具之一，发挥其战略作用。正是这些数据技术的结合，包括Hadoop、Spark、Business Intelligence (BI)和数据仓库，使得当前的分析市场如此令人兴奋。

再见！企业级商业智能栈

今年早些时候，作为一家企业级商业智能公司，MicroStrategy宣布向其前端竞争对手做出让步，引入他们的产品。MicroStrategy相信可以通过利用后端OLAP平台以及相关的数据处理来盈利。该公司似乎意识到了在数据可视化和仪表板方面的竞争是比较困难的，即使能够取得成功，也会带来收益递减。

那么后端是否足以维持企业收入并持续增长？我们拭目以待。但有一点是肯定的，单一的企业级商业智能堆栈已经开始解体，新的挑战即将开始。

数据分层

也许你熟悉数据分层的概念，比如数据存储与其访问频率的相关性。“热门”数据，即最常用的数据，有时访问请求会被路由到非常快的存储，比如固态硬盘，甚至是CPU缓存中；而冷门数据通常存储在更老的，但更便宜的旋转硬盘驱动器之中。

随着存储层次的完善，我们将在今年看到其他层次结构被逐渐认可。例如，分析涉及从与特定团队或业务单位相关的实验数据集到对整个企业都有用的高度结构化，审核和共识驱动的数据。 中间是结构化数据集，可能由于大小或清洁程度而被视为略低于生产水平。

实验数据集存储在数据湖中最好；逻辑上，高度审查的数据集最好存储在数据仓库中。中级数据集可能比较适合放在Hadoop或云存储中，但通常会使用IBM Big SQL，Microsoft Polybase和Oracle Big Data SQL等SQL-on-Hadoop工具从关系型数据库中进行查询。

还有一种层次结构可能会根据数据是用于设计机器学习模型还是仅用于分析来对数据进行分层，其他的层次结构可能由数据源的可信度来定义。

层次结构之所以重要，是因为相应的工具和技术也存在分级，包括查询端的商业智能和大数据分析工具，以及存储库端的事务型数据库，NoSQL数据库，数据仓库和数据湖。虽然最终，层次结构可能会得到简化，技术可能会趋于整合，但是现在有了这么多的技术选择，我们就需要数据中的层次结构来规定我们在工具链部署中的最佳实践。

可视化商品

MicroStrategy宣布与Tableau，Qlik和Power BI进行合作不仅仅是对竞争对手的让步。事实上，这三种自助商业智能工具现在已经成为行业标准，进一步为其他想在可视化领域大显身手的公司设置了障碍。

他们也对整个行业实现了商品化。在Tableau Public，Qlik Sense Cloud Basic和Power BI Desktop（以及Power BI云服务的免费层）之间，可以免费体验入门级分析功能，随着添加像plotly这样的可视化工具，体验D3生态系统和开源的地理空间/地图平台，你会发现你的分析能力从受时间限制变成了受金钱限制，你需要通过付费来获得更好的产品功能。

如今，用户已经将良好的数据处理能力看作理所当然，他们虽然对此印象深刻，但并不满足于此，好的产品不会具有很明显的竞争优势，但差的产品必然处于竞争劣势。

数据治理

虽然在过去的一段时间里，数据治理技术并未受到应有的重视，但如今也开始获得了一些尊重。欧盟的“通用数据保护条例”（GDPR）就是一个例子-而最终，缺乏足够的治理是今年对有效治理工具需求的一个非常重要的痛点。

即使遵循法规是催化剂，但治理背后还有其他驱动因素。其中最大的一项是数据分类，它们使数据湖中的数据集更有条理，并且更易于发现。数据发现工具可以帮助您通过查看数据库和数据湖，报告其数据内部和数据之间的关系和数据流。从另一个角度来讲，这些工具使数据湖本身更具有可用性，对其投资更加有效。随着公司对前几年投资寻求更好的回报，数据分类和发现工具将越来越受欢迎，进一步推动了治理技术的发展。

云数据湖 = 云数据锁定

我们已经谈到了基于云存储的数据湖的发展趋势。但事实是，这不是一个随机出现的有趣的上云案例，这是主要云供应商的中心卖点和销售策略。

在特定的云平台上，你存储的数据越多，你就会在这个平台上针对这些数据做更多的工作，包括但不限于数据准备，分析，预测建模和模型训练(在高端的gpu加速虚拟机上)。云之战是数据存储之战，赢家可能会让你深陷其中。

容器革命

大家都知道，基于Docker的容器技术在数据中心和软件开发领域正在改变一切。这种变革影响巨大且不容小觑。

但是您是否知道数据和分析世界中也在发生着类似的变化？这很难说，因为尽管这种转变不太明显，但它是真实发生的：

MapR已经通过其PACC（持久应用客户端容器）重新定位了融合数据平台

云提供商利用容器技术更快地部署节点，并促进更多资源共享 - 从而使临时集群看起来更持久

Hadoop最近刚刚发布了3.0版本，它很快就会支持在Docker容器中运行YARN资源管理器，从而使Hadoop作业代码的依赖项可以根据集群中每个节点上安装的代码而不同。

越来越清楚的是，每个软件供应商，其产品都依赖于其他软件的基础版本，都逐渐意识到容器可以消除版本冲突问题 - 为他们和他们的客户。

下一步，做决定

对大趋势进行识别和预测是非常有趣的。那些行业中发生的具体而突出的变化，以及供应商和客户追求的策略，可以帮助您制定自己的发展计划，他们为您的决定提供了依据：你今年要做什么，你不会做什么，以及你合理期待的结果。对于像数据分析这样的创新热点，您需要不断规划您的方案并进行大笔投注，但您也需要采取一定的保障措施。我们希望并相信这七个趋势分析可以帮助您做到这两点。

一个热爱生活又放荡不羁的程序猿

本文主要讲解如下内容：

一、数据湖的优点

二、目前有哪些开源数据湖组件

三、三大数据湖组件对比

数据湖相比传统数仓而言，最明显的便是优秀的T+0能力，这个解决了Hadoop时代数据分析的顽疾。传统的数据处理流程从数据入库到数据处理通常需要一个较长的环节、涉及许多复杂的逻辑来保证数据的一致性，由于架构的复杂性使得整个流水线具有明显的延迟。

目前开源的数据湖有江湖人称“数据湖三剑客”的 Hudi、Delta Lake和Iceberg

Iceberg官网定义：Iceberg是一个通用的表格式（数据组织格式），提供高性能的读写和元数据管理功能。

Iceberg 的 ACID 能力可以简化整个流水线的设计，传统 Hive/Spark 在修正数据时需要将数据读取出来，修改后再写入，有极大的修正成本。

[玫瑰]ACID能力，无缝贴合流批一体数据存储

随着flink等技术的不断发展，流批一体生态不断完善，但在流批一体数据存储方面一直是个空白，直到Iceberg等数据湖技术的出现，这片空白被慢慢填补。

Iceberg 提供 ACID 事务能力，上游数据写入即可见，不影响当前数据处理任务，这大大简化了 ETL；

Iceberg 提供了 upsert、merge into 能力，可以极大地缩小数据入库延迟；

[玫瑰]统一数据存储，无缝衔接计算引擎和数据存储

Iceberg提供了基于流式的增量计算模型和基于批处理的全量表计算模型。批处理和流任务可以使用相同的存储模型，数据不再孤立；

Iceberg 支持隐藏分区和分区进化，方便业务进行数据分区策略更新。

Iceberg屏蔽了底层数据存储格式的差异，提供对于Parquet，ORC和Avro格式的支持。将上层引擎的能力传导到下层的存储格式。

[玫瑰]开放架构设计，开发维护成本相对可控

Iceberg 的架构和实现并未绑定于某一特定引擎，它实现了通用的数据组织格式，利用此格式可以方便地与不同引擎对接，目前 Iceberg 支持的计算引擎有 Spark、Flink、Presto 以及 Hive。

相比于 Hudi、Delta Lake，Iceberg 的架构实现更为优雅，同时对于数据格式、类型系统有完备的定义和可进化的设计；

面向对象存储的优化。Iceberg 在数据组织方式上充分考虑了对象存储的特性，避免耗时的 listing 和 rename 操作，使其在基于对象存储的数据湖架构适配上更有优势。

[玫瑰]增量数据读取，实时计算的一把利剑

Iceberg 支持通过流式方式读取增量数据，支持 Structed Streaming 以及 Flink table Source。

Apache Hudi是一种数据湖的存储格式，在Hadoop文件系统之上提供了更新数据和删除数据的能力以及消费变化数据的能力。

Hudi支持如下两种表类型：

使用Parquet格式存储数据。Copy On Write表的更新操作需要通过重写实现。

使用列式文件格式（Parquet）和行式文件格式（Avro）混合的方式来存储数据。Merge On Read使用列式格式存放base数据，同时使用行式格式存放增量数据。最新写入的增量数据存放至行式文件中，根据可配置的策略执行COMPACTION操作合并增量数据至列式文件中。

应用场景

Hudi支持插入、更新和删除数据。可以实时消费消息队列（Kafka）和日志服务SLS等日志数据至Hudi中，同时也支持实时同步数据库Binlog产生的变更数据。

Hudi优化了数据写入过程中产生的小文件。因此，相比其他传统的文件格式，Hudi对HDFS文件系统更加的友好。

Hudi支持多种数据分析引擎，包括Hive、Spark、Presto和Impala。Hudi作为一种文件格式，不需要依赖额外的服务进程，在使用上也更加的轻量化。

Hudi支持Incremental Query查询类型，可以通过Spark Streaming查询给定COMMIT后发生变更的数据。Hudi提供了一种消费HDFS变化数据的能力，可以用来优化现有的系统架构。

Delta Lake是Spark计算框架和存储系统之间带有Schema信息数据的存储中间层。它给Spark带来了三个最主要的功能：

第一，Delta Lake使得Spark能支持数据更新和删除功能；

第二，Delta Lake使得Spark能支持事务；

第三，支持数据版本管理，运行用户查询 历史 数据快照。

核心特性

Delta lake

由于Apache Spark在商业化上取得巨 成功，所以由其背后商业公司Databricks推出的Delta lake也显得格外亮眼。在没有delta数据湖之前，Databricks的客户 般会采 经典的lambda架构来构建他们的流批处理场景。

Hudi

Apache Hudi是由Uber的 程师为满 其内部数据分析的需求 设计的数据湖项 ，它提供的fast upsert/delete以及compaction等功能可以说是精准命中 民群众的痛点，加上项 各成员积极地社区建设，包括技术细节分享、国内社区推 等等，也在逐步地吸引潜在 户的 光。

Iceberg

Netflix的数据湖原先是借助Hive来构建，但发现Hive在设计上的诸多缺陷之后，开始转为 研Iceberg，并最终演化成Apache下 个 度抽象通 的开源数据湖 案。

三者均为Data Lake的数据存储中间层，其数据管理的功能均是基于 系列的meta 件。meta 件的 类似于数据库的catalog，起到schema管理、事务管理和数据管理的功能。与数据库不同的是，这些meta 件是与数据 件 起存放在存储引擎中的， 户可以直接看到。这个做法直接继承了 数据分析中数据对 户可见的传统，但是 形中也增加了数据被不 破坏的风险。 旦删了meta 录，表就被破坏了，恢复难度很 。

meta包含有表的schema信息。因此系统可以 掌握schema的变动，提供schema演化的 持。meta 件也有transaction log的功能（需要 件系统有原 性和 致性的 持）。所有对表的变更都会 成 份新的meta 件，于是系统就有了ACID和多版本的 持，同时可以提供访问 历史 的功能。在这些 ，三者是相同的。

Hudi 的设计 标正如其名，Hadoop Upserts Deletes and Incrementals（原为 Hadoop Upserts anD Incrementals），强调了其主要 持Upserts、Deletes 和 Incremental 数据处理，其主要提供的写 具是 Spark HudiDataSource API 和 提供的 HoodieDeltaStreamer，均 持三种数据写 式：UPSERT，INSERT 和 BULK_INSERT。其对 Delete 的 持也是通过写 时指定 定的选项 持的，并不 持纯粹的 delete 接 。

在查询 ，Hudi 持 Hive、Spark、Presto。

在性能 ，Hudi 设计了 HoodieKey ， 个类似于主键的东西。对于查询性能， 般需求是根据查询谓词 成过滤条件下推 datasource。Hudi 这 没怎么做 作，其性能完全基于引擎 带的谓词下推和 partition prune 功能。

Hudi 的另 特 是 持 Copy On Write 和 Merge On Read。前者在写 时做数据的 merge，写 性能略差，但是读性能更 些。后者读的时候做 merge，读性能差，但是写 数据会 较及时，因 后者可以提供近实时的数据分析能 。最后，Hudi 提供了 个名为run_sync_tool 的脚本同步数据的 schema 到 Hive 表。Hudi 还提供了 个命令 具 于管理 Hudi 表。

Iceberg 没有类似的 HoodieKey 设计，其不强调主键。没有主键，做 update/delete/merge 等操作就要通过 Join 来实现， Join 需要有 个类似 SQL 的执 引擎。

Iceberg 在查询性能 做了 量的 作。值得 提的是它的 hidden partition 功能。Hidden partition 意思是说，对于 户输 的数据， 户可以选取其中某些列做适当的变换（Transform）形成 个新的列作为 partition 列。这个 partition 列仅仅为了将数据进 分区，并不直接体现在表的 schema中。

Delta 的定位是流批 体的， 持 update/delete/merge，spark 的所有数据写 式，包括基于dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是 持的。

不强调主键，因此其 update/delete/merge 的实现均是基于 spark 的 join 功能。在数据写 ，Delta 与 Spark 是强绑定的，这 点 Hudi 是不同的：Hudi 的数据写 不绑定 Spark。

在查询 ，Delta 前 持 Spark 与 Presto，但是，Spark 是不可或缺的，因为 delta log 的处理需要 到 Spark。这意味着如果要 Presto 查询 Delta，查询时还要跑 个 Spark 作业。更为难受的是，Presto 查询是基于 SymlinkTextInputFormat 。在查询之前，要运 Spark 作业 成这么个 Symlink 件。如果表数据是实时更新的，意味着每次在查询之前先要跑 个 SparkSQL，再跑 Presto。为此，EMR 在这 做了改进可以不必事先启动 个 Spark 任务。

在查询性能 ，开源的 Delta 乎没有任何优化。

Delta 在数据 merge 性能不如 Hudi，在查询 性能不如 Iceberg，是不是意味着 Delta 是处了呢？其实不然。Delta 的 优点就是与 Spark 的整合能 ，尤其是其流批 体的设计，配合 multi-hop 的 data pipeline，可以 持分析、Machine learning、CDC 等多种场景。使 灵活、场景 持完善是它相 Hudi 和 Iceberg 的最 优点。另外，Delta 号称是 Lambda 架构、Kappa 架构的改进版， 需关 流批， 需关 架构。这 点上 Hudi 和 Iceberg 是 所不及的。

三个引擎的初衷场景并不完全相同，Hudi 为了 incremental 的 upserts，Iceberg 定位于 性能的分析与可靠的数据管理，Delta 定位于流批 体的数据处理。这种场景的不同也造成了三者在设计上的差别。尤其是 Hudi，其设计与另外两个相 差别更为明显。

Delta、Hudi、Iceberg三个开源项 中，Delta和Hudi跟Spark的代码深度绑定，尤其是写 路径。这两个项 设计之初，都基本上把Spark作为他们的默认计算引擎了。 Apache Iceberg的 向 常坚定，宗旨就是要做 个通 化设计的Table Format。

Iceberg完美的解耦了计算引擎和底下的存储系统，便于多样化计算引擎和 件格式，很好的完成了数据湖架构中的Table Format这 层的实现，因此也更容易成为Table Format层的开源事实标准。另 ，Apache Iceberg也在朝着流批 体的数据存储层发展，manifest和snapshot的设计，有效地隔离不同transaction的变更， 常 便批处理和增量计算。并且，Apache Flink已经是 个流批 体的计算引擎， 者都可以完美匹配，合 打造流批 体的数据湖架构。

Apache Iceberg这个项 背后的社区资源 常丰富。在国外，Netflix、Apple、linkedin、Adobe等公司都有PB级别的 产数据运 在Apache Iceberg上；在国内，腾讯这样的巨头也有 常庞 的数据跑在Apache Iceberg之上，最 的业务每天有 T的增量数据写 。

以上就是关于估值380亿美元的数据湖引领者，Databricks是如何发展壮大的？全部的内容，如果了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！