夜深了，菊值，外驱，先說一聲，Spark 2.3.3 release了腻窒！再言歸主題昵宇，今夜，講幾個(gè)碼農(nóng)調(diào)Spark的故事儿子。瓦哎。。
Apache Spark在幾乎全球大大小小各種企業(yè)都有她自己的cluster柔逼，或大或小蒋譬。。卒落。各位資深用戶都是身帶無數(shù)勛章的猛士羡铲！Spark 應(yīng)用的長期穩(wěn)定運(yùn)行是各位資深Spark專家的拿手絕技蜂桶。也許都有這樣那樣的調(diào)試經(jīng)歷儡毕。這里分享一個(gè)大荷蘭的小創(chuàng)業(yè)公司channable的戰(zhàn)地報(bào)道【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在創(chuàng)業(yè)初期，2014年就開始使用spark了。當(dāng)時(shí)的版本還是1.0腰湾。每天處理上億條產(chǎn)品數(shù)據(jù)雷恃。高度并行處理+動(dòng)態(tài)字節(jié)碼生成【codegen】是他們提升性能的方式。他們是通過Broadcast Variable來廣播這種定制的動(dòng)態(tài)生成的字節(jié)碼給每個(gè)Spark worker费坊，而這些字節(jié)碼又可以在worker端的JIT編譯器進(jìn)一步優(yōu)化成機(jī)器碼倒槐。【注意附井，在異構(gòu)cluster環(huán)境下讨越，如果Java代碼里有平臺(tái)依賴的數(shù)值，driver端產(chǎn)生的字節(jié)碼不一定可以正確在worker端運(yùn)行永毅，可能會(huì)產(chǎn)生各種問題】這種用法會(huì)產(chǎn)生大量并發(fā)的小job把跨。有時(shí)候，整個(gè)Spark application大幅度地變慢沼死，無法完成up time的指標(biāo)着逐。究其原因，某一兩個(gè)spark job奇慢無比意蛀，可又不是因?yàn)閐ata skew耸别。。县钥。神秘莫測秀姐。。若贮。于是乎囊扳，萬能的程序員出現(xiàn)了。兜看。锥咸。
問題的解決過程就像一部偵探小說，如何監(jiān)控细移？如何分析搏予？這里就不劇透了，大家自己點(diǎn)開原文慢慢讀弧轧。雪侥。。最終精绎，問題被完美解決速缨。方案僅僅需要調(diào)兩個(gè)參數(shù)："spark.cleaner.referenceTracking.blocking" 設(shè)成 "false"和"spark.cleaner.periodicGC.interval"設(shè)成"3min"。
