大数据那些事(24):没毕业的IMPALA

自从Dremel出来以后，跟风的行动就开始了。狗狗出品，必有跟屁虫，必有抄袭者，更有炒作的。Cloudera最开始宣传的时候，在2012年，它们做的一个新系统叫Impala，是Dremel的开源版。当然，其他两家批发商也没闲着，MAPR搞了个Drill，Hortonworks也许最忽悠也许最实际，说我们只需要改善 Hive就好，没必要搞其他飞机。

这个事情后来的发展，当然是Hortonworks继续搞它的HIVE，MapR现在天天叫着Drill是Dremel的开源实现。而Cloudera很早之前就悄悄的改变了宣传，不再说自己是Dremel的开源实现了。现在的说法是，我们是一个SQL on Hadoop的实现，用的是MPP(Massively Parallel Processing)的架构。插一句题外话，MPP是一种并行数据库的实现，它的核心思想是说每个处理节点有本地的资源，比如CPU,内存，硬盘，不存在跨网络读取硬盘的操作。至于为什么Cloudera 突然不提自己是Dremel的开源实现了。我想主要是第一，那个Parquet，Cloudera搞的column store format成为了独立的项目，第二，这群写IMPALA的人里面有做传统DB出身的人，看不起Dremel的那套。当然这些都是我的揣测。

IMPALA 2015年正式进入Apache孵化器去孵化，很抱歉的是今年已经2017年，距离孵化已经不止一个年头，距离项目开始做已经4年多了，IMPALA还是在继续孵化中。

IMPALA这篇文章我写得慌，是因为我一没看过源代码，二没在实践中用过这个东西，我对于IMPALA的所有知识都来源于文档。书中自有黄金屋，书中自有颜如玉，书中还有胡说八道的素材。我想这次我是真的要胡说八道了。幸好还有论文，Cloudera在CIDR 2015发表了关于IMPALA的构架的论文。而我又比较习惯于从论文中读出个甲乙丙丁来。

在数据库领域里面，通常SIGMOD和VLDB算是公认第一档次，ICDE则是给牛人接纳那些被SIGMOD VLDB抛弃的论文的收容所，勉强1.5吧，而且有日渐没落的趋势。至于其他的会议很多只能是二三流了，二三流在很多人，尤其是所谓的没有Tenure的Assistant Professor的眼里，就和不入流没区别了。

CIDR在数据库研究领域是个奇葩的会议，不能说好不能说不好。因为是图灵机得主Michael Stonebraker开的，给大家提供个自娱自乐的场所。所以很多牛人买账，常常也有不错的论文。但是更多的感觉是未完成的作品。Cloudera选择这个会议不知道是想和大家说IMPALA是个没有完成的东西呢，还是被SIGMOD VLDB连番拒绝了。我也不知道。

有关IMPALA的构架，我们还是遵循Cloudera在CIDR 2015年发表的论文来说比较靠谱。下面的图是一个基本的体系构架：

IMPALA基本上遵循了一个MPP的数据库应该有的东西，除了有几个相对来说不一样的地方：

1. IMPALA支持多种存储系统，自己并不自带存储系统，但是Parquet显然是支持的最好的。
2. IMPALA里面每个工作进程都是万金油，完全等价，既可以做query compilation，也可以做coordinator，还可以做query execution。这个设计我并没有在其他地方见过。
3. 因为第二个设计，搞出了一套pub-sub的metadata和stats更新系统，我也是第一次见到这样的设计。

在这个系统的布局上，主要包括了三个services：

1. Impala Daemon
2. Statestore Daemon
3. Catalog Daemon

Impala Daemon在每台存储了数据的机器上都部署。这个Daemon很有特点，就是什么事情都能干，既能做coordinator，也能做query compilation，也能做local executor。论文解释的目的是说这样可以做出一个完全对称的系统来。很特别的design。

Catalog Daemon是管理metadata的。Catalog其实是数据库里面的一个术语，通俗的说，指的是Metadata，比如说有多少表啊，每个表名字是什么，有几个列，分别是什么类型，有几个partition，partition的列是哪些之类。Catalog Daemon提供了从其他的Metadata service比如Hive Metastore去读取信息并转换成为Impala自己能理解的数据格式的功能。

StateStore是一个IMPALA和其他的系统非常不一样的地方。这个东西是个pub-sub系统。其存在的意义是为了传输系统里面最新的Metadata，Stats以及其他的信息。IMPALA论文解释因为每个Impala Daemon都有相同的功能，必然有很多Daemon需要获得最新的信息，包括metadata和stats的信息。标准的做法是另外做个service来保存这些最新的信息，大家都访问它。这其实是GFS或者BigTable的做法。当然这个做法离不开ZooKeeper或者Chubby这样的东西。IMPALA觉得这样做不好，容易产生不必要的dependency，效率低。所以它们开发了这个pub-sub系统。

通读文章的另外一个感觉是这个系统应该可以比较好的Scale到几百台机器上，但是几千台机器就不好说了。

文章重点讲了IMPALA的前端和后端。我其实非常的犹豫自己到底要怎么去这一段。有三个选择，第一干脆啥都不说，这有点对不住我良心，第二，认认真真解释每个概念。这个我做不到，足够出一本书了。第三，就是随便乱写几句夹杂很多名词的介绍，如果是做数据库领域的人，那应该能明白，其他人就当做我癫痫发作，在不知所云的抖啊抖啊，然后就过去了。

前端是query compilation和optimization。那个optimizer看起来就是经典的MPP optimizer。第一步先生成一个最优的serial plan，这里包括了经典的query optimization的东西，比如predicate pushdown， join reordering等等。然后再把这个plan变成一个parallel的plan，其做法是在里面插入Exchange operator，还有必要的local/global aggregator。

后端是C++写的用LLVM做code generation的。从里面可以看出来最重要的一点是join和aggregate都是只有hash-base的实现，没有sort-based实现。这里讨论了hash-table如果内存装不下怎么办。这也解释了早年的IMPALA一旦内存用完就直接崩溃，但是现在的IMPALA则没有这个问题了。而分布式join的做法实现了broadcast join和repartition join，也算得上是标配了。

文章提到了搜集的stats，目前也就是最简单的 RowCount， number of Distinct Value这些，没有histogram。论文觉得下面比较重要的就是histogram。文章也提到了IMPALA可以支持多种文件格式，尤其重点的讲述了Parquet，这个Cloudera自己开发出来的Column存储的格式。

论文另外一个非常有意思的章节是关于resource management的，因为YARN的资源管理对于像IMPALA这样比较interactive的系统表现很差，所以这些人就在YARN和IMPALA之间自己搭了一层一半算cache一半算local reallocation的服务。这打脸是piapia的。他们说自己在努力想办法找更好的解决方案，但是不管怎么样吧，我想可能这是Apache不让他们毕业的原因之一。

I必须说出身不同命不同，MPALA2015年进去Apache的孵化器去了，只是我不知道是不是因为Cloudera对Apache的影响力有限，还是因为其他原因，孵化了很久也没孵化出来。狗狗家那个才开源才一年的Beam却早早毕业了。不知道Impala的团队怎么想这个事情。是不是后悔了自己的老板是Cloudera。