差异化广告现如今已越来越成为外贸人士留住消费者的主要手段之一，不论是内容属性还是投流等…当客户收到根据他们喜好量身定制的广告时，更容易激发他们的身份象征意识。此外，差异化广告也帮助商户与客户建立忠诚度并推动回头客的生成。数据显示，差异化广告可以增加高达 30% 的销售额。Google Cloud Bigtable 的关键用例之一正是谷歌广告的个性化定制。本篇文章将重点阐述如何在 Google 中使用 Bigtable 来支持一个重要的用例——为广告个性化建模用户意图，从而帮助您与您的团队发挥谷歌广告个性化定制的最大潜能。Google Cloud Bigtable 知识点
Cloud Bigtable 是一种流行且广泛使用的键值数据库，可在 Google Cloud 上使用。该服务提供规模弹性、成本效率、出色的性能特征和 99.999% 的可用性 SLA。在过去十年中，Bigtable 凭借出色性能特征的低成本存储，成为 lambda 式数据处理管道的绝佳选择，也是成千上万客户的信任之选。
Bigtable 已在 Google 持续生产使用超过 15 年。它在峰值时每秒处理超过 50 亿个请求，并且管理着超过 10 EB 的数据。它是 Google 最大的半结构化数据存储服务之一。
01 广告个性化
广告个性化旨在通过呈现主题和相关的广告内容来改善用户体验。例如，我经常在 YouTube 上观看制作面包的视频。如果在我的广告设置中启用了广告个性化，我的观看历史可能会向 YouTube 表明我有兴趣将烘焙作为主题，并且可能会对与烘焙产品相关的广告内容感兴趣。
广告个性化需要近乎实时的大规模数据处理，以便及时个性化，并对用户数据处理和保留进行严格控制。
系统可用性需要很高，并且服务延迟需要很低，因为需要在狭窄的窗口内决定检索和提供哪些广告内容。次优的服务决策（例如退回到通用广告内容）可能会影响用户体验。
谷歌的广告个性化平台提供了开发和部署机器学习模型的框架，用于广告内容的相关性和排名。该平台支持实时和批量个性化。该平台使用 Bigtable 构建，允许 Google 产品以符合隐私和政策的安全方式访问数据源以进行广告个性化，同时尊重用户关于他们希望向 Google 提供哪些数据的决定。
个性化管道的输出（例如广告配置文件）存储回 Bigtable 以供进一步使用。广告服务堆栈检索这些广告配置文件以推动下一组广告服务决策。
个性化平台的一些存储要求包括：
1、非常高的批量访问和近乎实时的个性化
2、在广告投放的关键路径上查找读取的低延迟（在 p99 时小于 20 毫秒）
3、快速（即以秒为单位）增量更新广告模型，以减少个性化延迟
02 Google Cloud 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 实现了复杂的流量控制和优先级提升机制来管理全局流量并平衡服务和复制流量的优先级。
工作负载隔离
对于 Cloud Bigtable 用户，AppProfiles 和集群路由策略提供了一种将工作负载限制和固定到特定副本以实现粗粒度隔离的方法。
数据驻留
默认情况下，数据会复制到每个副本（通常分布在全球范围内），这对于仅在区域内访问的数据来说是一种浪费。区域化通过将数据限制在最有可能被访问的区域来节省存储和复制成本。
数据的位置可以由请求的访问位置或通过位置元数据和其他产品信号隐式确定。一旦确定了用户的位置，它就会存储在位置元数据表中，该表指向应该将读取请求路由到的 Bigtable 副本。基于行放置策略的数据迁移发生在后台，没有停机时间或服务性能回归。
03 思想科技 Master Concept 能做什么？
看完这篇文章，相信您对 Bigtable 能够为广告差异化做出的改变已经有了全面的了解，想要进一步开启试用 - 欢迎直接联系我们，让我们知道您的想法。我们的团队渴望看到这些功能为您的出海业务开辟了哪些新的可能性。
