2015 年 12 月，Netflix 新的數據流水線 Keystone 上線。本文將介紹近年來 Netflix 數據流水線的演進。這是介紹新的 Keystone 數據流水線系列文章的第一篇。

Netflix 是一家數據驅動的公司，很多業務和產品決策均基于數據分析作出。數據流水線的作用是在云上收集、聚合、處理和移動數據。Netflix 的幾乎每一款應用都會用到該數據流水線。

先來看 Netflix 數據流水線的一些數據：

每天 5000 億事件， 1.3PB 數據 峰值時間每秒處理 800 萬事件，24GB 數據

有數百種事件會通過該流水線，如：

查看視頻活動 UI活動 錯誤日志 性能事件 問題定位和診斷事件

這里需要注意的是，運維相關指標不通過該流水線處理，而是有一個獨立的系統—— Atlas，和 Netflix 的其他很多技術一樣，該系統也開源了。

在過去這些年，因為需求的變化和技術的發展，Netflix 的數據流水線有幾次大的變化。

V1.0 Chukwa 流水線

原始的數據流水線，唯一目的就是聚合事件，并將其上傳到 Hadoop/Hive 進行批處理。從下圖中也可以看出，架構相當簡單。Chukwa 收集數據，并以 Hadoop 順序文件格式將它們寫入到 S3 中。大數據平臺團隊進一步處理 S3 文件，然后以 Parquet 格式寫入到 Hive 中。從一端到另一端的延遲高達 10 分鐘。不過對于通常以天或小時的頻率掃描數據的批處理作業而言，也足夠了。

　　V1.5 帶有實時分支的 Chukwa 流水線

隨著 Kafka 和 Elasticsearch 的出現，Netflix 對實時分析的需求也不斷增長。這里的“實時”指的是延遲小于 1 分鐘。

除了將事件上傳到 S3/EMR，Chukwa 還能將流量發到 Kafka（實時分支的前端）。在 V1.5 中，大約有 30% 的事件會進入實時流水線。實時分支的核心是 Router。它負責將數據從 Kafka 路由到不同的地方，如 Elasticsearch 或次級 Kafka。

過去兩年，Elasticsearch 在 Netflix 的應用增長迅速。現在有 150 個集群，總計 3500 個實例，上面有 1.3PB 數據。絕大部分數據都是通過該數據流水線進來的。

在 Chukwa 將流量發到 Kafka 時，既可以是完整的流，也可以是過濾之后的。有時還需要進一步過濾從 Chukwa 寫到 Kafka 的流，這就是引入 Router 的目的所在——可以消耗一個 Kafka 主題，并生成一個不同的Kafka 主題。

在數據到了 Kafka 之后，用戶可以使用 Mantis 、 Spark 或定制的應用來做實時的流處理。“自由與責任”（Freedom and Responsibility）是 Netflix 文化的基因。讓用戶選擇合適的工具來處理手頭的任務。

因為研發團隊擅長處理數據的大規模遷移，所以將 Router 設計成了一個托管服務。在運維路由服務的過程中，他們也得到幾點教訓：

Kafka 高層消費者可能會丟失分區（partition）所有權，在穩定運行一段時間后，不再處理某些分區。處理需要干預。 當推出新代碼時，有時高層的消費者會在重新平衡過程中陷入錯誤狀態。 將路由作業分組，放到一系列集群上，不過管理這些作業和集群的成本持續增長。所以需要更好的平臺來管理路由作業。

V2.0 Keystone 流水線 (Kafka fronted)

除了上面提到的與路由相關的問題，還有其他幾點考慮：

簡化架構 Kafka 實現復制，可以提高系統的可靠性，而 Chukwa 不支持復制。 Kafka 有一個非常活躍、生機勃勃的社區。

　　有 3 個主要組件：

數據獲取——有兩種方式：使用 Java 庫，直接寫入 Kafka；或者　　
發送給 HTTP 代理，然后由代理寫入 Kafka。 數據緩沖——Kafka 作為復制的持久消息隊列。 數據路由——路由服務負責將數據從前端的Kafka 移到 S3 、 Elasticsearch 和次級 Kafka。

過去幾個月，Keystone 已經應用于生產中。目前開發團隊仍然在改進 Keystone，著重于QoS、伸縮性、可用性、可運維性和自服務等方面。