Apache Spark：转变架构前必须解决的5大陷阱

2015-11-24 小象

原文地址：http://blog.takipi.com/apache-spark-5-pitfalls-you-must-solve-before-changing-your-architecture/

译者：丘志鹏

审校：林炀

责编：小象

小象科技原创作品，欢迎大家疯狂转发；

机构、自媒体平台转载务必至后台留言，申请版权。

 

 

当你开始使用Apache Spark之前必须了解的5大关键讯息

 

>当人们谈及最新最热的技术的时候，我们总是习惯性的去适应这项技术存在的缺陷。这都是很自然养成的行为不是吗？所有最新的特性总是能盖过一切，而对困难的挑战向来都是先被放置到一边。

 

Java/Scala开发人员注意咯!Takipi项目将取代登陆生产端JVM并且能让你看到造成每个记录错误与异常的变量状态。

 

然而这一次不一样了，尽管软件架构是困难的，权衡整个架构才是本文要进行的主题。

 

▼▼▼ ▼▼▼

 

Spark的优势

 

当你开始一个全新的项目时，无论是批量分析还是流式分析，你终将得益于分布式数据分析。正如Spark是基于MapReduce算法实现的分布式计算，拥有Hadoop MapReduce所具有的优点，目前来说已经成为该领域最为强有力的工具，主要是因为它使用内存的方式来处理问题。否则，如果你只需一台服务器便能完成处理数据，那么你最好避免使用复杂的分布式处理。请注意，在这我们甚至没有提到一次大数据概念。此外，Spark还提供了一个丰富而又易于使用的机器学习库。

 

Spark vs.

Hadoop

 

多数情况下你的起点是一个现有的解决方案，然而在这个方案中也许存在额外的种种困扰，因此这篇文章我们将会把重点放置于此。从Hadoop或者本地迁移时人们都纠结于其规模。性能的提高最终会降低你的硬件成本，从而提高你的生产力，难道这不就是你平时苦苦追寻的吗？

 

最大的好处来自于批量分析角度，如果你的情况和以下用例很相似，那么这是你的用例-升级你的集群才是当务之急。在Kenshoo的案例中，单服务器MySQL解决方案曾经是绰绰有余。但是随着公司的成长，单服务器数据库已经不再足够——每一天都会产生成千数百万条记录、数百个表、直至超过十亿万亿条记录，这已经不再是以前的数据规模了。所以说在这基础上做的所有优化工作甚至采用类似于TokuDB这样高性能的引擎都是行不通的。这样做的后果就是最终只会构成一个畸形的MySQL。

 

然而在另一边Spark能解决各式各样的问题，虽然较之于Hadoop，Spark诞生的较晚，但是Spark拥有长期开发的原则，并且能获得大量来自社区的积极信号并及时进行采用。

 

HDFS vs.

Cassandra vs.

S3

 

你为Apache Spark所选择的存储服务器能反映出你最看重什么系统。这有3个常见的选项，他们分别是Hadoop的HDFS，Apache Cassandra和Amazon的S3。其中S3适合非常具体且数据本地化并不重要的用例，例如每天只运行一次的作业，或者不需要共享一台机器的数据和处理能力且不是很紧急的作业。至于HDFS与Cassandra这一块，运行在HDFS上硬件成本相对较低，因为它是为了解决简单的用例。到底有多低呢？起码低了10倍。它们的主要区别来自HDFS解决问题是运行在分布式文件系统中的，尽管Cassandra是专门为高通量键值存储设计的。

 

尽管成本更高，但是用在交互与流数据分析时，Cassandra还是占据着上风，反对运行批处理作业。你可以说HDFS偏爱于大文件处理，而Cassandra使用时没有加载所有数据，只是在需要的时候才去获取。

 

S3 –非紧急的批处理作业。

Cassandra –适合于流数据分析，不面向批处理作业。

HDFS –不介意是否数据本地化且适合于批处理作业。

 

Greenfield vs.

Refactoring

 

好的，因此你决定了转向Spark，那么现在，你应该开始新项目的建立还是对你当前应用进行重构呢？每种情况都有自己相对应的注意事项，而Kenshoo决定舍弃新建项目而支持重构他们当前的系统。以下四点因素将阐述执行这项决定的缘由：

 

1.避免一个时常变更的目标场景：从头开始建立一个新的系统需要时间的投入，起码也得需要几个月的开发。而在这段时间期间，遗留的系统也是在变化的，除了原有的问题需要解决之外，重新开发时也会面临着种种问题，因此的你说明书所需要解决的问题也不断叠加，就好像一个随着时间不断改变的移动靶子。

 

2. 零改进差异的容忍：新的系统应该至少达到和旧系统一样的处理结果，不是吗？这听起来像是一个简单的过程，却依然是个难题。随着多年的发展，所有特定分析过程中奇怪的、定制的项目被硬编码到旧的应用程序内部，其中包括某些假设、舍入的结果、个人客户的要求等。一旦创建了一个复杂的分析过程，就很难再从头重新创建了。

 

3. 代码是唯一的规范：文档丢失的情况可能会经常出现。即便尚未丢失，它仍然很有可能已经不反映系统的当前状态了，所以说代码是唯一的规范。下面是一个例子，你也可以回想一下那些曾经被你抛弃在角落的代码：

 

 

4.测试复用：用新写好的测试代码来检测之前编写的代码可能会导致测试的失败。因此产生的一个新的任务就是要重写旧的代码，以便让它们适应新的架构。

 

概要：在这种情况下，重构而不是重新启动新的项目，这样会减少无意义的工作。

 

重构的挑战

 

选择重构的道路也是极具挑战性的，像是未经测试的遗留代码、与其他系统组件的紧密耦合、和新的架构的范式转换都是需要我们去考虑的。作为一个单节点应用程序转换到一个类似Hadoop的架构显然是比转换到到别的分布式系统来得更容易。这需要学习许多新的技能，你会面临流程的适应以及一系列困难的挑战。无论是否进行重构，这都是一个艰难的任务。但是一旦你决定下来，那便是值得的。只要坚持，你终将看到曙光。

 

在Kenshoo的案例中，他们的任务是将一个瓶颈聚合器组件从一个存在8年历史的巨型系统中抽离。这个聚合器偶尔执行批处理数据并且能根据不同键值分组。

 

概要：在行动之前知道你的弱项所在，确保自己在面对各种困难时知道解决的方法。

 

解决方案

 

➔核心业务规则第一

重构的主要好处之一当然是代码重用。构建新系统的第一步是先理解核心业务规则并创建一个独立的jar。在Spark中通过重构Java的静态方法可以避免序列化问题。

 

➔DropwizardMetrics和解决遗留代码

还记得上文提到的代码的实例吗?Kenshoo采用 Dropwizard Metrics 的counter方法来解决:

 

 

概要：使用Metrics这个强大的工具来衡量未知的遗留代码,它允许将“隐藏”属性转化为明确，并且拥有齐全的文档资料，以及完善的测试功能。

 

本地模式测试

 

为了尝试测试挑战，Kenshoo从Spark本地模式获得灵感，创建了一个类似于Spark内部聚合功能的嵌入式组件。此外，他们将这个新的组件，嵌入到遗留系统中，重用测试，并且确保新的系统能满足所有要求。

 

 

性能监控Graphite

工具中的diffRecoder

 

最后，在本地模式测试能力之外，还需要测试在生产环境中的实际数据并且看看Spark下的结果是否匹配之前遗留系统的结果。为了达成这个目的，通过实现了一个"diffRecorder"类 ，在Graphite可视化界面便能看到相应的视图。这个Diff Recorder代表每一个实际输入于新旧两个版本中结果的差别，并作为一个Graphite Metric，重点是准确的输入其实有时候会和新的实现并不相一致。

 

结果数据能帮助我们理解如何针对旧系统的匹配作出进一步的调整（或者在系统中发现隐藏的缺点），顺便提到一句，如果想了解更多关于Graphite 的详情，可以参考这篇文章《为你的系统选择最好的Graphite 架构》。

 

Kenshoo的Graphite 仪表盘面板

 

Spark监控

 

Spark对Graphite 有很好的集成，你可以绘制任意的你所想到的图形。除此之外，Spark 网页UI界面还能用于查看你的工作情况和性能指标。如果你想要认真的部署好你的Spark，那么你需要投入大量的心思在性能与监控上。这可能是个很棘手的问题，因此你需要熟悉内部优化结构。为Spark编码是件容易的事情，但是要兼顾到性能方面那么就挺复杂了。在这个意义上，它其实是很容易出错的，并且有可能会生成一些错误的代码。

 

上手Spark的

相关推荐资源

 

基础文档尽管十分简短，但能让你完成相关作业。想要更进一步了解Spark性能调优，可以查阅历史Spark summit记录。