2013 年旧金山 QCon 大会上,Netflix 的数据平台架构经理 Jeff Magnusson 做了一场关于 Netflix 数据平台即服务(Data Platform as a Service)的演讲。沿着这场演讲的线索,我们将尝试进一步探寻技术栈的组成,以及它如何帮助Netflix 做出重要的业务决策。
在全球范围里,Netflix 拥有超过三千万订阅用户。访问 Netflix 网站过程中,每位用户都会提供若干数据点。而网站将用户对视频进行的播放、打分或搜索等操作,作为事件进行捕捉和分析。此外,用户使用中涉及到的时间、日期、地理位置、设备和页面中的浏览或滚动行为,也将被 Netflix 用来提供操作事件发生的环境,并将用户划分到不同的类别中。Netflix 使用这些数据来提升其网站的参与度,并做出诸如接下来将资助哪套连续剧等业务决策。
来自诸如 Nielsen 等第三方或社交媒体的元数据,也有助于对平台吸引用户参与或新用户订阅。
自 2009 年起,Netflix 就已经运行在云上,并使用了 Hadoop 平台。他们所采用的基础设施中,关键的大数据模块包括:
- Amazon S3:亚马逊 S3 技术被用来捕捉来自数以十亿计的使用 Ursula(一种内部数据管线工具)的设备。S3 被当作运行 Hadoop 任务的 Elastic Map Reduce(EMR)集群的可信来源。
- Hadoop:Apache Hadoop 被用作分布式计算的基准库,它部署在 AWS 上的 Elastic Map Reduce 集群上;另外,每个节点提供的存储中并没有使用 HDFS,而是利用 S3 桶存储。这有点古怪,因为它可能会导致从 S3 到 EMR 节点的迁移,违反 Hadoop 利用的数据本地性原则。但从另一方面来说,这意味着 S3 可以作为单一的可信来源,而 EMR 集群被作为消耗品,而且几乎可以被实时调整为合适的大小
- Hive:Netflix 把 Hive 用在特定的查询和轻量级聚合上。Pig 则用在 ETL 和更复杂的数据流方面。其数据迁移方面的特长也被用来在复杂的操作之间进行连接。
- Genie:作为一种 Hadoop PaaS 技术, Genie 被用来在 EMR 中提交任务。Genie 提供了一种 RESTful API,在使用它时,开发者无需处理 Hadoop 集群固有的启动或维护工作。开发者可以从 Genie 的 GitHub代码库中 fork 它。
- Franklin:元数据 API Franklin 可以用来从 RDS、Redshift、Cassandra、Teradata 或 S3 源中提取信息。自 2011 年成功地从基于 Oracle 数据中心的解决方案迁移到 AWS 后,Netflix 就把 Cassandra 用在在线数据收集方面。过去,Teradata 主要被运用在数据中心领域,但随着 Teradata 宣布他们已经签约 Netflix 为其提供 Teradata 云服务后,这一产品定位也就随之发生了转变。
- Forklift: Forklift 可以用来在不同的数据仓库中迁移分析数据。源和目标位置可以是 Hive、RDBMS、S3、R 或其他类型。
- Sting: Sting 用于将 Genie 任务结果用特定的方式进行视觉化处理。通过讲数据集保留在内存中,Sting 能够以亚秒级响应时间执行常用 OLAP 操作,例如交叉分析。
- Lipstick: Lipstick 使用户能够按 Pig 任务和任务整体进展来把数据流视觉化。在这种方式下,用户可以直观地发现停滞的任务、错误输出的数据或失败的任务,并将这些问题快速修改以便正确执行。
除了这些工具,Netflix 还开发了 Curator 等若干辅助工具。 Curator 是一系列对运用 Apacke Zookeeper 有帮助的 Java 类库。使用 Curator,开发者能够轻易地构建健壮的客户端,并避免若干缺陷,例如不安全的客户端调用或是错误地假设某次请求会获得成功。
在上述技术栈的各个部分中,一个非常重要的组成部分是Netflix 推荐。Netflix 全部视频流中,大约有75% 是由推荐结果驱动的。驱动推荐的系统之一使用了马尔科夫链,将电影作为状态建模,并计算这些状态之间转换的可能性。在RDBMS 中,这将作为一个存储的规程,每周运行一次;不过作为一个昂贵的副本,它并不具有良好的可扩展性。使用Hadoop 后,这个问题就得到了本质的解决,能够进行扩展而无需复制任何数据,另外使用Pig 或Java Map Reduce 任务,将比作为存储的规程更易于维护。
马尔科夫链描绘了一种离散时间随机过程,它依据转移概率矩阵在一系列状态间变换。将每部电影作为一个节点建模,并使用双边Map Reduce 任务,Netflix 能够计算从某个节点转换到另一个的可能性,而这正是推荐值。未来的值仅仅依赖于当前值,这决定了它非常适合Map Reduce 任务——因为无需在Hadoop 节点中存储状态。
转移概率并不是Netflix 的推荐引擎中考虑的唯一一项参数。除此之外,使用环境也是一个值得考虑的有趣的维度。用户或许希望根据当前使用设备查看不同的内容——在家、休假或是在工作环境。这是一个Netflix 也尚未能够解决的问题,因为要想将使用环境与观看选项关联,还需要克服若干挑战。
无论是其他行业,还是同行业竞争对手,都无法简单地复制Netflix 的大数据架构。然而,其中部分构建模块现在已经开源,并放在其 GitHub 账户中供人们下载。对想要开始开发大数据架构的组织机构来说,它们都可以作为起步的基点。而正如 Netflix 所展现的,大数据战略并不是一个事后规划,相反它必须预先规划,并在数年时光中贯彻执行。
评论 1 条评论