共计 2883 个字符，预计需要花费 8 分钟才能阅读完成。
一、实时开发常见问题
1、一个实时计算工作该调配多少资源？
倡议：一些简略 ETL 工作，并且源数据流量在肯定范畴内，tm 个数 1、全局并行度 1、内存 1G。
剖析：
全局并行度为 1，对于简略 ETL 工作会有 operator chain，在一个 task(线程)中运行、缩小线程切换、缩小音讯序列化 / 反序列化等，该类问题的瓶颈个别在上游写入端。写入端是瓶颈：个别倡议开启批量写入(须要管制批量大小，避免内存溢出)、开启多并行度写入。如果是单台数据库的瓶颈：开启多个并行度就没法晋升性能、个别倡议依照肯定路由规定写入多台数据库、倡议应用分布式数据库(如 Hbase：提前建设分区、防止数据热点写入等)。2、为什么写入 Kafka 后果中有些分区没有数据？
倡议：如果现有 topic 曾经存在，并且是多个分区，后果表并行度设置 partition 数一样。
剖析：
因为 Flink 写 Kafka 默认采纳的是 FixedPartitioner。如果并行度比 partition 大，则数据都会发送到 partition 中，然而如果并行度比 partition 小，则有局部分区是没有数据的。source 端，如果并行度小于 partition，会取模的形式分给并行度，都会生产到数据。如果并行度大于 partition，则会有局部 task 生产不到数据。3、为什么和维表关联后工作解决数据的能力变慢？
倡议：小数据量不常更新的维表应用 ALL 模式。大数据量的维表应用应用 LRU 模式，并且依据数据库不同做相应的解决(比方关系型数据库则建设索引等)。
剖析：1.ALL 模式启动时候间接将数据全量加载到内存中，每次关联数据不须要查库，没有其余开销。2. 异步 (async) 查问模式
LRU 异步查询数据库，能够并发地解决多个申请。依据 SQL 中的关联字段程序建设复合索引。避免关联字段索引生效(关联程序不对、关联列做计算等)。如果维表字段个数少，思考将将多余字段都退出到索引中，缩小回表(带来的问题是索引变大)。4、为什么某些工作进步并行度能晋升性能，某些不能？
倡议：查看是否数据歪斜，如果是将数据打散。
剖析：
源头是否数据歪斜。SQL 中是否存在导致歪斜的语句。登陆到 Flink web 页面查看。通过批改 SQL 解决或者打散 groupby 字段。二、实时工作运维
1、配置反压告警
场景：反压导致 cp 失败，数据呈现提早或者不产出。
排查办法：
1）借助 Flink web-ui 提供的的反压性能查找具体的 operatorChain。
2）查问 Flink metric ‘inPoolUsage、outPoolUsage’ 来确定具体的反压算子。
2、配置 cp 失败告警
场景：cp 失败导致数据无奈真正落地，工作复原距离太长。
排查办法:
1）是否存在反压。
2）查看集群负载、IO、CPU、MEM 是否处于高负荷状态。
3、拆分实时工作日志
场景: Flink 实时工作运行工夫长之后导致日志占用磁盘大，另外一个大的日志文件不利于排查问题。
解决办法：
配置 log4j.log 的滚动参数，设置日志按日期或者大小滚动生产，并且限度保留的大小。
4、监控工作运行中 tm 日志
场景: 工作执行中产生的运行日志没有监控，比方网络抖动导致的链接失败等等。
解决办法:
批改 Flink 自带的 log4j jar 包中的代码，将异样日志重定向一份到 Kafka 或 ES 中，进行后续剖析，找到程序中可能存在的暗藏 bug。
5、脏数据管理
场景：因为数据源都是从 Kafka 过去的数据，可能存在数据类型谬误、字段名称谬误、字段阈值在 Flink 中超范围等。落库过程中，因为字段类型不匹配、阈值超范围等等状况。
解决办法：
在数据解析和数据落库等代码中，对 catch 中的数据进行收集。当异样数据达到肯定的量时，告警告诉。线下离线修改后果数据。
三、通过 Metrics 定位问题
1. 罕用内置 Metrics 介绍
端到端的延时(最大、均匀、百分位)：
flink_taskmanager_job_latency_source_id_operator_id_operator_subtask_index_latency
输出数据量：
flink_taskmanager_job_task_operator_numRecordsIn
flink_taskmanager_job_task_numBytesIn
输入数据量：
flink_taskmanager_job_task_operator_numRecordsOut
flink_taskmanager_job_task_numBytesOut
反压值：
flink_taskmanager_job_task_isBackPressured
工作 buffer：
inPoolUsage、outPoolUsage 等其余
2、flinkStreamSql 中罕用 metrics
业务提早：
flink_taskmanager_job_task_operator_dtEventDelay（单位 s）
数据自身的工夫和进入 flink 的以后工夫的差值。
各个输出源的脏数据：
flink_taskmanager_job_task_operator_dtDirtyData
从 Kafka 获取的数据解析失败视为脏数据。
各 Source 的数据输出 TPS：
flink_taskmanager_job_task_operator_dtNumRecordsInRate
Kafka 承受的记录数(未解析前)/s。
各 Source 的数据输出 RPS：
flink_taskmanager_job_task_operator_dtNumRecordsInResolveRate
Kafka 承受的记录数(未解析前)/s。
各 Source 的数据输出 BPS：
flink_taskmanager_job_task_operator_dtNumBytestInRate
Kafka 承受的字节数 /s。
Kafka 作为输出源的各个分区的提早数：
flink_taskmanager_job_task_operator_topic_partition_dtTopicPartitionLag
以后 Kafka10、Kafka11 有采集该指标。
各个输出源 RPS：
fink_taskmanager_job_task_operator_dtNumRecordsOutRate
写入的内部记录数 /s。
四、FlinkStreamSQL v1.11.1 介绍
1.DDL 建表语句和 FlinkStreamSql v1.10 之前版本保持一致。
2.DML 语句有两种不同的模式：
dtstack 模式：和之前的版本是统一的。
Flink 模式：和 Flink 原生的语法保持一致。
3. 次要区别点：和维表 join 形式不同。
4. 如何应用：在提交工作的时候加上 -planner dtstack/flink 即可。
本文作者：刘星（花名：吹雪），袋鼠云大数据开发工程师。
本文首发于：数栈研习社
咱们在 github 上有一个 flinkx 的开源我的项目，欢送大家来探讨交换~
对于这个内容的视频，咱们还上传到了 b 站，欢送大家观看
https://www.bilibili.com/vide…
