Processing Time: 机器或者系统的时间，可理解为真实世界的时间。使用该时间模式有最好的性能和最低的延迟。
Event time: 数据上自带的时间，可理解为数据世界的时间。实际场景中应用较多，由于数据在传输过程有网络、I/O以及消费等因素，往往不能保证数据按顺序到达，因此导致了时间的乱序等问题。
Ingestion time: 数据进入程序时的时间，比如12点的一条数据与11点的一条数据同时进入程序，这两者会被认为是同一时间的数据。与事件时间相比，摄入时间程序不能处理任何无序事件或者延迟事件，但是程序无需指定如何产生水印。
PS：对时间的理解，时间并不一定就一定是时间，只要数据是有序递增的，都可以理解为时间来进行处理。
在实际业务场景中的实时计算，往往都是使用的数据时间EventTime，这样才能保证数据的真实性和准确性。但是数据在传输过程有网络、I/O以及消费等因素，数据的时间可能会存在一定程度的乱序。
需要考虑对于整个序列进行更大程度离散化。把数据按照一定的条数组成一些小批次，但这里的小批次并不是攒够多少条就要去处理，而是为了对他们进行时间上的划分。
经过这种更高层次的离散化之后，我们会发现最右边方框里的时间就是一定会小于中间方框里的时间，中间框里的时间也一定会小于最左边方框里的时间。
这个时候我们在整个时间序列里插入一些类似于标志位的一些特殊的处理数据，这些特殊的处理数据叫做watermark。一个watermark 本质上就代表了这个watermark 所包含的timestamp数值，表示以后到来的数据已经再也没有小于或等于这个时间的了。
watermark 会以广播的形式在算子之间进行传播，下游所有算子共享watermark。
如果在程序里面收到了一个 Long.MAX_VALUE 这个数值的 watermark，就表示对应的那一条流的一个部分不会再有数据发过来了，它相当于就是一个终止的一个标志。
对于单流而言，会选择当前最大的值timestamp作为watermark。对于多流而言，会选择流中最小的watermark作为整个任务的watermark。即可看做一个由多个木块组成的装水的木桶，桶里面水多高取决于组成桶的那个最低的木块。
Watermaker的生成有两类。第一类是定期生成器，默认50ms向下游发送一次；第二类是根据一些在流处理数据流中遇到的一些特殊记录生成的，来一条数据获取一次，发送一次。生产中的使用可根据业务考虑使用何种，已达到性能和业务的平衡。
关于数据的延迟乱序，生成Watermaker时是可以直接增加一个特定延迟时间的。这样做的好处是，在水位到达时，仍然可以再等待一个延迟保证晚到的数据进行统计，保证数据的准确性，当然这样也使得数据实时性延迟，是保证实时性还是准确性，需要生成进行取舍，或者两种之间采用一个平衡值。具体的延迟时长，需要观察实际数据的延迟等进行判断及定义。
场景：
数据源一分钟产生一条数据，每条数据中有9条左右的不同key的子数据，程序进行Keyby处理后，开启一分钟的窗口进行汇总统计数量。
问题：
程序启动4个并行进行处理，结果几分钟后都没触发汇总。什么原因？
原因：通过前台对flink任务的监控发现，4个并行后由于数据量太少，有一个并行没有收到数据，因此没有产生Watermaker，由Watermaker的特性的第三条可以理解，整个程序目前的watermarker取的是第4个并行的watermarker初始值Long.MIN_VALUE，所以导致整个程序没有进行触发汇总。
不改并行的情况下，需要对程序Watermaker生成之前进行数据负载均衡，最简单直接的办法是进行一次keyby处理。
数据量较少的情况，直接改小并行度。
两种方法的目的都是保证每个并行都能消费到实时数据，这里我们采用第一个方案进行修改验证，结果如图时间小于1593572813000的数据都会及时进行汇总生成指标。
实际生产中关于数据负载均衡的问题往往也是需要注意的，往往数据的倾斜问题，如果比较严重会导致数据计算的准确性以及整个任务的性能等一系列问题，关于数据倾斜问题这里不进行深入探讨，下期有机会给大家做进一步的分享。
场景：业务链实时指标计算延迟。
原因：重复注册Watermaker导致任务吞吐量变低，影响计算效率。
如何解决：
业务链处理经过算子处理之后m条数据会生成m*n条数据，然后进行keyby汇总。之前水位注册在汇总数据之前，因此需要对m*n条数据都进行水位注册，使得同一时间多次水位处理，程序效率也下来了，整个任务吞吐量变低。利用水位广播传递的特点，将水位注册放到数据源，只需要对m条数据进行注册，处理逻辑直接少了n倍，整个任务吞吐量也随之上来了
建议生成Watermaker的工作越靠近DataSource越好。这样会方便让程序逻辑里面更多的operator去判断某些数据是否乱序。Flink内部提供了很好的机制去保证这些timestamp和watermark被正确地传递到下游的节点。
今天分享到此结束，后头见。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/130211.html
摘要：基于流处理机制实现批流融合相对基于批处理机制实现批流融合的思想更自然，更合理，也更有优势，因此阿里巴巴在基于支持大量核心实时计算场景的同时，也在不断改进的架构，使其朝着真正批流融合的统一计算引擎方向前进。 阿里妹导读：2018年12月下旬，由阿里巴巴集团主办的Flink Forward China在北京国家会议中心举行。Flink Forward是由Apache软件基金会授权的全球范围...
摘要：通过状态演变，可以在状态模式中添加或删除列，以便更改应用程序部署后应捕获的业务功能。本地恢复通过扩展的调度来完成本地恢复功能，以便在恢复时考虑先前的部署位置。此功能大大提高了恢复速度。问题导读1．Flink1．7开始支持Scala哪个版本？2．Flink1．7状态演变在实际生产中有什么好处？3．支持SQL／Table API中的富集连接可以做那些事情？4．Flink1．7新增了哪些连接器Ap...
摘要：默认情况下，当数据元到达时，分段接收器将按当前系统时间拆分，并使用日期时间模式命名存储区。如果需要，可以使用数据元或元组的属性来确定目录。这将调用传入的数据元并将它们写入部分文件，由换行符分隔。消费者的消费者被称为或等。 1 概览 1.1 预定义的源和接收器 Flink内置了一些基本数据源和接收器，并且始终可用。该预定义的数据源包括文件，目录和插socket，并从集合和迭代器摄取数据...
摘要：之前有了解到哥的一部分读者们没有充分搞清楚限流和熔断的关系。后者表示系统在同一时刻能处理的最大请求数量，比如次的并发。后续限流策略需要设定的具体标准数值就是从这些指标中来的。限流阈值不继续处理请求。 如果这是第二次看到我的文章，欢迎扫描文末二维码订阅我哟~本文长度为2869字，建议阅读8分钟。 可能你在网上看过不少「限流」相关的文章，但是z哥的这篇可能是最全面，最深入浅出的一篇了（容我...
摘要：另外，将机制发扬光大，对有着非常好的支持。系统也注意到并讨论了和的问题。总结本文分享了四本相关的书籍和一份领域相关的论文列表篇，涉及的设计，实现，故障恢复，弹性扩展等各方面。 前言 之前也分享了不少自己的文章，但是对于 Flink 来说，还是有不少新入门的朋友，这里给大家分享点 Flink 相关的资料（国外数据 pdf 和流处理相关的 Paper），期望可以帮你更好的理解 Flink。...
摘要：基于在阿里巴巴搭建的平台于年正式上线，并从阿里巴巴的搜索和推荐这两大场景开始实现。在经过一番调研之后，阿里巴巴实时计算认为是一个非常适合的选择。接下来，我们聊聊阿里巴巴在层对又大刀阔斧地进行了哪些改进。 Apache Flink 概述 Apache Flink（以下简称Flink）是诞生于欧洲的一个大数据研究项目，原名StratoSphere。该项目是柏林工业大学的一个研究性项目，早期...
阅读 1249·2023-01-11 13:20
阅读 1557·2023-01-11 13:20
阅读 1011·2023-01-11 13:20
阅读 1680·2023-01-11 13:20
阅读 3971·2023-01-11 13:20
阅读 2519·2023-01-11 13:20
阅读 1310·2023-01-11 13:20
阅读 3486·2023-01-11 13:20
