flink
未读
深入解析 Flink 的算子链机制
Flink 算子链简介 笔者在 Flink 社区群里经常能看到类似这样的疑问。这种情况几乎都不是程序有问题，而是因为 Flink 的 operator chain ——即算子链机制导致的，即提交的作业的执行计划中，所有算子的并发实例（即 sub-task ）都因为满足特定条件而串成了整体来执行，自然
Flink新增特性 | CDC(Change Data Capture) 原理和实践应用
CDC简介 CDC,Change Data Capture,变更数据获取的简称，使用CDC我们可以从数据库中获取已提交的更改并将这些更改发送到下游，供下游使用。这些变更可以包括INSERT,DELETE,UPDATE等。 用户可以在以下的场景下使用CDC： 使用flink sql进行数据同步,可以将
flink
未读
Flink State实践总结
1、 结论 从性能和 TTL 两个维度来描述区别。 性能 · RocksDB 场景，MapState 比 ValueState 中存 Map 性能高很多。 · 生产环境强烈推荐使用 MapState，不推荐 ValueState 中存大对象 · ValueState 中存大对象很容易使 CPU 打满
flink
未读
双亲委派模型与 Flink 的类加载策略
我们知道，在 JVM 中，一个类加载的过程大致分为加载、链接（验证、准备、解析）、初始化5个阶段。而我们通常提到类的加载，就是指利用类加载器（ClassLoader）通过类的全限定名来获取定义此类的二进制字节码流，进而构造出类的定义。 Flink 作为基于 JVM 的框架，在 flink-conf.
flink
未读
Flink RocksDB 状态后端参数调优实践
https://segmentfault.com/a/1190000024522233 截至当前，Flink 作业的状态后端仍然只有 Memory、FileSystem 和 RocksDB 三种可选，且 RocksDB 是状态数据量较大（GB 到 TB 级别）时的唯一选择。RocksDB 的性能发挥
Flink State 最佳实践
1. State 概念回顾 我们先回顾一下到底什么是 state，流式计算的数据往往是转瞬即逝， 当然，真实业务场景不可能说所有的数据都是进来之后就走掉，没有任何东西留下来，那么留下来的东西其实就是称之为 state，中文可以翻译成状态。 在下面这个图中，我们的所有的原始数据进入用户代码之后再输出到
在 Flink 中规划 RocksDB 内存容量
Tips：从 Flink 1.10 开始，Flink 自动管理 RocksDB 的内存，详细介绍如下：https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/state/state_backends.html#memory-m
Flink 原理与实现：如何处理反压问题
流处理系统需要能优雅地处理反压（backpressure）问题。反压通常产生于这样的场景：短时负载高峰导致系统接收数据的速率远高于它处理数据的速率。许多日常问题都会导致反压，例如，垃圾回收停顿可能会导致流入的数据快速堆积，或者遇到大促或秒杀活动导致流量陡增。反压如果不能得到正确的处理，可能会导致资源
Flink DataStream 关联维表
衡量指标 总体来讲，关联维表有三个基础的方式：实时数据库查找关联（Per-Record Reference Data Lookup）、预加载维表关联（Pre-Loading of Reference Data）和维表变更日志关联（Reference Data Change Stream），而根据实现