火山引擎ByteHouse：一套方案，提升OLAP引擎在广告投放场景的性能

据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主要为用户提供极速分析体验，能够支撑实时数据分析和海量数据离线分析，具备便捷的弹性扩缩容能力，极致分析性能和丰富的企业级特性，目前已经与中国地震台网中心、海王集团、莉莉丝游戏、极客邦科技等诸多行业企业达成合作，深度助力各个行业数字化转型。