这是一个创建于 3080 天前的主题，其中的信息可能已经有所发展或是发生改变。
网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术，为客户提供稳定流畅、低时延、高并发的视频直播、录制、存储、转码及点播等音视频的 PASS 服务。在线教育、远程医疗、娱乐秀场、在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台。现在，网易视频云与大家分享一下 spark streaming 小批量数据流处理系统。
当前流行的数据流计算平台是 twitter 的 storm ， yahoo 的 s4 等， 这些流计算平台采用 record-at-a-time 模型： 记录流式达到计算节点， 计算节点依据当前记录进行一定计算，更新节点内部状态，最后输出新记录给下游计算节点。 record-at-a-time 模型存在如下问题： • 故障处理不足。 有复制和数据回放两种容错方式， 但是这两种方式各有不足。 复制方法消耗两倍资源， 且不能容忍两节点同时故障。 数据回放方法处理故障的方式是， 备份节点回放数据， 重构故障节点的状态， 数据恢复过于慢是这种方法的主要缺点。 • 慢节点的影响。 流处理速度受限于最慢节点， 当集群增加到一定规模时， 慢节点出出现概率较大， 最终拖慢整体集群整体处理速度。 • 一致性。 每个计算节点独立工作， 找不到全局一致点。 比如说， 一个节点计算 UV ，另一个计算 PV ， 由于节点按照各自的节奏处理数据， 输出的 UV 和 PV 并不对应到同一时刻。 • 实时计算和离线计算不统一。 实时计算和离线数据两套代码，两套实现， 开发和维护代价高。 数据也无法打通， 离线和实时难以实现联合计算。
Spark Streaming 的提出就是为了解决这些问题。 如上图所示， 它的数据模型是 D-Stream ， 按照时间（比如 1 秒）切分数据流为连续的小批量数据， 每批数据都是 Spark 中 的 RDD 结构。 在 D-Stream 模型下， 数据流处理就转换为针对连续 RDD 的数据处理。 先来看一段 word count 例子：
// 每个 1 秒产生 1 个 RDD val ssc = new StreamingContext(sc, Seconds(1)) // Create a DStream that will connect to hostname:port, like localhost:9999 val lines = ssc.socketTextStream("localhost", 9999) // Split each line into words val words = lines.flatMap(.split(" ")) // Count each word in each batch val pairs = words.map(word => (word, 1)) val wordCounts = pairs.reduceByKey( + _) // Print the first ten elements of each RDD generated in this DStream to the console wordCounts.print() wordcount 例子非常简洁，与普通 spark 程序差别不大， 运行效果是每隔 1 秒输出这 1 秒内出现的词及其出现次数。 可以看到 D-Stream 支持 RDD 常见操作， 比如 map/groupby/reduce 等，这些操作作用于 D-Stream 下面的每个 RDD ， 将一个 D-Stream 转换为新的 D-Stream 。 除此之外， spark streaming 窗口计算操作符， 譬如 countByWindow/reduceByKeyAndWindow 等， 这些操作符作用于一个滑动窗口内所有 RDD 。 基于窗口计算操作符， 我们很容易算出过去任意时间段内的 wordcount 结果。
流计算很多时候依赖全局状态， spark streaming 在这方面也提供了支持。 updateStateByKey 操作为每个 key 维护和更新全局状态， 状态可以是任意类型， updateStateByKey 会根据前序状态和业务自定义函数维护全局状态， 其典型的应用场景是用户 session 分析。 全局状态依赖于 D-Stream 当前 RDD 以及前一个全局状态计算得开， 因此计算的开销较大， 尽量避免维护大量全局状态。 D-Stream 模型的优点 • 延时较低。 RDD 模型支持单副本内存存储， 支持较大吞吐率和较低的延迟， D-Stream 能做到亚秒级延迟。 • 容错较强。 record-at-a-time 模型容错不足的根本问题在于计算状态和计算本身的耦合， spark streaming 做的是把状态和计算本身分离， 使得计算本身无状态， 增强计算弹性。 RDD 模型基于血缘关系保证数据可恢复， 正常运行时不需要投入冗余资源， 出现故障时， spark steaming 可利用整个集群资源并行恢复数据， 恢复速度快。 此外， 亦不用担心慢节点拖慢在整个集群， 因为无状态计算是可复制的， 通过复制计算到多个节点， 慢节点问题迎刃而解。 • 一致性保证。 D-Stream 每个 RDD 代表某段时间内所有的数据， D-Stream 上各种计算结果都针对相同快照， 保证 exact-once 语义。 • 离线处理和实时处理深度融合。 实时的 spark streaming 和离线 spark 计算使用相同的数据模型， 具有互操作性。 （ 1 ） spark streaming 实时处理可以直接利用到离线计算出来的结果。 （ 2 ） 可在历史数据之上跑实时计算程序， 在历史数据基础上也能做数据流计算。（ 3 ）实时数据库流支持交互式查询， 方面诊断问题。
总结 spark streaming 以小批量计算方式解决数据流计算问题， 相比 record-at-a-time 模型改进了容错性和一致性， 而最重要的是， 实时计算、离线计算、交互式计算可融为一体， 大幅降低开发和维护代价。 小批量方式势必带来更多延迟， 不过 streaming 号称能做到亚秒级延迟。 若果真能如此，应用场景非常广泛。
Select Language