druid kylin 对比

KYLIN、DRUID是目前主流的OLAP引擎，本文尝试从数据模型和索引结构两个角度，分析这几个引擎的核心技术，并做出druid kylin 对比。在阅读本文之前希望能对KYLIN、DRUID有所理解。

KYLIN数据模型

Kylin的数据模型本质上是将二维表（Hive表）转换为Cube，然后将Cube存储到HBase表中，也就是两次转换。

第一次转换，其实就是传统数据库的Cube化，Cube由CuboId组成，下图每个节点都被称为一个CuboId，CuboId表示固定列的数据数据集合，比如“ AB” 两个维度组成的CuboId的数据集合等价于以下SQL的数据集合：

select A, B, sum(M), sum(N) from table group by A, B

第二次转换，是将Cube中的数据存储到HBase中，转换的时候CuboId和维度信息序列化到rowkey，度量列组成列簇。在转换的时候数据进行了预聚合。下图展示了Cube数据在HBase中的存储方式。

KYLIN索引结构

因为Kylin将数据存储到HBase中，所以kylin的数据索引就是HBase的索引。HBase的索引是简化版本的B+树，相比于B+树，HFile没有对数据文件的更新操作。

HFile的索引是按照rowkey排序的聚簇索引，索引树一般为二层或者三层，索引节点比MySQL的B+树大，默认是64KB。数据查找的时候通过树形结构定位到节点，节点内部数据是按照rowkey有序的，可以通过二分查找快速定位到目标。

KYLIN小结：适用于聚合查询场景；因为数据预聚合，Kylin可以说是最快的查询引擎（group-by查询这样的复杂查询，可能只需要扫描1条数据）；kylin查询效率取决于是否命中CuboId，查询波动较大；HBase索引有点类似MySQL中的联合索引，维度在rowkey中的排序和查询维度组合对查询效率影响巨大；所以Kylin建表需要业务专家参与。

DRUID数据模型

Druid数据模型比较简单，它将数据进行预聚合，只不过预聚合的方式与Kylin不同，kylin是Cube化，Druid的预聚合方式是将所有维度进行Group-by，可以参考下图：

DRUID索引结构

Druid索引结构使用自定义的数据结构，整体上它是一种列式存储结构，每个列独立一个逻辑文件（实际上是一个物理文件，在物理文件内部标记了每个列的start和offset）。对于维度列设计了索引，它的索引以Bitmap为核心。下图为“city”列的索引结构：

首先将该列所有的唯一值排序，并生成一个字典，然后对于每个唯一值生成一个Bitmap，Bitmap的长度为数据集的总行数，每个bit代表对应的行的数据是否是该值。Bitmap的下标位置和行号是一一对应的，所以可以定位到度量列，Bitmap可以说是反向索引。同时数据结构中保留了字典编码后的所有列值，其为正向的索引。

那么查询如何使用索引呢？以以下查询为例：

select site, sum(pv) from xx where date=2020-01-01 and city=’bj’ group by site

city列中二分查找dictionary并找到’bj’对应的bitmap

遍历city列，对于每一个字典值对应的bitmap与‘bj’的bitmap做与操作

每个相与后的bitmap即为city=’bj’查询条件下的site的一个group的pv的索引

通过索引在pv列中查找到相应的行，并做agg

后续计算

DRUID小结：Druid适用于聚合查询场景但是不适合有超高基维度的场景；存储全维度group-by后的数据，相当于只存储了KYLIN Cube的Base-CuboID；每个维度都有创建索引，所以每个查询都很快，并且没有类似KYLIN的巨大的查询效率波动。

druid kylin 对比小结

1.KYLIN、DRUID只适合聚合场景

2.聚合场景，查询效率排序：KYLIN > DRUID

3.KYLIN建表需要业务专家参与

4.KYLIN查询效率可能产生巨大差异

5.DRUID少量算子支持向量化、KYLIN目前还不支持向量化计算。