Streaming platform overview 2014
•
0 likes•321 views
Reviewed the key pieces of bigdata stream processing.
Recommended
More Related Content
Viewers also liked
Viewers also liked (13)
Similar to Streaming platform overview 2014
Similar to Streaming platform overview 2014 (20)
Streaming platform overview 2014
- 1. 流处理技术平台Overview和 设计模式 2015/1/31 钟翔 Storm PMC Mail: xiang.zhong@intel.com Weibo：http://weibo.com/clockfly 上海Intel亚太研发中心 | Intel 软件与服务部 Big Data Technology Department
- 2. About me • Intel大数据开发部，Storm PMC • 2014年之前做IDH Hadoop发行版，现从事Hadoop 开源工作， • 历史工作包括 MapReduce NativeTask，HBase图像 存储 Large Object Store (MOB)，Storm性能优化， 创立Gearpump项目等。
- 3. 什么是流处理？
- 4. 流处理 vs.批处理 • 批处理：一批数据处理一次，不要求实时流入，实时输出 数据实时流入 事件处理 实时输出结果 中间状态存储
- 6. 流处理有哪些应用？
- 7. 众包
- 8. 流处理应用: 按响应速度分类 • 实时决策支持，必须立刻输出结果 – 广告推荐，必须在click的session里面返回 – 银行诈欺中止交易 • 实时响应，在时间窗内处理才有价值 – 嫌疑人车辆排查布控 – 突发事件公共监测 • 近实时数据处理，越快处理价值越高 – Google 索引更新 – 日志分析
- 9. 流处理应用: 按数据一致性分类 • 对消息丢失不敏感 – IT 服务响应时间等Metrics指标监控等 • At least once – 手机短信验证码 • Exactly Once – 搜索引擎Ads关键字计价系统(每一个广告点击需要 向广告主收费，计费必须且只能被计一次)
- 10. 如何支撑流处理应用？ 流处理平台
- 11. 流处理技术平台 • 支持复杂的分布式 DAG计算 log 存储 流处理平台 Queue 各种 数据源 批处理 SQL 数据 分析 可视化 监控/报 警 用户 消息 预处理 实时模型训练 业务决策 存储 源数据存储
- 12. 流处理平台在大数据技术栈中的位置 分布式存储 数据可视化 批处理 流处理 SQL 查询 Catalyst StreamSQL Impala 集群管理 数据监控/通知 /报警 数据科学 / 机器学习 Graphx Cloudera Manager 存储层 计算平台 数据分析 可视化 storm 数据探索 交互式，启发式 价值发现
- 13. 流平台历史演进 1. 关系数据库 -> 流处理 (streamInsight, CEP System) 2. 消息队列 -> 流处理 (activemq, kafka, samza) 3. 批处理 -> 流处理 (spark, summingbird) 4. 其他, Storm, Millwheel, Gearpump 演进脉络： 热门系统： Storm，Spark Streaming SAMZA,
- 14. 怎样的流平台才是够好的？
- 15. Michael Stonebraker 流八条 1. In-Stream，数据长流不息，没有沉淀(不经存储) 2. StreamSQL 3. 容忍数据的延迟、乱序和丢失 4. 输出结果可预期、可重复 5. 实时处理、实时响应 6. Join历史数据和当前数据 7. 高可用，不宕机 8. 数据可以水平切割，计算可以水平扩展
- 16. 我的总结：一流的流处理技术平台 活 – 能满足各行各业的特殊需求， – 计算图动态灵活可定制 – 支持物联网，移动设备等各种数据源， – 支持各种高级语言，方便数据科学家 快 – 满足实时性要求，ms秒级响应 大 – 每秒能处理数百万消息 准 – 数据不丢不重，绝对准确，比如金融应用
- 18. 技术模式总结 从实现层面的视角 1. 高效的分布式消息传递 2. 检测流数据丢失 3. 流重放 4. 去重, Exactly once delivery 5. 在流计算 Pipelining 6. 高阶StreamSQL语言
- 19. 高效的分布式消息传递
- 20. 分布式消息传递的挑战 Partition and Shuffle 1. Partition & Shuffle, 数据通道多，数据碎！ 2. 流内每个节点能力不同，处理速度不匹配，容易内存 OOM，IO阻塞，CPU Hang等 N * N 个数据通道！ select * from R join S on R.key = S.key
- 21. Batch越大, 吞吐量越高 Batch越大, 延时越大 消息传递主要设计模式 • 中间数据落地 – 消息队列持久化(AMQP, SAMZA KAFKA) – 中间状态 Checkpoint到磁盘 (MapReduce, Spark) • 中间数据不落地(Millwheel, Storm) – Effective Batching – 流控
- 22. 数据高效归组 Storm-297: 性能2.5倍， 延时大幅下降！ http://storm.incubator.apache.org/2014/06/25/storm092-released.html Storm-297: Storm Message passing IA Optimization 解决连接多，数据碎片的问题。 根据网络状况，自适应，兼顾吞吐量和延时
- 23. 流控 – 滑动窗 sink sink sink Process 时间轴 滑动窗 send seq idack seq id Sliding window timeline 对每一个连接 流控控制线 …. 控制Pending 的总消息数 由于数据在内存中不落地，如果节点速率不匹配，内存会OOM。所以必须流控。 主要难点在于星型结构下流控压力的的反向传播(BackPressure) 和TCP协议实现原理相似。
- 24. 检测流数据丢失
- 25. 为什么需要检测流数据丢失？ • 有些应用有很高的一致性需求，必须确保不丢。 – 比如搜索引擎Ads关键字计价系统，每一个广告点 击都需要向广告主收费，一次点击只能计费一次 • 我们需要高效的跟踪哪些消息已经被处理了， 哪些消息还没有被处理，哪些消息丢失了，需 要恢复。
- 26. 流丢失检测模式1 – 时间片 • Spark Streaming 方式 – 以时间片为单位 把输入流切成时间片，比如1 batch/second 作业失败重试 时间片
- 27. 流丢失检测模式2：持久化 • SAMZA 方式 – 中间数据持久化，保证不丢 持久化存储
- 28. 流丢失检测模式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)
- 30. 流重放
- 32. 两种流重放模式 1. 数据源头重放 （比如Storm） 2. 各级消息上游重放(比如Millwheel) Source Store 2. 消息上游重放, 1. 数据源流重放 Store基于kafka 的数据源重放
- 33. 消息去重复
- 34. 为什么要消息去重复？ • 在流重放后，一个消息可能会被重复发送 多次，需要去除重复的影响，确保： – 去重保证Exactly Once Delivery – 对存储状态的修改是一致的，不能影响应用 – 错误不会传递，今天的错误不会传播到明天
- 36. 去重策略2：接收端去重 • 消息接收端去重 – Google Millwheel 使用 Bloom Filter ，判断是否收到过。 需要配合状态操作的原子性 过滤 处理 消息 第一次发送① Bloom Filter 查询② 处理消息④ 过滤 处理 消息 第二次发送① Bloom Filter 查询② 进一步确认④ 已经存在③不存在③ Hot Path Cold Path
- 37. 去重策略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的顺序
- 38. 去重策略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状态 ③失败时重放，从上一个状态恢复
- 39. 在流计算(IN-STREAM)
- 40. 在流计算 - 数据不落地 • 在流内计算，数据不落地直接往下游传，数据 流长流不止 – 系统本身不应该有固有的延时 • 中间数据落地的代价 – 数据太多，存储代价太高 – 增加延时 • Millwheel：200CPU, 中位数延时3.6 ms!
- 41. STREAMSQL
- 42. 高阶StreamSQL语言 • StreamSQL 由 Stonebraker 提出，扩展了SQL的语法， 支持Stream select， Stream join， Windows 运算。 • 实现模式 – 关系库方案扩展（状态存储在关系库中）, 使用关系库 的SQL – 新的SQL引擎, 比如Intel Team在Spark SQL基础上的工作。
- 44. 设计模式总结 • 通用流处理平台的设计模式： 1. 高效的分布式消息传递 2. 检测流数据丢失 3. 流重放 4. 去重, Exactly once delivery 5. 在流计算 Pipelining 6. 高阶StreamSQL语言
- 45. Gearpump流引擎: 上述模式 + Akka 开源项目地址: https://github.com/intel-hadoop/gearpump 设计目标： – Exactly Once 消息处理 – 毫秒级延时，每秒千万消息的吞吐量 – 灵活编程模型，动态可调整的图，可视化编程 – 轻量的两层资源调度器，可嵌入使用 – 支持应用时钟, 时间窗支持乱序消息(时间窗结果仍然准确) – Stream SQL – 基于Gossip协议的Master HA设计。
- 46. Gearpump Akka
- 47. 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/