分布式流数据实时与持续计算强琦

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