讀《百度基礎架構技術發展之路》有感

這篇文章主要介紹SDF的研發過程，包含問題的提出，解決方式，以及部署在實際系統過程當中遇到的問題。SDF的論文發表在ASPLOS 2014會議上。首先問題來自於實際工業環境：隨着數據中心將成爲承載互聯網用戶存儲和計算的主要戰場，怎樣設計和改進體系結構以知足大規模系統對性能。成本，功耗以及可擴展性的要求成爲新的挑戰。可以看到的是百度的ARM雲server方案攻克了存儲的成本和功耗問題，而SDF架構則幅度提高了性能的問題（固然也會減小成本和功耗）。

SDF的提出是爲了應對固態盤的諸多缺陷：當中包含帶寬利用率低，空間利用率低以及性能的不可預測性。

硬件上的問題需要經過軟件來屏蔽以向上層提供性能良好。執行穩定的服務接口。SDF的幾個features是：

• 軟件管理數據佈局（layout），用算法實現更高程度的並行。
• 扁平文件系統和I/O stack，分別解決可擴展性和延遲性問題。

• 考慮SSD在存儲時的硬件特徵，讀寫塊設置儘可能對硬件友好。
• 相似於hadoop的副本機制。消除了數據存儲時的校驗操做。

讓人感到吃驚的是百度內部的開發速度之快，以前聽賴春波前輩介紹百度ARM雲存儲server的整體設計和開發過程，就對百度內部雷厲風行，風馳電掣的開發效率印象深入。

相同這篇文章也能間接的讓人感覺到這樣的氣場。比方一個入職兩年的硬件project師和實習生在半年內完畢了1萬行的verilog代碼+3000行的C語言代碼；一個project師用半年的時間將包括100多萬行代碼的基礎庫和存儲系統代碼從x86-64架構移植到ARM-32位架構上的移植並完畢測試；高效率的系統原型到上線過程：從20臺到100臺再到500臺再到1000臺的迅速擴展。相信他們必定是有很充足的工做熱情才幹完畢這樣在工做量和工做難度都頗有挑戰的任務。

這也讓我懷念起在三年前作本科畢業設計時，和張胤同窗一塊兒用verilog編寫了1萬3千多行實現了一個六級流水、支持函數跳轉、支持中斷操做、支持分支預測的全功能MIPS處理器，用C#編寫了1萬多行的彙編器。本身定義了一套編程語言規範和彙編指令，而後在此基礎上又編寫了3000多行的彙編代碼（包含貪吃蛇遊戲，彈球遊戲等等）玩遍了開發箱上的所有外設（鍵盤，彩色觸屏，LED點陣等等）。

驅動這些外設的驅動程序也是用verilog編寫的。

那段時光真的很充實。至少現在看來可以在作過的最讓本身感動和自豪的事情中排名第二了。

讀博士以後，發現本身愈來愈懶散了，以前的那種衝勁慢慢的消退，這太可怕了！還有兩年就要畢業了，在這兩年裏必定要抓緊時間，學習一切讓本身興奮的知識，讓本身high起來充實起來。哎，說道工做激情和效率就扯遠了，接着說百度的基礎技術的指導原則---全棧式自主研發。詳細這樣作的緣由，文中給出了這麼幾點：

• 業務發展速度快。基礎架構要支撐新的業務，只依賴於開源社區是達不到的。

• 只在開源方案上修修補補，喪失自主研發大系統的能力
• 全棧式自底而上的研發作到軟件和硬件的協同設計，從而達到系統的最優.

技術方面，百度確實是一個使人欽佩的企業，只是感受其搜索的準確性上還有很是大的缺點，而且準確率彷佛在下滑。不知道是否是因爲融入了「深度學習」之類的新興技術。比方我要搜索《百度基礎架構技術發展之路》這篇文章的pdf版，在百度搜索框中輸入「百度基礎架構技術發展之路 pdf」。依據首頁呈現的內容來看，結果並不是很是讓人期待。該文章pdf的連接位於：http://www.ccf.org.cn/resources/1190201776262/2014/07/14/7.pdf