作业帮基于 StarRocks 画像系统的设计及优化实践( 二 ) 作者|作业帮大数据团队策划

文章图片
画像服务
画像服务核心能力有两个。第一个人群圈选能力，特点为内部系统qps不高，秒级返回。第二个单用户id规则判定能力，特点为qps很高， 10毫秒级返回。第二个不在本系统设计范围内，只说人群圈选部分，大体执行过程如下：
请求DSL参数解析及校验：将人群圈选DSL按标签拆分为多个独立的表达式和组合关系，然后根据标签配置信息补充隐含条件，同时校验每个表达式的合理性。
查询逻辑优化：标签同表存储时合并表达式，减少单表达式数据返回量加速查询速度。
表达式转SQL：根据抽象类型对应的查询模板，将优化合并后的表达式分别转化为多个子查询，然后结合组合关系形成整条SQL 。
执行SQL圈选人群。
建表语句及查询模板

文章图片
性能测试
（1）Profile+Agg测试
实时场景未采用PK主要因为不支持REPLACE_IF_NOT_NULL和局部列更新，标签间入库解耦需要此能力。性能测试如下：

文章图片
结论1：测试1/2可知查询耗时点为Fragment1阶段Scan操作含Merge-on-Read过程[OLAP_SCAN_NODE]、to_bitmap[PROJECT_NODE]、bitmap_union[AGGREGATION_NODE] ，而Fragment0阶段因数据量很少所以耗时很少。
结论2：测试2/3对比考虑优化Scan耗时。增加bucket数量后， Scan耗时明显下降。 tablet数量增加引起scan并行度提高。 doris_scanner_thread_pool_thread_num默认48 ， tablet数量调整前后为5->25均在此范围内，除profile信息外还可以通过Manager查看对应时间Scan相关监控。可根据集群负载情况适当增加线程数用于提高查询速度。
结论3：测试3/5对比考虑优化bitmap_union耗时并兼顾写负载平衡。采用Rangeguid分区， 5kw一个步调， bucket设为5 。每个tablet大约1kw数据量且差值低于5kw ，避免部分guid活跃度高带来的单分区写热点问题。同为5160W+数据量bitmap_union耗时减少约700ms 。
结论4：测试3/4对比考虑加上where条件后的查询耗时表现，因返回数据量降低一个数量级bitmap_union(to_bitmap(guid))耗时明显减少，性能瓶颈主要表现在Scan阶段。因增加where条件后多扫描了grade列，增加耗时部分主要消耗在此列的数据扫描和merge过程，暂无较好优化方式。
（2）Fact+Dup测试
实时场景Fact+Agg/Uniq和Profile+Agg情况差不多，相关优化可结合上边结论。针对离线场景Fact+Dup模型测试数据如下：

文章图片
结论1：测试1/2可知查询耗时点为：
Scan过程[OLAP_SCAN_NODE] 。
两阶段groupbyguid[Fragment2AGGREGATION_NODE和Fragment1的第一个AGGREGATION_NODE] 。 groupby耗时主要为HashTable构建时间含count(1)结果更新，本质取决于scan返回数据条数以及HashTableSize大小。
to_bitmap[Fragment1的第一个PROJECT_NODE]和bitmap_union[Fragment1的第二个AGGREGATION_NODE]算子，总体优化思路见上边测试结论。结论2：测试2/3分析无论是否增加bitmap索引，查询都有一定程度的下推到存储层【simdfilter】，增加bitmap索引但未应用，因区分度太低而不走bitmap索引【过滤条件枚举值数量/总数据条数
结论3：[推测未做测试]针对测试1DUPLICATEKEY(guid),DISTRIBUTEDBYHASH(guid) ，如果不用guid作为排序列和分桶使数据分布均匀那么会因为每个节点都有全部guid导致HashTableSize基本为现在节点的5倍，进而影响查询耗时会更长。