大数据世界中的许多人已经熟悉 Spark。但是新手可能会疑惑：什么是Spark？即使您是用户，互联网上也有很多 Spark 性能调优技巧。你如何从谷壳中挑选出小麦？
Spark 是一种开源分布式处理框架，旨在以比 Hadoop 更快的速度运行大数据工作负载，而且资源更少。 Spark 利用内存缓存和优化的查询执行对任何大小的数据执行快速查询。
在当今的大数据世界中，Spark 技术是一个核心工具。但是，它非常复杂，如果没有适当优化，可能会出现一系列问题。如果没有正确的 Spark 性能调优方法，您将面临许多 Spark 性能问题的风险，包括超支和次优性能。
Spark 性能调优是快速及时地更改 Spark 配置以确保优化所有流程和资源并顺利运行的过程。此 Spark 优化过程使用户能够实现 SLA 级别的 Spark 性能，同时缓解资源瓶颈并防止性能问题。
什么是 Spark Schema 调优？
以下是 Spark 性能调优的常用方法：
数据序列化。这个过程是指将对象转换为字节流，而相反的过程称为反序列化。序列化导致对象在网络节点上的最佳传输或在文件/内存缓冲区中的轻松存储。它通过以序列化格式存储 Spark RDD（弹性分布式数据集）来帮助减少内存使用。数据序列化有助于确保高效的资源利用和作业在精确的执行引擎上运行。数据序列化确保运行时间长的作业被终止。
内存调整。默认情况下，Java 对象的访问速度非常快。然而，他们可以轻松地使用比字段中“原始”数据多 2-5 倍的空间。通过内存调整，用户可以确定和优化对象的内存使用情况，从而提高性能。
数据结构调整。通过避免使用可能导致开销的 Java 功能，帮助减少内存消耗。
垃圾收集调整。就程序存储的 RDD 而言，垃圾收集在具有大量“搅动”的数据结构中代价高昂。通过使用具有较少对象的数据结构，垃圾收集成本大大降低。
内存管理。 Spark 利用内存进行数据存储和执行。有效的内存管理确保 Storage Memory 和 Execution Memory 和谐共存并共享彼此的可用空间。
Spark 监控工具还可以提高任何 Spark 性能调整工作的有效性。这些解决方案为用户提供了对其 Spark 应用程序的可见性、查看有价值的 Spark 指标，并通过强大的可视化跟踪应用程序执行情况。
持续和自动化的 Spark 监控使用户能够始终掌握其资源利用率。这确保他们有足够的资源以最佳方式运行他们的 Spark 实例。用户可以及时了解 Spark 核心和应用程序，使他们能够更好地理解配置并对其进行必要的更改。
我们联系了我们自己的 Spark 优化专家，现场工程师 Alex Pierce，以深入研究 Spark 技术并了解如何充分发挥 Spark 框架的作用。 Alex 最近举办了一场关于如何优化 Spark 作业并成功执行 Spark 性能调优的网络研讨会。
Alex 列出了他认为每个 Spark 用户都必须了解和实施的最佳实践的三种 Spark 优化技术。这些都是：
继续阅读我们直接从我们自己的 Spark 老手那里探索每个 Spark 性能调优技巧。
琪亚娜：大家好。我是 Pepperdata 的主持人 Kiana，我将采访 Pepperdata 现场工程师 Alex Pierce，他领导了我们最近的网络研讨会“Spark 性能管理最佳实践”。如果您还没有机会观看有关 Spark 性能调优和优化的网络研讨会，它会在本次采访所在的页面上提供链接。所以，请随时去看看。现在，让我们直接进入问题。
Kiana：在网络研讨会期间，我们对如何通过加盐优化 Spark 作业这一主题产生了浓厚的兴趣。您提到了分区大小和数据倾斜等加盐修复。您能否详细说明加盐的工作原理以及人们如何使用它来更好地管理他们的 Spark 性能？
亚历克斯：当然。当您查看要尝试执行的操作时，让我们专门查看本例中的连接，因为这是 Spark SQL 中非常常见的用例。但这是您处理具有特定维度的数据集的任何时候。假设您正在处理一年中的几个月、一周中的几天或类似的维度。这是一个非常小的键空间。一周只有7天，一年只有12个月。假设您是一家企业，或者绝大多数记录发生在星期六的公司。
因此，当我们处理数据时，假设我们正在处理一个月的数据并且我们正在对这些数据进行连接，那么在数据集和星期六的维度表将比其他任务运行更长的时间。这在 Spark 性能问题中很常见。那么加盐是做什么的——它有点像重新分区而实际上不需要重新分区你的数据。所以基本上，我们所做的就是把我们要加入的键，比方说，我们的左表，我们要让它分布得更均匀。
我们这样做的方法是附加，我应该说的最简单的方法是附加一个介于 0 和 N 之间的随机数。您可以根据环境的大小、数据集的大小、您的规模来确定需要看看，Ns应该有多大。然后我们需要在连接的另一端做同样的事情。所以现在我们需要获取维度表，我的意思是，抱歉，我们需要获取数据集表以及那些 ID 之前确实存在的地方，我们需要在该 ID 上运行相同的东西。设置为将相同的 0-N 值随机附加到这些键。
现在，这并不意味着 N 不需要匹配。如果一方的数字与另一方不匹配，那肯定有问题。但在这一点上，我们现在可以使用这些加盐键进行连接，假设在我们的工作日案例中，我们现在有 47 个键，而不是七个键。所以我们现在已经将其分布在一个更大的空间中。
这意味着，是时候真正进行连接了，而不是让一个特定的执行器来完成 80%-90% 的工作，因为数据集倾斜会得到更好的分布。现在你需要用你的数据集测试什么大小的盐最适合你，你需要记住如果你碰巧使用广播表，你的盐会增加它的大小维度表。
因此，如果您使用的是广播表，则需要密切注意自己的记忆，以确保不会炸毁执行者，而您只需要进行调整即可。这可能需要一些实验；你最了解你的数据集，所以你知道你的偏差有多大，并且你通常可以在 Pepperdata 等工具中将其可视化，以准确了解要添加多大的盐空间。但通常情况下，您会看到性能显着提高，尤其是在并行化方面。
因此，如果您处于分布式环境中，而之前您的环境中可能有 1000 台主机，但由于执行程序的密钥空间有限，您只使用了 7 台主机，现在您可以在 47 或 50 台主机上运行它。突然之间，有了通过这种 Spark 调优技术，您可以更好地使用环境的资源，您不会成为瓶颈，可能会在其他节点之一上长时间出现 CPU 瓶颈。这只是处理基于有限键空间的数据的好方法。
现在，至于它的实际代码。那里有大量的例子，甚至只是看看 DataZone 或 Stack Overflow 之类的东西。您应该能够非常简单地找到有关如何在 Spark 中的表上加盐的示例。
Kiana：是的，谢谢你的回答。那很棒。因此，您还提到，在多租户环境中，最好的 Spark 优化技术之一就是成为一名优秀的租户。这到底是什么意思？你有什么建议人们可能还没有想到吗？
亚历克斯：当然。所以这个很有趣。其中一部分是了解您所处环境的规模，一部分是了解您启动地点的提示限制，但想法是：Spark 是贪婪的。假设你正在做一些事情，即使是非常简单的事情，比如 Spark 自带的 SparkPi 示例，你要求十万个切片。现在，Spark 要征集十万个执行者。如果它得到 40，它会运行得很好，但它会一直询问，直到它得到它能得到的一切。
因此，要成为一名好租户，您可以做的一件事就是为您的要求设置一个最大值。比方说，我想运行十万个切片。我想使用 Spark 动态分配，但不要要求超过 100 个执行程序——我们知道这将为我们提供所需的性能，但会为其他用户留出可用资源，同时允许我们满足任何类型的 SLA。这是一个非常简单的例子，说明租赁如何成为一种有效的 Spark 性能调优实践。
亚历克斯：另一个需要考虑的 Spark 调优技巧是你如何调整大小。因此，如果您的数据集可以进一步细分，这再次取决于您对自己数据集的了解，那么这可能对环境更有利，而不是要求少数 90 或 100 位执行者——那听起来确实很荒谬，但我们确实看到了这一点——要求 10 到 20 个零工执行者，并进一步分解你的数据集。
这可能对你有好处，因为你更有可能在系统上获得这些执行者，而且它肯定会对尝试使用同一系统的其他人有好处。因为如果你设法在一个节点上启动一百个演出执行器，那通常是一个节点空间的 50% 以上，有时甚至可能是一个节点空间的 70%。所以第一，你将不得不等待那个空间释放出来，第二，一旦你在那里，没有其他人在那里承受工作量。因此，如果您可以分解数据集以尝试确定适合环境的大小并允许其他人同时工作，那总是更好。
这是另一个可能有点困难，但仍然不太难做的事情。我的意思是，如果您正在处理二进制 blob 数据集，并且它们只以特定大小出现，那么您无能为力。几乎所有其他方面都可以改进。有时甚至像我们的最后一个问题一样，加盐，因为也许你有一个执行者正在耗尽所有这些内存，因为那是所有数据所在的地方。
您没有解决 SKU 问题，而是一直在增加内存直到它运行。所以这是解决这个问题的一个好方法。核心方面也是一样。 CPU 的处理能力有限，如果您的代码是多线程的，有时您会使用比您要求的内核更多的内核。因此，请牢记可用的资源以及其他人正在使用的资源，并确保您做出明智的决定，这些决定既能帮助您适应那些资源受限的环境，又能让其他人在您使用时继续使用它们.
Kiana：好吧，Alex，谢谢你抽出时间来。很高兴能更深入地研究您常用的 Spark 性能调优技巧以及您在网络研讨会中谈到的一些主题。
再一次，对于我们的读者，如果您想观看完整的网络研讨会，Spark 绩效管理的最佳实践，它在本次采访所在的页面上有链接。此外，请查看有关 Spark 优化的视频，以获得更直观、更深入的演示。
如果不在对话中包括 Kubernetes，就很难讨论 Spark。许多用户在 Kubernetes 上运行 Spark，后者提供自动化和无缝的应用程序部署、管理和扩展。由于 Kubernetes 是一个开源框架，用户喜欢在 Kubernetes 上部署 Spark 并从其自动化和易于管理中受益，而无需增加成本。
也就是说，未优化的 Spark-Kubernetes 配置可能导致资源分配和利用不佳。当用户在 Kubernetes 上部署 Spark 而没有完成任何 Spark 性能调整时，这可能会导致性能不佳和成本失控。
对于开发人员来说，优化 Spark 和 Kubernetes 以最大限度地发挥这两种工具的优势、提高性能并实现所需的输出，同时保持成本可控，这一点至关重要。