在前1篇文章中,介绍到了Galaxy的增量计算性质,其state是框架内部管理的,和与Storm的简单对照。这篇文章将讲述更多Galaxy增量模型的事情,并介绍这套增量模型之上实现的Galaxy SQL和Galaxy Operator,同时会从增量角度对照Spark Streaming。
MRM模型全称为MapReduceMerge,比MapReduce做了1个Merge操作。merge阶段可与state交互,读写某个key的oldValue,并且这个merge接口还具有rollback语义。在流计算场景下,数据按时间或条数切成不同的批,批内可以做普遍意义下的MapReduce操作,批之间需要merge阶段做跨批聚合的计算。大家可以对照Spark Streaming的UpdateStateByKey操作,在1个DStream内,各个时间段内的RDD(即各批)可以通过这个接口更新1次任务内的state。而galaxy的merge本质上是1次add的进程,对应的rollback是1次delete的进程,从数据库的语义看,两个进程合起来相当因而update操作,而这俩进程都是根据1个primary key来做的,所以这件事情与spark streaming的updateStateByKey做的事情是1样的,但是细看的话,二者还是存在很大的差异。
galaxy的state暴露给计算task是线程级别独享的,spark streaming的state是任务内全局同享的。线程级别独享的优点,就在于同1批数据,按key shuffle以后来到不同的merge计算节点,各自不会阻塞各自的计算进程,而spark streaming的updateStateByKey操作会阻塞其他rdd的计算,虽然spark streaming能做到DStream内各个RDD并发履行,但是只要有state操作,终究还是落到了时间序列上的阻塞。本时间点StateRDD的计算需要依赖前1时间点父StateRDD的计算结果,而批内各个key对state操作是相互阻塞和影响的,所以着眼在这层barrier上的话,galaxy的merge进程更加精细,add和delete进程是分开的,批内的key是落到不同线程上计算而state是线程内独享的。
Galaxy有3种Model,分别是MapOnlyModel,MapReduceModel,MapReduceMergeModel。即,你可使用M Model和MR Model做普通的流计算或小批计算,当需要跨批操作的时候就使用MRM Model。Model之间是随便组合串连的,接口相比MapReduce实际上是相当灵活乃至过于灵活的,灵活的弊端是计算模型上带来复杂性。
Galaxy SQL是1种StreamSQL,而且是目前业界没有的。从语法上Galaxy SQL贴近HiveSQL,但又有些流计算语义上(无穷数据流)不能支持的语法,比如limit, order by。
Intel那边弄了1个Spark Streaming + Spark SQL的结合,叫StreamSQL。利用Spark SQL里的SchemaRDD,为Spark Streaming流进来的RDD带上了Schema元信息。借助Spark Streaming支持的操作,这类StreamSQL可以做滑窗效果的sql计算。但是真正跨批的增量语义(不单单是固定的window跨批计算),是支持不了的。Galaxy SQL可以做真实的增量流式SQL。
举个最简单的例子,
第1句sql中,根据t1的a字段分组,求了个count值。第2句sql中,t2表分组的字段变成t1表里count出来的cnt值。大家可以想象,在流计算场景里,第1次a求count出来的值多是100,下1个时间点,同1个a的key,count出来的值就是200了,这时候候,100这个cnt已丢到t2表里计算出结果了,现在100已更新到200了,200这个新的值的计算是简单的,但问题是如何把t2里之前100的计算结果撤消呢?
可以仔细想一想,StreamSQL是做不了这样的sql的,本质上是由于spark streaming不支持这样的操作。Galaxy计算框架的merge阶段可以做rollback操作,回滚之前"毛病"的状态,使得Galaxy SQL可以做散布式流式SQL。
Galaxy Operator是Galaxy MRM编程接口之上的1层DAG封装,兼具易用性和表达能力。
算子层终究将映照成多个Galaxy的MRM Model,使用户可以更加关注计算逻辑,屏蔽较复杂的MRM Model,特别是merge阶段。
生活不易,码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠