本篇郑重承诺以下！
本篇涉及的调优方向在PB级的集群上测试有效。本篇涉及的调优方向均为本人亲自调试。本篇涉及的调优方向基于数亿级别数据于数亿级别大表关联。本篇涉及的调优方向对应的调度任务规模数千个。本篇涉及的调优方向基于一个几十人的大数据开发团队。Background
血淋淋的战场
数据倾斜真的加加随机数就解决了吗？
与分析师的对话
与ETL的对话
学会分析倾斜
Analyze语句
SparkSQL自适应分区
广播
CBO
ResourceDynamicAllocation
BackgroundSpark性能调优，这属于老生常谈了。因为百度一下，可以看到很多。我截取了几个搜索比较多的。
image-这是一篇年的帖子，现在已经年了，Spark已经发生了巨大升级，3.1.1版本都发布了。里面介绍大量的RDD相关、以及广播的优化。
image-04282336这么好用的广播join是不是到生产就无敌了吗？难道就是这么牛逼，参数一调然后就所有问题就解决了呢？
血淋淋的战场我可以告诉大家，No！看似简单无比但到生产上却是寸步难行。因为你可能会不定时遇见：
一个应用提交到YARN，SparkWebUI卡死，连任务执行得什么样都不知道了。大批量的作业在集群中调度，上千个作业作业还没有提交到YARN就已经全线瘫痪。为了调错，增加了日志的输出详细程度，却不曾想巨大的作业数量，几千行、内外嵌套几十层的物理执行计划树分分钟数GB的日志文件，一眼物理执行计划望不到边。决策部门分析人员一个SQL提交上来，弹性资源怎么也弹不动、公平调度再也不公平。日入TB级的数据量，运维忙得焦头烂额，磁盘可以扩、经费可以批，但机房不能随便扩。数据你敢删吗？一旦出现问题，即使你是外包也可以让你在行业内脱几层皮。当你想要把教程里面说的，加随机数，打散随机值，发现你根本连下手的地方都没有。因为数仓分层的上层，你会发现是一层噩梦，那里面的SQL会分分钟把你的脸打得稀烂。他们说大数据都是内网隔离，不需要做安全控制，提交SQL的业务人员一个SQL把你的生产数据Overwrite得无影无踪，你想甩锅给业务部门？你会发现作为一个开发，自己居然连说话的机会都没有。他们说公司有钱，资源无穷无尽。做核心业务分析的人员一个大SQL，数以百计的JSON字段解析，几十亿与几十亿的历史数据关联与回写，吃光吃尽所有集群资源，一个SQL卡掉整个集群。他们说公司的内存足够，就算倾斜也没事，能跑下来，结果发现一到生产，发现一个Task里面正默默地shuffle着几十亿上TB的数据。难道你要去问问运维：兄弟，能给我把机房的机器内存升级到10TB吗？...我有太多血的经验，没有我的