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