如何通过 Cloud Bigtable 扩大广告个性化规模

Cloud Bigtable是一种流行且广泛使用的键值数据库。该服务提供规模弹性、成本效率、出色的性能特征和 99.999% 的可用性 SLA。大量客户采用并信任 Bigtable 来运行他们的各种关键任务工作负载。


Bigtable 已在 Google 持续生产使用超过 15 年。它在峰值时每秒处理超过 50 亿个请求,并且管理着超过 10 EB 的数据,是谷歌最大的半结构化数据存储服务之一。


Bigtable 的关键用例之一是广告个性化,这篇文章描述了 Bigtable 在广告个性化中扮演的核心角色。


广告个性化


广告个性化旨在通过呈现主题和相关的广告内容来改善用户体验。例如,你经常在 YouTube 上观看制作面包的视频,如果在广告设置中启用了广告个性化,观看历史可能会向 YouTube 表明你有兴趣将烘焙作为一个主题,并且可能会对与烘焙产品相关的广告内容感兴趣


广告个性化需要近乎实时的大规模数据处理,以便及时个性化,并对用户数据处理和保留进行严格控制。系统可用性需要很高,并且服务延迟需要很低,因为需要在狭窄的窗口内决定检索和提供哪些广告内容。次优的服务决策(例如退回到通用广告内容)可能会影响用户体验,广告经济学要求将基础设施成本保持在尽可能低的水平。


谷歌的广告个性化平台提供了开发和部署机器学习模型的框架,用于广告内容的相关性和排名,并支持支持实时和批量个性化。该平台使用 Bigtable 构建,允许 Google 产品以符合隐私和政策的安全方式访问数据源以进行广告个性化,同时尊重用户关于他们希望向 Google 提供哪些数据的决定。


个性化管道的输出(例如广告配置文件)存储回 Bigtable 以供进一步使用,广告服务堆栈检索这些广告配置文件以推动下一组广告服务决策。


个性化平台的一些存储要求包括:

  • 非常高的批量访问和近乎实时的个性化
  • 在广告投放的关键路径上查找读取的低延迟(在 p99 时小于 20 毫秒)
  • 快速(即以秒为单位)增量更新广告模型,以减少个性化延迟


Bigtable


Bigtable 在支持低成本、高吞吐量的离线个性化数据访问以及一致的低延迟在线数据服务访问方面的多功能性使其非常适合广告工作负载。


Google 规模的个性化需要非常大的存储空间,Bigtable 满足给定性能曲线所需的可扩展性、性能一致性和低成本是这些工作负载的关键区别。


数据模型

个性化平台将对象存储在 Bigtable 中,作为由对象 ID 键入的序列化 protobuf。在 p99 时,典型数据大小小于 1 MB,服务延迟小于 20 毫秒。


数据被组织为语料库,以对应不同的数据类别,语料库将映射到复制的 Bigtable。在语料库中,数据被组织为 DataTypes,即数据的逻辑分组。特征、嵌入和不同风格的广告配置文件存储为 DataTypes,映射到 Bigtable 列族。DataTypes 在描述数据的原型结构和指示所有权和出处的附加元数据的模式中定义。子类型映射到 Bigtable 列并且是自由格式的。


每行数据都由一个基于对象 ID 的 RowID 唯一标识。个性化 API 通过 RowID(行键)、DataType(列族)、SubType(列部分)和时间戳来识别各个值。


一致性

操作的默认一致性模式是最终的。在这种模式下,从离用户最近的 Bigtable 副本中检索数据,提供最低的中值和尾部延迟。


对单个 Bigtable 副本的读取和写入是一致的。如果一个区域有多个 Bigtable 副本,跨区域的流量溢出的可能性更大。为了提高写后读一致性的可能性,个性化平台使用行亲和性的概念。如果一个区域中有多个副本,则根据 Row ID 的哈希,优先为任何给定行选择一个副本。


对于一致性要求更严格的查找,平台首先尝试从最近的副本中读取,并请求 Bigtable 返回每个副本的当前低水位线 (LWM)。如果最近的副本恰好是发起写入的副本,或者如果 LWM 指示复制已赶上必要的时间戳,则服务将返回一致的响应。如果复制没有赶上,那么服务会发出第二次查找——这次查找的目标是写入发起的 Bigtable 副本。该副本可能很远,请求可能很慢。在等待响应时,平台可能会向其他副本发出故障转移查找,以防复制赶上这些副本。


Bigtable 复制

广告个性化工作负载使用具有 20 多个副本的 Bigtable 复制拓扑,分布在四大洲。复制有助于解决广告服务的高可用性需求。Bigtable 的区域每月正常运行时间百分比超过 99.9%,复制加上多集群路由策略允许超过 99.999% 的可用性。


跨越全球的拓扑允许将数据放置在靠近用户的位置,从而最大限度地减少服务延迟。然而,它也带来了挑战,例如网络链接成本和吞吐量的可变性。Bigtable 使用基于最小生成树的路由算法和节省带宽的代理副本来帮助降低网络成本。


对于广告个性化,减少 Bigtable 复制延迟是降低个性化延迟的关键。首选是更快的复制,但我们还需要平衡服务流量与复制流量,并确保低延迟用户数据服务不会因传入或传出复制流量而中断。在底层,Bigtable 实现了复杂的流量控制和优先级提升机制来管理全局流量并平衡服务和复制流量的优先级。


工作负载隔离

广告个性化批量工作负载通过将一组给定的工作负载固定到某些副本上而与服务工作负载隔离;一些 Bigtable 副本专门驱动个性化管道,而另一些则驱动用户数据服务。该模型允许在服务系统和离线个性化管道之间建立连续且近乎实时的反馈循环,同时防止两个工作负载相互竞争。


对于 Cloud Bigtable 用户,AppProfiles 和集群路由策略提供了一种将工作负载限制和固定到特定副本以实现粗粒度隔离的方法。

数据驻留

默认情况下,数据会复制到每个副本(通常分布在全球范围内),这对于仅在区域内访问的数据来说是一种浪费。区域化通过将数据限制在最有可能被访问的区域来节省存储和复制成本。遵守规定与某些主题有关的数据物理存储在给定地理区域内的法规也很重要。


数据的位置可以由请求的访问位置或通过位置元数据和其他产品信号隐式确定。一旦确定了用户的位置,它就会存储在位置元数据表中,该表指向读取请求应路由到的 Bigtable 副本。基于行放置策略的数据迁移发生在后台,没有停机时间或服务性能回归。


总结


在过去十年中,Bigtable 的规模随着 Google 的个性化需求增长了几个数量级而扩展。对于大规模个性化工作负载,Bigtable 提供具有出色性能特征的低成本存储。它通过简单的用户配置无缝处理全球流量,并由于它易于处理低延迟服务和高吞吐量批处理计算,成为 lambda 样式数据处理管道的绝佳选择。


———

WebEye是中国大陆地区首家获得 Google Cloud MSP 资质的合作伙伴。WebEye致力于用创新的技术向中国企业提供数字化效率创新服务,实现数字化赋能。我们不断帮助客户打造新的运营与协作方式,打造新的竞争优势,构建资源高效链接,共创价值生长空间。

WebEye整合全球资源,打造全球数字化营销体系,为企业提供营销增长服务营销增长引擎以及企业上云三大板块业务,涵盖数字营销、数字创意、游戏发行、流量变现、程序化广告、数据洞察、云计算等一站式全链条增长产品矩阵,是中国互联网出海领军企业。

返回全部