的兴起
Lakehouse范式

Databricks联合创始人兼首席执行官Ali Ghodsi在本次主题演讲中讨论了为什么数据仓库和数据湖不是为今天的用例设计的，以及湖屋如何在这些技术的基础上更好地释放数据的潜力。
在本主题摘要中，您将了解为什么数据仓库不适合现代数据管理，例如GDPR和CCPA要求、音频和视频数据集以及实时操作，并了解如何在任何规模的数据集上构建优化的可靠性、质量和性能的策划数据湖。

想看而不是读?访问Lakehouse范式主题演讲视频的崛起在这里．

简介

大家好，我是阿里·高德西，Databricks的联合创始人兼首席执行官。我今天要讲的是湖边小屋。我知道这有点陈词滥调，但我将以这句名言开始，因为我认为在数据管理行业，我们一直在建造越来越快的马，但实际上这里有一个未来的引擎。有一个平台来做所有的数据分析，所有的数据科学和所有的机器学习，这是一个没有兑现的承诺。bob体育客户端下载这就是我今天要讲的内容。

数据管理历史

让我们从它的历史开始。这一切都始于八十年代。商业领袖们眼看就要瞎了。他们不知道自己的生意做得如何。我们提出了一个数据仓库的范例。它的工作方式是让我们把所有在我们的运营数据存储中的数据，oracle和mysql，让我们用ETL工具把它全部ETL到一个中心位置，并把它放在干净，严格的模式和格式中。然后我们就可以开始商业智能和报告了。然后商业领袖就会知道他们的组织是如何运作的。

这太棒了。这是很棒的技术。它已经存在了几十年了。但随着时间的推移，出现了新的需求和新的数据集，对数据仓库提出了挑战。

一个我们看到越来越多的视频和音频数据集，组织正在收集这些数据，而数据仓库无法存储这些数据。

也在美国，大多数组织现在都希望使用机器学习、数据科学、人工智能来进行预测。通常在这些数据集上，他们拥有的视频和音频数据，或者他们拥有的文本数据，以及数据仓库都没有内置预测功能。如果你想要实时做一些事情，如果你想要实时流支持，它们也非常困难，这不是它们的目的，因为它们要求你首先将数据ETL到一个位置。

最后，数据仓库是封闭的专有系统。你把数据移进去，数据就会被锁在里面。因此，大多数组织开始将所有数据存储在blob存储之上的巨大数据湖中。有了数据湖，你就可以处理各种各样的数据。你可以存储数据来做数据科学，机器学习。你可以有视频，音频，你所有的数据都可以存储在那里。事实上，我们所知道的每个组织都有一个数据湖，用来存储他们的数据。

但这些数据湖本身也有很多挑战。事实上，在数据湖上，您无法进行BI。因此，在数据湖之上高效、轻松地运行商业智能工具是不可能的。设置起来很复杂，通常你的性能很差因为你只是把数据扔在那里，所以你得到了一个不可靠的数据沼泽，你有这么多数据，但很难从中得到意义。

因此，许多组织最终实际上拥有一个共存的数据湖，在那里他们拥有数据科学的所有数据，然后这些数据的子集被转移到一个数据仓库中，在那里它有模式，它实际上可以被BI和报告使用。但是这种共存并不是一个理想的策略，因为现在您有两个数据副本。如果您在数据仓库或数据湖中修改数据，则很难使另一个保持一致。为商业领袖制作仪表板的BI工具通常有过时的数据，因为最新的数据实际上在数据湖中。最后，你会有一个非常复杂、昂贵的系统，你首先要把数据ETLing到数据湖，然后再ETLing到数据仓库。所以它实际上是相当混乱的，在某些方面它后退了很多步。

在Databricks，我们坚信将所有这些用例合并到一个地方是可能的。我们称之为莱克豪斯范式。我今天会详细讲一下。那么这是如何工作的呢?Lakehouse范例建立在数据湖的基础上。所以它从底层开始，将所有数据存储在数据湖中。数据湖很棒，因为它们非常便宜，它们是耐用的存储，它们有10个9的持久性，所以99.9999，它们很便宜，而且可以扩展。它们还能存储各种数据。原始数据，视频数据，音频数据，结构化的，非结构化的。最后，它们基于开放标准格式，通常是拼花格式或ORC格式。在数据湖上，有一个很大的工具生态系统在这些格式的基础上运行。这就是数据湖兴起的原因。

数据湖的挑战

但是在Databricks，在过去的十年里，我们发现数据湖也存在很多问题，而且它们是不够的。接下来我要做的是，我要带你们看看我们看到的人们在使用数据湖时遇到的九个最常见的问题。我将向你们解释一些他们用来解决这个问题的技巧。

让我们从最常见的问题开始。

一个．最常见的问题是很难将新数据添加到数据湖中。特别是，如果向数据湖添加新数据，很难同时读取数据并获得一致的结果。这是因为底层的blob存储系统并不是为了保持一致而构建的。它们不是文件系统。组织通常试图解决这个问题的方法是制作大量的数据副本。因此，他们会在一个名为登台的目录中有一个副本，当它准备就绪时，另一个副本称为生产，他们试图修复这个问题。但这并不是进行数据管理的好方法。

两个，我们发现组织在实际修改数据湖上的现有数据时非常困难，因为数据湖是使用像Spark这样的批处理系统构建的。随着GDPR和CCPA的出现，这种情况变得尤其糟糕，这要求我们对数据进行细粒度操作。细粒度操作可能涉及删除特定用户的记录，因为他们不想在数据系统中再保留任何关于该用户的记录。许多组织解决这个问题的方法是每周运行一次批处理作业，重写数据湖中的所有数据，并将其清理以符合要求。这是非常昂贵的，延迟是非常非常糟糕的。

三个通常情况下，工作失败，什么都没有被注意到，部分数据进入数据湖，其他部分丢失，但最糟糕的是你不知道它。多年以后，当您试图在数据湖上运行应用程序时，它失败了，经过大量调试后，您会发现一些作业在几年前失败了，数据湖中只有一半的数据。

四个在美国，很难进行实时操作。这确实是第一个的特例，但基本上添加数据并追加数据，然后实时读取数据，很难以一致的方式完成。使用两个目录的老技巧在这里并不适用，因为您正在实时读取它。

五个在美国，保存数据的历史版本成本非常高，尤其是在受监管的行业。您需要可再现性审计和治理，但对于数据湖和基于批处理的系统来说，这真的很难做到。人们所做的就是将所有这些数据复制很多份，并在目录上写上不同的日期，希望他们可以跟踪所有这些不同的数据，并且没有人编辑以前的目录。但这是非常非常昂贵和耗时的。

六个．这些数据湖随着它们的增长变得相当大，它们的元数据本身也变得相当大。处理元数据是非常困难的。通常会变慢或者系统崩溃。

七个在美国，数据湖实际上是一种文件抽象。因此，我们经常会遇到问题，因为我们有数百万个非常小的文件，或者一些非常大的文件。你必须优化它。

八个．因此，我们看到了更多的性能问题。很难对它们进行真正的调整，使它们具有良好的下游性能。

九个．最后，最重要的问题是数据湖的数据质量问题。确保所有的数据都是正确的、高质量的、有正确的模式，并且您的下游实际上可以依赖它，这一直是一个令人头痛的问题。

三角洲湖:湖屋的基础

这就是九个问题。在Databricks，我们相信有办法解决这些问题，我们相信我们开发的开源技术，叫做Delta Lake，可以解决数据湖上的这些问题。bob下载地址

通过Delta Lake，您可以为数据湖添加可靠性、质量和性能。它将最好的数据仓库和数据湖结合在一起。它基于开源格式和开源系统，所以你不需要担心bob下载地址将你的系统锁定到某个专有系统。

简而言之，我们相信这是建造湖屋的新标准。我们来看看这9个问题，看看Delta如何解决它们。

事实证明，前五个问题实际上可以通过使用一种叫做ACID事务这在数据管理系统中已经存在了几十年。因此，资产事务的工作方式是，它们确保每个操作要么完全成功，要么中止并清除任何残留物。我们实现它的方法是将事务日志放在打开的parquet文件旁边。事实上，事务日志本身是拼字格式的。现在，您可以确保您正在执行的每个操作，无论是流处理、批处理还是追加，都完全成功，或者被清理并中止。

同样，由于我们现在将正在执行的操作的每个Delta存储在事务日志中，我们现在实际上可以实现称为时间旅行的东西。这意味着我们可以查看过去的交易。正如您从示例中看到的，您可以提交SQL查询，然后添加到它的时间戳，然后它返回数据结果，就像您在指定时间戳时提交了查询一样。

这很好。现在我们可以解决所有这些问题。我们有一致的读取、追加、流、作业失败和时间旅行。最重要的是，我们现在可以做UPSERTS了。这意味着我们可以以细粒度的方式插入、删除和更新记录，正如您从示例中看到的那样。我们可以删除一条记录，它会存储在事务日志中，而不需要运行一个大的批处理作业。

这很好。这就是ACID事务。我们如何处理剩下的问题?

对于元数据，我们实际上是可以重用的Apache火花．Apache Spark已经是一个高度可扩展的系统，可以处理pb级的数据。因此，对于底层的所有元数据操作，我们使用Apache Spark。如果元数据最终非常小，我们实际上有一个单节点实现，它会非常非常快。如果它很大，我们可以无限扩大。

我们如何处理性能问题?在那里，我们实际上采用了我们在过去的文献中可以找到的所有索引技术，我们专门为数据湖实现了它们。因此，我们实现了在数据湖上自动发生的分区。我们实现了一种叫做数据不，它存储统计数据，并在执行查询之前删除数据，这样如果查询只涉及数据的某些部分，就不必读取所有数据集。我们添加了z值，这是一种可以同时索引多个列的方法。但与索引不同的是，访问任何列都同样快。您可以在这里看到示例，它实际上是多么容易添加到您的数据集。太棒了，这给我们留下了最后一个问题。

我们如何从数据中获得高质量?在这里，我们为所有的Delta添加了严格的模式验证和进化。这意味着Delta表中的所有数据都必须遵循严格的模式。星星图案，雪花图案，随便你。它还包括模式演变和合并操作。但这意味着无论何时数据进入Delta，它总是满足该模式。如果没有，我们就把它转移到隔离区，在那里你可以查看它，你可以清理它，所以它可以回来，但这意味着当你使用那张桌子时，你可以确保它总是干净的。

在模式验证和进化的基础上，我们还添加了Delta Expectations。这是一种非常强大的方法，您可以在SQL中表达您喜欢的任何质量度量。你可以组合列，你可以指定任何你想要的，你可以说你想要特定的表满足所有这些品质。这将确保在任何给定的时间，您的表都是原始的，并具有所需的期望。有了这个，我们的客户正在建立我们所谓的策划数据湖。它的工作方式是，按照惯例，他们首先将所有可能不干净的原始数据存储在数据湖中。我们把那些叫做青铜桌。但随后他们对其进行了改进和清理，并有了更多的模式，并创建了过滤、清理和增强得多的银表。然后是最后一个级别，黄金弹性级别，我们有黄金表，我们可能会增加业务级别的总量和额外的预期，以确保下游消费真的很好。这就是我们建立数据湖的方式。

为了缩小和总结，我们已经解决了我们在数据湖、资产交易、使用Spark扩展、索引以使其更快、以及模式验证和期望以真正提高数据湖的质量方面看到的九个问题。

在底部，我们有数据湖。在此之上，我们将事务层分层，现在我们实际上可以从数据中获得质量和可靠性。但是我们如何真正地支持我们想要做的所有用例呢?为此，我们在Databricks建立了一个叫做Delta Engine的东西。这是一个高性能的查询引擎，我要稍微讲一下。这个引擎与Spark 3.0的API完全兼容，所以它支持Spark的所有API，但它是用c++从头构建的，为Delta做向量化和自定义构建，以非常非常快的速度处理你的数据湖中的Delta格式的数据。它带有一个经过高度改进的优化器，可以进行基于成本的优化。我们还为ssd和内存内置了缓存，这样我们就可以真正地加快速度，从而可以掩盖数据湖的延迟和性能。

这就是Delta引擎，但是它的性能如何呢?当你把它们放在一起时，我们看到了什么?为此，我们运行了称为TPC-DS的行业标准基准测试。我们把它作为一个相当大的规模因子运行，30tb。我们在没有Delta引擎的情况下运行Delta，在有Delta引擎的情况下运行我们看到性能提升了3.3倍。这太棒了。所以你可以用它得到最先进的性能。现在，当你把它们放在一起，你就有了一个数据湖。

有了结构化事务层Delta Lake，有了高性能查询引擎Delta Engine，现在可以在Lakehouse中支持所有这些不同的用例。

结论

你可以在一个地方完成BI、报告、数据科学和机器学习。如今，Databricks拥有6000多名客户。他们中的大多数人使用德尔塔引擎和德尔塔湖建造了湖屋。我最喜欢的一些是在医疗保健行业，像Regeneron这样的公司实际上能够找到慢性肝病的治疗方法，建立了一个带有基因组数据的Lakehouse，并用机器学习来找到导致这种疾病的基因组。像康卡斯特这样的客户，在大众媒体中，能够建立一个语音控制的遥控器，实际上可以获取你所有的数据，把它放在Lakehouse，并使用机器学习来实时解释你的命令，让你操作它。还有很多其他类似的例子，我们对此感到非常兴奋。

我们相信，通过Delta Lake上的Lakehouse和Databricks的一个数据分析、数据科学和机器学习平台，最终可以实现未实现的承诺。bob体育客户端下载