來自Facebook的真正的大數據項目

如今隨便哪個網站都可能需要處理數量巨大的在線數據,而Facebook早在五年前就已經在處理這個問題了。Facebook技術牛人Jay Parikh說現在這些網站處理大數據比他們當年容易多了。

這是因爲過去幾年中許多網絡公司(包括Facebook)都投入了很多精力去開發能夠在上萬臺服務器上分析處理線上數據的軟件平臺。當這些處理“大數據”的軟件完成之後,這些公司將成果公開了,任何感興趣的人都可以使用。

Facebook與yahoo一樣是開發推廣hadoop的急先鋒。Hadoop是一款很厲害的軟件平臺,用來處理和分析現代網絡產生的海量數據。Yahoo一開始開源這款軟件的時候是用作搭建自己搜索引擎所需的索引信息的,但是別的公司很快就將它用於自己的線上數據分析中,並且爲了達到這個目的不斷的增強完善Hadoop。

這些努力的結果是Hadoop平臺可以處理超過100PB(即十億GB)的數據。“五年前當我們開始用這些技術的時候,(這個平臺)在計算的類型和速度上都還有很多的侷限性。在開源社區的努力下,這些侷限性和障礙都被解決了,所以人們可以比我們當年更快的完成任務。”Parikh說。他現在管理着Facebook運行所需的數量巨大的硬件和軟件架構。

但是現在的Facebook所面臨的數據量比過去還要大多了,現有的平臺像Hadoop處理這樣大的數據還是有很多侷限性需要解決。在本週Facebook門羅園區總部的一個有記者參與的報告中,Parikh透露公司已經開發了兩個比Hadoop伸縮性更好的新平臺,而且Facebook打算將兩個平臺都開源出來。

第一個平臺名字叫做Corona,它允許你在許多Hadoop服務器上運行大量的任務,不需要擔心整個集羣(被單個任務搞)崩潰。另外一個更有吸引力,叫做Prism,能夠運行一個超大的、能夠將全球數據中心都連起來的Hadoop集羣。


Parikh說這個系統能夠“讓數據按照我們的要求任意移動,不管是俄勒岡州的普賴恩維爾、北卡州的Forest市、還是瑞典。


 

Hadoop建立在十年前Google的兩篇描述大規模軟件平臺(原理)的論文之上,Google用這兩篇論文中的技術構造了GFS和MapReduce平臺。GFS是谷歌文件系統的簡稱,能夠將數據分佈存儲在上千臺服務器上;MapReduce讓你利用所有服務器的計算資源進行計算得到想要的結果。Hadoop的工作原理與之類似,對應GFS和MapReduce的叫做HDFS和Hadoop MapReduce。


 

這兩個Hadoop平臺已經Yahoo和Facebook等公司用了幾年,但是它們不完美,尤其是在Facebook的用戶數超過9億之後這兩個系統的問題越來越明顯。最引人注目的問題就是“單點錯誤”特性,即如果管理集羣的主服務器掛掉了,整個集羣就(至少暫時的)掛掉了。

最近幾個月,Facebook開發了一種叫做AvatarNode的技術來避免HDFS平臺的單點錯誤,而Hadoop開源社區實現了一個類似的HA NameNode方案,提高了可用性。但是MapReduce還是存在單點失效的問題。現在Facebook通過Corona解決了這個問題。

傳統上MapReduc使用一個單獨的“任務跟蹤器”來管理服務器集羣中的任務,而Corona創建多個任務跟蹤器。Parikh說這幫助Facebook在同樣的MapReduce平臺上執行的任務數量大大增加,總體吞吐量提高了,從而更多的小組和產品可以在集羣上運行任務。

過去如果任務跟蹤器出現了問題,就會導致系統中所有的任務都死掉了,逼得你把所有東西都重啓一遍。只要有一個服務器故障了整個系統都會受到影響。現在系統中有了很多迷你任務跟蹤器,只負責各自的任務。

Tomer Shiran是硅谷創業公司MapR最早的一批員工,這家公司發行的Hadoop版本中包含了類似的功能,他同時指出目前開源版本的Hadoop中還沒有類似的多任務跟蹤器實現。他見過某個版本的Corona,覺得在這個平臺上MapReduce任務的啓動速度也快了很多。

關於Corona平臺Jay Parikh說的很少,但是顯然這個系統已經在Facebook內部使用了——而且確實非常需要。Parikh說Facebook運行着世界上最大的Hadoop集羣,包含超過100PB的數據,半個小時就能處理105TB的數據。

但是這個集羣就快滿足不了Facebook了。9億用戶不斷的更新狀態,傳照片、視頻,寫評論——數據增長的速度你懂的。這就是Parikh跟同事構建跨數據中心的集羣Prism的原因。

傳統上由於數據中心之間的網絡不夠快,Hadoop計算一般不在地理上分離的數據中心之間運行。“Hadoop的一大缺陷就是所有的服務器都必須緊挨着,”他說“系統的耦合性非常高,如果服務器之間的(數據傳送)延遲增加幾十微秒,整個系統就會慢到爆。”

有了Prism就不一樣了。簡而言之它的特長就是能夠根據需要在不同的網絡計算節點之間自動的複製和傳送數據。“這使得我們能夠建立多個分離的數據中心但是在系統中看到的還是一個系統,”他說。“我們可以根據成本、性能、技術因素來移動數據……我們已經不再侷限於單個數據中心的計算能力了。”

Prism讓人聯想到谷歌的Spanner平臺。關於Spanner的消息不多——谷歌在其基礎架構的設計實現上比較低調——但是在09年求點,谷歌公開描述這個系統爲“一個存儲和計算系統,利用了我們所有的數據中心(的磁盤和計算能力),根據資源的約束和使用模式自動的進行數據的複製和計算的重分佈。”

谷歌宣稱這個平臺提供“在任何服務器上自動分配資源的能力”,涵蓋了全球36個數據中心。

Parikh承認Prism跟Spanner類似,但是他也謹慎的指出對於Spanner他知道的不多。而且Prism可能在一個數據中心當掉的時候即時的將數據重新分佈(到別的中心中去)。

Tomer Shiran說這類平臺只在谷歌或Facebook內部使用,還沒有開放的實現。但是他也指出,目前也沒有多少公司需要這麼高級的東西,“還沒有公司(數據量)達到了谷歌處理的數據的量級“。

Facebook目前還沒有實際的部署Prism,Parikh也沒有給出明確的時間。但是他說到那時可能就會開源了。Corona系統也會開源。確實現在還沒有公司需要處理像谷歌和Facebook這麼多的線上數據,但是在未來可能會的。“他們需要面對下一波數據量級增長的挑戰,”Parikh說。

傳智播客收集整理,關注java培訓,提供java入門教程java程序設計教程java視頻教程下載

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章