将云数据湖转换为三角洲数据湖的5大原因

通过杰森·波尔

2020年8月21日在公司博客上

分享这篇文章

如果你看一下任何一个议程火花峰会在过去的五年中，您会注意到，关于如何使用Apache Spark™作为ETL和查询引擎，并使用Apache Parquet作为首选文件格式，在云中最好地构建数据湖的讨论并不少。关于如何[以及如何不]划分数据，如何计算理想的文件大小，如何处理不断变化的模式，如何构建压缩例程，如何从失败的ETL作业中恢复，如何将原始数据流到数据湖等，有一些演讲给出了建议。

Databricks一直在与客户合作，将数据湖实现的所有最佳实践封装到Delta lake中在2019年Spark +AI峰会上开源．将Apache Parquet Data Lake转换为Delta Lake有很多好处，但这篇博客将重点介绍前5个原因:

防止数据损坏
更快的查询
提高数据新鲜度
复制ML模型
实现遵从性

基本上，Delta Lake在数据的同时维护一个事务日志。这使得每个Delta Lake表都可以进行与acid兼容的读写。

防止数据损坏

数据湖最初被认为是对HDFS上的数据仓库的内部大数据补充，而不是在云中。当将相同的设计模式复制到blob数据存储(如Amazon Web Services (AWS) S3)上时，由于最终的一致性属性，会出现独特的挑战。最初的Hadoop提交协议假设事务具有RENAME功能，这些事务存在于HDFS中，但不存在于S3中。这迫使工程师从两种不同的Hadoop提交协议中做出选择，要么安全但缓慢，要么快速但不安全。在发布Delta Lake之前，Databricks开发了他们自己的提交协议来解决这个问题。2017年Spark峰会的演讲，事务性写入云存储，解释了这些挑战以及我们当时的解决方案。

Delta Lake从一开始就设计为适应blob存储以及最终的一致性和数据质量属性。如果ETL作业在完全完成之前对Delta Lake表失败，它不会破坏任何查询。每个SQL查询总是引用表的一致状态。这允许企业数据工程师排除ETL作业可能失败的原因、修复它并重新运行它，而不需要担心警告用户、清除部分写入的文件或调整到以前的状态。

在Delta Lake之前，一种常见的设计模式是通过批处理id对数据的第一阶段进行分区，这样如果在输入时发生故障，可以删除该分区，并在重试时创建一个新分区。尽管这种模式有助于ETL的可恢复性，但它通常会导致许多分区和几个小的Parquet文件;从而阻碍了下游查询的性能。这通常通过将数据复制到具有更大分区的其他表中来纠正。Delta Lake仍然支持分区，但是您只需要将它们与预期的查询模式相匹配，而且只有当每个分区包含大量数据时才需要这样做。这最终消除了数据中的许多分区，并通过扫描更少的文件来提高性能。

Spark允许将不同的Parquet模式合并在一起mergeSchema选择。对于常规的Parquet数据湖，模式可以在不同分区之间有所不同，但在分区内部则不会。然而，Delta Lake表没有这种限制。三角洲湖给了工程师一个选择允许表的模式演进，或在写时强制执行模式．如果检测到不兼容的模式更改，Delta Lake将抛出异常，并防止表被具有不兼容类型的列损坏。此外，Delta Lake表可能在列上包含NOT NULL约束，这不能在常规Parquet表上强制执行。这可以防止为需要数据的列加载NULL值的记录(并可能中断下游进程)。

Delta Lake防止数据损坏的最后一种方法是支持合并声明。许多表的结构都是只能追加的，但是，重复的记录进入管道的情况并不少见。通过使用MERGE语句，可以将管道配置为插入新记录或忽略Delta表中已经存在的记录。

更快的查询

Delta Lake有几个属性，可以使相同的查询比普通拼花更快。Delta事务日志不是为每个查询在blob存储上执行昂贵的LIST操作(这是常规Parquet读取器会做的)，而是作为清单使用。

事务日志不仅跟踪Parquet文件名，而且集中了它们的统计信息。这些是Parquet文件页脚中每列的最小值和最大值。这允许Delta Lake在确定文件与查询谓词不匹配时跳过文件的摄取。

另一种跳过不必要数据摄入的技术是，以查询谓词仅映射到少量文件的方式对数据进行物理组织。这就是ZORDER数据重组背后的概念。这种表设计适合对不属于分区键的列进行快速查询。这些数据跳过技术的组合在2018年的博客中有解释:

使用Databricks Delta在几秒钟内处理pb字节的数据．

在2020年Spark+AI峰会上，数据公司宣布了我们的新德尔塔引擎，这增加了更多的性能增强。它有一个智能缓存层，可以在集群的SSD/NVME驱动器上缓存数据;从而加快对相同数据的后续查询。它有一个增强的查询优化器，可以加快常见的查询模式。然而，最大的创新是Photon的实现，这是一个用c++编写的原生矢量化引擎。总之，这些组件为Delta Engine提供了相对于Apache Spark的显著性能提升，同时仍然保持相同的开放api。

因为Delta Lake是一个开源项目，围绕它形成了一个社区，其他查询引擎也建立了对它的支持。如果您已经在使用其中一个查询引擎，那么您可以开始利用Delta Lake并立即获得一些好处。

提高数据新鲜度

许多Parquet数据湖每天都会刷新，有时每小时刷新一次，但很少每分钟刷新一次。有时这与聚合的粒度有关，但通常这是由于能够将实时数据流传输到数据湖的技术挑战。Delta Lake从一开始就被设计为同时适应批处理和流摄取用例。通过利用Delta Lake的结构化流，在将数据从一个Delta表转换到另一个Delta表时，自动获得内置检查点。通过对Trigger的单个配置更改，可以将摄取从批处理更改为流处理。

适应流摄取的一个挑战是，更频繁的写入会生成许多非常小的文件，这会对下游查询性能产生负面影响。作为一般规则，查询较少数量的大文件要比查询大量的小文件快。每个表应尽量实现统一的拼花文件大小;通常在128MB到512MB之间。多年来，工程师们开发了自己的压缩工作，将这些小文件压缩成更大的文件。但是，由于blob存储缺乏事务，这些例程通常在半夜运行，以防止下游查询失败。Delta Lake可以把这些文件压缩成一个优化命令，并且由于符合ACID，它可以在用户查询表的同时运行。同样，Delta Lake也可以发挥杠杆作用自动最优化以最佳大小连续写入文件。