数据治理 - [04] 任务并发数如何设置？

题记部分

在大数据开发中，并发数的设置是一个至关重要且常见的性能调优点。设置得当，可以充分利用集群资源，缩短任务运行时间；设置不当，则可能导致资源浪费、任务拥堵甚至系统崩溃。最优并发数取决于任务类型、数据量、集群资源和业务要求等多个因素。

 

001 || 核心目标与原则

设置并发数的核心目标：在保证集群稳定性和任务成功率的前提下，用尽可能少的资源，在尽可能短的时间内完成计算。

两个关键原则：

1.最大化资源利用率：让CPU、内存、磁盘IO、网络IO等关键资源尽可能饱和，但不要过载（例如CPU利用率保持在70%—80%是健康的，100%则可能引发问题）。

2.避免不必要的开销：并发数并非越高越好。过高的并发会带来大量的任务调度、序列化、网络传输、上下文切换开销，反而可能降低整体效率。

 

 

002 || 关键考虑因素

1.任务类型（Task Type）

CPU密集型：任务逻辑复杂，计算量大（如机器学习模型训练、复杂数值计算）。并发数主要受限于CPU核心数。

通常建议：并发数 ≈ CPU总核心数 或 CPU总核心数 * (1 + 超线程系数)。

IO密集型：任务需要大量读写磁盘、网络传输（如数据导入导出、ETL清洗、Shuffle操作）。这类任务CPU等待时间长，可以设置较高的并发数。通常建议：并发数 >> CPU核心数，具体数值需要看磁盘IOPS和网络带宽的瓶颈。

Memory密集型：任务需要大量内存（如处理大宽表、缓存全量数据）。并发数主要受限于总内存。必须确保单个任务内存 * 并发数 < 集群可用内存，并预留一部分给系统和其他服务。

 

2.数据规模（Data Scale）

数据量：大数据量的任务通常需要更高的并发来并行处理。一个常见的启发式方法是根据输入数据的总大小来初步估算。

数据分布：数据是否倾斜？如果存在严重的数据倾斜，盲目增加并发数对热点数据无效，反而会加剧倾斜问题。应先处理数据倾斜。

 

3.集群资源（Cluster Resources）

这是最硬性的约束。

总CPU核心数：集群总vcores

总内存：集群总内存（YARN NodeManager 或Kubernetes Worker的内存）

可用资源：扣除掉其他运行中任务和系统服务占用的资源后，还剩多少？

外部系统瓶颈：你的任务是否读写HDFS、Hive、HBase、Kafka、MySQL等？这些外部系统的连接数、吞吐量也可能称为瓶颈。

 

4.框架与引擎特性（Framework & Engine）

不同的大数据引擎有其特定的资源模型和参数。

Spark

核心概念：executors（执行器容器），cores per executor（每个执行器的CPU核数），memory per executor（每个执行器的内存）。

并发数主要由num-executors * executor-cores决定。

推荐配置：通常建议executors-cores设置为3-5个，以平衡并行度和GC开销。然后根据总资源计算num-executors。

 

Flink

核心概念：parallelism（并行度），task slots（任务槽）。

并发数直接由parallelism控制。

Flink的Slot是资源隔离单位，一个TaskManager（类似于YARN的NodeManager）有多个Slot。

 

Hive on Tez/Spark

类似Spark，通过tez.grouping.max-size，tez.grouping.min-size等参数控制输入切片的大小，从而间接决定并发数。

 

 

003 || 标题