广告系统怎么用OLAP秒查10亿数据，性能和实操经验分享

（引用来源：知乎专栏“大数据技术与架构”文章《万亿数据下的OLAP引擎在广告场景的实践》）

广告系统要处理的数据量非常大,每天可能新增几十亿甚至上百亿的广告曝光、点击日志，市场团队或者产品经理经常需要快速查询这些数据，过去一周，来自北京地区、年龄在25-30岁的女性用户，对汽车类广告的点击率是多少？”，这种涉及多个维度（时间、地区、用户属性、广告类型）的随意组合查询，就是OLAP的典型场景，要秒查10亿级别的数据，核心在于“用空间换时间”和“预计算”。

（引用来源：腾讯云开发者社区技术博客《ClickHouse在腾讯广告的规模化应用》）

数据绝对不能按原样一条条存,想象一下，10亿条原始日志就像10亿张散落的名片，每次查询都要把所有名片翻一遍，肯定慢，第一步是数据预处理和聚合，在数据写入OLAP数据库之前，会先按照常见的查询维度进行一轮轻度的聚合，不是存每一笔点击记录，而是预先按1分钟、城市、广告位、广告计划等维度，把点击次数、曝光次数、消费金额等指标汇总好，这样，10亿行原始数据可能就被聚合成几千万甚至几百万行的“预聚合数据块”，查询时，数据库只需要扫描这些已经部分汇总好的数据块，计算量大大降低。

（引用来源：字节跳动技术团队分享《ByteHouse：基于ClickHouse的云原生数仓实践》）

选择合适的OLAP数据库引擎是关键，业内广告系统用得比较多的是ClickHouse，它有几个杀手锏很适合这种场景，一是列式存储，查询时不用读整行数据，只读取查询条件涉及到的列，比如查点击率就只读“点击数列”和“曝光数列”，I/O效率极高，二是数据压缩，因为同一列的数据类型相同，压缩比很高，能显著减少磁盘存储和读取的数据量，三是向量化执行引擎，它能一次性处理一整批数据（一个向量），而不是一行一行处理，充分利用了CPU的缓存和并行计算能力，这就像搬砖，一次搬一块和一次用推车搬一车，效率天差地别。

（引用来源：阿里云瑶池数据库峰会演讲《AnalyticDB在阿里妈妈广告分析中的实践》）

光有引擎还不够,表结构设计（建表）非常有讲究，这直接决定了查询性能的上限，常用的方法是使用“分区键”和“排序键”，分区键通常按时间分区，比如按天，查询指定日期范围时，引擎可以直接跳过不相关的分区，这叫“分区裁剪”，排序键则更精细，它决定了数据在分区内物理存储的顺序，应该把最常作为查询条件的列设为排序键的前几位，比如广告主ID、广告计划ID，这样，当查询指定某个广告主时，ClickHouse可以利用排序信息，只扫描这个广告主相关的数据块，实现“索引裁剪”，实操中，需要根据业务最频繁的查询模式来反复调整和优化排序键。

（引用来源：美团技术博客《OLAP在美团广告业务中的探索与实践》）

利用物化视图进一步加速，对于一些特别常用、但又无法通过简单预聚合满足的复杂查询，可以创建物化视图，物化视图可以理解为一个预先计算好的、更粗粒度的结果表，业务方经常要看每个广告计划在各省市分小时的表现，我们可以创建一个物化视图，数据写入时自动按小时、省市、广告计划维度聚合好指标，当用户发起这个模式的查询时，引擎会直接读取物化视图这个“成品”，速度极快，几乎毫秒级返回，但这会增加数据存储和写入时的计算开销，是一种典型的空间换时间的权衡，不能滥用。

（引用来源：上述多篇来源均提及的共性实操经验）

运维和监控是保证稳定性的生命线，在实操中，面对每天海量的数据写入和频繁的查询，系统会面临很大压力，需要做好几点：1）监控查询耗时，对慢查询进行优化或限制，避免一条烂SQL拖垮整个集群，2）设置资源队列，对不同优先级的查询任务分配不同的计算资源，保证核心报表的查询速度不受后台批量任务影响，3）数据写入采用批量提交，而不是单条插入，减少对数据库的请求次数，提升吞吐量，4）定期清理过期数据，释放存储空间。

广告系统要用OLAP秒查10亿数据,不是一个单点技术能解决的，而是一个系统工程，它需要从数据接入时的预处理、选择合适的列式数据库、精心设计表结构、到灵活运用物化视图等预计算技术，再配合完善的运维监控，各个环节协同作用，才能在高并发、大数据量的情况下，实现稳定高效的秒级查询响应。