文章目录

1.概述
2.位图法简述
3.RoaringBitmap的思路
4.Container原理
- 4.1 ArrayContainer
- 4.2 BitmapContainer
- 4.3 RunContainer
- - 4.3.1 时空分析
  - 4.3.2 Container的创建与转换
  - 4.3.3 RBM的应用
  - - 4.3.3.1 Lucene
    - 4.3.3.2 Spark
    - 4.3.3.4 Greenplum
    - 4.3.3.5 Redis
M.扩展阅读

1.概述

转载：https://www.jianshu.com/p/818ac4e90daf
学习到了这个技术，转载一下加深记忆

2.位图法简述

对于我们大数据工作者来说，海量数据的判重和基数统计是两个绕不开的基础问题。之前我已经讲了两种应用广泛的方法，即布隆过滤器和HyperLogLog。虽然它们节省空间并且效率高，但也付出了一定的代价，即：

只能插入元素，不能删除元素；
不保证100%准确，总是存在误差。

这两个缺点可以说是所有概率性数据结构（probabilistic data structure）做出的trade-off，毕竟鱼与熊掌不可兼得嘛。

话说回来，有什么相对高效的能够保证绝对精确的方法呢？最朴素的思路是利用布隆过滤器和HyperLogLog的基础——位数组，也叫位图（bitmap）。不妨来看一道老生常谈的面试题：

给定含有40亿个不重复的位于[0, 232 - 1]区间内的整数的集合，如何快速判定某个数是否在该集合内？

显然，如果我们将这40亿个数原样存储下来，需要耗费高达14.9GB的内存，不可接受。所以我们可以用位图来存储，即第0个比特表示数字0，第1个比特表示数字1，以此类推。如果某个数位于原集合内，就将它对应的位图内的比特置为1，否则保持为0。这样就能很方便地查询得出结果了，仅仅需要占用512MB的内存，只有原来的不到3.4%。

由于位图的这个特性，它经常被作为索引用在数据库、查询引擎和搜索引擎中，并且位操作（如and求交集、or求并集）之间可以并行，效率更好。但是，位图也不是完美无缺的：不管业务中实际的元素基数有多少，它占用的内存空间都恒定不变。举个例子，如果上文题目中的集合只存储了0这一个元素，那么该位图只有最低位是1，其他位全为0，但仍然占用了512MB内存。数据越稀疏，空间浪费越严重。

为了解决位图不适应稀疏存储的问题，大佬们提出了多种算法对稀疏位图进行压缩，减少内存占用并提高效率。比较有代表性的有WAH、EWAH、Concise，以及RoaringBitmap。前三种算法都是基于行程长度编码（Run-length encoding, RLE）做压缩的，而RoaringBitmap算是它们的改进版，更加优秀，因此本文重点探讨它。

3.RoaringBitmap的思路

为了不用打那么多字，下文将RoaringBitmap简称为RBM。

RBM的历史并不长，它于2016年由S. Chambi、D. Lemire、O. Kaser等人在论文《Better bitmap performance with Roaring bitmaps》与《Consistently faster and smaller compressed bitmaps with Roaring》中提出，官网在这里。

RBM的主要思路是：将32位无符号整数按照高16位分桶，即最多可能有216=65536个桶，论文内称为container。存储数据时，按照数据的高16位找到container（找不到就会新建一个），再将低16位放入container中。也就是说，一个RBM就是很多container的集合。

为了方便理解，照搬论文中的示例图，如下所示。

图中示出了三个container：

高16位为0000H的container，存储有前1000个62的倍数。
高16位为0001H的container，存储有[2的16次方, 2的16次方+100)区间内的100个数。
高16位为0002H的container，存储有[2×2的16次方, 3×2的16次方)区间内的所有偶数，共215个。

container是RBM新创造的概念，自然也是提高效率的核心。为了更高效地存储和查询数据，不同情况下会采用不同类型的container，下面深入讲解一下container的细节。

4.Container原理

一共有3种。

4.1 ArrayContainer

当桶内数据的基数不大于4096时，会采用它来存储，其本质上是一个unsigned short类型的有序数组。数组初始长度为4，随着数据的增多会自动扩容（但最大长度就是4096）。另外还维护有一个计数器，用来实时记录基数。

上图中的前两个container基数都没超过4096，所以均为ArrayContainer。

4.2 BitmapContainer

当桶内数据的基数大于4096时，会采用它来存储，其本质就是上一节讲过的普通位图，用长度固定为1024的unsigned long型数组表示，亦即位图的大小固定为216位（8KB）。它同样有一个计数器。

上图中的第三个container基数远远大于4096，所以要用BitmapContainer存储。

4.3 RunContainer

RunContainer在图中并未示出，初始的RBM实现中也没有它，而是在本节开头的第二篇论文中新加入的。它使用可变长度的unsigned short数组存储用行程长度编码（RLE）压缩后的数据。举个例子，连续的整数序列11, 12, 13, 14, 15, 27, 28, 29会被RLE压缩为两个二元组11, 4, 27, 2，表示11后面紧跟着4个连续递增的值，27后面跟着2个连续递增的值。

由此可见，RunContainer的压缩效果可好可坏。考虑极端情况：如果所有数据都是连续的，那么最终只需要4字节；如果所有数据都不连续（比如全是奇数或全是偶数），那么不仅不会压缩，还会膨胀成原来的两倍大。所以，RBM引入RunContainer是作为其他两种container的折衷方案。

下面来简要看看它们的复杂度和转换方法。

4.3.1 时空分析

增删改查的时间复杂度方面，BitmapContainer只涉及到位运算，显然为O(1)。而ArrayContainer和RunContainer都需要用二分查找在有序数组中定位元素，故为O(logN)。

空间占用（即序列化时写出的字节流长度）方面，BitmapContainer是恒定为8192B的。ArrayContainer的空间占用与基数（c）有关，为(2 + 2c)B；RunContainer的则与它存储的连续序列数（r）有关，为(2 + 4r)B。以上节图中的RBM为例，它一共存储了33868个unsigned int，只占用了10396个字节的空间，可以说是非常高效了。

4.3.2 Container的创建与转换

在创建一个新container时，如果只插入一个元素，RBM默认会用ArrayContainer来存储。如果插入的是元素序列的话，则会先根据上面的方法计算ArrayContainer和RunContainer的空间占用大小，并选择较小的那一种进行存储。

当ArrayContainer的容量超过4096后，会自动转成BitmapContainer存储。4096这个阈值很聪明，低于它时ArrayContainer比较省空间，高于它时BitmapContainer比较省空间。也就是说ArrayContainer存储稀疏数据，BitmapContainer存储稠密数据，可以最大限度地避免内存浪费。

RBM还可以通过调用特定的API（名为optimize）比较ArrayContainer/BitmapContainer与等价的RunContainer的内存占用情况，一旦RunContainer占用较小，就转换之。也就是说，上图例子中的第二个ArrayContainer可以转化为只有一个二元组0, 100的RunContainer，占用空间进一步下降到10200字节。

4.3.3 RBM的应用

官方提供了RBM的多种语言实现，Java、C/C++、Python、Go、C#等等一应俱全。Java版本的GitHub repo见这里。代码比较多，但思路很清晰，看官如果对位运算比较熟悉的话读起来不难，故本文就不再长篇大论地讲源码了。值得注意的几点如下：

两个RBM做集合操作时，不同种类container之间位运算的处理方式，如ArrayContainer AND BitmapContainer，BitmapContainer OR RunContainer等；
对64位整数的支持（32位有时会不够用哈）；
能够将RBM数据写到堆外，即内存映射；
支持Kryo序列化方式。

RBM的应用范围极广，下面只简单列举几个有代表性的应用，并给出reference。

4.3.3.1 Lucene

为了加速搜索，Lucene会将常用的查询过滤条件产生的结果集缓存到内存中，方便复用，称为filter cache。结果集其实就是文档ID（整形数）的集合。从Lucene 5开始，使用了RBM优化过的文档ID集合RoaringDocIdSet作为filter cache，详情可以参见《Frame of Reference and Roaring Bitmaps》。该文除了介绍RBM外，还介绍了压缩倒排索引的Frame of Reference（FOR）编码，值得一读。

4.3.3.2 Spark

在Spark Core的MapStatus组件（用来跟踪ShuffleMapTask的输出结果块）中，利用了RBM来存储块是否非空的状态。今后会在Spark连载里讲到它，所以现在看看该类的源码就可以了，不难理解。

4.3.3.4 Greenplum

我司是Greenplum大户，虽然本鶸现在不负责数仓相关的事情了，但是偶尔还是要向GP提供一些数据。GP配合RoaringBitmap非常适合做海量用户的近实时画像，每个RBM代表一维标签即可，根据标签圈选用户也很方便。GP原生并未支持RBM类型数据，需要安装一个扩展插件，见这里。关于GP与RBM的整合与使用，有两篇不错的参考文章：

https://yq.aliyun.com/articles/405191
http://mysql.taobao.org/monthly/2018/08/09

4.3.3.5 Redis

我们在Redis里经常使用位图存储数据（Redis原生以字符串的形式支持位图），当然也就会遇到稀疏位图浪费存储空间的问题。但要让Redis支持RBM，需要引入专门的module，项目地址见这里。它的设计思想与Java版RBM几乎相同，不再废话了。

M.扩展阅读

【Flink】Flink kafka Spark 如何实现数据有序性

【java】高效压缩位图RoaringBitmap的原理与应用

【clickhouse】clickhouse表引擎之ReplacingMergeTree

【Flink】Flink 实时去重方案四种方案 MapState 、SQL方式、HyperLogLog、Bitmap

【java】高效压缩位图RoaringBitmap的原理与应用相关推荐

高效压缩位图RoaringBitmap的原理与应用
目录位图法简述 RoaringBitmap的思路 Container原理 ArrayContainer BitmapContainer RunContainer 时空分析 Container的创建与 ...
Java 高效压缩zip
以前遇到文件压缩的功能是都直接从网上找一个,随便测试一下能用就行了.既不关心效率也没有好好的测一下是否支持内嵌文件夹的压缩. 现在仔细测试才发现网上好多都不支持内嵌文件夹的压缩. 支持的不是有问题就是 ...
java jpeg压缩解码_JPEG图像压缩原理简介
JPEG(发音:[ˈdʒeɪpɛg])是一种针对照片视频而广泛使用的有损压缩标准方法. 这个名称代表 Joint Photographic Experts Group(联合图像专家小组).联合图像专家 ...
java的markword_【转帖】Java工具结构与锁实现原理及MarkWord详解
Java工具结构与锁实现原理及MarkWord详解 https://www.pianshen.com/article/2382167638/ 我们都知道,Java工具存储在堆(Heap)内存.那么一个 ...
简单高效压缩图片，保持图片高质量的神仙网站
简单高效压缩图片,保持图片高质量的神网站前言我们在做网站前端的时候常常会遇到这样一个场景我有一张超高清的图片,要在首页作为封面图来展示,图片大小达到了 1.23MB,而我们此时需要要求我们前端页 ...
java 文件压缩解压_Java文件压缩与解压缩(一)
package com.cn; import java.io.File; import java.io.FileInputStream; import java.io.FileOutputStream ...
Java并发机制的底层实现原理
Java代码在编译后会变成Java字节码,字节码被类加载器加载到JVM里,JVM执行字节码,最终需要转化为汇编指令在CPU上执行,Java中所使用的并发机制依赖于JVM的实现和CPU的指令.本章我们将 ...
Java服务器热部署的实现原理
[本文转载于Java服务器热部署的实现原理] 今天发现早年在大象笔记中写的一篇笔记,之前放在ijavaboy上的,现在它已经访问不了了.前几天又有同事在讨论这个问题.这里拿来分享一下. 在web应用开 ...
JAVA层HIDL服务的获取原理-Android10.0 HwBinder通信原理（九）
摘要:本节主要来讲解Android10.0 JAVA层HIDL服务的获取原理阅读本文大约需要花费19分钟. 文章首发微信公众号:IngresGe 专注于Android系统级源码分析,Android的 ...