- 博客(43)
- 收藏
- 关注
RSS订阅原创 Flink 组件详解及任务提交流程
控制一个应用程序执行的主进程，也就是说，每个应用程序都会被一个不同的Jobmanager所控制执行Jobmanager会先接收到要执行的应用程序，这个应用程序会包括：作业图（ Job Graph）、逻辑数据流图（ ogical dataflow graph）和打包了所有的类、库和其它资源的JAR包。Jobmanager会把Jobgraph转换成一个物理层面的数据流图，这个图被叫做“执行图”(Executiongraph)，包含了所有可以并发执行的任务。Job Manager会。
2024-04-23 13:30:00
1604
2
原创 Flink 数据倾斜问题
据本身就不均匀，例如由于某些原因Kafka的topic中某些partition的数据量较大，某些partition的数据量较少。使用shuffle、rebalance、rescale算子即可将数据均匀分配，从而解决数据倾斜的问题。如果keyBy之前就存在数据倾斜，上游算子的某些实例可能处理的数据较多，某些实例可能处理的数据较少，产生该情况可能是因为数据源的数。第二阶段聚合：去掉随机数前缀或后缀，按照原来的key及windowEnd作keyby、聚合。3.keyBy后的窗口聚合操作存在数据倾斜。
2024-04-22 09:41:07
343
1
原创 Flink Leader Epoch
假设现在有两个 Leader Epoch 和 ，那么，第一个 Leader Epoch 表示版本号是 0，这个版本的 Leader 从位移 0 开始保存消息，一。这样，每次有 Leader 变更时，新的 Leader 副本会查询这部分缓存，取出对应的 Leader Epoch 的起始位移，以避免数据丢失和不一致的情况。之后，Leader 发生了变更，版本号增加到 1，新版本的起始位移是 120。2.起始位移，leader副本在该Epoch值上写入的首条消息的位移。
2024-04-19 13:11:49
214
1
原创 Kafka事务机制的原理
Transaction Coordinator 的主要责任是协调和管理事务的生命周期,它与 Producer 和 Consumer 之间进行通信，主要负责分配PID，记录事务状态等操作，确保事务的正确执行,每个事务协调器负责一组Partition的事务协调工作。总体而言，Kafka 在事务机制下通过 Transaction Coordinator 和 Transaction Log 的结合，以及复制协议和选举机制的应用，实现了对事务状态的持久化存储和对 Coordinator 故障的容错处理。
2024-04-16 09:20:13
622
原创 Leader总是-1，怎么解决？
当然了，当你知道controller的注册机制后，你也可以说：删除ZooKeeper节点/controller，触发Controller重选举。重启Controller节点上的Kafka进程，让其他节点重新注册Controller角色，但是如上面ZooKeeper的作用。但是，需要注意的是，直接操作ZooKeeper是一件风险很大的操作，就好比在Linux中执行了rm -rf /xxx一样，如果在/和xxx之间不小心多了几个空格。通常情况下就是Controller不工作了，导致无法分配leader，
2024-04-12 13:05:37
431
2
原创 LEO、LSO、AR、ISR、HW都表示什么含义？
ISR（In-Sync Replicas）：Kafka中特别重要的概念，指代的是AR中那些与Leader保持同步的副本集合。LEO（Log End Offset）：日志末端位移值或末端偏移量，表示日志下一条待插入消息的位移值。举个例子，如果日志有10条消息，位移值从0开始，它经常与Log Start Offset，即日志起始位移值相混淆，因为有些人将后者缩写成LSO，这是不对的。AR（Assigned Replicas）：AR是主题被创建后，分区创建时被分配的副本集合，副本个数由副本因子决定。
2024-04-12 13:02:49
369
2
原创 Flink如何和Yarn进行交互
ResourceManager分配Container资源并启动ApplicationMaster,然后AppMaster加载Flink的Jar包和配置构建环境,启动JobManager，JobManager和ApplicationMaster运行在同一个container上。此外，AppMaster容器也提供了Flink的web服务接口。ApplicationMaster向ResourceManager申请工作资源,NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager。
2024-04-11 10:39:18
142
原创 Flink生产环境配置注意事项
Flink Kafka source的并行度需要和kafka topic的分区数一致。最大化利用kafka多分区topic的并行读取能力。由于一个Kafka分区只能被一个消费者消费，因此一定要确保Flink Kafka source的并行度不要大于Kafka分区数，否则有些计算资源会空闲。如果并行度和分区数相同配置后，消费数据的速度仍然跟不上生产数据的速度，需要加大Kafka的分区数。同理，如果Sink端也是Kafka，sink的并行度尽量和Kafka分区数一致。
2024-04-10 15:30:39
44
原创 Flink Barrier机制
当一个中间（Intermediate）Operator接收到一个Barrier后，它会发送Barrier到属于该Barrier的Snapshot的数据流中，等到Sink Operator接收到该Barrier后会向Checkpoint Coordinator确认该Snapshot，直到所有的Sink Operator都确认了该Snapshot，才被认为完成了该Snapshot。接收到Barrier n的Stream被临时搁置，来自这些Stream的记录不会被处理，而是被放在一个Buffer中。
2024-04-10 14:14:58
344
原创 Flink 分布式缓存原理
当程序执行，Flink自动将文件或者目录复制到所有taskmanager节点的本地文件系统，仅会执行一次。此缓存的工作机制如下：程序注册一个文件或者目录(本地或者远程文件系统，例如hdfs或者s3)，通过ExecutionEnvironment注册缓存文件并为它起一个名称。Flink提供了一个分布式缓存，类似于hadoop，可以使用户在并行函数中很方便的读取本地文件，并把它放在taskmanager节点中，防止task重复拉取。
2024-04-10 09:13:30
105
原创 Flink重启策略
Flink默认重启策略是通过Flink的配置文件设置的flink-conf.yaml,配置参数restart-strategy定义采用的策略。注意：如果启用了checkpoint并且没有显式配置重启策略，会默认使用fixeddelay策略，最大重试次数为Integer.MAX_VALUE。
2024-04-10 09:13:16
608
原创 Flink是如何实现Exactly-once
在flink1.4.0之前，flink通过checkpoint保证了flink应用内部的exactly-once语义。如果flink应用失败或者升级时，可以拉取checkpoint中的状态来恢复上次失败时的数据。两次提交来保证语义的方式需要flink所连接的外部系统支持两部提交，也就是外部系统要支持可以预提交和回滚没有最终提交的数据这样子的特性。可以根据状态来提交预提交的数据，也可删除预提交的数据。exactly-once语义就是保证最后的数据处理的结果和数据摄入时没有数据的丢失与重复。
2024-04-10 09:12:58
139
原创 Impala中的刷新元数据和刷新表
主要用于表中元数据未修改，数据的修改，例如insert into、load data、alter table add partition、llter table drop partition等，refresh是用于刷新某个表或者某个分区的数据信息，它会重用之前的表元数据，仅仅执行文件刷新操作，它能够检测到表中分区的增加和减少，invalidate metadata是用于刷新全库或者某个表的元数据，包括表的元数据和表内的文件数据，它会首先清楚表的缓存，
2024-04-09 13:06:00
497
原创 Flink的时间类型和watermark机制
Watermark是一个对Event Time的标识，内容方面Watermark是个时间戳，一个带有时间戳X的Watermark到达，相当于告诉Flink系统，Processing Time并不能保证确定性，它容易受到Event到达系统的速度（例如来自消息队列）以及数据在Flink系统内部处理的先后顺序的影响，首先如果这种事情出现的概率非常小，不影响所要求的准确度，除了把违反watermark机制的数据丢弃，也有不丢弃的处理方法，比如通过一些机制来更新之前统计的结果，这种方式会有一定的性能开销。
2024-04-09 11:41:45
343
原创 kafka如何保证数据的顺序消费
①、kafka的顺序消息仅仅是通过partitionKey，将某类消息写入同一个partition，一个partition只能对应一个消费线程，以保证数据有序。③、kafka broker宕机，kafka会有自选择，所以宕机不会减少partition数量，也就不会影响partitionKey的sharding。1、如顺序消费中的第①点说明，生产者在写的时候，可以指定一个 key，比如说我们指定了某个订单 id 作为 key，那么这个订单相关的数据，而多个线程并发的话，到这里，顺序还是 ok 的，没有错乱。
2024-04-09 11:37:02
588
原创 Elasticsearch 性能调优
如果我们对搜索的实效性要。cluster.name: elasticsearch：配置Elasticsearch的集群名称，默认值是elasticsearch，建议改成与所存数据相关的名称，Elasticsearch会自动发现在同一网段下的集群名称相同的节点。随着数据量的变化，段的数量会越来越多，消耗的多文件句柄数及CPU就越多，查询效率就会下降。discovery.zen.minimum_master_nodes: 1：设置在选举Master节点时需要参与的最少的候选主节点数，默认为1.如果使用默认值，
2024-04-09 11:33:52
57
原创 spark 宽依赖与窄依赖
窄依赖是指父RDD的每个分区只被子RDD的一个分区所使用，子RDD一般对应父RDD的一个或者多个分区。下面的join也是窄依赖，虽然有两个父RDD，但是两个 RDD中每个分区都被一个子RDD的分区使用，即使父RDD的分区里面的内容并没有让子。对于宽依赖，重算的父RDD分区对应多个子RDD分区，这样实际上父RDD 中只有一部分的数据是被用于恢复这个丢失的子RDD分区的，对于窄依赖，由于父RDD的一个分区只对应一个子RDD分区，这样只需要重算和子RDD分区对应的父RDD分区即可，RDD的一个分区使用。
2024-04-09 10:51:47
230
原创 Mysql快速定位已发生的死锁问题
在项目开发中，可能会遇到数据库发生死锁的情况出现，可以参考通过以下步骤，快速定位和发现死锁的位置，并手动解决死锁。通过杀掉发生死锁的其中一个线程，一般情况则会解决死锁问题，如果还未解决死锁，则杀掉所有相关死锁线程。通过查看开启的事务，锁相同表的事务，容易导致死锁的发生，可以大致定位出出现死锁的事务。通过查看当前数据库打开了哪些表，可以大概分析出，死锁会发生在哪些表格中。通过查看，查找正在执行的SQL语句，定位到发生死锁的线程。通过查看正在等待锁的事务，则已经可以看出发生死锁的事务。查看数据库中打开的表。
2024-04-09 10:27:59
693
原创 spark 性能调优
（1）通过配置文件 spark-env.sh添加可以参照spark-env.sh.template模板文件中的格式进行配置，参见下面的格式。（2）在程序中通过SparkConf对象添加如果是在代码中添加，则需要在SparkContext定义之前修改配置项的修改。例如：（3）在程序中通过System.setProperty添加如果是在代码中添加，则需要在SparkContext定义之前修改配置项。例如：过早的性能优化是万恶之源，
2024-04-09 10:13:57
16
原创 Elasticsearch 配置调优
这两个参数搭配使用时，1、确定分片(shard)的数量和副本(replica)的数量 ElasticSearch在创建索引数据时，最好指定相关的shards数量和replicas，(如果节点数达到expected_nodes则立刻进行 recovery)，5分钟后，如果剩余的节点依然没有加入，则会进行数据 recovery。Mapping 相当于数据库中的schema，用来约束字段的类型，不过 Elasticsearch 的 mapping 可以自动根据数据创建。分片对应的是 Lucene 中的索引。
2024-04-09 09:54:08
48
原创 hbase org.apache.hadoop.hbase.RegionTooBusyException
blockingMemStoreSize=hbase.hregion.memstore.flush.size*hbase.hregion.memstore.block.multiplier（默认为4）=512M，这里将hbase.region.store.parallel.put.limit.min.column.count参数，线程处理的最小列数由默认100改为200。将hbase.region.store.parallel.put.limit参数，单region处理的并发数由默认10改为100。
2024-04-09 09:12:16
376
原创 线上Kafka突发rebalance异常，如何快速解决？
这个分配的过程，其实也是一个 rebalance 的过程。因为在 kafka 消费者的实现中，其是单线程去消费消息和执行心跳的，如果线程卡在处理消息，那么这时候即使到时间要心跳了，还是没有线程可以去执行心跳操作。很多同学在处理问题的时候，明明设置了很长的 session.timeout.ms 时间，但最终还是心跳超时了，就是因为没有处理好这两个参数的关联。所以每次拉取的消息数不能太多，需要保证在 max.poll.interval.ms 设置的时间内能消费完，否则会发生 rebalance。
2024-04-09 09:11:35
1624
原创 Flink CheckPoint原理和在生产中的应用
checkpointTimeout用于指定checkpoint执行的超时时间(单位milliseconds)，超时没完成就会被abort掉minPauseBetweenCheckpoints用于指定checkpoint coordinator上一个checkpoint完成之后最小等多久可以出发另一个checkpoint，当指定这个参数时，maxConcurrentCheckpoints的值为1。当CheckpointCoordinator收到所有算子的报告之后，认为该周期的快照制作成功;
2024-04-08 11:45:16
288
原创 Flink在大规模状态数据集下的checkpoint调优
因为Flink在checkpoint时是首先在每个task上做数据checkpoint，然后在外部存储中做checkpoint持久化。在这里的一个优化思路是：在总状态数据固定的情况下，当每个task平均所checkpoint的数据越少，那么相应地checkpoint的总时间也会变短。答案是应用会一直在做checkpoint，因为当应用发现它刚刚做完一次checkpoint后，又已经到了下次checkpoint的时间了，然后又开始新的checkpoint。Checkpoint的资源设置。
2024-04-08 11:40:15
186
原创 Kafka 分区分配策略
RangeAssignor 是 Kafka 默认的分区分配算法，它是按照 Topic 的维度进行分配的，对于每个 Topic，首先对 Partition 按照分区ID进行排序，然后对订阅这个 Topic 的 Consumer Group 的 Consumer 再进行排序，之后尽量均衡的按照范围区段将分区分配给 Consumer。注意：当两个目标发生冲突的时候，优先保证第一个目标，这样可以使分配更加均匀，其中第一个目标是3种分配策略都尽量去尝试完成的， 而第二个目标才是该算法的精髓所在。
2024-04-08 11:33:46
185
原创 Flink CDC
需要对源数据进行修改：Flink CDC需要在源数据库中创建特殊的日志表或触发器来捕获变更，这可能会影响源系统的性能和稳定性，对网络和存储资源的需求较高：Flink CDC需要大量的网络带宽和存储资源来处理大规模的数据流，并确保数据的及时性和正确性。可靠性：Flink CDC 提供了高可靠性的数据处理和容错机制，即使系统出现故障或错误，也能保证数据的安全性和正确性。需要专业知识：Flink CDC需要相当的专业知识和技能才能正确配置和操作，这可能会增加部署和运维的成本和风险。Flink CDC的优点。
2024-04-08 11:13:03
198
原创 Flink算子并行度与Slot的关系
通过对Yarn的学习我们可以了解到，每个Container都是一个独立的进程，一台物理机可以有多个Container存在（多个进程），每个Container都持有一定数量的CPU和Memory资源，而且是资源隔离的，进程间不共享，这就可以保证同一台机器上的多个TM之间是资源隔离的（Standalone模式下，同一台机器下若有多个TM，是做不到TM之间的CPU资源隔离的）注意：一个Tm内的slot只有内存上隔离，CPU是共享的。
2024-04-08 11:11:35
137
原创 Kubernetes和Docker之间的一些主要区别
在实际应用中，通常使用Docker来构建和打包应用程序的容器镜像，然后使用Kubernetes来管理和调度这些容器。Docker提供了容器化的基本功能，而Kubernetes提供了容器编排和管理的高级功能。1. 抽象层次不同：Docker提供了一种容器化的技术，而Kubernetes提供了一个容器编排和管理的平台。而Docker更注重容器本身的构建和管理。2. 管理范围不同：Docker主要用于本地开发和单主机环境中的容器管理，而Kubernetes适用于多主机或云环境中的容器编排和调度。
2024-04-08 11:09:03
312
原创 Flink Checkpoint 与SavePoint 剖析
默认情况下，如果设置了Checkpoint选项，则Flink只保留最近成功生成的1个Checkpoint，而当Flink程序失败时，可以从最近的这个Checkpoint来进行恢复。Flink通过Savepoint功能可以做到程序升级后，继续从升级前的那个点开始执行计算，保证数据不中断全局，一致性快照。Flink可以支持保留多个Checkpoint，需要在Flink的配置文件conf/flink-conf.yaml中，添加如下配置，指定最多需要保存Checkpoint的个数。SavePoint 剖析。
2024-04-08 11:02:41
83
原创 Flink Rich Functions与Functions区别
3.getRuntimeContext()方法提供了函数的RuntimeContext的一些信息， 可以通过改方法获取到函数执行并行度，任务名称，state状态等信息。Rich它与常规函数的不同在于，可以获取运行环境的上下文，并拥有一些生命周期方法， 所以可以实现更复杂的功能。2.最后一个方法close(), 做一些清理工作, 在每个并行度上只调用一次, 而且是最后被调用， 但读文件时在每个并行度上调用两次；默认生命周期方法：1.初始化方法open(), 在每个并行度上只会被调用一次, 而且先被调用；
2024-04-08 10:40:41
140
原创 Flink CEP 使用场景概述
就是可以在事件流里，检测到特定的事件组合并进行处理，比如说“连续登录失败”，或者“订单支付超时”等等。CEP 可以帮助在复杂的、看似不相关的事件流中找出那些有意义的事件组合，进而可以接近实时地进行分析判断、利用 CEP 可以用预先定义好的规则，对用户的行为轨迹进行实时跟踪，从而检测出具有特定行为习惯的一些用户，做出相应的用户画像。具体的处理过程是，把事件流中的一个个简单事件，通过一定的规则匹配组合起来，这就是“复杂事件”；可以进行精准营销，即对行为匹配预定义规则的用户实时发送相应的营销推广；
2024-04-08 10:32:47
132
原创 Flink 状态使用注意事项
只要对 KeyedStream。答案：在 STMapFunction 中可以使用 ValueState，在 STFilterFunction 和 STFlatMapFunction 中不能使用 ValueState。的操作才能使用 KeyedState，KeyedState 表示相同的 key 共享同一个 State，普通的 DataStream 中没有 key 的概念不能使用 KeyedState。Flink 的 ValueState 吗？
2024-04-08 10:23:53
122
原创 Kafka监控管理工具对比
所以，不要让你的KAFKA集群太大，故障恢复会是一场灾难。但是注意，当你的Topic太多，监控数据会占用你大量的带宽，为了达到Exactly once这个语义，KAFKA做了很多努力，努力的结果就是几乎不可用，吞吐量实在是太低了。Availability Monitor for Kafka 微软开源的Kafka可用性、延迟性的监控框架,提供JMX接口，用的很少。Kafka Web Console 监控功能较为全面，可以预览消息，监控Offset、Lag等信息，不建议在生产环境中使用。造成你的机器负载增高。
2024-04-08 10:14:17
114
原创 Flink Kafka实现端到端一致性代码实例
所以应该将隔离级别配置 为 read_committed，表示消费者遇到未提交的消息时，会停止从分区中消费数据，直到消息被标记为已提交才会再次恢复消费。Flink的Kafka连接器中配置的事务超时时间transaction.timeout.ms默认是1小时。//执行Checkpoint的时候提交offset到Checkpoint(Flink用)//3.1 设置事务超时时间，也可在kafka配置中设置。所以最后要配置的事务时间，应该小于Kafka配置的事务最大超时时间。//保存检查点的超时时间为5秒钟。
2024-04-08 09:47:10
39
原创 Kafka和Pulsar深入解析
组件依赖：Kafka Raft（KRaft）从Kafka 2.8开始处于早期访问模式，允许Kafka在没有ZooKeeper的情况下工作。然而，它的架构相对陈旧，在云原生时代，面对前景光明的新。组件依赖：对Pulsar的一个常见批评是它对ZooKeeper的强烈依赖，以及需要维护额外的存储系统，这需要运维人员掌握更多的技能。分层存储：内置分层存储，支持将冷数据移动到更便宜的存储选项，如AWS S3或谷歌云存储。生态系统：一个蓬勃发展的生态系统，拥有各种工具，如connector。云原生部署：相对复杂。
2024-04-08 09:30:20
125
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人