一、实时开发常见问题
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…