接着上篇文章继续聊聊交互式查询，交互式查询崛起的原因是人类的懒惰本质，自从谷歌发表了 Dremel 论文后，相似的计算引擎不断地出现，在这篇文章里，针对几种典型的计算引擎简单聊聊。
第一波出现的 Dremel 的开源实现是 Cloudera 的 Apache Impala 和 MapR 的 Apache Drill 。
因为我们团队的交互式查询的底层引擎使用的是 Apache Impala ，对此也比较熟悉。Impala 与传统的大数据框架不同，它是由 C 写的，而不是常见的 JVM 上的语言。使用 C 的好处不言而喻，速度快、没有 GC ，更像是一款数据库，但是缺点也很明显，在我国，使用 C 的人还是少，玩 Java 的一大堆，这导致了 Impala 出了 bug 不容易解决。
Impala 的源码没有怎么读过，但是它的论文倒是拜读了一次。首先，Impala 是一个类似于 MPP 的架构，所谓 MPP 架构就是每个节点都是等价的，节点之间通过网络进行通信。不过与一般的 MPP 数据库不同的是，Impala 本身是没有存储系统的，而是通过接口的方式对接外部存储系统，例如 HDFS 、Kudu 和 Hbase。当然支持最好的是 HDFS 的 Parquet 文件格式和 Kudu 。
与常见的数据库设计不一样，一般的数据库都会选择单独的节点处理 SQL 解析等元数据，而 Impala 每个节点都是一样的，完全等价，既可以做 query compilation，也可以做coordinator，还可以做query execution 。这样的设计有一个好处就是，哪个节点宕机了都不需要担心会影响集群的可用性。不过使用了这个设计，就必然要引入一套类消息系统，同步各个节点的元数据信息。在 Impala 里这个类消息系统被称为 StateStore ，专门用于传输系统里面最新的元数据信息、统计信息等等。
Impala 还完全兼容 Hive 的元数据库，因此 Impala 还设计了一个 Catalog Daemon 去管理元数据，把 Hive 的元数据库转换成 Impala 能理解的元数据信息，除此以外，为了最大化利用，还会存储某张表的相关统计信息，比如存储的文件有哪些、表的数据类型有哪些甚至还有某些列的最大值等基础统计数据。
Impala 是一个典型的交互式查询引擎，可以理解为数据库和MapReduce 的一个中间产品。它既不像数据库那样，有着自己的存储系统，从而可以最大化的提升数据处理效率，也不像 MapReduce 简单粗暴，而是引进了很多数据库里的优化技术，相比于 MapReduce 大大加速了计算速度。
回到 Impala 本身，这种架构放到几十台机器上百台机器，应该是没啥问题的，但是要像 MapReduce 那样稳定运行在几千台机器上，还需要慎重考虑。
