作者：火山引擎ByteHouse团队@孔柏林
由于流量红利逐渐消退，越来越多的广告企业和从业者开始探索精细化营销的新路径，取代以往的全流量、粗放式的广告轰炸。精细化营销意味着要在数以亿计的人群中优选出那些最具潜力的目标受众，这无疑对提供基础引擎支持的数据仓库能力，提出了极大的技术挑战。
本篇内容将聚焦字节跳动OLAP引擎技术和落地经验，以字节跳动内部场景为例，具体拆解广告业务的实现逻辑和业务效果。
广告精准投放场景
广告投放过程一般包含数据收集->数据整合->人群圈选->广告投放->反馈分析等关键流程，人群圈选是广告精准投放的关键步骤，它帮助确定广告目标受众，辅助投放平台根据不同受众和广告目标优化投放策略，提升广告收益；
人群预估
人群预估主要是根据一定的圈选条件，确认命中的用户数目。在广告精准投放过程中，广告主需要知道当前选定的人群组合中大概会有多少人，用于辅助判断投放情况进而确定投放预算，通常要求计算时间不能超过 5 秒。
广告投放
广告精准投放过程中遇到的问题与痛点：
1. 数据预估： 广告主需要对选定的人群组合进行预估，以便判断投放情况并确定投放预算。但人群包数据量多，基数大。平台的用户数上亿，仅抖音的 DAU 就几亿，抖音、头条对应的人群包在亿级别，早期的预估版本采用ElasticSearch，但由于数据过于庞大，只能采用1/10抽样存储，导致10%的误差，业务难以接受。
2. 查询性能： 广告主可以设定一个非常复杂的圈选条件，导致计算复杂（单次计算可能包含几百上千个人群包），Hive和ES等方案在处理大数据量时，查询速度会变得非常慢，如果需要查询某个广告主的所有用户，需要扫描整个用户库，而这个过程可能需要几分钟甚至几个小时，无法满足实时性要求。
3. 存储空间大： Hive和ES等方案需要额外的索引结构，导致存储空间变大，从而增加了存储成本。例如，如果需要对用户属性进行索引，就需要额外的存储空间来存储索引数据。
4. 不支持高并发： Hive和ES等方案在处理高并发请求时，容易出现性能问题，无法支持高效的广告投放。例如，如果同时有多个广告主需要查询用户信息，就可能会出现查询阻塞或响应延迟等问题。
5. 数据查询效率： 采用ClickHouse支持预估，但随着数据量的增长，ClickHouse在当前存储引擎的支持下也难以保证查询时间。这导致了数据查询效率的问题，影响了用户体验。
ByteHouse BitEngine方案
方案简介
新查询引擎
- 针对广告人群预估业务开发的新查询引擎，基于ClickHouse提供的MergeTree Family系列引擎，添加了新的bitmap64类型和一系列的相关聚合函数。BitEngine提供的bitmap64类型适合存储和计算大量的用户ID之间的关系；在广告人群预估业务中，bitmap64类型用于存储人群包数据，然后将人群包之间的交并补计算转化为bitmap之间的交并补，从而达到远超普通查询的性能指标。
实现步骤
创建一个bitmap64类型，可以将用户ID直接存储在bitmap中，提供一系列交并补的聚合计算，并且还希望可以充分利用多核CPU的并行计算能力，由此我们设计了BitEngine。示例如下
CREATE TABLE cdp.tag_uids_map (
tags String,
uids BitMap64 BitEngineEncode
)ENGINE = HaMergeTree('/clickhouse/xxxx/{shard}', '{replica}')
ORDER BY tag
tag_uids_map存储格式如下
| tag | uids |
|---|---|
| A | {10001,20001,30001,40001,50001,60001,70001,80001,90001} |
| B | {10001,20001,20002,20003,20004,20005,20006,20007,20008} |
要查询 A&B 的结果 SQL 为
SELECT bitmapCount('A&B') FROM tag_uids_map
