查询速度最高提升 50 倍！火山引擎 ByteHouse 在广告投放领域实践分享

更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

据 QuestMobile 报告显示，移动互联网已经进入了下半场，在使用人数和使用时长方面已经没有明显增长，互联网已经流量趋于饱和。

作为广告投放主要阵地，由于互联网平台流量红利逐渐消退，越来越多的广告企业和从业者开始探索精细化营销的新路径，取代以往的全流量、粗放式的广告轰炸。精细化营销意味着要在数以亿计的人群中优选出那些最具潜力的目标受众，这无疑对提供基础引擎支持的数据仓库能力，提出了极大的技术挑战。

在人群圈选分析中， 分析师一般利用各种标签组合，挑选出最合适的人群，进而完成广告推送，达到精准投放的效果。但由于人群查询在不同标签组合下的结果集大小不同，在一次广告投放中，分析师需要经过多次的逻辑调整，以获得"最好"的人群包。抖音集团拥有广泛的广告投放场景，在日常实践中，我们发现以下痛点问题：

• 首先，数据预估。广告主需要对选定的人群组合进行预估，以便判断投放情况并确定投放预算。但广告平台用户越来越多，有的平台 DAU 达到上亿，使得人群包数据量过大，技术上只能采用 1/10 抽样存储，将导致 10%误差。

• 其次，性能问题。为了保证人群圈选精准度，广告主往往会设定多样、复杂的人群圈选条件，导致底层计算逻辑复杂，比如单次计算可能包含几百，甚至上千个人群包。Hive 和 Elasticsearch 等方案在处理大数据量时，查询速度慢。如果研发人员查询某个广告主的所有用户，该方案需要扫描整个用户库，整个过程需要几分钟甚至几个小时，无法满足广告主实时性要求。

• 最后，存储问题。Hive 和 Elasticsearch 等方案需要额外的索引结构，使得存储空间变大，导致成本增加。

在以往，研发团队通常使用两种方案来解决以上问题：

方案一：将每个人群包存储为一个 Array 类型的数据结构，每次查询需要从 Array 中找到某一个特定 ID。

方案二：使用一个表来存储用户 ID，在查询的时使用 In/Join 计算多个人群的交集。

经过内部长期使用经验，无论是方案一或方案二，都存在当数据量逐渐增大，查询速度无法满足实时分析需求的问题。基于高性能、分布式特点，ClickHouse 可以满足大规模数据的分析和查询需求，因此研发团队以开源 ClickHouse 为基础，研发出火山引擎云原生数据仓库 ByteHouse，并在其中定制一套处理模型——BitEngine，用于解决集合的交并补计算在实时分析场景中的性能提升问题。

据介绍，BitEngine 是一个高效集合数据处理模型，底层基于 MergeTree Family 存储引擎，并在此基础上引入了 BitMap64 类型，开发了系列相关运算函数。BitEngine 提供的 BitMap64 类型适合表达具有特定关系的大量实体 ID 的集合，将集合的交并补运算转化为 bitmap 之间的交并补运算，从而达到远超普通查询的性能指标。

那么，BitEngine 如何应用在人群圈选场景中？举个例子，广告主需求为圈选出“人群包 A”和“人群包 B”的交集人群，完成广告精准投放。

人群包情况：

• 人群包 A = [10001, 20001，30001，40001，50001]，人群包 B = [10001, 20001，20002，20003，20004]

期望结果：

• 通过 BitEngine 计算 A&B = [10001, 20001]

首先，人群包按照一定规则划分为多个区间，任意两个区间之间的人群包没有交集，由 BitEngine 保障数据的读取和计算是严格按照区间进行；其次，BitEngine 在数据读取时会为每一个文件构建一个读任务，由一个线程调度模块完成整个任务调度和读取；最后，BitEngine 完成所有中间结果计算后，按照结果的输出要求做一次数据合并，由此完成交集计算。已上线业务的测试表明，相比普通和 Array 或者用户表方式，BitEngine 在查询速度上有 10-50 倍提升。

BitEngine 上线前后查询耗时监控

BitEngine 不仅仅在抖音集团海量广告投放场景中使用，目前更是集成在火山引擎云原生数据仓库 ByteHouse 中对外输出。火山引擎 ByteHouse 主要为用户提供极速分析体验，能够支撑实时数据分析和海量数据离线分析，具备便捷的弹性扩缩容能力，极致分析性能和丰富的企业级特性，目前已经与中国地震台网中心、海王集团、莉莉丝游戏、极客邦科技等诸多行业企业达成合作，深度助力各个行业数字化转型。

点击跳转火山引擎ByteHouse了解更多