a) Bitmap如何做到多維交叉計算的？
Bit即比特，是目前計算機(jī)系統(tǒng)里邊數(shù)據(jù)的最小單位，8個bit即為一個Byte。一個bit的值，或者是0，或者是1；也就是說一個bit能存儲的最多信息是2。
Bitmap可以理解為通過一個bit數(shù)組來存儲特定數(shù)據(jù)的一種數(shù)據(jù)結(jié)構(gòu)；由于bit是數(shù)據(jù)的最小單位，所以這種數(shù)據(jù)結(jié)構(gòu)往往是非常節(jié)省存儲空間。比如一個公司有8個員工，現(xiàn)在需要記錄公司的考勤記錄，傳統(tǒng)的方案是記錄下每天正常考勤的員工的ID列表，比如2012-01-01:[1,2,3,4,5,6,7,8]。假如員工ID采用byte數(shù)據(jù)類型，則保存每天的考勤記錄需要N個byte，其中N是當(dāng)天考勤的總?cè)藬?shù)。另一種方案則是構(gòu)造一個8bit（01110011）的數(shù)組，將這8個員工跟員工號分別映射到這8個位置，如果當(dāng)天正常考勤了，則將對應(yīng)的這個位置置為1，否則置為0；這樣可以每天采用恒定的1個byte即可保存當(dāng)天的考勤記錄。
綜上所述，Bitmap節(jié)省大量的存儲空間，因此可以被一次性加載到內(nèi)存中。再看其結(jié)構(gòu)的另一個更重要的特點，它也顯現(xiàn)出巨大威力：就是很方便通過位的運(yùn)算（AND/OR/XOR/NOT），高效的對多個Bitmap數(shù)據(jù)進(jìn)行處理，這點很重要，它直接的支持了多維交叉計算能力。比如上邊的考勤的例子里，如果想知道哪個員工最近兩天都沒來，只要將昨天的Bitmap和今天的Bitmap做一個按位的“OR”計算，然后檢查那些位置是0，就可以得到最近兩天都沒來的員工的數(shù)據(jù)了，比如：
再比如，我們想知道哪些男員工沒來？我們可以在此結(jié)果上再“And”上一個Bitmap就能得到結(jié)果。
b) Bitmap如何做到高速運(yùn)算的？
回憶一下前面，浪費的有兩個部分：其一是存儲空間的浪費，Bitmap比文件強(qiáng)多了，但是仍然有浪費的嫌疑。它需要保存到外部存儲（數(shù)據(jù)庫或者文件），計算時需要從外部存儲加載到內(nèi)存，因此存儲的Bitmap越大，需要的外部存儲空間就越大；并且計算時I/O的消耗會更大，加載Bitmap的時間也越長。其二是計算資源的浪費，計算時要加載到內(nèi)存，越大的Bitmap消耗的內(nèi)存越多；位數(shù)越多，計算時消耗的cpu時間也越多。
對于第一種浪費，最直覺的方案就是可以引入一些文件壓縮技術(shù)，比如gzip/lzo之類的，對存儲的Bitmap文件進(jìn)行壓縮，在加載Bitmap的時候再進(jìn)行解壓，這樣可以很好的解決存儲空間的浪費，以及加載時I/O的消耗；代價則是壓縮/解壓縮都需要消耗更多的CPU/內(nèi)存資源；并且文件壓縮技術(shù)對第二種浪費也無能為力。因此只有系統(tǒng)有足夠多空閑的CPU資源而I/O成為瓶頸的情況下，可以考慮引入文件壓縮技術(shù)。
那么有沒有一些技術(shù)可以同時解決這兩種浪費呢？好消息是有，那就是Bitmap壓縮技術(shù)；而常見的壓縮技術(shù)都是基于RLE（Run Length Encoding，詳見http://en.wikipedia.org/wiki/Run-length_encoding）。
RLE編碼很簡單，比較適合有很多連續(xù)字符的數(shù)據(jù)，比如以下邊的Bitmap為例：
可以編碼為0,8,2,11,1,2,3,11
其意思是:第一位為0，連續(xù)有8個，接下來是2個1，11個0，1個1，2個0，3個1，最后是11個0（當(dāng)然此處只是對RLE的基本原理解釋，實際應(yīng)用中的編碼并不完全是這樣的）。
可以預(yù)見，對于一個很大的Bitmap，如果里邊的數(shù)據(jù)分布很稀疏（說明有很多大片連續(xù)的0），采用RLE編碼后，占用的空間會比原始的Bitmap小很多。
同時引入一些對齊的技術(shù)，可以讓采用RLE編碼的Bitmap不需要進(jìn)行解壓縮，就可以直接進(jìn)行AND/OR/XOR等各類計算；因此采用這類壓縮技術(shù)的Bitmap，加載到內(nèi)存后還是以壓縮的方式存在，從而可以保證計算時候的低內(nèi)存消耗；而采用word（計算機(jī)的字長，64位系統(tǒng)就是64bit）對齊等技術(shù)又保證了對CPU資源的高效利用。因此采用這類壓縮技術(shù)的Bitmap，保持了Bitmap數(shù)據(jù)結(jié)構(gòu)最重要的一個特性，就是高效的針對每個bit的邏輯運(yùn)算。
常見的壓縮技術(shù)包括BBC（有專利保護(hù)）,
WAH（http://code.google.com/p/compressedbitset/）
和EWAH(http://code.google.com/p/javaewah/)。在Apache Hive里邊使用了EWAH。
c) Bitmap在大數(shù)據(jù)計算上的能力？
我們用一個TalkingData Analytics中用戶留存的例子來看Bitmap如何做到用戶回訪的統(tǒng)計。比如想知道某個應(yīng)用，昨天新增的用戶中，有多少人今天又開啟了應(yīng)用（次日留存）。使用過Hive的工程師，不難理解下面語句的含義：
同時，我們使用Bitmap技術(shù)后，同樣實現(xiàn)上述的計算，對比測試顯示出效率的差異是巨大的：
d) 引入Bitmap技術(shù)后，分析系統(tǒng)可能的處理流程大體是什么樣的？
數(shù)據(jù)收集系統(tǒng)收集設(shè)備上傳數(shù)據(jù)，然后分發(fā)給實時處理系統(tǒng)和批量處理系統(tǒng)；
實時系統(tǒng)采用自有計數(shù)器程序，或者基于Storm之類中間件的計數(shù)器程序，計算各類簡單計數(shù)器，然后批量（比如30s或者1min）更新到Redis或者HBase之類的存儲；前端供應(yīng)計數(shù)器類數(shù)據(jù)的服務(wù)通過訪問后臺計算器程序或者是計數(shù)器存儲來給報表系統(tǒng)提供服務(wù)；
批量系統(tǒng)對該批的數(shù)據(jù)按用戶進(jìn)行去重生成/修改某天/某個應(yīng)用的活躍用戶Bitmap，同時可以根據(jù)需要，將機(jī)型、地域、操作系統(tǒng)等等各種數(shù)據(jù)提煉成屬性Bitmap，備用。
報表中針對分析需要，提取各種Bitmap（用戶、屬性……Bitmap），高效的利用CPU/內(nèi)存，通過組合And/Or/Not等基礎(chǔ)計算，最終完成多維交叉計算功能，反饋客戶結(jié)果。
