SQL on Hadoop相关技术分享(1)

大数据是现在非常热门的一个话题，大数据能预测未来发生的事情，那么从工程或者技术的角度来看，大数据的核心是如何存储、分析、挖掘海量的数据解决实际的问题，大数据有什么优点和缺点。那么对于一个工程师或者分析师来说，如何查询和分析TB/PB级别的数据是在大数据时代不可回避的问题。SQL on Hadoop就成为了一个重要的工具。为什么非要把SQL放到Hadoop上？ SQL易于使用；那为什么非得基于Hadoop呢？Hadoop架构具备很强的鲁棒性和可扩展性。本文从技术架构和最新进展两个角度分析一下各种SQL on Hadoop产品的优缺点和适用范围：Hive、Tez/Stinger、Impala、Shark/Spark、Phoenix、 Hdapt/HadoopDB、Hawq/Greenplum。
在互联网企业和有大数据处理需求的传统企业中，基于Hadoop构建的数据仓库的数据来源主要有以下几个：

• 通过Flume/Scribe/Chukwa这样的日志收集和分析系统把来自Apache/Nginx的日志收集到HDFS上，然后通过Hive查询。
• 通过Sqoop这样的工具把用户和业务维度数据（一般存储在Oracle/MySQL中）定期导入Hive，那么OLTP数据就有了一个用于OLAP的副本了。
• 通过ETL工具从其他外部DW数据源里导入的数据。
  

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

• interactive query （ms~3min）
• data analyst，reporting query （3min~20min）
• data mining，modeling and large ETL （20 min ~ hr ~ day）
• 机器学习需求（通过MapReduce/MPI/Spark等计算模型来满足）
  

Tez/Stinger
Tez是一种新的基于YARN的DAG计算模型，主要是为了优化Hive而设计的。目前Tez/Stinger主要是Hortonworks在搞，他们希望以后把Hive SQL解析成能够在Tez上跑的DAG而不是MapReduce，从而解决计算实时性的问题。Tez的主要特点有：

• 底层执行引擎不再使用MR，而是使用基于YARN的更加通用的DAG执行引擎
• MR是高度抽象的Map和Reduce两个操作，而Tez则是在这两个操作的基础上提供了更丰富的接口。把Map具体到Input、Processor、 Sort、Merge、Output，而Reduce也具体化成Input、Shuffle、Sort、Merge、Processor、 Output。其实这个跟Spark有点类似了，都是提供更丰富的可操作单元给用户。
• 传统的Reduce只能输出到HDFS，而Tez的Reduce Processor能够输出给下一个Reduce Processor作为输入。
• Hot table也放到内存中cache起来
• Tez service：预启动container和container重用，降低了每次Query执行计划生成之后Task启动的时间，从而提高实时性。
• Tez本身只是YARN框架下得一个library，无需部署。只需指定mapreduce.framework.name=yarn-tez
  

Tez/Stinger还有一个最重要的feature : Vectorized Query Execution
目前Hive中一行一行的处理数据，然后调用lazy deserialization解析出该列的Java对象，显然会严重影响效率。Vectorized Query Execution把多行数据同时读取并处理（基本的比较或者数值计算），降低了函数调用的次数，提高了CPU利用率和cache命中率。
Hive->Tez/Stinger未来工作的主要方向：Cost-based optimizer，基于统计选择执行策略，例如多表JOIN时按照怎样的顺序执行效率最高。统计执行过程中每个中间表的Row/Column等数目，从而决定启动多少个MR执行。
Impala  
Impala可以看成是Google Dremel架构和MPP (Massively Parallel Processing)结构的混合体，目前主要是Cloudera在主导这个项目。
优点：

• 目前支持两种类型的JOIN：broadcast join和partition join。对于大表JOIN时由于内存限制，装不下时就要dump部分数据到磁盘，那样就会比较慢。
• Impala各个任务之间传输数据采用的是push的方式（MR采用的是pull的方式），也就是上游任务计算完就会push到下游，这样能够分散网络压力，提高job执行效率。
• Parquet列存格式，同时能够处理嵌套数据。通过嵌套数据以及扩展的SQL查询语义，在某些特定的场景上避开了JOIN从而解决了一部分性能的bottleneck。
• Cloudera Manager 4.6以后会有slow query的分析功能。
• Runtime Code Generation
  

缺点：

• Impala不会按照group by的列排序
• 目前不支持UDF，Impala 1.2即将支持Hive UDFs和Impala native UDFs and UDAs
• 不支持像Hive的Serializer/Deserializer，从而使得它做从非结构化到结构化数据的ETL工作比较麻烦。所以本质上讲Impala适合MR配合做ETL之后的查询工作。
• 由于Impala的设计初衷是short query，所以不支持fault tolerance。如果参与查询的某个node出错，Impala将会丢弃本次查询。
• 安全方面的支持还比较差。impalad之间传输的数据没有加密，不支持表或者列级别的授权。
• 每个PlanFragment执行尽量并行化，但是有的时候并不是很容易。例如Hash Join需要等到其中一个表完全Scan结束才能开始。
  

虽然有这么多缺点，但是很多公司还是开始尝试Impala了。以百度为例，百度尝试把MySQL接入Impala的后端作为存储引擎，同时实现相应操作对应的PlanFragment，那么用户来的query还是按照原来的解析方法解析成各种PlanFragment，然后直接调度到对应的节点(HDFS DataNode/HBaseRegionServer/MySQL)上执行。会把某些源数据或者中间数据放到MySQL中，用户的query涉及到使用这部分数据时直接去MySQL里面拿。

Hive  Hive是目前互联网企业中处理大数据、构建数据仓库最常用的解决方案，甚至在很多公司部署了Hadoop集群不是为了跑原生MapReduce程序，而全用来跑Hive SQL的查询任务。
对于有很多data scientist和analyst的公司，会有很多相同表的查询需求。那么显然每个人都从Hive中查数据速度既慢又浪费资源。如果能把经常访问的数据放到内存组成的集群中供用户查询那样效率就会高很多。Facebook针对这一需求开发了Presto，一个把热数据放到内存中供SQL查询的系统。这个设计思路跟Impala和Stinger非常类似了。使用Presto进行简单查询只需要几百毫秒，即使是非常复杂的查询，也只需数分钟即可完成，它在内存中运行，并且不会向磁盘写入。Facebook有超过850名工程师每天用它来扫描超过320TB的数据，满足了80%的ad-hoc查询需求。
目前Hive的主要缺点：

• data shuffle时网络瓶颈，Reduce要等Map结束才能开始，不能高效利用网络带宽。
• 一般一个SQL都会解析成多个MR job，Hadoop每次Job输出都直接写HDFS，大量磁盘IO导致性能比较差。
• 每次执行Job都要启动Task，花费很多时间，无法做到实时。
• 由于把SQL转化成MapReduce job时，map、shuffle和reduce所负责执行的SQL解析出得功能不同。那么就有Map->MapReduce或者MapReduce->Reduce这样的需求，这样可以降低写HDFS的IO数量，从而提高性能。但是目前MapReduce框架还不支持M->MR或者MR->R这样的任务执行。
  

目前Hive主要的改进：
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）
例如JOIN顺序的优化，就是原来一个大表和多个小表在不同column匹配的条件下JOIN需要解析成多个Map join + MR job，现在可以合并成一个MR job。
这个改进方向要做的就是用户不用给太多的hint，hive可以自己根据表的大小、行数等，自动选择最快的join的方法（小表能装进内存的话就用Map join，Map join能和其他MR job合并的就合并）。这个思路跟cost-based query optimizer有点类似了，用户写出来的SQL在翻译成执行计划之前要计算那种执行方式和JOIN顺序效率更高。
3. ORCFile
ORCFile是一种列式存储的文件，对于分析型应用来说列存有非常大的优势。
原来的RCFile中把每一列看成binary blob，没有任何语义，所以只能用通用的zlib,LZO,Snappy等压缩方法。ORCFile能够获取每一列的类型(int还是string)，那么就可以使用诸如dictionary encoding, bit packing, delta encoding, run-length encoding等轻量级的压缩技术。这种压缩技术的优势有两点：一是提高压缩率；二是能够起到过滤无关数据的效果。
Predicate Pushdown:原来的Hive是把所有的数据都读到内存中，然后再判断哪些是符合查询需求的。在ORCFile中数据以Stripe为单元读取到内存，那么ORCFile的RecordReader会根据Stripe的元数据(Index Data，常驻内存)判断该Stripe是否满足这个查询的需求，如果不满足直接略过不读，从而节省了IO。
通过对ORCFile的上述分析，我想大家已经看到了brighthouse的影子了吧。都是把列数据相应的索引、统计数据、词典等放到内存中参与查询条件的过滤，如果不符合直接略过不读，大量节省IO。
4. HiveServer2的Security和Concurrency特性
HiveServer2能够支持并发客户端(JDBC/ODBC)的访问。
Cloudera还搞了个Sentry用于Hadoop生态系统的的安全性和授权管理方面的工作。这两个特点是企业级应用Hadoop/Hive主要关心的。
5. HCatalog Hadoop的统一元数据管理平台
目前Hive存储的表格元数据和HDFS存储的表格数据之间在schema上没有一致性保证，也就是得靠管理员来保证。目前Hive对列的改变只会修改 Hive 的元数据，而不会改变实际数据。比如你要添加一个column，那么你用Hive命令行只是修改了了Hive元数据，没有修改HDFS上存储的格式。还得通过修改导入HDFS的程序来改变HDFS上存储的文件的格式。Hadoop系统目前对表的处理是’schema on read’，有了HCatlog就可以做到EDW的’schema on write’。
6. Windowing and Analytics Functions的支持。

找到好贴不容易，我顶你了，谢了

ppboy_000 发表于 2013-10-25 09:01
找到好贴不容易，我顶你了，谢了

:P我帮顶