Facebook大数据技术架构的演进路线
??? Facebook早期的大數據技術架構是建立在Hadoop、HBase、Hive、Scribe等開源工具基礎上的。日志數據流從HTTP服務器產生,通過日志收集系統Scribe耗費秒級時間傳送到共享存儲NFS文件系統,然后通過小時級的Copier/Loader(即MapReduce作業)將數據文件上傳到Hadoop。數據摘要通過每天例行的流水作業產生,它是基于Hive的類SQL語言開發,結果會定期會更新到前端的Mysql服務器,以便通過OLTP工具產生報表。Hadoop集群節點有3000個,擴展性和容錯性方面的問題能夠很好地解決,但是早期系統的主要問題是整體的處理延遲較大,從日志產生起1~2天后才能得到最終的報表。
??? Facebook當前的大數據技術架構是在早期架構基礎上對數據傳輸通道和數據處理系統進行了優化,如圖所示,主要分為分布式日志系統Scribe、分布式存儲系統HDFS和HBase、分布式計算和分析系統(MapReduce、Puma和Hive)等。
其中,Scribe日志系統用于聚合來自大量HTTP服務器的日志數據。Thrift是Facebook提供的軟件框架,用于跨語言的服務開發,能夠在C 、Java、PHP 、Python和Ruby等語言之間實現無縫的支持。采用Thrift RPC來調用Scribe日志收集服務進行日志數據匯總。Scribe Policy是日志流量和模型管理節點,將元數據傳送給Scribe客戶端和Scribe HDFS,采集的日志數據存儲在Scribe HDFS。Facebook對早期系統優化后的數據通道稱為Data?Freeway,能夠處理峰值9GB/s的數據并且端到端的延遲在10s以內,支持超過2500種的日志種類。Data?Freeway主要包括4個組件,Scribe、Calligraphus、Continuous?Copier和PTail。Scribe用于客戶端,負責通過Thrift RPC發送數據;Calligraphus在中間層梳理數據并寫到HDFS,它提供了日志種類的管理,利用Zookeeper進行輔助;Continuous?Copier將文件從一個HDFS拷貝到另一個HDFS;PTail并行地tail多個HDFS上的目錄,并寫文件數據到標準輸出。在當前架構中,一部分數據處理仍然以批處理的方式通過MapReduce進行小時級的處理,存儲在中央的HDFS,每天通過Hive進行分析處理。另一部分接近實時的數據流則通過Puma來進行分鐘級的處理。Facebook對專門分析提供Peregrine(Hipal)工具、對周期性分析提供Nocron工具進行分析。
??? Facebook未來的大數據技術架構的雛形已經出來。首先開源的是可能替代Hadoop系統中MapReduce的Corona,類似于Yahoo提出的YARN。Corona最大的一個進步是其集群管理器做到了基于CPU、內存和其他作業處理的需求資源的管理,這可以使得Corona既可以處理MapReduce 作業,也可以處理非MapReduce 作業,使Hadoop集群的應用領域更加廣泛。二是Facebook最新的交互式大數據查詢系統Presto,類似于Cloudera的Impala和Hortonworks的Stinger,解決了Facebook迅速膨脹的海量數據倉庫快速查詢需求。據Facebook稱,使用Presto進行簡單的查詢只需要幾百毫秒,即使是非常復雜的查詢,也只需數分鐘便可完成,它在內存中運行,并且不會向磁盤寫入。第三是Wormhole流計算系統,類似于Twiitter的Storm和Yahoo的Storm-YARN。第四個重要項目是Prism,它能夠運行一個超大的、能夠將全球數據中心都連起來的Hadoop集群,可能在一個數據中心宕掉的時候即時的將數據重新分布,這是一個與Google的Spanner類似的項目。
??? Facebook的大數據技術架構演進路徑代表了大數據技術的發展路線,難能可貴的是,開源是Facebook一貫的路線,它和Yahoo等公司一起為大數據技術的發展作出了巨大貢獻。
?
本文內容節選自北京賽智時代信息技術咨詢有限公司(CIOManage咨詢)的《2013-2014年中國互聯網行業大數據應用年度研究報告》。
總結
以上是生活随笔為你收集整理的Facebook大数据技术架构的演进路线的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: HC-05蓝牙模块连接测试
- 下一篇: 友邦人寿发布非一线差异化发展策略,稳步加