大数据准实时流式系统设计（一）——基于大数据框架设计

前段时间负责了公司一个新的项目，项目不属于直接面向用户的线上实时响应系统，要求做到尽快毫秒级或者秒级响应的准实时系统。结合以前学习的一些大数据理论方面和参与的准实时系统方面的经验，对准实时系统架构设计做个自我总结。

对我理解的准实时系统做个定义，一种区别线上实时响应系统，也不同于离线跑批系统时效滞后性，通常实时数据量还偏大，要求最快毫秒级或者秒级响应的系统形式。 一般准实时系统还要求，支持水平伸缩扩展，通过增加资源（机器、容器）线性提高并发量来保证高可用。

说准实时系统前，先要从开源批处理系统鼻祖Hadoop的MapReduce模型说起，MapReduce模型是谷歌在2004年在国际会议上发表的一篇关于分布式大数据编程模型。2004年，开源项目Lucene和Nutch的创始人Doug Cutting发现MapReduce正是其所需要的解决大规模Web数据处理的编程模型，基于Java设计开发了一个称为Hadoop的开源MapReduce并行计算框架和系统。MapReduce模型主要就是解决了大数据并行处理的技术难题，现在看来，MapReduce虽然也有不少局限性，但是其分布式并行处理的思想广泛影响了整个大数据世界的发展方向。下面通过一个典型的MapReduce模型的原理图开始说起：

忽略具体的技术细节，简化后看MapReduce模型，如下:

如图所示，Map过程对输入数据分而治之，每个Map的输出作为Reduce的输入,Reduce进一步把数据进行处理，得到输出结果。Map过程提供了大数据情况下经典的数据分而治之，把输入数据分散到多个Map进行数据拆分，处理完一起把数据输出到Reduce对应的实例（容器或者服务器），具体某个Map如果出现异常，其它机器能容错接过来该任务，MapReduce模型提供了大数据情况下高可用处理方案。

然后，MapReduce模型至少有以下几点自身的局限性，

1. 不适合做准实时大数据系统：MapReduce模型Map过程都是偏向处理一次输入的批量大数据，Map和Reduce每一步的输入输出数据都是落在硬盘，Reduce过程必须要等Map过程处理完，才能执行Reduce过程，因此，Hadoop不适合做大数据情况下的实时或者准实时系统，目前业界对Hadoop的定位也都是大数据批处理系统。
2. MapReduce模型不适合做复杂步骤的数据处理工作，经常业务场景需要对一批数据进行多个MapReduce操作才能达到业务上的处理效果。

             

针对MapReduce的以上问题，Spark都很好的解决了这些问题。首先应该说Spark怎么解决复杂多步骤任务计算，Spark提出了RDD DAG 的编程模型。

RDD 是一个只读的、分区的（partitioned）数据集合，RDD可以来源于HDFS这样的文件系统，也可以是上一部的RDD经过算子计算后的新RDD集合，问题2中的复杂多步骤计算任务，在Spark实际上可以表示成为一个或者多个RDD（上图的数据源是一个）通过算子连接的有向无环图，节点就是RDD,边就是算子，Spark支持大量的算子。

针对Hadoop存在的问题1，可以分为两部分来说：

第一部分，批处理过程的Map和Reduce过程为了分区容错都要落盘的情况，Spark通过分区一旦丢失就重新计算来解决，具体过程：另一个计算节点可以从它的前继节点出发、用同样的计算过程重算一次，然后，丢失的RDD就可以重新得到。

第二部分，Spark 支持Spark Streaming，Saprk Streaming通过将持续输入数据切分为一定大小的切片（mini-batch），用一系列的RDD + DAG的过程来处理每一个切片。如此一来，这多个RDD + DAG就变成了同一个批处理大任务被切割成多个在集群多个机器上小任务，Spark Streaming 就实现了变批量到流式处理了。哈哈，多年不学数学的我，第一次弄明白这一点的时候，马上想到了这不是微积分思想在大数据处理上的应用啊。

关于MapReduce模型不适合做复杂步骤的数据处理工作的劣势，因为复杂任务会是一个相对负责的MapReduce有向无环图，如果自己针对有向无环图每个节点去写Map和Reduce的话，成本会非常高。针对这种情况，Hadoop 生态专门有Pig语言和Hive框架分别针对不同的场景下复杂大数据处理工作，Pig语言简单概括就是对mapreduce算法实现了一套shell脚本；Hive框架主要做大数据数据仓库使用，数据仓库的各种数据纬度分析可以通过HSql语言来实现各种分析，原理也是把查询任务转换成一个复杂的有向无环图的MapReduce任务。

简单介绍了下Hadoop和Spark处理的编程模型，有没有发现Hadoop 和Spark 的长处都更是擅长大数据计算方面，Hadoop更实用做批处理任务，Spark不仅可以做批处理，还可以做流式大数据处理。基本上可以任务Spark继承了MapReduce所有优点，Spark在批处理上最大的优点是：不同于MapReduce的是Job中间输出和结果保存在HDFS中,Spark直接保存在内存中，同时RDD模型天然适合分布式数据处理模型理论。

流式处理系统除了使用Spark Streaming外，其实还可以使用Strom。通过上面的介绍，Spark Streaming 通过切片的方式来实现流式处理，而Strom 就是天生为流式处理而生。按照Storm设计者的说法，Storm对于实时计算的意义类似于Hadoop对于批处理的意义，在实时性上Strom优于Spark。

针对以上情况，如果让你设计一个准实时流式系统的话，我的建议是，如果你们公司已经有Spark集群，可以基于Spark Streaming 作为准实时系统的计算框架；如果没有的话，可以直接上Storm。

如果你们团队不熟悉常用的大数据框架，如果你们有kafka的使用经验的话，也可以使用kafka搭建准实时流式系统，后面会专门一篇写基于kafka设计准实时流式大数据系统。