这篇文章主要介绍Flink Client、Window Time & WaterMarker，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
Flink Client:
Scala shell
SQL Client
Command line
Restfull
Web
命令行说明:
Standalone模式
#查看命令完整说明 flink -h #查看命令参数说明 flink run -h #启动一个standalone集群 bin/start-cluster.sh #运行job flink run -d examples/streaming/TopSpeedWindowing.jar #查看任务列表 flink list -m 127.0.0.1:8081 #停止指定任务，任务的source需实现StoppableFunction函数 flink stop -m 127.0.0.1:8081 d67420e52bd051fae2fddbaa79e046bb #取消指定任务，如果conf/flink-conf.yaml配置了state.savepoints.dir 会保存savepoint, 否则不会保存savepoint flink cancel -m 127.0.0.1:8081 5e20cb6b0f357591171dfcca2eea09de #触发 Savepoint flink savepoint -m 127.0.0.1:8081 ec53edcfaeb96b2a5dadbfbe5ff62bbb /tmp/savepoint #从指定的savepoint启动 flink run -d -s /tmp/savepoint/savepoint-f049ff-24ec0d3e0dc7 #info查看执行计划(StreamGraph) flink info examples/streaming/TopSpeedWindowing.jar ##拷贝输出的 Json 内容，粘贴到这个网站：http://flink.apache.org/visualizer/
Yarn Per-Job模式(每个Job启动一个flink cluster)
#单任务attach模式,客户端会一直等待任务结束才退出 flink run -m yarn-cluster ./examples/batch/WordCount.jar # Yarn上显示flink session cluster #单任务detached模式,客户端提交完任务就退出 flink run -yd -m yarn-cluster ./examples/streaming/TopSpeedWindowing.jar # Yarn上显示flink per-job cluster
Yarn Session模式(多个Job运行在一个Flink cluster)
#启动session yarn-session.sh -tm 2048 -s 3 tm内存2g, 每个tm有3个slot 默认atache模式, 加-d为detache模式 Yarn显示为flink session cluster #提交任务 flink run ./examples/batch/WordCount.jar 将会根据 /tmp/.yarn-properties-admin 文件内容提交到了刚启动的 Session。 #提交到指定的session 通过 -yid 参数来提交到指定的 Session flink run -d -p 30 -m yarn-cluster -yid application_1532332183347_0708 ./examples/streaming/TopSpeedWindowing.jar
Savepoint 与 Checkpoint区别:
Checkpoint是增量做的,每次时间短,数据量小,只要在程序里启用后会自动触发,用户无须感知;Checkpoint是作业failover的时候自动调用,不需用户指定
<font size=2>Savepoint是全量做的,每次时间较长,数据量大,需用户主动触发,Savepoint通常用于程序版本更新,Bug修复 A/B Test等场景,需用户指定.</font>
Restfull API提交方式: https://ci.apache.org/projects/flink/flink-docs-stable/monitoring/rest_api.html
Window 可以将无限流切分成有限流,是处理有限流核心组件.将流拆分成一个个buckets, 可以在buckets里进行计算
Flink中window分为时间驱动(Time Window)和数据驱动(Count Window)两种.
window方法入参WindowAssigner, WindowAssigner 负责将每条输入的数据分发到正确的 window 中（一条数据可能同时分发到多个 Window 中），Flink 提供了几种通用的 WindowAssigner：tumbling window(窗口间的元素无重复），sliding window（窗口间的元素可能重复），session window 以及 global window。如果需要自己定制数据分发策略，则可以实现一个 class，继承自 WindowAssigner
简言之，只要属于此窗口的第一个元素到达，就会创建一个窗口，当时间（事件或处理时间）超过其结束时间戳加上用户指定的允许延迟时，窗口将完全删除
window assigner: 用来决定某个元素被分配到哪个/哪些窗口中
Trigger: 触发器，决定一个窗口何时能够被计算或移除。触发策略可能类似于“当窗口元素数量大于4”时或“当水位线通过窗口结束时”
Evictor: 它可以在触发器触发后&应用函数之前/或之后从窗口中删除元素。
翻滚窗口（Tumbling window 无重叠）
滚动窗口（Sliding window 有重叠）
会话窗口（Session window 活动间隙）
WaterMarker是Apache Flink为了处理Event Time窗口计算提出的一种机制，本质上也是一种时间戳。 用于处理乱序事件或延迟数据，这通常用watermark机制结合window来实现(Watermark用来触发window窗口计算
watermark时间戳 > = window endtime
在[window_start_time, window_end_time]中数据存在
event time > watermark时间戳
标点水位线（Punctuated Watermark）通过数据流中某些特殊标记事件来触发新水位线的生成。这种方式下窗口的触发与时间无关，而是决定于何时收到标记事件
在实际的生产中Punctuated方式在TPS很高的场景下会产生大量的Watermark在一定程度上对下游算子造成压力，所以只有在实时性要求非常高的场景才会选择Punctuated的方式进行Watermark的生成。
周期性的（允许一定时间间隔或者达到一定的记录条数）产生一个Watermark。水位线提升的时间间隔是由用户设置的，在两次水位线提升时隔内会有一部分消息流入，用户可以根据这部分数据来计算出新的水位线。
在实际的生产中Periodic的方式必须结合时间和积累条数两个维度继续周期性产生Watermark，否则在极端情况下会有很大的延时。
举个例子，最简单的水位线算法就是取目前为止最大的事件时间，然而这种方式比较暴力，对乱序事件的容忍程度比较低，容易出现大量迟到事件。
迟到事件是不可避免的，元素到来时窗口已经关闭了
重新激活已经关闭的窗口并重新计算以修正结果。
将迟到事件收集起来另外处理。
将迟到事件视为错误消息并丢弃。
ps: flink默认采用第3种丢弃方式，也支持side output 和 allowed lateness
side output机制可以将迟到事件单独放入一个数据流分支，这会作为 window 计算结果的副产品，以便用户获取并对其进行特殊处理
Allowed Lateness机制允许用户设置一个允许的最大迟到时长。Flink 会在窗口关闭后一直保存窗口的状态直至超过允许迟到时长，这期间的迟到事件不会被丢弃，而是默认会触发窗口重新计算。因为保存窗口状态需要额外内存，并且如果窗口计算使用了 ProcessWindowFunction API 还可能使得每个迟到事件触发一次窗口的全量计算，代价比较大，所以允许迟到时长不宜设得太长，迟到事件也不宜过多，否则应该考虑降低水位线提高的速度或者调整算法。
窗口window 的作用是为了周期性的获取数据。
watermark的作用是防止数据出现乱序(经常)，事件时间内获取不到指定的全部数据，而做的一种保险方法。
allowLateNess是将窗口关闭时间再延迟一段时间。
sideOutPut是最后兜底操作，所有过期延迟数据，指定窗口已经彻底关闭了，就会把数据放到侧输出流。
以上是“Flink Client、Window Time & WaterMarker”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注亿速云行业资讯频道！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
