Open bjkonglu opened 6 years ago
在使用structured streaming计算实时报表时，应用运行一段时间后会出现有Executor因为频繁GC导致进程挂掉的问题如下图所示：
Executor进程主要的功能是接收从Driver端分发的task，然后通过线程池去执行这些tasks。而这些task要去数据源拉取数据并使用用户定义的逻辑处理这些数据。当Executor进程出现频繁GC时，我怀疑是每个task处理的数据过大。
所以，针对这种情况的处理方案就是增加数据源的分区数，从而减小每个task要处理的数据，来减少GC的可能性。
如果是业务逻辑里面出现一个或多个group的数据过多，也就是数据倾斜，导致Executor进程出现频繁GC。
这种情况的处理方案就是增加shuffle的task数量，例如增加参数spark.sql.shuffle.partitions值；如果调大shuffle的task无法解决问题，说明数据倾斜很严重，某个group的数据远远大于其他group，需要在业务逻辑上进行处理，预先针对较大的group做单独处理。
场景
在使用structured streaming计算实时报表时，应用运行一段时间后会出现有Executor因为频繁GC导致进程挂掉的问题如下图所示：
分析
情况一
Executor进程主要的功能是接收从Driver端分发的task，然后通过线程池去执行这些tasks。而这些task要去数据源拉取数据并使用用户定义的逻辑处理这些数据。当Executor进程出现频繁GC时，我怀疑是每个task处理的数据过大。
所以，针对这种情况的处理方案就是增加数据源的分区数，从而减小每个task要处理的数据，来减少GC的可能性。
情况二
如果是业务逻辑里面出现一个或多个group的数据过多，也就是数据倾斜，导致Executor进程出现频繁GC。
这种情况的处理方案就是增加shuffle的task数量，例如增加参数spark.sql.shuffle.partitions值；如果调大shuffle的task无法解决问题，说明数据倾斜很严重，某个group的数据远远大于其他group，需要在业务逻辑上进行处理，预先针对较大的group做单独处理。