SQL on Hadoop系统的最新进展

　　为什么非要把SQL放到Hadoop上? SQL易于使用。

　　那为什么非得基于Hadoop呢?the robust and scalable architecture of Hadoop

　　目前SQL on Hadoop产品主要有以下几种：

　　Hive, Tez/Stinger, Impala, Shark/Spark, Phoenix, Hawq/Greenplum, HadoopDB, Citusdata等。本文主要讨论Hive, Tez/Stinger, Impala, Shark以及传统开源数据仓库brighthouse的特点和最新进展;下一篇文章会讨论Phoenix, Hadapt/HadoopDB, Hawq/Greenplum。

　　在互联网企业中一般的基于Hadoop的数据仓库的数据来源主要有以下几个：

　　1，通过Flume/Scribe/Chukwa这样的日志收集和分析系统把来自Apache/nginx等Server cluster的日志收集到HDFS上，然后通过Hive创建Table时指定SerDe把非结构化的日志数据转化成结构化数据。

　　2，通过Sqoop这样的工具把用户和业务维度数据(一般存储在Oracle/MySQL中)定期导入Hive，那么OLTP数据就有了一个用于OLAP的副本了。

　　3，通过ETL工具从其他外部DW数据源里导入的数据。

　　目前所有的SQL on Hadoop产品其实都是在某个或者某些特定领域内适合的，没有silver bullet。像当年Oracle/Teradata这样的满足几乎所有企业级应用的产品在现阶段是不现实的。所以每一种SQL on Hadoop产品都在尽量满足某一类应用的特征。

　　典型需求：

　　1, interactive query (ms~3min)

　　2，data analyst, reporting query (3min~20min)

　　3，data mining, modeling and large ETL (20 min ~ hr ~ day)

　　4，机器学习需求(通过MapReduce/MPI/Spark等计算模型来满足)

　　Hive

　　Hive是目前互联网企业中处理大数据、构建数据仓库最常用的解决方案，甚至在很多公司部署了Hadoop集群不是为了跑原生MapReduce程序，而全用来跑Hive SQL的查询任务。

　　对于有很多data scientist和analyst的公司，会有很多相同table的查询需求。那么显然每个人都从hive中查数据速度既慢又浪费资源。我们在online的数据库系统部署的时候都会在DB前面部署Redis或者memcache用于缓存用户经常访问的数据。那么OLAP应用也可以参考类似的方法，把经常访问的数据放到内存组成的集群中供用户查询。

　　Facebook针对这一需求开发了Presto，一个把热数据放到内存中供SQL查询的系统。这个设计思路跟Impala和Stinger非常类似了。使用Presto进行简单查询只需要几百毫秒，即使是非常复杂的查询，也只需数分钟即可完成，它在内存中运行，并且不会向磁盘写入。Facebook有超过850名工程师每天用它来扫描超过320TB的数据，满足了80%的ad-hoc查询需求。

　　目前Hive的主要缺点：

　　1，data shuffle时网络瓶颈，Reduce要等Map结束才能开始，不能高效利用网络带宽

　　2，一般一个SQL都会解析成多个MR job，Hadoop每次Job输出都直接写HDFS，性能差

　　3，每次执行Job都要启动Task，花费很多时间，无法做到实时

　　4，由于把SQL转化成MapReduce job时，map,shuffle和reduce所负责执行的SQL功能不同。那么就有Map->MapReduce或者MapReduce->Reduce这样的需求。这样可以降低写HDFS的次数，从而提高性能。

　　目前Hive主要的改进(主要是体现在 hive 0.11版本上)：

　　1，同一条hive sql解析出的多个MR任务的合并。

　　由Hive解析出来的MR jobs中有非常多的Map->MapReduce类型的job，可以考虑把这个过程合并成一个MRjob。https://issues.apache.org/jira/browse/HIVE-3952

　　2，Hive query optimizer(查询优化器是Hive需要持续不断优化的一个topic)

　　http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.0.2/ds_Hive/optimize-joins.html

　　Joins where one side fits in memory

　　Star schema join的改进，就是原来一个大表和多个小表在不同column匹配的条件下join需要解析成多个map join + MR job，现在可以合并成一个MR job

　　这个改进方向要做的就是用户不用给太多的hint，hive可以自己根据表的大小、行数等，自动选择最快的join的方法(小表能装进内存的话就用map join，Map join能和其他MR job合并的就合并)。这个思路跟cost-based query optimizer有点类似了，用户写出来的SQL在翻译成执行计划之前要计算那种执行方式效率更高。

　　3，ORCFile

　　ORCFile是一种列式存储的文件，对于分析型应用来说列存有非常大的优势。 http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.0.2/ds_Hive/orcfile.html

　　原来的RCFile中把每一列看成binary blob，没有任何语义，所以只能用通用的zlib,LZO,Snappy等压缩方法。

　　ORCFile能够获取每一列的类型(int还是string)，那么就可以使用诸如dictionary encoding, bit packing, delta encoding, run-length encoding等轻量级的压缩技术。这种压缩技术的优势有两点：一是提高压缩率;二是能够起到过滤无关数据的效果

　　现在ORCFile中主要有三种编码：

　　bit编码，所有数据类型都可以用。Google’s protocol buffers and uses the high bit to represent whether this byte is not the last and the lower 7 bits to encode data

　　run-length encoding(行程长度压缩算法)，int类型专用。

　　dictionary encoding，string类型专用。同时这个dictionary还能帮助过滤查询中的predicate条件。

　　Run length Encoding对某些列压缩会减少存储3-4个数量级，对内存提升也有2-3个数量级，Dictionary Encoding一般对磁盘空间减少大概20倍，对内存空间大概减少5倍，根据Google PowerDrill的实验，在常见的聚合查询中这些特殊的编码方式会对查询速度有2-3个数量级的提升.

　　Predicate Pushdown:原来的Hive是把所有的数据都读到内存中，然后再判断哪些是符合查询需求的。在ORCFile中数据以Stripe为单元读取到内存，那么ORCFile的RecordReader会根据Stripe的元数据(Index Data，常驻内存)判断该Stripe是否满足这个查询的需求，如果不满足直接略过不读，从而节省了IO。

原文转自：http://yanbohappy.sinaapp.com/?p=381