【观察】常用的流式框架（二）-- Spark与Flink

 Spark由加州大学伯克利分校于2009年开发，第二年开源，2014年成为Apache顶级项目。作为MapReduce的继任者，Spark可以提供高水准API（如RDD--可恢复分布式数据集；Dstream--离散无序的RDD），其社区在2015年就有超过1000名贡献者，知名的用户包括亚马逊、eBay、雅虎、IBM、百度等。 2013年Spark Streaming成为Spark的核心，严格意义上说它是跑微批量（Micro-Batching）的架构，所以会有几秒钟的延时，但Spark Streaming支持丰富的状态数据、无重复传输并且扩展性极佳。一般地，流式数据经过Spark Streaming被切分成微批量，再由Spark引擎处理。

 Spark的一个应用就是统计网页访问量，可以用Python调取Spark Streming的接口，首先我们先读取服务端的站点地址（pageViews）并定义读取间隔，然后根据URL做Map算法将数据归类（ones--即每一个访问事件被定义为一个最小元素），最后使用Reduce算法将不同URL的GET事件聚合统计出浏览量。

 最后登场的是Flink，它于2010年由柏林工业大学、柏林洪堡大学和德国波茨坦普拉特拉学院联合开发，起初名字叫Stratosphere，在2014年进入Apache孵化计划并更名为Flink，2015年成为Apache顶级项目。Flink作为原生的流处理器，延时小于100毫秒；可以为应用提供流式或批量的虚拟API；支持数据表/SQL，CEP，机器学习，Gelly等多种特征库；目前的用户包括阿里巴巴、爱立信、奥拓，ResearchGate，Zalando等。 Flink的架构将批量应用与流式应用在数据层汇聚，这个数据层可以分布式地部署在搭在Hadoop Yarn、Apache Mesos和Kubernetes上甚至可以单独作为集群搭建，无高可用之虞。此外Flink还提供多种API和库接口（有流式的及批量优化的）供第三方接入开发（Java/Scala/Python）

 Flink适合支持日事务处理量达几万亿条的应用、需要维护TB级状态数据的应用及有数千节点的应用，在处理大型状态数据的时候，Flink会将状态数据按时序分窗口按批次存储，恢复的时候也会从分布式文件系统种按批次恢复。

 当有任意Flink节点宕机时，系统是如何实现高可用的呢？Flink会将数据流按顺序切分成多个分区（Partition），然后为每个分区计算检查点（CheckPoints），在恢复节点时，只需重置检查点状态，然后将此检查点后的数据由别的节点上重播入宕机节点即可。

 介绍完了五种（Storm和Storm Trident算作两种，尽管）框架，我们来比较下他们的优劣势。

 对于数据的严密性，Storm和Samza都会检查至少一次；延时性角度Storm远小于100ms表现最优；但对于状态数据Storm和Trident只能处理小型数据，不及Samza、Spark Streaming和Flink；严格意义上说Trident和Spark Streaming是微批量的处理方式；由于Samza没有数据缓冲区，因此就不存在反压问题；除Storm外，另外四种架构都是能保证数据时序的；延展性方面，Strom、Trident和Spark Streaming表现更优，可以在运行时直接添加新的节点。 根据在雅虎研究所的测试报告显示：“Storm和Flink的处理延时最低，Spark支持高的数据吞吐量，但代价就是会有较大延时。” 除了这五大体系之外，还有一些非主流的流式处理系统，比如的google的Dataflow，IBM的InfoSphere Streams等，这里就不一一赘述了。