阿里分布式流数据实时与持续计算-20111124.

领域答辩-分布式流数据实时与持续计算领域2011-11-24Outline•背景•目标•职责•计划•团队•风险背景•业务背景–数据量急剧增加–互联网2.0时代，计算由点到边–电子商务和移动互联网，移动支付–欺诈，风控对海量交易实时性–用户体验的个性化–用户体验的实时性–实时搜索，风控，BNS，安全，网站交易，推荐等背景•技术背景–MAPREDUCE/DRYAD等全量/增量计算平台–S4,STORM等新型流计算框架–CEP以及EDA模型–Pregel等图计算模型传统方案与业界进展•传统方案–MAPREDUCE：HDFS加载，存储LOCALITY(容错性)，顺序IO，存储HDFS，单输入，单输出下载Map输入shufflereduce输入计算过程输出MapreduceJobIProcessJob独立数据Di独立数据DnlatencyLatency(i)Latency(n)不足•Hadoop–全量场景，任务内串行–重吞吐量，响应时间完全没有保证–中间结果不可见，不可分享–单输入单输出，链式浪费严重–链式MR不能并行–粗粒度容错，可能会造成陷阱–图计算不友好–迭代计算不友好业界进展•S4–2010年底，Yahoo，0.3，windowtodo•Storm–2011.9，twitter，0.5.2不足•S4，Storm处理“独立”流数据的处理。–无法处理“复杂”事件，需要用户handle复杂的条件–不能很好的适用于大部分需要相关数据集执行计算和流数据保序的实时场景。–容错性较差–集群无法动态扩展–只处理“流数据”实时方面业界进展•StreamBase•Borealis•StreamInsight•Percolator•Hbasecoprocessor•Baidu?•…图计算-pregel图计算•Mapreduce为什么不适合图计算?–迭代–边的量级远大于节点•Graphcomputing特点–适合事件机制，规模大(边)–局部性是难点容错性•Pregel–本质上还是全量–超步太多•iprocess–乱序执行，避免了不必要的超步–实时图计算，有些边慢，但效果可以渐显目标•通用的分布式流数据实时与持续计算平台•构建技术生态体系•全面提升业务的实时处理能力•业界有影响力的技术产品目标•通用的分布式流数据实时与持续计算平台–通用性，解决分布式系统中的问题–实时计算–持续计算–实时图计算–运算时扩容–应用，系统级容错–可扩展的编程模型目标•构建技术生态体系–IPROCESS与风控计算平台RPM–IPROCESS与BNS的图计算平台–IPROCESS与搜索数据中心，提供实时搜索服务–IPROCESS与SQL引擎•全面提升业务的实时处理能力–交易，用户行为的实时统计和数据挖掘–交易，欺诈，风险实时预警和响应–用户关系数据实时反馈和计算–实时搜索与网站数据实时处理和应用–实时业务数据统计–打通整站数据流的实时处理目标•业界有影响力的技术产品–具有原创技术并发表影响力论文(osdi2012,…)–业界有技术影响力的会议(hadoopchina2011)–Hive架设在IPROCESS–Nutch架设IPROCESS提供整套实时搜索方案–部分开放分布式存储建平台•通用的分布式流数据实时与持续计算平台–有向图模型，节点为用户组件，边为事件–子图优化，支持跨机器，同物理机多进程，线程池，单线程，保序–同时支持流模式(S4,STORM)和触发器模式–完备事件驱动的架构，定制复杂完备事件条件–树存储模型，支持不同级别定制不同一致性模型和事务模型–提出并支持树型MapReduce和增量/定时MR–支持相关集计算和Reduce时数据集生成(kmean)–提升迭代计算性能（机器学习）IProcess–持续与AD-HOC计算(endpoint)–多任务服务化，任务沙箱，优先级，任务调度–两级容错：应用级和系统级，运算时动态扩容–微内核+插件系统(系统级插件+用户模块)–系统级插件系统：实时join，二级索引，到排表，物化视图(cc)，counter…–早停，删除•基础的运行系统–引入CEP规则引擎模块（RPM），类似hive，mr–引入数据集控制（用于机器学习），BI–引入类SQL语言•“每个节点”为用户编写的组件，该节点为逻辑节点，被称为processor，会被系统调度到多台物理机器形成逻辑集群，也就是说一个逻辑节点可能会有多台的物理机同时服务，从而形成逻辑集群，processor根据计算负载调度形成不同的逻辑集群。而”边“为组件定义的完备事件。•系统的ProcessNode是加载，管理，调度用户组件processor的进程，不同的PN可以在不同的物理机也可以在相同的物理机。触发器模式的例子•资讯搜索IProcess整体架构整体拓扑IProcess中的存储•树结构的存储(mr，表关系，相关集，不同的一致性模型和事务模型等)•区分实时数据与其它数据的存储•两级容错：应用级和系统级•运算时动态扩容•流模式和触发器模式•流数据的保序•流计算(latency)和块计算(throughput)动态tradeoffIProcess的存储MR模型的本质Reduce(key,valueList,context)实现STCacheStrategy接口GlobalTable•Hbase维护分支–Segment分裂策略–Coprocessor沙箱–类Redis接口–容量规划–剥离行事务编程模型•IProcess只提供最基本的功能，提供高度可定制的接口，上层可定制出不同平台（计算模型）和业务系统。IProcess支持4种组件：容器类组件；系统组件；共享组件；业务组件。•完备事件模型(底层只有一个基本模型)–触发器模式IProcessModule–流模式EventProcessor–MR模式MapperReducerMergerPreparer，级联MR，实时增量MR，树MR–引入图计算模型–SQL–规则引擎应用场景特点•响应时间-实时–毫秒级别（子图）–秒级别–分钟级别•图复杂度–节点简单且重，图复杂（网页搜索，机器学习）–节点简单但轻，图复杂（业务系统）–节点复杂但轻，图简单（风控）–节点复杂且重，图简单应用场景特点•语言–C++,java,shell–SQL–规则–。。。•模型–流–触发器–MR–。。。应用架构Iprocess模型特点•可扩展的编程模型–触发器–实时MR模式–事件流模式–图计算模式•完备事件模型，并可定制相关集•树MapReduce，preparer接口•图模型的乱序执行Iprocess系统特性•树状存储•事务模型–逻辑事务–弱事务–强事务•运行时扩容•系统，应用量级容错•保序用户API简介•用户实现类（组件实现）–系统级•STCacheStrategy接口:ST的缓存替换策略，系统有LRU缺省的实现。不过用户可以自行定制特殊的替换策略。•LogicalConflictResolver接口：用户实现接口。当并发写操作发生时，用户通过该方法告诉系统如何处理逻辑冲突的数据。详见“人立方的实时计算”•LazyConflictResovler接口：用户实现接口。某些应用场景允许短暂的数据不一致，当并发写操作发生时，用户通过该方法告诉系统如何处理逻辑冲突的数据。•UserDefinedCondition接口：用户实现接口。用于用户定制更复杂的事件触发条件，或者调用其它服务来判断等。系统有缺省实现。•Partitioner接口：用户实现接口。用来定制数据的分布。类似于hadoop中的partition。系统有缺省实现。用户API简介–应用级•IProcessModule类：用户实现。在触发器模式下，用户编写模块（组件）。•EventProcessor类：用户实现。适用于流模式（简单事件）用户模块（组件）的编写。•Mapper类：用户实现。适用于MR模式下用户模块（组件）即MAP的编写。•Preparer类：用户实现。适用于MR模式中的相关集动态生成场景下，相关集生成用户模块的。详见：kmean的例子。•Reducer类：用户实现类。适用于MR模式下用户模块（组件）即REDUCE的编写。•Merger类：用户实现类。适用于MR模式下，合并模块（组件）的编写。详见：wordcount的例子。•GraphComputing类?•SQLEngine?•DSLEngine?用户API说明•Iprocess目前支持三种模式–流（简单事件）模式，类似于S4和STORM。用户在此模式下工作，需要实现EventProcessor等接口–MapReduce模式，用户需要实现Map,preparer,reduce,merger等接口–触发器（复杂事件）模式，用户需要实现IProcessModule等接口•实际iprocess在最底层只有一种模式即触发器模式（IProcessModule），用户工作在流模式和MR模式，最终系统也会将这两种模式的代码转化为触发器模式进行计算（容器组件实现，类似SQL），编程模型可扩展•简化用户编码•兼容MR代码•兼容STORM代码例子•MapReduce例子（代码直接复用，效果大不一样）•访问记录•实时JOIN•SQL执行•Kmean聚类例子•SNS推荐系统–用户将公司名修改，引发推荐的实时变化–某用户增加一个好友会引发对自己和对别人的推荐变化–实时人立方(剪枝)•风控CEP构建技术生态体系•开放的体系–GlobalTable，cache，partition等•可扩展编程模型–从基本的触发器模式可扩展–实时MR–流模式–图计算–SQL引擎–规则引擎–DSL全面提升业务的实时处理能力•实时搜索–原来做不了的事情，提升到秒（分）级–原来做的慢的事情(天)，提升到秒（分）级•风控–平台体系化–从CEP到RPM•交易实时分析–从两天到秒级（CBU）•活动实时推荐–从天到秒级（ICBU）全面提升业务的实时处理能力•BNS–难度最大–关系的实时变化带来实时推荐–实时人立方，pregel做不到的–删除关系–平台化，成体系•金融–被动型基金–从消息源实时获取信息快速动作全面提升业务的实时处理能力•广告–实时结算–实时反馈–日志实时分析–快速决策展望•全站的神经–打通全身经脉–统一平台–即通且畅–数据，信息流动四通八达业界有影响力的技术产品•业界有影响力的技术产品–具有原创技术并发表影响力论文(osdi2012,…)–业界有技术影响力的会议(hadoopchina2011)–Hive架设在IPROCESS–Nutch架设IPROCESS提供整套实时搜索方案–部分开放分布式存储–开源职责•打造平台–实时计算（功能易用性迭代）–持续计算（功能易用性迭代）–Iprocess将专注，专业，专心于完备事件机制。只提供最基本的功能，提供高度可定制的接口，上层可定制出不同平台（计算模型）和业务系统。•合作打造技术生态体系–合作开发容器类组件(hive之于mapreduce，MR模，流模型，图计算模型，SQL,规则引擎等)–协助开发通用组件（指标集，分词组件等）–协调可复用子图(物化VIEW)–协调可复用系统目前进展与近期规划•Iprocess0.1(Q1,Q2)：完备事件，图模型==storm,s4•Iprocess0.2(Q3)：树存储，完善事件，保序等•Iprocess0.2.1(Q3)：搜索，网站交易落地•Iprocess0.3(Q4)：事件机制基本完善，MR模型•Iprocess0.3.x(Q4,12Q1)：跨语言，易用性，风控，BNS落地•Iprocess0.4(12Q1，Q2)：图计算，开放控制接口，服务化，调度，持续计算，监控，IDE，DEBUG环境，完善事务•Iprocess0.4.x(12年Q2,Q3)：SQL引擎，其它落地•Iprocess0.5(12年Q3,Q4)：服务化，完善开发和调试，迭代计算，hbase分支规划•构建技术生态体系–11年Q4,12年Q1,Q2。搜索中心合作打造搜索实时/全量计算–11年Q4,12年Q1,Q2。风控合作打造通用的CEP，RPM系统–11