1. 项目概述为什么我们需要更精准的计数在数据仓库和实时分析领域精确统计用户数、设备数这类“唯一值”是一个高频且核心的需求。你可能经常听到“日活跃用户DAU”、“月活跃用户MAU”这样的指标它们的本质就是基于用户ID的去重计数。在Apache Doris这类MPP分析型数据库中我们通常会用COUNT(DISTINCT user_id)来实现。这个方法简单直观但在面对海量数据比如数亿甚至数十亿级别的用户ID时它的性能瓶颈会非常明显。COUNT(DISTINCT)在分布式计算中需要将数据打散Shuffle到一个节点上进行全局去重和聚合这个过程会产生巨大的网络传输开销和单点计算压力查询耗时可能从几秒飙升到几分钟严重影响了实时分析的体验。于是Bitmap位图技术就成为了解决这一痛点的利器。它不是Doris的独创但在Doris中通过高效的函数和聚合模型得到了极佳的实现。简单来说Bitmap将一个巨大的整数集合比如用户ID压缩成一个比特位数组。每个比特位代表一个整数如果该整数存在则对应位为1否则为0。最终我们只需要统计这个位图中“1”的个数就能得到去重后的总数。这种方法的空间利用率和计算效率在处理稀疏的大整数集时远超传统的哈希去重。最近在处理一个用户行为日志分析项目时我就深刻体会到了这一点。我们的用户ID是十亿级别的BIGINT类型按天分区存储。最初使用COUNT(DISTINCT)查询每日去重用户数在数据量大的分区需要近一分钟。在引入Bitmap方案后同样的查询被稳定优化到了5秒以内并且支持了更复杂的多日去重合并计算如7日去重用户数。这不仅仅是性能的提升更是为业务提供了更灵活、更强大的数据分析能力。接下来我就结合这次实战拆解如何在Apache Doris中玩转Bitmap函数实现精准且高效的去重。2. Bitmap去重的核心原理与Doris实现要用好Bitmap不能只停留在“调用函数”的层面理解其底层原理和Doris的实现方式能帮助我们在模型设计、资源调优时做出更正确的决策。2.1 Bitmap的数学与存储本质Bitmap的核心思想是用位Bit来标记存在性。假设我们有一个取值范围在[0, 7]的用户ID集合 {1, 3, 5}。我们可以用一个长度为8比特的位图来表示它比特位下标0 1 2 3 4 5 6 7对应值 0 1 0 1 0 1 0 0这样统计“1”的个数即bit_count为3就是去重后的用户数。其优势在于空间效率存储一个整数如8字节的BIGINT需要64位而Bitmap中标记它只需要1位。对于稀疏但范围集中的整数集压缩比极高。计算效率集合的交AND、并OR、差ANDNOT操作可以转换为比特位的逻辑运算CPU利用SIMD指令集能极快地并行处理。精确性与HyperLogLog等概率性数据结构不同Bitmap提供的是100%精确的基数统计。在Doris中Bitmap对象并不是直接存储为原始的比特位数组。Doris使用了Roaring Bitmap这种优化的数据结构。Roaring Bitmap将32位整数范围Doris的Bitmap函数主要针对INT和BIGINT划分为多个桶Container每个桶根据内部数据的稀疏程度选择用位图Bitmap Container还是数组Array Container来存储。这种混合结构使得它在各种数据分布下都能保持高性能和低内存占用避免了传统位图在数据极度稀疏时如只存储一个很大的数的空间浪费。2.2 Doris中的Bitmap类型与聚合模型Doris为Bitmap提供了原生支持主要体现在两种方式BITMAP类型这是一种实际的列数据类型。你可以在建表时定义一列的类型为BITMAP并使用BITMAP_UNION()聚合函数。这通常用于明细模型或聚合模型的表是进行预聚合的最佳实践。-- 在聚合模型中使用BITMAP列预存用户ID集合 CREATE TABLE user_visit_bitmap ( dt DATE, page VARCHAR(50), user_id_bitmap BITMAP BITMAP_UNION ) AGGREGATE KEY(dt, page) DISTRIBUTED BY HASH(dt, page) BUCKETS 10;向这张表插入数据时需要先将整型的user_id转化为BitmapINSERT INTO user_visit_bitmap VALUES (2023-10-27, homepage, BITMAP_FROM_STRING(1,3,5)); -- 或者从查询构建 INSERT INTO user_visit_bitmap SELECT 2023-10-27, homepage, BITMAP_FROM_ARRAY(ARRAY[1,3,5]);查询时直接使用BITMAP_UNION_COUNT(user_id_bitmap)即可获得全局去重数。Doris会在后台自动进行Bitmap的合并计算。Bitmap聚合函数针对存储在INT或BIGINT列中的原始ID数据Doris提供了一系列聚合函数如BITMAP_UNION(TO_BITMAP(user_id))。这更适用于对已有表的即席查询无需改变表结构。-- 在原始明细表上直接计算 SELECT COUNT(DISTINCT user_id) as cnt_distinct, BITMAP_UNION_COUNT(TO_BITMAP(user_id)) as cnt_bitmap FROM user_visit_detail WHERE dt 2023-10-27;两者结果一致但BITMAP_UNION_COUNT在分布式计算中会先在每个节点本地构建并聚合Bitmap然后只传输压缩后的Bitmap中间结果到FE进行最终合并大幅减少了网络传输量。实操心得模型选择策略如果你的去重查询模式固定且频繁如每日DAU报表强烈建议使用聚合模型BITMAP列进行预聚合。数据导入时即完成去重计算查询速度极快消耗资源极少。 如果你的分析需求灵活多变需要基于各种维度组合进行即席去重查询那么使用明细模型Bitmap函数更为合适虽然每次查询需要计算但灵活性最高。在实际项目中我们常常会采用“分层建设”的思路明细层存放原始数据轻度汇总层使用Bitmap预聚合常用维度应用层直接查询汇总层兼顾灵活与性能。3. 从入门到精通Bitmap函数实战解析了解了原理我们进入实战环节。Doris提供了丰富的Bitmap函数掌握它们的关键在于理解其输入输出和适用场景。3.1 基础构造与聚合函数这是最常用的函数簇用于构建Bitmap并计算基数。TO_BITMAP(INT_COL)/BITMAP_FROM_ARRAY(ARRAY[INT...])将整数或整数数组转化为一个Bitmap对象。这是所有Bitmap操作的起点。-- 将单个值转为Bitmap (通常用于INSERT或测试) SELECT TO_BITMAP(10086); -- 将数组转为Bitmap非常实用 SELECT BITMAP_FROM_ARRAY([1,2,3,2,1]); -- 结果Bitmap包含 {1,2,3}自动去重BITMAP_UNION(BITMAP_COL)聚合函数用于将多行数据的Bitmap合并为一个全局Bitmap。通常与BITMAP_UNION_COUNT联用但也可以单独使用以获取中间结果。BITMAP_UNION_COUNT(BITMAP_COL)最核心的去重函数。它先执行BITMAP_UNION然后计算合并后Bitmap的基数即去重总数。等价于BITMAP_COUNT(BITMAP_UNION(BITMAP_COL))。-- 计算每日去重用户数 SELECT dt, BITMAP_UNION_COUNT(TO_BITMAP(user_id)) as daily_uv FROM user_visits GROUP BY dt ORDER BY dt;BITMAP_COUNT(BITMAP)标量函数计算单个Bitmap的基数。常用于对已经聚合或构建好的Bitmap进行统计。-- 假设我们已经有一个存储了某页面用户集的Bitmap列 user_set SELECT page, BITMAP_COUNT(user_set) as uv FROM page_agg_table;3.2 集合运算函数Bitmap的强大之处在于支持高效的集合运算用于计算交集、并集、差集等复杂场景例如计算“留存用户”、“新增用户”。BITMAP_AND(BITMAP, BITMAP)返回两个Bitmap的交集。-- 计算昨天和今天都访问过的用户次日留存 SELECT BITMAP_UNION_COUNT( BITMAP_AND( TO_BITMAP(today.user_id), TO_BITMAP(yesterday.user_id) ) ) as retained_users FROM user_visits today JOIN user_visits yesterday ON today.user_id yesterday.user_id WHERE today.dt 2023-10-27 AND yesterday.dt 2023-10-26;但上述写法效率不高更优的做法是先按天聚合出BitmapWITH daily_bitmap AS ( SELECT dt, BITMAP_UNION(TO_BITMAP(user_id)) as uid_bitmap FROM user_visits WHERE dt IN (2023-10-26, 2023-10-27) GROUP BY dt ) SELECT BITMAP_COUNT( BITMAP_AND( MAX(CASE WHEN dt2023-10-27 THEN uid_bitmap END), MAX(CASE WHEN dt2023-10-26 THEN uid_bitmap END) ) ) as retained_users FROM daily_bitmap;BITMAP_OR(BITMAP, BITMAP)返回两个Bitmap的并集。BITMAP_UNION本质上是多行的BITMAP_OR聚合。-- 计算最近7天的去重用户数7日活跃 SELECT BITMAP_UNION_COUNT(uid_bitmap) as wau FROM ( SELECT BITMAP_UNION(TO_BITMAP(user_id)) as uid_bitmap FROM user_visits WHERE dt 2023-10-21 AND dt 2023-10-27 ) t; -- 更简洁的写法Doris的聚合函数会自动处理 SELECT BITMAP_UNION_COUNT(TO_BITMAP(user_id)) as wau FROM user_visits WHERE dt 2023-10-21 AND dt 2023-10-27;BITMAP_ANDNOT(BITMAP, BITMAP)返回第一个Bitmap有而第二个Bitmap没有的元素差集。-- 计算今天新增的用户今天有昨天没有 WITH bitmap_today AS ( SELECT BITMAP_UNION(TO_BITMAP(user_id)) as bm FROM user_visits WHERE dt 2023-10-27 ), bitmap_yesterday AS ( SELECT BITMAP_UNION(TO_BITMAP(user_id)) as bm FROM user_visits WHERE dt 2023-10-26 ) SELECT BITMAP_COUNT(BITMAP_ANDNOT(t.bm, y.bm)) as new_users FROM bitmap_today t, bitmap_yesterday y;3.3 包含性判断与输出函数BITMAP_CONTAINS(BITMAP, INT)判断Bitmap中是否包含某个整数。适用于用户分群后的精准筛选。-- 找出高价值用户UV1000的页面的访问记录 WITH high_value_users AS ( SELECT BITMAP_UNION(TO_BITMAP(user_id)) as bm FROM user_visits GROUP BY page HAVING BITMAP_UNION_COUNT(TO_BITMAP(user_id)) 1000 ) SELECT v.* FROM user_visits v, high_value_users h WHERE BITMAP_CONTAINS(h.bm, v.user_id);BITMAP_TO_STRING(BITMAP)将Bitmap转换为逗号分隔的字符串。慎用仅适用于调试或极小数据集因为转换大Bitmap会爆内存。SELECT BITMAP_TO_STRING(BITMAP_FROM_ARRAY([1,5,10])); -- 输出 1,5,10注意事项性能与内存BITMAP_TO_STRING是“性能杀手”绝对不要在大数据量的Bitmap上使用这个函数。它的作用是将所有ID展开完全违背了Bitmap压缩存储的初衷极易导致内存溢出OOM。仅在调试时对极小结果使用。BITMAP_CONTAINS在Join中的使用如上例所示BITMAP_CONTAINS常用于过滤。需要关注执行计划确保大Bitmap如high_value_users能够被广播Broadcast到存储原始数据的节点避免Shuffle。4. 高级应用多维去重与状态组合分析掌握了基础函数我们可以解决更复杂的业务场景。Bitmap的真正威力在于其可聚合、可计算性能够轻松处理多维度组合下的去重问题。4.1 多维度去重UV per Property业务中常需要计算“每个品类下的独立访客数”或“每个城市的不同设备数”。传统COUNT(DISTINCT)在多个维度组合时计算复杂度成倍增长。而Bitmap可以优雅解决。假设有表user_actions(item_id, city_id, user_id)我们需要计算每个商品在每个城市下的独立访问用户数。SELECT item_id, city_id, BITMAP_UNION_COUNT(TO_BITMAP(user_id)) as unique_visitors FROM user_actions GROUP BY item_id, city_id;这个查询会在每个(item_id, city_id)分组内本地构建user_id的Bitmap并聚合效率远高于在每个分组内做哈希去重。更进一步如果我们已经有了按天聚合的Bitmap表daily_user_bitmap(dt, item_id, city_id, user_bitmap BITMAP)那么查询历史任意时间段的维度组合UV将变得极其高效-- 查询过去7天商品A在北京市的独立访客数 SELECT BITMAP_UNION_COUNT(user_bitmap) as uv_7d FROM daily_user_bitmap WHERE dt 2023-10-21 AND dt 2023-10-27 AND item_id A AND city_id Beijing;4.2 用户行为序列与状态留存分析这是Bitmap集合运算的经典场景。例如我们定义“连续活跃用户”为最近7天每天都访问的用户。首先我们需要一张表记录每天活跃用户的BitmapCREATE TABLE dau_bitmap ( dt DATE, active_user_bm BITMAP BITMAP_UNION ) AGGREGATE KEY(dt) DISTRIBUTED BY HASH(dt) BUCKETS 10; -- 每日从明细表更新 INSERT INTO dau_bitmap SELECT dt, BITMAP_UNION(TO_BITMAP(user_id)) FROM user_visit_detail GROUP BY dt;然后计算连续7天活跃的用户WITH recent_days AS ( SELECT dt, active_user_bm FROM dau_bitmap WHERE dt 2023-10-21 AND dt 2023-10-27 ORDER BY dt ) -- 使用BITMAP_AND逐次求交集 SELECT BITMAP_COUNT( active_user_bm_21 active_user_bm_22 active_user_bm_23 active_user_bm_24 active_user_bm_25 active_user_bm_26 active_user_bm_27 ) as continuous_active_users_7d FROM ( SELECT MAX(CASE WHEN dt2023-10-21 THEN active_user_bm END) as active_user_bm_21, MAX(CASE WHEN dt2023-10-22 THEN active_user_bm END) as active_user_bm_22, ... -- 以此类推 MAX(CASE WHEN dt2023-10-27 THEN active_user_bm END) as active_user_bm_27 FROM recent_days ) t;这个查询通过行转列Pivot将7天的Bitmap变成7列然后使用BITMAP_AND的运算符形式进行连续求交。虽然SQL写起来有点冗长但实际计算发生在Bitmap的压缩数据上速度非常快。4.3 与其他聚合函数的协同Bitmap可以和其他聚合结果组合进行更深入的分析。例如计算人均访问次数PV/UV。SELECT dt, COUNT(*) as total_pv, -- 总访问次数 BITMAP_UNION_COUNT(TO_BITMAP(user_id)) as uv, -- 去重用户数 COUNT(*) / BITMAP_UNION_COUNT(TO_BITMAP(user_id)) as avg_pv_per_user -- 人均PV FROM user_visit_detail GROUP BY dt;这里COUNT(*)和BITMAP_UNION_COUNT在同一个聚合过程中并行计算效率很高。5. 性能调优、问题排查与最佳实践再好的工具用不好也会事倍功半。以下是我在项目中积累的关于Bitmap性能调优和问题排查的经验。5.1 常见性能瓶颈与优化策略数据分布倾斜如果用户ID本身分布不均例如某些超级用户ID产生海量记录在构建Bitmap的TO_BITMAP阶段可能产生数据倾斜。可以通过观察BE节点内存监控如果某个节点内存远高于其他节点可能存在倾斜。优化检查user_id的分布。如果ID是连续的或可分段可以考虑在DISTRIBUTED BY语句中增加一个随机桶列或者使用user_id本身进行分桶但需确保桶数足够多如10。Bitmap聚合内存压力在最终聚合阶段BITMAP_UNION如果全局去重基数极大例如数亿合并Bitmap会消耗较多内存。优化调整BE的bitmap_memory_limit参数在be.conf中增加Bitmap操作可用的内存上限。同时确保查询有合理的LIMIT或有效的过滤条件避免全表扫描构建超大Bitmap。即席查询响应慢对没有Bitmap预聚合的明细表进行多日去重查询即使使用Bitmap函数也需要扫描大量数据并现场构建Bitmap。优化这是架构问题。必须建立预聚合层。根据业务查询模式建立按小时、天、周等不同粒度并包含关键维度如产品、渠道的Bitmap聚合表。让95%的查询命中聚合表。5.2 典型错误与问题排查错误Invalid type或Cannot cast场景TO_BITMAP函数报错。原因TO_BITMAP只接受INT或BIGINT类型的列。如果你的用户ID是字符串如UUID直接使用会报错。排查-- 1. 确认字段类型 DESCRIBE table_name; -- 2. 如果是字符串需要先哈希为整数有碰撞风险需评估 SELECT BITMAP_UNION_COUNT(TO_BITMAP(CRC32(user_id_string))) FROM table_name; -- 或者如果字符串本身是数字可以转换 SELECT BITMAP_UNION_COUNT(TO_BITMAP(CAST(user_id_string AS BIGINT))) FROM table_name;根本解决在设计表时尽量让需要去重的标识字段使用INT/BIGINT类型。如果源数据是字符串应在ETL过程中将其映射为整数。错误查询内存超限OOM场景查询复杂涉及多个大Bitmap的集合运算。排查查看FE/BE的日志确认错误是否发生在BITMAP_UNION或BITMAP_TO_STRING阶段。解决避免使用BITMAP_TO_STRING。尝试分而治之将复杂的多日交集/并集查询拆分成多个子查询逐步缩小Bitmap大小。增加BE内存并调整query_mem_limit和exec_mem_limit参数。检查是否存在数据倾斜优化数据分布。问题Bitmap精度与哈希碰撞场景使用哈希函数如CRC32将字符串转为整数后使用Bitmap结果可能与COUNT(DISTINCT)有细微差异。原因CRC32是32位哈希存在理论上的碰撞概率两个不同的字符串哈希到同一个整数。评估对于亿级以下的基数统计CRC32碰撞概率极低通常可以接受。如果要求绝对精确可以考虑使用BIGINT类型的哈希函数如HASH64或使用BITMAP类型存储原始字符串的哈希值但Doris Bitmap原生支持整数。5.3 最佳实践清单根据我的项目经验总结出以下 checklist能帮你避开大多数坑设计阶段[ ]标识字段整形化将需要去重的业务ID用户、设备、订单设计为BIGINT类型。[ ]优先使用聚合模型对于固定维度的去重指标建表时直接使用AGGREGATE KEY和BITMAP列。[ ]合理分桶根据数据量和查询模式选择高基数列如user_id或常用过滤列进行分桶避免数据倾斜。开发阶段[ ]避免BITMAP_TO_STRING除非调试否则不要在生产查询中使用。[ ]善用BITMAP_FROM_ARRAY在数据补录或手动插入时这是构建测试数据的好工具。[ ]BITMAP_UNION_COUNT是首选绝大多数去重场景直接使用这个聚合函数。[ ]复杂集合运算先聚合先按最小粒度聚合出Bitmap再进行多Bitmap的AND/OR运算性能远优于在明细数据上直接JOIN。运维阶段[ ]监控Bitmap内存关注BE节点的bitmap_memory_usage指标。[ ]建立预聚合链路将Bitmap预聚合作为数仓DWD层到DWS层轻度汇总层的标准加工步骤。[ ]查询引导通过物化视图或查询路由将业务查询引导至Bitmap聚合表。从我自己的经验来看引入Bitmap最大的收益不是单个查询变快而是它为整个数据分析体系提供了一种可累加、可计算的“用户资产”表达方式。一旦将每日的用户集合沉淀为Bitmap后续计算留存、新增、交叉活跃等复杂指标就变成了简单的集合运算成本极低且实时性极高。这背后是从“统计结果”到“存储集合”的思维转变也是构建高效实时分析系统的关键一步。