简化为变更数据捕获（CDC）和GDPR用例构建大数据管道。Databricks Delta，建立在ApacheSpark之上的下一代引擎™，现在支持MERGE命令，该命令允许您高效地向上插入和删除数据湖中的记录。MERGE极大地简化了许多公共数据管道的构建方式；现在可以用简单的合并查询来代替所有那些低效重写整个分区的复杂多跳进程。这种更细粒度的更新功能简化了您为从变更数据捕获到GDPR的各种用例构建大数据管道的方式。在各种用例中需要升级有许多常见的用例需要更新或删除数据湖中的现有数据：通用数据保护法规（GDPR）合规性：随着GDPR中引入遗忘权（也称为数据擦除），组织必须根据要求删除用户的信息。这种数据擦除还包括删除数据湖中的用户信息。从传统数据库获取更改数据：在面向服务的体系结构中，web和移动应用程序通常由构建在传统SQL/NoSQL数据库上的微服务提供服务，这些服务针对低延迟进行了优化。组织面临的最大挑战之一是跨这些不同的竖井式数据系统连接数据，因此数据工程师构建管道，将所有数据源整合到一个中心数据池中，以便于分析。这些管道通常必须定期读取对传统SQL/NoSQL表所做的更改，并将其应用于数据湖中的相应表。这种更改可以采取多种形式：具有缓慢变化的维度的表、所有插入/更新/删除行的更改数据捕获等。会话化：将多个事件分组到单个会话中是从产品分析到目标广告到预测性维护等许多领域的常见用例。构建连续的应用程序来跟踪会话并记录写入数据湖的结果是很困难的，因为数据湖总是针对附加数据而优化的。重复数据消除：一个常见的数据管道用例是通过向表中追加数据来将系统日志收集到Databricks Delta表中。但是，源通常会生成重复记录，因此需要执行下游重复数据消除步骤来处理这些记录。数据湖上游的挑战由于数据湖基本上是基于文件的，所以它们总是针对附加数据而不是更改现有数据进行优化。因此，构建上述用例一直是一个挑战。用户通常读取整个表（或分区的子集），然后覆盖它们。因此，每一个组织都试图通过用SQL、Spark等手工编写复杂的查询来重新设计自己的需求。这种方法是：效率低下：读取和重写整个分区（或整个表）以更新一些记录会导致管道速度慢且成本高昂。手动调整表布局和查询优化非常繁琐，并且需要深入的领域知识。可能不正确：修改数据的手写代码很容易出现逻辑错误和人为错误。例如，多个管道在没有任何事务支持的情况下并发修改同一个表可能会导致不可预测的数据不一致，在最坏的情况下，会导致数据丢失。通常，即使是一个手工编写的管道也很容易由于业务逻辑编码错误而导致数据损坏。难以维护：从根本上说，这种手写代码很难理解、跟踪和维护。从长远来看，仅此一项就可以大大增加组织和基础设施成本。在Databricks Delta中引入Merge使用Databricks Delta，您可以使用以下MERGE命令轻松地解决上述用例，而不会出现上述任何问题：合并到使用打开[匹配时[然后][匹配时[然后][不匹配时[然后]哪里=删除|更新集*|更新集合column1=value1[，column2=value2…]=插入*|插入（column1[，column2…]）值（value1[，value2…]）请参阅我们的文档（Azure | AWS）以获得更详细的语法解释。让我们通过一个简单的例子来了解如何使用MERGE。假设您有一个缓慢变化的维度表，该表维护诸如地址之类的用户信息。此外，您还为现有用户和新用户提供了一个新地址表。要将所有新地址合并到主用户表中，可以运行以下命令：合并到用户使用更新打开用户.userId= 更新.userId如果匹配的话更新集地址=更新.地址当不匹配的时候插入（userId，address）值(更新.userId, 更新.地址)这将完全执行语法所说的-对于现有用户（即MATCHED子句），它将更新address列，对于新用户（即NOT MATCHED子句），它将插入所有列。对于具有TBs数据的大型表，这种Databricks增量合并操作比覆盖整个分区或表快几个数量级，因为Delta只读取相关文件并更新它们。具体而言，德尔塔的合并具有以下优势：细粒度：操作以文件而不是分区的粒度重写数据。这消除了重写分区、用MSCK更新配置单元元存储等的所有复杂问题。高效：Delta的数据跳过使合并在查找要重写的文件时效率更高，因此无需手动优化管道。此外，Delta及其所有的I/O和处理优化使得通过合并读取和写入数据的速度大大快于apachespark中的类似操作。事务性：Delta使用乐观并发控制来确保并发写入程序使用ACID事务正确地更新数据，并且并发读卡器始终可以看到一致的数据快照。下面是对MERGE与手写管道的比较的直观说明。图中显示了将记录合并到带有和不包含Databricks Delta的数据湖所涉及的步骤使用合并简化用例由于GDPR删除数据遵守GDPR的"被遗忘的权利"条款对于数据湖中的数据来说再容易不过了。您可以使用下面的示例代码设置一个简单的计划作业，以删除所有选择退出服务的用户。合并到用户使用已选择的用户在选择退出_用户.userId= 用户.userId匹配后删除应用数据库中的更改数据您可以使用MERGE语法将从外部数据库生成的所有数据更改（更新、删除、插入）轻松应用到Databricks Delta表中：合并到用户使用(选择userId，最新地址作为地址，最新.已删除从中删除(选择userId，MAX（struct（TIME，address，deleted））作为最新版本从按用户标识分组的更改))最新变化打开最新更改.userId= 用户.userId当匹配和最新更改。已删除=真的吗删除如果匹配的话更新集地址=最新更改地址不匹配时和最新更改。已删除=则为假插入（userId，address）值（userId，address）从流式管道更新会话信息如果有流式事件数据流入，并且希望对流式事件数据进行会话化，并在Databricks Delta表中增量更新和存储会话，则可以在结构化流式处理和合并中使用foreachBatch。例如，假设您有一个结构化的流式数据帧，它为每个用户计算更新的会话信息。您可以启动一个流式查询，将所有会话更新应用于Delta表，如下所示（Scala）。斯特拉mingSessionUpdatesDF.writeStream.foreachBatch{（microBatchOutputDF:DataFrame，batchId:Long）=>microBatchOutputDF.createOrReplaceTempView（"更新"）microBatchOutputDF.sparkSession.sql（s"""合并到会话中使用更新打开会话.sessionId= 更新.sessionId匹配后更新集*如果不匹配，则插入*""）}。开始（）有关foreachBatch和MERGE的完整工作示例，请参阅此笔记本（Azure | AWS）。结论Databricks Delta中的细粒度更新功能简化了构建大数据管道的方式。您不再需要编写复杂的逻辑来覆盖表并克服快照隔离的不足。使用细粒度更新，您的管道也将更加高效，因为您不需要读取和覆盖整个表。随着数据的变化，需要的另一个关键功能是在发生错误写入时进行回滚的能力。Databricks Delta还提供了带有时间旅行特性的回滚功能，因此如果合并不好，就可以轻松地回滚。阅读更多（Azure | AWS）关于细粒度更新功能的信息。要查看该特性的实际应用，请注册免费试用Databricks并试用它。对开源的三角洲湖感兴趣吗？访问Delta Lake在线中心了解更多信息，下载最新代码并加入Delta Lake社区。 免费试用Databricks。今天就开始吧