标签:分布式计算 流式计算 storm spark 增量计算
本文是我对分布式计算的算子这层的一些认识和想法。因为最近自己的开发任务也是这方面相关的,公司内部有自研的类流式计算框架需要做一层算子层。我主要分析的是流式系统上实现算子这一点入手,对比现有计算框架和业界正在开展的项目,分析分析这件事的表面和背后深层的含义,以及可想象空间。
Yahoo! 的Pig on Storm项目,让Pig-latin能够执行在Storm这种流式引擎上,最终使得Pig-latin能够混用于流式计算和批量计算场景下。应该说,无论是Spark,Summingbird,还是Pig,都在尝试做同一件事情:借助自己的DSL或原语在流式和批量两套引擎上表达(近)实时和离线数据处理能力。
Spark本身依赖RDD,实现了Spark Streaming这种小批流计算,其DStream就是RDD,所以在Spark上写批量作业和流式作业API自然是统一的。
Summingbird在API层面统一了Storm上和Hadoop上的作业,对于Hadoop上任务的编写借助的是Cascading,属性上看更多的是一种适配的角色,虽然Summingbird也称为Lambda Architecture的一种解决方案。
总结:表面上看,DSL需要支持不同的计算引擎,以达到算子层面的混用,这是趋势。那么实现上的难度在哪呢?
在流式系统上实现pig-latin这种本身就诞生于批量计算场景里的DSL,对某些关系型操作会有语义层面的不清晰性,具体可以看Pig on Storm初步讨论。对于filter,foreach,union,甚至稍微复杂点的需要借助state的distinct,limit,在批量和流式场景下都是没有歧义的,实现起来不会有太大的区别或难度。但是像两流做sql语义里的join,或者多流做pig语义里的group,cross的时候,流式上的实现就不一致了,而且这个原语的定义也不同了。
在流式系统上实现DSL或者一套FlumeJava,关键在能把UDAF给实现了。而要实现UDAF,就涉及到了跨批的事情。这件事情本质上需要引擎的支持,比如Trident有SpoutCoordinator作流控,还具备一定的事务性,那么在你要做跨批之间的UDAF的时候呢,可以借助Trident的State,也就是辅助存储,调用persistAggregate这样的操作来完成。如果引擎不支持的话,比如原生Storm的接口,就没办法做流式DSL。
那么像Spark那样又不同,因为Spark本身不是流式系统,他的Spark Streaming上可以实现DSL,甚至可以和Spark SQL结合起来跑Streaming形式的SQL,原因是Spark是批量计算框架,所以他可以做类流式DSL。
总结:实现上看,流式系统上实现DSL难点在UDAF,本质上是跨批计算。那么流式上的跨批可以抽象为一种怎样的模式呢?
之前在杭州Spark meetup,分享Spark SQL的时候,我提到过Spark RDD最重要的两层意义:原语的丰富和数据表示能力。前者使得Spark编程很easy,后者使得计算结果做到了reuse,适应了MR模型、迭代计算模型、BSP模型。基于这两点,Spark Core上可以轻松衍生出SQL产品、机器学习产品、图计算产品、流计算产品。
反观流式系统,比如Storm,原语要简单丰富易用不是难事,问题是你数据能reuse吗?!reuse有什么优点?拿RDD来说,节省内存空间以及并发的计算能力。RDD在设计之初就是immutable的,而且在计算内部消化掉了MapReduce,而暴露出丰富的Transformation和Action。在论文中,RDD与DSM(Distributed Shared Memory)也进行了多维度的对比。应该说,Matei在设计RDD之前的参与Hadoop MapReduce源码的开发经验,加上当时其他系统内DSM的差异设计,以及Google FlumeJava,微软DryadLINQ在API层面的理念,最终揉合成了RDD这套东西。现在只有Spark现在实现了它。
最近我在增量计算引擎上实现的算子层,也是参考了FlumeJava,Trident,RDD设计出来的,还在测试中。就像我开头说的,Pig on Storm这件事情,换引擎是表面。背后意义是算子层面的混用,最终的想象空间是一层统一的DAG,上面承接Pig、Hive、SQL等DSL,下面对接不同的计算系统。实现起来是不困难的,困难点可能不是技术问题。
总结:RDD两个致命优点,easy to use和数据的reuse,是其他系统难达到的,特别是第二点,也是RDD的精髓所在。
marz做了Storm,ElephentDB之后,按照他的理解在how to beat CAP里提出了一种解决方案。在他提出的lambda achitecture里,Storm的定位在流式处理,而做类似ad-hoc的service layer是HBase。如果换做是我们目前的增量计算框架的愿景的话,我认为,流式和ad-hoc这层有望被增量计算引擎统一。为什么?
Query = Function(All Data)
Data静,Query动,是ad-hoc计算;Data动,Query静,是流式计算;Data动,Query动,是持续计算。Storm处于第二者,增量计算框架可以做到第三者。Storm的拓扑提交是个严重问题,等Nimbus拉起bolt和spout的时候,黄花菜都凉了。它的确适合流式计算,为什么呢,因为流式的本质就是消息。Storm抽象的那层拓扑,bolt之间的消息通道,ack机制都很不错,这层抽象满足了流式计算,但是work这层以及调度这层远远不满足Query不断变化而仍需要流式计算的场景。我们现在做的框架将来会满足这件事情,从此统一了流式、批量、迭代,超越现在的流式计算,不仅仅是StreamSQL,Stream上的DSL都是可以通过算子层来实现的。
总结:Data动,Query动的场景如何统一解决?增量计算想象空间巨大,算子层重要性突显。
全文完 :)
标签:分布式计算 流式计算 storm spark 增量计算
原文地址:http://blog.csdn.net/pelick/article/details/39577785