需求背景
即席查询AD-HOC ：以单独的SQL语句的形式执行的查询就是即席查询，比如说：HUE里面输入SQL语句并获得结果或者使用dbeaver连接hiveserver2自己键入的SQL代码并获取结果，这样的操作就是即席查询。
我们可以把OLAP分为两大类，即席查询就是其中的一类，另外一类可以被称作固化查询。它们之间的差别在于，固化查询在系统设计和实施时是已知的我们可以在系统中通过分区、预计算等技术来优化这些查询使这些查询的效率很高，而即席查询是用户在使用时临时生产的，查询的内容无法提前运算和预测。
对于数仓来说，即席查询的响应程度也就成为了评估数据仓库的一个重要指标。对于即席查询的支持程度不仅仅是对数据仓库设计的要求，也是对于整个数据平台架构的要求。在整个系统中即席查询使用的越多，对系统的要求就越高，对数仓中数据模型的对称性的要求也越高。（这里所说的对称性指的是：数据模型对所有的查询都是相同的，这也是维度建模的一个优点）
能够快速的执行自定义SQL对即席查询来说是最基本的要求，一般情况下即席查询基本上都是从全量的详细数据中进行过滤筛选，并且需要在短时间内给出查询的结果，这就对响应速度有了严格的要求，从查询输入到用户得到结果必须是秒级的相应。对于Hive这样的离线数仓肯定是满足不了这样的需求，所以就产生各种架构的查询引擎/系统。
引擎介绍和对比
这里我根据不同的实现方式把支持即席查询的系统分成了3个类别：
预计算
Kylin：通过建立cube模型，将事实表、维度、度量之间进行各种的排列组合和预计算，用户查询的结果直接从cube中获取，通过预计算的方式简化查询的计算量。这种方式对于数据模型的要求是最高的，因为要求所有的查询必须满足cube建立时的维度，对于新增维度需要从新进行计算，所以可以说Kylin其实对于固化查询是一个非常好的工具，但是对于查询目标本身就不定的即席查询支持度还是太低了。
数据存储
这个名字其实不太恰当，但是我实在想不出其他的词汇了。
Elasticsearch：他出现在这里并不奇怪，因为作为OLAP的要求他都可以达到，但是因为ES其实是一个搜索引擎，所以查询方面的支持还是比较少，比如不支持index之间的join，另外一个问题就是ES聚合不准，甚至有可能排序的结果也不准，这是因为ES的分片计算框架导致的，具体可以看官网说明：https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html
Apache Druid ：一个分布式的支持实时分析的数据存储系统，旨在快速提取大量事件数据，并在数据之上提供低延迟查询。它核心设计结合了数据仓库，时间序列数据库和搜索系统的想法，从而创建了一个统一的系统。Druid 的最大好处是All In One，基本上安装完成后就可以直接使用，从数据导入到提供查询，完全不需要其他的组件支持Druid 全部都能够搞定。这样很方便，但是Druid 因为结合了时序数据库的特点，在导入时必须要指定时间字段（查询时好像也要指定，只做过测试后面就没线上使用所以不太确认了），使得druid并不适应所有的业务并且和ES一样聚合也不准，对于传统的数仓迁移或升级，这个就不要考虑了。Druid 更适合带有时间字段的数据，最显而易见的就是用户访问行为的数据或者监控类的数据。
MPP分布式并行处理
Greenplum：其实GP出现的时间是比较早的，应该是06，07年与Hadoop基本上是一同发布的。关系型数据库Postgres的团队因为hadoop的出现开始关注SQL on Hadoop的开发，慢慢成立了商业公司并开始商业化，所以GP才以Postgres作为底层的存储。后来以GP的架构开发了HAWQ （可以理解为GP的MPP 架构，但是后端不使用Postgres，而是HDFS、Hive、HBase）。使用GP的优点是简单方便，跟普通使用数据库是一样的，但是缺点也很明显,集群规模受物理Master限制,应用中很难超过20个物理节点，所以对于中等数据量还是可以的，中小公司几十TB到几百TB大小的一般应用是可以的。另外还一个要说明的是因为是独立架构，所以对于Hadoop生态的兼容性几乎为0。
Oracle RAC：其实GP做的事情RAC也是一样的，都是把表做成Hash Range分区，理论上都是一样的只不过实现方式不一样，Oracle最大的问题是扩展能力也有限，其实还是钱有限
