多维分析引擎比较
前言
在大数据时代的今天，数据分析的体量、数据分析的速度都变得越来越重要，也是考验数据分析引擎的重点。在数据分析领域，如果有一款引擎在易用性，数据体量，查询效率上都能满足，这一定是一款好的分析引擎，现实是每个引擎都有优缺点，在选型的时候需要根据业务需求来确定选哪个合适。比如数据量小，查询方便选用什么？ 数据量大，分析的维度有限？ 数据量大，所有维度都有可能用来作为分析。每种业务场景需要的引擎也会不一样。下面总结了几种开源的常用的引擎，对比一下这些引擎的优缺点。
Greenplum
基于MPP的架构，底层表主要为postgresql，分为master节点及segment节点，master节点管理查询，segment为数据节点，执行数据的查询、存储。基于大宽表的方式，无需预计算，所有维度均可进行分析；缺点是并发量支持的比较少，查询速度非实时，只能做到准实时，如几秒到几十秒的RT；不支持大量的实时写入，一般通过segment来装载数据。在标签圈人的场景使用的比较多。
ES
ES之前的定位一直是文本的倒排索引引擎，用于文本搜索的场景。近几年慢慢转化成一个数据分析平台。能够提供一些简单的count，group等功能。ES内部使用lucene的倒排索引，这种结构适合基数较大的列，比如人名，单词等。ES能提供完美的索引方案，无需定义schema，可以直接插入json数据进行索引，在数据量小的时候是个不错的选择。缺点比较明显，数据量较大的时候查询性能会比较慢，实时写入到性能也比较差。
Druid
Druid提供基于时间维度的存储，时间是druid必须包含的维度，druid分为实时数据、历史数据节点，来提供快速的实时数据摄入和查询。支持数据量大，支持实时流式数据摄入，查询灵活且快速。
kylin
分布式的分析引擎，提供了在Hadoop之上的SQL查询接口及多维分析能力。可以支持超大规模数据，查询能在亚秒内返回。kylin在Hadoop hive表上做了一层缓存，通过预计算和定期任务，把很多数据事先存在以HBASE为基础的OLAP cube中，大部分查询可以访问hbase获取，而不需要访问hive原始数据。这种方式缺点，因为采用的预计算的方式，所以灵活性上需要有些取舍，需要事先定义好查询模式，结构，且不支持实时录入的能力。
opentsdb
一种时序类的数据库，支持数千亿的数据点，提供精确查询服务。opentsb通过预先定义好的维度，将rowkey进行设计放到Hbase中，通过hbase的keyrange进行快速查询。但是在多个维度组合查询时，查询效率会明显减低，尤其是在keyrange跨度比较大的时候。