介绍

Apache Spark ™是一种广泛使用的开源分布式计算引擎。它是 Uber 数据栈的主要组成部分之一。

Spark 是 Uber 的主要批处理计算引擎。与任何其他框架一样，Spark 也有自己的一套权衡。

问题陈述

使用过 Spark 的用户都知道，编写优化的 Spark 应用程序并不是一项简单的任务，需要大量的配置调整以及代码级优化。

考虑到 Uber 的 Spark 应用程序规模（每天约 100K+ 个应用程序），编写优化的 Spark 应用程序以节省计算资源对我们来说变得很重要。

我们承认，并非每个 Spark 用户都是高级用户，他们可能不了解该框架的所有复杂之处。这导致用户有时会编写未优化的 Spark 应用程序，这在 Uber 规模下可能导致计算资源的低效使用。

这个问题不仅限于优步——这是一个全行业的挑战，需要编写优化的计算工作流以有效地使用资源。

为了解决优步未优化 Spark 应用程序的问题，我们构建了 Spark Analysers。

架构设计

图 1：架构

组件术语

卓耿

Drogon 是 Uber 的 Spark 即服务产品

YARNRed（减少纱线）

努力降低 Uber 的 YARN 消耗

火花分析仪

Spark Analyzers 是一组组件，用于检测Spark 应用程序中的反模式。该系统包含 2 个主要组件：

Spark 事件监听器分析器——Flink 应用程序Spark 事件监听器

Spark Event Listener 是一个组件，用于侦听 Spark 应用程序运行时由 Spark 框架发出的一组特定事件。

我们在 Uber 有很多 Spark Listener，其中一个专门针对 Spark Analyzers 系统。该监听器实现了以下两个 Spark 监听器：

查询执行监听器火花监听器

并监听以下事件：

图 2：Spark 事件

侦听器获取有关每个正在运行的 Spark 查询和整个应用程序的大量信息。它解析所有这些信息以提取可用于检测一组预定义反模式的内容。

侦听器解析的主要实体之一是 Spark 计划。

图 3：星火计划

Spark 计划是一种树状数据结构，其中每个节点都包含有关 Spark 应用程序正在执行的操作的特定信息。侦听器递归地遍历 Spark Plan 并在可能提供有用信息以检测反模式的节点处停止。

一旦从当前事件中收集了所有信息，它就会被推送到 Kafka ®主题。整个操作一直持续到应用程序结束。

分析器——Flink 应用

该组件包含反模式的具体定义和每个分析器的实现。这是一个实时 Apache Flink ®应用程序，它正在轮询 Kafka 主题，其中事件由上述 Spark 事件侦听器发布。

这个 Flink 应用程序目前有 2 个分析器，为每个 Spark 应用程序运行：

过度分区扫描分析仪重复的 Spark 计划分析器过度分区扫描分析仪

在 Uber，我们对 Hive ™表的数据扫描模式有一些建议，如下图所示：

图 4：扫描建议

分析仪设计

图 5：过度分区扫描分析器

该分析器查看 Kafka 主题中的每个事件，并检查它是否包含有关数据扫描的信息。如果是，那么它会检查正在扫描的表类型并相应地应用阈值验证。如果违反阈值，则会创建一个新的反模式事件并将其推送到不同的 Kafka 主题。

此反模式事件包含有关扫描的信息，例如正在扫描的表、正在扫描的数据天数以及数据扫描建议。

由于此分析器在事件级别工作，因此它是一个无状态分析器并且独立于流中的其他事件工作。

重复的 Spark 计划分析器

图 6：Spark DAG

Spark 的另一个重要特性是它惰性地评估计划。惰性评估意味着除非用户请求 Spark 的输出，否则不会执行任何具体操作。所有转换都一个接一个地放入 Spark 计划中，但除非用户告诉 Spark 执行计划并返回结果，否则不会评估任何内容。

图 7：Spark 转换和操作

一旦用户请求结果，就执行到目前为止创建的计划。但有趣的是，如果用户再次请求相同的结果，Spark 会再次重新计算完全相同的计划。

考虑一个示例，用户在 Spark SQL 中连接 4 个表，并在对记录进行一些过滤后执行计数操作。如果用户请求计数两次，Spark 将执行两次 4 个表之间的连接！

这会导致大量复杂的计算，具体取决于 Spark Plan 和再次执行的操作。为避免此类情况，用户需要了解 Spark 中的缓存并以避免此类数据重新计算的方式编写应用程序代码。

分析仪设计

图 8：重复的 Spark 计划分析器

该分析器检测应用程序中的这些重复计划，并向用户推荐避免大量数据重新计算的方法。

为了识别重复的计划，侦听器需要了解 Spark 应用程序中的所有 Spark 计划，因此它需要为每个应用程序维护一个状态，使其成为一个有状态的分析器。

如上面的分析器设计图所示，它会在应用程序结束或 2 小时计时器到期且未从应用程序接收到新事件时检测重复计划。

图 9：星火计划示例

为了识别给定的 Spark Plan 之前是否已经被看到，侦听器使用 Spark Plan 的语义哈希，它由 Spark Listener 推送到 Kafka。语义哈希允许分析器在 Spark 应用程序的单次运行中检测重复计划。Spark 在计算此哈希之前删除了表面更改，从而为应用程序中的相同查询提供相同的结果。侦听器还发布了 Spark 计划的普通哈希，它不会在运行时发生变化，但对于同一应用程序中的同一查询是不同的。我们使用语义哈希来检测应用程序运行中重复的 Spark 计划。纯哈希可用于检测跨应用程序运行的重复 Spark 计划，但这不是我们今天所做的事情。

例子

在检测到重复计划时创建反模式事件并将其推送到 Kafka。

YARNRed – Jira 票务

YARNRed 代表 YARN Reduction，这是 Uber 为减少 YARN 资源消耗并提高资源使用效率而做出的努力。它针对计划的工作负载。

计划的 Spark 工作负载的识别

我们为 Spark 应用程序准备了指纹识别逻辑 (SHA1)，我们使用该唯一签名根据它们所属的工作流来识别预定应用程序。Ad hoc spark 应用程序将此设置为空。

YARNRed 的主要组件之一是 Jira Ticketing Pipeline，它从各种来源收集数据并分析不同窗口中的历史数据（例如，分别是最近 180、30 和 7 天）。然后管道使用历史记录，应用规则来识别建议，并为应用程序所有者创建 Jira 票证，以通知他们如果将建议的优化应用于他们的应用程序（例如，如果工作流有很高的失败率）可以实现的潜在节省速度）。

在 Spark 应用程序的情况下，Spark Analyzers 还有助于实现 YARN 资源优化的相同目标。因此，YARNRed 现在还使用 Spark Analyzers 的输出并识别创建票证的候选人。对于 Spark，它会为以下两种情况创建 Jira 票证：

如果为特定表扫描了太多分区如果存在重复的 Spark 计划并且相应的 Spark 查询运行时间大于 10 分钟

我们有一个额外的成本阈值过滤器检查，以避免通过创建不必要的票证给用户带来噪音。

在各自的 Jira 票证中，它还分别为所有者提供了过去 180 天和 7 天消耗的平均资源（虚拟内核和内存）以及故障率的洞察力。

图 10：YARRed 架构

样本 Jira 票据

图 11：样本 Jira 票证

此工作流负责每 2 周定期提醒一次，并向所有者提供详细摘要以优化他们的工作量。

工作流的设计方式还确保已批准的用例不会被识别为票证创建的候选者，再次避免票证重复。

使用的术语

vCores

使用的 CPU 虚拟内核数

核心数

最大值（vCore、已用内存/SKU 比率）

此 SKU 比率是使用我们 YARN 队列中每个 vCore 的内存得出的。截至目前，每 1 个 vCore 映射到我们的 YARN 集群中大约 4.4GB 的可用内存

考虑因素和设计选择

开发 Spark Analyzer 时的主要考虑因素之一是不以任何方式影响用户应用程序。影响用户应用程序可能会让优步数据平台的消费者感到不安，并给他们带来糟糕的体验。我们关心用户体验，并希望确保我们所做的一切都是从用户那里抽象出来的，并且所有正在运行的应用程序都不会受到 Spark Analysers 的所有处理的影响。

为了达到同样的目的，我们做出了一个设计选择，将事件统计收集与实际分析分离。Spark Listener 执行的事件统计收集是一个轻量级操作，发生在应用程序上下文中。分析器完成所有繁重的工作，因此作为一个单独的实时 Flink 应用程序位于应用程序之外。

以下是我们在开发分析器时遵循的设计原则：

可插拔

轻松开发新的分析仪并将其插入现有系统

可扩展

根据用例扩展现有分析器

可扩展

Flink 应用程序可以独立于 Spark 应用程序进行扩展

解耦

整体架构分层解耦，每个组件都可以独立伸缩

结果

在没有任何成本过滤的情况下，我们每天 在 1500多个不同的应用程序中检测到5000 多个反模式。

应用上述成本函数后，我们确定了约 150 个候选票据创建。

我们每年通过当前检测节省 60k+ uCores，并且随着用户继续对 Jira 票证采取行动，我们预计会看到更多。

挑战之一是让应用程序所有者对 Jira 票证采取行动，我们会定期使用自动票证管道发送提醒，以获得越来越多的 Jira 票证。

结论

Spark Analyzers 是大规模解决 Spark 应用程序低效问题的独特方法。我们希望调查更多的反模式并推出新的分析器以增加我们对反模式的覆盖范围。

如果没有多个 Uber 团队齐心协力，Spark Analyzers 的推出是不可能的。我们的数据平台团队不断致力于通过尽可能多地识别和应用优化来改进数据产品并降低平台成本。Spark Analyzers 是 Uber 为改善 Spark 应用程序的资源使用所做的众多努力之一，涉及一些可以自动应用优化而无需任何用户操作的努力。

鉴于我们的规模，Uber 继续致力于解决此类常见数据问题，即使是小的改进也可以节省大笔费用！

主要图片归属：图片来自根据谷歌图片

作者:

维贾扬索尼

Vijayant Soni 是 Uber 交付数据解决方案团队的一名软件工程师。他致力于增强 Uber 的 ETL 框架，以避免不同环境的管道重复，并使用单个功能标志执行小文件压缩。他构思并开发了 Spark Analyzers 来揭示用户在编写 Spark 应用程序时面临的最常见问题。他目前正致力于分散一个巨大的蜂巢数据库（约 10 PB），以实现更好的可扩展性并维持 Uber 的显着数据增长。

萨希达尔塔拉姆

Sashidhar Thallam 是 Uber 交付数据解决方案团队的前任软件工程师。他致力于自动化以优化所有 Hive 工作负载的资源使用。他构建了查询分析器，可以检测 Hive 查询中的许多反模式，并向查询所有者提出改进建议。

萨克什·潘德

Sakshi Pande 是数据退款和减少消耗团队的软件工程师。自 11 月 21 日以来，她是参与 Chargeback 和成本效率计划的早期工程师之一，在 HDFSRed、YARNRed、PrestoRed 等计划中发挥着至关重要的作用。

阿图曼特里

Atul Mantri 是 Uber 数据平台团队的高级软件工程师。他专注于构建能够在 Uber 的所有批处理和实时应用程序中实现大数据可观察性的系统，并推动平台中的成本效益计划。在 Uber 之前，Atul 曾在 Rubrik 和 Netapp 工作，构建高性能分布式系统。他拥有北卡罗来纳州立大学的硕士学位。

出处: