1. 从“计数不准”到“精准去重”的实战需求在数据仓库和实时分析领域我们经常遇到一个看似简单却暗藏玄机的问题如何精确地统计一个集合中不重复元素的数量尤其是在处理海量用户ID、设备ID、订单号等场景时传统的COUNT(DISTINCT)方法在高基数即唯一值数量巨大和大数据量下往往会成为性能瓶颈甚至因为内存限制导致查询失败或结果不准确。很多从业者都曾踩过这个坑明明数据就在那里但一个简单的去重计数查询却跑得异常缓慢或者在某些分布式计算框架下因为数据倾斜或近似算法的误差得到一个“差不多”但“不精确”的数字。对于需要精确对账、财务计算或关键业务指标的场景这种“差不多”是绝对无法接受的。Apache Doris作为一个高性能的实时分析型数据库其MPP架构和向量化执行引擎在处理大规模数据分析上有着天然优势。面对精准去重的挑战Doris提供了一套基于BitMap数据类型的强大函数集。这不仅仅是提供了一个新函数那么简单它代表了一种从“近似估算”到“精确计算”的思维转变以及一种利用内存高效数据结构来换取极致查询性能的工程实践。BitMap去重的核心价值在于它能在常数级内存增长下实现对海量高基数数据的精确去重计数将原本可能需要数分钟甚至更久的COUNT(DISTINCT)查询优化到秒级甚至毫秒级响应。本文将深入拆解Apache Doris中BitMap函数用于精准去重的原理、适用场景、详细操作步骤以及那些官方文档可能不会提及的实战避坑指南。无论你是正在为COUNT(DISTINCT)的性能问题而头疼还是希望寻找一种更优雅、更高效的数据去重解决方案这篇从一线实战中总结出的经验都将为你提供清晰的路径和可靠的参考。2. BitMap去重为什么是它而不是COUNT(DISTINCT)要理解BitMap的优势我们必须先看清传统COUNT(DISTINCT)的局限性。在分布式数据库如Doris中一个COUNT(DISTINCT column)的查询其执行过程通常涉及数据重分布Shuffle和全局聚合。当去重列的唯一值数量基数非常高时这个聚合节点需要维护一个巨大的哈希表来记录所有已经出现过的唯一值以判断后续值是否重复。这个过程会消耗大量的内存一旦超出节点内存限制就会触发磁盘溢出Spill to Disk甚至直接导致查询失败OOM。此外数据在节点间网络传输Shuffle本身也是一项昂贵的开销。BitMap则采用了一种完全不同的思路。它本质上是一个基于位bit的集合表示法。假设我们需要对用户ID进行去重我们可以预先定义一个足够大的位图空间例如使用BIGINT类型的用户ID理论范围是0到2^63-1。BitMap并不直接存储每一个用户ID的原始值而是将每个用户ID映射到位图中的一个特定位置位。如果该用户ID存在则将其对应的位设置为1否则为0。最后要得到不重复用户的数量只需要统计这个位图中值为1的位的个数即可。2.1 核心优势对比为了更直观地展示差异我们通过一个表格来对比两种方式特性维度COUNT(DISTINCT)BitMap去重计算精度精确精确内存消耗与去重列的基数成正比。基数越高内存消耗越大易OOM。与去重列的值域范围成正比与数据量和基数无关。通过压缩技术如Roaring Bitmap实际内存消耗远小于理论值。计算速度较慢。涉及哈希计算、哈希表维护和可能的数据Shuffle。极快。位操作OR, AND, COUNT是CPU指令级优化效率极高且常可避免全局Shuffle。适用场景低基数去重例如性别、省份等枚举值。高基数去重用户ID、设备ID、手机号等。特别是当ID是连续或分布相对集中的整数时优势巨大。预处理需求无需预处理可直接在原始数据上查询。通常需要在数据导入或通过物化视图预计算阶段将原始数据转化为BitMap。属于“空间换时间”和“计算前置”。存储开销无额外存储。需要存储BitMap对象但通过压缩存储增量通常可接受。注意BitMap并非银弹。它的一个关键前提是去重对象必须是整型TINYINT, SMALLINT, INT, BIGINT或者可以稳定地映射为整型如将字符串通过哈希函数转为整型但需注意哈希冲突风险。对于非整型数据需要额外的ETL处理。2.2 BitMap在Doris中的实现精髓Apache Doris内置了BITMAP数据类型和一系列函数如bitmap_union(),bitmap_union_count(),bitmap_hash()等。其高效性得益于两点计算下推与预聚合在Doris的聚合模型中可以在数据导入时或通过物化视图使用BITMAP类型列和bitmap_union()函数进行预聚合。查询时直接对已经聚合好的BitMap进行bitmap_union_count()计算避免了扫描原始明细数据和高成本的运行时去重。Roaring Bitmap压缩Doris底层使用的BitMap库是经过高度优化的Roaring Bitmap。它并非简单开辟一个巨大的位数组而是根据数据分布智能地将值域分成多个块Container对于稀疏块使用数组存储对于稠密块使用位图存储从而在绝大多数实际场景下实现了内存和计算效率的最佳平衡。理解了“为什么”之后接下来的问题就是“怎么做”。我们将从一个具体的业务场景出发手把手完成从表设计到高效查询的全过程。3. 实战演练设计一个基于BitMap的用户活跃日统计表假设我们有一个经典的业务需求统计每天活跃的用户数DAU以及任意时间范围内的去重活跃用户数如WAU, MAU。用户ID是BIGINT类型每天产生数十亿的访问记录用户基数在数亿级别。3.1 表结构设计与建表语句在Doris中我们需要设计一张聚合表Aggregate Table这是使用BitMap进行高效预聚合的基础。CREATE TABLE dau_bitmap ( dt date NOT NULL COMMENT 日期, user_id_bitmap BITMAP BITMAP_UNION NOT NULL COMMENT 活跃用户Bitmap ) ENGINEOLAP AGGREGATE KEY(dt) COMMENT 使用Bitmap存储每日活跃用户 DISTRIBUTED BY HASH(dt) BUCKETS 10 PROPERTIES ( replication_num 3, storage_format V2 );关键设计解析聚合键AGGREGATE KEY这里只包含了dt日期字段。这意味着表会按照dt进行聚合。所有相同dt的数据行在导入或Compaction时其user_id_bitmap列会按照BITMAP_UNION的聚合方式合并。BITMAP_UNION聚合方式这是核心。它指定了user_id_bitmap这个BITMAP类型列的聚合逻辑是“位图并集合并”。当多行数据具有相同的dt时它们的user_id_bitmap会被合并求并集成一个更大的BitMap从而自动实现去重。数据分布使用dt字段进行HASH分桶将不同日期的数据分布到不同节点便于并行查询和存储。这个表结构非常精简它不存储原始的用户ID列表只存储每天聚合后的BitMap对象。存储压力从存储大量重复的user_id字符串或数字转变为存储高度压缩的BitMap。3.2 数据导入将原始数据转化为Bitmap原始日志或业务表user_behavior可能长这样user_idevent_time...100012023-10-27 10:00:00...100022023-10-27 10:01:00...100012023-10-27 11:00:00...100032023-10-28 09:00:00...我们需要将这样的数据导入到dau_bitmap表中。这里使用INSERT INTO SELECT配合bitmap_agg()函数来实现。bitmap_agg()是一个聚合函数它将一组整数值聚合成一个BitMap。-- 假设原始表为 user_behavior 有 user_id(BIGINT) 和 event_time(DATETIME) 字段 INSERT INTO dau_bitmap (dt, user_id_bitmap) SELECT DATE(event_time) as dt, BITMAP_AGG(user_id) as user_id_bitmap FROM user_behavior WHERE event_time 2023-10-27 GROUP BY DATE(event_time);执行这个语句后Doris会按DATE(event_time)分组。在每个分组内对所有的user_id调用BITMAP_AGG()生成一个包含该日内所有活跃用户ID的BitMap自动去重。将结果日期 BitMap插入到dau_bitmap表。如果同一天的数据分多次导入Doris会在底层自动使用BITMAP_UNION合并这些BitMap。实操心得数据分批次导入的优化对于历史数据初始化或大规模数据回溯建议按时间范围分批执行INSERT INTO SELECT例如每次处理一周或一天的数据。这可以避免单个导入作业过大导致FEFrontend生成执行计划过慢或BEBackend内存压力剧增。可以在脚本中循环执行并添加适当的间隔。3.3 高效查询秒级获取DAU、WAU、MAU当数据以BitMap形式预聚合好后查询变得异常简单和快速。查询单日活跃用户数DAUSELECT dt, BITMAP_UNION_COUNT(user_id_bitmap) as dau FROM dau_bitmap WHERE dt 2023-10-27;BITMAP_UNION_COUNT()函数是查询的关键。它接收一个BitMap列并返回该位图中置为1的位的总数即精确的去重用户数。由于数据已经按天聚合好这个查询几乎不需要进行任何昂贵的计算直接读取并计算预聚合好的BitMap即可速度极快。查询过去7天的去重活跃用户数WAUSELECT BITMAP_UNION_COUNT(user_id_bitmap) as wau FROM dau_bitmap WHERE dt 2023-10-21 AND dt 2023-10-27;这个查询会将7天内每天的BitMap通过BITMAP_UNION_COUNT()函数在计算过程中进行合并union然后统计总数。虽然涉及多个BitMap的合并操作但由于BitMap合并是高度优化的位运算且数据已经按天压缩其性能依然远优于对7天原始数据做COUNT(DISTINCT user_id)。4. 进阶应用与复杂场景剖析基础的日粒度统计只是开始。BitMap的真正威力体现在更复杂的多维分析和用户分群场景中。4.1 多维交叉分析哪些用户既活跃又完成了购买假设我们还有另一张表purchase_bitmap以同样的方式存储了每日完成购买的用户BitMap。现在想分析在2023-10-27当天既活跃又购买的用户数即活跃购买用户交集。SELECT BITMAP_UNION_COUNT( BITMAP_INTERSECT(dau.user_id_bitmap, pur.user_id_bitmap) ) as active_purchase_users FROM dau_bitmap dau JOIN purchase_bitmap pur ON dau.dt pur.dt WHERE dau.dt 2023-10-27;这里引入了BITMAP_INTERSECT()函数用于计算两个BitMap的交集然后再对交集的BitMap计数。这种基于集合的运算并集、交集、差集是BitMap的天然优势可以轻松实现复杂的用户行为交集、并集分析而无需复杂的子查询或JOIN去重。4.2 用户留存率计算计算次日留存率是常见的需求。例如计算2023-10-26的新增用户在2023-10-27的留存情况。首先我们需要一张表first_day_bitmap来记录用户的首日活跃BitMap这可以通过对dau_bitmap进行首次出现聚合得到或由业务直接记录。然后使用BITMAP_INTERSECT计算留存用户。-- 假设 first_day_bitmap 表结构为 (first_dt date, user_id_bitmap BITMAP) SELECT first.first_dt, BITMAP_UNION_COUNT(first.user_id_bitmap) as new_users, BITMAP_UNION_COUNT( BITMAP_INTERSECT(first.user_id_bitmap, dau.user_id_bitmap) ) as retained_users, BITMAP_UNION_COUNT( BITMAP_INTERSECT(first.user_id_bitmap, dau.user_id_bitmap) ) / BITMAP_UNION_COUNT(first.user_id_bitmap) as retention_rate FROM first_day_bitmap first LEFT JOIN dau_bitmap dau ON dau.dt DATE_ADD(first.first_dt, INTERVAL 1 DAY) WHERE first.first_dt 2023-10-26 GROUP BY first.first_dt;这个查询清晰地展示了如何利用BitMap的集合运算高效且精确地完成留存率这种需要多重去重和关联的分析。4.3 处理非整型数据字符串ID的映射如果用户ID是字符串如UUID、手机号直接使用BitMap是不行的。常见的做法是使用一个稳定的哈希函数如murmur_hash3_32,crc32将其转化为整型。但这里有一个至关重要的坑哈希冲突。-- 在数据导入时进行转换 INSERT INTO dau_bitmap (dt, user_id_bitmap) SELECT DATE(event_time), BITMAP_AGG(CAST(MURMUR_HASH3_32(user_id_string) AS INT)) -- 使用32位哈希转为INT FROM user_behavior_string GROUP BY DATE(event_time);重要警告与避坑指南哈希冲突风险哈希函数将无限可能的字符串映射到有限的整数空间如32位整型是42亿必然存在不同字符串哈希到同一个整数的可能这就是哈希冲突。冲突会导致本应不同的用户被误判为同一用户使得去重计数结果偏少造成数据不准。缓解方案评估冲突概率对于数亿级别的用户基数使用32位哈希约42亿空间冲突概率已不可忽视。建议使用64位哈希murmur_hash3_64并存储为BIGINT冲突概率极低。业务层保证如果可能最好在业务系统设计时就为需要分析的用户生成一个全局唯一的数字ID如自增ID或Snowflake算法ID从源头上避免映射问题。使用Bitmap字典维护一个用户字符串到唯一整数ID的映射字典表。虽然更精确但增加了ETL复杂度。需要权衡精确性和工程成本。实测建议在决定方案前可以对存量数据抽样计算哈希冲突率评估对业务指标的潜在影响。5. 性能调优与生产环境注意事项将BitMap应用于生产环境除了正确的使用姿势还需要关注一些影响稳定性和性能的细节。5.1 Bitmap列的数据分布与压缩BitMap对象的体积与其表示的最大整数值有关。如果用户ID范围非常稀疏例如ID从10亿开始直接使用会导致BitMap内部开辟大量无效空间。虽然Roaring Bitmap已经做了优化但初始ID偏移量过大仍可能影响效率。优化建议如果ID不是从0或1开始的小数字可以考虑在导入时进行偏移归一化。例如如果最小用户ID是1000000000可以在BITMAP_AGG之前先减去这个最小值user_id - 1000000000以缩小值域范围。查询时如果需要还原原始ID进行关联则需要额外记录这个偏移量。这属于一种“数据预处理”的优化手段适用于ID范围已知且相对固定的场景。5.2 物化视图加速更复杂的聚合上述例子是按天聚合。但如果经常需要查询“每小时的DAU”或“每周的MAU”每次都从日粒度BitMap上计算虽然比查原始数据快但仍有计算开销。此时可以利用Doris的异步物化视图功能预先计算好更细粒度或更粗粒度的BitMap聚合。例如创建小时粒度的物化视图CREATE MATERIALIZED VIEW dau_hourly_mv AS SELECT DATE_TRUNC(HOUR, event_time) as dt_hour, BITMAP_AGG(user_id) as user_id_bitmap FROM user_behavior GROUP BY DATE_TRUNC(HOUR, event_time);创建后查询WHERE dt_hour ...时Doris查询优化器会自动路由到这个物化视图直接读取小时粒度的聚合结果速度更快。5.3 监控与问题排查内存监控虽然BitMap压缩率高但在执行涉及多个大BitMap合并的查询时如计算一个月的MAU中间结果BitMap可能会占用较多内存。需要关注BE节点的内存监控指标如query_peak_memory。慢查询分析如果BitMap查询变慢可以使用EXPLAIN命令查看执行计划。重点检查是否没有命中预聚合的BitMap数据而是回退到了扫描原始明细数据。这通常是因为WHERE条件中的过滤字段不是聚合键的一部分或者物化视图未正确创建。存储膨胀定期检查表的数据量。虽然BitMap压缩但无止境的历史数据存储仍会带来成本。需要根据业务需求设计数据生命周期管理TTL将过期的冷数据转移到对象存储如S3或直接删除。5.4 一个真实的踩坑案例Bitmap与COUNT DISTINCT的混合使用误区有一次在优化一个宽表查询时我需要同时计算一个高基数字段A的去重数和几个低基数字段B、C的去重数。我自作聪明地将高基数字段A改用了BitMap预聚合而低基数字段B、C保留了COUNT(DISTINCT)。查询语句类似SELECT bitmap_union_count(bitmap_A) as uv_A, COUNT(DISTINCT B) as uv_B, COUNT(DISTINCT C) as uv_C FROM my_table;结果发现查询性能并没有达到预期提升有时甚至更慢。通过EXPLAIN分析发现由于查询中同时存在BitMap聚合和普通的COUNT(DISTINCT)聚合Doris的查询引擎无法完全利用BitMap表的预聚合优势执行计划变得复杂部分计算仍需扫描原始数据。解决方案与心得 对于这种混合场景更优的做法是彻底拥抱BitMap或者进行查询拆分。彻底拥抱BitMap即使对于低基数字段B和C也为其创建BITMAP类型的聚合列。因为BitMap对于低基数数据压缩率极高计算也很快。将表彻底改造为全BitMap聚合表。查询拆分如果改造表结构成本高可以将一个复杂查询拆分成多个简单查询。先通过BitMap表快速查询出uv_A再通过其他方式查询uv_B和uv_C在应用层进行结果组装。这违背了“一次查询搞定所有”的直觉但在分布式系统中有时简单的查询并行执行总耗时反而少于一个复杂的单一查询。这个坑让我明白性能优化不是简单地替换一个函数而是需要从表设计、数据存储到查询方式的全链路通盘考虑。引入BitMap这类高效但特化的数据结构后整个数据模型和查询模式最好都能围绕其特性进行适配才能最大化其收益。