海量数据查询的一些关键技术

• MPP架构，数据并行化处理

1. 1. 垂直切分，列式存储，列存储只需要将需要查询的数据列load到内存即可，且列式存储压缩比很高，例如bigtable/hbase等列族数据存储、dremel/impala的parquet数据格式。
   2. 水平切分，数据sharding，newsql或者传统数仓都是这么做的，一般是基于key range。除非有大量的hotspot的查询，否则不会用hash方式。

• code gen。把查询的SQL转化为一种bytecode，然后利用利用LLVM进行目标代码优化，同事可以利用SIMD加速等。pgsql，spark，impala 有这方面的工作。
• 单机内存管理优化，抛弃JVM垃圾回收机制，自己管理管理内存；cache friendly、cache oblivious。JVM系叫做off heap memory，例如hbase的bucket cache。如果cache置换较为频繁，内存压力较大时，建议使用堆外内存方式。spark生态圈是有专门的组件alluvia来管理堆外内存。
• 分级存储，memory+ssd+sas/sata分别作为不同的级别的存储介质，热点数据放在high performance tier。Hbase的bucket cache可以配合为ssd存储。
• query predicate push down，查询谓词下推，在一个查询计划执行过程中
  • 将filter谓词选择尽量放在前面步骤执行，例如大表jion，提前进行where过滤，可以有效减少中间结果集的大小，降低网络传输带宽等；
  • 将聚集运算提前汇总，例如mapreduce里面的combinator就是最简单的一种；
  • 其实数据存储格式中最好也包含一些 索引信息，把谓词下推到存储引擎层实现。
• data locality。数据本地化，尽量减少网络传输。例如一个大表join一个小表，将小表广播/复制到大表sharding分片所在的所有节点，在这些节点以大表的sharding跟小表做join然后汇总。hive这种简单的mr处理就很难做到data locality，而mpp的olap数据库这方面要好很多。
• cost based query optimization。接着上述问题，如何判断一个表是小表还是大表呢？两个大表join时，需要进行分布式的hash join还是nested loop join？谓词可否在join前下推，索引是否有效？等等诸如此类的问题的衡量和判断以及策略选择，需要实现一个基于代价的查询计划优化器，查询计划优化器根据一个查询计划的生成树，判断每个策略的代价，选择最小代价的路径生产查询计划；而这个搜索的过程是个NP问题，需要用到启发式搜索的方法。GreenPlum的cbo查询计划优化器ORCA是做的不错的。分布式的cbo还需要支持分布式的表分析。实现的技术难度比较大。
• 索引技术，分布式存储依然可以依赖索引，例如hbase主键索引、二级索引等，Hfile的数据格式优化，主要就是单个hfile内部数据的索引粒度切分。当然分布式的索引会比单机索引技术复杂很多，例如dremel、imapla之类选择放弃索引而采用全表扫描，因为索引有时候也有反作用，太大的索引导致加载数据的时间过程，不如进行暴力扫描。
• bloom filter，主要用于在一个大数据空间判断一个key是否存在本地，有可能存在假阳性。
• data cube技术，以空间换时间，是dremel/impala的另外一个反面。dermal没索引，而data cube可以理解为按照任意一组子列组合做聚集索引，提前把任意一种group by的查询方式，提前统计好存下来。例如apache kylin正式采用这种技术，适合查询大小不经常变化的数据集，增量数据太多太频繁时，build cube的时间比较长影响查询效果。data cube其实是一种物化视图，物化视图跟索引本质上类似，以预计算的冗余数据加速查询的效率。
• 关系数据库与nosq的主要区别，就是nosq去掉了ACID和查询优化器。
  

补充：

       很多技术都是殊途同归，比如oracle exacta是share disk架构，green plum是share nothing，但是对于query push down而言都需要，索引或者cbo也是必须的。