再谈Flink

前一阵痴迷于calcite，打算写一些streaming sql相关的东西，正好时逢置办年货，就买了本书《Flink基础教程》，打开看了一下，就放不下了，一口气都看完了，书不厚，很薄的一本小册子，有种醍醐灌顶的感觉，回想起9月份写的《阿卡姆科普报告——Flink》未免有些稚嫩......

还是那些内容，但是现在和当时的理解完全不一样了，希望半年后的我，再来看这篇文章的时候，也觉得很稚嫩吧...

首先Flink和其他流框架的区别：

这张图，就充分表达了flink的特点，保证高吞吐量、低延迟、正确性、操作简单以及语义化时间窗几个特点。

说到高吞吐量和低延迟，那么就不得不说一说lambda和kappa架构了，在最传统的ETL跑批的基础上，演化出来的lambda，目前可以说已经独领风骚了，而且基本整个生态体系，都是这个样子，大家自知或是不自知的都在往这个解决方案上靠拢。

建立在跑批加流处理的方式虽然解决问题，但是总感觉不够优雅，那么kappa架构，估计就是你的菜了，至少在理论上，是看着舒服和优雅那么一点。

这也是flink推荐的架构方式

之所以，kappa架构成为可能，除了kafka体系提供的支持外，也是由于flink能很好的完成exactly-once，这让不负责任的at-most-once，和凑合用的at-least-once情何以堪。

说到这里，flink是如何完成 exactly-once的？通过检查点，那么怎么加的检查点呢？是通过watermark，看文章有人翻译成水位线，有人翻译成水印，个人比较推荐使用水印的，因为这样可以方便你后续理解程序，反正我开始看一些文章，总觉得水位线这个翻译，和他起到的作用，有一种很割裂的感觉。

对于一个没做过流系统的人，时间和窗口可能是比较陌生的概念了，时间可以分成事件时间和处理时间，举个不太恰当的例子：

一个系列影片的故事线时间，相当于处理时间，而发行时间是事件时间，所以事件时间，很有可能是乱序，如果不是乱序，事件时间可能是很好的水印选择了。

下面一个图，就是对时间窗口和滚动最好的诠释了

对于 状态部分， 我真的还没理解，其完全的内涵.... 如果你懂的话，还请不吝赐教.....

也许是最近研究calcite的原因，个人总感觉calcite+flink会是一个很有意思的组合，如果加上ranger可能形成一套系统......

容我三思......

后续，在完成 calcite streaming sql前，可能会发几个flink的程序入门教程，一起来学习学习......