Netflix：使用大数据驱动业务决策

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 所展现的，大数据战略并不是一个事后规划，相反它必须预先规划，并在数年时光中贯彻执行。

原文英文链接： Big Data at Netflix Drives Business Decisions