潜入三角洲湖

视频记录

-所以今天，我们要讨论的是Delta Lake模式的强化和演变。这是我们潜入三角洲湖系列的第二部分我是安德里亚斯·诺伊曼我的搭档是丹尼·李简单介绍一下我自己。我是Databricks的软件工程师。我几乎把我所有的时间都花在了Delta Lake上，以及如何使用Delta构建数据管道。我干这行已经有一段时间了。自2014年以来，我一直在Spark上构建管道，我已经正式做到了这一点，在其他地方，如谷歌Clouds，初创公司Cask Data, Yahoo!还有IBM，我来自德国。这就是为什么我的计算机科学学位也是来自德国的大学，你可能从未听说过。但是，我把它交给Denny做自我介绍。

-谢谢安德里亚斯。大家好，我是Denny Lee。我是Databricks的开发者拥护者。我从零五零六天就开始使用Apache Spark了。在此之前，我是Concur的数据科学工程高级总监，我也是微软的前员工，在西雅图地区工作。老鹰队加油，没错，我喊出来了。因此，作为微软的一员，我参与了cosmos DB团队HDInsight(同位素)，也参与了SQL server团队，有些人是一个长期的数据库人员。这就是为什么Delta like很棒的原因。然后，我在OHSU有一个生物医学信息学硕士学位，我不像Andreas那么有趣。我只有麦吉尔大学的生理学学士学位。 Basically Asian parents was supposed to be a doctor, turned out, that was already a bad idea, so there you go. (Denny Chuckles) – I think that’s very interesting though (laughing). Okay, so– – We have the time my friend (laughing softly). – (laughing) All right, so just a very quick recap last week, we discussed the transaction log of Delta and just in case you missed this, I highly recommend that you catch up on this. The video is on YouTube and, we’ll post the link later on.

概述

让我们回到今天的话题。

我们要讨论的是，数据，是不断发展和变化的。好吧?为什么呢?因为它反映了我们所经历的一切。它反映了我们所拥有的业务问题和业务需求。随着这些变化，我们的数据结构也在变化，对吧?当这种情况发生时，我们希望有可预测性，对吧?我们想要控制这一切的发生。事实证明，三角洲湖让这一切变得很容易。Delta Lake有很好的方法来控制模式的变化，也有很好的方法来实施模式。 So, what exactly is schema enforcement? Enforcement and that’s also often called validation, simply means that it prevents us from accidentally, writing bad data to our table, writing data to our table that is not compatible with its schema or with its structure.

但是当我们想要改变表的模式时，我们可以使用模式进化。这让我们能够以一种非常可控的方式改变模式。

理解表模式

表模式是什么?

表模式描述了数据的结构，对吧?例如，在Apache Spark中，该框架每天都有一个模式。如果您使用Delta Lake作为存储格式，那么该数据的模式就会变成表的模式，并以JSON格式保存在事务日志中。我们上周看过交易日志了，对吧?这个模式是什么样的呢?这是一个字段列表，对吧?每个字段都有一个名称。

哦。

每个字段都有一个类型它还会显示是否为空?如果它是空的，这意味着该字段不必存在。但如果nullable为false，那么写入表的每条记录都必须有这个列或这个字段。

什么是模式强制?

好的。知道了什么是模式，我们来谈谈什么是模式强制。模式强制，也称为模式验证，拒绝任何与表模式不匹配的写操作。这是什么意思呢?它发生在写的时候，任何时候我写，我覆盖，我附加到一个表。应用模式强制。如果我写入的数据模式与表的模式不兼容，Delta Lake就会取消事务，对吧?

这意味着没有数据被写入，这是原子的，对吧?

永远不会有数据被写入的情况。要么完成整个交易，要么取消交易。Delta Lake会抛出异常，你的工作就会失败。这就是不匹配的地方。

现在，模式实施的规则是什么?

模式实施规则

因此，写入表的数据不能包含任何额外的列，对吧?如果表的模式中没有任何列，那么表将不接受该数据。

另一方面，如果我写的数据不包含所有的列，也没关系，对吧?有些列可能会缺失，然后发生的是，在我写的数据中这些列会被赋值为空。这是可以的，但是如果这些列不是可空的就不行了，对吧?很多人可能听说过，让所有字段都为空是一种很好的做法，因为这样可以更灵活地处理写入表的数据。

此外，不能让列的数据类型与表模式中定义的数据类型不同。对，举个例子，如果我的表说，或者这一列的类型是字符串，但我要写入的数据的类型是整数，那么模式强制写入会失败它会抛出一个异常，不会发生写入。

这里另一个非常重要和棘手的情况是，列名不能与表模式仅按大小写不同。这意味着什么呢?比方说，你有一列' Foo '，有一个大写的F，那么你就不能有另一列，其中F是一个小写字母。为什么呢?这里有一点背景知识。这是关于你的作业区分大小写的问题。所以Spark可以做任何一件事。

但是Parquet (Delta Lake的默认存储格式)始终是区分大小写的。因为它想同时处理这两种情况，所以保留大小写。所以它会简单地穿过你给它的盒子。但是当它存储模式时，它不允许您有两个具有相同名称的列，除了大小写。这只是为了防止潜在的错误和防止可能发生在您的数据上的意外情况如果您没有意识到大小写敏感性问题的话。好了，这就是模式强制。

模式强制如何有用?

为什么模式强制是有用的?什么情况下我需要这个，对吧?基本上在任何时候当我运行生产系统的时候它都依赖于它们所读取的数据的固定结构，对吧?例如，机器学习算法。当我训练我的模型时，它期望得到一种确切的数据，如果数据改变了，我甚至不知道这个模型意味着什么。BI仪表板。

几乎所有需要高度结构化和强类型模式的数据分析和可视化工具以及任何生产系统。

因此，为了做到这一点，因为您的数据通常以模式变化的方式到达数据中心或云中，许多人构建了使用“多跳”方法的管道。所以，第一跳就像摄取原始数据一样，下一跳会过滤掉坏数据，下一跳可能会规范化模式，这样到最后，当你有了目标表时，那些表中的所有记录都符合预期的模式。好了，现在我们已经讨论了模式实施，让我们来谈谈进化，对吧?

什么是图式进化?

模式强制是一种允许我们修正数据模式的方法。模式进化允许我们，以一种非常可控的方式改变数据的模式。好吧?因此，它允许您更改表的模式，以适应随着时间变化的数据。好吧?最常见的是，它用于追加和覆盖等操作。为了在Spark和Delta Lake中做到这一点，你使用一个选项，那个选项叫做mergeSchema，你只需要把那个选项添加到你的写语句中。还有一种方法可以通过Spark配置来做到这一点。你将spark. databicks .delta.schema. automerge设置为true。但是，如果您这样做，您必须意识到模式强制将不再适用，对吗?

因此，现在当您开始向具有额外列的表写入数据时，例如，表的模式将会改变。所以你需要知道你在做什么。有了这个选项，mergeSchema为true，我们基本上可以做出读兼容的模式改变。读兼容是什么意思?这意味着仍然可以根据新的模式读取表中的现有数据。对吧?因此，当我们追加或覆盖表时，我们这样做，这里有以下类型的更改。所以我们可以添加新的列，对吧?而表中已经存在的旧数据，这些列将为空。我们可以将列的类型从非空变为空，对吧? So that’s basically, that’s a relaxation of the existing schema, right? And so the old data will still fit. And we can do upcasts, right? Where we go from smaller type to a bigger type. So, any bytes can be represented as a short or short can be represented as an integer. So the old data can still be read.

还有一种更强的模式进化形式。对于这种形式的进化，您将使用选项“overwriteSchema”。这使得我们可以做一些与现有数据不兼容的模式更改。当我们覆盖数据时通常会这样做，对吧?因为如果我们只添加旧数据，表格就会变得毫无用处。但如果我们覆盖所有数据，那么我们就可以改变模式。那么，我们可以做哪些类型的图式改变呢?例如，我们可以删除一列，或者我们可以改变一列的数据类型?以前是字符串的东西现在可以是整数，这在mergeSchema中是不可能的。我们也可以重命名列。 And even if we just change the case of columns, this is all an hour round, if we do overwrite schema.

再注意一点，在Spark 3.0中，也会有DDL语法允许你改变一个表的模式那将被称为' alter table '语句。

这部分的介绍到此结束，接下来我将进行一个演示。

这是哪个屏幕。好了，现在每个人都能看到我的笔记本了。我将用这个笔记本来演示，模式实施和模式进化是如何工作的。我想说你们可以自己试试。所有这些小样，不好意思。所以这些都可以为你提供。您可以尝试在Databricks中自己的集群中运行这些笔记本。如果您没有Databricks帐户，可以使用Databricks社区版。对吧?所有这些都将在这次网络研讨会后公布。 The data that we’re using here, is actually public data and it’s from a website called ‘Lending Club’. And it basically describes loans that were funded during a certain time.

好的，这是对三角洲湖的一个快速介绍，我不会把这些都讲一遍。在这次演讲中，有两件事对我们很重要，一是ACID交易。所以我们知道权利要么通过要么失效。这样我们的数据就永远是完整的。这里真正重要的部分是模式实施和模式演变。我们还将稍微看一下表的历史并做一点时间旅行，只是在不同的时间玩玩模式。

首先，我们要展示如果没有德尔塔湖，这是什么样子。因此，Delta Lake使用拼花文件作为默认存储格式。我们来看看拼花的数据。我们要做的第一件事，就是下载这些数据。数据现在在这里，它在这个特定的位置，它被下载到这个位置，这就是我们现在要处理的数据。我要做的第一件事就是做一些设置，导入一些东西，设置一些选项，并为这个实验创建一个工作目录。好的，这已经发生了。我现在要做的是做一张拼花桌。对吧?我创建这个的方式是读取这个数据，这意味着它已经下载了，我不会对它做太多操作。 I’m just gonna write it, write it back using parquet format. And then we’re gonna create a view over this data and this view will allow us to run SQL queries over that data.

这个没有在运行，这个运行得很快。如果我们现在看这个表格，让我们看看这里的前20条记录。我们可以看到这个表有一个模式，对吧?这里的每一行都有一个贷款ID。它有一个资助金额，它们似乎都是1000。然后是支付金额。这是偿还的金额。然后还有美国，贷款的资金来源。这看起来很统一，数据也很好。

让我们看看这个表中有多少条记录。因此，我们使用一个简单的SQL计数查询来完成此操作。这很快，14705。好的，这是这个数据集中记录的数量，现在，我们想要这个表我们想要向它添加更多的数据，对吧?为了做到这一点，我们会运行一个流查询。我们要做结构化流媒体。这个流永远不会运行它会生成随机数据其中也有贷款id和贷款金额。好吧?这里，我定义了几个效用函数。这是随机生成的状态。

这里的主要方法是这个，对吧?它所做的就是使用Spark格式“rate”。rate所做的就是生成行。每秒钟它生成，我想在这里，它生成5行。每一行都有一个时间戳和值，然后我们可以用这些东西来创建新的列，对吧?所以这里我们把这个值加上10,000，然后我们有一个新的贷款ID。等等。因此，我们基本上生成了这四列它们在我们在上面看到的表的模式中。好的，这看起来是相同的数据，相同类型的数据。然后我们开始一个简单的查询，作为一个流查询，每10秒就会向表中写入数据。 All right, so, and I’m also defining a utility to stop my streams when I’m done with them. All right, so let’s run this query. Right? So this should null, every 10 seconds, it should add some data. Let’s look at this query. It’s running, it’s still initializing it seems, but pretty soon we should be seeing some change here. Okay, so now it’s processing data. We can see that here. And so let’s look at this table, let’s count the number of records in the table. Okay, so it looks like it has written some data and it should actually be adding more and more data. Yeah, we see that the number of records in this table is steadily going up. So it looks like this streaming query is working, and it does what it’s supposed to do. But wait, we had 14,705 rows in this table, and where did those go? I suddenly only have 145. This is weird.

让我们再看一遍这些数据。让我们来看看。让我们来看一些记录。好的。哦，是的，我发现我的数据不一样。该数据具有不同的模式。它有两个额外的列。它有一个时间戳和一个值。好的，那么这些是从哪里来的呢?

这有点让人困惑，但我们来看看。好吧，让我们再看一遍这段代码。如果我们仔细看，我们会发现它使用了这种叫做" rate "的格式它创建了这两列。当我们说withColumn时，我们会向那个路径添加更多的列。我们从不删除这两列，这就是为什么我们现在有了一个有两个额外列的模式。

好的，有了这个，我们现在在表中有两种数据。我们有一些数据有四列，一些数据有六列，在Parquet文件格式中，会发生什么以及Spark将如何读取这些数据是非常不可预测的。结果是这会导致数据丢失，因为Spark会忽略表中的一些文件。这并不是很有效。现在我想向你们展示Delta Lake如何保护我们不受这种情况的影响在这种情况下，我们会在不知不觉中丢失数据。

好的，我们要做一个和Parquet非常相似的设置，但这次我们要用Delta，对吧?我们再次读取我们下载的这个文件，但现在我们以delta格式写入它，并将它写入不同的路径。再一次，我们创建了一个临时视图以便我们可以用SQL查询。

那么，让我们再看一遍这些数据。它有14705行。这正是我们所期望的。如果我们看一些记录，是的，它们看起来和我们做拼花的时候一模一样。因此，让我们快速深入了解Delta Lake如何存储模式。让我们看一下表示这个表的目录中实际存在的文件。

这里我们有一个Parquet文件，这是写好的。但是我们还有一个额外的目录，那就是Delta日志，Delta日志包含了Delta的事务日志。让我们看看这里的文件。这里应该包含" commit "因为我们只对它运行了一个小批处理作业，所以只有一个提交，该提交由这个JSON文件表示。让我们看看这个JSON文件，它是什么样的?这是非常复杂的JSON。让我们以另一种方式来看待它，因为Spark有一种方法将其读取为JSON。现在我们可以看到它的结构了。我们可以看到这是一个嵌套非常丰富的JSON结构。 It has an ‘adds’ field, which says what information was added in this commit. It has a general commit info, and it also has metadata and the protocol. So let’s look at these things in detail. The first one we’re looking at, is the ‘commit’ information.

所以这个" commit "

显然它是写在这个ID的集群上的。

我们可以看到隔离级别，我们可以看到我们所在的笔记本的ID。如果你看这里的标题，你可以看到，这确实是我笔记本的ID。我们可以看到时间戳，我们可以看到我的用户ID和电子邮件地址。这很酷。这给了我们很多信息。现在让我们看看在这个“提交”中添加了什么信息，添加了什么数据。我们在这里看到的是，有数据变化，有一个修改时间戳。我们还有一个路径，这个路径与我们在上面的目录列表中看到的相匹配，对吧?这就是这个路径，它属于这个提交。

我们看到了一些数据，对吧?统计数据帮助优化查询。我们看到所有四列的统计数据都存在，对吧?贷款ID，资助金额，支付金额和国家。现在，让我们看看元数据。元数据是非常有趣的。如果我们看一下这个，我们会看到它有一个创建时间，它有文件的格式，但最重要的是，它有schemaString。这是Parquet或Avro schemaString，它精确地描述了表格中的字段?这里有贷款ID，有资助金额，有支付金额，还有国家。好了，现在我们知道Delta在元数据中记录表的模式。

让我们在这个表上运行一个流统计，因为我们接下来要做的是，我们要开始向这个表添加更多的数据。所以运行这个流式计数，会持续地计数这个表，并实时更新这些计数。我们要做的第一件事是，写入数据，就像写入parquet一样。

这和之前调用的函数是一样的，只是现在使用了表格格式的delta。我们在这里看到的是，我们得到了一个分析异常?spark拒绝运行这个查询，它为什么这么做呢?因为表模式不匹配，对吧?它实际上告诉了我们两种模式的区别，对吧?就是这两列。这很好，对吧?我们刚刚看到了模式实施的作用，对吧?它防止我们将不兼容的数据颠倒到模式中。看起来不错。

现在，让我们修复流查询，好吗?现在我们知道我们必须修复这个查询，因为它是不兼容的。我们可以做的一件事是，我们可以简单地添加一个投影，作为查询的最后一条语句，它只选择我们感兴趣的四列，对吧?让我们定义这个，再运行一次，用另外5个查询。现在，随着这个查询的运行，还记得我们在这里开始了这个查询吗，它不断地计算表中有多少条记录。这就是它的状态，我们来看看。

现在应该更新计数了。

哦，好了。现在我们看到表中有更多的记录，计数器实际上在上升，对吧?我们不像拼花那样，从零开始。哦，这个不错，我喜欢。

为了理智起见，我们还运行批处理查询，这也是一个更大的计数?关于Delta的好处是，您可以在同一个表上运行多个并发作业。它们不会相互冲突，它们不会相互妨碍，它们可以流处理和批处理，你可以随心所欲地混合它们。schema强制起作用了，现在我们要停止这个流。我们会尝试做一些图式进化的实验。

在我做这个之前，我想记住，这个表中有多少个提交。这个表中的最后一次提交，在我运行了最后3次之后，是第7次。好的。我们可以看到，如果我们列出，我们可以看到在Delta log中它们实际上是7次提交。好的，我们要记住这个数字7，现在，我们要运行流式计数，来查看实时更新的计数。现在，让我们再次开始这个查询。实际上，他们失败了，对吧?是的，我们看到了这个，对吧?它失败了，让我们再看看实际的错误。这个错误告诉我们模式是不同的，但它也给了我们一个提示。 It says, well, if you want to have schema migration, which is another term for schema evolution, use this option. So let’s try that. Let’s do that and modify our query, to use this option, right? And so here, we’re just modifying this function, to add one option ‘mergeSchema’ equals true. And then we’re gonna try this again.

好了，这个查询正在初始化。它现在正在运行，我们到上面的流媒体计数，看看这里发生了什么。所以我们在数。哦，这个查询失败了。为什么这次失败了呢?哦，它检测到架构更改。因此，它检测到表中有两个额外的列。这很有趣，对吧?因此，当模式发生变化时，我们必须重新启动流查询，因为我们不能在模式运行时动态地更改模式。错误消息实际上告诉我们，“嘿，为什么不尝试重新启动查询呢? This will refresh the schema and then it should work again.” So, let’s try running this counter again.

当我们开始一个新的查询时，它应该可以工作。我们来看看这个。是的，现在它可以计数了，我们应该看到计数在上升。同时，我还要做一个批量查询来看看是否匹配?这里的计数上升了这里的计数也升高了。所以我们看到了图式进化是有效的。当我有matchSchema作为一个选项的时候。我实际上能够随着数据形状的变化而动态地改变模式。好的，在我们看完这个之后，我要再次停止播放。顺便说一下，如果您在Community Edition上运行此程序，请确保始终在笔记本中停止流，否则您可能很快就会耗尽集群中的配额。

好了，在我们讲完这个模式的演变之后，让我们来看看这个表的历史以及它是如何随着模式的变化而变化的。我们再看一遍所有的文件。我们看到现在有一堆新的提交。这里是第7题，这是我开始模式进化之前的最后一次提交。我们看到这里有两分钟的空隙。第8次提交应该是第一个模式改变的提交，对吧?然后从9开始，所有这些提交都必须有新的模式。我们也可以在表历史中看到这个。Delta实际上有一个API可以让你看到历史。这里我们可以很好地展示出来。 We can see all the commits and we can see their timestamp, we can see things like the query ID, the notebook ID. And then interesting thing that we can see here is, between commit number seven and commit number eight, the queryid is changing. And why is that? Because here I started writing with a new query. Alright, and this is also when I started writing with a new schema.

好，现在让我们仔细看看这个事务日志中的实际提交点，对吧?对于这个，我记得之前我的schema改变之前的提交号是7，对吧?所以，我只是给这个加了1，让图式改变它自己之后的所有东西，大于等于9的，都应该有新的图式。

现在我有了这个，我要把这三个提交，读入JSON格式。然后我们可以详细地查看这些提交。首先，让我们看看模式更改前的提交。

我们在这里看到的是它有一堆数据变化，对吧?如果我们看一个单独的，我们可以看到这个文件中有32条记录它有模式改变前表中四个字段的统计信息。好吧?这正是我们所期望的。现在我们看一下使模式改变的提交。

这看起来像什么?这里也有数据更改，等等，这是数据更改但它没有记录，为什么这个提交中没有记录?如果它说有一个数据更改，那么这个提交的牛肉实际上是在它的元数据中。对吧?要了解这个提交中真正发生了什么，我们必须查看元数据。如果我们看元数据，我们会看到这个提交有一个模式。在这个模式中，我们有两个新字段。我们有时间戳和值。对吧?我们在这里看到的是，当我们进行模式进化时，Delta Lake添加了，它基本上添加了一个空提交点。 That all it does is change the schema, but it doesn’t really add data, all right. And now we can look at the next commit. And then we can look at the data that it added. And this now again has records in the files that it wrote.

它还提供了新字段的统计信息。所以，我们可以看出，是的，这是用新的基模写的。

好了，Delta完全按我们的要求做了。它在事务日志的正确时间点记录模式更改。从上周开始，我们知道我们可以使用事务日志进行时间旅行，对吧?我们可以回到之前的表格版本看看它当时的状态。我们还记得几个提交版本让我们看看表格中三个不同的时间点。第一个是初始化表时的版本。那是我们第一次给它写信。第二个是模式改变前的表版本。第三个是该表的最新版本。如果我们在这三个不同的时间计算所有的记录，我们会看到，是的，最初是14705。 At the time of schema change we had more and now the current version has even more records in it. And that was exactly what we expected. The nice thing is we can actually also look at the data. And if we look at the data even though the schema of the table has changed, right? So our schema now includes two additional fields. These two fields, were not present in this commit, right? In c_before that was number seven. So if we read this data now, we will still see the old data and we will see it with the old schema, right? So, this is nice, right? Because if we go back in history we don’t just see the old data at that time but we actually see it with the schema that it had at that time.

现在我们回到图式改变之前的时间。

如果我们看这个数据它仍然是，不这是模式改变的时间，对吧?这是第8次提交。我们现在看到的是旧数据，对吧?这和我们之前看到的数据完全一样。但是现在，我们看到了另外两列。这里所有的值都是空的。为什么呢?因为我们还没有写出任何有这些列的数据，对吧?所以它们默认为空值。这正是我们所期望的。 Now if we go to the latest version of this table or even if we just go to the first version of the table, right after the schema change, right? This was commit after, then we will actually find records where the timestamp was not null. And we will see that here. You see here, and so now we have actual data with the new schema where the new columns do not default to null.

这就是我在演示中想要展示的。

我要回到我的演讲，并结束我的演讲。

Delta Lake连接器

你可能会想，如果我现在把我的存储格式换成Delta，我有所有现有的应用程序，那么我还能很容易地使用那些数据吗?好消息是，有很多工具可以连接三角洲湖泊。所以如果你在使用Hive、Spark或Presto，即使你在云端，你在使用Redshifts、Athena、Snowflake，有很多工具都有Delta的连接器，可以实际操作Delta的数据。

Delta Lake合bob体育外网下载作伙伴和供应商

还有很多合作伙伴会帮助你或者允许你在他们的工bob体育外网下载具中使用Delta，对吧?所以，有很多比这些更突出的是我们有很多分析公司。

三角洲湖的使用者

我们有数据采集公司

Delta Lake合bob体育外网下载作伙伴和供应商

我们也有大型云供应商，对吧?谷歌Dataproc支持这个，Azure Synapse支持这个。因此，无论你在哪里，你都能找到支持你使用达美航空的合作伙伴。bob体育外网下载如果这还不能说服你，还有很多公司已经在使用达美航空了。

三角洲湖的使用者

它比这里展示的要多得多。这只是一个小样本。所以如果你想加入这个俱乐部，也开始使用Delta，然后问自己这个问题。我怎么使用它?

使用Spark API开始了解Delta

这很简单。因此，如果你有现有的Spark作业或Spark笔记本或PySpark笔记本，你所需要做的就是将Delta添加到你的包或依赖项中。你可以在PySpark或Spark shell的命令行中做这个，如果你有一个Maven作业，你可以在Maven中做这个，当你做了这个，你就可以切换之前是parquet的东西。你现在可以在这里使用格式。这是您需要更改的唯一一行代码。其他的都可以。

今天订阅!

如果你想了解更多，这是整个BOB低频彩系列讲座的一部分，我鼓励你订阅我们的频道，下次再见。网址在这里，如果你想成为社区的一员，建立自己的三角洲湖，请访问https://delta.io。这就是开源社区存在的地方。bob下载地址

现在我想让大家提问。——完美。谢谢安德烈亚斯。那是一个很棒的演讲。我们有10分钟左右的时间来回答问题。我将从回答一些问答开始让安德烈亚斯有一点时间呼吸和休息同时也参考问答问题。或者如果你想我可以问你各种各样的问题，你想怎么问都行。但我将以一个简短的问题开始，一个人问了这个问题。模式演化在开源的Delta Lake中可用吗? Databrickbob下载地址s中的Delta Lake与开源的Delta Lake之间有什么区别吗?当我们在Databricks上做这个演示的时候，我们所展示的所有东西实际上都是开源的。bob下载地址 There is actually no difference between, or I shouldn’t say no difference, but the goal is as will be part of Delta Lake 1.0, there will be no difference between the open source and or managed Delta Lake, the one that’s for Databricks because all of the APIs and those features are actually gonna be exactly the same, okay? So, it doesn’t, that’s absolutely the goal. The quick call out is that there are some potential differences for Databricks itself in terms of the management of it. But in terms of the actual functionality and the API, no, there actually is no difference. And related to this question, there was a question concerning, why didn’t we do this using the SQL syntax? That’s part of the reason why. Because, once Spark 3.0 it becomes available, we can show you running all of this in using the SQL syntax, instead of using the API syntax. It’s just that we’re dependent on some of the features that are specific at Spark 3.0, in order to be able to support that, okay. So I just want to call that out. So, Andreas, would you like me to ask you some questions, or are there any questions inside here in the Q&A panel that you particularly like? (Denny chuckles) – Yeah, I was just struggling with actually seeing the questions because while I’m presenting, I don’t see them. (Andreas laughs) – Oh, that’s right, that’s right. Okay, no problem. So then, you know what, I will ask you some questions and you can just tell me if you’d like me to answer them, or if you wanna go ahead and answer them. How’s that? – Sure. – All right. So the quick call out is that, if I understood this correctly, is our enforcement and evolution in this case mutually exclusive?

-它们并不相互排斥。这是一个工作对工作的基础。如果你在Spark工作，对吧?它使用选项mergeSchema或覆盖模式，然后该作业将被允许更改模式。好吧，其他不给这个选项的工作可能不允许这样做。如果他们试图这样做，这些工作就会失败。——酷。很好，还有一个问题，这个问题在战术上已经回答了，但我觉得还是直接说出来比较好，对吧?三角洲湖有办法追踪血统吗?这种方法具体来说就是，知道模式是如何存储于数据之间的。

-是的，我的意思是血统是隐含在每一个德尔塔湖提交和交易法，对。当我们查看这个JSON结构时，我们可以看到每个提交都有沿袭。它能告诉你笔记本的ID是什么?Spark作业ID是什么?用户ID是什么?执行此操作的用户的电子邮件是什么?当你查看执行模式更改的提交时，你可以找到所有这些信息。——没错。再补充一下你的观点。不要忘记，在使用Parquet时，Parquet本身包含模式本身。 But the problem, this is the reason why we have schema evolution and schema enforcement, which is to say that, okay, well, while parquet can do it, the reality is that things can change over time. So you need something, that actually has a transaction log that contains all of the potential changes. That way we have an enforcement epic ability. That way we can evolve. We could say exactly to the point of lineage, we can see within the JSON itself in the metadata column, oh, okay! Version zero in the case, this particular case, this is where we went ahead and had the initial version of four columns, by version was it seven or eight. (Denny chuckles) That one is the where the switch made. And then now it has six columns. So you can actually see it within the transaction log itself, basically, okay. A fun one for you Andreas, is it possible to relate to time travel, is it possible to roll back to a certain point in history. – It absolutely is, yes. You just need to go back to that commit. You can read at any point in time.

——当然。酷。让我们看看，这是另一个因为我们实际上有很多，它基本上支持，谈论支持模式之类的东西。我想你已经回答了大部分问题，所以我只是想把它们过滤掉。(丹尼和安德里亚斯笑)好吧。我想我们已经回答了这个问题，但是，我认为这是一个很好的呼吁。在模式验证中，是否允许空字段不匹配?

-所以一个空字段的不匹配是不允许的，如果你试图写不包含该字段的数据，那么Delta Lake将抛出一个异常，因为它强制非空字段始终存在。如果字段为空，这就放宽了限制。这意味着您可以编写没有这些问题的数据。

——酷。与此相关的是，因为我们一直在讨论模式，Delta Lake是否支持无模式模式还是总是与模式一起运行?我想你在第一次提交时已经回答了这个问题但我们决定把它叫出来。-是的，Delta总是有一个模式，Delta是它正确存储的模式。

-太好了。这实际上与Delta Lake的错误有关，例如，如果你读取消息队列或写入消息队列，Delta出现错误。它是自动重放还是你现在必须处理丢失的信息?不，这更像是一个揭露事务日志的问题而不是一个模式问题，但我认为这仍然是一个很好的呼吁，它也允许我们无耻地呼吁去播放列表(Denny笑了笑)并回顾前一周我们深入研究的事务日志但我认为至少我现在说出来了，所以。-是的，没错。所以不会自动回放，对吧?它将抛出一个异常，您的工作将失败。但是关于的好处是你试图写入的任何数据，要么全部都在那里，要么根本就不在那里，对吧?这意味着你是对的是原子。这样你的数据就会一直保持一致。 You won’t have phantom rights from like failed transactions or anything like that. – Exactly, so just to add to exactly to Andrea’s point here.

Delta Lake有乐观并发模型，并发控制模型，不好意思。所以如果它能够允许权利发生它就会让它发生，对吧?换句话说，如果有一个错误，两个线程试图在同一时间写数据，检查就会说，好吧，你试图在同一时间读同一个表，但实际上没关系，因为它们要去两个不同的分区。然后会有一些错误它会自动为你重试它会处理这些错误。这就是乐观并发控制。但完全符合安德烈亚斯的观点。如果有一个错误，基本上，不，它确实是一个错误，我们没有办法继续自动处理它。它会继续，然后出错。最重要的是，它不会留下任何部分的书面文件。完全符合安德烈亚斯关于自动性的观点。 It’s either written or it isn’t. So you can trust your data. This goes back to our theme of reliable Delta Lakes, okay. Cool let’s see, I think we’ve got time for probably one more question. So actually a good one that I started like talking about this might go a little long, so we’ll have to make sure you and I both don’t go too long on this one. Schema enforcement evolution usually comes at a performance cost. What’s our take on this?

-你去接吧，丹尼-哦，当然好吧，不错。这就是发展和实施的背景，对吧?从性能的角度来看，这实际上是写入交易法的内容，对吧?首先，你有一个事务日志。这样做会有一些开销。第二，因为我们实际上是在这里写到磁盘。当然，您所面临的问题是，正如您从事务日志中看到的那样，我们可以有不同的版本，实际上写入的每个数据版本都有不同的模式。换句话说，我相信安德里亚斯，我们有17个版本，但在demo完成的时候。从技术上讲，这里有一些团队版本的数据。 Now, in this case it was relatively simplistic because we can go ahead and it was mostly additions. We didn’t do any updates, we didn’t do any inserts. So in this particular scenario probably it wasn’t that much of a performance hit because of the fact that we’re just simply adding two new columns. And that means all the previous data was just nullable. So yeah, it’s not really not much of an impact. But how about if you were to instead to do updates to that data or deletes, right? There that means what is implied very strongly is that there’s that many more versions of the data and those versions are much larger. So the the potential performance impact is that you have that many more files. Now you can certainly run compaction to reduce the number of files but the reality is you still have more data, okay. And so the that’s ultimately what the performance impact is. So it’s less of a specific to schema enforcement and evolution per se outside the transaction overhead and more the fact that you have that many more files to work with. That’s where the real performance hits gonna be, okay? – And just to add to that, one important distinction here is whether you use merge schema or override schema. Because merge schema basically says that your old data is still read compatible with the new schema. So you don’t need to rewrite any of the old data, right? And you just keep it in the table and when you read that data every time, you can easily morph it into the new schema. So that just happens on the fly and there’s almost no performance penalty. Whereas if you do an override schema then you’re basically forced to rewrite to make a new copy of all your existing data. Because otherwise you would not be able to read that back. And that’s a huge performance penalty. And this is why typically the recommendation is to do read compatible schema evolution because it’s just operationally is easier to handle.

——完美。好吧，知道吗?我想知道时间，所以我为不能回答的问题道歉，但我希望你们喜欢今天的课程我们要感谢安德里亚斯，但让我们回到凯伦。那就让她结束这部剧吧。-我想感谢各位的出席。-是的，非常感谢Andreas，精彩的演讲。同时也感谢Denny的加入。感谢大家的收看。只是一个快速的呼叫，我发布了YouTube链接订阅，然后也加入我们的在线聚会群。所以，我认为这些是让你了解我们所有即将到来的技术演讲以及我们计划在未来几个月里推出的所有好东西的最好地方。 So thanks everyone again for joining