View
291
Download
6
Category
Preview:
Citation preview
流处理技术平台Overview和设计模式
2015/1/31
钟翔 Storm PMC Mail: xiang.zhong@intel.com
Weibo:http://weibo.com/clockfly
上海Intel亚太研发中心 | Intel 软件与服务部 Big Data Technology Department
About me
• Intel大数据开发部,Storm PMC
• 2014年之前做IDH Hadoop发行版,现从事Hadoop开源工作,
• 历史工作包括 MapReduce NativeTask,HBase图像存储 Large Object Store (MOB),Storm性能优化,创立Gearpump项目等。
流处理应用: 按响应速度分类 • 实时决策支持,必须立刻输出结果
– 广告推荐,必须在click的session里面返回 – 银行诈欺中止交易
• 实时响应,在时间窗内处理才有价值 – 嫌疑人车辆排查布控 – 突发事件公共监测
• 近实时数据处理,越快处理价值越高 – Google 索引更新 – 日志分析
流处理应用: 按数据一致性分类
• 对消息丢失不敏感 – IT 服务响应时间等Metrics指标监控等
• At least once – 手机短信验证码
• Exactly Once – 搜索引擎Ads关键字计价系统(每一个广告点击需要向广告主收费,计费必须且只能被计一次)
流处理技术平台 • 支持复杂的分布式 DAG计算
log
存储
流处理平台
Queue
各种 数据源
批处理
SQL
数据 分析
可视化
监控/报警
用户
消息 预处理
实时模型训练
业务决策
存储 源数据存储
流处理平台在大数据技术栈中的位置
分布式存储
数据可视化
批处理 流处理
SQL 查询 Catalyst StreamSQL Impala
集群管理 数据监控/通知 /报警
数据科学 / 机器学习
Graphx
Cloudera Manager
存储层
计算平台
数据分析
可视化
storm
数据探索 交互式,启发式 价值发现
流平台历史演进 1. 关系数据库 -> 流处理 (streamInsight, CEP System) 2. 消息队列 -> 流处理 (activemq, kafka, samza) 3. 批处理 -> 流处理 (spark, summingbird) 4. 其他, Storm, Millwheel, Gearpump
演进脉络: 热门系统: Storm,Spark Streaming SAMZA,
Michael Stonebraker 流八条
1. In-Stream,数据长流不息,没有沉淀(不经存储) 2. StreamSQL 3. 容忍数据的延迟、乱序和丢失 4. 输出结果可预期、可重复 5. 实时处理、实时响应 6. Join历史数据和当前数据 7. 高可用,不宕机 8. 数据可以水平切割,计算可以水平扩展
我的总结:一流的流处理技术平台 活
– 能满足各行各业的特殊需求, – 计算图动态灵活可定制 – 支持物联网,移动设备等各种数据源, – 支持各种高级语言,方便数据科学家
快 – 满足实时性要求,ms秒级响应
大 – 每秒能处理数百万消息
准 – 数据不丢不重,绝对准确,比如金融应用
技术模式总结 从实现层面的视角
1. 高效的分布式消息传递
2. 检测流数据丢失
3. 流重放
4. 去重, Exactly once delivery
5. 在流计算 Pipelining
6. 高阶StreamSQL语言
分布式消息传递的挑战
Partition and Shuffle
1. Partition & Shuffle, 数据通道多,数据碎!
2. 流内每个节点能力不同,处理速度不匹配,容易内存OOM,IO阻塞,CPU Hang等
N * N 个数据通道!
select * from R join S on R.key = S.key
Batch越大, 吞吐量越高 Batch越大, 延时越大
消息传递主要设计模式 • 中间数据落地
–消息队列持久化(AMQP, SAMZA KAFKA)
–中间状态 Checkpoint到磁盘 (MapReduce, Spark)
• 中间数据不落地(Millwheel, Storm)
– Effective Batching
– 流控
数据高效归组
Storm-297: 性能2.5倍, 延时大幅下降! http://storm.incubator.apache.org/2014/06/25/storm092-released.html
Storm-297: Storm Message passing IA Optimization
解决连接多,数据碎片的问题。 根据网络状况,自适应,兼顾吞吐量和延时
流控 – 滑动窗
sink
sink
sink
Process 时间轴
滑动窗
send seq id ack seq id Sliding window
timeline
对每一个连接
流控控制线
….
控制Pending 的总消息数
由于数据在内存中不落地,如果节点速率不匹配,内存会OOM。所以必须流控。
主要难点在于星型结构下流控压力的的反向传播(BackPressure)
和TCP协议实现原理相似。
为什么需要检测流数据丢失?
• 有些应用有很高的一致性需求,必须确保不丢。
– 比如搜索引擎Ads关键字计价系统,每一个广告点击都需要向广告主收费,一次点击只能计费一次
• 我们需要高效的跟踪哪些消息已经被处理了,哪些消息还没有被处理,哪些消息丢失了,需要恢复。
流丢失检测模式3: 细粒度Request & Ack
• Millwheel 方式
–以消息为单位,细粒度
– Task之间 Request & Ack,每个 消息独立Ack
– Msg Id 是UUID,不重复
A B
时间线
Msg(id=4534)
Ack(id=4533)
Msg(id=6327)
Ack(id=6327)
… Msg(id=1352)
Ack(id=1352)
两种流重放模式 1. 数据源头重放 (比如Storm)
2. 各级消息上游重放(比如Millwheel)
Source
Store 2. 消息上游重放,
1. 数据源流重放
Store 基于kafka 的数据源重放
为什么要消息去重复?
• 在流重放后,一个消息可能会被重复发送多次,需要去除重复的影响,确保:
–去重保证Exactly Once Delivery
–对存储状态的修改是一致的,不能影响应用
–错误不会传递,今天的错误不会传播到明天
去重策略2:接收端去重
• 消息接收端去重
– Google Millwheel 使用 Bloom Filter ,判断是否收到过。需要配合状态操作的原子性
过滤
处理
消息 第一次发送①
Bloom Filter 查询②
处理消息④
过滤
处理
消息 第二次发送①
Bloom Filter 查询②
进一步确认④
已经存在③ 不存在③
Hot Path Cold Path
去重策略3:增量状态ID
• 增量Transaction Id (Trident使用这个方法)
1. 消息Id 是增量的, 0, 1, 2, 3, 4, 5…..
2. 收到新消息id=3,处理,保存状态 State(id=“3”)
3. 重复收到消息id=3,读取状态的ID,和当前消息id相同,说明已经处理过,丢弃当前消息。
4. 各个Id消息的计算可以同时进行,但对状态State的commit必须按照ID的顺序
去重策略4:vector clock去重方法
• Vector clock是分布式系统的时钟技术,用来保持数据的一致性。
流处理系统
数据源1
数据源2
数据源3
c1
c2
c3
每个消息都有 当前时钟的 Timestamp ① Checkpoint at
Clock (t1, t2, t3)
clock(t1, t2, t3)之前的累积状态
②系统当时钟超过(t1, t2, t3时) checkpoint状态
③失败时重放,从上一个状态恢复
在流计算 - 数据不落地
• 在流内计算,数据不落地直接往下游传,数据流长流不止 – 系统本身不应该有固有的延时
• 中间数据落地的代价 – 数据太多,存储代价太高 – 增加延时
• Millwheel:200CPU, 中位数延时3.6 ms!
高阶StreamSQL语言
• StreamSQL 由 Stonebraker 提出,扩展了SQL的语法,支持Stream select, Stream join, Windows 运算。
• 实现模式 – 关系库方案扩展(状态存储在关系库中), 使用关系库的SQL
– 新的SQL引擎, 比如Intel Team在Spark SQL基础上的工作。
设计模式总结
• 通用流处理平台的设计模式: 1. 高效的分布式消息传递
2. 检测流数据丢失
3. 流重放
4. 去重, Exactly once delivery
5. 在流计算 Pipelining
6. 高阶StreamSQL语言
Gearpump流引擎: 上述模式 + Akka 开源项目地址: https://github.com/intel-hadoop/gearpump
设计目标:
– Exactly Once 消息处理
– 毫秒级延时,每秒千万消息的吞吐量
– 灵活编程模型,动态可调整的图,可视化编程
– 轻量的两层资源调度器,可嵌入使用
– 支持应用时钟, 时间窗支持乱序消息(时间窗结果仍然准确)
– Stream SQL
– 基于Gossip协议的Master HA设计。
– 更好的Metrics,dashboard
References • 吴甘沙 低延迟流处理系统的逆袭, 程序员期刊2013年10期 • Stonebraker http://cs.brown.edu/~ugur/8rulesSigRec.pdf • Gearpump: https://github.com/intel-hadoop/gearpump • http://highlyscalable.wordpress.com/2013/08/20/in-stream-big-data-processing/ • https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-
writes-second-three-cheap-machines • Sqlstream http://www.sqlstream.com/customers/ • http://www.statsblogs.com/2014/05/19/a-general-introduction-to-stream-
processing/ • http://www.statalgo.com/2014/05/28/stream-processing-with-messaging-
systems/
Recommended