关于flink的一些简单的理论性问题

**

关于flink的一些简单的理论性问题

**

一、初识Flink

使用一个架构先了解其用途，特点，长短处。以下将逐步描述其性能以及使用。
1.简介

Flink是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架。
Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。Flink被设计在所有常见的集群环境中运行，以内存执行速度和任意规模来执行计算。如果对scala语言有一定基础，并对spark计算框架熟悉，再对flink的学习中有一定的帮助。
**

1.1选择flink的原因

**
1.1 Flink为大容量数据提供流处理，并用同一种技术实现批处理。
许多系统都会产生连续的事件流，如行驶中的汽车发射出GPS信号，金融交易，移动通信基站与繁忙的智能手机进行信号交换，网络流量，机器日志，工业传感器和可穿戴设备的测量结果，等等。如果能够高效地分析大规模流数据，我们对上述系统的理解将会更清楚、更快速。
我们渴望按照流的方式处理数据，但要做好很困难; 随着大规模数据在各行各业中出现，难度越来越大。这是一个属于物理学范畴的难题: 在大型分布式系统中，数据一致性和对事件发生顺序的理解必然都是有限的。

1.2 连续事件处理和容错
人们希望流处理不仅做到低延迟和高吞吐，还可以处理中断。换句话说，优秀的流处理技术可以容错，而且能保证exactly-once。
1.3关于流处理技术的前世今身
分开处理连续的实时数据和有限批次的数据，可以使系统构建工作变得更加简单，但是这种做法将管理两套系统的复杂性留给了系统用户: 应用程序的开发团队和DevOps团队需要自己使用并管理这两套系统。
为了处理这种情况，有些用户开发出了自己的流处理系统。在开源世界里，Apache Storm项目(以下简称Storm)是流处理先锋。Storm提供了低延迟的流处理，但是它为实时性付出了一些代价: 很难实现高吞吐，并且其正确性没能达到通常所需的水平。换句话说，它并不能保证exactly-once; 即便是它能够保证的正确性级别，其开销也相当大。
在低延迟和高吞吐的流处理系统中维持良好的容错性是非常困难的，但是为了得到有保障的准确状态，人们想出了一种替代方法: 将连续事件中的流数据分割成一系列微小的批量作业。如果分割得足够小(即所谓的微批处理作业)，计算就几乎可以实现真正的流处理。因为存在延迟，所以不可能做到完全实时，但是每个简单的应用程序都可以实现仅有几秒甚至几亚秒的延迟。这就是在Spark批处理引擎上运行的Apache Spark Streaming所使用的方法。
更重要的是，使用微批处理方法，可以实现exactly-once语义，从而保障状态的一致性。如果一个微批处理作业失败了，它可以重新运行。这比连续的流处理方法更容易。Storm Trident是对Storm的延伸，它的底层流处理引擎就是基于微批处理方法来进行计算的，从而实现了exactly-once语义，但是在延迟性方面付出了很大的代价。
然而，通过间歇性的批处理作业来模拟流处理，会导致开发和运维相互交错。完成间歇性的批处理作业所需的时间和数据到达的时间紧密耦合，任何延迟都可能导致不一致(或者说错误)的结果。这种技术的潜在问题是，时间由系统中生成小批量作业的那一部分全权控制。Spark Streaming等一些流处理框架在一定程度上弱化了这一弊端，但还是不能完全避免。另外，使用这种方法的计算有着糟糕的用户体验，尤其是那些对延迟比较敏感的作业，而且人们需要在写业务代码时花费大量精力来提升性能。
为了实现理想的功能，人们继续改进已有的处理器(比如Storm Trident的开发初衷就是试图克服Storm的局限性)。当已有的处理器不能满足需求时，产生的各种后果则必须由应用程序开发人员面对和解决。以微批处理方法为例，人们往往期望根据实际情况分割事件数据，而处理器只能根据批量作业时间(恢复间隔)的倍数进行分割。当灵活性和表现力都缺乏的时候，开发速度变慢，运维成本变高。
于是，Flink出现了。这一数据处理器可以避免上述弊端，并且拥有所需的诸多功能，还能按照连续事件高效地处理数据。
1.4优势
Flink是第三代分布式流处理器，它拥有极富竞争力的功能。它提供准确的大规模流处理，具有高吞吐量和低延迟。特别的是，以下功能使Flink脱颖而出：
①事件时间（event-time）和处理时间（processing-tme）语义。即使对于无序事件流，事件时间（event-time）语义仍然能提供一致且准确的结果。而处理时间（processing-time）语义可用于具有极低延迟要求的应用程序。
②精确一次（exactly-once）的状态一致性保证。
③每秒处理数百万个事件，毫秒级延迟。 Flink应用程序可以扩展为在数千个核（cores）上运行。
④分层API，具有不同的权衡表现力和易用性。
⑤连接到最常用的存储系统，如Apache Kafka，Apache Cassandra，Elasticsearch，JDBC，Kinesis和（分布式）文件系统，如HDFS和S3。
⑥高容错性。由于其高可用的设置（无单点故障），以及与Kubernetes，YARN和Apache Mesos的紧密集成，再加上从故障中快速恢复和动态扩展任务的能力，Flink能够以极少的停机时间7*24全天候运行流应用程序。
⑦可迁移性。能够更新应用程序代码并将作业（jobs）迁移到不同的Flink集群，而不会丢失应用程序的状态。
除了这些功能之外，Flink还是一个非常易于开发的框架，因为它易于使用的API。嵌入式执行模式，可以在单个JVM进程中启动应用程序和整个Flink系统，这种模式一般用于在IDE中运行和调试Flink作业。在开发和测试Flink应用程序时，此功能非常有用。

2、重点概念

2.1事件时间和处理时间
事件时间是流中的事件实际发生的时间。事件时间基于流中的事件所包含的时间戳。通常情况下，在事件进入流处理程序前，事件数据就已经包含了时间戳。下图展示了事件时间窗口将会正确的将事件分发到窗口中去。可以如实反应事情是怎么发生的。即使事件可能存在延迟。
处理时间是处理流的应用程序的机器的本地时钟的时间（墙上时钟）。处理时间的窗口包含了一个时间段内来到机器的所有事件。这个时间段指的是机器的墙上时钟。如下图所示，在Alice的这个例子中，处理时间窗口在Alice的手机离线的情况下，时间将会继续行走。但这个处理时间窗口将不会收集Alice的手机离线时产生的事件。
简单理解：以商品为例，事件时间就好比生产日期，一个时间戳从生产线生产出来就被加入了时间戳。处理时间则是你买货时间等对商品产生影响的实际时间。
2.2水位线（Watermarks）
这也是flink中及其重要和特别的一个概念。
水位线是全局进度的度量标准。
一般来说，水位线提供了一个逻辑时钟，这个逻辑时钟告诉系统当前的事件时间。当一个运算符接收到含有时间T的水位线时，这个运算符会认为早于时间T的发生的事件已经全部都到达了。
简单理解：好比在流数据中插入一个标识，代表之前一定量的数据已经全部到达，用来触发操作。
2.3状态和持久化模型
在数据处理中，状态是普遍存在的。任何稍微复杂一点的计算，都涉及到状态。为了产生计算结果，一个函数在一段时间内的一定数量的事件上来累加状态（例如，聚合计算或者模式匹配）。有状态的运算符使用输入的事件以及内部保存的状态来计算得到输出。
①状态管理：系统需要搞笑的管理状态，并保证针对状态的并发更新，不会产生竞争条件（race condition）。
②状态分区：并行会带来复杂性。因为计算结果同时取决于已经保存的状态和输入的事件流。幸运的是，大多数情况下，我们可以使用Key来对状态进行分区，然后独立的管理每一个分区。例如，当我们处理一组传感器的测量事件流时，我们可以使用分区的运算符状态来针对不同的传感器独立的保存状态
③状态恢复
状态的恢复引出了状态中断所导致的结果一致性问题。
结果的保证：分为3种
a：AT-MOST-ONCE，当任务故障时，最简单的做法是什么都不干，既不恢复丢失的状态，也不重播丢失的事件。换句话说，事件可以被丢弃掉，也没有任何操作来保证结果的准确性。
b：AT-LEAST-ONCE，意思是所有的事件都得到了处理，而且一些事件还可能被处理多次。会产生数据重复处理。
c：EXACTLY-ONCE，恰好处理一次是最严格的保证，也是最难实现的。Flink使用了一种轻量级快照机制来保证恰好处理一次语义。
2.4窗口（Window）
Streaming流式计算是一种被设计用于处理无限数据集的数据处理引擎，而无限数据集是指一种不断增长的本质上无限的数据集，而Window是一种切割无限数据为有限块进行处理的手段。
简单理解：从无限数据流中截取一段符合条件的进行计算或处理操作的手段。
本文章属于Flink的一些简单知识点，对于学习使用flink有帮助，对于深入研究底层也有辅助作用。

[1]:参寻《Stream Processing with Apache Flink》
[2]: https://github.com/confucianzuoyuan/flink.git