Apache Spark：更改架构之前必须解决的5个陷阱

迁移到Apache Spark之前需要了解的5件事

似乎每个人都只是在谈论最热门的新技术，而忽略采用它的真正含义。但这是自然的，对吧？新功能和承诺胜过其他一切，而艰巨的挑战和决定被抛在一边。

这次不行。软件架构很难，权衡取胜是游戏的名称。

在本文中，我们想退后一步，看看执行从头开始转向Spark的决定的真正含义。非常感谢Kenshoo的开发人员和系统架构师Tzach Zohar ，他在本博文中与我们分享了他的经验。

为什么还要烦恼呢？

如果您从一个可以从分布式数据分析中受益的全新项目开始，无论是批处理分析还是精简分析，Spark都已将其优势确立为MapReduce的最佳实现。主要是因为它使用内存处理的方式。否则，如果您在一台服务器上获得了所需的吞吐量，并且使用的数据不会超出该范围，那么最好避免使用分布式的复杂性。请注意，我们甚至一次都没有说过大数据。哦此外，Spark具有一个很棒且易于使用的机器学习库。
Spark与Hadoop

尽管您的起点很可能是您已经拥有的现有解决方案，但这会使事情变得多余。我们将把重点放在那上面。在难以应对规模的数据库之上从Hadoop或本地解决方案迁移。性能的提高最终可以减少硬件成本，提高生产力，或者实际上只是摆脱尝试做的事情的唯一方法。

最大的好处来自批处理分析的角度，因此，如果这是您的用例–升级集群将变得更加紧迫。就Kenshoo而言，单服务器MySQL解决方案已绰绰有余。但是随着公司的发展和几年的过去，这已经不够了–每天要处理成千上万条记录，数百张表，较大记录上的十亿条记录以及TB级的数据。不再是堪萨斯州了。有一点是，您无法进行所有优化，甚至TokuDB之类的高性能存储引擎也无法实现。您最终要做的是在类固醇上安装了一个突变MySQL。

在海岸的另一端，有Spark公司，它解决了各种各样的问题，这些新问题却是长期存在的原则，并得到社区的Swift采用和许多积极的信号。

1. HDFS与Cassandra与S3

您为Apache Spark选择的存储服务器应该反映出您对系统最看重的东西。这里的3个常见选项是Hadoop的HDFS，Apache Cassandra和Amazon的S3。当数据局部性不是关键时，S3适合非常特定的用例。例如，每天运行一次的作业，或者实际上不需要任何数据和处理能力来共享机器的任何事情。没有紧迫的工作。至于HDFS与Cassandra的问题，运行HDFS的硬件成本较低，因为它旨在解决更简单的用例。多低高达10倍。主要区别在于HDFS解决了分布式文件系统运行的问题，而Cassandra专门设计为高吞吐量键值存储。

尽管成本较高，但Cassandra在交互式流数据分析方面处于优势地位–与运行批处理作业相反。您可以说HDFS喜欢大文件，而Cassandra不必加载所有数据，仅使用所需的数据即可访问

S3 –非紧急批处理作业。
Cassandra –非常适合流数据分析，并且对批处理作业有过高的要求。
HDFS –非常适合批处理作业，而不会影响数据局部性。

2.绿地与重构

好吧，所以您现在决定迁移到Spark，您应该从全新的项目开始还是基于当前应用程序进行重构？每个人都有自己的警告，Kenshoo决定放弃绿地之路，以重构其当前系统。该决定缩小为4个因素：

避免移动目标场景 –从头开始构建新系统需要花费时间和数月的开发时间。在此期间，旧系统也在发生变化，因此您的规范实际上是随时间变化的移动目标。
零差异容限 –新系统应达到与旧系统相同的结果，对吗？听起来很简单的过程是一个变相的问题。经过多年的发展，针对特定分析过程的各种怪癖和定制已被硬编码到较旧的应用程序中。例如，某些假设，四舍五入的结果以及来自各个客户的请求–已经创建了一个复杂的分析过程，很难从头开始重新创建。
代码是唯一的规范 –文档很有可能……不存在。如果确实存在，则很可能不能反映系统的当前状态。这是您可能与代码中的那些黑角有关的示例：

“不应该”发生的事情，但是它发生了吗？
测试重用 –您当前的测试与较早的实现结合在一起，并采用了不同的设置。这里的另一个任务是重写它们以匹配新的实现。

底线：在这种情况下，重构而不是完全重新启动是最有意义的。

3.重构挑战

选择重构路径还面临挑战，未经测试的旧代码，与其他系统组件的紧密耦合以及新体系结构的范式转换。从类似的Hadoop架构进行切换比在单节点应用程序上进入分布式系统路径更容易。有许多新的知识要学习，要有调整的过程，还有很多摩擦。不论是否新建，这都是艰巨的任务，但是如果您确定这是值得的–隧道尽头便是一盏灯。

在Kenshoo的案例中，他们的任务是从一个拥有8年历史的庞大系统中释放瓶颈聚合器组件。聚合器偶尔对数据执行批处理，并通过不同的键将其分组。

底线：在移动之前预先了解您的薄弱环节，并确保针对新实施中的关键路径具有解决方案。

4.解决方法

4.1。核心业务规则至上

重构的主要好处之一当然是代码重用。构建新系统的第一步是首先遵循核心业务规则，并从中创建一个独立的jar。这些方法被重构为Java静态方法，以避免Spark中的序列化问题。

4.2。 Dropwizard指标和复杂的遗留代码

继续前进，还记得“不应该发生”的例子吗？ Kenshoo使用Dropwizard Metrics计数器进行装配：

而且你知道什么。它确实发生了很多：

发生…..“这不应该发生”

底线：事实证明，使用度量标准来度量遗留代码中的未知数是一个功能强大的工具，它可以将“隐藏”功能转变为明确的，经过良好记录和经过良好测试的功能。

4.3。本地模式测试

为了应对测试挑战，Kenshoo充分利用了Spark的本地模式并从中汲取了灵感–在新的聚合组件内部创建了一个类似Spark的嵌入式实例。此外，他们然后采用了这个新组件，并将其嵌入到旧系统中，重用了较早的测试，并确保新系统满足所有要求：

4.4。石墨“ diffRecorder”

除了本地模式测试之外，最后的领域是测试生产中的实际数据，并查看Spark结果是否与旧系统的结果匹配。为此，实现了与Graphite可视化挂钩的“ diffRecorder”。差异记录器将这两个版本有所不同的每个实际输入表示为Graphite Metric（石墨度量），并指出与新实现不一致的确切输入。

生成的数据有助于了解需要进行哪些调整以匹配旧系统（或发现系统中的隐藏故障）。顺便说一句，要了解有关Graphite的更多信息，可以查看有关为系统选择最佳Graphite体系结构的文章。

Kenshoo的Graphite仪表板

5.火花监控

Spark与Graphite进行了很好的集成，您可以在其中绘制任何您想要的图形。除此之外，这里的第二个工具是Spark Web UI，用于查看您的作业和性能指标。任何严肃的Spark部署都需要在性能和监视方面投入大量精力。这可能会成为一个非常棘手的问题，您需要熟悉内部结构才能调整系统。为Spark编写代码很容易，但是性能又增加了另一层复杂性。从这个意义上讲，很容易在这里出错并产生错误的代码。

查看这篇文章，我们探讨了Taboola的Spark监视架构，以及为什么他们要继续将Takipi添加到其监视堆栈中。

结论

存储，重构技术，监视，测试重用和一致的结果–我们希望您发现所提供的解决方案有用，并且知道如何在需要时应用它们。向新技术的过渡非常困难。除了学习曲线外，它们还使您更容易出错（也使您更有可能在半夜接听电话以解决某些关键的生产问题）。针对这种情况，我们启动了Takipi对Spark的错误分析。

我们要再次感谢Kenshoo的Tzach Zohar与我们分享他的经验！

翻译自: https://www.javacodegeeks.com/2015/08/apache-spark-5-pitfalls-you-must-solve-before-changing-your-architecture.html