flink中文教程为数据架构师和开发者提供了一扇了解流处理和实时数据处理的窗口，在传统的批处理架构中，设计复杂、不够灵活且难以适应快速变化的需求，这一点在教程中得到了清晰的阐述，Flink作为一种先进的流处理框架，其能力不仅限于实现实时计数和预警功能，还能优雅地处理乱序事件和时间窗口的动态调整，通过将事件流按照发生的时间而非固定时间间隔划分任务，Flink简化了实时数据处理的复杂性，同时提供了更大的灵活性和准确度，这个教程通过直接的比较，展示了Flink如何优化现有的lambda架构，解决数据堆积问题，并通过事件、处理、摄入时间的区分，满足不同的业务需求，对于追求低延迟、高准确度的实时数据处理任务，这本教程提供了宝贵的实践指导。
数据架构设计领域发生了重大的变化，基于流的处理是变化的核心。
分布式文件系统用来存储不经常更新的数据，他们也是大规模批量计算所以来的数据存储方式。
批处理架构（lambda架构）实现计数的方式：持续摄取数据的管道（flume）每小时创建一个文件，由调度程序安排批处理作业分析最近生成的文件，然后输出计数结果。
该架构缺点：1.组件多，设计管道、调度、作业程序，学习成本、管理成本大 2.修改分析时间周期不方便，涉及工作流调度逻辑 3.实现计数预警功能需要引入流处理系统，流处理做近似计算，批处理做准确计数。4.事件可能是乱序的，上一批事件可能混入当前批次。
5.事件窗口是短板，不灵活。例如不能满足登录登出计数的需求。
flink可以同时满足计数和预警的功能，flink速度减慢只会导致数据在传输系统如kafka中堆积。
flink以时间为单位把事件流分割为一个个任务（称为窗口）。
由固定时间分组改为根据事件产生的时间分组，只需要在flink中修改时间窗口的定义即可。
如果flink的代码有改动，只需要重播kafka主题。
和lambda架构相比，flink不需要以时间为单位生成额外的文件，同时时间的定义被代码明确定义。而不是摄取，调度，计算扯不清。
时间的概念：事件时间（时间发生的时候），处理时间（事件被处理的时间），摄入时间（进入流处理系统的时间）。很多情况下事件时间和处理时间是不一致的，即事件以乱序的方式进入系统。
有些需求要求尽快处理得到结果，即使有小的误差也无所谓，这种场景适合采用处理时间。
有些需求要求只是统计特定时间发生的事件，这种场景适合采用事件时间。
flink支持的窗口：
时间窗口：flink支持2种时间窗口：滚动时间窗口（没周期），滑动时间窗口（每周期，滑动步长值）
计数窗口：分组依据不再是时间窗口，而是根据元素的数量。同时也支持滚动和滑动2种方式。计数窗口需要谨慎使用，场景如下：假设事件窗口大小是100，达到90后事件停止，则窗口永远不能关闭，该窗口占用的内存也浪费了。一种解决方式是通过超时触发。
会话窗口：会话窗口是指活动阶段，其前后都有非活动阶段。在flink种，会话窗口由超时时间决定，即希望多久认为会话已经结束。
触发器：触发器控制生成结果的时间，即核实聚合窗口内容并返回给用户。（收到水印触发，自定义触发*1秒1次*）
因为在实际的工作中，遇到了部署Flink项目的情况，所以对Flink集群部署有了初步的了解。但是，我仍希望对Flink有更多的了解。所以，我对《Flink基础教程》一书做了学习，该书针对产品的诞生背景、应用场景、设计理念、实现方式和和架构模式，以及与其他产品的性能对比进行简要描述。以下是我的学习笔记。
产品简介：作为新一代的开源流处理器，Flink以同一种技术支持流处理和批处理，并能同时满足高吞吐、低延迟和容错的需求。
诞生背景：人们对某件事的正确理解往往来自基于有效论据的结论。要获得这样的结论，最有效的方法就是沿着事件发生的轨迹进行分析。流数据更为真实而有始有终地反映我们的生活方式和事物的发展规律。我们希望将数据用事件流的方式收集起来并加以处理。但要做好很困难，大规模的数据爆发式涌现，使得处理这个物理学范畴的问题变得更加棘手。在大型分布式系统中，数据一致性和对事件发生顺序的理解必然都是有限的，但我们致力于使得这种局限性不会危及商业目标和运营目标，flink应运而生。
应用背景：零售业和市场营销、物联网、电信行业、银行和金融业等。
零售业：在现代零售业中，点击量就代表销量，点击量数据可能是大量、连续、不均匀的，要快速准确地处理从各种渠道获得的大量数据，且不会因为各种瓶颈造成服务中断，并保持一致性的同时有效控制成本，是一件很有挑战性的事情；
物联网：低延迟的数据传输和处理，以及准确的数据分析是非常关键的事情。各类仪器中的传感器频繁地获得测量数据，并将它们以流的形式传输至数据中心。公用事业、交通运输行业和联网智能汽车就充分体现了这一特点，大型设备都依赖传感器数据的分析来获得鼓掌预警，如果不能及时处理这些设备的流数据，将会导致灾难性后果。
电信行业：基站在高峰期要承受的流量高峰压力可能超乎你的想象，如果流数据不能被很好处理，也就很难完成流量的负载均衡，无法完成合理的流量预分配，也不能在断电时快速做出调整，通过流数据进行异常检测至关重要。
银行金融业：银行和金融对交易的数据准确度、精度、速度和统计效率、正确率有着近乎苛刻的标准。所以，银行早早关门下班进行结算的营业模式在逐渐走向淘汰，取而代之的是交易数据和财务报表都要快速而准确地生成，以支持24小时的服务。这样的服务不仅仅限于交易，还要有能力监测欺诈和恶意攻击，避免巨大的损失，避免因为金融问题所带来的社会不稳定等严重后果。
设计理念：这里主要关注连续事件的处理目标，以非常低的延迟处理数据，人们希望流处理不仅做到低延迟和高吞吐，还可以处理中断。优秀的流处理技术可以容错，并且保证exactly-once，并尽力减小开销。Apache Flink是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架，能在支持高吞吐、exactly-once的同时，提供批量数据处理的能力。无论是有无限数据还是有限数据的处理表现，都堪称目前的佼佼者。
实现方式：对时间的处理被视为重中之重，采用流处理架构计数的应用程序模型。事件流由消息传输系统提供，并且只被单一的Flink作业处理，从而以小时为单位计数和预警。这个解法，解决了过多的独立部分、预警服务失准、乱序事件流处理困难和批处理作业的界限不清晰的问题。流处理区别于批处理最主要的两点是：流即是流，不必人为地将它分割为文件；时间的定义被明确地写入应用程序代码（如以上代码的时间窗口），而不是与摄取、计算和调度等过程牵扯不清。
架构模式：数据流模式简要可以描述为：日志文件或数据库的数据，从Kafka/MapR Stream读入（可能日志需要LogStash）Flink，Flink可以把处理好的数据传给ElasticSearch。Flink常见的做法是设置消息传输层和流处理层，（1）消息传输层从各种数据源（生产者）采集连续事件产生的数据，并传输给订阅了这些数据的应用程序和服务（消费者）。（2）流处理层有3个用途：①持续地将数据在应用程序和系统间移动；②聚合合并处理事件；③在本地维持应用程序的状态。消息传输层的理想功能：（1）兼具高性能和持久性；（2）将生产者和消费者解耦。另外，检查点的设置，保证exactly-once，做到状态版本控制。保存点（1）应用程序代码升级；（2）flink版本更新；（3）维护和迁移；（4）假设模拟与恢复；（5）A/B测试。
性能对比：Storm实现了低延迟，但是大部分版本做不到高吞吐，也不能在故障发生时准确地处理计算状态；Spark Streaming 通过采用微批处理方法实现了高吞吐和容错性，但是牺牲了低延迟和实时处理能力，也不能使窗口与自然时间相匹配，并且表现力欠佳。Flink的一个优势是，它拥有诸多重要的流式计算功能，其他项目为了实现这些功能，都不得不付出代价。
Flink起源于Stratosphere项目，Stratosphere是在2010~2014年由3所地处柏林的大学和欧洲的一些其他的大学共同进行的研究项目，2014年4月Stratosphere的代码被复制并捐赠给了Apache软件基金会，参加这个孵化项目的初始成员是Stratosphere系统的核心开发人员，2014年12月，
Flink一跃成为Apache软件基金会的顶级项目。
Flink主页在其顶部展示了该项目的理念：“Apache Flink是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架”
Flink将批处理（即处理有限的静态数据）视作一种特殊的流处理。
DataStream API 流式处理的接口，DataSet API 面相批处理的接口
FlinkML:机器学习 CEP:复杂事件处理 Gelly图计算 针对流式和批处理的Table API