Netflix 的云中数据仓库架构和 Hadoop PaaS——Genie

  • 郑柯

2013 年 2 月 4 日

话题:RESTAWSDevOps大数据架构AI

Netflix 基于 Hadoop 的数据仓库达到 Petabyte 量级,而且增长迅速。他们大数据处理架构十分独特,能让他们构建一个可以在云中无限扩容的数据仓库,而且是在数据和计算能力两方面同时做到无限扩容。前不久,他们在自己的技术博客上发布了一篇文章,其中谈到了 Netflix 基于云的数据仓库,以及它与传统基于数据中心的 Hadoop 基础设施的不同之处,此外还介绍了如何利用云的弹性构建动态可扩展的系统。文章重点对 Genie 项目做了说明,该项目是 Netflix 内部的 Hadoop PaaS,为作业执行和资源管理提供 REST-ful API。

在传统的、基于数据中心的 Hadoop 数据仓库中,数据保存在 HDFS 中。HDFS 可以运行在商用硬件之上,提供对大数据集的容错和高吞吐访问。在云中,最典型的方式就是跟随这个模型,将存在 HDFS 上的数据放在基于云的 Hadoop 集群上。但是,Netflix 没有这么做,他们的选择是:

我们将所有的数据存在 Amazon S3 上,这是我们架构的核心原则。

我们使用 S3 作为基于云的数据仓库的真正数据来源。任何值得存留的数据都放在 S3 上。这包括每小时产生的几十亿个流事件,它们来自支持 Netflix 的电视、笔记本电脑、移动设备,被我们的日志数据管道(Ursula)抓取,还有由 Cassandra 提供的维度数据,来自我们的Aegisthus管道。

之所以选择 S3,文中给出 4 个原因:

S3 保证其中存储的对象在一年期内的耐用性(durability)是 99.999999999%,可用性(availability)是 99.99%,并可同时承受两个机房的并行数据丢失。

其次,S3 提供存储桶版本控制,我们使用该功能来防止数据出现无意丢失。举个例子,如果开发人员不小心误删除某些数据,我们可以轻易恢复。

第三,S3 具备弹性,而提供事实上“无限”的存储容量。我们不需要事先准备任何存储资源,就让数据仓库做到了有机增长,从几百个 T 到 P 级。

最后,用 S3 作为数据仓库,我们可以运行多个高度动态化集群,而且能适应失败和负载。

当然,也有一些问题:

S3 的数据读取和写入都比 HDFS 慢。不过,很多查询和流程都是多步骤的 MapReduce 作业,因此第一个步骤中的 mapper 从 S3 中同时读取输入数据,最后一个步骤中的 reducer 将数据写回 S3。HDFS 和本地存储用来完成所有中间的转换和临时数据,这就降低了性能开销。

Netflix 使用 Amazon 的 Elastic MapReduce(EMR)Hadoop 版本。他们会使用多个 Hadoop 集群处理不同负载,全都访问同样的数据。一个超过 500 个节点的“查询”集群,供工程师、数据科学家、分析人员使用,完成随机查询。还有一个与“查询”集群大小相似的“生产”(或称为“SLA”)集群,运行由 SLA 驱动的 ETL(数据抽取、转换、加载)作业。他们还有其他一些“研发”集群,根据需要启动。

如果我们使用 HDFS 作为数据来源,那么就要把数据复制到所有的集群中。使用 S3,这就不是问题了,所有的集群可以马上访问同一个完整的数据集。

亚马逊通过 EMR 提供 Hadoop IaaS,EMR 有 API 可以准备和运行 Hadoop 集群。但 Netflix 实现了自己的 Hadoop PaaS,名为“Genie”,提供更高层面的抽象。开发人员可以使用 RESTful 的 API 来提交单个 Hadoop、Hive 或是 Pig 作业,而不需要准备新的 Hadoop 集群,或是安装任何 Hadoop、Hive 或 Pig 客户端。而且,这让系统管理员可以管理和抽象出云中不同 Hadoop 后端资源的配置。

那为什么还要开发 Genie 呢?

我们的 ETL 过程是松耦合的,组合使用 Hadoop 和非 Hadoop 工具,跨越云和我们的数据中心。举个例子:我们需要在基于云的 Hadoop 数据仓库中使用 Pig 和 Hive 执行每日总结,并将结果加载到在数据中心的关系数据仓库中。这是很常用的大数据架构,用小得多的关系数据仓库来对上基于 Hadoop 的系统。前者提供实时性更强的互动查询和报表,而且与传统的 BI 工具整合更好。目前,我们使用 Teradata 作为关系数据仓库。不过,我们也在研究 Amazon 的 Redshift 新产品。

在数据中心中,我们使用企业级调度应用UC4,用其定义数据中心和云之间不同作业的彼此依赖关系,将它们作为“ 流程流(process flow)”运行。因此,我们需要一种机制,在不安装整个 Hadoop 软件栈的前提下,做到从任何客户端启动 Hadoop、Hive 和 Pig 作业。而且,由于我们每小时运行数百个 Hadoop 作业,需要该系统来水平扩展,主要原因在于:随着将更多 ETL 和处理工作放在云中的 Hadoop 上,负载会不断增加。最后,由于云中的集群总有可能发生变化,而且有多个 Hadoop 集群可以运行 Hadoop 作业,我们需要从客户端中抽取出后端集群的具体细节。

之所以不用一些现有的工具,是因为:

开源社区中现在没有合适的工具,能满足我们的需求:要有 API 可以执行作业、抽象后端集群、有能力提交作业到多个集群、足够的可扩展性(水平或是其他方式)等等。

Genie 到底是什么呢?

Genie 是一系列 REST-ful 服务,用来管理 Hadoop 生态系统中的作业和资源。其中有两个关键服务。

  • 执行服务(Execution Service):提交和管理 Hadoop、Hive 和 Pig 作业。客户端通过执行服务 API 来与 Genie 交互,发送带有参数的 JSON 或是 XML 消息启动作业。如果一个作业提交成功,Genie 会返回一个作业 ID,可用它获取作业状态和输出 URL。
  • 配置服务(Configuration Service):保持可用 Hadoop 资源的资源库,包括需要链接和在这些资源上执行作业的元数据。配置服务跟踪所有目前运行的集群,还有它们支持的调度类型。

文中还简单介绍了如何使用 Genie 完成动态资源管理。

在 Netflix,不同工程师团队在 AWS 的自动扩展组(auto-scaling groups,简称 ASG)内的预留实例上运行自己的服务,它们会根据负载扩展或收缩。很多 ETL 作业在午夜执行,这个时候,很多 ASG 都已经变小了。因此,我们使用这些过剩的预留实例来启动“奖励”集群,补充其他生产集群。我们会用配置服务注册这些实例,Genie 客户端(ETL 作业)会使用执行服务 API 访问这些新集群。当工程团队需要他们的实例时,“奖励”集群会中止并取消注册,而且无法通过 Genie 客户端访问。

不像传统的 Hadoop 集群,我们不需要做滚动升级。如果需要升级一个生产(SLA)集群,一个方法是使用升级后的软件栈来启动一个新的生产集群,然后停止将流量路由到旧集群上,要实现这个目的,只需要设置其状态为“Out of Servcie”。另一个方法,是将运行中的集群状态设置为“Out of Service”,然后执行升级,并临时将另一个运行中的集群设置为 SLA 集群。

目前,Genie 项目还没有开源,让我们期待 Netflix 将其放在自己 Github 页面上的那一天!

RESTAWSDevOps大数据架构AI