原文：Evolution of the Netflix Data Pipeline
譯者：杰微刊兼職翻譯王強
Netflix在2015年12月上線了新一代數(shù)據(jù)管道"Keystone"。這篇文章將介紹Netflix的數(shù)據(jù)管道幾年來的發(fā)展演變寄症，也是關(guān)于新一代Keystone數(shù)據(jù)管道的一系列文章的第一篇幸冻。
Netflix是一家數(shù)據(jù)驅(qū)動型的公司楚午，通過數(shù)據(jù)分析探究出的信息做出了很多商業(yè)和產(chǎn)品決策吴旋。數(shù)據(jù)管道的職責是從云端層面收集、存儲骗卜、處理和遷移數(shù)據(jù)挺峡。Netflix幾乎所有的應(yīng)用都使用了數(shù)據(jù)管道。
來看看Netflix數(shù)據(jù)管道的一些指標：
1鼻由、每天處理約5000億事件暇榴，1.3PB數(shù)據(jù)
2、峰值狀態(tài)下每秒處理800萬事件蕉世、24GB數(shù)據(jù)
有數(shù)百種事件流程通過數(shù)據(jù)管道執(zhí)行蔼紧，例如：
1、視頻查閱操作
2狠轻、UI 操作
3奸例、錯誤記錄
4、性能事件
5向楼、故障申報和反饋事件
需要注意的是運營指標的監(jiān)測不通過上面這條數(shù)據(jù)管道查吊。Netflix有另一套監(jiān)測系統(tǒng)Atlas來處理運營數(shù)據(jù)谐区，Atlas也像Netflix的許多其他技術(shù)一樣是開源系統(tǒng)。
過去數(shù)年來逻卖，Netflix的數(shù)據(jù)管道在不斷增長的需求和技術(shù)進步推動下經(jīng)歷了多次重大轉(zhuǎn)變宋列。
V 1.0版本 "Chukwa"
早期的數(shù)據(jù)管道唯一的職責就是將事件集中上傳至Hadoop/Hive數(shù)據(jù)庫系統(tǒng)進行批量處理。如你所見评也，那時的架構(gòu)是相當簡單的：Chukwa收集事件炼杖，以Hadoop的S3序列格式存儲下來。接下來大數(shù)據(jù)平臺進一步處理這些S3文件仇参，以Parquet格式傳送給Hive嘹叫。整個端到端處理延遲最多可達10分鐘。對于每天或者每小時批量處理一次數(shù)據(jù)的頻率來說這個延遲并不算低效诈乒。
V 1.5版本罩扇，Chukwa與實時處理分支
隨著Kafka（開源消息系統(tǒng)）、Elasticsearch（開源搜索服務(wù)）過去幾年的進步怕磨，Netflix對數(shù)據(jù)實時分析的需求不斷增強喂饥。所謂"實時"，這里指的是處理延遲小于一分鐘肠鲫。
除了將事件上傳至S3/EMR,Chukwa還能將流量輸送到Kafka（這是實時分支的入口）员帮。1.5版本的Chukwa中，大約30％的事件被分發(fā)到了實時管道导饲。實時分支的核心是路由捞高，其負責將Kafka傳來的數(shù)據(jù)遞送到不同的數(shù)據(jù)池：Elasticsearch或者第二套Kafka系統(tǒng)。
過去兩年里Netflix的Elasticsearch的需求暴漲≡酰現(xiàn)在有大約150個節(jié)點處理約3500個實例硝岗，管理1.3PB的數(shù)據(jù)。絕大部分的數(shù)據(jù)都是通過數(shù)據(jù)管道注入的袋毙。
Chukwa將流量輸送到Kafka時型檀，既可以傳送原始數(shù)據(jù)流也能對數(shù)據(jù)做預(yù)過濾。有時Netflix需要將Chukwa寫入Kafka的數(shù)據(jù)流做進一步過濾听盖，所以路由這時要從一個Kafka的主題（topic）讀取數(shù)據(jù)輸出到另一個Kafka主題中胀溺。
數(shù)據(jù)提交到Kafka后，用戶就可以使用Mantis皆看、Spark或者定制應(yīng)用來進行實時數(shù)據(jù)處理了仓坞。Netflix文化的DNA是"自由與責任"。根據(jù)實際任務(wù)選擇合適的工具是用戶的事情腰吟。
Netflix的團隊擅長海量數(shù)據(jù)的遷移工作扯躺，因而他們將路由做成了可管理的服務(wù)。在運營路由服務(wù)的過程中團隊也獲得了很多經(jīng)驗教訓：
1、Kafka的上層用戶有時會在一段時間的穩(wěn)定運行后失去分區(qū)的權(quán)限录语，不再使用一些分區(qū)倍啥。結(jié)果團隊就得來解決問題。
2澎埠、系統(tǒng)代碼更新時虽缕，有時上層用戶會在rebalance的過程中卡在bad state。
3蒲稳、團隊將幾百項路由任務(wù)分組到幾十個節(jié)點處理氮趋，然而管理這些節(jié)點、分發(fā)任務(wù)的開銷負擔越來越大江耀。團隊需要一個更好的平臺來管理這些路由任務(wù)剩胁。
V2.0 Keystone數(shù)據(jù)管道（Kafka前端）
除了路由服務(wù)的這些問題外，Netflix還有一些其他方面的需求促成了數(shù)據(jù)管道的更新?lián)Q代：
1祥国、簡化架構(gòu)
2昵观、Kafka支持副本模式，提升了可靠性舌稀，但Chukwa不支持這一功能啊犬。
3、 Kafka有一個充滿活力壁查、前途光明的技術(shù)社區(qū)觉至。
新版本由三大主要部分組成：
1、數(shù)據(jù)入口 － 應(yīng)用有兩種方式載入數(shù)據(jù)睡腿。
①使用Java庫直接寫入Kafka语御。
②傳送到HTTP代理，后者將數(shù)據(jù)寫入Kafka席怪。
2应闯、 數(shù)據(jù)緩存 － Kafka負責以復(fù)制模式處理永久消息隊列。
這一部分也能為下游數(shù)據(jù)池提供緩沖何恶，減少斷流。
3嚼黔、數(shù)據(jù)路由 － 路由服務(wù)負責將數(shù)據(jù)從前端Kafka遷移到各個數(shù)據(jù)池：S3细层、Elasticsearch、第二套Kafka唬涧。
Netflix已經(jīng)在實戰(zhàn)狀態(tài)下運行Keystone數(shù)據(jù)管道幾個月時間了疫赎。Netflix仍在不斷改進Keystone，專注于QoS碎节、擴展性捧搞、可用性、可操作性和自助服務(wù)等指標。
