flink随笔

主要总结flink知识点：
自定义窗口实现，默认情况下基本time、count窗口都能满足基本需求，要是特殊一些的情况就需要定义 window assign、trigger、evictor 比如：下面例子代表5S的滑动窗口，但是要窗口里面的元素打到100才出发计算，触发时保留该窗口的10个元素。

keyedStream
    .window(SlidingEventTimeWindows.of(Time.seconds(5), Time.seconds(1))
    .trigger(CountTrigger.of(100))
    .evictor(CountEvictor.of(10));

实时计算事件时间最大挑战：
1，事件时间乱序
2，事件时间倾斜，延迟到达时间范围不可控制。

水印的发送是通过 ExecutionConfig.setAutoWatermarkInterval(…) 控制的周期性的调用getCurrentWatermark()只要生成的新水印非空并且比之前的都大就往下游传递。
水印时间延迟和allowedLateness区别：
水印延迟时间控制的是窗口触发计算时间，这个参数一般配置的是通用无序度。
allowedLateness一般在窗口之后配置代表窗口最多保留多长时间，比如我有些消息最多可能会延迟1小时到达，故可以设置此参数保留窗口状态到一小时之后，此时间范围内只要有延迟事件到来就会触发计算比如SUM所有需要有支持upinsert的数据库存储。
水印的本质：执行时间是系统时钟超过window-end-time就触发，事件时间是通过水印机制评估当前事件时钟到那了，当事件时钟超过window-end-time则触发事件窗口计算。水印是由source产生的，一个算子接收到水印就推进当前事件时间时钟为该水印对应的值。

基于事件时间窗口的根本好处如下：

• 事件时间窗口计算更准确，无序延迟达到都能处理
• 能对历史数据进行回溯执行
• 完全避免使用批处理回溯，完全可以使用一套流计算框架，避免lambda架构，实现Kappa架构。

声明水印：
1，Timestamp Assigners / Watermark Generators
2，With Ascending timestamps ： 默认元素是递增的时候可以使用，事件时间就可以当做水印，没有比它更小的元素了
3，With Periodic Watermarks：乱序并且一定范围延迟时处理； 包含2种方案执行时间设置，max事件时间设置
4，With Punctuated Watermarks： 不是时间触发特定事件触发。

flink和spark-stream状态管理的区别：Spark implements the state as a distributed dataset, while Flink employs a distributed in memory key/value store。 状态增大时spark性能急剧下降，它会扫描整个数据集，flink性能常量级好只需要读取指定KEY对应的state。

rescal 本质：buckets 作为内部状态管理的单元，详情如下图

增量checkpoint： checkpoint包含2部分先内存状态存储，最后同步到HDFS

Asynchronous I/O: 使用场景访问外部存储比如HBASE。

Building real-time dashboard applications with Apache Flink, Elasticsearch（创建index，配置mapping，插入）, and Kibana（各种报表支持，垂直直方图，map图）；

技术选型考虑点：场景，成本，体验。

flink join:

• 间隔Join（Interval Join） -lowtime ~ +uppertime

flink中所有join相关的类：

AllWindowedStream缺点会导致所有分区的数据融入到一个task中去，单个task会成为整个JOB的瓶颈。
流join ConnectedStreams 、union
ConnectedStreams 限制所有合并的流的类型必须是一致的，
ConnectedStreams 只能连接两个流，而 union 可以连接多于两个流。
ConnectedStreams 连接的两个流类型可以不一致，而 union 连接的流的类型必须一致。

event time skew = processing time - event time

trigger(ProcessingTimeTrigger.create) trigger 可以任意指定，指定之后会修改trigger的默认类型。

实时计算存储选型：对于读写平均频率高于 1000 QPS 但查询不太复杂的实时应用，比如商户实时的经营数据。采用 Cellar 为存储，提供实时数据服务。对于一些查询复杂的和需要明细列表的应用，使用 Elasticsearch 作为存储则更为合适。而一些查询频率低，比如一些内部运营的数据。 Druid 通过实时处理消息构建索引，并通过预聚合可以快速的提供实时数据 OLAP 分析功能。对于一些历史版本的数据产品进行实时化改造时，也可以使用 MySQL 存储便于产品迭代。

存储引擎 优点 缺点
MySQL 使用简单，支持数据量小 数据量大，对MySQL的压力大,查询性能慢
Druid 数据预计算 不支持精确查询
Elasticsearch 查询效率快，支持常用聚合操作；可以做到精确去重 查询条件受限
Redis 内存存储KV，查询效率高 写入资源有限，不支持大数据量写入
Tair 持久化和非持久化两种缓存，查询效率高 单节点性能比Redis较弱
Kylin 多维查询预计算 不支持实时

实时计算引擎对比：Flink 的 Table 可以通过 TableSchema 进行管理，支持丰富的数据类型和数据结构以及数据源，可以很容易的和现有的元数据管理系统或配置管理系统结合。flink table 可以通过元数据来定义schema，可以很好的和数据开发中的元数据，数据治理等系统结合，提高开发效率。过大的checkpoint会导致吞吐下降和checkpoint超时，在实际生产中可以使用 RocksDB 和启用增量保存点模式，减少 Checkpoint 过程对吞吐产生影响。维表离线+实时 =》 接口提供； 去重方案：自定义的 UDAF，实现了 MapView 精确去重、BloomFilter 非精确去重、 HyperLogLog 超低内存去重方案应对各种实时去重场景。 RocksDBStateBackend 模式对于较大的 Key 进行更新操作时序列化和反序列化耗时很多。可以考虑使用 FsStateBackend 模式替代。

flink后端状态存储选型：

多流join解决思路：主流没join上也send出去， 后续从流补全上再使用数据库upinsert支持。

ES写入优化：

• 写入优化 在通过DataLinkString写入ES时，在集群可接受的范围内，数据Shuffle后再分组，增加Client并发数，提升写入效率。
• 数据结构化 根据需要设计了索引的模版，使用了最小的足够用的数据类型。
• 按天建索引 通过模版按天建索引，避免影响磁盘IO效率，同时通过别名兼容搜索一致性。
• 设置合理的分片和副本数 如果分片数过少或过多都会导致检索比较慢。分片数过多会导致检索时打开比较多的文件，另外也会影响多台服务器之间通讯。而分片数过少为导至单个分片索引过大，所以检索速度慢。在确定分片数之前需要进行单服务单索引单分片的测试。 我们根据 索引分片数=数据总量/单分片数 设置了合理的分片数。

数据服务查询量大解决方案：

• cache
• 重要维度预计算写入cache，不重要维度第一个用户驱动查ES写入cache
• master-worker模式提高查询并发，对复杂指标拆解

实时数据质量问题：

• 重置 offset重新消费
• hive2es覆盖

数据监控：

• 在计算引擎对源实时流进行监控，确保源数据流正确生产。
• 对展示的汇总数据进行监控保证产出指标正确。

使用version解决并发更新问题。update where version = ?
并发更新多线程安全问题，事务完整性问题解决方案：
并发更新安全问题：分布式锁，原子性setNX 算子， 执行完成之后delete key。
事务完整性问题：每次操作之前生成一个新的version， 事务中一个操作执行完成要更新最新version，同事缓存未处理的算子，下次重启的时候从未处理的恢复执行。

flink state 详解：
keybystream 维护的是每个KEY对应的状态，在open中初始化，
Long startTs = shiftStart.value();
shiftStart.update(startTs);
// register timer to clean up the state in 24h
ctx.timerService().registerEventTimeTimer(startTs + CLEAN_UP_INTERVAL);
Similar to state, timers are maintained per key