大膽預測：重量級的數據應用，包括但不僅限于數據分析，數據挖掘，計算廣告等，將全部會轉換成實時數據處理架構。在電子化市場營銷，尤其當今信息技術快速發(fā)展的前提下，數據處理的快慢直接影響變現的質量。

?

愛好收集一些數據應用，今天在?InfoQ.com?上看到一篇好文，迫不及待要順著原文清理下自己的思路。原文如下：

?

Migrating Batch ETL to stream processing: A netflix case study with Kafka and Flink

https://www.infoq.com/articles/netflix-migrating-stream-processing?utm_campaign=rightbar_v2&utm_source=infoq&utm_medium=articles_link&utm_content=link_text

?

1 Batch ETL 與 Stream Processing 的區(qū)別: 在《DesignData-Intensive Applications》書中，Batch ETL 又可分為 Normal Batch ETL 和 Micro-Batch ETL, 即 傳統(tǒng)意義上耗時非常長的 ETL 以及 微批次的 ETL. 耗時長的 ETL 通常會有占有一段非業(yè)務時間來處理，比如夜晚的 0 點到 6 點，這段時間由于業(yè)務量小，影響的范圍面積也少。而微批次的 ETL 則是針對延遲低的業(yè)務，將 處理增量業(yè)務的 ETL 運行間隔時間，縮短為 1m 或者1s, 所以讓用戶感覺是實時在處理數據，Spark Stream 就是這類處理框架。如果用戶是在間隔時間內較早提出數據處理請求，就會明顯感覺到延遲了。 Kafka 與 Flink 的出現就很好的解決了這類實時 ETL 的應用。當然業(yè)界還有很多其他實時處理框架，比如Storm, SQLstream Blaze, IBM InfoSphere Streams等。

?

2 工具的出現，肯定也伴隨著適用場景的挑剔。并不是所有的 ETL 都要使用實時處理框架。仔細分別當前應用適合采用那種方式的處理便成了一門學問。比如實時推薦系統(tǒng)，如果當前登錄的帳戶是全家共用的，推薦系統(tǒng)需要實時監(jiān)測帳戶瀏覽了哪些產品，來做出有效的推薦，此時實時處理和訓練模型就顯得比較合適

?

3 在應用實時處理框架的時候，通常會碰到業(yè)務場景帶來的技術實現難題，歸納這些難題，找出最佳實踐 也成了項目的工作重心。所以在實施Stream Processing 技術平臺的時候，有哪些缺陷和挑戰(zhàn)也要注意避免和克服

?

Netflix 的業(yè)務概述:

Netflix processes 450 billion unique events daily from 100+ million active members in 190 different countries who view 125 million hours of content per day. The Netflix system uses the?microservice?architectural style?and services communicate via remote procedure call (RPC) and messaging. The production system has a large?Apache
Kafka?cluster with 700+ topics deployed that manages messaging and also feeds the data-processing pipeline.

?

每天需要處理 4500 億不同的事件，采用了微服務架構， RPC 和消息系統(tǒng)。擁有700多話題的 Kafka 集群，已經穩(wěn)穩(wěn)的運行在生產環(huán)境用來傳遞消息到數據處理系統(tǒng)。

?

Netflix 數據架構:

?

Within Netflix, the Data Engineering and Analytics (DEA) team and Netflix Research are responsible for running the personalization systems. At a high level, microservice application instances emit user and system-driven data events that are collected within the?Netflix Keystone?data pipeline?— a petabyte-scale real-time event streaming-processing system for business and product analytics. Traditional batch data processing is conducted by storing this data within a?Hadoop Distributed File System (HDFS)?running on the Amazon S3 object storage service and processing with?Apache?Spark,?Pig,?Hive, or?Hadoop. Batch-processed data is stored within tables or indexers like?Elasticsearch?for consumption by the research team, downstream systems, or dashboard applications. Stream processing is also conducted by using Apache Kafka to stream data into?Apache Flink?or?Spark Streaming.

?

總體上分為三塊，作為數據來源的業(yè)務系統(tǒng)，由微服務架構來承載。作為數據的消費者，分為了批次處理以及實時處理。批次處理的數據，采用的是Hadoop 框架，數據存儲在 Amazon S3 上面，計算框架多樣化，有 Spark, Hive, Pig, MapReduce. 最終結果的輸出，會存儲到Hive或者 關系型數據庫數據表，還有ElasticSearch 等索引庫以供最終的用戶使用；而實時數據，則由 Kafka 導入 Stream Processing 框架中處理，這類計算框架主要包含了 Spark Stream, Flink .

?

?

在選擇實時處理平臺的時候，Netflix 為什么選擇Flink 而不是 Spark, 原因有幾何？

?

1 support for customization windowing: 除了 event-based processing（實時處理）之外，Flink 還可以提供處理ETL間隔可定制化的功能，而這份功能正是 Spark?
Stream 的核心功能。

?

2 lambda architecture:?在數據處理領域里， lambda architecture 的概念是融合了批次處理與實時處理方法。一方面，通過建立一層 batch layer 來平衡延遲，吞吐量和容錯，達到完整一致的數據試圖；另一方面，通過建立一層 Speed Layber來實時同步數據處理。Flink 同時具有上述兩種特性，另一種具有 lambda architecture 設計思路的實時處理平臺是 Storm.

?

Netflix 面臨的一個需要轉實時處理的應用場景是，需要通過用戶的觀看歷史，提供用戶更多的感興趣的視頻，并且縮小這份分析時間從24小時的延遲到實時。在轉換的過程中，NetFlix 遇到一些問題:

?

1 實時獲取其它系統(tǒng)的數據，比如用戶瀏覽記錄；

2 多維度信息的抽取。應用系統(tǒng)或許有緩存，如何抓最新的數據便成了難題

3 數據恢復：提高了故障處理的難度。原本批次處理，可以重新啟動批次處理的任務；而實時處理的任務，需要更迅速的恢復

4 對過期事件的處理

5 增加了對監(jiān)控的要求

?

?

采用的技術手段有：

1 Kafka 作為消息系統(tǒng)

2 Hive 作為聚合計算引擎

3 Amazon s3 作為存儲引擎

4 NetFlix OSS棧作為 java 生態(tài)連接

5 Apache Mesos 作為調度工具

6 Spinnaker 作為持續(xù)級成工具

?

在Netflix 的數據平臺中，值得拿來說的是 lambda architecture, 其他技術在之前的文章中已經講述過理論和實踐。

?

Lambda architecture, 在 《Design Data-Intensive Applications》中首次接觸。核心思想便是批次處理與實時處理技術共存。而同時容納著兩種技術的優(yōu)越之處是什么，畢竟它看上去有些冗余和復雜（不僅僅是我這么認為， 《Data-Intensive》的作者Martin 也提出了以下三個疑惑 ） ：

1 如果批次處理與實時處理的邏輯是一樣的，那么實時處理如果故障率很小，似乎沒有必要再運行一邊批次處理 ；

2 鑒于批次處理與實時處理的輸出結果是隔離的，如何將兩者的結果統(tǒng)一起來，又成了一個復雜的操作。比如將兩者的數據用類似 SQL 的聯(lián)合(Join)算法鏈接起來，采用非 SQL的編程方法就徒增難度了。

3 分布式系統(tǒng)雖然可以處理大規(guī)模的數據集，但是每一次聚合就要處理所有歷史記錄，會最終逐漸擴大處理的相應時間。所以分布式系統(tǒng)中也要設置跑批的數據，使得每一次增量更新影響的數據范圍足夠小。因此也就增加了編程的復雜性

?

以上 LA 架構的缺陷主要是由于 批次處理 (Batch Processing, 大規(guī)模的循環(huán)處理歷史數據)和實時處理(Real-Time processing , 實時處理事件數據) 實現方式分離，即兩者應用了不同的實現技術造成的。Flink 與 Storm 等實時處理框架流行起來后，Lambda Architecture 注入了新的活力，他們融合了批次處理與實時處理于同一個平臺之中，分層處理與結果整合做到無縫鏈接:

?

1 批次處理與實時處理都應用同一個處理引擎，實時處理如果處理失敗，可以驅動批次處理再一次執(zhí)行。如果不使用同一個處理引擎，那么失敗的實時處理必須要有一套機制來傳輸給批次處理引擎，使其重新處理。而針對同一個處理邏輯分別寫了兩個處理引擎上的計算程序，造成了人力的浪費

?

2 Exactly-once semantics: 在處理失敗的任務時，永遠只是嚴格的運行了一次處理程序，哪怕中間運行了很多次的失敗重處理，使得消息系統(tǒng)重發(fā)了很多歷史數據，但任何處理失敗的中間結果集都會被清理，最后只是嚴格的按照時間順序從頭處理了一遍。這需要消息的生產者和消費者在發(fā)送和接收的時候，嚴格的耦合在一起。如果實時處理與批次處理是不同的引擎處理的，那么實現這套機制就非常困難。

?

3 實時處理的時間標識，一定是事件(event) 發(fā)生時的時間，如此在重新處理歷史數據的時候，才能代表精確的處理時間，而這類標識一定是通過實時處理引擎才能做到的。

?

而這正是為什么 Flink 會替代 Spark Stream 被 NetFlix 選擇為實時處理引擎平臺的原因。Spark Stream 必須結合 Hadoop mapReduce 一起搭建lambda Architecture，而這種組合就會有一代 Lambda Architecture 的缺陷。而 Storm ,Flink 則是第二代的 Lambda Architecture 的平臺，有效地避免了一代的缺陷，而且提供更多的特性

?

?

除了明確的2層 之外，LA 還有一層服務層。這一層融合了另外兩層的結果，將結果合并起來，做好聚合以及索引，以提高查詢和分析的響應時間，比如 Impala 以及 NoSQL

總結

以上是生活随笔為你收集整理的Netflix: 从 Batch ETL 到 Stream Processing 的转型之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。