Starrocks的Bitmap在用户人群中的应用

背景
Starrocks & Bitmap介绍
Bitmap应用在用户人群的优势
设计方案
数据流
Bitmap 常用函数介绍
宽表 VS Bitmap

背景

      智能运营平台本是为各品牌商提供用户画像、用户分群、数据报表、邮件服务、App Push、App 弹窗、App Banner 、线上答卷等一系列运营工具，帮助品牌商提升用户的 IoT 设备使用体验、提高 App 用户粘性、提升产品销量。
      平台发布两年来已服务海内外较多KA客户，客群日益增长之下，自身的功能、服务以及客户诉求也日益多样化、复杂化，平台也从一个营销工具逐渐平台化、产品化。与此同时，团队面临的挑战也逐步扩大，原本基于Spark+Clickhouse的基础服务也越发的不堪重负，成本增长的同时，客户体验以及平台功能却在不断减弱，实际损耗远高于回报。
      结合当前业务与技术的诸多痛点，在对业内竞品以及当下前瞻技术调研中，逐渐深入探索了基于Starrocks的bitmap方案，最终于今年年底正式落地交付使用。

Starrocks & Bitmap介绍

      Starrocks是一个分布式列式存储和分析系统，旨在处理大规模数据集。
      Bitmap（位图）是Starrocks数据库中一种用于高效存储和处理大规模数据的压缩数据结构。
      在Starrocks中，Bitmap通常用于解决多维度数据的过滤和聚合问题。它通过使用针对位图的位运算，从而提供了高性能的筛选和聚合操作。Bitmap可以理解为一个由位组成的二进制向量，其中每个位对应于一条数据记录的某个属性。使用Bitmap进行数据过滤和聚合操作时，可以通过位运算（如并、交、异或）高效地对数据进行筛选和组合。位图压缩技术还可以减少存储空间的使用，提高查询性能。
       在Starrocks中，Bitmap常用于处理大规模数据的快速过滤、数据预聚合和多维度分析等场景，可以大大提高数据处理的效率和性能。
      综上所述，Starrocks中的Bitmap是一种用于高效存储和处理大规模数据的压缩数据结构，通过位运算实现高性能的数据过滤和聚合操作，在Starrocks数据库中被广泛应用于多维度数据处理和分析。

Bitmap应用在用户人群的优势

      用户人群普遍推荐使用 Bitmap（位图）的原因是因为 Bitmap 能够有效地解决某些数据处理问题，具有以下优点：
      1.节省存储空间：Bitmap 使用位的方式表示数据集中的存在与否，比如在大规模数据集中，标记一个用户是否满足某个条件，而不需要存储实际的数据内容，从而节省了存储空间。
      2.快速过滤：Bitmap 可以在常量时间内（O(1)）进行数据过滤操作，即可以快速确定某个用户是否满足某个条件，例如判断某个用户是否属于某个特定年龄段或者某个地理区域。
      3.快速计算交集和并集：Bitmap 可以高效地进行交集和并集操作，即可将两个或多个 Bitmap 进行逻辑运算，从而得到包含满足整体条件的用户集合。这对于倒排索引、数据集合的合并等场景非常有用。
      4.简单高效：Bitmap 算法实现简单，具有高效的计算性能和查询速度。
      然而，需要注意的是，Bitmap 适用于处理稀疏数据，如果数据比较密集或者范围较大，可能会导致 Bitmap 的存储和计算开销过大。因此，在应用 Bitmap 时需要根据具体情况进行评估和选择合适的算法和数据结构。
      总结来说，用户人群推荐使用 Bitmap 是因为它可以在存储和计算效率上提供优势，并且适用于处理稀疏数据的情况。

设计方案

      在设计架构与产品选型上，也经历了一个较大的版本迭代，当下也从Clickhouse的方案迁移到了Starrocks上。
在这里插入图片描述
      行为日志：数据来自Web、App、服务端埋点日志上报至Kafka，通过Pipeline+Transform采集至离线数仓
用户画像：主要来自各端业务数据的基本信息采集、基础数据统计
方案对比：
      1、早期采用Clickhouse的时候，也调研过Bitmap的方案，从Spark到Clickhouse的bitmap生成对CPU和内存的消耗颇大，在极致的成本管控下，对亿级体量的用户数据无法转化，以至于当时只能通过Clickhouse高效的查询性能用大宽表的方式满足基本功能。在对业务进行有效裁剪，在对比成本（资源成本、开发成本、学习成本、维护成本）后，决定使用Starrocks替换Clickhouse，且在Starrocks端完成Bitmap的转化。
      2、基于大宽表的查询生成人群对服务器的资源消耗也颇高，尤其Clickhouse基本上是以Cpu满负载的方式提效，在高并发高QPS的情况下服务器极端不稳定，满足不了即查即用的功能场景，不得以将人群包的规则转化成HiveSQL的方式，每天通过离线数仓的批计算循环处理生产离线人群包同步到ES，供平台使用。导致业务极度依赖离线数仓，当人群越来越多，高至上千的时候，每天需要上千个SQL任务，不仅占用离线集群的大量资源，且时效性也越发的没有保障，还徒增了冗余存储、ES的成本。在Starrocks端，通过转化bitmap查询，对资源的消耗较低，且QPS、性能都能满足业务诉求。
      3、Clickhouse & Starrocks综合对比
      整体上Clickhouse查询并发能力弱，在多表join的场景下，基本上是战五渣，且社区活跃度相对较低，日常运维难度较大、成本较高，且其底层原理无法保障数据的一致性，相对于Clickhouse欠缺的地方，Starrocks的优势刚好做了如下补充：
● ⽀持多并发查询；
● ⽀持 Shuffle Join，Colocate Join 等多种分布式 Join ⽅式，多表关联性能更优；
● ⽀持事务性的 DDL 与 DML 操作，兼容 MySQL 协议；
● FE、BE 架构简单，不依赖外部组件，运维更加简单；
● 数据⾃动均衡，集群随业务增⻓⽔平扩展⽅便。
      4、Clickhouse VS Starrocks性能测试
      两者之间的性能测试，本文不做具体描述，简而言之，在单表查询上两者不相伯仲，但是如上所诉，在多表Join以及多并发场景上，Starrocks明细占优势。

数据流

在这里插入图片描述
目前版本主要还是以离线的方式为业务提供数据，在离线数仓完成用户画像标签与用户行为日志，然后将数据同步到Starrocks完成Bitmap的转化。

Hive的用户画像表（user_profile）

CREATE EXTERNAL TABLE IF NOT EXISTS  user_profile
(uid string  COMMENT '用户id' ,
appId bigint  COMMENT 'app id' ,
tag1 string  COMMENT '标签1' ,
tag2 bigint  COMMENT '标签2' ,
tag3 decimal(38,4)  COMMENT '标签3' ,
......
tag198 string  COMMENT '标签198' ,
tag199 bigint  COMMENT '标签199' ,
tag200 decimal(38,4)  COMMENT '标签200'
) 
COMMENT '商业版c端用户画像应用表'
PARTITIONED BY ( 
 `dt` string  COMMENT '按天分区'  
)

Hive的用户行为标签表（user_action_tags）

CREATE EXTERNAL TABLE IF NOT EXISTS  user_profile
(uid string  COMMENT '用户id' ,
appId bigint  COMMENT 'app id' ,
eventCode string  COMMENT '用户行为事件' ,
tagType string  COMMENT '标签类型' ,
tagValue string  COMMENT '标签值' 
) 
COMMENT '商业版c端用户画像应用表'
PARTITIONED BY ( 
`dt` string  COMMENT '按天分区'  
)

Starrocks的用户画像标签unnest类表

CREATE TABLE `user_profile_unnest_{dataType}` (
  `u_id` bigint(20) not NULL COMMENT '用户自增id主键',
  `tag_type` varchar(50) not NULL DEFAULT '' COMMENT '标签名',
  `tag_value` BIGINT not NULL DEFAULT '0' COMMENT '标签值-字段类型与dataType 保持一致',
) ENGINE=OLAP

Starrocks的用户画像标签bitmap类表

CREATE TABLE `bitmap_user_profile_{dataType}` (
  `dt` int(11) not NULL COMMENT '日期分区',
  `tag_type` varchar(50) not NULL DEFAULT '' COMMENT '标签名',
  `tag_value` BIGINT not NULL DEFAULT '0' COMMENT '标签值-字段类型与dataType 保持一致',
  `uid_bitmap` bitmap NOT NULL COMMENT 'uid bitmap'
) ENGINE=OLAP

Starrocks的用户行为标签unnest表

CREATE TABLE `user_action_unnest` (
  `dt` int(11) not NULL COMMENT '日期分区',
  `u_id` bigint(20) not NULL COMMENT '用户自增id主键',
  `app_id` bigint(20) not NULL COMMENT 'appid',
  `event_code` bigint(20) not NULL COMMENT '行为事件编码',
  `tag_key` varchar(50) not NULL COMMENT '',
  `tag_value` string NULL COMMENT ''
) ENGINE=OLAP

Starrocks的用户行为标签bitmap表

CREATE TABLE `bitmap_user_action` (
  `dt` int(11) not NULL COMMENT '日期分区',
  `app_id` bigint(20) not NULL COMMENT 'appid',
  `event_code` bigint(20) not NULL COMMENT '行为事件编码',
  `tag_type` varchar(50) not NULL DEFAULT '' COMMENT '标签名',
  `tag_value` BIGINT not NULL DEFAULT '0' COMMENT '标签值',
  `uid_bitmap` bitmap NOT NULL COMMENT 'uid bitmap'
) ENGINE=OLAP

用户画像标签在做Bitmap转化的过程中会根据标签值的数据类型进行拆分，当下仅使用字符串（String）、整型（Bigint）、精度类型（Decimal）。行为标签是根据日志埋点平台定义的参数，日志以Json格式存储，当前仅使用字符串类型。因业务平台支持导入第三方用户进行营销，所以基于uid的自增id的过程放在了Starrocks端，行为日志仅支持内部APP用户，离线数仓处理完Unnest表后，直接同步到Starrocks端，关联uid_mapping获取u_id。

Bitmap 常用函数介绍

以下在业务场景中使用较为频繁，更多函数详见官方文档。
在这里插入图片描述

宽表 VS Bitmap

在这里插入图片描述