大数据序列十二:交互式查询工具-Impala(上)

发布于 2021-10-11 12:51

Impala是什么

Impala是Cloudera提供的⼀款开源的针对HDFS和HBASE中的PB级别数据进⾏交互式实时查询(Impala速度快)，Impala是参照⾕歌的新三篇论⽂当中的Dremel实现⽽来，其中旧三篇论⽂分别是BigTable，GFS，MapReduce。

Impala最⼤卖点和最⼤特点就是快速，Impala中⽂翻译是⾼⻆羚⽺。

Impala的优势

1：基于内存运算，不需要把中间结果写入磁盘，省掉了大量的I/O开销。

2：无需转换为Mapreduce，直接访问存储在HDFS，HBase中的数据进行作业调度，速度快。

3：使用了支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销。

4：支持各种文件格式，如TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet...。

5：可以访问hive的metastore，对hive数据直接做数据分析。

Impala的诞⽣

前几章节说过的的Hive以及MR适合做离线批处理，但是对交互式查询的场景⽆能为⼒(要求快速响应)，所以为了解决查询速度的问题，Cloudera公司依据Google的Dremel开发了Impala,Impala抛弃了MapReduce使⽤了类似于传统的MPP数据库技术，⼤⼤提⾼了查询的速度。

MPP是什么？

MPP (Massively Parallel Processing)，就是⼤规模并⾏处理，在MPP集群中，每个节点资源都是独⽴享有也就是有独⽴的磁盘和内存，每个节点通过⽹络互相连接，彼此协同计算，作为整体提供数据服务。

简单来说，MPP是将任务并⾏的分散到多个服务器和节点上，在每个节点上计算完成后，将各⾃部分的结果汇总在⼀起得到最终的结果。

对于MPP架构的软件来说聚合操作⽐如计算某张表的总条数，则先进⾏局部聚合(每个节点并⾏计算)，然后把局部汇总结果进⾏全局聚合(与Hadoop相似)。

Impala与Hive对⽐

在前几章里作者已经针对impala和hive做过简单的介绍和对比，这里作者再次阐述下。

Impala的技术优势

1：Impala没有采取MapReduce作为计算引擎，MR是⾮常好的分布式并⾏计算框架，但MR引擎更多的是⾯向批处理模式，⽽不是⾯向交互式的SQL执⾏。与 Hive相⽐：Impala把整个查询任务转为⼀棵执⾏计划树，⽽不是⼀连串的MR任务，在分发执⾏计划后，Impala使⽤拉取的⽅式获取上个阶段的执⾏结果，把结果数据、按执⾏树流式传递汇集，减少的了把中间结果写⼊磁盘的步骤，再从磁盘读取数据的开销。Impala使⽤服务的⽅式避免每次执⾏查询都需要启动的开销，即相⽐Hive没了MR启动时间。

2：使⽤LLVM(C++编写的编译器)产⽣运⾏代码，针对特定查询⽣成特定代码。

3：优秀的IO调度，Impala⽀持直接数据块读取和本地代码计算。

4：选择适合的数据存储格式可以得到最好的性能（Impala⽀持多种存储格式）。

5：尽可能使⽤内存，中间结果不写磁盘，及时通过⽹络以stream的⽅式传递。

Impala与Hive对⽐分析

查询过程：

Hive：在Hive中，每个查询都有⼀个“冷启动”的常⻅问题。（map,reduce每次都要启动关闭，申请资源，释放资源。。。）

Impala：Impala避免了任何可能的启动开销，这是⼀种本地查询语⾔。因为要始终处理查询，则Impala守护程序进程总是在集群启动之后就准备就绪。守护进程在集群启动之后可以接收查询任务并执⾏查询任务。

中间结果：

Hive：Hive通过MR引擎实现所有中间结果，中间结果需要落盘，这对降低数据处理速度有不利影响。

Impala：在执⾏程序之间使⽤流的⽅式传输中间结果，避免数据落盘。尽可能使⽤内存避免磁盘开销。

交互查询：

Hive：对于交互式计算，Hive不是理想的选择。

Impala：对于交互式计算，Impala⾮常适合。(数据量级PB级)

计算引擎：

Hive：是基于批处理的Hadoop MapReduce。

Impala：更像是MPP数据库。

容错：

Hive：Hive是容错的（通过MR&Yarn实现）。

Impala：Impala没有容错，由于良好的查询性能，Impala遇到错误会重新执⾏⼀次查询。

查询速度：

Impala⽐Hive快3-90倍。

Impala优势总结：

1：Impala最⼤优点就是查询速度快，在⼀定数据量下。

2：速度快的原因：避免了MR引擎的弊端，采⽤了MPP数据库技术。

Impala的缺点：

1：Impala属于MPP架构，只能做到百节点级，⼀般并发查询个数达到20个左右时，整个系统的吞吐已经达到满负荷状态，在扩容节点也提升不了吞吐量，处理数据量在PB级别最佳。

2：资源不能通过YARN统⼀资源管理调度，所以Hadoop集群⽆法实现Impala、Spark、Hive等组件的动态资源共享。

适⽤场景

Hive: 复杂的批处理查询任务，数据转换任务，对实时性要求不⾼同时数据量⼜很⼤的场景。

Impala：实时数据分析，与Hive配合使⽤,对Hive的结果数据集进⾏实时分析。impala不能完全取代hive，impala可以直接处理hive表中的数据。

大家应该深有感触，这几年大数据的发展真的快如闪电，很多新技术都接踵而来，让我们应接不暇，比如OLAP(分析型数据库)的clickhouse、doris，再比如前段时间吹的很凶的一股风：能代替kafka的pulsar，还有老生常谈但始终只了解皮毛的数据湖：delta Lake、hudi、lceberg，还有最近几天处于热榜的能代替impala的starRocks,....。

不过作为资深技术宅，自己也非常欣赏那些开源新技术的公司或个人，相信每一个朋友都不甘落后(为何站在金字塔上的人不是我呢？)，希望大家共同努力，造就非凡。