介绍Databricks Delta是一个统一的数据管理系统，它为云数据湖带来了数据可靠性和快速分析能力。在这篇博文中，我们将深入了解是什么使得Databricks Delta能够在几秒钟内筛选出数PB的数据。特别地，我们讨论了数据跳转和ZORDER聚类。这两个特性的结合使Databricks运行时能够显著减少需要扫描的数据量，以便针对大型Delta表回答高度选择性的查询，这通常转化为数量级的运行时改进和成本节约。你可以在2018年Spark+AI峰会的主题演讲中看到这些功能的实际应用，苹果公司的Dominique Brezinski在会上展示了Databricks Delta的使用案例，作为网络安全监控和威胁应对环境下数据工程和数据科学的统一解决方案。如何使用数据跳转和ZORDER聚类为了利用数据跳转的优势，您需要做的就是使用Databricks Delta。该功能是自动的，每当您的SQL查询或数据集操作包含"column op literal"形式的筛选器时，该功能就会生效，其中：column是某些Databricks Delta表的属性，无论是顶层还是嵌套的，其数据类型为string/numeric/date/timestampop是一个二进制比较运算符，用/LIKE"pattern%"或

literal是与列具有相同数据类型的显式（列表）值AND/OR/NOT以及"literal op column"谓词也受支持。正如我们将在下面解释的，即使在满足上述条件时，数据跳过总是起作用，但它可能并不总是非常有效。但是，如果有一些列是您经常筛选的，并且希望确保快速筛选，那么您可以通过运行以下命令来显式地优化关于跳过有效性的数据布局：优化[其中]排序依据（[，…]）稍后再谈这个。首先，让我们退一步，把事情放在上下文中。数据跳过和ZORDER集群的工作原理这些特性的一般使用情况是提高针对大量数据集的大海捞针式查询的性能。由于可伸缩性的原因，典型的RDBMS解决方案（即二级索引）在大数据环境中并不实用。如果您熟悉大数据系统（apachespark、Hive、Impala、Vertica等），您可能已经在考虑：（水平）分区。快速提醒：在Spark中，就像Hive一样，分区1的工作原理是为分区列的每个不同值设置一个子目录。分区列上带有过滤器的查询可以从分区修剪中获益，也就是说，避免扫描任何不满足这些过滤器的分区。主要的问题是：您按什么列进行分区？典型的答案是：在对时间敏感的查询中，最有可能筛选的那些。但是…如果有多个（比如4+），同样相关的列呢？在这种情况下，问题是最终会得到大量唯一的值组合，这意味着有大量的分区和文件。在多个小文件中拆分数据会带来以下主要问题：元数据变得和数据本身一样大，从而导致各种驱动端操作的性能问题特别是，文件列表会受到影响，变得非常缓慢压缩效率受到影响，导致空间浪费和IO速度减慢因此，虽然Spark中的数据分区通常对日期或分类列很有效，但它不太适合高基数列，而且在实践中，它通常最多只能有一到两列。数据跳过除了分区修剪之外，数据仓库领域中使用的另一种常用技术是基于小型物化聚合的I/O修剪，而Spark目前还缺乏这种技术。简言之，其目的是：跟踪与I/O粒度相关的特定粒度的简单统计信息，如最小值和最大值。在查询规划时利用这些统计信息，以避免不必要的I/O。这正是Databricks Delta的数据跳过特性所涉及的。当新数据插入到Databricks Delta表中时，将为支持类型的所有列（包括嵌套列）收集文件级的最小/最大统计信息。然后，当对表进行查找查询时，Databricks Delta首先查询这些统计信息，以确定哪些文件可以安全地跳过。但是，正如他们所说，一个GIF值千言万语，所以你来：一方面，这是一种轻量级和灵活的（粒度可以调整）技术，易于实现和推理。它还与分区完全正交：它与分区一起工作得很好，但并不依赖于它。另一方面，它是一种概率索引方法，与bloomfilters一样，可能会给出误报，尤其是在数据没有聚集的情况下。这就引出了下一个技巧。佐尔德聚类为了使I/O修剪有效，需要对数据进行聚类，以使最小-最大范围窄，理想情况下，不重叠。这样，对于一个给定的点查找，最小-最大范围命中的数量最小化，即跳过最大化。有时，数据恰好是自然聚集的：单调递增的id、与插入时间相关的列（例如日期/时间戳）或分区键（例如pk_brand_name–model_name）。如果不是这样，您仍然可以通过在插入之前显式地对数据进行排序或范围分区来实施集群。但是，再次假设您的工作负载由（例如n=4）个不同列上相同频繁/相关的单列谓词组成。在这种情况下，所有n列的"线性"即"词典学"或"主次"排序将强烈支持第一个指定的列，将其值完美地聚集在一起。但是，对于第二列，它不会做太多事情，如果有的话（取决于第一列上有多少重复值），依此类推。因此，在所有可能的情况下，在第n列上不会有集群，因此涉及到它的查找不可能跳过。那么我们怎样才能做得更好呢？更确切地说，我们如何在每个单独的维度上实现类似的跳转效果？如果我们仔细考虑一下，我们要寻找的是一种将n维数据点分配给数据文件的方法，这样分配给同一个文件的点在n维上也相互接近。换言之，我们希望以保持局部性的方式将多维点映射到一维值。这是一个众所周知的问题，不仅在数据库世界中遇到，而且在计算机图形和地理哈希等领域也遇到。答案是：保局部空间填充曲线，最常用的是Z阶和Hilbert曲线。下面是一个简单的例子，说明如何应用Z排序来改进数据布局，以提高数据跳过的有效性。图例：灰点=数据点，例如棋盘方格坐标灰色框=数据文件；在本例中，我们的目标是每个文件有4个点黄框=为给定查询读取的数据文件绿点=通过查询过滤器并回答查询的数据点红点=已读取但不满足过滤器要求的数据点；"假阳性"网络安全分析中的一个例子好吧，理论够了，让我们回到Spark+AI峰会的主题，看看Databricks Delta如何用于实时网络安全威胁响应。假设您正在使用Bro，这是一种流行的开源网络流量分析器，它可以生成实时、全面的网络活动信息2。你的产品越受欢迎，你的服务使用量就越大，因此，Bro开始输出的数据就越多。以足够快的速度编写这些数据，以便以更结构化的方式进行持久存储，以便将来进行处理，这是您将面临的第一个大数据挑战。这正是Databricks Delta最初设计的目的，使得这项任务简单可靠。您可以使用结构化流将Bro-conn数据导入到一个日期分区的Databricks Delta表中，您将定期在该表上运行OPTIMIZE，以便日志记录最终均匀分布在大小合理的数据文件中。但这并不是本文的重点，因此，为了说明问题，让我们保持简单，并使用一个由均匀分布的随机数据组成的非流式、非分区的Databricks Delta表。面对潜在的网络攻击威胁，您需要运行的即席数据分析是针对记录的网络连接数据进行的一系列交互式"点查找"。例如，"查找涉及此可疑IP地址的所有最近的网络活动"。我们将假设此工作负载由基本查找查询组成，并使用单列相等筛选器，同时使用随机和抽样的IP和端口。这些简单的查询是IO绑定的，即它们的运行时间与扫描的数据量成线性关系。这些查找查询通常会转化为运行数小时的完整表扫描，这取决于存储的数据量和查找的时间。您的最终目标可能是最小化运行这些查询所花费的总时间，但是，为了便于说明，让我们将cost函数定义为扫描的记录总数。这个度量应该是整个运行时的一个很好的近似值，并且具有良好的定义和确定性，允许感兴趣的读者轻松可靠地再现我们的实验。所以现在我们要做的是，具体来说：端口dst-ip-String\dst-ip-String，类型：srt-u-Intdef randomIPv4（r:随机）=顺序填充（4） （r.nextInt（256））.mkString（"."）随机端口定义（656随机）=随机def randomConnRecord（r:随机）=ConnRecord(src_ip=随机IPv4（r），src_port=随机端口（r），