开发者学堂课程【开源 Flink 极速上手教程：走进 Apache Flink】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/331/detail/3707
走进 Apache Flink（一）
内容简介：
一、追本溯源-Flink 的昨天
二、为快不破-流批的本质
三、秉轴持钧-流计算的核心
四、学以致用-Flink应用场景
五、怎样理解流批一体/流批融合？
一、追本溯源-Flink 的昨天
1.教师简介
孙金诚（阿里巴巴金竹），2007.07毕业于吉林通化师范学院
2011年，加入阿里巴巴，高级技术专家
2017年，加入Flink Committer
2019年，成为Flink PMC 成员
2020年1月，加入IoTDB Committer
2020年5月，成为Io TDB PPMC成员
2020年2月，加入Beam Committer
2020年4月，加入Apache Member
希望大家的学习态度：但行好事，莫问前程
2.Apache Flink 的历史渊源
Flink源于柏林工业大学，起初 Flink 并不叫 Flink，而是叫 Stratosphere。Stratosphere项目的目标是致力于大数据的处理，项目愿景是 Big Data looks ting from here，回头展望，做S tratosphere 项目确实实现了他们的目标，Flink 成为了Apache 的顶级项目，Flink 也是现如今统一的大数据引擎。
Statosphere 是什么？（What is Stratosphere）
Stratosphere 是一个研究性项目，其目标是开发下一代大数据分析平台。该项目由德国的几所机构共同研究。于2014年4月份贡献给Apache软件基金会，并于12月份迅速成为Apache顶级项目。
其中26位早期的研发人员，都在后来加入了Flink PMC
Stratosphere 于2010年诞生
根据计算机代码，Stratosphere的第一个 commit 在2010年12月15日星期三下午的17:02:01发生
在2014年的5月14日，Stratosphere 正式更名为 Flink，在更名为Flink之前已经进入Apache 的 incubating
2014年9月27日，Flink 的第一个版本上线
从孵化器到诞生，Flink 只用了短短4个月时间，足以证明Flink的实用与优秀
2014年12月12日，Flink成为Apache的顶级项目
Flink平均每四个月发布一个新版本
3.Flink 的新功能概览
对Flink 的内部的了解，不建议向了解Flink历史一样，从诞生到发展的顺序去了解。学习flash的内部，建议直接从最新的版本学习了解，当遇到具体的问题点，具体的功能点可以回溯历史，回溯它的功能的变化。从1.1发布之后，官方也陆续发布了一些这个介绍一些新功能介绍
第一个 Unaligned Checkpoints
非绿旗的检查点，这个功能在精准一次性于一下，可以大大缩短检查点的时间，从而提升检查点的一个成功的概率。在1.1之前，做 CT 有一个对齐的过程，对齐意味着等待，等待就会有一些耗时，新的功能它消除了那个等待耗时，进而大大缩短了这项工作的时间，提高了Flink的成功率。因为做这件事情是有一个超时时间的，那么你等待时间过长，可能就失败了。
第二个 Watermark IdIeness Detection
水印生成的空闲检测，这个功能非常实用，拿具体的一个例子进行说明，比如说要在上游消费一个 Kaska 的数据，有多个盘点。但每个party的数据不一样的时候，也就是有数据的 SQL 倾斜的时候，最慢的或者最小的数据，会阻碍否定内部的沃尔玛特生成一个 case，就阻止了 word 的持续向前单调递增的生成，这样的话就不阻碍业务的持续计算。这个功能可以检查某一个检查的空闲，可以暂时忽略它，确保业务数据的持续的计算
第三个 Batch and Streaming Unification（Source）
其实放眼看去用户本身或者说正在应用领域的用户而言，其实并不关心数据到底是流还是批。用户只关心计算的延迟和计算的准确性，因为只有被告知流计算延迟时，用户才关心流，一次计算结果不再更新，计算非常准确，所以客户才知道了批的概念。但其实用户本身并不关心，可以不告诉用户流，也可以不告诉用户批，只需要告诉用户，我需要这样的流批，需要这样的数据准确性。所以最终要朝着流批统一，流批融合的方向去发展的话，其实流和批对于用户而言越来越淡化。
第四个Application Mode DepIoyments
这是一个作业提交模式一个优化，那么之前的时候提交一个作业，要在提交作业的这个club专辑已经生成一个jar graph的一些资源下载等等。在提交作业的时候，构建自己的业务平台的时候，提交作业就可能造成一个单点问题。那么在1.1版本之后，这项功能的优化就减轻了提交作业的压力。
第五个 Change Data Capture（CDC）
CDC 功能在数据迁移场景非常实用，当然这个功能也并不是flink创造的新概念，在很多产品和场景上也都有这个概念和应用
第六个Pandas UDF PyFlink
目前 PyFlink，增加了对 PandasUDF的支持，本身的愿景是不断的增强。Flink 的Python 的分布式处理能力从而也不断的扩大。Flink 本身排成生态，那么 Patrick 对panda u d f的支持无疑是拓展了 flink 在 Python 生态上的支持。同时 UDF 的性能相对于之前的版本也有高达30倍的性能的提升
二、为快不破-流批的本质
现在的用户装修，作业要么是流的方式运行，要么是批的作业运行，那是否能从某个角度去审视，或者去分析探究，或者是一个预测，这个流批将来的一个走向是什么，目前流批的本质又是什么？
1.数据库本身可以完成流批计算
讨论流批本质的时候，其实可以借助数据库来辅助理解流批的一个区别和联系。我们都知道，可以用insert 、update 、delete来管理数据，然后用select来查询数据，那么查询本身就是一种计算。同时也可以利用Twitter这种触发器来监控表数据的一些变化。假设有一个需求，要实时的显示某种表里的全部数据。思考一下，应该用怎样的方式才能满足这样的一个需求？
比如用 insert 插入一个数据，然后用update更新一个信息。其实很容易想到，利用select就可以查询出表里面的一些数据，然后进行一些可视化的显示和监控。这里需要先考虑一个问题，当执行了这一次查询之后，其实时手工化，下次在什么时候出发，并不可预知，用户可能十分钟，可能一小时，可能一天，甚至用户相信了再查一次。总而言之，不论什么时间去查一次，它不能做到只要数据表有变化，计算机就显示出来。那么如果要达到这种效果，需要怎么办？其实还有另一种做法，就是利用触发器。现在有一个 insert 的触发器，再订一个 update 的触发器。以insert触发器为例，可以看到定义的一个方式，这个是MYSQL 的触发器的一个定义的语法，那定义完之后，它的逻辑就是只要表里面有音色的数据到来，就立即出发查询，并将结果写入到一个文件。那么同样update的操作到了之后，同样也触发一次查询写入。并写入一个结果文件里面去。其实对应着上面这个触发器，以及上面这两条点儿语句来讲，其实就会生成两个接口文件，当执行 insert into 的时候，生成一个 TRIGGER1，当执行的时候，再生成一个H2。这里面的结果可以看到，第一次颜色一条，其实就是一个一条。当第二次a的时候，会有两条结果出来，那么开始的时候只有一个码，MARY就查出一条来，然后查出来的时候把包裹也更新进去就可以了
2.流批的背后是在说什么？
数据库本身就可以完成流批的计算，那么为什么还需要很多的大数据的计算和流计算的计算框架。带着这个问题，来看一看流批计算的背后到底是在说什么。
既然数据库本身可以完成牛批计算。那么为什么还需要分布式流计算和批计算呢？其实本质上不管是流还是批，其实说的都是对数据的一个处理，尤其是对大数据的计算处理能力。
(1).目前数据有怎么样的变化？
目前全球的数据量又是一个怎样的变化？为什么迫切需要这种大数据的处理能力的这种计算引擎？
随着云计算，物联网，人工智能等新技术的到来，人们真正的步入了一个信息的时代，目前全球数据量呈现一个几何式的增长，可以看到这份预测的一个数据。全球十年的时间，数据量从16.1ZB增长到了16.3GB，那么这个数据量已经远远超过了单台计算机的存储和处理能力。大家如果对C的概念没有大小，可以看一下这个单位换算的一个关系，目前所说的是PB级别数据量就很大了，那么GB其实就是更难以想像的一个海量数据。
(2).这些数据从哪里来的？
目前的数据在一个非常快速的方式在增长，比如说Facebook的社交平台有几百亿上千亿的照片进行对，一些证券交易市场，比如纽约的证券交易，每天有几TB甚至十几TB的一个交易数据量。阿里巴巴，也许都有过双十一的经历。看看十年来阿里巴巴每年双十一的成交额，交易额十年时间已经增长了几千倍，开始是0.5亿，到一九年的时候就达到了2000多亿。在一九年的时候，还有一件非常让人振奋的事情就是在一九年的双一活动中，流计算的处理能力创造了一个25.511条每秒的处理记录。所以，从种种的事实和实际发生在我们身边的事情来看，其实不管你知不知道，它其实都是存在，也就是说不知道不代表不发生，没感觉也不代表不存在。所以说这个数据量的惊人是客观存在的。
(3).用户对计算的核心诉求
从另一个角度去看，数据量的惊人在某一种程度上也推动了技术的发展。这样海量的数据计算，对用户言而言，用户关心的是什么？对用户而言，它核心的诉求是什么？
首先一个诉求就是有这么多的数据，能否处理掉。
第二个诉求，在你能处理掉的同时，也要求的是计算准确，计算迅速。什么叫迅速呢？不能跑一个查询需求，运行一年。那这肯定不能叫快速，其实是无法接受的。
用户对计算的正确性和计算的迅速有非常迫切需求。一个家喻户晓的一个技术体系，谷歌创造的三驾马车。
这三辆马车，本质上解决了分布式的存储和分布式的计算能力。解决了这两个问题，就为当前的海量数据的持续增长和数据价值的挖掘提供了技术手段。但是谷歌的三驾马车，它描述了如何进行海量数据分析计算的分布的一个编程模型。但是是在谷歌内部落地的。对于谷歌之外的公司，如何完成分布式的存储和分布式的计算？大名鼎鼎的阿尔奇翰生产包括hdfs h base存储等等在内的计算模型，再来分析一下开源生态，这个体系是一个分布式的RPG体系，一般是若干小时或者若干天的计算延时。那么实际的生产业务中，大多数在T加一的场景会应用APP的分布式计算。也就是说今天看到的结果，实际上是对昨天数据的一个统计分析，所以它的体系很好地完成了在大数据计算场景里面，用户对海量数据计算支撑和计算准确性的需求。其实本质上，这种需求被满足了，但是数小时的业务延时还不能说是计算快速，那么用户需求的快是一个怎样的速度呢？快速往往是说秒级毫秒级。计算的一个快速问题怎么解决？怎样的技术手段可以达到海量数据的快速计算？试着分析一下为什么计算无法达到秒级或者毫秒级的延时？
数据计算处理有多个环节，叫stage。批计算的逻辑是stage by stage，也就是当前的stage没有完成之前，不能启动下一个stage。如图比如有N个数据转换处理逻辑的话，那么从第一个辞职的启动处理。直到第N个stay处理完成之后，才能有真正的数据结果产出。所以X data com一般是非常久的。那么在这种情况下，在数据量一样，业务逻辑一样，数据逻辑一样的情况下，怎样降低业务的延迟。那就是流的方式。为什么流计算方法能解决？因为数据的处理就像流水一般，同时启动所有的处理的环节和逻辑，哪怕刚流入第一滴水，就将这滴一滴水的所有的处理逻辑都处理完成，并输出这第一滴水处理的一个结果，流向下游，这时候数据的延迟是最低的，也就是不用等到所有的数据都到齐，将所有的处理逻辑都执行完了。在输出结果，那这种及时的计算模式就是流计算。
也正是因为这个缘故，促使其在业务延时方面和批计算有着天壤之别。从个人的角度去做一个解释，那就是快，也就是流与批的本质上是业务延迟的不同。那么本质上所谓的快，这个要求也是相对的，不同的业务可能有不同的需求。现在所说的毫秒和天数的延迟是两个极端。实际的业务中还有分钟的延时，小时的延时等等。小的时间间隔的一个演示需求。针对这样的需求，在小时和分钟级别的业务场景中，不论是批计算还是流计算都是可以满足的。所以流计算和批计算，用户并不十分的关心。客户关心的是计算结果输出的一个时效性和计算结果的准确性。
基于现在的分析和判断，对于计算引擎技术实现，从实现的角度去看，所谓的触发，不管是秒还是小时，以及天。其实内部引起内部的一个触发机制的设计。比如每条记录都触发一次，计算并输出结果，那自然而然是最低的延迟了。如果将处理结果全部结束了，数据就结束了，所有数据都到齐了，再触发一次计算并输出结果，显然效率是最高的。并且如果在计算引擎上，在处罚机制上还支持了，按业务的需求，指定时间的一个范围，或者记录数据的一个范围进行触发计算的话，对用户而言，这已经足够了。
本质上流和批的计算模式的选择，更多的应该是计算引擎的选择。用户接受一天的颜值，就选择P计算。用户需要一秒的延迟，就可以选择流计算。满足用户需求即可。一个好的系统，流批统一的系统，本质上是一个计算的模式。对用户而言，在业务的角度来看，其实本质上透明一点反而会更好。
（4）.流与批的计算方案
批计算比较简单，就是一个数据结束之后，一个计算的出发。但是对于流计算而言，计算引擎的设计会根据流批的认知的不同，目前有两种主流的设计方案。
第一种，批是流的特例。既然可以每条记录都触发计算，那么也可以三条或者五条，甚至一个小的数据集合之后触发计算，所以流计算的计算引擎自然而然就会支持一个。这是批是流的一个特例。
另一种说法是流是批的特例，既然有批，就能攒一批出去，有这个机制，如果每一批的数据，批次的数据足够小，就发一条，那是不是也相当于每条数据都触发了计算？那是不是也就意味着这个延时应该是最低的。也就是流计算。
那么这也就是为什么有流是批的一个特例的说法，当然这两种观念的不同就导致了底层架构、引擎架构的不同。针对这两种认知的不同，就有两种计算引擎的实现方案，或者设计方案。
一种是native streaming，另外一种就是micro bag。
Native streaming计算模式认为批是流的特例，这个概念，其实本质上更贴切流的概念，比如说监控的一些消息，数据库的一些blog，那么实时的一些支付系统，这些消息都是一条条处理的，一条条的流入，native streaming计算模式，每条数据的到来都触发计算这种机制。就会最大程度地降低我计算的延时，那么很明显streaming的模式占据了流计算领域的颜值的核心竞争力。
micro.streaming计算模式，认为流是批的特例，那么流计算就是将连续不断的批计算连续不断的PI数据进行持续的计算，那么如果数据足够小，批足够小，那么延迟就足够小。在一定程度上，这种设计其实本质上也满足了99%的实时计算场景，那么那1%为什么做不到？其实就是架构的不同，用Microsoft的架构模式实现的，其实本身设计上就有攒批的过程，并且对PI数据进行调度计算的一个过程，那么在这种程度上其实就增加了一定的延时。显然Micro Beijing的模式，即天生在的延迟上，会有那么一点点的平静。
flink是一个native.streaming的计算模式的流批统一的计算引擎。
（5）.总结
简单总结流批的关键区别，从数据集合、计算过程两个维度去说，批计算是有限的数据一次计算一次输出结果。而流计算本身的数据集可已是无限的，当然有限的数据集合也可以以流的方式进行计算，同时流计算要不断的进行结果的输出，如果计算有结果有更新，也要不断地进行历史数据计算结果的一个更新。
（6）.示例
以一个具体的事例，简单直观的看一下流计算和批计算的区别。当然还有一定的联系在里面，假设有一张用户表，用户点击时间表，表里面有时间托儿和用户姓名，需求是进行页面的 PV 统计，就是进行简单的select，Select count from 一个 table，那对于批查询手工执行即可，执行一次立即输出一个查询结果。就目前的需求就是like看得清，From user click，会输出一个六，因为在执行查询收工复发，有六个点击事件。当然，如果是这种查询，后续再有用户点击事件发生，其实这个结果也不会更改。如果想知道最新的结果，必须在此手工触发一次下去。如果目前这个产品的需求，使用流计算的方式情况会是，第一个，当你第一条事件来的时候，就会触发一次计算，部分计算的时候，就看肯定是各异，但第二次来的时候，同样也会出现一个计算12，以此类推，每条数据到来，我都会触发一次计算。最终第六条术语到来的时候，当批计算的数据结果这个数据集一样，计算逻辑也一样的时候，查询的结果跟批是一样的。虽然两种计算模式不一样，但计算结果都是一样的。所以对用户而言，批流是一种黑盒子，它能感知到的有两件事情，一个是计算结果，一个是计算结果输出的延时性。老师认为对于初学者来说，直观的认知到流批这种两种计算方式和计算结果输出方式的不同，以及他们最终结果一致性的相同。
