Netflix: 从 Batch ETL 到 Stream Processing 的转型之路

大胆预测：重量级的数据应用，包括但不仅限于数据分析，数据挖掘，计算广告等，将全部会转换成实时数据处理架构。在电子化市场营销，尤其当今信息技术快速发展的前提下，数据处理的快慢直接影响变现的质量。

爱好收集一些数据应用，今天在 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 的区别: 在《DesignData-Intensive Applications》书中，Batch ETL 又可分为 Normal Batch ETL 和 Micro-Batch ETL, 即 传统意义上耗时非常长的 ETL 以及 微批次的 ETL. 耗时长的 ETL 通常会有占有一段非业务时间来处理，比如夜晚的 0 点到 6 点，这段时间由于业务量小，影响的范围面积也少。而微批次的 ETL 则是针对延迟低的业务，将 处理增量业务的 ETL 运行间隔时间，缩短为 1m 或者1s, 所以让用户感觉是实时在处理数据，Spark Stream 就是这类处理框架。如果用户是在间隔时间内较早提出数据处理请求，就会明显感觉到延迟了。 Kafka 与 Flink 的出现就很好的解决了这类实时 ETL 的应用。当然业界还有很多其他实时处理框架，比如Storm, SQLstream Blaze, IBM InfoSphere Streams等。

2 工具的出现，肯定也伴随着适用场景的挑剔。并不是所有的 ETL 都要使用实时处理框架。仔细分别当前应用适合采用那种方式的处理便成了一门学问。比如实时推荐系统，如果当前登录的帐户是全家共用的，推荐系统需要实时监测帐户浏览了哪些产品，来做出有效的推荐，此时实时处理和训练模型就显得比较合适

3 在应用实时处理框架的时候，通常会碰到业务场景带来的技术实现难题，归纳这些难题，找出最佳实践 也成了项目的工作重心。所以在实施Stream Processing 技术平台的时候，有哪些缺陷和挑战也要注意避免和克服

Netflix 的业务概述:
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 和消息系统。拥有700多话题的 Kafka 集群，已经稳稳的运行在生产环境用来传递消息到数据处理系统。

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.

总体上分为三块，作为数据来源的业务系统，由微服务架构来承载。作为数据的消费者，分为了批次处理以及实时处理。批次处理的数据，采用的是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 实时获取其它系统的数据，比如用户浏览记录；
2 多维度信息的抽取。应用系统或许有缓存，如何抓最新的数据便成了难题
3 数据恢复：提高了故障处理的难度。原本批次处理，可以重新启动批次处理的任务；而实时处理的任务，需要更迅速的恢复
4 对过期事件的处理
5 增加了对监控的要求

采用的技术手段有：
1 Kafka 作为消息系统
2 Hive 作为聚合计算引擎
3 Amazon s3 作为存储引擎
4 NetFlix OSS栈作为 java 生态连接
5 Apache Mesos 作为调度工具
6 Spinnaker 作为持续级成工具

在Netflix 的数据平台中，值得拿来说的是 lambda architecture, 其他技术在之前的文章中已经讲述过理论和实践。

Lambda architecture, 在 《Design Data-Intensive Applications》中首次接触。核心思想便是批次处理与实时处理技术共存。而同时容纳着两种技术的优越之处是什么，毕竟它看上去有些冗余和复杂（不仅仅是我这么认为， 《Data-Intensive》的作者Martin 也提出了以下三个疑惑 ） ：
1 如果批次处理与实时处理的逻辑是一样的，那么实时处理如果故障率很小，似乎没有必要再运行一边批次处理 ；
2 鉴于批次处理与实时处理的输出结果是隔离的，如何将两者的结果统一起来，又成了一个复杂的操作。比如将两者的数据用类似 SQL 的联合(Join)算法链接起来，采用非 SQL的编程方法就徒增难度了。
3 分布式系统虽然可以处理大规模的数据集，但是每一次聚合就要处理所有历史记录，会最终逐渐扩大处理的相应时间。所以分布式系统中也要设置跑批的数据，使得每一次增量更新影响的数据范围足够小。因此也就增加了编程的复杂性

以上 LA 架构的缺陷主要是由于 批次处理 (Batch Processing, 大规模的循环处理历史数据)和实时处理(Real-Time processing , 实时处理事件数据) 实现方式分离，即两者应用了不同的实现技术造成的。Flink 与 Storm 等实时处理框架流行起来后，Lambda Architecture 注入了新的活力，他们融合了批次处理与实时处理于同一个平台之中，分层处理与结果整合做到无缝链接:

1 批次处理与实时处理都应用同一个处理引擎，实时处理如果处理失败，可以驱动批次处理再一次执行。如果不使用同一个处理引擎，那么失败的实时处理必须要有一套机制来传输给批次处理引擎，使其重新处理。而针对同一个处理逻辑分别写了两个处理引擎上的计算程序，造成了人力的浪费

2 Exactly-once semantics: 在处理失败的任务时，永远只是严格的运行了一次处理程序，哪怕中间运行了很多次的失败重处理，使得消息系统重发了很多历史数据，但任何处理失败的中间结果集都会被清理，最后只是严格的按照时间顺序从头处理了一遍。这需要消息的生产者和消费者在发送和接收的时候，严格的耦合在一起。如果实时处理与批次处理是不同的引擎处理的，那么实现这套机制就非常困难。

3 实时处理的时间标识，一定是事件(event) 发生时的时间，如此在重新处理历史数据的时候，才能代表精确的处理时间，而这类标识一定是通过实时处理引擎才能做到的。

而这正是为什么 Flink 会替代 Spark Stream 被 NetFlix 选择为实时处理引擎平台的原因。Spark Stream 必须结合 Hadoop mapReduce 一起搭建lambda Architecture，而这种组合就会有一代 Lambda Architecture 的缺陷。而 Storm ,Flink 则是第二代的 Lambda Architecture 的平台，有效地避免了一代的缺陷，而且提供更多的特性

除了明确的2层 之外，LA 还有一层服务层。这一层融合了另外两层的结果，将结果合并起来，做好聚合以及索引，以提高查询和分析的响应时间，比如 Impala 以及 NoSQL

欢迎关注【有关SQL】