Prism：來自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說。

(責任編輯：呂光)