默硕的博客

因为Flink在checkpoint时是首先在每个task上做数据checkpoint，然后在外部存储中做checkpoint持久化。在这里的一个优化思路是：在总状态数据固定的情况下，当每个task平均所checkpoint的数据越少，那么相应地checkpoint的总时间也会变短。答案是应用会一直在做checkpoint，因为当应用发现它刚刚做完一次checkpoint后，又已经到了下次checkpoint的时间了，然后又开始新的checkpoint。Checkpoint的资源设置。

checkpointTimeout用于指定checkpoint执行的超时时间(单位milliseconds)，超时没完成就会被abort掉minPauseBetweenCheckpoints用于指定checkpoint coordinator上一个checkpoint完成之后最小等多久可以出发另一个checkpoint，当指定这个参数时，maxConcurrentCheckpoints的值为1。当CheckpointCoordinator收到所有算子的报告之后，认为该周期的快照制作成功;

Flink Kafka source的并行度需要和kafka topic的分区数一致。最大化利用kafka多分区topic的并行读取能力。由于一个Kafka分区只能被一个消费者消费，因此一定要确保Flink Kafka source的并行度不要大于Kafka分区数，否则有些计算资源会空闲。如果并行度和分区数相同配置后，消费数据的速度仍然跟不上生产数据的速度，需要加大Kafka的分区数。同理，如果Sink端也是Kafka，sink的并行度尽量和Kafka分区数一致。

如果我们对搜索的实效性要。cluster.name: elasticsearch：配置Elasticsearch的集群名称，默认值是elasticsearch，建议改成与所存数据相关的名称，Elasticsearch会自动发现在同一网段下的集群名称相同的节点。随着数据量的变化，段的数量会越来越多，消耗的多文件句柄数及CPU就越多，查询效率就会下降。discovery.zen.minimum_master_nodes: 1：设置在选举Master节点时需要参与的最少的候选主节点数，默认为1.如果使用默认值，

（1）通过配置文件 spark-env.sh添加可以参照spark-env.sh.template模板文件中的格式进行配置，参见下面的格式。（2）在程序中通过SparkConf对象添加如果是在代码中添加，则需要在SparkContext定义之前修改配置项的修改。例如：（3）在程序中通过System.setProperty添加如果是在代码中添加，则需要在SparkContext定义之前修改配置项。例如：过早的性能优化是万恶之源，

这两个参数搭配使用时，1、确定分片(shard)的数量和副本(replica)的数量 ElasticSearch在创建索引数据时，最好指定相关的shards数量和replicas，(如果节点数达到expected_nodes则立刻进行 recovery)，5分钟后，如果剩余的节点依然没有加入，则会进行数据 recovery。Mapping 相当于数据库中的schema，用来约束字段的类型，不过 Elasticsearch 的 mapping 可以自动根据数据创建。分片对应的是 Lucene 中的索引。

默认情况下，如果设置了Checkpoint选项，则Flink只保留最近成功生成的1个Checkpoint，而当Flink程序失败时，可以从最近的这个Checkpoint来进行恢复。Flink通过Savepoint功能可以做到程序升级后，继续从升级前的那个点开始执行计算，保证数据不中断全局，一致性快照。Flink可以支持保留多个Checkpoint，需要在Flink的配置文件conf/flink-conf.yaml中，添加如下配置，指定最多需要保存Checkpoint的个数。SavePoint 剖析。

组件依赖：Kafka Raft（KRaft）从Kafka 2.8开始处于早期访问模式，允许Kafka在没有ZooKeeper的情况下工作。然而，它的架构相对陈旧，在云原生时代，面对前景光明的新。组件依赖：对Pulsar的一个常见批评是它对ZooKeeper的强烈依赖，以及需要维护额外的存储系统，这需要运维人员掌握更多的技能。分层存储：内置分层存储，支持将冷数据移动到更便宜的存储选项，如AWS S3或谷歌云存储。生态系统：一个蓬勃发展的生态系统，拥有各种工具，如connector。云原生部署：相对复杂。

定时器具有容错能力，并且会与应用程序的状态一起进行 Checkpoint，如果发生故障重启会从 Checkpoint／Savepoint 中恢复定时器的状态。每次调用 processElement() 都可以获得一个 Context 对象，通过该对象可以访问元素的事件时间。如果是KeyedStream ，可以使用KeyedProcessFunction函数，它是ProcessFunction 的一个扩展。处理时间定时器原本是要在恢复起来的那个时间之前触发的，那么在恢复的那一刻会立即触发该定时器。

所以应该将隔离级别配置 为 read_committed，表示消费者遇到未提交的消息时，会停止从分区中消费数据，直到消息被标记为已提交才会再次恢复消费。Flink的Kafka连接器中配置的事务超时时间transaction.timeout.ms默认是1小时。//执行Checkpoint的时候提交offset到Checkpoint(Flink用)//3.1 设置事务超时时间，也可在kafka配置中设置。所以最后要配置的事务时间，应该小于Kafka配置的事务最大超时时间。//保存检查点的超时时间为5秒钟。