BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

从批处理ETL到流式处理:一个来自Netflix的案例

| 作者 Daniel Bryant 关注 586 他的粉丝 ,译者 Martin 关注 0 他的粉丝 发布于 2018年3月13日. 估计阅读时间: 12 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

要点

  • 在将基于批处理的ETL迁移到流式处理的过程中,需要考虑很多因素,并做出很多权衡。不能只是因为流式处理技术的流行而将所有东西都使用流来处理。
  • 这篇文章的案例来自Netflix,他们使用Apache Flink代替原有的批处理系统。之所以选择Flink,是因为他们需要实时的事件处理和可扩展的自定义窗口。
  • 在迁移过程中碰到了很多困难,例如,如何从实时数据源获取数据、如何管理元数据、如何进行数据恢复、如何处理乱序数据,以及如何做好运维工作。
  • 流式处理为业务带来了好处,例如,可以使用最新的数据来训练机器学习算法。
  • 流式处理也带来了技术方面的好处,例如,可以更灵活地节省存储成本、与其他实时系统集成。

在2017年的纽约QCon大会上,Shriya Arora呈现了“Personalizing Netflix with Streaming Datasets”的演讲,分享了Netflix的一个数据作业迁移案例,他们使用Flink替代了原先基于批处理的ETL。

Arora是Netflix的一名高级数据工程师,在演讲刚开始,Arora说明了演讲的主要目的是帮助听众们了解流式处理数据管道是否能够帮助他们解决传统ETL批处理作业存在的问题。除此之外,她还探讨了在向流式处理迁移过程中需要注意的问题和需要作出的权衡。Arora表示,“批处理并没有死去”,尽管现在有很多流式处理引擎,但没有哪一个能够单独提供最佳的解决方案。

Netflix的核心使命是让用户能够在任意时刻、任意地点观看定制化的视频内容。Netflix每天需要处理来自190多个国家1个多亿个活跃用户所生成的4500亿个事件,这些用户每天观看视频的总时间超过1亿2500万个小时。Netflix的系统采用了微服务架构,服务之间通过远程过程调用(RPC)和消息进行通信。生产环境的Kafka集群拥有700多个主题,负责管理消息,同时向数据处理管道输送数据。

Netflix的数据工程分析(Data Engineering and Analytics,DEA)团队和Netflix Research团队负责运营定制化系统。微服务应用程序生成用户和系统数据,这些数据被收集到Netflix Keystone数据管道中,Keystone是一个PB级别的实时数据流式处理系统。传统的批处理是这样的:先将这些数据保存到部署在亚马逊S3上的Hadoop Distributed File System(HDFS)中,然后使用Apache Spark、Pig、Hive或Hadoop来处理数据。处理过的数据被保存到数据库表或Elasticsearch中,Research团队、下游的系统或仪表盘应用程序就可以使用这些数据。与此同时,他们也使用Apache Kafka将数据导向Flink或Spark Streaming。

在介绍他们如何将ETL批处理作业转成流式处理之前,Arora告诫听众,“不要尝试流式化所有的东西”。流式处理确实能够带来业务上的好处,比如可以使用最新的数据来训练机器学习算法、为市场创新提供新的想法,以及增加开发新机器学习算法的可能性。流式处理也能带来技术上的好处,比如更灵活地节约存储成本(原始数据不需要以最初的形式保存)、更快的回退(批处理在发生故障时需要很长的回退时间)、实时的审计,以及与其他实时系统集成。

在实现流式处理时,最大的挑战是如何选择一个合适的引擎。首先要搞清楚的是,数据的处理是基于事件流的还是基于微批次的。在Arora看来,微批次只是批处理的一个子集,只不过是将时间窗口从一天变成了一个小时或一分钟,数据的处理仍然是基于一大段数据,而不是基于事件。如果说只是期望更快一点获得结果,而且企业已经在批处理上做了大量投入,那么迁移到微批次处理可能是最合适的低成本解决方案。

在选择引擎时,另一个需要考虑的问题是:哪些特性是最为关键的。这个问题不是通过一场头脑风暴就能解决的,通常只有在对问题有深入了解并经过深度调研之后才能得出答案。Netflix的系统需要“会话化”的事件数据,也就是基于会话的时间窗口。各种引擎对该特性的支持程度各不一样,最后,他们选择了Flink,因为相比Spark Streaming,Flink提供了更好的自定义窗口支持(不过,在这次演讲之后,Spark发布了2.2.0,以及最近发布的2.3.0,提供了Structured Streaming和高级的会话处理能力)。

还一个需要考虑的问题是:是否需要支持lambda架构。这里所说的lambda不是指AWS Lambda或无服务器架构。在数据处理领域,lambda架构指的是同时使用批处理和流式处理的方式来处理海量数据,以便在延迟、吞吐量和容错方面做出权衡。批处理层提供了整体精确的批次数据视图,同时实现了一个速度层,用于实时的流式处理,提供几近完整的实时在线数据视图。如果已经存在一个批处理作业,只需要再加入一个速度层,那么,可以选择一个lambda架构的引擎,这样就可以重用已有的代码。

在选择流式处理引擎时还需要考虑如下的问题:

  • 公司的其他团队在使用什么引擎?如果说采用新技术需要大量投入,那么或许可以考虑利用公司已有的技术。
  • 公司现有的ETL系统是怎样的?新技术是否能够与已有的数据源和数据池很好地接在一起?
  • 新技术的学习曲线是怎样的?批处理所采用的是什么引擎和编程语言?

演讲的倒数第二部分主要介绍了Netflix是如何将批处理ETL转成流式ETL的。之前,Netflix的DEA团队使用批处理ETL来分析播放源(Source of Play)和发现源(Source of Discovery),至少需要8个小时才能完成。播放源是指从Netflix应用程序的主页面到用户开始播放视频的位置,而发现源是指用户在主页面上发现想观看内容的位置。DEA团队的终极目标是优化主页面,最大化用户观看的转化率,并减小从事件发生到得出分析结果之间的延迟(当时是超过了24小时),而实时处理可以大幅缩短这一差距。

经过对“发现源”问题的深入分析,Netflix发现,流式处理引擎可以帮助他们实现如下的一些目标:处理高吞吐量数据(全球用户每天生成大概1亿个播放事件);通过胖客户端(基于RPC)与直播微服务发生交互,以便对播放事件进行填充;与Netflix生态系统的其他系统进行集成;集中式的日志和告警;支持低变更频率的输入数据(比如包含电影元数据或国家人口统计资料的元数据表)。

最后,Arora和她的团队选择了Flink,以及其他相关技术:

  • 使用Kafka作为消息总线;
  • 使用Hive进行数据摘要、查询和分析,Hive提供了SQL风格的接口(这里主要用在元数据上);
  • 使用亚马逊S3存储数据(HDFS);
  • 通过Netflix OSS与Netflix生态系统的其他部分集成;
  • 使用Apache Mesos调度和执行作业;
  • 使用Spinnaker实现持续交付。

下图展示了发现源的整体管道架构:

Arora总结了DEA团队在迁移过程中面临的主要挑战:

  • 从直播源获取数据:
    • 迁移后的作业需要访问完整的用户播放历史。
    • 理论上,可以很容易地通过流式处理来实现,因为与Netflix生态系统的集成和数据处理的实时性意味着处理一个事件只需要一个简单的RPC调用。
    • 不过,因为Flink和Netflix OSS都是使用Java开发,有时候会出现类库的兼容性问题(也就是所谓的“JAR包地狱”)。
  • 侧面输入:
    • 流式处理作业中的每一项元数据可能在获取直播源数据时就已经获取过了。
    • 重复获取数据需要更多的网络开销,最终会导致不合理的资源利用。
    • 所以,他们将元数据缓存在内存里,每15分钟刷新一次。
  • 数据恢复:
    • 如果一个批处理作业因为基础设施问题而运行失败,可以重新运行,因为数据仍然保存在底层的对象存储中,比如HDFS。但在流式处理中可能不是这么一回事,因为原始事件被处理之后可能就不存在了。
    • 在Netflix生态系统中,消息总线(Kafka)的TTL可能是4到6个小时,如果一个流式处理作业执行失败,并且无法在TTL期限内检测出来并加以修复,那么数据就会丢失掉。
    • 解决办法是将原始数据保存在HDFS里(保留一到两天),便于后续重新处理。
  • 乱序事件:
    • 如果数据管道出现故障,需要进行数据恢复,这意味着“旧”数据将会混杂在新的实时数据中。
    • 问题在于如何正确地使用数据的生成时间来标记迟到的数据。
    • DEA团队选择自己实现时间窗口,并进行后处理(Post Processing),确保使用的是正确的事件时间。
  • 监控和告警的增长:
    • 一旦发生管道故障,相应的团队必须立即收到告警。
    • 如果不能及时触发告警,将会造成数据丢失。
    • 实现高效的监控、日志和告警至关重要。

Arora在演讲的最后表示,尽管将批处理ETL迁移到流式处理能够在业务和技术两个方面带来很多好处,但同时也带来了很多挑战。采用流式处理的工程师们需要为此付出代价,因为大部分传统的ETL都是基于批处理的,而基于流式处理进行机器学习训练还只是个相对新兴的领域。数据团队也需要处理运维问题,比如参与轮班待命或处理中断事故。可以说,批次故障需要得到紧急处理,而流式故障需要立即得到解决。企业需要投入资源构建具有弹性的基础设施,构建高效的监控和告警机制,并创建能够支持快速迭代和部署的持续交付管道。

Arora在2017年纽约QCon大会的演讲视频可以在InfoQ网站上找到。

关于作者

Daniel Bryant 是组织和技术的变革者。他目前的工作包括:通过引入更好的需求和计划模型在企业中促进敏捷的实施、专注于与敏捷开发相关的架构问题、促进持续集成和持续交付的实施。他目前的技术领域主要包括DevOps工具、云计算/容器平台和微服务实现。他是伦敦Java社区(LJC)的负责人,是多个开源项目的贡献者,为多个知名网站(InfoQ、DZone和Voxxed)撰文,并定期在国际大会(QCon、JavaOne和Devoxx)上演讲。

查看英文原文Migrating Batch ETL to Stream Processing: A Netflix Case Study with Kafka and Flink

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

流数据存入离线HDFS难道不应该整个历史保存吗 by 裴 帅帅

原始数据才是宝藏,处理后的数据必定有损失;

难道不应该让流将原始数据存入HDFS,整个历史保存,随时可以再次挖掘吗

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT