夜深了，，，先说一声，Spark 2.3.3 release了！再言归主题，今夜，讲几个码农调Spark的故事。。。
Apache Spark在几乎全球大大小小各种企业都有她自己的cluster，或大或小。。。各位资深用户都是身带无数勋章的猛士！Spark 应用的长期稳定运行是各位资深Spark专家的拿手绝技。也许都有这样那样的调试经历。这里分享一个大荷兰的小创业公司channable的战地报道【A War Story】：Debugging a long-running Apache Spark application: A War Story https://tech.channable.com/posts/2018-04-10-debugging-a-long-running-apache-spark-application.html
channable在创业初期，2014年就开始使用spark了。当时的版本还是1.0。每天处理上亿条产品数据。高度并行处理+动态字节码生成【codegen】是他们提升性能的方式。他们是通过Broadcast Variable来广播这种定制的动态生成的字节码给每个Spark worker，而这些字节码又可以在worker端的JIT编译器进一步优化成机器码。【注意，在异构cluster环境下，如果Java代码里有平台依赖的数值，driver端产生的字节码不一定可以正确在worker端运行，可能会产生各种问题】这种用法会产生大量并发的小job。有时候，整个Spark application大幅度地变慢，无法完成up time的指标。究其原因，某一两个spark job奇慢无比，可又不是因为data skew。。。神秘莫测。。。于是乎，万能的程序员出现了。。。
问题的解决过程就像一部侦探小说，如何监控？如何分析？这里就不剧透了，大家自己点开原文慢慢读。。。最终，问题被完美解决。方案仅仅需要调两个参数："spark.cleaner.referenceTracking.blocking" 设成 "false"和"spark.cleaner.periodicGC.interval"设成"3min"。
