以前也玩过spark，但这次玩，是因为spark从1.4版本后使spark sql独立出来，想必一定不赖；另外，还支持DataFrame，底层存储支持parquet，甚至orc file。

    一、parquet 和 orc 对比

    我专门查了查parquet 和 orc，网上很多，我只说关键的。

    1、parquet 和 orc 都是用于存储数据的底层格式，都是列式的。不难想象，对于单查某一个或2个列，因为不涉及其他列，所以速度会很快。

    2、都能实现列压缩。如连续3个一样的数据放在一起，他们可以只写一遍，标示上为3次即可。压缩不压缩，我倒不怕空间浪费，关键是因为减小了体积，所以查询速度势必加快，所以这是好的。

    3、在一定体积内（无论多少行），都是放在一起的，所以他们列式的前提，是先多行在一起，然后在多行内的列独立。

    4、不同：orc 格式，在文件头有一个粗粒度索引，如此列的最大值和最小值。如果您查询的值不在此列包，则跳过不查，所以orc格式在查询结果不大的情况下，会速度快很多。而parquet则没有此特征。

    5、parquet 不支持Update，不支持ACID。

    二、spark 和 hive 

    先说好的：如果查询结果非常大，且需要将这些大的查询结果来回倒腾对比，建议使用spark。 spark的 DataFrame也很好使，且支持lambda表达式，是完全的程序员式的数据检索方式，很符合我的风格要求（.NET早就有了）。还有，可以将DataFrame结果存储为parquet，甚至orc。

    但结果很让我失望，我想将结果存储为orc，但他要求先配置hive，要知道，安装一个spark就很得先安装hadoop，都是难安装的主，再安装hive，所以他们之间会很复杂，出错后，很难找原因。

    而且关键的是，hive必然用mapreduce，所以启动一次就会很慢，对于焦躁的用户来说，速度太慢了。

    Spark即使用parquet格式，也必须每次在用的时候重新抽取，而且他不管你数据在那台机器上，都统统检索一遍，所以，我想用不必每个数据包都检索的orc格式，但却非常困难。

    所以，对于结构化数据的快速查询，因为没有索引，所以是不理想的（如果需要全部检索，大批量和大批量迭代比对，准备花个几个小时的情况，是适用的）。特别是用作数据库来讲，单用spark来实现，结果是困难的。数据进库也比较麻烦，我倒是写了一个接口，但毕竟没有kettle等etl工具的支持啊。

    三、impala 和 hive 

    impala是为了实现实时查询的，没有像hive一样仅仅把SQL翻译成MapReduce，而是直接读取HDFS，所以速度是快的。甚至新版本可以parquet存储。但：

    1、impala不能实现删除数据。

    2、目前不支持orc 格式。平时都是行式查询，即使使用了parquet，也不能跳过不必要的行组。

    3、impala可秒级检索，但却不能将实时数据立即加载到数据集中，所以impala是准实时。

    毕竟 impala要用到 hive的表结构，所以，有人说，他们之间要是能底层一套数据，impala用做即时查询，hive（必须map + reduce，所以慢）用作批量离线分析，就好了。但他们之间却是：impala用parquet格式，hive用orc格式，所以是不能一个底层的。对我来讲最遗憾的是：如果他们的底层颠倒一下就好了：impala用orc，hive用parquet，那我就选择 impala 了。

    标准的Hive使用场景为：定期进行数据的批量加载，再进行批处理计算。这个数据加载周期短则一个小时，长的甚至每天才加载一次数据。更糟糕的是，分析计算本身也往往需要数分钟甚至数小时的时间。因此这种计算模式往往无法满足结果的时效性。

    四、hbase

    hbase是列式数据库，为了学习他，我还在当当上买了本书。hbase也是用于实时查询的，所以比一般的hadoop要快，当然了，他也是建立在hadoop上的。

    hbase是很多行组成一个region，每个region有一个rowkey（类似于rowid），这个rowkey可以自己定义，根据这个rowkey，可以实现最快速的定位。但：

    1、hbase还是在多行集合的内部，实现的列单独存储。所以要定位某个非rowkey，还是要启动所有的服务器来查找每个region内的某列的。

    2、没有列压缩，起码我没有找到这方面的资料。前面说了，列压缩可以实现减小体积，减小硬盘I/O，加快检索速度。

    五、gbase 8a MPP

    gbase 8a MPP，是国产的一个列式并行数据库。优点：

    1、纯列式，每个列在操作系统内，都是单独的文件，你可以看到的，所以检索是势必减少I/O。

    2、列式压缩。有很多种压缩方式，如NULL不实际存，只在包头内标注；多行连续一样时，可以只存一次，减小了体积。

    3、粗粒度索引。包头上注明了此列包，最大值和最小值是什么，如果你查的东西不在此列，则直接跳过此包。

    4、安装、维护极简单。由于不建立在hadoop上，所以虽然是安装在linux上，但即使不会linux的人，看了说明书，5分钟就可上手安装，连ssh都不用配，再5分钟就可安装完毕。因为有粗粒度索引，所以连数据优化工程师都可以免了，比oracle简单太多了。懒人的福音，当然如果懂得原理更多，速度也会有更好的优化。

    5、可以建立全文索引！

    缺点：

    1、只支持哈希索引。

    2、sql语句虽然支持的非常丰富，但在复杂查询时，后台的查询语句顺序，不是你想象的那样，甚至出现排序速度比不排序速度快的情况。

    3、导入数据较困难。虽然可可以支持kettle，但总体上讲，导入数据还是需要有很多技巧的，上手慢。

    

    以上是我为了挑选合适的大数据库，所做的尝试和对比，上面只写了最关键的对比，细节没有再描述。其中付出了半年多的日日夜夜，即使如此，也仍然有不对之处，欢迎拍砖。