flink和其它模块交互

Flink从kafka消息队列读取数据

转载：https://blog.csdn.net/yanshien840826/article/details/111313896
flink文档：https://www.bookstack.cn/read/BigData-Notes/notes-Flink_Data_Sink.md
1、首先要设置Flink的执行环境

// 创建Flink执行环境
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

2、设置Kafka相关参数，连接对应的服务器和端口号，读取名为Shakespeare的Topic中的数据源，将数据源命名为stream：

// Kafka参数
Properties properties = new Properties();
properties.setProperty("bootstrap.servers", "localhost:9092");
properties.setProperty("group.id", "flink-group");
String inputTopic = "Shakespeare";
String outputTopic = "WordCount";

// Source
FlinkKafkaConsumer<String> consumer =
                new FlinkKafkaConsumer<String>(inputTopic, new SimpleStringSchema(), properties);
DataStream<String> stream = env.addSource(consumer);

3、使用Flink算子处理这个数据流：

// Transformations
// 使用Flink算子对输入流的文本进行操作
// 按空格切词、计数、分区、设置时间窗口、聚合
DataStream<Tuple2<String, Integer>> wordCount = stream
    .flatMap((String line, Collector<Tuple2<String, Integer>> collector) -> {
      String[] tokens = line.split("\\s");
      // 输出结果 (word, 1)
      for (String token : tokens) {
        if (token.length() > 0) {
          collector.collect(new Tuple2<>(token, 1));
        }
      }
    })
    .returns(Types.TUPLE(Types.STRING, Types.INT))
    .keyBy(0)
    .timeWindow(Time.seconds(5))
    .sum(1);

4、这里使用的是Flink提供的DataStream级别的API，主要包括转换、分组、窗口和聚合等操作。

将数据流打印：

// Sink
wordCount.print();

最后执行这个程序：

// execute
env.execute("kafka streaming word count");

5、env.execute 是启动Flink作业所必需的，只有在execute()被调用时，之前调用的各个操作才会在提交到集群上或本地计算机上执行。

flink的窗口函数

在流处理应用中， 数据是连续不断的， 需要通过窗口的方式对流数据进行一定范围的聚合计算，例如统计在过去的 1 分钟内有多少用户点击某一网页，在这种情况下，我们必须定义一个窗口， 用来收集最近一分钟内的数据， 并对这个窗口内的数据进行再计算。Flink 将窗口划分为基于 Time、Count、Session，以及 Data-driven 等类型的窗口操作， 窗口可以用灵活的触发条件定制化来达到对复杂的流传输模式的支持， 用户可以定义不同的窗口触发机制来满足不同的需求。

原文链接：https://blog.csdn.net/lzxlfly/article/details/106876066

flink 写kafka_flink消费kafka的offset与checkpoint

https://blog.csdn.net/weixin_39845613/article/details/112076351
读取kafka的数据，然后使用hive catalog，实时写入hbase，hive，redis。使用的flink版本为1.11.1。为了防止写入hive的文件数量过多，我设置了checkpoint为30分钟。

checkpoint机制：https://zhuanlan.zhihu.com/p/263831130

env.enableCheckpointing(1000 * 60 * 30); // 1000 * 60 * 30 => 30 minutes
hive> dfs -ls /opt/user/hive/warehouse/dw.db/ods_analog_zgyp/dt_day=2020-10-18/dt_hour=00/ ;Found 10 items-rw-r--r--   3 hdfs hive          0 2020-10-18 01:20 /opt/user/hive/warehouse/dw.db/ods_analog_zgyp/dt_day=2020-10-18/dt_hour=00/_SUCCESS-rw-r--r--   3 hdfs hive     248895 2020-10-18 00:20 /opt/user/hive/warehouse/dw.db/ods_analog_zgyp/dt_day=2020-10-18/dt_hour=00/part-5b7b6d44-993a-4af7-b7ee-1a8ab64d3453-0-10911-rw-r--r--   3 hdfs hive     306900 2020-10-18 00:50 /opt/user/hive/warehouse/dw.db/ods_analog_zgyp/dt_day=2020-10-18/dt_hour=00/part-5b7b6d44-993a-4af7-b7ee-1a8ab64d3453-0-10912-rw-r--r--   3 hdfs hive     208227 2020-10-18 01:20 /opt/user/hive/warehouse/dw.db/ods_analog_zgyp/dt_day=2020-10-18/dt_hour=00/part-5b7b6d44-993a-4af7-b7ee-1a8ab64d3453-0-10913-rw-r--r--   3 hdfs hive     263586 2020-10-18 00:20 /opt/user/hive/warehouse/dw.db/ods_analog_zgyp/dt_day=2020-10-18/dt_hour=00/part-5b7b6d44-993a-4af7-b7ee-1a8ab64d3453-1-10911-rw-r--r--   3 hdfs hive     307723 2020-10-18 00:50 /opt/user/hive/warehouse/dw.db/ods_analog_zgyp/dt_day=2020-10-18/dt_hour=00/part-5b7b6d44-993a-4af7-b7ee-1a8ab64d3453-1-10912-rw-r--r--   3 hdfs hive     196777 2020-10-18 01:20 /opt/user/hive/warehouse/dw.db/ods_analog_zgyp/dt_day=2020-10-18/dt_hour=00/part-5b7b6d44-993a-4af7-b7ee-1a8ab64d3453-1-10913-rw-r--r--   3 hdfs hive     266984 2020-10-18 00:20 /opt/user/hive/warehouse/dw.db/ods_analog_zgyp/dt_day=2020-10-18/dt_hour=00/part-5b7b6d44-993a-4af7-b7ee-1a8ab64d3453-2-10911-rw-r--r--   3 hdfs hive     338992 2020-10-18 00:50 /opt/user/hive/warehouse/dw.db/ods_analog_zgyp/dt_day=2020-10-18/dt_hour=00/part-5b7b6d44-993a-4af7-b7ee-1a8ab64d3453-2-10912-rw-r--r--   3 hdfs hive     216655 2020-10-18 01:20 /opt/user/hive/warehouse/dw.db/ods_analog_zgyp/dt_day=2020-10-18/dt_hour=00/part-5b7b6d44-993a-4af7-b7ee-1a8ab64d3453-2-10913hive> 

但是，同时也观察到归属于这个作业的kafka消费组积压数量，每分钟消费数量，明显具有周期性消费峰值。

比如，对于每30分钟时间间隔度的一个观察，前面25分钟的“每分钟消费数量”都是为0，然后，后面5分钟的“每分钟消费数量”为300k。同理，“消费组积压数量”也出现同样情况，积压数量一直递增，但是到了30分钟的间隔，就下降到数值0。如图。

证明：flink使用savepoint启动作业，不会重复消费kafka数据，也会正确更新kafka的offset。

重申，以上试验证明：

• flink消费了kafka数据后，不会更新offset到kafka，直到checkpoint完成。
• flink在没有使用savepoint重启作业的时候，消费kafka的offset还是从kafka自身获取，存在重复消费数据的情况。
• flink使用savepoint重启作业，不会重复消费kafka数据，也会正确更新kafka的offset。

flink怎么保证eos

https://zhuanlan.zhihu.com/p/348559815
在 Flink 中需要端到端精准一次处理的位置有三个：

Source 端：数据从上一阶段进入到 Flink 时，需要保证消息精准一次消费。
Flink 内部端：这个我们已经了解，利用 Checkpoint 机制，把状态存盘，发生故障的时候可以恢复，保证内部的状态一致性。
Sink 端：将处理完的数据发送到下一阶段时，需要保证数据能够准确无误发送到下一阶段。

在 Flink 1.4 版本之前，精准一次处理只限于 Flink 应用内，也就是所有的 Operator 完全由 Flink 状态保存并管理的才能实现精确一次处理。但 Flink 处理完数据后大多需要将结果发送到外部系统，比如 Sink 到 Kafka 中，这个过程中 Flink 并不保证精准一次处理。
在 Flink 1.4 版本正式引入了一个里程碑式的功能：两阶段提交 Sink，即 TwoPhaseCommitSinkFunction 函数。该 SinkFunction 提取并封装了两阶段提交协议中的公共逻辑，自此 Flink 搭配特定 Source 和 Sink（如 Kafka 0.11 版）实现精确一次处理语义(英文简称：EOS，即 Exactly-Once Semantics)。

端到端精准一次处理语义（EOS）
以下内容适用于 Flink 1.4 及之后版本
对于 Source 端：Source 端的精准一次处理比较简单，毕竟数据是落到 Flink 中，所以 Flink 只需要保存消费数据的偏移量即可， 如消费 Kafka 中的数据，Flink 将 Kafka Consumer 作为 Source，可以将偏移量保存下来，如果后续任务出现了故障，恢复的时候可以由连接器重置偏移量，重新消费数据，保证一致性。

对于 Sink 端：Sink 端是最复杂的，因为数据是落地到其他系统上的，数据一旦离开 Flink 之后，Flink 就监控不到这些数据了，所以精准一次处理语义必须也要应用于 Flink 写入数据的外部系统，故这些外部系统必须提供一种手段允许提交或回滚这些写入操作，同时还要保证与 Flink Checkpoint 能够协调使用（Kafka 0.11 版本已经实现精确一次处理语义）。

我们以 Flink 与 Kafka 组合为例，Flink 从 Kafka 中读数据，处理完的数据在写入 Kafka 中。
为什么以Kafka为例，第一个原因是目前大多数的 Flink 系统读写数据都是与 Kafka 系统进行的。第二个原因，也是最重要的原因 Kafka 0.11 版本正式发布了对于事务的支持，这是与Kafka交互的Flink应用要实现端到端精准一次语义的必要条件。

当然，Flink 支持这种精准一次处理语义并不只是限于与 Kafka 的结合，可以使用任何 Source/Sink，只要它们提供了必要的协调机制。
Flink 与 Kafka 组合

flink发压怎么处理，数据堆积怎么处理

1、反压出现的场景

反压经常出现在促销、热门活动等场景。短时间内流量陡增造成数据的堆积或者消费速度变慢。

它们有一个共同的特点：数据的消费速度小于数据的生产速度。

2、反压监控方法

通过Flink Web UI发现反压问题

Flink 的 TaskManager 会每隔 50 ms 触发一次反压状态监测，共监测 100 次，并将计算结果反馈给 JobManager，最后由 JobManager 进行计算反压的比例，然后进行展示。

这个比例展示逻辑如下：

OK: 0 <= Ratio <= 0.10，正常；

LOW: 0.10 < Ratio <= 0.5，一般；

HIGH: 0.5 < Ratio <= 1，严重。

3、flink反压的实现方式

Flink任务的组成由基本的“流”和“算子”构成，“流”中的数据在“算子”间进行计算和转换时，会被放入分布式的阻塞队列中。当消费者的阻塞队列满时，则会降低生产者的数据生产速度

4、反压问题定位和处理

Flink会因为数据堆积和处理速度变慢导致checkpoint超时，而checkpoint是Flink保证数据一致性的关键所在，最终会导致数据的不一致发生。

数据倾斜：可以在 Flink 的后台管理页面看到每个 Task 处理数据的大小。当数据倾斜出现时，通常是简单地使用类似 KeyBy 等分组聚合函数导致的，需要用户将热点 Key 进行预处理，降低或者消除热点 Key 的影响

GC：不合理的设置 TaskManager 的垃圾回收参数会导致严重的 GC 问题，我们可以通过 -XX:+PrintGCDetails 参数查看 GC 的日志。

代码本身：开发者错误地使用 Flink 算子，没有深入了解算子的实现机制导致性能问题。我们可以通过查看运行机器节点的 CPU 和内存情况定位问题

1.问题定位口诀
“一压二查三指标，延迟吞吐是核心。
时刻关注资源量 , 排查首先看GC。”
一压是指背压，遇到问题先看背压的情况，二查就是指 checkpoint ，对齐数据的时间是否很长，state 是否很大，这些都是和系统吞吐密切相关的，三指标就是指 Flink UI 那块的一些展示，我们的主要关注点其实就是延迟和吞吐，系统资源，还有就是 GC logs。

看反压：通常最后一个被压高的 subTask 的下游就是 job 的瓶颈之一。
看 Checkpoint 时长：Checkpoint 时长能在一定程度影响 job 的整体吞吐。
看核心指标：指标是对一个任务性能精准判断的依据，延迟指标和吞吐则是其中最为关键的指标。
资源的使用率：提高资源的利用率是最终的目的。
https://zhuanlan.zhihu.com/p/149147987

二、如何处理生产环境中的数据倾斜问题？

1、flink数据倾斜的表现：

任务节点频繁出现反压，增加并行度也不能解决问题

部分节点出现OOM异常，是因为大量的数据集中在某个节点上，导致该节点内存被爆，任务失败重启

2、数据倾斜产生的原因：

业务上有严重的数据热点，比如滴滴打车的订单数据中北京、上海等几个城市的订单量远远超过其他地区；

技术上大量使用了 KeyBy、GroupBy 等操作，错误的使用了分组 Key，人为产生数据热点。

3、解决问题的思路：

业务上要尽量避免热点 key 的设计，例如我们可以把北京、上海等热点城市分成不同的区域，并进行单独处理；

技术上出现热点时，要调整方案打散原来的 key，避免直接聚合；此外 Flink 还提供了大量的功能可以避免数据倾斜。

三、Flink 任务数据倾斜场景和解决方案

A、两阶段聚合解决 KeyBy 热点：

首先把分组的 key 打散，比如加随机后缀；
对打散后的数据进行聚合；
把打散的 key 还原为真正的 key；
二次 KeyBy 进行结果统计，然后输出。

DataStream sourceStream = ...;
resultStream = sourceStream
     .map(record -> {
        Record record = JSON.parseObject(record, Record.class);
        String type = record.getType();
        record.setType(type + "#" + new Random().nextInt(100));
        return record;
      })
      .keyBy(0)
      .window(TumblingEventTimeWindows.of(Time.minutes(1)))
      .aggregate(new CountAggregate())
      .map(count -> {
        String key = count.getKey.substring(0, count.getKey.indexOf("#"));
        return RecordCount(key,count.getCount);
      })
      //二次聚合
      .keyBy(0)
      .process(new CountProcessFunction);
resultStream.sink()...
env.execute()...

B、GroupBy + Aggregation 分组聚合热点问题:

将SQL 拆成了内外两层，第一层通过随机打散 100 份的方式减少数据热点，当然这个打散的方式可以根据业务灵活指定。

select date,
       type,
       sum(pv) as pv
from(
  select
        date,
        type,
        sum(count) as pv
  from table
        group by
        date,
        type,
        floor(rand()*100) --随机打散成100份 
    )
    group by 
    date,
    type;

C、Flink 消费 Kafka 上下游并行度不一致导致的数据倾斜

Flink 消费 Kafka 的数据时，是推荐上下游并行度保持一致，即 Kafka 的分区数等于 Flink Consumer 的并行度。

但是会有一种情况，为了加快数据的处理速度，来设置 Flink 消费者的并行度大于 Kafka 的分区数。如果你不做任何的设置则会导致部分 Flink Consumer 线程永远消费不到数据。需要设置 Flink 的 Redistributing，也就是数据重分配。

dataStream
        .setParallelism(2)
        // 采用REBALANCE分区策略重分区
        .rebalance() //.rescale()
        .print()
        .setParallelism(4);

Rebalance 分区策略，数据会以 round-robin 的方式对数据进行再次分区，可以全局负载均衡。
Rescale 分区策略基于上下游的并行度，会将数据以循环的方式输出到下游的每个实例中

三、flink维度表关联

根据我们业务对维表数据关联的时效性要求，有以下几种解决方案：

1、实时查询维表

实时查询维表是指用户在Flink 的Map算子中直接访问外部数据库，比如用 MySQL 来进行关联，这种方式是同步方式，数据保证是最新的。最后，为了保证连接及时关闭和释放，一定要在最后的 close 方式释放连接，否则会将 MySQL 的连接数打满导致任务失败。

一般我们在查询小数据量的维表情况下才使用这种方式，并且要妥善处理连接外部系统的线程，一般还会用到线程池。

2、预加载全量数据

当我们的系统启动时，就将维度表数据全部加载到内存中，然后数据在内存中进行关联，不需要直接访问外部数据库。一旦维表数据发生更新，Flink 任务是无法感知,可以采取定时拉取维表数据
对计算节点的内存消耗很高，所以不能适用于数量很大的维度表

适用于那些实时场景不是很高，维表数据较小的场景

3、LRU 缓存(最近最少使用的数据则被淘汰)

如果维表的数据比较大，无法一次性全部加载到内存中，可以使用LRU策略加载维表数据。

利用 Flink 的 RichAsyncFunction 读取 Hbase 的数据到缓存中，我们在关联维度表时先去查询缓存，如果缓存中不存在这条数据，就利用客户端去查询 Hbase，然后插入到缓存中

4、将维表消息广播出去
//1：初始化数据
DataSet toBroadcast = env.fromElements(1, 2, 3)

//2：广播数据
.withBroadcastSet(toBroadcast, “broadcastSetName”);

//3：获取数据
Collection broadcastSet = getRuntimeContext().getBroadcastVariable(“broadcastSetName”);
四、flink海量数据高效去重
①基于状态后端
②基于HyperLogLog：不是精准的去重
③基于布隆过滤器（BloomFilter）
快速判断一个key是否存在于某容器，不存在就直接返回。
④基于BitMap
用一个bit位来标记某个元素对应的Value，而Key即是该元素。由于采用了Bit为单位来存储数据，因此可以大大节省存储空间。
⑤基于外部数据库
选择使用Redis或者HBase存储数据，我们只需要设计好存储的Key即可，不需要关心Flink任务重启造成的状态丢失问题

五、Flink 任务出现很高的延迟，你会如何入手解决类似问题？
在 Flink 的后台任务管理中，可以看到 Flink 的哪个算子和 task 出现了反压；

资源调优和算子调优：资源调优即对作业中的 Operator 并发数（Parallelism）、CPU（Core）、堆内存（Heap_memory）等参数进行调优；

作业参数调优：并行度的设置、State 的设置、Checkpoint 的设置。

六、flink在快照过程中，一个节点挂了怎么办
快照之间的节点挂了

flink消费kafka的offset，存在哪里：
1、http://wuchong.me/blog/2018/11/04/how-apache-flink-manages-kafka-consumer-offsets/
2、https://www.ververica.com/blog/kafka-flink-a-practical-how-to

flink这边用过哪些state，处理的过程当中有哪些状态
什么情况下存这个状态，以及这个状态是做什么用的

flink消费kafka到数据库，怎么保证数据仅有一次
flink+checkpoint+事务
flink+checkpoint+幂等

hive sql

java基础：线程创建的方式，四种
多线程的同步、并发
hashmap为什么线程不安全，表现在哪，什么情况
链表有没有环，jvm

大数据底层

hdfs查看目录的大小