分布式流数据实时与持续计算.pdf

分布式流数据实时与持续计算强琦hic20112011.12.3提纲•背景•目标•传统方案与业界进展•设计理念(重点)•技术架构•要点•例子•系统边界•计划背景•应用背景–数据量急剧增加–Web1.0Æweb2.0,publicÆegonet–电子商务、移动互联网、移动支付–欺诈、风控对海量交易实时性–用户体验的个性化和实时性–由点到面•实时搜索、个人实时信息服务、SNS等背景•技术背景–MapReduce、Dryad等全量/增量计算平台–S4、Storm等流计算框架–CEP以及EDA模型–Pregel等图计算模型传统方案与业界进展•传统方案–MAPREDUCE：HDFS加载，存储LOCALITY(容错性)，顺序IO，存储HDFS，单输入，单输出独立数据Latency(i)输入Di输入计算过程下载latency输出Mapshuffle独立数据DnLatency(n)reduceMapreduceJobIProcessJobHadoop之于实时•问题(hdhadoop本质是为全量而生)–任务内串行–重吞吐量，响应时间完全没有保证–中间结果不可见，不可共享–单输入单输出，链式浪费严重–链式MR不能并行–粗粒度容错，可能会造成陷阱–图计算不友好–迭代计算不友好图计算•MapReduce为什么不适合图计算?–迭代–边的量级远大于节点•图计算特点–适应于事件机制，规模大(边)，但单条数据不大–很难分布式(locality、partition，一直都是难点)–容错性–GlGooglePlPregel•本质上还是全量•中间结果不可见•超步过多(IProcess)Pregelvs.IProcess图计算•IProcess9乱序执行，避免了不必要的超步9实时图计算，图计算注定慢，但是效果的可以渐显。迭代计算•特点–结构固定•本质–UdUpdate•方案–传统MR模型，hadoop效率太低–Haloop–Iprocess0.4实时计算业界进展•S4–2010年底，Yahoo，0.3，windowtodo业界进展•Storm:2011.9，twitter，0.5.2业界进展‐Storm系统边界•S4、Storm–只能处理“独立”的流数据–无法处理“复杂”事件(condition)，需要用户handle复杂的条件–不能很好的适用于大部分需要相关数据集执行计算和流数据保序的实时场景–容错性较差–集群无法动态扩展业界进展•其它–StreamBase–Borealis–StreamInsight–Percolator–Hbasecoprocessor–Pregel–dremel–…设计理念•负责任(Condition)–MapReduce本质上保证了Reduce触发的条件，即所有map都结束（但这点很容易被忽视）。–实时计算Condition很容易被忽略。很多只是考虑了streaming，而没有考虑Condition。•实时(Streaming)•成本((gpThroughput)•有所为有所不为–通用计算框架，用户组件只需关心业务逻辑。–涉及到业务逻辑统统不做。设计理念•举例–实时JOIN(后面有具体代码)在storm（不考虑Condition）框架下，实现join，需要用户代码自己hold条件，判断条件，进而触发join后的逻辑处理。但在我们的设计理念下，这些condition完全可以抽象为复杂完备事件模型，所以作为通用系统应该提供condition的通用功能，用户只需进行配置而不是编码就可以完成condition，那么实时join在iprocess体系下，用户无需编码处理condition，而只需处理join后的逻辑。IProcess•通用的分布式流数据实时与持续计算平台–有向图模型•节点为用户编写的组件、边为事件–触发器模式–完备事件驱动的架构，定制复杂完备事件条件–支持相关集计算和Reduce时数据集生成(k‐mean)–树存储模型，支持不同级别定制不同一致性模型和事务模型–可扩展的编程模型•提出并支持树型实时MR和增量/定时MRIProcess•通用的分布式流数据实时与持续计算平台–持续与AdHoc计算((p)endpoint)–微内核+组件系统(系统级组件+用户组件)–多任务服务化，任务沙箱，优先级，任务调度–两级容错：应用级和系统级，运算时动态扩容–系统级组件系统：实时join、二级索引、倒排表、物化视图、counter…–分布式系统的容错，自动扩展，通讯，调度–保序…IProcess•基础的运行系统–引入CEP规则引擎模块（RPM），类似hive与MR–引入数据集控制（用于机器学习），BI–引入类SQL语言，DSL引擎–引入图计算模型逻辑模型持续计算•Ad‐HocQuery–不可枚举–用户搜索(online)，DBSQL•持续计算–计算相对