开源大数据分析利器——Impala

Posted 2021-04-24 通信大数据分析及应用

一、概述

目前Hadoop是用于大数据的优选平台解决方案，Impala是Cloudera公司主导开发的新型开源的实时交互大数据查询系统，它提供SQL语义，能实现低延迟的查询存储在Hadoop的HDFS和HBase中的PB级大数据。它继承了Hadoop的灵活性、伸缩性和经济性，具有分布式本地化处理的特性以避免网络瓶颈。Impala适用于海量数据的实时分析，相比Hive、SQL和MapReduce等交互性更强，对于用户而言使用方便快捷并且简单实用。

目前电信行业通过网格营销、市场监控、经营决策等方式提升用户体验，保有市场份额。因此针对海量数据的分析，时效性成为不容忽视的问题。而Impala最大的优势则在于它的快速与实时性，能够更好的满足电信行业大数据分析的需求。

二、Impala架构

Impala的系统架构如上图所示，Impala使用了Hive的SQL接口（包括SELECT、INSERT、JOIN等操作），表的元数据信息存储在Hive Metastore中。StateStore是Impala的一个子服务，用于监控集群中各个节点的健康状况，提供节点注册、错误检测等功能；Impala在每个节点运行了一个后台服务Impalad，用于响应外部请求，并完成实际的查询处理。Impalad主要包含Query Planner、Query Coordinator和Query Exec Engine三个模块。Query Planner接收来自SQL APP和ODBC的查询，然后将查询转换为许多子查询，Query Coordinator将这些子查询分发到各个节点上，由各个节点上的Query Exec Engine负责子查询的执行，然后返回子查询的结果，这些中间结果经过聚集之后最终返回给用户。

三、Impala服务器组件

Impala服务器是一个分布式、大规模并行处理的数据库引擎，包括运行在集群主机上的不同后台进程。

（1）Impala Deamon

它是运行在集群每个节点上的守护进程，是Impala的核心组件，在每个节点上这个进程的名称为Impalad。该进程负责读写数据文件；接受来自Impala-shell、Hue、JDBC、ODBC等客户端的查询请求（接收查询请求的Impalad为Coordinator），Coordinator通过JNI调用java前端解释SQL查询语句，生成查询计划树，再通过调度器把执行计划分发给具有相应数据的其它节点分布式并行执行，并将各节点的查询结果返回给中心协调者节点Coordinator，再由该节点返回给客户端。同时Impalad会与State Store保持通信，以了解其他节点的健康状况和负载。

（2）Impala State Store

该进程负责搜集集群中Impalad进程节点的健康状况，它通过创建多个线程来处理Impalad的注册订阅，并与各节点保持心跳连接，不断地将健康状况的结果转发给所有的Impalad进程节点。一个Impala集群只需一个statestored进程节点，当某一节点不可用时，该进程负责将这一信息传递给所有的Impalad进程节点，再有新的查询时不会把请求发送到不可用的节点上。

（3）Impala Shell

提供给用户查询使用的命令行交互工具，供使用者发起数据查询或管理任务，同时Impala还提供了Hue、JDBC、ODBC等使用接口。

四、Impala的查询处理流程

Impala的查询处理流程如上图所示。

0.注册&订阅

当Impala启动时，所有Impalad节点会在Impala State Store中注册并订阅各个节点最新的健康信息以及负载情况。

1.提交查询

接受客户端连接的Impalad即作为这次查询的Coordinator，Coordinator对用户的查询SQL进行分析并生成执行计划树，不同的操作对应不用的PlanNode，如：SelectNode、 ScanNode、 SortNode、AggregationNode、HashJoinNode等等。

3.分发查询任务

执行计划树的每个原子操作由一个Plan Fragment表示，通常一条查询语句由多个Plan Fragment组成。Coordinator节点根据执行计划以及获取到的数据存储信息，通过调度器将Plan Fragment分发给各个Impalad实例并行执行。

4.汇聚结果

Coordinator节点会不断向各个Impalad执行子节点获取计算结果，直到所有执行计划树的叶子节点执行完毕，并向父节点返回计算结果集。

5.返回结果

Coordinator节点即执行计划数的根节点，汇聚所有查询结果后返回给用户。查询执行结束，注销此次查询服务。

五、Impala性能测试

测试环境：6台惠普BL460C刀片机（2CPU，单CPU6核2.6G，128G内存，硬盘1.2T*12），其中5台分配用于查询运算的SLAVE节点，1台用于管理与协调整个集群的MASTER节点，Impala进程运行在SLAVE节点上。为了保证Impala集群的稳定性，所有服务器的操作系统均为：Red Hat Enterprise Linux Server release 6.5 (Santiago)。

本次Impala性能测试从数据加载、SQL查询、Impala稳定性和数据同步四个方面进行。

数据加载测试

本测试包含单个数据文件加载和并发多个数据文件加载两个用例，测试数据文件录入Impala数据库的整体时间。

可以看出，由linux系统拷贝到HDFS时间在10.7~12G/分左右，与一个大文件相同总大小的多个小文件线性拷贝时速度会高于单个文件拷贝速度。由HDFS插入内部表的时间在3G/分左右，随插入条目数增加速度呈现递增趋势。

由linux系统拷贝到HDFS由于增加了并发，3个并发时速度为29.5G/分，数据加载速度在3个并行-6个并行之间是呈线性速度递增的，而在8个并行之上的插入速度并没有递增，反而因为并发过多，造成CPU瓶颈呈下降趋势。

总体结论

对于数据文件的入库主要分为文件拷贝和数据插入两个过程，数据文件的拷贝过程主要是磁盘IO的占用；数据的插入需要对插入的数据进行解析、压缩和写入，主要是消耗CPU资源。文件的拷贝速度基本呈现线性关系；单个数据文件的加载速度也是呈现线性增长。并发加载方面，就目前的测试集群资源而言，460G的数据文件并行数为6时, 达到最优加载速度，同时集群资源利用率也最优。并行数为8时，虽然加载速度高于并行数6，但由于发生了资源争用情况，因此提升不大。

SQL查询测试

本部分以数据加载部分导入的数据为主，以天和小时粒度，分区和不分区两种情况，分别进行了基本SQL、大表关联、嵌套查询、并发查询等测试。查询数据源信息如下所示：

1. mb_gprs_new_all：460G，17.68亿行21列；

2. msisdn_info：1.65MB，75052行4列；

3. province_info：11.2KB，362行5列；

4. tac_info：44.2MB，434883行26列；

5. charge_sum_all：617G，14.89亿行31列。

测试结果如下表所示：

在测试过程中，当一个大表查询占用较大内存，impala系统出现内存溢出时，哪怕是一个很小的查询在申请内存时也会继续报错，导致小查询无法查出结果，当大表查询结束释放内存后，小查询可以继续查出结果。

在并行查询时，原本越快的查询在并行时越不占优势，原本耗时较多的查询用例，在并行时耗时2倍左右。但内存的限制导致了多个并行的报错，可见过量的并行作业并不是impala的优势，而在合理范围内的多个查询的并行效率要高于多个串行查询的效率，所以找到最优的并行数与内存的关系是impala系统在使用中的关键。

总体结论

Impala的查询同时对CPU和内存都有较大的需求，通过测试可以看出，查询时间随表大小增大呈线性递增，使用小时级分区表后时间成倍缩短；查询结果受内存限制较大，多并发或大表关联会导致查询无法得出结果，因此需要通过SQL代码优化、资源合理分配和严谨的任务调度程序等方法避免内存溢出的情况。

另外，Impala大部分的查询效率跟Vertica相比，相对较慢一些，尤其是在数据量较大的情况下，差距较大。

稳定性测试

本部分对Impala集群的稳定性进行了相应的测试，通过宕机一台服务器节点前后查询结果对比、执行SQL查询过程中宕机一台服务器节点和数据加载过程中宕机一台服务器三种用例进行测试。

总体结论

当Impala集群在不损害数据完整性的情况下，宕机一台节点不影响SQL的正常查询，降低的只是由于节点资源不可用导致的查询速度。宕机的节点损失了数据完整性，但底层的HDFS文件存储依然可用。在查询和数据导入的过程中若发生宕机，Impala集群各节点会缺失分布式交互工作必要的统计信息，无法保证任务的继续执行，在实际中应避免此种情况。

数据同步测试

本部分通过使用Impala集群中的sqoop工具，对Impala与传统关系型数据库Oracle的数据同步进行了测试，测试结果如下所示。

总体结论

Impala支持与传统关系型数据库之间的数据同步，但效率相比Impala直接的数据加载差距较大，且当前版本在与关系数据库的同步时存在一定的限制：从Impala到关系型的数据同步只支持从文本表数据同步；从关系数据库到Impala的数据同步，可以写parquet, text等多种文件格式，但写入目录需要为空，或不存在上次导入时的metadata文件。因此，应避免二者之间大数据量的同步，或通过制订闲时自动同步计划等方式进行数据同步。

六、Impala的优缺点

• 优点

• 直接为存储在HDFS或HBase中的Hadoop数据提供交互式的SQL查询，能够快速实时地查询大数据。

• Impala不需要把中间结果写入磁盘，省掉了大量的I/O开销；

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

• 可以与Hive配合使用，并且数据支持多种存储格式以及压缩方式。

• 缺点

• 对内存需求过高，没有内存溢出写入外存的机制；

• 不支持数据的UPDATE/DELETE，对配置类数据的处理不好；

• 对数据挖掘类的操作处理还不够丰富，但已能满足日常大部分的统计分析需求。