雾岛与鲸的博客

checkpoint和savepoint是Flink为我们提供的作业快照机制，它们都包含有作业状态的持久化副本。用几句话总结一下。checkpoint的侧重点是“容错”，即Flink作业意外失败并重启之后，能够直接从早先打下的checkpoint恢复运行，且不影响作业逻辑的准确性。而savepoint的侧重点是“维护”，即Flink作业需要在人工干预下手动重启、升级、迁移或A/B测试时，先将状态整体写入可靠存储，维护完毕之后再从savepoint恢复现场。

环境准备1、flink 1.13.02、oracle 11g3、flink-connector-oracle-cdc 2.1.01、oracle环境配置首先需要安装oracle环境，参考 https://blog.csdn.net/qq_36039236/article/details/124224500?spm=1001.2014.3001.5502进入容器进行配置:docker exec -it oracle11 bash# 切换到oracle用户su - oracle# 创建数据需

错误信息:BIGINT and VARCHAR(2147483647) does not have common type no解决办法看看是否进行了表关联,表关联的字段类型可能没有匹配上左表关联字段数据类型为bigint， 右表关联字段数据类型为string，从而导致一直报该异常。...

短窗口的计算由于其窗口期较短，那么很快就能获取到结果，但是对于长窗口来说短窗口时间比较长，如果等窗口期结束才能看到结果，那么这份数据就不具备实时性，大多数情况我们希望能够看到一个长窗口的结果不断变动的情况，对此Flink提供了ContinuousEventTimeTrigger连续事件时间触发器与ContinuousProcessingTimeTrigger连续处理时间触发器，指定一个固定时间间隔interval，不需要等到窗口结束才能获取结果，能够在固定的interval获取到窗口的中间结果。Cont

Flink 版本 1.9.1程序报错:原因: watermark的event_time为null导致

Flink版本: 1.12.0异常: java.time.format.DateTimeParseExceptionkafka数据源声明案例:CREATE TABLE user_actions_source (-- `event_time` TIMESTAMP(3) METADATA FROM 'timestamp',-- `partition` BIGINT METADATA VIRTUAL,-- `offset` BIGINT METADATA VIRTUAL, `user_id

Evictor可在Window Function执行前或后，从原Window中剔除元素。本文总结Flink DataStream Window内置的三种剔除器: CountEvictor、DeltaEvictor、TimeEvictor的剔除原理及使用。CountEvictor: 数量剔除器。在Window中保留指定数量的元素，并从窗口头部开始丢弃其余元素。DeltaEvictor: 阈值剔除器。计算Window中最后一个元素与其余每个元素之间的增量，丢弃增量大于或等于阈值的元素。TimeEvic

Flink包含8中分区策略，这8中分区策略(分区器)分别如下面所示，本文将从源码的角度一一解读每个分区器的实现方式。GlobalPartitionerShufflePartitionerRebalancePartitionerRescalePartitionerBroadcastPartitionerForwardPartitionerKeyGroupStreamPartitionerCustomPartitionerWrapper继承关系图接口名称ChannelSelector

生产中是否有遇到过：调大 Flink 任务并行度，但任务的整体吞吐量几乎没有提升Flink 任务整体 CPU 利用率特别低，如何提高资源利用率呢？这篇文章主要解决生产实践过程中遇到的这两个问题。文中会先给出结论，方便读者知道这篇文章具体会涉及到哪些知识。如果对相关结论完全理解的，就没必要详细阅读本文了。文中会涉及到 Flink KeyGroup 和 Rescale 相关的概念，对 KeyGroup 和 Rescale 不熟悉的同学强烈建议先阅读 《 从 KeyGroup 到 Rescale》。1

问题描述: 使用异步IO 访问hbase, hbase需要kerberos验证，kerberos验证的时候，需要把kerberos验证文件加载到分布式缓存中，但是flink异步IO不支持访问分布式缓存，报错信息如下:好了，不说废话，直接上解决方案:在执行异步io操作之前，使用map方法构建对hbase的连接，使用静态变量，创建的hbase连接存储在内存中，后续使用hbase客户端的操作可以直接从taskManager的内存中去获取对应的连接即可主要测试代码:import java.util.Pro

在用flink sql在做实时数仓，架构大概是kafka关联hbase维表，然后写入clickhouse。hbase维表是频繁变化的现在遇到的几个比较棘手的问题：1、自己在实现AsyncTableFunction做异步io的时候，发现性能还是不够。后来就加入本地缓存，但是缓存一致性出现问题，不知道该如何解决2、写入hbase的时候，是批量写的，无法保证有序，维表频繁变化的话，顺序不对，会造成结果有问题3、hbase维表，可能5s后才会更新，但是此时kafka数据流已经过去了，关联的数据都是空不

Spark和Flink均为分布式计算引擎，在使用yarn作为资源调度器提交任务并且连接拥有Kerberos认证的Hbase时，同时面临着认证文件分发与获取的问题。两者的解决方案也是类似的，先在driver端加载认证文件，存储到分布式缓存，然后再Executor端获取文件目录进行认证。Spark on Yarndriver端 sparkSession.sparkContext.addFile(keytabPath) sparkSession.sparkContext.addFile(krb5P

问题描述:在消费Kafka的时候通过consumer.setStartFromTimestamp方法将消费起始点设置到12月3号0点0分0秒，但是消费到的数据有12月2号23点59分59秒的。问题原因:consumer.setStartFromTimestamp 表示数据写进 kafka 的时间...

导读：数据仓库是公司数据发展到一定规模后必然需要提供的一种基础服务，也是“数据智能”建设的基础环节。迅速获取数据反馈不仅有利于改善产品及用户体验，更有利于公司的科学决策，因此获取数据的实时性尤为重要。目前企业的数仓建设大多是离线一套，实时一套。业务要求低延时的使用实时数仓；业务复杂的使用离线数仓。架构十分复杂，需要使用很多系统和计算框架，这就要求企业储备多方面的人才，导致人才成本较高，且出了问题难以排查，终端用户也需要熟悉多种语法。本文分析目前的数仓架构，探索离线和实时数仓是否能放在一起考虑，探索 Fli

看完本文，你能 get 到以下知识介绍 CheckPoint 如何保障 Flink 任务的高可用CheckPoint 中的状态简介如何实现全域一致的分布式快照？什么是 barrier？什么是 barrier 对齐？证明了：为什么 barrier 对齐就是 Exactly Once？为什么 barrier 不对齐就是 At Least Once？Flink简介有状态函数和运算符在各个元素/事件的处理中存储数据（状态数据可以修改和查询，可以自己维护，根据自己的业务场景，保存历史数据或者中间结

Flink内部的Exactly-Once语义是基于Asynchronous Barrier Snapshotting(ABS)实现的.那么Flink和外部系统(如Kafka)之间的消息传递如何做到exactly once呢?问题所在:如上图，当sink A已经往Kafka写入了数据，而sink B fail。根据Flink的exactly once保证，系统会回滚到最近的checkpoint，但是sink A已经把数据写入到kafka了。Flink无法回滚kafka的state，因此，kafka

在异步IO查询外部存储时，对于提供异步查询的客户端来说可以直接使用，但是对于没有提供异步查询的客户端应该怎么做呢？我们可以将查询请求丢到一个线程池中，将这个线程池看做是一个异步的客户端来帮助我们完成查询请求。通过线程池方式来帮助我们完成异步请求关键在于线程池的core大小如何设置，如果设置过大，会导致创建很多个线程，势必会造成CPU的压力比较大，由于大多数情况下集群是没有做CPU隔离策略的，就会影响到其他任务；如果设置过小，在处理的速度跟不上就会导致任务阻塞。可以做一个粗略的估算：假如任务中单个Task需

Flink中广播状态假设存在这样一种场景，一个是用户行为数据，一个是规则数据，要求通过规则去匹配用户行为找到符合规则的用户，并且规则是可以实时变更的，在用户行为匹配中也能根据规则的实时变更作出相应的调整。这个时候就可以使用广播状态，将用户行为数据看做是一个流userActionStream，规则数据也看做是一个流ruleStream，将ruleStream流中数据下发到userActionStream流中，使得在userActionStream流中每一个Task都能获取到ruleStream流中所有数据，

在做维表关联如果要求低延时，即维表数据的变更能够被立刻感知到，所以就要求在查询时没有缓存策略，直接查询数据库维表信息。本篇以实时查询redis为例，要求redis 客户端支持异步查询，可以使用io.lettuce包，支持redis不同模式：单点模式、sentinel模式、集群模式，需要在pom中引入：<dependency> <groupId>io.lettuce</groupId> <artifactId>lettuce-core</artif

LRULRU(Least Recently Used)，最近最少使用缓存淘汰算法，认为最近访问过的数据在将来被访问的概率也比较大，当内存达到上限去淘汰那些最近访问较少的数据。在Flink中做维表关联时，如果维表的数据比较大，无法一次性全部加载到内存中，而在业务上也允许一定数据的延时，那么就可以使用LRU策略加载维表数据。但是如果一条维表数据一直都被缓存命中，这条数据永远都不会被淘汰，这时维表的数据已经发生改变，那么将会在很长时间或者永远都无法更新这条改变，所以需要设置缓存超时时间TTL，当缓存时间超过t

在维表关联中定时全量加载是针对维表数据量较少并且业务对维表数据变化的敏感程度较低的情况下可采取的一种策略，对于这种方案使用有几点需要注意：全量加载有可能会比较耗时，所以必须是一个异步加载过程内存维表数据需要被流表数据关联读取、也需要被定时重新加载，这两个过程是不同线程执行，为了尽可能保证数据一致性，可使用原子引用变量包装内存维表数据对象，即AtomicReference查内存维表数据非异步io过程具体实例：广告流量统计，广告流量数据包含：广告位id,用户设备id,事件类型(点击、浏览)，发生时间

一、维表服务维度或者是维表概念熟知应该是从数据仓库维度建模开始了解的，区别于事实表业务真实发生的数据，通常用来表示业务属性，比如订单业务中，商品属性、商家属性都可以称之为维度表。在flink 流处理实时分析中或者实时数仓中，同样需要使用维表来完成一些数据过滤或者字段补齐操作，但是我们所需要的维度数据通常存储在Mysql/Redis/Hbase/Es这样的外部数据库中，并且可能是会随时变动的，根据业务要求数据的时效性，需要不同程度的感知维表数据的变化，在实际使用中常常会有以下几种方案可供选择：在维度数据

Flink中的数据交换是围绕着下面的原则设计的：数据交换的控制流（即，为了启动交换而传递的消息）是由接收者发起的，就像原始的MapReduce一样。用于数据交换的数据流，即通过电缆的实际数据传输，被抽象为了IntermediateResult，并且是可插拔的。 这意味着系统可以使用同一实现同时支持流数据传输和批处理数据传输。数据交换也涉及到了一些角色，包括：JobManager，master节点，负责任务调度，异常恢复，任务协调，并且通过ExecutionGraph这样的数据结构来保存一个作业

本文从编程模型、任务调度、时间机制、Kafka 动态分区的感知、容错及处理语义、背压等几个方面对比 Spark Stream 与 Flink，希望对有实时处理需求业务的企业端用户在框架选型有所启发。本文篇幅较长，建议先收藏～目录```/ 运行模型对比 / ``````生态``````运行模型``````/ 编程模型对比 / ``````Spark Streaming``````Flink``````/ 任务调度原理 / ``````Spark 任务调度``````Flink 任务调度``````/ 时间

目录故障恢复自动故障恢复是 Flink 提供的一个强大的功能，在实际运行环境中，我们会遇到各种各样的问题从而导致应用挂掉，比如我们经常遇到的非法数据、网络抖动等。Flink 提供了强大的可配置故障恢复和重启策略来进行自动恢复。故障恢复在flink的配置文件flink-conf.yml 中，其中有一个参数 jobmanager.execution.failover-strategy: region。Flink 支持了不同级别的故障恢复策略，jobmanager.execution.failover-

flink sql 数据sink到mysql时，非空存在null值，插入mysql报错，配置下面的参数进行解决:table.exec.sink.not-null-enforcer对表的NOT NULL列约束强制执行不能将空值插入到表中。Flink支持“错误”（默认）和“删除”强制行为默认情况下，当将空值写入NOT NULL列时，Flink将检查值并引发运行时异常。用户可以将行为更改为“删除”，以在不引发异常的情况下静默删除此类记录。......

目录Flink重启策略1. 固定延迟重启策略2. 故障率重启策略3. 无重启策略4. 后备重启策略Flink重启策略Flink支持不同的重启策略，可以控制在发生故障时如何重启新启动作业。默认重启策略是通过Flink的配置文件设置的flink-conf.yaml。配置参数restart-strategy定义采用的策略。如果未启用检查点，则使用“无重启”策略。如果激活了检查点并且尚未配置重启策略，则固定延迟策略将用于 Integer.MAX_VALUE重启尝试。重启策略分为：固定延迟重启策略、故障率重

PV(访问量)：即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次。UV(独立访客)：即Unique Visitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次。需求: 实时计算当天零点起，到当前时间的uv一、模拟测试数据由于是测试一天的窗口，所以我们将数据的事件时间进行调整，每次增加一个小时，这样平均一天就只发送了12条数据，便于观察最终的测试结果。好了，上代码：import java.util.{Calendar, Proper

在flink streaming 处理中窗口是比较常见的操作, 例如窗口sum、max、min等，窗口构建主要包含：Assigner、Trigger、Function、Evictor,Assigner: 窗口分配器, 当有一个元素到达判断窗口属于哪一个窗口，对于滚动窗口分配给一个窗口, 对于滑动窗口可能会分配给多个窗口;Trigger: 窗口触发器, 决定什么时候触发窗口操作;Function: 窗口函数, 对窗口中数据执行的操作;Evictor: 窗口驱逐器, 并不常用，在Function 前后

去重计算应该是数据分析业务里面常见的指标计算，例如网站一天的访问用户数、广告的点击用户数等等，离线计算是一个全量、一次性计算的过程通常可以通过distinct的方式得到去重结果，而实时计算是一种增量、长期计算过程，我们在面对不同的场景，例如数据量的大小、计算结果精准度要求等可以使用不同的方案。此篇介绍如何通过编码方式实现精确去重，以一个实际场景为例：计算每个广告每小时的点击用户数，广告点击日志包含：广告位ID、用户设备ID(idfa/imei/cookie)、点击时间。实现步骤分析：为了当天的数据可重

出错程序:import java.sql.Timestampimport java.text.SimpleDateFormatimport org.apache.flink.api.common.typeinfo.Typesimport org.apache.flink.streaming.api.TimeCharacteristicimport org.apache.flink.streaming.api.functions.sink.SinkFunctionimport org.apach