Amazon DynamoDB：谈广告技术用例与设计模式

Original URL: https://amazonaws-china.com/cn/blogs/database/amazon-dynamodb-ad-tech-use-cases-and-design-patterns/

广告技术（简称ad tech）厂商正在运用Amazon DynamoDB保存各类市场营销数据，具体包括用户资料、用户事件、点击操作以及链接访问情况等等。在这些数据的支持之下，厂商的实时出价（RTB）、广告定位与归因等业务才有实现的可能。在本篇文章中，我们将一同了解广告技术厂商在DynamoDB使用方面的常见用例及设计模式。

这些用例往往要求较高的请求速率（每秒可达数百万的请求），延迟较低且可预测，以及较强的可靠性。为了应对读取量激增或者保证亚毫秒级别的读取延迟，广告技术厂商通常会求助于DynamoDB Accelerator（简称DAX）提供的缓存机制。而随着这类厂商逐步在全球多个地区部署其RTB与广告定位平台，不同AWS区域之间的数据复制也成为新的刚性需求。

作为一项全托管服务，DynamoDB在满足广告科技厂商上述严苛要求的同时，避免在数据库运维层面投入大量资源。更重要的是，厂商可以亲身体验到DynamoDB具有出色的成本效益，以及将业务迁移至DynamoDB所带来的数据库运营支出的下降。例如，GumGum就已经将其数字广告平台迁移至DynamoDB，与传统数据库方案相比预计可节约65%至70%的常规运维成本。

本文中使用的术语

在本篇文章中，我将使用以下几个数据建模术语：

• 1:1建模：使用分区键作为主键，进行一对一关系建模。
• 1:M建模：使用分区键与排序键作为主键，进行一对多关系建模。
• DAX缓存：将DAX作为DynamoDB之前的读取缓存将有助于降低读取延迟，并以更加经济高效的方式降低高访问频率内容的读取负载。

广告技术用例与设计模式

用例：实时出价（RTB）与广告定位中的用户资料存储

RTB与广告定位用例往往要求响应延迟不超过100毫秒。为了保证这种低延迟水平，广告技术厂商必须管理整个流程中各个步骤的延迟，包括数据库层的延迟。此外，日均支持上千亿次内容展示的RTB平台必然依托于一套强大的数据库，由后者处理每秒高达数百万请求、存储数十亿用户的资料以及上百TB的数据。在如此庞大的业务规模下，即使只有极小一部分出价操作未能及时完成，也可能造成数百万美元的损失。正因为如此，AdRoll等众多广告技术厂商选择DynamoDB以保证在任意业务规模下都可实现个位数毫秒级的访问延迟。

设计模式：存储在DynamoDB表中的用户资料数据采用1：1或1：M两种方式建模。在1：1建模的场景下，用户资料按用户ID进行分区与访问。如果需要更进一步的细粒度访问，则可使用1：M建模方法对用户资料进行细分并存储为单一条目层级，其中用户ID将作为分区键、进而细分为排序键。以此为基础，大家可以使用 Query  API聚合并检索用户资料中的所有细分条目。需要强调的是，如果要使用排序键将资料数据进一步细分为具体层级，则应使用带有begins_with函数的键条件表达式，以匹配begins_with过滤器对各具体条目的细粒度访问。

用例：用户事件、点击流以及展示数据的存储

广告技术厂商需要将用户事件（例如点击与展示）存储在DynamoDB，以便按用户/时间组合进行快速访问。例如，在RTB平台的归因引擎里，DataXu公司就使用DynamoDB存储用户事件信息。之所以选择DynamoDB，是因为它是全托管且极具成本效益的服务，可根据DataXu的实际请求提供必要扩展以满足更高性能要求。在DynamoDB的支持下，该公司无需分神于扩展管理工作（例如添加节点）即可轻松将日均请求处理能力提高到数亿次之巨。

设计模式：用户事件以键-值对的形式进行存储（1：M建模模式），其中用户ID被作为分区键，时间戳被作为主键中的排序键。为了节约读取/写入容量，我们可以将数据以压缩方式保存。一般来讲，存储数据的保留周期是限定的，例如一个月。为了保证及时删除不必要的DynamoDB数据，厂商可以免费使用时间管理（TTL）功能自动清理掉标记为过期的数据。

用例：资源元数据存储

广告技术厂商还使用DynamoDB存储资源的各类元数据，包括图像、页面与链接等。例如，除了用户的个人资料之外，GumGum还在其广告定位平台中使用DynamoDB存储图像与页面元数据。他们的用例要求配备大型数据存储区，跨越位于多个地理边界的多处数据中心以较低的延迟处理高流量负载。GumGum之所以选择DynamoDB，是因为它不仅能够满足上述严苛要求，同时也带来良好的成本效益与无服务器架构，帮助开发者团队轻松扩展并维护这套广告业务平台。

再以移动营销与链接平台Branch为例，他们使用DynamoDB作为其深层链接平台上的数据库存储。这套平台旨在提供统一的解决方案，负责支持并管理产品网页中的深层链接并进行分析。该平台需要一套高性能、可扩展且可靠性的键-值数据库，由这套数据库存储数百亿条链接以及总量达数十TB的相关元数据。DynamoDB能够当选自然是因为它完全符合Branch的业务需求，并且具有良好的成本效益以及可预测的成本模型。作为一项全托管服务，DynamoDB还消除了Branch公司运维团队的日常工作负荷。

设计模式：用户将多种资源（包括页面、图像与深层链接）的元数据存储在DynamoDB表当中，并按资源类型进行分区（1：1建模模式）。

用例：高访问频率条目缓存

这种用例与之前提到的“资源元数据存储”用例密切相关。在DAX的支持下，DynamoDB获得了解决热数据读取峰值较低难题的能力，同时进一步降低了读取延迟。通过降低DynamoDB上的读取负载，DAX还可帮助用户降低由DynamoDB带来的服务成本。

设计模式：以Branch为例，他们的深度链接平台使用DynamoDB存储链接以及相关元数据，并通过DAX缓存更多新增的高频访问链接。相关数据被存储在按唯一链接ID分区的表当中，并以链接ID作为主键（1：1建模模式）。虽然在理论上，所有链接都应具备良好的访问速度，但必然有一部分链接有着比其他链接更高的访问频率与速度要求。这部分链接将被缓存在DAX当中，借此满足亚毫秒级的访问延迟，同时降低DynamoDB的读取负载及相应的运维成本。

总结

本文介绍了广告技术厂商使用DynamoDB的一些常见方式。若需了解AWS提供的广告技术解决方案的更多细节信息，请参阅AWS for Digital Marketing。您也可以在下方评论区中发表评论，或在DynamoDB论坛上创建新的讨论主题。

本篇作者