Netflix 实现Media 数据库

在之前的文章Netflix Media数据库特性中，我们介绍了Netflix媒体数据库(NMDB)及其突出的”媒体文档”数据模型。在这篇文章中，我们将从系统需求开始提供NMDB系统架构的详细信息——这些将作为我们做出架构选择的必要动机。任何持久数据系统的一个基本要求是，它应该随着其希望服务的业务应用程序的增长而伸缩。NMDB被构建为一个高度可伸缩的、多租户的、媒体元数据系统，可以提供高容量的写/读吞吐量，并支持近乎实时的查询。在任何给定时间，都可能有几个应用程序试图持久化关于媒体资产的数据(例如，图像、视频、音频、字幕)和/或试图利用这些数据来解决业务问题。

这种数据系统的一些基本要素是(a)可靠性和可用性- -在各种负荷条件以及各种各样的存取模式下;(b)可伸缩性——坚持和大量的媒体服务元数据和比例在面对丛发性请求服务至关重要的后端系统(如媒体编码,(c)可扩展性,支持的要求列表特性越来越多的Netflix业务用例,和(d)的一致性,保证数据访问语义重复的数据读取客户机应用程序的行为。下面的部分列举了NMDB的关键特性以及设计的目的是如何解决这些特性。

系统需求

对结构化数据的支持

NoSQL数据库的发展伴随着数据”无模式”的趋势(例如，键值存储通常允许在键下存储任何数据)。对于正在生成数据的应用程序开发人员来说，无模式系统似乎没有那么大的影响，因为它(A)使开发人员免除了对数据结构进行规划和未来验证的负担，(b)使他们能够轻松地按照自己的喜好发展数据格式。然而，模式在无模式系统中是隐式的，因为读取数据的代码需要考虑结构和数据中的变化(“读模式”)。这给希望使用这些数据宝藏的应用程序带来了负担，并可能导致编写数据的系统和使用数据的应用程序之间的强耦合。由于这个原因，我们将NMDB实现为”写时模式”系统——在向NMDB写入时，数据根据模式进行验证。这提供了一些好处包括(a)模式是类似于一个API的合同,和多个应用程序可以受益于一个定义良好的合同,(b)数据有一个统一的外观和服从定义查询,以及提取、转换和加载(ETL)工作,(c)促进更好的数据无数应用程序之间的互操作性,(d)优化存储、索引和查询性能从而提高服务质量(QoS)。此外，这有助于提高数据读取吞吐量，就像我们在读取数据时消除复杂的应用程序逻辑一样。

“写时模式”系统的一个关键组件是确保输入数据神圣性的模块。在NMDB系统中，Media Data ValidatIOn Service (MDVS)是确保写入NMDB的数据符合前面提到的模式的组件。MDVS还充当数据模式本身的存储库和管理器。正如前一篇文章所指出的，数据模式本身可能会随着时间的推移而发展，但是到目前为止摄入的所有数据都必须与最新的模式保持兼容。MDVS通过对模式修改进行细致的处理来确保这一点，确保任何模式更新都与系统中已有的数据完全兼容。

多租户和访问控制

我们设想NMDB作为一个系统，帮助促进Netflix业务不同领域的创新。由一个团队开发的应用程序创建的媒体数据分析可以被另一个团队开发的应用程序使用，而不会产生冲突。这使得多租户以及数据访问控制成为需要解决的重要问题。所有NMDB api都经过身份验证(AuthN)，以便预先知道访问应用程序的标识。此外，NMDB应用授权(AuthZ)过滤器，将特定操作的应用程序或用户列入白名单，例如，可以将用户或应用程序列入白名单以进行读/写/查询，或者对特定媒体元数据进行更严格的只读访问。

在NMDB中，我们以”数据存储”为单位来考虑媒体元数据。对各种媒体资产执行的特定媒体分析(例如，对所有音频文件的响度分析)通常存储在相同的数据存储(DS)中。而对于相同的媒体资产，不同类型的媒体分析(例如，视频镜头边界和视频人脸检测)通常会保存在不同的数据存储中。DS帮助我们实现两个非常重要的目的(A)作为一个逻辑名称空间为同一媒体分析各种媒体资产的Netflix目录,和(b)作为一个单元的访问控制,应用程序(或相当于一个团队)定义了一个数据存储还配置了对数据的访问权限。此外，正如前一篇博客文章所描述的，每个DS都与它存储的数据的模式相关联。因此，DS的特征是三元组(1)名称空间，(2)媒体分析类型(例如，视频拍摄边界数据)和(3)媒体分析类型的版本(媒体分析的不同版本对应于不同的数据模式)。如图1所示。

我们选择了DS定义的名称空间部分来对应LDAP组名称。NMDB使用它引导自助服务流程，其中LDAP组的成员被授予”admin”特权，可以执行各种操作(如创建DS、删除DS)和管理访问控制策略(如添加/删除”writer”和”readers”)。这允许创建和管理DS的无缝自助服务流程。因此，DS的概念是支持多租户和细粒度访问控制的关键。

与其他Netflix系统集成

在Netflix微服务环境中，不同的业务应用程序作为不同媒体资产的记录系统。例如，虽然标题的视频、音频和字幕等可播放媒体资产可以由”播放服务”管理，但图像或视频预告片等促销资产可以由”促销服务”管理。NMDB引入了”MediaID”(MID)的概念，以促进与这些不同的资产管理系统的集成。我们认为MID是指向NMDB中的媒体文档实例的外键。多个应用程序可以使用它们的特定于域的标识符/键来处理NMDB中的媒体文档实例。我们将MID实现为字符串到字符串的映射。与媒体数据模式一样，NMDB DS也与单个MID模式相关联。然而，与媒体数据模式不同，MID模式是不可变的。在定义DS时，客户机应用程序可以定义一组(名称、值)对，所有媒体文档实例都将根据这些对存储在该DS中。MID句柄可用于在NMDB的DS中获取文档，为特定媒体资产提供对最新或所有文档的方便访问。

SLA保证

NMDB服务于不同的逻辑层次的业务应用程序，其中一些应用程序被认为比其他的业务应用程序更重要。Netflix media transcoding子系统是业务关键应用程序的一个例子。这个子系统中的应用程序具有严格的一致性、持久性和可用性需求，因为大量的微服务正在为我们的客户生成内容。如果不能以较低的延迟提供数据，那么多个管道就会停止工作，这可能会对辅助后端服务造成连锁影响。这些业务需求促使我们在NMDB中持久化数据时，将不可变性和写后读一致性作为基本原则。

我们选择了高数据容量和高性能的Cassandra (C*)数据库作为后端实现，作为所有数据的真实来源。前端服务(称为媒体数据持久性服务(Media Data Persistence service, MDPS))管理C*后端，并以惊人的速度(延迟为几十毫秒)提供数据，以支持这些业务关键应用程序。MDPS使用本地仲裁进行读和写，以确保写后读的一致性。数据的不变性帮助我们避免任何冲突问题，可能出现的并发更新到C*，同时允许我们执行IO操作在一个非常快的剪辑。我们使用UUID作为C *的主键,从而使每一个写操作(一个中期+媒体文档实例)一个唯一键,从而避免写冲突当多个文档保存对中期相同。这UUID(也称为DocumentID)还充当主键为媒体文档实例上下文的整体NMDB系统。我们将在后面的部分再次讨论不可变性，以展示我们如何在NMDB的其他设计方面也从它获益。

灵活的查询

数据建模和”写时模式”系统的关键好处是查询能力。驻留在NMDB中的技术元数据对于开发内容建议、标题提升、机器辅助内容质量控制(QC)以及用户体验创新等领域的新业务洞察非常宝贵。NMDB的主要用途之一是它可以用作数据仓库。这就需要对数据进行索引并使其可用于查询，而无需预先了解所有可能的查询模式。

原则上，图形数据库可以回答任意查询，并为连接提供最佳的查询性能。出于这个原因，我们研究了一个类似于图形的数据模型，以便处理查询用例。然而，我们很快了解到，我们的主要用例，即媒体时间轴上的时空查询，使用了有限的数据库连接。在那些使用连接的查询中，连接的程度很小。换句话说，类图模型的能力没有得到充分利用。我们得出结论，对于有限的连接查询用例，应用程序端连接可能提供令人满意的性能，并且可以由我们称为媒体数据查询服务(Media Data query Service, MDQS)的应用程序来处理。此外，还出现了另一种查询模式——搜索非结构化文本数据，例如挖掘电影脚本数据和字幕搜索。我们很清楚，具有搜索功能的文档数据库将满足我们的大多数需求，比如允许多个元数据、快速算法开发、提供非结构化查询以及结构化查询，即使查询模式不是预先知道的。

Elasticsearch (ES)是一种高性能、可伸缩的文档数据库实现，非常适合我们的需求。ES支持广泛的查询可能性，尤其是在非结构化文本搜索方面，例如，在字幕资产中搜索具有文化敏感性的单词，需要基于单词的词干进行搜索。ES的核心是使用Lucene——一个功能强大、功能丰富的索引和搜索引擎。前端服务(称为媒体数据分析服务(Media Data Analysis service, MDAS))管理NMDB ES后端，用于编写和查询操作。MDAS为回答查询和索引数据实现了几种优化，以满足存储具有不同特征和大小的文档的需求。本文后面将对此进行更深入的描述。

数据库中的数据系统

如上所述，业务需求要求将NMDB实现为一个具有多个微服务的系统，这些微服务管理多语言数据库(DBs)。不同的组成星展服务于互补的目的。然而，面对典型的分布式系统缺陷，我们面临着保持跨系统数据一致性的挑战——有时依赖服务可能会失败，有时服务节点可能会宕机，甚至添加更多节点来满足突发需求。这激发了对健壮编排服务的需求，该服务可以(a)维护和执行状态机，(b)在发生瞬时故障时重试操作，(c)支持异步(可能长时间运行)操作，比如查询。我们使用指挥编制框架来协调和执行与NMDB创建、读取、更新、删除(CRUD)操作和其他异步操作(如查询)相关的工作流。Conductor帮助我们在不同的存储后端实现高度的服务可用性和数据一致性。然而，考虑到系统和服务的集合是一致工作的，因此不可能在数据一致性方面提供强有力的保证，同时对某些用例仍然保持高可用性，这意味着数据读取倾斜并不是完全可以避免的。对于查询api尤其如此——这些api依赖于对媒体文档实例的成功索引，而索引是在ES中作为异步后台操作完成的。因此，对NMDB的查询最终应该是一致的。

图2显示了NMDB系统框图。与NMDB系统共享其名称的前端服务充当所有CRUD和查询操作的网关。读api是同步执行的，而写和长时间运行的查询api是通过导体工作流异步管理的。回到前面讨论过的数据不变性这一点上——它的另一个好处是，它保留了所有可能发生的写操作，例如，当客户机或导体框架可能由于临时连接问题重试写操作时。虽然这确实增加了数据占用，但好处远远大于存储成本，比如(a)允许无锁重试、(b)消除了解决写冲突的需要和(c)减少了数据丢失。

图2中包含一个名为Object Store的组件，它是NMDB数据基础结构的一部分。对象存储是一种高度可用的、web规模的、安全的存储服务，如Amazon的Simple storage service (S3)。此组件确保所有被持久存储的数据都经过分组和加密，以获得最佳性能。它同时用于写和读路径。此组件用作NMDB的各个组件之间交换媒体文档实例的主要方法。媒体文档实例的大小可以很大(数百mb)，这可能是因为媒体分析可以为元数据建模，例如视频文件中的每一帧。此外，由于对一些空间属性(如边界框)进行了建模，每帧数据的大小可能会激增)。这种机制通过确保媒体文档实例不必在读写路径中涉及的不同微服务之间通过网络传输，并且只在必要时才能下载，从而优化带宽和延迟性能。

NMDB在行动

虽然前面几节讨论了关键的体系结构特征，但在本节中，我们将深入研究NMDB实现。

将数据写入NMDB

注：上图是gif格式

图3所示的动画详细描述了在我们写入NMDB时所设置的运行机制。编写过程从一个客户机应用程序开始，该应用程序传达了编写媒体文档实例的意图。NMDB通过将作业提交给编制框架(导体)来接受写请求，并返回一个惟一的句柄来标识请求。客户端可以使用它来查询请求的状态。然后，按照这个顺序执行模式验证、文档持久性和文档索引步骤。一旦文档被保存在C*中，它就可以以强一致性保证读取，并且可以被只读应用程序使用。将文档索引到ES中可能是一个高延迟操作，因为这是一个相对密集的过程，需要多个进程协调来分析文档内容，并更新几个数据结构，从而实现高效的搜索和查询。

另外，值得注意的是使用对象存储来跨服务组件优化IO(如前所述)。NMDB利用云存储服务(例如AWS S3服务)，客户端首先将媒体文档实例数据上传到该服务。对于每个对NMDB的写请求，NMDB生成一个Type-IV UUID，用于组合一个键。然后，密钥用于组合一个惟一的URL，客户端将其希望写入NMDB的数据上传到该URL。然后将此URL作为媒体文档实例数据的引用传递。

扩展策略

从向NMDB写入的角度来看，一些NMDB组件计算量很大，而另一些组件IO很大。例如，MDVS的瓶颈是CPU和内存(因为它需要处理大型文档进行验证)。另一方面，MDAS也受网络IO的约束(媒体文档实例需要从NMDB对象存储库下载到MDAS，以便对它们进行索引)。可以使用不同的度量标准来配置一个连续的部署平台，例如用于NMDB的负载平衡和自动伸缩的Spinnaker。例如，”每秒请求数”(RPS)通常用于自动扩展微服务，以服务于增加的读取或查询。虽然RPS或CPU使用量可能是扩展同步服务的有用指标，但是异步api(如在NMDB中存储文档)引入了监视队列深度的需求，以预测工作的构建和相应的扩展。

上面讨论的策略为我们提供了一种准线性自动伸缩NMDB微服务层(在图4中标识为”服务平面”)的好方法。但是，如图4所示，系统能够支持的稳定状态RPS最终会达到一个稳定的水平，此时扩展服务平面并不能帮助提高SLA。此时应该非常清楚，数据节点(被标识为”数据后端”)已经达到了性能极限的峰值，需要进行伸缩。然而，分布式DBs的扩展速度不如服务那么快，而且根据数据占用空间的大小，横向或纵向扩展可能需要几小时到几天的时间。此外，虽然扩展服务平面可以是一个自动化的过程，但是添加更多的数据节点(C*或ES)来扩展数据后端通常是手工完成的。但是，请注意，一旦数据后端向上伸缩(水平和/或垂直)，伸缩服务平面的效果将表现为稳定状态RPS的增加，如图4所示。

与扩展数据节点相关的一个重要方面是每个DB实现的关键散列策略，值得一提。C*使用一致的键哈希，因此添加一个节点可以在节点之间均匀分布数据。然而，ES采用了基于模量的分布式哈希。在这里，添加一个数据节点可以改进切分在可用节点之间的分布，这在一定程度上有助于缓解查询/写瓶颈。然而，由于碎片的大小随着时间的推移而增长，水平扩展可能无助于提高查询/写性能，如图5所示。

ES要求在创建索引时为每个索引选择碎片的数量，如果不执行重索引步骤，就不能修改该索引，而重索引步骤对于大量数据来说是昂贵且耗时的。固定的预先配置的碎片大小策略可以用于计时数据，比如日志，其中可以创建新的碎片，而丢弃旧的碎片。但是，NMDB不能使用此策略，因为多个业务关键应用程序可以使用该数据，换句话说，NMDB中的数据需要是持久的，并且可能永远不会被丢弃。但是，如上所述，较大的碎片大小会对查询性能产生负面影响。这需要一些应用程序级别的管理来将碎片重新定位到多个索引中，如图6所示。

因此，一旦索引增长超过阈值，MDAS就为相同的NMDB DS创建不同的索引，从而允许索引随着时间增长，同时将碎片大小保持在一个范围内，以获得最佳的写/查询性能。ES有一个称为索引混叠的特性，这对于缓解由于适合我们所解释的场景的大碎片大小而导致的性能下降特别有帮助。索引别名可以指向多个索引，并通过聚合别名内所有索引的搜索结果来提供查询。

按比例索引NMDB中的数据

单个媒体文档实例可能很大，从数百个MBs到几个GBs不等。许多文档数据库(包括ES)对文档的大小有一个限制，在此限制之后，DB性能会显著下降。索引大型文档可能给数据系统带来其他挑战，比如需要高网络I/O连接、增加计算和内存成本、高索引延迟以及其他不利影响。

原则上，我们可以在媒体文档层次结构的各个级别应用ES父子关系，并将媒体文档实例拆分为几个较小的ES文档。然而，ES父子关系是一个两级关系，当多个这样的关系被链接在一起以表示一个深度嵌套模型时，查询性能会受到影响(NMDB媒体文档模型显示了最多五个嵌套级别)。另一种方法是，我们可以考虑将其建模为关系”子”端上具有高基数实体(“事件”和”区域”)的两级关系。然而，媒体文档可能包含大量的”事件”和”区域”实体(对于一个小时的内容，每个事件通常包含数十万个事件和数十个区域)，这将导致大量的子文档。这还可能对查询性能产生负面影响。

为了解决这些相反的限制，我们提出了使用”数据去正规化”的想法。采用这种方法需要更多的思考，因为数据去正规化可能会导致数据爆炸。通过一个称为”分块”的过程，我们将大型文档有效负载分割为多个较小的文档，然后在ES中对它们进行索引。较小的分块文档可以通过使用多线程计算(在单个服务节点上)或多个服务节点进行索引——这将导致更好的工作负载分布、有效的内存使用、避免热点并提高索引延迟(因为我们同时处理较小的数据块)。为了提供最佳的索引和查询性能，我们在使用这种方法的同时，还仔细地决定对哪些数据进行反规范化。我们的实现的更多细节如下所示。

分块媒体文档实例

媒体文档模型的层次性(如前一篇博客文章所解释的)需要在分块时仔细考虑，因为它包含实体之间的关系。图7描述了在ES中索引媒体文档实例之前对其执行的预处理。

· 每个媒体文档实例被均匀地分割为多个较小大小的块(几个MBs的顺序)。

· 资产、跟踪和组件级别的信息跨所有块进行反规范化，并且在ES中为每个块的父文档建立索引。这种跨不同块的父文档反规范化还帮助我们克服了ES父-子关系的一个主要限制，即父文档和所有子文档必须属于同一个切分。

· 在事件级别，跨所有区域的数据被反规范化，每个区域的子文档在ES中被索引。

这种体系结构允许跨多个节点分发媒体文档实例，并加快索引和查询性能。在查询时，MDAS根据查询模式使用不同的策略组合来有效地提供查询

· ES父子连接查询用于在需要时加速查询性能。

· 在另一种查询模式中，首先查询父文档，然后查询子文档，然后在MDAS中执行应用程序端连接来创建搜索结果。

服务查询和分析

如前所述，NMDB拥有一个索引媒体元数据的宝库，通过分析它可以开发许多有趣的见解。带有ES的MDAS后端构成了NMDB分析功能的主干。在典型的分析使用中，NMDB用户对两种类型的查询感兴趣:

1. 用于检索与指定查询匹配的所有文档的DS级查询。这类似于使用SQL ‘ WHERE ‘子句过滤记录。可以使用各种条件操作符’ = ‘、’ > ‘或’ < ‘等对媒体文档实例中的任何实体进行过滤。条件还可以使用逻辑运算符(如OR、AND、NOT等)进行分组。

2. 对媒体文档实例的更具针对性的查询，使用文档ID句柄检索文档的特定部分。在这种查询类型中，用户可以对媒体文档实例的每个实体应用条件筛选，并检索匹配的实体。

这两种查询类型针对不同的用例。第一种类型的查询跨越整个NMDB DS，可以提供关于DS中哪些文档匹配指定查询的信息。考虑到与匹配第一种类型查询的媒体文档实例对应的巨大数据负载，NMDB只返回匹配文档的坐标(documententid和MID)。第二种查询类型可以使用documententid针对特定的媒体文档实例，并使用条件过滤检索文档的部分。例如，只能检索满足指定查询的一组事件，以及跟踪和组件级元数据。虽然通常连续使用这两种类型的查询，但是在已经知道文档句柄的情况下，可以通过直接在特定的媒体文档实例上执行第二种查询类型来收集对数据的更多信息。

如前所述，在索引时分块媒体文档实例对于优化查询非常方便。由于保存了媒体文档实例的不同实体之间的关系，因此可以在ES层处理跨实体查询。例如，可以根据跟踪包含的事件数量或是否包含匹配指定查询的事件来筛选跟踪。前面解释的索引策略可以与ES的嵌套文档方法进行比较。将事件和区域级信息作为子文档进行索引，可以帮助我们更有效地输出搜索结果。

接下来是什么

正如在前一篇博客文章中所解释的，媒体文档模型具有层次结构，并提供了对媒体时间轴数据建模的逻辑方法。然而，这种层次结构对于并行处理不是最优的。特别是验证(MDVS)和索引(MDAS)服务可以通过并行处理大型媒体文档实例而大大受益，从而减少写延迟。媒体文档实例的组合结构将更易于并行处理，因此在缓解大型媒体文档实例带来的挑战方面将大有作为。简单地说，这样的结构意味着一个媒体时间轴由多个”较小的”媒体时间轴组成，其中每个媒体时间轴由对应的”较小的”媒体文档实例表示。这样的模型还可以实现不需要读取整个媒体文档实例的目标读取。

在查询方面，我们预计对跨不同NMDB数据存储实例执行连接的需求会越来越大——在某些场景中，这可能需要大量的计算。这一点，以及与ES相关的高存储成本，正促使我们寻找其他”大数据”存储解决方案。由于NMDB仍然是跨Netflix应用程序的首选媒体元数据平台，我们将继续仔细考虑可能需要支持的新用例，并评估我们将需要使用的技术来解决这些问题。未来工作的一些有趣领域可能包括探索用于分布式计算的Map-Reduce框架，如Apache Hadoop、查询处理、用于事务支持的关系数据库，以及其他大数据技术。Netflix在面向媒体的数据系统领域有大量的机会，特别是随着商业应用和相关数据的预期增长。

文章翻译自：https://medium.com/netflix-techblog/implementing-the-netflix-media-database-53b5a840b42a

部分名词可能与原文有出处。