HBase是建立Hadoop File System上的一层Key-Value Pair 存储服务器。 HBase能够支持Key-Value快速插入，修改及删除，和单个Key到Value快速查询。那么Hbase适合做BI分析的数据源吗？筛选(Filtering)和聚合(Aggregation)是BI中的基本运算，所以我们首先要知道HBase是否能支持快速的筛选和聚合运算。
MapReduce是Hadoop系统上的基本计算框架，HBase用户可以使用MapReduce来进行筛选和聚合运算。但是我们知道MapReduce的反应时间一般在几十秒或几分钟以上，这对于实时BI运算过慢。所以我们想调查一下HBase Coprocessor是否是一个更好的选择。
HBase Coprocessor是一个比MapReduce更简单的运算系统。Coprocessor相当于是在HBase Region Server上的一个存储过程 （Stored Procedure）。HBase的运算客户可以调用（通过execCoprocessor）在Region Server上的Coprocessor， 来做筛选和聚合运算。 Coprocessor运算Region Server本地进行，然后Region Server将部分结果传递给客户端，最后结果将在客户端组装完成。 下图展示了用Corprocessor做Count运算的示意图。
程序员可以编写自己的Coprocessor程序，用HBase的Scan Object来做筛选，用Java 代码来实现如Sum（）， Avg（）的聚合运算。
由于HBase本身的API不支持Table Join，我们可以假设所有的数据仓库的数据都存贮在一个巨型的HBase Table上。
在逻辑层面上， HBase Table相当于一个3维Map--用（Row， Column, TimeStamp）,我们可以找到相应的值。在具体实现中，HBase Table的数据是按照一个一个数据单元存储的，每个数据单元除了值域以外，还有其它的域，如RowKey, Column ID，TimeStamp。这样数据单元的很大一部分空间实际上被用来存储那些Metadata. 这种存储格式对于稀疏报表十分有效，但是当报表的数据密度变大时，其存储效率就大打折扣了。而一个典型的数据仓库的数据表的数据密度往往接近于100%，这时HBase Table的存储效率要远远低于一个简单的2维报表，如一个关系型数据库报表或一个CSV报表。
我们测试表明，当数据报表较小时（200—300MB），coprocessor要稍慢于MySQL，但要快于MapReduce. 当数据报表变大时，coprocessor将会比MySQL慢的更多甚至比MapReduce还要慢。而在MapReduce里面，一样的数据，CSV和HBase Table相比，CSV要快很多。
综上所述，博主认为，HBase Table本身的存储格式并不适合典型的BI运用。
但是对于一些简单的报表应用，如Facebook Insight, HBase依然可以被用作数据源。在Facebook Insight中，每个用户有一些Count度量，如Click#，Impression #等，用户ID（作为Key）和这些Count度量都存在一张HBase Table里，Insight可以根据Web Log对于每个用户的度量做实时更新。而每个用户的度量数值亦可以被实时读取。由于这里不牵扯到更加复杂的筛选和聚合运算， HBase可以发挥很好作用。