Google Cloud郭斌:Cloud Bigtable在广告技术中的使用

时间:2021-10-21 01:00:51

  本文根据郭斌老师在【第十三届中国数据库技术大会(DTCC2022)】线上演讲内容整理而成。

   讲师介绍:

Google Cloud郭斌:Cloud Bigtable在广告技术中的使用

  郭斌,Google Cloud架构师,20年数据库技术实践经验,精通主流关系型数据库和NoSQL数据库,对各类新的数据库技术有着深入理解和实战经验。此前,曾就职于Elastic,MongoDB,Oracle,担任架构师、咨询工程师等工作。

   本文摘要:

  Google Cloud Bigtable是全托管可扩缩的NoSQL数据库服务,用于处理大规模分析和运营工作负载,可用性高达99.999%;延迟时间在10毫秒以内,每秒可处理数百万个请求,其技术非常适用于广告技术平台。本次演讲将以Bigtable在广告技术中的实际使用,带领大家领略Cloud Bigtable的风采。

   演讲正文:

   Cloud Bigtable的技术特点

  可能大多数人对HBase比较熟悉,但实际上是先有的Bigtable,再有的HBase,他们都是宽列NoSQL数据库,能够很好的实现横向扩展和降低延迟。

  为什么他们的性能这么好呢?因为,他们是以磁盘为支撑的内存数据库,通过观察他们的写入路径和读取路径,你会发现他们大部分的运算,特别是读的操作,都是在内存中完成。不仅如此,Bigtable还与HBase的API做了兼容。

  关于Bigtable的性能指标有两个维度:吞吐量和延迟。吞吐量方面针对批量数据处理的每秒扫描的数据量;延迟方面是参考处理用户请求的在线服务,例如点查或点写的延迟情况。

  这两个指标分别是面向批处理和实时访问的场景,这两个场景Bigtable都具有很大优势。Bigtable具有很好的横向扩展能力,随着性能需求的增加,Bigtable可以通过增加节点解决性能瓶颈。在日常使用过程中,用户会关注性能Spike的情况,根据我们的经验有以下两种可能:

  第一方面,表的主键rowkey是否合适?是否有热点?我们的rowkey一定要尽量分散,其中某些rowkey不会支持热点。第二方面,当我们有了数据之后,我们的数据是否分散?用户刚使用Bigtable时,数据较少,用到很多节点,但数据并没有打散,例如有4-5个节点,但实际工作的可能只有1-2个节点,这样就会带来性能瓶颈。

  解决上述问题,可能有几种方式:第一,通过预先的加载,促使数据产生更多分片,把数据分的更散;第二,采用预分片技术,通过创建预分片的table,把数据进行指定数量的分片。

  关于Bigtable在处理性能扩容方面,还具备很多特点:Bigtable做得比较好的地方是计算和存储是彻底分离的,数据是保存在分布式文件系统上,计算节点是一个没有状态的,它不真正的拥有数据,它只是和某些数据产生关联,这样的好处是扩容和缩容都非常简单,数据是不需要发生拷贝的,只需要关联到一个新的节点。

  Bigtable还有哪些独特的地方呢?Bigtable可以支持全球分布,我可以建立一个实例,下面可以有若干集群,这些集群可以分布到不同地区,数据可以自动同步,我们称之为全球复制,数据在不同地区同时可读可写。

  我们如何访问数据呢?我们可以通过App profile功能访问不同区域的数据库或集群。不仅如此,在扩缩容方面,Bigtable可以按照一定的指标,自动的对数据库节点进行增加或缩减。

  Bigtable和HBase对比来看,Bigtable是一个全托管数据库,用户直接使用即可,不需要关注底层配置和运维,但Bigtable没有二级索引功能。

  对于开发者来说,使用它们两者有哪些区别呢?Bigtable是云原生数据库,它使用的IAM认证。

Google Cloud郭斌:Cloud Bigtable在广告技术中的使用

   Bigtable在广告技术中的实际应用

Google Cloud郭斌:Cloud Bigtable在广告技术中的使用

(source:)

  在数字广告方面有实时竞价系统,以上图为例,最左边Advertiser是广告主,他会借助DSP来投放平台,最右侧是Publisher,他会通过SSP告诉广告交换平台,我这边有很多流量,可以告知广告主投放。

  例如,我打开一个网页,有一个广告位,但是这里放什么广告,这是需要去实时竞价的,并且需要在100毫秒之内做出决策,这当中,Bigtable可以发挥巨大作用。

  当我受众打开网页时,我们会发出一个竞价请求,请求通过SSP发到了Ad Exchange中,我们需要实时竞价,看这个请求来源于哪个客户,分析投哪个广告合适。

  在数字广告实时竞价场景中,有三个方面,Bigtable有很好的发挥:

  用户匹配:难点是,我们如何找到这个用户,并与其匹配对应的广告。我们有不同的用户识别方法。例如从网络浏览器,使用cookie同步、匹配表,可以在SSP、DSP、DMP等之间使用,Bigtable非常适合此类工作负载。

  用户画像:快速查找提取用户以供选择,根据用户与广告、他们访问的网站或他们的行为的交互。

  机器学习:我们在实时广告推荐的过程中,需要掌握并运用机器学习内容来进行广告的各类优化。

  我们如何识别用户?分为两个端:第一,网页浏览器端,AdTech公司使用第三方cookie和cookie同步以识别不同网站的用户。Cloud Bigtable上的Cookie匹配表用于这个目的。

  第二,移动设备端,提供设备的广告ID(例如IDFA和AID),但隐私设置允许用户阻止公司收集他们的广告信息。

  如何维护实时用户?Cloud Bigtable是一个分布式低延迟NoSQL作为用户存储,用户存储包含特定用户的关联性,用作投标的输入决策逻辑。广告商使用受众群体来定位用户跨网络和移动平台。

  如何进行实时预测?实时预测是机器学习对数字广告的推动,预测模型如何产生、实时预测需要在线特征值输入,最后产生预测结果。模型是通过采集用户在网站上的行为,收集完之后存储到BigQuery中进行训练,而Bigtable可以作为线上的Feature lookup。