Netflix數(shù)據(jù)管道的演進(jìn)歷程

去年12月我們的Keystone數(shù)據(jù)管道正式投入使用，本文我們就來講講這些年Netflix數(shù)據(jù)管道的變化歷程。
　　數(shù)據(jù)是Netflix的中心，很多的商業(yè)決策和產(chǎn)品設(shè)計都是依據(jù)數(shù)據(jù)分析而做出的決定。在Netflix，數(shù)據(jù)管道的目的是對數(shù)據(jù)進(jìn)行收集歸納和處理，幾乎我們所有的應(yīng)用都會用到數(shù)據(jù)管道。下面我們先來看看有關(guān)Netflix數(shù)據(jù)管道的一些統(tǒng)計數(shù)據(jù)：
　　每天約5000億個事件，1.3PB的數(shù)據(jù)高峰時段約每秒800萬個事件，24GB數(shù)據(jù)
　　我們用另外的Atlas系統(tǒng)來管理運營相關(guān)的數(shù)據(jù)所以它并沒有出現(xiàn)在上面的列表中。
　　由于需求的變化和技術(shù)的進(jìn)步，過去幾年我們的數(shù)據(jù)管道發(fā)生了很大的改變。下面我們就來介紹一下。
　　V1.0 Chukwa數(shù)據(jù)管道
　　最初數(shù)據(jù)管道唯一的目的就是把事件信息上傳到Hadoop/Hive。如下圖中所示，整個架構(gòu)是比較簡單的。Chukwa收集事件信息并將sequencefile寫入亞馬遜S3，之后大數(shù)據(jù)平臺部門會進(jìn)一步處理并寫入Hive。從事件發(fā)生到以Parquet格式寫入Hive整個過程不超過十分鐘，對于每小時甚至每天才運行一次的batch job來說已經(jīng)足夠了。
　　
　　V1.5 能夠進(jìn)行實時處理的Chukwa數(shù)據(jù)管道
　　隨著Kafka和Elasticsearch等技術(shù)的發(fā)展，公司內(nèi)部對于實時分析的需求愈加強烈，我們必須保證處理所需時間在一分鐘之內(nèi)。
　　
　　除了將數(shù)據(jù)寫入S3，Chukwa還可以將數(shù)據(jù)發(fā)送到Kafka，新的實時分支（虛線框住的部分）處理的事件大約占到總事件的30%。處于實時處理分支中心位置的是事件路由模塊，它負(fù)責(zé)將數(shù)據(jù)從Kafka傳遞到Elasticsearch和下一級Kafka（進(jìn)行數(shù)據(jù)的篩選）。終端用戶可以自由選擇趁手的工具進(jìn)行分析，比如Mantis、Spark或其他定制工具。
　　Elasticsearch在Netflix的應(yīng)用過去兩年經(jīng)歷了爆炸式的發(fā)展，現(xiàn)在共有約150個集群和約3500個節(jié)點，總數(shù)據(jù)量約1.3PB，而這其中大部分?jǐn)?shù)據(jù)都是通過我們的數(shù)據(jù)管道采集處理的。
　　數(shù)據(jù)路由的部分是由我所在的小組管理的，下面是一些我們碰到過的問題：
　　Kafka high level consumer會喪失消息分區(qū)的所有權(quán)并停止讀取一些分區(qū)，唯一的解決辦法是重啟。有時部署代碼之后high level consumer在rebalance時會出錯。我們有幾十個集群用于事件路由，運營上的開銷正持續(xù)增長，所以對于路由job的管理還要想個更好的辦法。