研究生flink论文

当前大数据的数据量已达PB级别（1PB=1024TB），可以说是庞大无比。同时数据还有 结构化 （如数字、符号等）、 非结构化 （如文本、图像、声音、视频等）之分，兼具大量、复杂的特点，使得如何又快又好又便宜得进行大数据的存储，管理和处理变成一个亟待解决的问题。 于是 分布式计算 作为一种低成本的方案被提出来了。原理就是把一组计算机通过网络相互连接组成分散系统，尽管分散系统内的单个计算机的计算能力不强，但是每个计算机只计算一部分数据，多台计算机同时计算，最后将这些计算结果合并得到最终的结果。就整个分散系统而言，处理数据的速度远高于单个计算机，且比集中式计算的大型机要划算的多。 为什么是他们，这要从谷歌的三篇论文说起... 2003年到2004年间，Google发表了三篇技术论文，提出了一套分布式计算理论，分别是： 但由于Google没有开源，所以其他互联网公司根据Google三篇论文中提到的原理，对照MapReduce搭建了 Hadoop ， 对照GFS搭建了 HDFS ，对照BigTable搭建了 HBase. 即：而 Spark 分布式计算是在Hadoop分布式计算的基础上进行的一些架构上的改良。目前也是Hadoop生态圈的成员之一。 Spark与Hadoop最大的不同点在于，Hadoop用 硬盘 存储数据，而Spark用 内存 存储数据,所以Spark能提供超过Hadoop100倍的运算速度。但因为内存断电后会丢失数据，所以Spark不能用于处理需要长期保存的数据。 Flink是目前唯一同时支持高吞吐、低延迟、高性能的分布式流式数据处理框架。一般需要实时处理的场景都有他的身影，比如：实时智能推荐、实时复杂事件处理、实时欺诈检测、实时数仓与ETL、实时报表分析等 广义的Hadoop不再是单指一个分布式计算系统，而是一套生态系统。 那么，这套生态圈是如何产生的呢？ 在有了Hadoop之类计算系统的基础上，人们希望用更友好的语言来做计算，于是产生了Hive、Pig、SparkSQL等。计算问题解决了，还能在什么地方进一步优化呢？于是人们想到给不同的任务分配资源，于是就有了Yarn、Oozie等。渐渐地，随着各种各样的工具出现，就慢慢演变成一个包含了文件系统、计算框架、调度系统的Hadoop大数据生态圈。 附：一些其他的组件示意 Kafka：是一种高吞吐量的分布式发布订阅消息系统，它可以处理各大网站或者App中用户的动作流数据。用户行为数据是后续进行业务分析和优化的重要数据资产，这些数据通常以处理日志和日志聚合的方式解决。 Kafka集群上的消息是有时效性的，可以对发布上来的消息设置一个过期时间，不管有没有被消费，超过过期时间的消息都会被清空。例如，如果过期时间设置为一周，那么消息发布上来一周内，它们都是可以被消费的，如果过了过期时间，这条消息就会被丢弃以释放更多空间。 Oozie：是一个工作流调度系统，统一管理工作流的调度顺序、安排任务的执行时间等，用来管理Hadoop的任务。Oozie集成了Hadoop的MapReduce、Pig、Hive等协议以及Java、Shell脚本等任务，底层仍然是一个MapReduce程序。 ZooKeeper：是Hadoop和HBase的重要组件，是一个分布式开放的应用程序协调服务，主要为应用提供配置维护、域名服务、分布式同步、组服务等一致性服务。 YARN：Hadoop生态有很多工具，为了保证这些工具有序地运行在同一个集群上，需要有一个调度系统进行协调指挥，YARN就是基于此背景诞生的资源统一管理平台。

flink的snapshot的算法在 这篇 论文，本文讲述也是基于这部分内容，如果有兴趣可以自行参考原文。   目前已知的能够保证只执行一次（exactly once）语义，依赖于全局、一致性运行状态的快照。但是这么做有两个明显的缺点： 1. 同步的快照需要停止当前所有正在计算的任务 2. 需要保存很多计算无关的状态和记录，需要占用很多额外的空间。 一种简单的实现方案可以分三步来进行： 1. 挂起所有正在执行的计算 2. 快照 3. 快照结束后，继续执行任务 这种实现方案最大的问题是对吞吐量和存储空间都有很大的影响，而且会依赖于上游发送方的数据备份。 Flink采用的是ABS（Asynchronous Barrier Snapshotting）算法。ABS只保存节点的状态，而不保存channel的状态。 1. 由中心调度节点（JobManager）向所有的source注入barrier。当source收到barrier，会对其当前状态做快照，并且广播到所有的output（如图a） 2. 当一个非source节点，收到barrier，那么其会阻塞当前的input，直到收到所有input的barrier（如图b） 3. 收到所有barrier之后，会保存当前的快照，并向所有的output广播barrier（如图c） 4. 快照结束后，解除input的阻塞，继续计算。全局的快照是所有的节点快照环状图的快照和无环图不完全一致： 1. 首先环状可能会无限的收到某个input的barrier 2. 数据在环状随意流动，可能会丢失数据。 为了解决以上问题，Flink对之前的算法做了一些扩展 1. 通过深度优先查找，首先得到所有的back-edge（就是回路） 2. 运算过程中，当收到所有的barrier时候（不包括回路的barrier），开始备份所有从back-edge发过来的记录，直到收到back-edge的barrier（如图b） 3. 这样在循环里的记录会被记录到本次的快照，如图c