一、基础概念：
批处理：持续收取数据，以时间作为划分多个批次的依据，再周期性地执行批次运算。（块状的划分）
不足：如果事件转换跨越了所定义的时间划分，传统批处理会将中介运算结果带到下一个批次进行计算；除此之外，当出现接收到的事件顺序颠倒情况下，传统批处理仍会将中介状态带到下一批次的运算结果中。
流处理：假设有一个无穷无尽的数据源在持续收取数据，以代码作为数据处理的基础逻辑，数据源的数据经过代码处理后产生出结果，然后输出。从流中接收到事件时，流处理应用程序对该事件作出反应：它可以触发动作，更新聚合或其他统计，或“记住”该事件以供将来参考，从而达到实时处理的效果。
注：流的计算本质上事Data Driven（数据驱动）计算。
Data Driven 将处理的规则和逻辑写入到Datastream 的API 或者是ProcessFunction 的API 中，然后将逻辑扩展到整个Flink 引擎，当外面的数据流或者是事件进入就会触发相应的规则，在触发某些规则后，Data Driven 会进行处理或者是进行预警，这些预警会发到下游产生业务通知，这是Data Driven 的应用场景，Data Driven 在应用上更多应用于复杂事件的处理。
(2) Flink确保状态拥有精确一次（Exactly-once guarantee）的容错保证:
----Flink 提供了一致性的Checkpoint。Checkpoint是Flink 实现容错机制的核心，它周期性的记录计算过程中Operator 的状态，并生成快照持久化存储。当Flink 作业发生故障崩溃时，可以有选择的从Checkpoint 中恢复，保证了计算的一致性。
状态维护：用一段代码在本地维护状态值，当状态值非常大时需要本地的状态后端来支持。
1、JVM Heap状态后端，适合数量较小的状态，当状态量不大时就可以采用JVM Heap 的状态后端。JVM Heap 状态后端会在每一次运算值需要读取状态时，用Java object read / writes 进行读或写，不会产生较大代价，但当Checkpoint （检查站）需要将每一个运算值的本地状态放入Distributed Snapshots （分布式快照）的时候，就需要进行序列化了。
2、RocksDB状态后端，它是一种out of core 的状态后端。在Runtime 的本地状态后端让使用者去读取状态的时候会经过磁盘，相当于将状态维护在磁盘里，与之对应的代价可能就是每次读取状态时，都需要经过序列化和反序列化的过程。当需要进行快照时只将应用序列化即可，序列化后的数据直接传输到中央的共享DFS 中。
三、Event – Time 事件时间驱动
Event – Time 相当于事件，它在数据最源头产生时带有时间戳，后面都需要用时间戳来进行运算。如需要处理3点到4点的数据，用事件真实产生的时间戳去做Re-bucketing（重新存储），把对应时间3 点到4 点的数据放在3 点到4 点的Bucket（桶），然后Bucket 产生结果。
注：Event – Time 的重要性在于记录引擎输出运算结果的时间。流式引擎连续24 小时在运行、搜集资料，假设Pipeline（管道） 里有一个 Windows Operator （操作）正在做运算，每小时能产生结果，何时输出 Windows的运算值，这个时间点就是Event – Time 处理的精髓，用来表示该收的数据已经收到。