目錄
前言
前面兩篇文章一直在講SparkContext初始化的內部邏輯,除此之外,它也對外提供一部分其他功能,我們挑選幾個主要的來簡要了解。SparkContext還有一個伴生對象,里面涉及到一些SparkContext創(chuàng)建的內部機制。
本文就是SparkContext概況的收尾。在它的背后,還有形形色色的更加底層的邏輯等著我們去探索。
SparkContext提供的其他功能
生成RDD
在文章#0中,我們提到了生成RDD的兩種方法,一是對內存中存在的數據執(zhí)行并行化(Parallelize)操作,二是從外部存儲中的數據源讀取。這兩類方法都在SparkContext中。以下是parallelize()方法的代碼。
代碼#4.1 - o.a.s.SparkContext.parallelize()方法
def parallelize[T: ClassTag](
seq: Seq[T],
numSlices: Int = defaultParallelism): RDD[T] = withScope {
assertNotStopped()
new ParallelCollectionRDD[T](this, seq, numSlices, Map[Int, Seq[String]]())
}
該方法生成的RDD類型為ParallelCollectionRDD。numSlices就是該RDD的分區(qū)數,默認值與TaskScheduler的Task并行度相同。這個方法非常簡單,因此在Spark入門教程中經常會用到它。
從外部數據源讀取并生成RDD的方法比較多,為了簡潔,我們只看代碼#0.1中出現的textFile()方法。
代碼#4.2 - o.a.s.SparkContext.textFile()與hadoopFile()方法
def textFile(
path: String,
minPartitions: Int = defaultMinPartitions): RDD[String] = withScope {
assertNotStopped()
hadoopFile(path, classOf[TextInputFormat], classOf[LongWritable], classOf[Text],
minPartitions).map(pair => pair._2.toString).setName(path)
}
def hadoopFile[K, V](
path: String,
inputFormatClass: Class[_ <: InputFormat[K, V]],
keyClass: Class[K],
valueClass: Class[V],
minPartitions: Int = defaultMinPartitions): RDD[(K, V)] = withScope {
assertNotStopped()
FileSystem.getLocal(hadoopConfiguration)
val confBroadcast = broadcast(new SerializableConfiguration(hadoopConfiguration))
val setInputPathsFunc = (jobConf: JobConf) => FileInputFormat.setInputPaths(jobConf, path)
new HadoopRDD(
this,
confBroadcast,
Some(setInputPathsFunc),
inputFormatClass,
keyClass,
valueClass,
minPartitions).setName(path)
}
可見,textFile()方法用TextInputFormat格式讀取HDFS上指定路徑的文件,生成HadoopRDD,再將其中的具體內容用map()算子提取出來。HadoopRDD是一個Pair RDD,它內部存儲的是二元組,如上面代碼中的(LongWritable, Text)二元組。
廣播變量
廣播變量是Spark兩種共享變量中的一種。所謂廣播,就是Driver直接向每個Worker節(jié)點發(fā)送同一份數據的只讀副本,而不像通常一樣通過Task來計算。廣播變量適合處理多節(jié)點跨Stage的共享數據,特別是輸入數據量較大的集合,可以提高效率。
下面是broadcast()方法的源碼。它在上文代碼#4.2中已經出現過,用來廣播序列化過的Hadoop配置信息。
代碼#4.3 - o.a.s.SparkContext.broadcast()方法
def broadcast[T: ClassTag](value: T): Broadcast[T] = {
assertNotStopped()
require(!classOf[RDD[_]].isAssignableFrom(classTag[T].runtimeClass),
"Can not directly broadcast RDDs; instead, call collect() and broadcast the result.")
val bc = env.broadcastManager.newBroadcast[T](value, isLocal)
val callSite = getCallSite
logInfo("Created broadcast " + bc.id + " from " + callSite.shortForm)
cleaner.foreach(_.registerBroadcastForCleanup(bc))
bc
}
廣播變量的產生依賴于Spark執(zhí)行環(huán)境里的廣播管理器BroadcastManager,因此在之后閱讀SparkEnv的源碼時,會詳細分析廣播的內部機制。
累加器
累加器與廣播變量一樣,也是Spark的共享變量。顧名思義,累加器就是一個能夠累積結果值的變量,最常見的用途是做計數。它在Driver端創(chuàng)建和讀取,Executor端(也就是各個Task)只能做累加操作。SparkContext已經提供了數值型累加器的創(chuàng)建方法,如長整型的LongAccumulator。
代碼#4.4 - o.a.s.SparkContext.longAccumulator()方法
def longAccumulator: LongAccumulator = {
val acc = new LongAccumulator
register(acc)
acc
}
def longAccumulator(name: String): LongAccumulator = {
val acc = new LongAccumulator
register(acc, name)
acc
}
所有累加器的基類都是AccumulatorV2抽象類,我們也可以自定義其他類型的累加器。特征AccumulatorParam則用于封裝累加器對應的數據類型及累加操作,在后面的文章中也會閱讀到與累加器相關的源碼。
運行Job
SparkContext提供了很多種runJob()方法的重載來運行一個Job,也就是觸發(fā)RDD動作算子的執(zhí)行。歸根結底,所有runJob()方法的重載都會調用如下所示的邏輯。
代碼#4.5 - o.a.s.SparkContext.runJob()方法
def runJob[T, U: ClassTag](
rdd: RDD[T],
func: (TaskContext, Iterator[T]) => U,
partitions: Seq[Int],
resultHandler: (Int, U) => Unit): Unit = {
if (stopped.get()) {
throw new IllegalStateException("SparkContext has been shutdown")
}
val callSite = getCallSite
val cleanedFunc = clean(func)
logInfo("Starting job: " + callSite.shortForm)
if (conf.getBoolean("spark.logLineage", false)) {
logInfo("RDD's recursive dependencies:\n" + rdd.toDebugString)
}
dagScheduler.runJob(rdd, cleanedFunc, partitions, callSite, resultHandler, localProperties.get)
progressBar.foreach(_.finishAll())
rdd.doCheckpoint()
}
可見,它最終調用了DAGScheduler.runJob()方法來運行Job。它會將需要計算的RDD及其分區(qū)列表傳入,在計算完成后,將結果傳回給resultHandler回調方法。在運行Job的同時,還會對RDD本身保存其檢查點。關于DAGScheduler的細節(jié),在涉及調度邏輯時會深入了解。
SparkContext伴生對象
前文代碼#2.11里的createTaskScheduler()方法就來自SparkContext伴生對象。除了它之外,伴生對象主要用來跟蹤并維護SparkContext的創(chuàng)建與激活。
伴生對象中的屬性
代碼#4.6 - SparkContext伴生對象中的屬性
private val SPARK_CONTEXT_CONSTRUCTOR_LOCK = new Object()
private val activeContext: AtomicReference[SparkContext] =
new AtomicReference[SparkContext](null)
private var contextBeingConstructed: Option[SparkContext] = None
這三個屬性都與SparkContext的創(chuàng)建過程相關。SPARK_CONTEXT_CONSTRUCTOR_LOCK是SparkContext構造過程中使用的鎖對象,用來保證線程安全性。activeContext用于保存當前活動的SparkContext的原子引用。contextBeingConstructed用于保存當前正在創(chuàng)建的SparkContext。
markPartiallyConstructed()方法
這個方法實際上在SparkContext主構造方法的開頭就被調用了,它將當前的SparkContext標記為正在創(chuàng)建。
代碼#4.7 - o.a.s.SparkContext.markPartiallyConstructed()方法
private[spark] def markPartiallyConstructed(
sc: SparkContext,
allowMultipleContexts: Boolean): Unit = {
SPARK_CONTEXT_CONSTRUCTOR_LOCK.synchronized {
assertNoOtherContextIsRunning(sc, allowMultipleContexts)
contextBeingConstructed = Some(sc)
}
}
可見,最終是調用了assertNoOtherContextIsRunning()方法。這是一個私有方法,它檢測當前是否有多個SparkContext實例在運行,并根據spark.driver.allowMultipleContexts參數的設置拋出異常或輸出警告。
setActiveContext()方法
與上面的方法相對,它是在SparkContext主構造方法的結尾處調用的,將當前的SparkContext標記為已激活。
代碼#4.8 - o.a.s.SparkContext.setActiveContext()方法
private[spark] def setActiveContext(
sc: SparkContext,
allowMultipleContexts: Boolean): Unit = {
SPARK_CONTEXT_CONSTRUCTOR_LOCK.synchronized {
assertNoOtherContextIsRunning(sc, allowMultipleContexts)
contextBeingConstructed = None
activeContext.set(sc)
}
getOrCreate()方法
該方法是除new SparkContext()之外,另一種更好的創(chuàng)建SparkContext的途徑。它會檢查當前有沒有已經激活的SparkContext,如果有則直接復用,沒有的話再創(chuàng)建。
代碼#4.9 - o.a.s.SparkContext.getOrCreate()方法
def getOrCreate(config: SparkConf): SparkContext = {
SPARK_CONTEXT_CONSTRUCTOR_LOCK.synchronized {
if (activeContext.get() == null) {
setActiveContext(new SparkContext(config), allowMultipleContexts = false)
} else {
if (config.getAll.nonEmpty) {
logWarning("Using an existing SparkContext; some configuration may not take effect.")
}
}
activeContext.get()
}
}
總結
本文對SparkContext初始化邏輯之外剩下的一些邏輯做了簡要介紹,包括SparkContext提供的其他功能,及其伴生對象中的一些細節(jié)。這樣,我們就對SparkContext有了相對全面的了解。
接下來,我們會選擇幾個SparkContext組件初始化邏輯中涉及到的重要組件,對它們的實現機制加以分析。下一篇仍然計劃從基礎開始講起,就是LiveListenerBus及以其為代表的事件總線。