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