Spark源碼分析 – BlockManager

對于storage, 為何spark需要storage子產品？為了cache rdd 

spark的特點就是可以将rdd cache在memory或disk中，rdd是由partitions組成的，對應于block 

是以storage子產品，就是要實作rdd在memory和disk上的persistent功能

首先每個節點都有一個blockmanager, 其中有一個是driver(master), 其餘的都是slave 

master負責track所有的slave blockmanager的blockmanagerinfo, 而blockmanagerinfo中又track了該blockmanager管理的所有的block的blockstatus 

當slave上的block有任何變化的時候, 需要發送updateblockinfo事件來更新master上block資訊 

典型的中心化設計, master和slave之間的通信通過actor來進行, 當然對于block資料的傳輸, 由于資料量比較大, 是以使用connectionmanager(nio或netty) 

其中還有個blockmanagermaster,負責wrap blockmanagermasteractor, 比較confusing的是每個節點都會建立這個blockmanagermaster, 隻是在slave中不會真正建立blockmanagermasteractor, 而是ref, 不好的設計 

而且由于blockmanager被master和slave公用, 是以提供了兩者大部分接口, 而對于master部分都是直接wrap blockmanagermaster, 而對于slave中的資料讀寫等就直接實作了, 設計不統一

總之, storage這個子產品, 設計比較随意, 不是很合理, 也展現在一些細小的命名上, 給分析和了解帶來了一些困難.

在sparkenv的初始化中, 建立blockmanagermaster和blockmanager

blockmanagerid作為blockmanager唯一辨別, 是以希望一個blockmanager隻建立一個blockmanagerid 對象 

典型singleton的場景 

在scala裡面實作singleton比較晦澀, 這裡是個典型的例子 

将所有的構造函數設為private, 然後利用伴生對象的來建立對象執行個體

blockmanager是被master和slave公用的, 但對于master的邏輯都已經wrap在blockmanagermaster中了 

是以這裡主要分析一些slave相關的接口邏輯, reportblockstatus, get, put 

2.1 blockinfo

blockinfo關鍵是對block做了通路互斥, 通路block前需要, 先waitforready 

是以每個block, 都需要生成一個blockinfo來經行互斥管理 

這個為啥叫blockinfo? 

blockmanagermasteractor中updateblockinfo事件更新的不是這個blockinfo, 而是blockmanagerinfo.blockstatus, 不太合理!

2.2 reportblockstatus

2.3 get

2.3 put

2.3 dropfrommemory