我们的一位客户是专门从事设计和制造软件解决方案的软件开发商。这家软件公司为工程、建筑、制造、娱乐等主要行业的一些最大组织提供服务。我们客户推出的每个新软件和更新都必须满足严格的 SLA 要求。

为确保其产品按照 SLA 的规定运行，该软件公司利用 Apache Spark 来处理和分析大量大数据并收集可操作的见解。这些见解反过来又为软件开发人员提供了有价值的信息，使他们能够快速识别和解决性能问题并推出更好的产品。

但是，该公司缺乏 Spark 方面的专业知识。最重要的是，他们没有一个全面的可观察性工具来衡量 Spark 的性能，也没有帮助他们识别和解决 Spark 带来的复杂问题。结果，软件供应商没有从其 Spark 投资中获得最大价值。直到 Pepperdata 出现并改变了公司与 Spark 的合作方式。

虽然 Spark 使这家软件公司能够分析大量大数据并获得有关绩效、客户旅程、销售等方面的可行见解，但他们未优化的 Spark 性能让他们付出了很多代价。

使情况变得更加复杂的是软件公司没有内部 Spark 专业知识。由于没有足够的 Spark 框架知识和经验，软件公司被迫做出他们认为最合乎逻辑的选择：投入更多计算资源。

虽然这样的方法让他们可以运行更多的 Spark 作业，但 Spark 性能本身并没有得到优化。他们也没有可观察性工具来查看他们的 Spark 应用程序和工作流。这导致了更多的资源和计算能力浪费。随着公司的扩张，这个问题变得更加严重。更多的客户意味着更多的 Spark 工作。随后计算消耗的增加很快耗尽了他们的大部分大数据预算。

该组织与 Spark 的斗争并不是新闻。严重依赖 Spark 处理大数据工作负载的企业也会遇到同样的困难，尤其是资源利用率低和大数据预算超支。

成本是运行像 Spark 这样的大数据架构的主要问题之一。在我们最近的 2021 年大数据云调查中，64% 的公司表示，他们在使用大数据技术和应用程序时一直在与“成本管理和控制”作斗争。

虽然大多数云提供商提供自动缩放功能以帮助企业在流量激增期间满足计算资源需求，但默认的自动缩放配置是基于峰值级别的要求。这意味着许多大数据进程和工作负载都在未经优化的情况下运行。难怪许多企业的支出比最初的大数据云预算高出 40%。

许多企业最终过度配置了计算资源。虽然这种方法可确保他们在高峰时段拥有足够的资源，但当流量低于预期时，未使用的资源就会被浪费。在大数据和云计算的世界里，未利用的资源意味着损失金钱。

这家软件公司的大数据专家承认使用最理想的配置来调整 Spark 是多么困难。但他们知道他们需要一个强大的优化解决方案来扭转局面，使 Spark 成为高效、经济的大数据引擎。

到 2020 年，他们的数据处理需求比上一年增加了 10 倍。他们需要找到一种优化和可观察性工具来控制支出并最大限度地利用计算资源。

否则，使用添加更多资源的相同方法会导致成本过高，同时还会遭受性能滞后和停机的困扰。

软件组织知道他们需要对 Spark 和整体大数据基础架构进行观察，以发现问题、提高 Spark 性能并降低 Spark 成本。

在部署他们的 Spark 可观察性工具后不久，软件开发人员就能够从他们的 Spark 框架中获得强大且可操作的见解。