Flink介绍

1. 传统事务处理

存储层用于数据存储；计算层用于数据处理

对于用户的请求实时地进行响应，然而当数据规模越来越大时，需要花费更多的精力在表的设计和重构以及SQL调优上

那有没有更合理、更高效的处理架构呢？ 这就产生了有状态的流处理

2. 有状态的流处理

对于事件流的处理，当收到一个请求就产生一个响应，不必再访问数据库

但是现实中只针对当前事件处理后来产生结果是没有意义的，往往还需要一些额外的数据，而我们需要将这些额外的数据保存为 状态，可以根据状态来计算结果并且对状态进行更新，而状态是保存到 内存 中的，实时性得到了保证，比如在WordCount中，之前已经统计的结果就可作为状态，然后根据当前输入得到结果并更新状态。在传统架构中，我们是将状态保存到数据库中的

当数据规模增大后，就需要搭建分布式集群，这时就需要保证本地状态，防止在故障时数据丢失。我们可以定期地将应用状态的一致性检查点（checkpoint）存盘，写入远程的持久化存储，遇到故障时再去读取进行恢复，这样就保证了更好的容错性

有状态的流处理主要有以下几种典型应用：事件驱动型（Event-Driven）应用：和传统事务处理类似、数据分析（Data Analysis）型应用 、数据管道（Data Pipeline）型应用：如ETL

3. Lambda 架构

但是分布式架构会带来另一个问题：怎样保证数据处理的顺序是正确的呢？

以 Storm 为代表的第一代分布式开源流处理器，主要专注于具有毫秒延迟的事件处理，特点就是一个字“快”；而对于准确性和结果的一致性，是不提供内置支持的，结果有可能取决于到达事件的时间和顺序。另外，第一代流处理器通过检查点来保证容错性，但是故障恢复的时候，即使事件不会丢失，也有可能被重复处理，所以无法保证exactly-once

与批处理器相比，可以说第一代流处理器牺牲了结果的准确性，用来换取更低的延迟。而批处理器恰好反过来，牺牲了实时性，换取了结果的准确

Lambda 架构优点：兼具了批处理器和第一代流处理器的特点，同时保证了低延迟和结果的准确性 ；缺点：很难建立和维护

4. 新一代流处理器 Flink

第三代流处理器通过巧妙的设计，完美解决了乱序数据对结果正确性的影响。这一代系统还做到了精确一次（exactly-once）的一致性保障，是第一个具有一致性和准确结果的开源流处理器。另外，先前的流处理器仅能在高吞吐和低延迟中二选一，而新一代系统能够同时提供这两个特性

核心特性

• 高吞吐和低延迟。每秒处理数百万个事件，毫秒级延迟

• 结果的准确性

  Flink 提供了事件时间（event-time）和处理时间（processing-time）语义。对于乱序事件流，事件时间语义仍然能提供一致且准确的结果

• 精确一次（exactly-once）的状态一致性保证

• 可以连接到最常用的存储系统

  如 Apache Kafka、 Apache Cassandra、 Elasticsearch、JDBC、 Kinesis 和（分布式）文件系统，如 HDFS 和 S3

• 高可用

  本身高可用的设置，加上与 K8s， YARN 和 Mesos 的紧密集成，再加上从故障中快速恢复和动态扩展任务的能力， Flink 能做到以极少的停机时间 7× 24 全天候运行

• 能够更新应用程序代码并将作业（jobs）迁移到不同的 Flink 集群，而不会丢失应用程序的状态

API分层如下：

Spark 还是 Flink？

如果在工作中需要从 Spark 和 Flink 这两个主流框架中选择一个来进行实时流处理，更加推荐使用 Flink，主要的原因有：

• Flink 的延迟是毫秒级别，而 Spark Streaming 的延迟是秒级延迟
• Flink 提供了严格的精确一次性语义保证
• Flink 的窗口 API 更加灵活、语义更丰富
• Flink 提供事件时间语义，可以正确处理延迟数据
• Flink 提供了更加灵活的对状态编程的 API

当然，在海量数据的批处理方面， Spark 还是具有明显的优势