再谈 Flink
source link: https://mp.weixin.qq.com/s?__biz=MzI3MDU3OTc1Nw%3D%3D&%3Bmid=2247483895&%3Bidx=1&%3Bsn=43760cc09a8a8980875996799dab8b7f&%3Bchksm=eacfa0b5ddb829a32eaa382d6a19121c8c944828a7f104b0bef25c7bfe14701215600d6
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
前一阵痴迷于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的程序入门教程，一起来学习学习......
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK