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