开发者学堂课程【开源 Flink 极客训练营：走进 Apache Flink】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/760/detail/13337
走进 Apache Flink
内容介绍：
一、追本溯源–Flink 的昨天
二、唯快不破–流批的本质
三、秉轴持钧–流计算的核心
四、学以致用一Flink 应用场景
本节目标：
对 Flink 的前世今生有一个直观的了解，同时 Flink 作为流批统一的大数据引擎，了解流与批的本质区别与 Flink 的学习至关重要。了解了流与批的本质区别之后，更需要了解形成这一本质区别的手段是什么。当了解 Flink 的历史，了解了 Flink 的由来以及 Flink 流计算的一些特质，Flink 流支持这些流计算和音特质核心机制后，要清楚的知道 Flink 可以解决哪方面的业务问题。
一、追本溯源–Flink的昨天
1.Flink 的起源
德国柏林工业大学就是 Flink 的发源地
Flink 源于柏林工业大学，起初项目的名字并不叫 Flink，而是叫 Stratosphere，该项目的目标是致力于对大数据的处理。所以当时的使命是：Big Data looks tiny from here.
回看 Stratosphere 其实做到了该点，它已经成为 Apache Flink 的顶级项目，也成为了目前火热的、流批统一的大数据引擎。
当时该项目源于学校，也是一个研究型项目，致力于打造新一代的大数据分析平台，除了德国柏林工业大学还有其他大学及机构共同参与和贡献。于2014年4月份贡献给Apache软件基金会，并于12月份迅速成为Apache顶级项目。
在该项目贡献给 Apache 之前，Stratosphere 有36位贡献者：
这些元老级贡献者中，有很多成为了 Flink 的 pmc 成员。
我们现在非常感谢当初他们的创造性的付出，才有了今天在企业中不断创造价值的 Apache Flink。
Stratosphere 项目是从2010年开始的，从它的Git commit日志里面可以看到，它的第一行代码是在2010年的12月15日星期三下午的17时02分01秒开始的。
该名字被柏林工业大学使用了3年多，然后就出现在 Apache 的邮件列表中，也就是在2014年5月14日该项目的名字正式更名为 Flink。
最初的讨论是在 Stratosphere 的开发邮件中进行的，之后在 Apache 的邮件列表进行一个知会，所以在更名为 Flink 之前已经是 Apache 的项目。
2.Flink 的发展
贡献到 Apache 社区后，Apache Flink 孵化器期间，孵化第一个版本在2014年的8月27号完成了第一个版本 v0.6-incubating
从贡献到 Apache 社区到第一个版本的发布，用了4个月左右的时间，该时间也是 Flink 一直保持的发布周期。
在两个孵化器版本发布之后，Apache 迅速在2014年12月12日从 Apache 孵化器毕业，成为 Apache 的顶级项目。
Flink 能在短短几个月内毕业，足以证明其本身的优秀。
在成为 Apache 顶流项目后，Apache 在2015年1月份 Apache 发布了成为顶级项目后的第一个 Release 版本Flink 0.8.0。正式步入了 Apache 顶级项目的正轨。
纵观 Flink 发布的周期的历史，Flink 每四个月会进行一次版本的发布，对于初学者来说，Flink 的昨天、由来（包括名字的由来）、项目的原始初衷和目的、现在的发布，了解的较为清楚了。
3.Flink 内部内容
学习 Flink 内部建议从最新版本开始，当遇到具体问题点、具体功能点，可以回溯其功能的变化。
从 Flink1.11 发布之后，官方陆续文章了一些介绍，一些新功能。
这里简单的列举几点：
第一个：Unaligned Checkpoints
该功能在精准一次性语义下大大缩短了检查点的时间，提高检查点成功的概率。（在1.11版本之前，有一个对其的过程，对其意味着有一个等待的过程，所以等待会有耗时，该新功能消除了该等待时间，进而大大缩短了等待时间，也提高了其成功率，因为进行时会有一个超时时间，时间过长可能会失败，所以该功能在实际生产中是非常主要的功能。）
第二个：Watermark ldleness Detection
水印生成的控前检测，该功能非常实用，举个例子：
比如要上游消费一个 kafka 的数据，有多个 partition，当每个 partition 的数据不一样时，数据最慢或者最小的实验数据会阻碍 Flink 内部的一个叫 word mark 生成的 case ，阻止了 word mark 的持续向前（单调递增的生成），这样的话就阻碍了业务持续的计算。有了 Watermark ldleness Detection 功能后，可以检查某一个空闲，生成 word mark 时可以暂时忽略来确保业务数据的持续的上升计算。
第三个：Batch and Streaming Unification (Source)
Source 接口的统一，流批统一的基础建设之一。
对正在应用 Flink 的用户而言，并不关心到低是流还是批，关心的是计算的延时和计算的准确性。因为流计算延时低，所以才关心流，因为批计算一次结果不再更新，计算非常准确，所以才知道了批的概念。但是其实本身并不关心，可以不告诉是流，不告诉是批，只需要告诉需要这样的延时、需要这样的准确性，是否能够完成就行。所以最终要朝着统一流批融合的方向发展的话，其实流和批对于用户而言越来越淡化。
第四个：Application Mode Deployments
是作为提交模式的优化，在之前提交一个作业要在提交作业的 clangd 端生成一些资源的下载等等，这时如果建立在 Flink 基础之上构建自己的业务平台时，提交作业可以造成单点问题。这项功能的优化减轻了 clangd 的压力。
第五个：Change Data Capture(CDC)
在数据迁移场景非常实用，在很多场景上都有该应用，可以在1.11版本中尝试该类型的功能。
第六个：Pandas UDF PyFlink
PyFlink 本身的愿景是不断地增强 python 的分布式处理能力，从而也不断地扩大 Flink 本身 python 生态。PyFlink 对 Pandas UDF PyFlink 的支持无疑是扩展了 Flink 在 python 生态上的支持，同时 UDF 的性能相对之前的版本也有高达30倍的性能提升。
