1. 程式人生 > >許鵬-Spark原始碼閱讀經驗和C++經典書籍資料推薦

許鵬-Spark原始碼閱讀經驗和C++經典書籍資料推薦

CSDN:多年C和C++專案開發及管理,有什麼經驗可以分享給這個領域的工作者?在程式設計師修養方面,他們又應該注意什麼,多學些什麼,多看些什麼?

許鵬:儘管從事C和C++開發多年,我還是不敢說自己非常精通。有的只是一點點的感悟和體會,如果是進行Linux平臺下的C語言開發,最好還是就下面幾個問題多做一些試驗,多讀一些相關的書。

1. 程式的執行和載入,推薦程式設計師的自我修養一書。

2. 記憶體分配,推薦閱讀Ptmalloc原始碼分析,無論是C還是C++程式設計師,這一部分是最容易踩雷的,多讀一點基礎的東西,會在解決實際問題的時候,不至於手足無措。以這些為基礎,再結合Valgrind或Purify,相信效果會更好。

3. 多讀一點C和C++開發的成功產品,如Apache Http Server和Nginx,這樣就容易搞清楚在設計一個系統的時候需要有哪些關注點。 

  • 是單程序還是多程序,是單程序多執行緒還是多程序單執行緒
  • 程序間通訊採用什麼方式
  • 訊息的encoding/decoding以及message passing,每次都要自己寫一次,不累嗎,有沒有好的開源實現,如Protobuffer、Thrift
  • 對於一個Network Server來說,基本構架大體上還是相同的,acceptor→dispatcher→worker

4. 《深入理解計算機系統》真的是一本非常不錯的書,為什麼要這麼說,軟體的設計還是要以物理裝置支援的特性為基礎的,這本書讓我們在CPU的級別來進一步思考程式設計。

閱讀原始碼的經驗

CSDN:大量開源專案使用和學習經驗,您對開源運動怎麼看?如何才能更好的學習一個開源專案?開源專案使用時又該注意些什麼?

許鵬: 開源專案離不開大家的廣泛參與和支援,要讓一個開源專案取得成功,有多個方面的因素。

  • 產品本身的創新功能
  • 在實際專案中的應用和推廣,業界大佬企業的積極參與
  • 教育培訓市場的積極跟進,也是一個開源專案最終能夠長久生存下來的必備因素

CSDN:能否分享一些您對當下大資料的看法?

許鵬: 大資料要解決的兩大基本問題是“資料儲存”和“資料分析”,在資料儲存領域,開源實現方面似乎大家都已經首肯HDFS的方式,不再懷疑。

而在資料分析的計算框架方面,目前還有大量的競爭或博弈出現。Spark就是一例,分析領域除了基於傳統關係型資料庫的分析方式,還有圖計算相關和機器學習為代表的資料探勘。顯然機器學習是一個大熱門,這一方面個人所知甚少,不敢胡說八道,但門檻似乎很高,數學底子一定要好,決不是簡簡單單的呼叫幾個API就完事了的。

雲端計算是大資料的支撐,雖然脫胎於虛擬化,不乏商業宣傳的味道,但是大量機器的安裝部署,如果全部使用物理機一臺臺去裝,肯定會讓人發瘋,雲端計算讓大規模部署和產品遷移變的更為簡單。

CSDN:對於閱讀原始碼您有著豐富的經驗,對想閱讀原始碼又不知道如何下手的同學可否做一些分享?

許鵬: 原始碼閱讀其實是一個逆向的工程,這期間必須會遇到種種問題。一般來說,我會遵循這樣一個思維正規化——Problem domain→model→architecture&implementation→improvement→best practice。

1. 首先搞清楚要分析的產品解決的問題是什麼,這個問題在哪個大的範疇裡,也就是要搞清楚problem domain。一個著名的開源產品必定在Wikipedia上有相應的條目,所以一開始去看wikipedia是破題的一種極好方式。

2. 清楚要分析產品的大體框架和關鍵性的概念,也就是理解清楚architecture和key concept。

3. 將分析的產品實實在在的執行起來,我一般選擇debian或archlinux作為工作平臺,它們提供了豐富的軟體包,可以很快的將東西安裝並執行。熟悉Linux本身對於開源專案的原始碼閱讀還是大有裨益的。

4. 修改日誌級別,得到豐富的日誌資訊。有了這個為基礎,再來開始真正的原始碼閱讀和分析。

5. 原始碼分析的時候,要始終問這幾個問題。

  • 程序以及執行緒的啟動順序
  • 搞清楚呼叫關係call flow
  • 這一部分程式碼是在同一個程序中麼,同一個執行緒中麼,執行在同一臺機器中麼
  • 每一個執行緒都要問清楚,什麼時候啟動的,什麼時候停止的
  • 訊息傳遞的路徑,針對每一個函式,搞清楚,input是誰傳給我的,output要傳給誰,由哪個來傳
  • 搞清楚上述的問題之後,就將最開始提到的對architecture的瞭解做到具體而微了。有了這個基礎之後,再繼續往下問
  • 當前實現的效能如何,比如i/o, cpu, network 這個需要做相應的測試方面的試驗
  • 當前的解決方案還有優化空間嗎,比如針對spark中的scheduling問題,就有sparrow的優化機制提出

6. 碰到具體的問題一時解決不了怎麼辦

  • 用好google,用好stackoverflow
  • 將碰到的問題模型化,寫一些驗證性的程式碼,或者是寫一個小的demo來驗證,我在解決許多很妖的bug,也是採用類似的思路
  • 找到相應的使用者論壇,發帖虛心請教
  • 如果還是不行,就先擱一擱,去看能看懂的地方

7. 程式語言選擇

  • 原始碼閱讀中可能遇到的一個問題就是這個語言是新近出來的,我根本沒學過,我需要系統去掌握該語言之後,才能來看原始碼麼。我的看法是可以邊看邊學,在掌握語言的過程中,牢牢把握住這幾個問題
  • 基本語法:資料型別、控制語句、函式定義
  • 是否支援FP
  • 多型和繼承
  • 現代程式語言基本上都混合了面向過程,面向物件和函數語言程式設計的特點,即便是C++或新近的java8都如此。
  • Storm用Clojure來編寫,而Spark使用Scala,就語言的偏好來說,我更喜歡Clojure一些。 

稍微總結一下,我想原始碼分析心中要有兩幅大圖,將整體與區域性很好的結合起來思考

  • 一是太極圖,要有整體性的思維,要對architecture有掌握,對其在整個生態系統中的定位要清楚,東方式的思維強調整體性
  • 二是數學中常見的笛卡爾座標體系,將大的問題拆分之後一一研究,做到具體而微,西方式的思維強調個性