360SDN.COM

首页/Hadoop/列表

大数据Hadoop插件: Impala

来源:AI玩转智能  2017-09-19 15:26:01    评论:0点击:

AI


随着大数据时代的到来,Hadoop在过去几年以接近统治性的方式包揽的ETL和数据分析查询的工作,大家也无意间的想往大数据方向靠拢,但是当面对真正的Big Data的时候,Hadoop就会暴露出它对于数据分析查询支持的弱点。甚至出现《MapReduce: 一个巨大的倒退》此类极端的吐槽,这也怪不得Hadoop,毕竟它的设计就是为了批处理,使用用MR的编程模型来实现SQL查询,性能肯定不如意。


但在Dremel论文发表之后,开源社区涌现出了一批基于MPP架构的SQL-on-Hadoop(HDFS)查询引擎,典型代表有Apache Impala、Presto、Apache Drill、Apache HAWQ等,看上去这些查询引擎提供的功能和实现方式也都大同小异,所以这篇文章将基于Impala的使用和实现介绍日益发展的基于HDFS的MPP数据查询引擎。


一,impala概述

1-1 什么是MMP

MPP (Massively Parallel Processing),大规模并行处理系统,这样的系统是由许多松耦合的处理单元组成的,要注意的是这里指的是处理单元而不是处理器。每个单元内的CPU都有自己私有的资源,如总线,内存,硬盘等。在每个单元内都有操作系统和管理数据库的实例复本。这种结构最大的特点在于不共享资源。


详细介绍可以参考此文章:http://www.cnblogs.com/yubo/archive/2010/04/23/1718810.html


1-2 Impala简介

Apache Impala是由Cloudera开发并开源的一款基于HDFS/Hbase的MPP SQL引擎,它拥有和Hadoop一样的可扩展性、它提供了类SQL(类Hsql)语法,在多用户场景下也能拥有较高的响应速度和吞吐量。它是由Java和C++实现的,Java提供的查询交互的接口和实现,C++实现了查询引擎部分,除此之外,Impala还能够共享Hive Metastore(这逐渐变成一种标准),甚至可以直接使用Hive的JDBC jar和beeline等直接对Impala进行查询、支持丰富的数据存储格式(Parquet、Avro等),当然除了有比较明确的理由,Parquet总是使用Impala的第一选择。


1-3 用户体验

Impala这类系统的用户可以分为两类,一类是负责数据导入和管理的数据开发同学,另一类则是执行查询的数据分析师同学,


前者通常需要将数据存储到HDFS,通过create table的方式创建与数据match的schema,然后通过load data或者add partition的方式将表和数据关联起来,这一些流程串起来还是挺麻烦的,但是多亏了Hive,由于Impala可以共享Hive的MetaStore,这样就可以使用Hive完成此类ETL工作,然后将数据查询的工作交给Impala,大大简化工作流程(据我所知毕竟大部分数据开发同学还是比较熟悉Hive)。


接下来对于数据分析师而言就是如何编写正确的SQ以表达他们的查询、分析需求,这也是它们最拿手的了,Impala通常可以在TB级别的数据上提供秒级的查询速度,所以使用起来可能让你从Hive的龟速响应一下提升到期望的速度。



二, impala与Hive

2-1 impala的优势

impala作为新一代开源大数据分析引擎,最初参照Dremel(由Google开发的交互式数据分析系统),支持实时计算,提供与Hive类似的功能,在性能上高出Hive3~30倍。Impala可能会超过Hive的使用率能成为Hadoop上最流行的实时计算平台。Impala采用与商用并行关系数据库类似的分布式查询引擎,可直接从HDFS、HBase中用SQL语句查询数据,不需把SQL语句转换成MR任务,降低延迟,可很好地满足实时查询需求。


但是Impala不能替换Hive,提供一个统一的平台用于实时查询。Impala的运行依赖于Hive的元数据(Metastore)。Impala和Hive采用相同的SQL语法、ODBC驱动程序和用户接口,可统一部署Hive和Impala等分析工具,同时支持批处理和实时查询。


2-2异同点

首先让我们看一张图:

不同点:

Hive适合长时间批处理查询分析;而Impala适合进行交互式SQL查询。


Hive依赖于MR计算框架,执行计划组合成管道型MR任务模型进行执行;而Impala则把执行计划表现为一棵完整的执行计划树,可更自然地分发执行计划到各个Impalad执行查询。


Hive在执行过程中,若内存放不下所有数据,则会使用外存,以保证查询能够顺利执行完成;而Impala在遇到内存放不下数据时,不会利用外存,所以Impala处理查询时会受到一定的限制。


相同点:

使用相同的存储数据池,都支持把数据存储在HDFS和HBase中,其中HDFS支持存储TEXT、RCFILE、PARQUET、AVRO、ETC等格式的数据,HBase存储表中记录。


使用相同的元数据。


对SQL的解析处理比较类似,都是通过词法分析生成执行计划。


三,impala原理与架构

3-1 系统架构

从用户的使用方式上来看,Impala和Hive还是很相似的,并且可以共享一份元数据,这也大大简化了接入流程,下面我们从实现的角度来看一下Impala是如何工作的。下图展示了Impala的系统架构和查询的执行流程。


从上图可以看出,Impala自身包含三个模块:Impalad、Statestore和Catalog,除此之外它还依赖Hive Metastore和HDFS。


3-2 impalad

其中Imapalad负责接受用户的查询请求,也意味着用户的可以将请求发送给任意一个Impalad进程,该进程在本次查询充当协调者(coordinator)的作用,生成执行计划并且分发到其它的Impalad进程执行,最终汇集结果返回给用户。

并且对于当前Impalad和其它Impalad进程而言,他们同时也是本次查询的执行者,完成数据读取、物理算子的执行并将结果返回给协调者Impalad。

这种无中心查询节点的设计能够最大程度的保证容错性并且很容易做负载均衡。正如图中展示的一样,通常每一个HDFS的DataNode上部署一个Impalad进程,由于HDFS存储数据通常是多副本的,所以这样的部署可以保证数据的本地性,查询尽可能的从本地磁盘读取数据而非网络,从这点可以推断出Impalad对于本地数据的读取应该是通过直接读本地文件的方式,而非调用HDFS的接口。为了实现查询分割的子任务可以做到尽可能的本地数据读取,Impalad需要从Metastore中获取表的数据存储路径,并且从NameNode中获取每一个文件的数据块分布。


3-3 Catalog

Catalog服务提供了元数据的服务,它以单点的形式存在,它既可以从外部系统(例如HDFS NameNode和Hive Metastore)拉取元数据,也负责在Impala中执行的DDL语句提交到Metatstore,由于Impala没有update/delete操作,所以它不需要对HDFS做任何修改。

之前我们介绍过有两种方式向Impala中导入数据(DDL)——通过hive或者impala,如果通过hive则改变的是Hive metastore的状态,此时需要通过在Impala中执行REFRESH以通知元数据的更新,

而如果在impala中操作则Impalad会将该更新操作通知Catalog,后者通过广播的方式通知其它的Impalad进程。默认情况下Catalog是异步加载元数据的,因此查询可能需要等待元数据加载完成之后才能进行(第一次加载)。该服务的存在将元数据从Impalad进程中独立出来,可以简化Impalad的实现,降低Impalad之间的耦合。


3-4 StateStore

除了Catalog服务,Impala还提供了StateStore服务完成两个工作:消息订阅服务和状态监测功能。

Catalog中的元数据就是通过StateStore服务进行广播分发的,它实现了一个Pub-Sub服务,Impalad可以注册它们希望获得的事件类型,Statestore会周期性的发送两种类型的消息给Impalad进程,一种为该Impalad注册监听的事件的更新,基于版本的增量更新(只通知上次成功更新之后的变化)可以减小每次通信的消息大小;

另一种消息为心跳信息,StateStore负责统计每一个Impalad进程的状态,Impalad可以据此了解其余Impalad进程的状态,用于判断分配查询任务到哪些节点。由于周期性的推送并且每一个节点的推送频率不一致可能会导致每一个Impalad进程获得的状态不一致,由于每一次查询只依赖于协调者Impalad进程获取的状态进行任务的分配,而不需要多个进程进行再次的协调,因此并不需要保证所有的Impalad状态是一致的。

另外,StateStore进程是单点的,并且不会持久化任何数据到磁盘,如果服务挂掉,Impalad则依赖于上一次获得元数据状态进行任务分配,官方并没有提供可靠性部署的方案,通常可以使用DNS方式绑定多个服务以应对单个服务挂掉的情况


四,Kudu

4-1 前言

Apache Kudu是由Cloudera开源的存储引擎,可以同时提供低延迟的随机读写和高效的数据分析能力。Kudu支持水平扩展,使用Raft协议进行一致性保证,并且与Cloudera Impala和Apache Spark等当前流行的大数据查询和分析工具结 合紧密。


现在提起大数据存储,我们能想到的技术有很多,比如HDFS,以及在HDFS上的列式存储技术Apache Parquet,Apache ORC,还有以KV形式存储半结构化数据的Apache HBase和Apache Cassandra等等。既然有了如此多的存储技术,Cloudera公司为什么要开发出一款全新的存储引擎Kudu呢? 


事实上,当前的这些存储技术都存在着一定的局限性。对于会被用来进行分析的静态数据集来说,使用Parquet或者ORC存储是一种明智的选择。但是目前的列式存储技术都不能更新数据,而且随机读写性能感人。而可以进行高效随机读写的HBase、Cassandra等数据库,却并不适用于基于SQL的数据分析方向。


所以现在的企业中,经常会存储两套数据分别用于实时读写与数据分析,先将数据写入HBase中,再定期通过ETL到Parquet进行数据同步。但是这样做有很多缺点:


  1. 用户需要在两套系统间编写和维护复杂的ETL逻辑。

  2. 时效性较差。因为ETL通常是一个小时、几个小时甚至是一天一次,那么可供分析的数据就需要一个小时至一天的时间后才进入到可用状态,也就是说从数据到达到可被分析之间是会存在一个较为明显的“空档期”的。

  3. 更新需求难以满足。在实际情况中可能会有一些对已经写入的数据的更新需求,这种情况往往需要对历史数据进行更新,而对Parquet这种静态数据集的更新操作,代价是非常昂贵的。

  4. 存储资源浪费。两套存储系统意味着占用的磁盘资源翻倍了,造成了成本的提升。


我们知道,基于HDFS的存储技术,比如Parquet,具有高吞吐量连续读取数据的能力;而HBase和Cassandra等技术适用于低延迟的随机读写场景,那么有没有一种技术可以同时具备这两种优点呢?Kudu提供了一种“happy medium”的选择:

Kudu不但提供了行级的插入、更新、删除API,同时也提供了接近Parquet性能的批量扫描操作。使用同一份存储,既可以进行随机读写,也可以满足数据分析的要求。


对于Kudu架构与原理感兴趣的同学可以看一看这篇文章:https://mp.weixin.qq.com/s?__biz=MzI1MjQ2OTQ3Ng==&mid=2247485528&idx=1&sn=4cb2e40ec6e27232aaa03d1b52bb89c0&chksm=e9e201d3de9588c52e06c86e9b7ac04ef93cdd723357a85d9374fb58a3f7c347478f08bb90ca&mpshare=1&scene=23&srcid=0827vww6LJzzNTXVMBNjwYTr#rd


Kudu与impala

在kudu之前,我们的大数据分析管道流程大概是有这几种:

1. 数据源-> scribe打日志到HDFS -> MR/Hive/Spark -> HDFS Parquet -> Impala -> 结果service

这个数据流一般用来分析各种日志。


2. 数据源 -> 实时更新HBase/Mysql -> 每天批量导出Parquet-> Impala -> 结果serve

这个数据流一般用来分析状态数据,也就是一般需要随机更新的数据,比如用户profile之类。


这两条数据流主要由几个问题:

1. 数据从生成到能够被高效查询的列存储,整个数据流延迟比较大,一般是小时级别到一天;

2. 很多数据的日志到达时间和逻辑时间是不一致的,一般存在一些随机延迟。


比如很多mobile app统计应用,这些tracing event发生后,很可能过一段时间才被后端tracing server收集到。

我们经常看到一些hive查询,分析一天或者一小时的数据,但是要读2-3天或者多个小时的日志,然后过滤出实际想要的记录。

对于一些实时分析需求,有一些可以通过流处理来解决,不过他肯定没用SQL方便,另外流式处理只能做固定的数据分析,对ad-hoc查询无能为力


kudu的特点正好可以来配合impala搭建实时ad-hoc分析应用。

改进后的数据流大概是这个样子:

1. 数据源 -> kafka -> ETL(Storm) -> kudu -> Impala

2. 数据源 -> kudu -> Impala

数据流1 主要是为需要进一步做ETL的应用使用的,另外kafka可以当做一个buffer,当写吞吐有毛刺时,kafka可以做一个缓冲。

如果应用有严格的实时需求,就是只要数据源写入就必须能够查到,就需要使用数据流2。


所以我们引入kudu主要是用来替换 HDFS+parquet的。

但是Kudu不能替代hbase,感觉这两个工具目前用来解决不同的问题,hbase还是用来做OLTP类存储跟Mysql类似,kudu则用来升级我们现有的数据分析数据流,主要还是OLAP的workload。


AI


本文主要介绍了Impala这个高性能的查询引擎,区别于传统DBMS的MPP解决方案,Impala更好的融入大数据(Hadoop/Spark)生态圈,更好的实现数据之间的流通,而传统MPP数据库,更倾向于数据自制。


当然基于HDFS的实现导致Impala无法实现单条数据的实时更新,而只能批量的追加或者覆盖数据,虽然Cloudera也提供了Impala对于Kudu的支持,但是从性能测试结果看,目前查询性能还是不理想,而传统MPP数据库不仅可以支持单条数据的实时更新,甚至能够在保证查询性能的情况下支持较复杂的事务,这也是SQL-on-Hadoop查询引擎所望尘莫及的。


欢迎大家在后台回复Hadoop获得最新的资料。

不失初心,不忘初衷

 


AI玩转智能


阅读原文

为您推荐

友情链接 |九搜汽车网 |手机ok生活信息网|ok生活信息网|ok微生活
 Powered by www.360SDN.COM   京ICP备11022651号-4 © 2012-2016 版权