去年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的管理還要想個更好的辦法。
v2.0 keystone資料管道
我們決心對v1.5的資料管道進行調整是基于下面三個方面的考量。
簡化架構。
提升系統可靠性(chukwa不支援備援)。
kafka社群較活躍後勁足。
架構中一共有三部分主要的子產品：
資料收集-有兩種方式。
直接寫入kafka。
通過http代理寫入kafka。
資料緩存-使用kafka來實作持久化消息隊列。
資料路由-與v1.5中作用相同。
keystone資料管道已經在生産環境中平穩運作了幾個月，不過我們還在進行品質、擴充性、可用性和自動化方面的提升。
原文釋出時間為：2016-03-15
本文來自雲栖社群合作夥伴“大資料文摘”，了解相關資訊可以關注“bigdatadigest”微信公衆号