a) Bitmap如何做到多维交叉计算的？
Bit即比特，是目前计算机系统里边数据的最小单位，8个bit即为一个Byte。一个bit的值，或者是0，或者是1；也就是说一个bit能存储的最多信息是2。
Bitmap可以理解为通过一个bit数组来存储特定数据的一种数据结构；由于bit是数据的最小单位，所以这种数据结构往往是非常节省存储空间。比如一个公司有8个员工，现在需要记录公司的考勤记录，传统的方案是记录下每天正常考勤的员工的ID列表，比如2012-01-01:[1,2,3,4,5,6,7,8]。假如员工ID采用byte数据类型，则保存每天的考勤记录需要N个byte，其中N是当天考勤的总人数。另一种方案则是构造一个8bit（01110011）的数组，将这8个员工跟员工号分别映射到这8个位置，如果当天正常考勤了，则将对应的这个位置置为1，否则置为0；这样可以每天采用恒定的1个byte即可保存当天的考勤记录。
综上所述，Bitmap节省大量的存储空间，因此可以被一次性加载到内存中。再看其结构的另一个更重要的特点，它也显现出巨大威力：就是很方便通过位的运算（AND/OR/XOR/NOT），高效的对多个Bitmap数据进行处理，这点很重要，它直接的支持了多维交叉计算能力。比如上边的考勤的例子里，如果想知道哪个员工最近两天都没来，只要将昨天的Bitmap和今天的Bitmap做一个按位的“OR”计算，然后检查那些位置是0，就可以得到最近两天都没来的员工的数据了，比如：
再比如，我们想知道哪些男员工没来？我们可以在此结果上再“And”上一个Bitmap就能得到结果。
b) Bitmap如何做到高速运算的？
回忆一下前面，浪费的有两个部分：其一是存储空间的浪费，Bitmap比文件强多了，但是仍然有浪费的嫌疑。它需要保存到外部存储（数据库或者文件），计算时需要从外部存储加载到内存，因此存储的Bitmap越大，需要的外部存储空间就越大；并且计算时I/O的消耗会更大，加载Bitmap的时间也越长。其二是计算资源的浪费，计算时要加载到内存，越大的Bitmap消耗的内存越多；位数越多，计算时消耗的cpu时间也越多。
对于第一种浪费，最直觉的方案就是可以引入一些文件压缩技术，比如gzip/lzo之类的，对存储的Bitmap文件进行压缩，在加载Bitmap的时候再进行解压，这样可以很好的解决存储空间的浪费，以及加载时I/O的消耗；代价则是压缩/解压缩都需要消耗更多的CPU/内存资源；并且文件压缩技术对第二种浪费也无能为力。因此只有系统有足够多空闲的CPU资源而I/O成为瓶颈的情况下，可以考虑引入文件压缩技术。
那么有没有一些技术可以同时解决这两种浪费呢？好消息是有，那就是Bitmap压缩技术；而常见的压缩技术都是基于RLE（Run Length Encoding，详见http://en.wikipedia.org/wiki/Run-length_encoding）。
RLE编码很简单，比较适合有很多连续字符的数据，比如以下边的Bitmap为例：
可以编码为0,8,2,11,1,2,3,11
其意思是:第一位为0，连续有8个，接下来是2个1，11个0，1个1，2个0，3个1，最后是11个0（当然此处只是对RLE的基本原理解释，实际应用中的编码并不完全是这样的）。
可以预见，对于一个很大的Bitmap，如果里边的数据分布很稀疏（说明有很多大片连续的0），采用RLE编码后，占用的空间会比原始的Bitmap小很多。
同时引入一些对齐的技术，可以让采用RLE编码的Bitmap不需要进行解压缩，就可以直接进行AND/OR/XOR等各类计算；因此采用这类压缩技术的Bitmap，加载到内存后还是以压缩的方式存在，从而可以保证计算时候的低内存消耗；而采用word（计算机的字长，64位系统就是64bit）对齐等技术又保证了对CPU资源的高效利用。因此采用这类压缩技术的Bitmap，保持了Bitmap数据结构最重要的一个特性，就是高效的针对每个bit的逻辑运算。
常见的压缩技术包括BBC（有专利保护）,
WAH（http://code.google.com/p/compressedbitset/）
和EWAH(http://code.google.com/p/javaewah/)。在Apache Hive里边使用了EWAH。
c) Bitmap在大数据计算上的能力？
我们用一个TalkingData Analytics中用户留存的例子来看Bitmap如何做到用户回访的统计。比如想知道某个应用，昨天新增的用户中，有多少人今天又开启了应用（次日留存）。使用过Hive的工程师，不难理解下面语句的含义：
同时，我们使用Bitmap技术后，同样实现上述的计算，对比测试显示出效率的差异是巨大的：
d) 引入Bitmap技术后，分析系统可能的处理流程大体是什么样的？
数据收集系统收集设备上传数据，然后分发给实时处理系统和批量处理系统；
实时系统采用自有计数器程序，或者基于Storm之类中间件的计数器程序，计算各类简单计数器，然后批量（比如30s或者1min）更新到Redis或者HBase之类的存储；前端供应计数器类数据的服务通过访问后台计算器程序或者是计数器存储来给报表系统提供服务；
批量系统对该批的数据按用户进行去重生成/修改某天/某个应用的活跃用户Bitmap，同时可以根据需要，将机型、地域、操作系统等等各种数据提炼成属性Bitmap，备用。
报表中针对分析需要，提取各种Bitmap（用户、属性……Bitmap），高效的利用CPU/内存，通过组合And/Or/Not等基础计算，最终完成多维交叉计算功能，反馈客户结果。
