Spark、HPCC与Hadoop计算模型之趣味比较

摘要: Spark是继Hadoop之后的新一代大数据分布式处理框架，HPCC是基于LexisNexis公司发布的开源的数据处理方案，LexisNexis公司宣称其处理工作负载的能力要优于Hadoop。该系统在10年前帮助LexusNexis公司的Risk Solutions分析大量的客户数据。

Spark是继Hadoop之后的新一代大数据分布式处理框架，HPCC是基于LexisNexis公司发布的开源的数据处理方案，LexisNexis公司宣称其处理工作负载的能力要优于Hadoop。该系统在10年前帮助LexusNexis公司的Risk Solutions分析大量的客户数据。并在金融业和其他重要的行业中应用。看来HPCC（High-Performance Cluster Computing 高性能集群计算）似乎有能力成为替代Hadoop的解决方案。

Spark，HPCC和Hadoop有什么不同呢?

　　【1.Spark的中间数据放到内存中，对于迭代运算效率比较高】

MapReduce和Sparkis的一个主要区别，MapReduce是非周期性。也就是说，数据流从一个稳定的来源，加工，流出到一个稳定的文件系统。“Spark允许相同的数据，这将形成一个周期，如果工作是可视化的迭代计算。)

　　Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面，有RDD的概念。弹性分布式数据集（RDD）作为原始数据的抽象，和一些数据保存在内存中缓存供以后使用。最后这点很重要;spark允许在RAM致力于为近似20X基于加速了MapReduce的磁盘上的数据。RDDs是不可改变的，并通过并行转换，如地图，过滤器，GroupBy和减少创建的。

　　RDD可以cache到内存中，那么每次对RDD数据集的操作之后的结果，都可以存放到内存中，下一个操作可以直接从内存中输入，省去了MapReduce大量的磁盘IO操作。这对于迭代运算比较常见的机器学习算法来说，效率提升比较大。但是由于Spark目前只是在UC Berkeley的一个研究项目，目前看到的最大规模也就200台机器，没有像Hadoop那样的部署规模，所以，在大规模使用的时候还是要慎重考虑的。

　　【2.Spark比Hadoop更通用】

　　Spark提供的数据集操作类型有很多种，不像Hadoop只提供了Map和Reduce两种操作。比如map, filter, flatMap,sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort,partionBy等多种操作类型，他们把这些操作称为Transformations。同时还提供Count, collect, reduce, lookup, save等多种actions。

　　这些多种多样的数据集操作类型，给上层应用者提供了方便。各个处理节点之间的通信模型不再像Hadoop那样就是唯一的Data Shuffle一种模式。用户可以命名，物化，控制中间结果的分区等。可以说编程模型比Hadoop更灵活。

　　不过论文中也提到，Spark不适用那种异步细粒度更新状态的应用，例如web服务的存储或者是增量的web爬虫和索引。就是对于那种增量修改的应用模型，当然不适合把大量数据拿到内存中了。增量改动完了，也就不用了，不需要迭代了。

　　【3.容错性】

　　从Spark的论文《Resilient Distributed Datasets: AFault-Tolerant Abstraction for In-Memory Cluster Computing》中没看出容错性做的有多好。倒是提到了分布式数据集计算，做checkpoint的两种方式，一个是checkpoint data，一个是logging the updates。貌似Spark采用了后者。但是文中后来又提到，虽然后者看似节省存储空间。但是由于数据处理模型是类似DAG的操作过程，由于图中的某个节点出错，由于lineage chains的依赖复杂性，可能会引起全部计算节点的重新计算，这样成本也不低。他们后来说，是存数据，还是存更新日志，做checkpoint还是由用户说了算吧。相当于什么都没说，又把这个皮球踢给了用户。所以我看就是由用户根据业务类型，衡量是存储数据IO和磁盘空间的代价和重新计算的代价，选择代价较小的一种策略。

　　【4.关于Spark和Hadoop的融合】

　　不知道Apache基金会的人怎么想的，我看Spark还是应该融入到Hadoop生态系统中。从Hadoop 0.23把MapReduce做成了库，看出Hadoop的目标是要支持包括MapReduce在内的更多的并行计算模型，比如MPI，Spark等。毕竟现在Hadoop的单节点CPU利用率并不高，那么假如这种迭代密集型运算是和现有平台的互补。同时，这对资源调度系统就提出了更高的要求。有关资源调度方面，UC Berkeley貌似也在做一个Mesos的东西，还用了Linux container，统一调度Hadoop和其他应用模型。

（这是趣味编程关于移动互联网，车联网，电动汽车，新商业模式的观察和思考，搜索“趣味编程”即可关注我们，每天发一条消息，微信号:softsys