转自：http://www.infoq.com/cn/articles/trillion-log-and-data-storage-query-techniques?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage
目前大数据存储查询方案大概可以分为：Hbase系、Dremel系、预聚合系、Lucene系，笔者就自身的使用经验说说这几个系的优缺点，如有纰漏，欢迎一起探讨。
数据查询包括大体可以分为两步，首先根据某一个或几个字段筛选出符合条件的数据，然后根据关联填充其他所需字段信息或者聚合其他字段信息，本文中提到的大数据技术，都将围绕这两方面。
一、Hbase系
笔者认为Hbase系的解决方案（例如Opentsdb和Kylin）适合相对固定的业务报表类需求，只需要统计少量维度即可满足业务报表需求，对于单值查询有优势，但很难满足灵活聚合数据的场景。
而在需要聚合的场景，对于Hbase而言恰恰需要大量scan数据，会非常影响性能。Hbase只有一个简单rowkey的倒排索引，缺少列索引，所有的查询和聚合只能依赖于rowkey，很难解决聚合的性能问题。
随着Hbase的发展，基于Hbase做数据存储包括Opentsdb和Kylin也随之产生，例如Kylin也是一种预聚合方案，因其底层存储使用Hbase，故笔者将其归为Hbase系。在笔者看来，Opentsdb和Kylin的数据结构极其相似，都是将各种维度值组合，结合时间戳拼成rowkey，利用字典的原理将维度值标签化，达到压缩的目的。如此，可以满足快速查询数据的需要，但同时也会受限于Hbase索引，聚合需要大量scan，并不能提升数据聚合的速度。
为了避免查询数据时的聚合，Kylin可以通过cube的方式定制数据结构，在数据接入时通过指定metric来提前聚合数据。这样虽然在一定程度上解决了数据聚合慢的情况，但这是一种典型的空间换时间的方案，组合在维度多、或者有高基数维度的情况，数据膨胀会非常严重，笔者曾遇到存储后的数据比原始数据大90倍的情况。另外，业务的变化会导致重建cube，难以灵活的满足业务需要。
二、Dremel系
Parquet作为Dremel系的代表，相对Hbase的方案，Scan的性能更好，也避免了存储索引和生成索引的开销。但对于数据还原和聚合，相对直接使用正向索引来说成本会很高，而且以离线处理为主，很难提高数据写的实时性。
Google的Dremel，其最早用于网页文档数据分析，所以设计为嵌套的数据结构，当然它也可以用于扁平的二维表数据存储。开源技术中，Parquet算是Dremel系的代表，各种查询引擎(Hive/Impala/Drill)、计算框架甚至一些序列化结构数据（如ProtoBuf）都对其进行了支持，甚至Spark还专门针对Parquet的数据格式进行了优化，前途一片光明，本文主要结合Parquet来展开论述。
Parquet的实时写方面是硬伤，基于Parquet的方案基本上都是批量写。一般情况，都是定期生成Parquet文件，所以数据延迟比较严重。为了提高数据的实时性，还需要其他解决方案来解决数据实时的查询，Parquet只能作为历史数据查询的补充。
Parquet存储是相对索引的存储来说，是一种折中处理，没有倒排索引，而是通过Row Group水平分割数据，然后再根据Column垂直分割，保证数据IO不高，直接Scan数据进行查询，相对Hbase的方案，Scan的性能更好。这种方式，避免了存储索引和生成索引的开销，随着索引Page的完善，相信查询性能值得信赖。而对于数据还原和聚合也没有利用正向索引，而是通过Striping/Assembly算法来解决，这种方式更好能够很取巧的解决数据嵌套填充的问题， 但是相对直接使用正向索引来说成本会很高。
另外，由于是基于Row Group为读写的基本单元，属于粗粒度的数据写入，数据生成应该还是以离线处理为主，很难提高数据写的实时性，而引入其他的解决方案又会带来存储架构的复杂性，维护成本都会相应增加。
三、预聚合系
最近几年，随着OLAP场景的需要，预聚合的解决方案越来越多。其中比较典型的有Kylin、Druid和Pinot。预聚合的方案，笔者不想做过多介绍，其本身只是单纯的为了满足OLAP查询的场景，需要指定预聚合的指标，在数据接入的时候根据指定的指标进行聚合运算，数据在聚合的过程中会丢失metric对应的列值信息。
笔者认为，这种方式需要以有损数据为代价，虽然能够满足短期的OLAP需求，但是对于数据存储是非常不利的，会丢掉数据本身存在的潜在价值。另外，查询的指标也相对固定，没有办法灵活的自由定义所需的指标，只能查询提前聚合好的指标。
四、Lucene系
Lucene算是java中最先进的开源全文检索工具，基于它有两个很不错的全文检索产品ElasticSearch和Solr。Lucene经过多年的发展，整个索引体系已经非常完善，能够满足的的查询场景远多于传统的数据库存储，这都归功于其强大的索引。但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋。
Lucene中把一条数据对应为一个Document，数据中的字段对应Lucene的Field，Field的信息可以拆分为多个Term，同时Term中会包含其所属的Field信息，在Lucene中每一个Document都会分配一个行号。然后在数据接入时建立Term和行号的对应关系，就能够根据字段的信息快速的搜索出相应的行号，而Term与行号的对应关系我们称之为字典。大部分时候查询是多个条件的组合，于是Lucene引入了跳表的思想，来加快行号的求交和求并。字典和跳表就共同组成了Lucene的倒排索引。Lucene从4开始使用了FST的数据结构，即得到了很高的字典压缩率，又加快了字典的检索。
由于ElasticSearch是一个搜索框架，对于所有的搜索请求，都必须搜索所有的分片。对于一个针对内容的搜索应用来说，这显然没有什么问题，因为对应的内容会被存储到哪一个分片往往是不可知的。然而对于日志、行为类数据则不然，因为很多时候我们关注的是某一个特定时间段的数据，这时如果我们可以针对性的搜索这一部分数据，那么搜索性能显然会得到明显的提升。
同时，这类数据往往具有另一个非常重要的特征，即时效性。很多时候我们的需求往往是这样的：对于最近一段时间的热数据，其查询频率往往要比失去时效的冷数据高得多，而ElasticSearch这样不加区分的分片方式显然不足以支持这样的需求。
而另外一方面，ElasticSearch对于聚合分析场景的支持也是软肋，典型的问题是，使用Hyperloglog这类求基数的聚合函数时，非常容易发生oom。这固然跟这类聚合算法的内存消耗相对高有关（事实上，hll在基数估计领域是以内存消耗低著称的，高是相对count，sum这类简单聚合而言）。