Flink官网资料学习笔记
浏览技术博客时经常看到流式计算，Flink等词，虽然自己是个CRUD boy但是还是需要了解这个是什么东西的，遂打开官网学习了一番。
What is Apache Flink?
从介绍中我们了解到Flink流分成
有界流：有固定大小数据集
无界流：数据集是无限的
这个很好理解，无论是来自 Web 服务器的事件数据，证券交易所的交易数据，还是来自工厂车间机器上的传感器数据，其数据都是流式的。只是看你想怎么组织处理数据来决定用哪种流。
Use Cases
知道了Flink能处理流后，我们其实还是对它的使用场景很模糊。那么看看官网是怎么介绍使用方式的。
官网介绍了三种使用方式：
- Event-driven Applications事件驱动的应用程序
- Data Analytics Applications数据分析应用程序
- Data Pipeline Applications数据管道应用程序
我们分别看下这三种有什么区别
事件驱动的应用程序
官网的定义是：
事件驱动的应用程序是有状态的应用程序，从多个事件流中获取事件，并对传入的事件做出反应，触发计算、状态更新或外部操作。
然后又介绍了事件驱动的应用的好处。
其实看不太懂再说什么，但其中有一句话和两张配图我觉得对理解事件驱动有帮助：
事件驱动的应用程序是传统应用程序设计的演进
左边是传统应用：就和我开发的业务系统一样，事件发生后应用系统会对数据库进行变更然后触发下一步动作。
右边是事件驱动应用：比起传统多了Event Log和Ingest这两个东西，Ingest这个词有摄入吸收的意思。联想一下大数据组同事经常会有抽取业务数据系统的动作。大体能体会到了这两种应用的区别。
官网举了几个事件驱动的应用程序的例子
- 欺诈检测
- 异常检测
- 基于规则的警报
- 业务流程监控
- Web应用程序（社交网络）
我用“Fraud detection flink”作为关键字查了一下，确实有很多应用。最简单的一个例子就是官网的入门介绍例子：nightlies.apache.org/flink/flink…
很短的一篇文章，值得一步一步跟着做完，既体会了Flink的使用，又体会了欺诈检测系统的设计方法。除此之外，在查资料过程中我还了解到，现在大数据架构分成Lambda架构和Kappa架构，并且有人评价现在大部分流分析平台，基本都由Apache Kafka支持的Kappa架构取代了Lambda架构。那么我们有必要了解下为什么Lambda架构会被替代。
Lambda架构，参看这篇文章：www.cnblogs.com/cciejh/p/la…
从我开发的视角来看，Lambda架构的BatchLayer和SpeedLayer是两套计算逻辑，所以针对一个需求可能开发两套代码。这样可太痛苦了，以我从其他系统获得的开发经验来说，如果一个功能同时有两套代码实现，那么到最后，这两套代码的实现细节的差距肯定会越来越大。
而Kappa架构比Lambda架构删除了BatchLayer这一层，相当于简化了。Kappa架构流处理核心思想：
- 用Kafka或者类似MQ队列系统收集各种各样的数据，你需要几天的数据量就保存几天。
- 当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
- 当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。
官网还有一个更详细的欺诈检测的例子：flink.apache.org/2020/01/15/…
事件驱动的应用程序总结
在查资料的过程中伴随着Flink出现的最多的一个组件就是Kafka，常见使用场景是：前置系统收集各种事件，然后将数据均送入Kafka流转，然后Flink从Kafka中获取数据进行计算。再回想一下事件驱动的应用程序的图，是不是Kafka就是图中的Event Log的角色呢？Kafka对于Flink有一个很重要的功能就是历史数据回放，有了这个功能就支持了Flink重新计算。工作以来没有用过kafka，所以以后有时间会了解一下。
数据分析应用程序
官网定义是：
分析型作业从原始数据中提取信息
Flink可以进行批量分析，也可以进行流式分析。
从官网的图中可以看到数据分析应用和事件驱动的应用似乎差不多。但数据分析应用的输出的内容和事件驱动的应用的输出不太一样，数据分析应用输出的感觉更终端一些（分析报告，Dashboard）。而事件驱动的应用的输出可能会给下游系统使用。
官网举了几个数据分析的应用程序的例子
- 电信网络的质量监控
- 移动应用中的产品更新与实验评估分析
- 消费者技术中实时数据的即席分析
- 大规模图形分析
可以看出这几个应用更偏向于分析和结果一些。感觉数据分析应用程序可能用有界流更多一些。
数据管道应用程序
官网给的定义是：
提取-转换-加载（ETL）是存储系统之间转换和移动数据的常见方法。通常，ETL作业会定期触发，以从事务型数据库复制数据到分析型数据库或数据仓库。
数据管道与ETL作业具有类似的目的。它们转换和丰富数据，并且可以从一个存储系统移动到另一个存储系统。然而，它们以连续流模式运行而不是定期触发。因此它们能够以低延迟读取源源不断生成数据的记录，并将其移动到目的地。
官网举了一个例子：
一个数据管道可能会监视文件系统目录以获取新文件，并将它们的数据写入事件日志。另一个应用程序可能会将事件流存入数据库或增量构建索引。
下面的图形描述了定期ETL作业与连续数据管道之间的区别
感觉用法和前面的也没啥区别，区别在于使用的目的。
官网举了几个数据管道的应用程序的例子
- 电子商务中实时搜索索引的构建
- 电子商务中的连续ETL
电子商务中实时搜索索引的构建的原文：www.ververica.com/blog/blink-…
是阿里巴巴的专家写的，写的很“架构师”，我看不太懂。但是足以见得Flink连阿里的需求都能满足，那么肯定一般的小公司肯定没问题了。>
Use Cases总结
综合上述三个方向来看，虽然三个方向目的不同，但是感觉Flink的使用方式都是类似的。所以我又找了更多的实例来看看Flink更具体的应用，这里面的案例我没有一一细看，因为我已经大概理解Flink的使用场景了，今天的学习目的也达到了：
十大行业经典案例！Apache Flink 的 40 个最佳实践
我感觉这篇写的挺好的，讲了一些Flink的具体使用场景。
这篇讲了Kappa架构和Lambda架构的优劣 Flink + Iceberg 全场景实时数仓的建设实践
Apache Flink 在实时金融数据湖的应用
这里举了一个简单的例子，临期贷后催收业务。贷款快过期了需要进行催收。业务依赖账户余额、交易金额、本期应还金额。通过三个数据，针对不同的业务进行决策，是通过短信催收、智能语音催收，还是电话催收？
如果是基于原有的离线数仓的架构，得到的数据都是 T+1 的。用过期的数据决策，可能客户已经还款，但是仍然存在电话催收的问题。而通过“直通式”场景架构的应用，可以实现 T+0 的账户余额，交易金额和本期应还金额，实时进行决策，提升用户的体验。
