大数据处理框架的类型、比较和挑拣

 

　　从今天的眼光来看，MapReduce作为Hadoop默认的数据处理引擎，存在着很多的不足。比如：编程模型抽象程度较低，仅支持Map和Reduce两种操作，需要手工编写大量的代码;Map的中间结果需要写入磁盘，多个MR之间需要使用HDFS交换数据，因此不适合迭代计算(机器学习、图计算);任务的启动和调度开销较大等。随着更多高性能处理引擎的发展，目前在企业中使用MapReduce进行计算的应用已经呈下降趋势(HDFS及YARN仍然被广泛使用)，但虽然如此，MapReduce作为最早的大数据处理引擎，仍然值得被我们铭记。

 

　　四、流处理系统

 

　　批处理系统好理解，那什么是流处理系统呢?小学的时候我们都做过这么一道数学题：一个水池有一个进水管和一个出水管，只打开进水管8个小时充满水，只打开出水管6个小时流光水，那么同时打开进水管和出水管，水池多长时间充满水?

 

　　好吧，这道题的答案是永远也充不满……因为出水管出水比较快嘛。流处理系统就相当于这个水池，把流进来的水(数据)进行加工，比如加盐让它变成盐水，然后再把加工过的水(数据)从出水管放出去。这样，数据就像水流一样永不停止，而且在水池中就被处理过了。所以，这种处理永不停止的接入数据的系统就叫做流处理系统。

 

　　流处理系统与批处理系统所处理的数据不同之处在于，流处理系统并不对已经存在的数据集进行操作，而是对从外部系统接入的的数据进行处理。流处理系统可以分为两种：

 

　　逐项处理： 每次处理一条数据，是真正意义上的流处理。

 

　　微批处理： 这种处理方式把一小段时间内的数据当作一个微批次，对这个微批次内的数据进行处理。

 

　　不论是哪种处理方式，其实时性都要远远好于批处理系统。因此，流处理系统非常适合应用于对实时性要求较高的场景，比如日志分析，设备监控、网站实时流量变化等等。由于很多情况下，我们想要尽快看到计算结果，所以近些年流处理系统的应用越来越广泛。下面我们来了解两种流处理系统。

 

　　Apache Storm

 

　　Apache Storm是一种侧重于低延迟的流处理框架，它可以处理海量的接入数据，以近实时方式处理数据。Storm延时可以达到亚秒级。Storm含有如下关键概念：

 

　　Topology：Storm topology中封装了实时应用程序的逻辑。Storm topology类似于MapReduce作业，但区别是MapReduce最终会完成，而topology则会一直运行(除非被强制停止)。Topology是由spouts和bolts组成的DAG(有向无环图)。

 

　　Stream:Stream是一种不断被接入Storm中的无界的数据序列。

 

　　Spout：Spout是topology中Stream的源。Spout从外部数据源读取数据并接入到Strom系统中

 

　　Bolt：Bolt用于Storm中的数据处理，它可以进行过滤、聚合、连接等操作。将不同的bolt连接组成完整的数据处理链条，最后一个bolt用来输出(到文件系统或数据库等)。

 

　　Storm的基本思想是使用spout拉取stream(数据)，并使用bolt进行处理和输出。默认情况下Storm提供了“at least once”的保证，即每条数据被至少消费一次。当一些特殊情况(比如服务器故障等)发生时，可能会导致重复消费。为了实现“exactly once”(即有且仅有一次消费)，Storm引入了Trident。Trident可以将Storm的单条处理方式改变为微批处理方式，但同时也会对Storm的处理能力产生一定的影响。

 

　　值得一提的是，一些国内的公司在Storm的基础上进行了改进，为推动流处理系统的发展做出了很大贡献。阿里巴巴的JStorm参考了Storm，并在网络IO、线程模型、资源调度及稳定性上做了改进。而华为的StreamCQL则为Storm提供了SQL查询语义。

 

　　Apache Samza

 

　　提到Apache Samza，就不得不提到当前最流行的大数据消息中间件：Apache Kafka。Apache Kafka是一个分布式的消息中间件系统，具有高吞吐、低延时等特点，并且自带了容错机制。以下是Kafka的关键概念：

 

　　Broker：由于Kafka是分布式消息中间件，所以需要多个节点来存储数据。Broker即为Kafka集群中的单个节点。

 

　　Topic：用于存储写入Kafka的数据流。如同它的字面含义——主题，不同主题的数据流最好写入不同的topic，方便后续的处理。

 

　　Partition：每个topic都有1到多个partition，便于分散到不同的borker中。多个partition的数据合并在一起组成了topic完整的数据。

 

　　Producer：消息的生产者，用来将消息写入到Kafka集群。

 

　　Consumer：消息的消费者，用来读取Kafka中的消息并进行处理。

 

　　虽然Kafka被广泛应用于各种流处理系统做数据源，但Samza可以更好的发挥Kafka架构的优势。根据官网的解释，Samza由三个层次组成：

 

　　数据流层 执行层 处理层 支持三个层次的组件分别为： Kafka YARN Samza API

 

　　也就是说，Samza使用Kafka提供了数据流，使用YARN进行资源管理，自身仅提供了操作数据流的API。Samza对Kafka和YARN的依赖在很多方面上与MapReduce对HDFS和YARN的依赖相似。

 

　　如果已经拥有Hadoop集群和Kafka集群环境，那么使用Samza作为流处理系统无疑是一个非常好的选择。由于可以很方便的将处理过的数据再次写入Kafka，Samza尤其适合不同团队之间合作开发，处理不同阶段的多个数据流。

 

　　五、混合处理系统：批处理和流处理

 

　　一些处理框架既可以进行批处理，也可以进行流处理。这些框架可以使用相同或相关的API处理历史和实时数据。当前主流的混合处理框架主要为Spark和Flink。

 

　　虽然专注于一种处理方式可能非常适合特定场景，但是混合框架为数据处理提供了通用的解决方案。

 

　　Apache Spark

 

　　如果说如今大数据处理框架处于一个群星闪耀的年代，那Spark无疑就是所有星星中最闪亮的那一颗。Spark由加州大学伯克利分校AMP实验室开发，最初的设计受到了MapReduce思想的启发，但不同于MapReduce的是，Spark通过内存计算模型和执行优化大幅提高了对数据的处理能力(在不同情况下，速度可以达到MR的10-100倍，甚至更高)。相比于MapReduce，Spark具有如下优点：

 

　　提供了内存计算模型RDD(Resilient Distributed Dataset，弹性分布式数据集)，将数据读入内存中生成一个RDD，再对RDD进行计算。并且每次计算结果可以缓存在内存中，减少了磁盘IO。因此很适用于迭代计算。

 

　　不同于MapReduce的MR模型，Spark采用了DAG编程模型，将不同步骤的操作串联成一个有向无环图，可以有效减少任务间的数据传递，提高了性能。

 

　　提供了丰富的编程模型，可以轻松实现过滤、连接、聚合等操作，代码量相比MapReduce少到令人发指，因此可以提高开发人员的生产力。

 

　　支持Java、Scala、Python和R四种编程语言，为不同语言的使用者降低了学习成本。

 

　　而Spark的流处理能力，则是由Spark Streaming模块提供的。Spark在设计之初与MapReduce一样是用于批处理系统，为了适应于流处理模式，Spark提出了微批次(Micro-Batch)的概念，即把一小段时间内的接入数据作为一个微批次来处理。这样做的优点是在设计Spark Streaming时可以很大程度上重用批处理模块(Spark Core)的代码，开发人员也不必学习两套编程模型。但缺点就是，与Storm等原生的流处理系统相比，Spark Streaming的延时会相对高一些。

 

　　除了最初开发用于批处理的Spark Core和用于流处理的Spark Streaming，Spark还提供了其他编程模型用于支持图计算(GraphX)、交互式查询(Spark SQL)和机器学习(MLlib)。

 

　　但Spark也不是没有缺点。在批处理领域，由于内存是比硬盘更昂贵的资源，所以Spark集群的成本比MapReduce集群更高。而在流处理领域，微批次的架构使得它的延时要比Storm等流处理系统略高。不过瑕不掩瑜，Spark依然是如今最炙手可热的数据处理框架。

 

　　Apache Flink

 

　　有趣的是，同样作为混合处理框架，Flink的思想与Spark是完全相反的：Spark把流拆分成若干个小批次来处理，而Flink把批处理任务当作有界的流来处理。其本质原因是，Spark最初是被设计用来进行批处理的，而Flink最初是被设计用来进行流处理的。这种流处理优先的方式叫做Kappa架构，与之相对的使用批处理优先的架构叫做Lambda架构。Kappa架构会使用处理流的方式处理一切，以此来简化编程模型。这一切是在最近流处理引擎逐渐成熟起来才有可能实现的。

 

　　Flink的流处理模型将逐项输入的数据作为真实的流处理。Flink提供了DataStream API用于处理无尽的数据流。Flink的基本组件包括：