Impala的分布式查询

Posted 2020-07-06 Thinking in 毛毛

翻译自《Getting Started with Impala》

 

分布式查询

　　分布式查询是impala的核心。曾几何时，你需要研究并行计算，才能开始进行深奥而晦涩的操作。现在，有运行在Hadoop上面的Impala，你只需要...一台笔记本电脑。理想情况下，一个IT部门也会有运行着Cloudera Distribution with Hadoop (CDH)的Linux服务器集群。但在紧急情况下，有一个虚拟机的单独的笔记本电脑就能够进行开发和设计的工作。

　　当一个Impala查询在一个Hadoop集群上运行时，Impala将工作分解成多个阶段，并且自动的将适当的请求发送给集群中对应的节点。这种自动分工就是为什么Impala能这么好适用于大数据应用案例的原因。当一个工作被4个，10个，100个或者更多的机器划分的时候，这些查询根据单机的容量而应变，形成一个单元来运行。分解工作和制定它在这么多的机器之间通信会产生一些开销。因此，有两个重点：1.为高效的查询处理组织好你的方案 2.帮助Impala估计特定的查询会涉及多少工作。

　　每个分布式查询执行步骤如下（极大的简化了）：

　　1.Node #1，core #1：从你的本地磁盘的相关数据块中读取大数据文件的一部分。

　　2.Node #1，core #2：读取相同文件的不同部分。每个请求像这样运行，使得一个节点有着该请求对应的数据块备份。多核意味着每个服务器有并行处理4,8,16甚至更多的数据块的潜力。

　　3.Node #2 ，core #1：读取整个小的数据文件。该文件要足够小，以至于能适应单个HDFS块，这样一来你就能处理所有事情了。

　　4.重复以上集群中所有数据节点和节点中的核的工作，增加每个节点的可用磁盘数量。保持运行，直到所有的相关HDFS数据块被处理完。

　　5.假设：处理一个查询，只需要列X，Y和Z，并且产生一个结果集。那么，每个节点：忽略来自所有其它列的数据。（使用Parquet格式的表的话，这些被忽略的数据将不会被读取）这种操作就是所谓的投影（projection）。

　　6.每个节点：当你读取数据文件时，忽略所有不符合WHERE条款的行。这就是一个过滤（filtering）操作；在WHERE条款中的条件被称作为断言（predicates）。

　　7.每个节点：现在可以得到所保存的更加易于管理的数据量，在它上面进行求和，排序，分组，函数调用，或者其它操作。

　　8.对表中的所有相关的数据文件运行这些步骤，直到所有需要的数据读取完毕，并且每个节点的每个核得出自己部分所对应的结果集。

　　9.如果查询语句有LIMIT条款，那么结果集会更加被压缩。每个节点：假设你是一个寻找到“top N”结果的节点，并且只返回前N行的结果集。

　　10.现在如果有一个JOIN或者UNION条框，每个节点传送必要的中间结果给其它节点来进行交叉检查，消除重复等等。对所有的JOIN和UNION条款重复以上步骤。

　　11.当查询的所有阶段的中间结果都已经准备好了，就尽量把结果返回给任何首先初始化查询的节点。这个协调节点（coordinator node）进行必要的最终排序，分组和聚合。比如，只有当所有的中间结果可以相互比较的时候，才能最终裁定“top 10 visitors”。

　　

　　所有的并行处理对结果的特性具有以下的影响：

• 任何写操作可能产生多个输出文件，每个节点以单独的文件作为返回的运行结果。
  
• 哪个数据在哪个节点上处理事先并不确定。因此，在连续查询的时候，会存在一定程度的性能变化。
• 通过后续查询而形成的特定排序，返回至磁盘上的结果是不可靠的。工作可能被分解到不同的节点上，或者节点会根据完成自己那部分的工作的速度，以不同的顺序返回中间结果。
• 跨群集分配工作之前，每个查询的规划阶段会尽可能的计算出未知数。Impala会尽可能的把表达式转化为常量，而不是在每个节点上重新计算它们。当你调用时间相关的函数时，比如说 NOW()， 在查询开始的时候，那时候的时间会被捕获，并且所有节点上使用相同的值，而不会重新计算每个节点开始工作的精确时间。
• 传送最终结果给协调节点所花的时间和结果集的大小成正比。因此，Impala的查询一般会避免大表的select * 操作，并且一般会包含多个WHERE条款，一个LIMIT条款或者聚合函数，来把结果压缩成相对小的体积，并且减少网络开销。