搜索引擎技术,分析数据库技术,分布式计算引擎技术这三股力量正在快速地彼此融合。举例证如下
Hive一开始只是用sql的方式描述map/reduce的逻辑,是一个典型的分布式计算引擎。这是分布式计算引擎向OLAP方向靠拢的第一步。
Hive推出不久就被发现,虽然用的SQL但是性能离数据库还差很远。很快就有人提出是不是要给Hive加上数据库一样的索引。这明显就是分布式计算引擎向分析数据库的方向靠拢。
Parquet是一种列式文件,用于加速hive/impala这样的分布式计算引擎的查询速度。使用 parquet 加上了索引的 hive/impala/spark 这些已经很难说与 OLAP 数据库的差别是什么了。
这些Hive的衍生物直接上来就是瞄着OLAP去的。各种sql on hadoop的方案。
另外一个方向的融合是搜索引擎技术快速地向OLAP融合。Elasticsearch公司更名为了Elastic,因为越来越多的人开始用Elasticsearch不是search,而是analytics,也就是跑SQL。
Elasticsearch底层的Lucene引入了DocValues之后,数据可以按列存储(和parquet一样),使得Elasticsearch几乎可以当成一个列式数据库来使用了。
另外Elasticsearch在Lucene的基础上大幅加强了Aggregation的功能,利用其冗长但是强大的aggregation dsl可以表达出比SQL还要复杂的聚合逻辑。
腾讯的Hermes数据库( http://data.qq.com/article?id=817 )就是基于Lucene/Solr实现的分析型数据库
因为Elasticsearch性能实在太出众了,但是dsl接口不好使。有人拿Elasticsearch做为底层,上层封装了一个SQL接口,从何正式变成了一种数据库,叫 http://crate.io
http://groonga.org/docs/characteristic.html 日本人写了一个搜索引擎,而这个搜索引擎同时还可以作为mysql可插拔的存储引擎使用,从而把mysql变成一种支持全文检索的列式数据库。
一个更加有趣的方向是Spark开始和OLAP数据库和Elasticsearch勾搭在一起。利用把Elasticsearch查询映射成Spark的RDD,可以把一条SQL的where部分放在Elasticsearch里分布式执行(所谓filter push down优化),然后把分布式的group by 和 projection 由Spark来完成。
这三个技术各自有独自看重的内在实现方式
* 搜索引擎:重点是inverted index,索引的压缩存储和高效检索
* 分析数据库:重点是column oriented storage,利用列式存储快速地在查询时暴力扫描
* 分布式计算引擎:从一开始就是map reduce,关注的是分区和分布式执行
实际上三家是从不同的角度切入了同一个问题。不过这已经不是一招鲜的时代了。一个好的搜索引擎需要inverted index/column oriented storage/map reduce,三者都要。一个好的OLAP也是inverted index/column oriented storage/map reduce三个都要的。
目前从趋势上来看风头最火的是 Elasticsearch,最佳的组合是 Spark + Elasticsearch。
最科幻的未来组合是把Spark + Elasticsearch 做深度的整合,去掉 Elasticsearch 自己的分布式层,完全靠 Spark 做分布式计算。要是能再配备一个实时计算管道作为灵活的入库渠道和物化视图就更牛x了。