数据仓库随笔

 Impala与Hive的异同

原文链接：https://blog.csdn.net/bluejoe2000/article/details/51527029

• 数据存储：使用相同的存储数据池都支持把数据存储于HDFS, HBase。
• 元数据：两者使用相同的元数据。
• SQL解释处理：比较相似都是通过词法分析生成执行计划。

执行计划：

• Hive: 依赖于MapReduce执行框架，执行计划分成 map->shuffle->reduce->map->shuffle->reduce…的模型。如果一个Query会 被编译成多轮MapReduce，则会有更多的写中间结果。由于MapReduce执行框架本身的特点，过多的中间过程会增加整个Query的执行时间。
• Impala: 把执行计划表现为一棵完整的执行计划树，可以更自然地分发执行计划到各个Impalad执行查询，而不用像Hive那样把它组合成管道型的 map->reduce模式，以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle。

数据流：

• Hive: 采用推的方式，每一个计算节点计算完成后将数据主动推给后续节点。
• Impala: 采用拉的方式，后续节点通过getNext主动向前面节点要数据，以此方式数据可以流式的返回给客户端，且只要有1条数据被处理完，就可以立即展现出来，而不用等到全部处理完成，更符合SQL交互式查询使用。

内存使用：

• Hive: 在执行过程中如果内存放不下所有数据，则会使用外存，以保证Query能顺序执行完。每一轮MapReduce结束，中间结果也会写入HDFS中，同样由于MapReduce执行架构的特性，shuffle过程也会有写本地磁盘的操作。
• Impala: 在遇到内存放不下数据时，当前版本1.0.1是直接返回错误，而不会利用外存，以后版本应该会进行改进。这使用得Impala目前处理Query会受到一 定的限制，最好还是与Hive配合使用。Impala在多个阶段之间利用网络传输数据，在执行过程不会有写磁盘的操作（insert除外）。

调度：

• Hive: 任务调度依赖于Hadoop的调度策略。
• Impala: 调度由自己完成，目前只有一种调度器simple-schedule，它会尽量满足数据的局部性，扫描数据的进程尽量靠近数据本身所在的物理机器。调度器 目前还比较简单，在SimpleScheduler::GetBackend中可以看到，现在还没有考虑负载，网络IO状况等因素进行调度。但目前 Impala已经有对执行过程的性能统计分析，应该以后版本会利用这些统计信息进行调度吧。

容错：

• Hive: 依赖于Hadoop的容错能力。
• Impala: 在查询过程中，没有容错逻辑，如果在执行过程中发生故障，则直接返回错误（这与Impala的设计有关，因为Impala定位于实时查询，一次查询失败， 再查一次就好了，再查一次的成本很低）。但从整体来看，Impala是能很好的容错，所有的Impalad是对等的结构，用户可以向任何一个 Impalad提交查询，如果一个Impalad失效，其上正在运行的所有Query都将失败，但用户可以重新提交查询由其它Impalad代替执行，不 会影响服务。对于State Store目前只有一个，但当State Store失效，也不会影响服务，每个Impalad都缓存了State Store的信息，只是不能再更新集群状态，有可能会把执行任务分配给已经失效的Impalad执行，导致本次Query失败。

适用面：

• Hive: 复杂的批处理查询任务，数据转换任务。
• Impala：实时数据分析，因为不支持UDF，能处理的问题域有一定的限制，与Hive配合使用,对Hive的结果数据集进行实时分析。
• 
• hive.groupby.skewindata=true时，hive不支持多列上的去重操作，并报错
• 当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group ByKey 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce中），最后完成最终的聚合操作。
• 设置reduce个数（一个reduce生成一个文件）
  1、如果不指定reduce个数，hive会基于一下两个参数自动计算
        （1）hive.exec.reducers.bytes.per.reducer
                  这是每个reduce处理的数据量，默认为1G=1000000000
         （2）hive.exec.reducers.max(每个任务的最大reduce个数，默认1009)
      reduce个数=min(参数2，map端输出数据总量/参数1)
  2、设置每个reduce处理的数据量（例如1M）
         参数：hive.exec.reducers.bytes.per.reducer=1000000；
          reduce个数=map端输出数据总量/参数
  3、直接设置reduce个数
        set mapred.reduce.tasks=5;
  4、在2,3中设置的参数在以下情况出现时会失效
        （1）sql语句中没有group by的汇总
        （2）使用了order by
        （3）有笛卡尔积
        （4）map端输出的数据量小于hive.exec.reducers.bytes.per.reducer参数值
  设置map个数
      map个数和来源表文件压缩格式有关，.gz格式的压缩文件无法切分，每个文件会生成一个map
  set hive.hadoop.supports.splittable.combineinputformat=true; 只有这个参数打开，下面的3个参数才能生效
      set mapred.max.split.size=16000000; 每个map负载
      set mapred.min.split.size.per.node=100000000; 每个节点map的最小负载，这个值必须小于set mapred.max.split.size的值
      set mapred.min.split.size.per.rack=100000000; 每个机架map的最小负载
      set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;   

  • Map端：

    1．每个输入分片会让一个map任务来处理，默认情况下，以HDFS的一个块的大小（默认为64M）为一个分片，当然我们也可以设置块的大小。map输出的结果会暂且放在一个环形内存缓冲区中（该缓冲区的大小默认为100M，由io.sort.mb属性控制），当该缓冲区快要溢出时（默认为缓冲区大小的80%，由io.sort.spill.percent属性控制），会在本地文件系统中创建一个溢出文件，将该缓冲区中的数据写入这个文件。

    2．在写入磁盘之前，线程首先根据reduce任务的数目将数据划分为相同数目的分区，也就是一个reduce任务对应一个分区的数据。这样做是为了避免有些reduce任务分配到大量数据，而有些reduce任务却分到很少数据，甚至没有分到数据的尴尬局面。其实分区就是对数据进行hash的过程。然后对每个分区中的数据进行排序，如果此时设置了Combiner，将排序后的结果进行Combia操作，这样做的目的是让尽可能少的数据写入到磁盘。

    3．当map任务输出最后一个记录时，可能会有很多的溢出文件，这时需要将这些文件合并。合并的过程中会不断地进行排序和combia操作，目的有两个：1.尽量减少每次写入磁盘的数据量；2.尽量减少下一复制阶段网络传输的数据量。最后合并成了一个已分区且已排序的文件。为了减少网络传输的数据量，这里可以将数据压缩，只要将mapred.compress.map.out设置为true就可以了。

    4．将分区中的数据拷贝给相对应的reduce任务。有人可能会问：分区中的数据怎么知道它对应的reduce是哪个呢？其实map任务一直和其父TaskTracker保持联系，而TaskTracker又一直和JobTracker保持心跳。所以JobTracker中保存了整个集群中的宏观信息。只要reduce任务向JobTracker获取对应的map输出位置就ok了哦。

    Reduce端：

    1．Reduce会接收到不同map任务传来的数据，并且每个map传来的数据都是有序的。如果reduce端接受的数据量相当小，则直接存储在内存中（缓冲区大小由mapred.job.shuffle.input.buffer.percent属性控制，表示用作此用途的堆空间的百分比），如果数据量超过了该缓冲区大小的一定比例（由mapred.job.shuffle.merge.percent决定），则对数据合并后溢写到磁盘中。

    2．随着溢写文件的增多，后台线程会将它们合并成一个更大的有序的文件，这样做是为了给后面的合并节省时间。其实不管在map端还是reduce端，MapReduce都是反复地执行排序，合并操作，现在终于明白了有些人为什么会说：排序是hadoop的灵魂。

    3．合并的过程中会产生许多的中间文件（写入磁盘了），但MapReduce会让写入磁盘的数据尽可能地少，并且最后一次合并的结果并没有写入磁盘，而是直接输入到reduce函数。

•  

  2. SQL转化为MapReduce的过程
      了解了MapReduce实现SQL基本操作之后，我们来看看Hive是如何将SQL转化为MapReduce任务的，整个编译过程分为六个阶段：

  Antlr定义SQL的语法规则，完成SQL词法，语法解析，将SQL转化为抽象语法树AST Tree
  遍历AST Tree，抽象出查询的基本组成单元QueryBlock
  遍历QueryBlock，翻译为执行操作树OperatorTree,
  逻辑层优化器进行OperatorTree变换，合并不必要的ReduceSinkOperator，减少shuffle数据量
  遍历OperatorTree，翻译为MapReduce任务
  物理层优化器进行MapReduce任务的变换，生成最终的执行计划
  在slice中，将着六个阶段表示为：

  解析：将HIVEQL解析为AST。
  语义解析：将AST翻译为QB。
  生成逻辑计划：将QB转化为OperatorTree
  优化逻辑计划
  生成物理执行计划：将OperatorTree转化为TaskTree
  优化物理计划