纸上谈兵YARN、Spark、Storm、Flink

在之前搜狗工作写的程序百分之八十都是Map-Reduce程序,对当时的Hadoop 1.x框架还是很熟悉的,也一直在关注着大数据模型业界动态。近些年在快仓一直因为业务规模相对比较小,程序都是单机部署,对新的流行的大数据模型虽有耳闻,却一直没有进一步了解。这段日子在想智能化仓库的调度系统云端解决方案到底是什么样子的,之前写过一篇关于Mesos应用的思考,借这个机会也调研了几篇现在应用比较广的框架论文(YARN、Spark、Storm、Flink),参考论文见最后的Reference部分,并没有深入实践过,纸上谈兵容易忘记,记录下来。

为什么一定要云端发布呢?

本地发布也有很明显的优势:

我理解云端的好处是:

凡事都有利弊,云端是不是更好,以及什么样的云端架构更合适都需要更大的智慧,这不是这篇文章纠结的点

YARN

Hadoop 2.0之前的Hadoop平台是一个为Map-Reduce定制的计算平台,虽然取得了巨大的成功,但也遇到了不少问题,《Apache Hadoop YARN: Yet Another Resource Negotiator》这篇文章列举了“十宗罪”,2.0进化出了YARN平台,可以说是十分了不起的架构升级,最主要的工作如下:

Hadoop 1.x阶段备受争议的JobTracker设计被拆解为了独立的两块:Resource Manager和Application Manager。这个架构升级让YARN不仅仅是支撑Map-Reduce的运行平台,包括后面提到计算框架也都可以运行在YARN平台上。

image

在新的YARN架构上,抽象出下面几个主要模块:

Resource Manager

Resource Manager会做:

Resource Manager不会做:

Application Manager
Node Manager

每台机器上会有一个NodeManager进行管理:

Spark

Map-Reduce在业界取得了巨大的成功,但是它也不是银弹,Map-Reduce对数据的使用采用的方式是“阅后即焚”,即读过一次后就丢弃掉,如果还需要使用要重新再运行一个Map-Reduce任务重新从HDFS上再读一次数据。这对一些应用来说是很低效的,比如:

Spark就是针对这种“内存导向型”的应用提出的解决方案。Spark的核心模型是resilient distributed dataset(RDD)数据结构,该数据结构可以缓存在分布式机器的内存中,随时可以使用,而且支持容错机制,即使部分机器宕机,仍然可以恢复出该数据。

spark利用RDD的抽象机制,把数据尽可能hold在内存中,这在一些经典的机器学习问题上的训练速度可以比hadoop快十倍以上。

总体上说,Spark编程模型包括三部分:

RDD 数据模型

RDD的来源只有两种:
RDD的存在形式:

当内存中无法存储所有rdd时,会采用lru的方式换入换出

RDD的表示:
RDD的管理:

通常由spark系统决定rdd的管理,同时spark也给用户提供了接口,支持用户对rdd进行操作:

RDD的好处:

基于RDD的并行操作

支持基于rdd的操作,例如:reduce、collect、foreach。。。

共享变量

Spark的Stream Process

Spark虽说是支持流式处理,但处理方式仍然是batch的模式,只是这个batch的大小会比较小,这点不同于storm,storm每条数据都会进行一次计算。spark stream(D-stream)方法是把流式计算理解为一系列很短时间间隔的批量计算

D-stream的低延迟:

不像hadoop需要把状态持久化到文件中,spark可以通过rdd的手段来把需要的数据cache在内存里,所以可以保证较低的延迟

错误恢复:

错误恢复可以利用每台机器分别恢复rdd的不同partition来做到并行恢复,加速恢复过程

模型一致性:

可以理解为模型一直在计算,在旧的数据算完之后,开始迭代新的训练样本

Storm

storm是一个分布式的、支持错误恢复的流式处理系统(基于YARN或Mesos),设计目标如下:

image

image

storm架构抽象:

image

storm支持两种数据保证:

在Twitter大部分storm拓扑在twitter是小于3个节点的,最长的有8个节点,99%的拓扑返回时间接近1ms

PS: 《Storm @Twitter》 paper里有大规模集群应用场景下调优zookeeper的经验,后续用到可以参考

image

Flink希望把批处理和流处理都规约到统一的一套流式处理系统里,它的架构模型包括Flink Client、Job Manager、 Task Manager十分类似Hadoop 1.0 里的client、jobtracker、tasktracker。 Flink会把任务抽象为有向图,节点是一些处理操作(operator),边代表信息流传输(数据或事件)。

Flink的数据流传输:

Flink实现迭代算法比较容易,只是在流处理的有向图的最后一个节点加一个条反馈边到初始节点

Reference

联系我: