基于hadoop生态圈的数据仓库实践 —— OLAP与数据可视化（一）
一、OLAP与Impala简介
1. OLAP简介
OLAP是Online Analytical Processing的缩写，意为联机分析处理。此概念最早是由关系数据库之父E.F.Codd于1993年提出，至今已有20多年。OLAP允许以一种称为多维数据集的结构，访问业务数据源经过聚合和组织整理的后数据。以此为标准，OLAP作为单独的一类产品同联机事务处理(OLTP)得以明显区分。
在计算领域，OLAP是一种快速应答多维分析查询的方法，也是商业智能的一个组成部分，与之相关的概念还包括数据仓库、报表系统、数据挖掘等。数据仓库用于数据的存储和组织，OLAP集中于数据的分析，数据挖掘则致力于知识的自动发现，报表系统则侧重于数据的展现。OLAP从数据仓库中的集成数据出发，构建面向分析的多维数据模型，再使用多维分析方法从多个不同的视角对多维数据进行分析比较，分析活动以数据驱动。
通过使用OLAP工具，用户可以从多个视角交互式地分析多维数据。OLAP由三个基本的分析操作构成：合并（上卷）、下钻和切片。合并是指数据的聚合，即数据可以在一个或多个维度上进行累积和计算。例如，所有的营业部数据被上卷到销售部门以分析销售趋势。下钻是一种由汇总数据向下浏览细节数据的技术，比如用户可以从产品分类的销售数据下钻查看单个产品的销售数据。切片则是这样一种特性，通过它用户可以获取OLAP立方体中的特定数据集合，并从不同的视角观察这些数据。这些观察数据的视角又叫做维度（例如通过经销商、日期、客户、产品或区域等等，查看同一销售数据）。
OLAP系统的核心是OLAP立方体（或称为多维立方体或超立方体）。它由被称为度量的数值事实组成，这些度量被维度划分归类。一个OLAP立方体的例子如下图所示，数据单元位于立方体的交叉点上，每个数据单元跨越产品、时间、位置等多个维度。通常使用一个矩阵接口操作OLAP立方体，例如电子表格程序的数据透视表，可以按维度分组执行聚合或求平均值等操作。立方体的元数据一般由关系数据库中的星型模式或雪花模式生成，度量来自事实表的记录，维度来自维度表。
OLAP分析所需的原始数据量是非常庞大的。一个分析模型，往往会涉及数千万或数亿条数据，甚至更多，而分析模型中包含多个维度数据，这些维度又可以由用户作任意的组合。这样的结果就是大量的实时运算导致过长的响应时间。想象一个1000万条记录的分析模型，如果一次提取4个维度进行组合分析，每个维度有10个不同的取值，理论上的运算次数将达到10的12次方。这样的运算量将导致数十分钟乃至更长的等待时间。如果用户对维组合次序进行调整，或增加、或减少某些维度的话，又将是一个重新的计算过程。
从上面的分析中可以得出结论，如果不能解决OLAP运算效率问题的话，OLAP将只会是一个没有实用价值的概念。在OLAP的发展历史中，常见的解决方案是用多维数据库代替关系数据库设计，将数据根据维度进行最大限度的聚合运算，运算中会考虑到各种维度组合情况，运算结果将生成一个数据立方体，并保存在磁盘上。用这种以空间换时间的预运算方式提高OLAP的速度。那么，在大数据流行的今天，又有什么产品可以解决OLAP的效率问题呢？且看Hadoop生态圈中适合做OLAP的组件——Impala。
2. Impala简介
（1）Impala是 什么
Impala是一个运行在Hadoop之上的大规模并行处理（MPP）查询引擎，提供对Hadoop集群数据的高性能、低延迟的SQL查询，使用HDFS作为底层存储。它是基于Google Dremel的开源实现。对查询的快速响应使交互式查询和对分析查询的调优成为可能，而这些在针对处理长时间批处理作业的SQL-on-Hadoop传统技术上是无法完成的。
Impala与Hive元数据存储数据库相结合，在这两个组件之间共享数据库表，并且Impala与HiveQL的语法兼容。因此既可以使用Impala也可以使用Hive进行建立表、发布查询、装载数据等操作。Impala可以在已经存在的Hive表上执行交互式实时查询。
（2）为什么要使用Impala
（3）适合Impala的使用场景
（4）Impala架构
Impala架构图如下所示。
Impala服务器是一个分布式、大规模并行处理（MPP）数据库引擎。它由不同的守护进程组成，每种守护进程运行在Hadoop集群中的特定主机上。其中Impalad、Statestored、Catalogd三个守护进程在其架构中扮演主要角色。
Impala守护进程
Impala的核心组件是一个运行在集群中每个数据节点上的守护进程，物理表现为impalad进程。该进程读写数据文件，接收从impala-shell命令行、Hue、JDBC、ODBC提交的查询请求，将查询工作并行分布到集群的数据节点上，并将查询的中间结果返回给中心协调节点。
可以将查询提交至任意一个数据节点上运行的Impala守护进程，此守护进程实例担任该查询的协调器，其它节点提交部分中间结果返给协调器，协调器构建查询的最终结果集。当在试验环境使用impala-shell命令行运行SQL时，出于方便性，通常总是连接同一个Impala守护进程。而在生产环境负载的集群中，可以采用循环的方式，通过JDBC或ODBC接口，将每个查询轮流提交至不同的Impala守护进程，已达到负载均衡。
Impala守护进程持续与statestore进行通信，以确认每个节点健康状况以及是否可以接收新的任务。
当集群中的任何Impala节点建立、修改、删除任何类型的对象，或者通过Impala处理一个insert或load data语句时，catalogd守护进程（Impala 1.2引入）都会发出广播消息。Impala守护进程会接收这种从catalogd守护进程发出的广播消息。这种后台通信减少了对refresh或invalidate metadata语句的需要，而在Impala 1.2版本前，这些语句被用于在节点间协调元数据信息。
Impala Statestore
叫做statestore的Impala组件检查集群中所有数据节点上Impala守护进程的健康状况，并将这些信息持续转发给每个Impala守护进程。其物理表现为一个名为statestored的守护进程，该进程只需要在集群中的一台主机上启动。如果Impala守护进程由于硬件、软件、网络或其它原因失效，statestore会通知所有其它的Impala守护进程，这样以后的查询就不会再向不可到达的节点发出请求。
statestore的目的只是在发生某种错误时提供帮助，因此在正常操作一个Impala集群时，它并不是一个关键组件。即使statestore没有运行或者不可用，Impala守护进程依然会运行，并像通常一样在它们中分法任务。 这时如果一个Impala守护进程失效，仅仅是降低了集群的鲁棒性。当statestore恢复可用后，它会重建与Impala守护进程之间的通信并恢复监控功能。
在Impala中，所有负载均衡和高可用的考虑都是用于Impala守护进程的。statestored和catalogd进程没有高可用的需求，因为这些进程即使出现问题也不会引起数据丢失。当这些进程由于所在的主机停机而变成不可用时，可以这样处理：先停止Impala服务，然后删除Impala StateStore和Impala Catalog服务器角色，再在另一台主机上添加这两个角色，最后重启Impala服务。
Impala Catalog服务
称为Catalog服务的Impala组件将Impala SQL语句产生的元数据改变转发至集群中的所有数据节点。其物理表现为一个名为catalogd的守护进程，该进程只需要在集群中的一台主机上启动，而且应该与statestored进程在同一台主机上。
由于catalog服务的存在，当通过执行Impala语句而改变元数据时，不需要再发出refresh或invalidate metadata语句。然而，当通过Hive执行建立表、装载数据等操作后，在一个Impala节点上执行查询前，仍然需要先发出refresh或invalidate metadata语句。例如，通过Impala执行的create table、insert或其它改变表或改变数据的操作，无需执行refresh and invalidate metadata语句。而如果这些操作是用过Hive执行的，或者是直接操纵的HDFS数据文件，仍需执行refresh and invalidate metadata语句（只需在一个Impala节点执行，而不是全部节点）。
缺省情况下，元数据在Impala启动时异步装载并缓存，这样Impala可以立即接收查询请求。如果想让Impala等所有元数据装载后再接收查询请求，需要设置catalogd的配置选项load_catalog_in_background=false。
（4）开发Impala应用
Impala SQL方言
Impala的核心开发语言是SQL，也可以使用Java或其它语言，通过JDBC或ODBC接口与Impala进行交互，许多商业智能工具都使用这种方式。对于特殊的分析需求，还可以用C++或Java编写用户定义的函数（UDFs），补充SQL内建的功能。
Impala的SQL方言与Hive组件（HiveQL）在语法上高度兼容。正因如此，对于熟悉Hadoop架构上SQL查询的用户来说，Impala SQL并不陌生。当前，Impala SQL支持HiveQL语句、数据类型、内建函数的一个子集。Impala还包含一些附加的符合工业标准的内建函数，用于简化从非Hadoop系统移植SQL。
可以通过下面的接口连接Impala，并向Impala守护进程提交请求。
每个impalad守护进程运行在集群中的不同节点上，监听来自多个端口的请求。来自impala-shell和Hue的请求通过相同的端口被路由至impalad守护进程，而JDBC和ODBC的请求发往不同的impalad监听端口。
（5）Impala与Hadoop生态圈
Impala可以利用Hadoop生态圈中许多熟悉的组件，并且可以和这些组件交换数据，即可作为生产者也可作为消费者，因此可以灵活地加入到ETL管道中。
Impala与Hive
Impala的一个主要目标是让SQL-on-Hadoop操作足够快，以吸引新的Hadoop用户，或开发Hadoop新的使用场景。在实际中，许多Hadoop用户使用Hive来执行长时间运行的、面向批处理的SQL查询，而Impala可以利用这些已有的Hive架构。Impala将它的表定义存储在一个传统的MySQL或PostgreSQL数据库中，这个数据库被称为metastore，而Hive也将其元数据存储在同一个的数据库中。通过这种方式，只要Hive表定义的文件类型和压缩算法为Impala所支持，所有列的数据类型也是Impala所支持的类型，Impala就可以访问它。
Impala最初被设计成致力于提高查询的性能，这就意味着在Impala里，select语句能够读取的数据的类型比insert语句能够插入的数据的类型要多Impala可以读取使用Hive装载的Avro、RCFile或SequenceFile文件格式的数据。
Impala查询优化器也可以利用表和列的统计信息。在Impala 1.2.2版本前，使用Hive里的analyze table语句收集这些信息，在Impala 1.2.2及其更高版本中，使用Impala的compute stats语句收集信息。compute stats更灵活也更简单，并且不需要再impala-shell和Hive shell之间来回切换。
Impala的元数据和元数据存储
前面讨论Impala如何与Hive一起使用时提到，Impala使用一个叫做metastore的数据库维护它的表定义信息。同时Impala还跟踪其它数据文件底层特性的元数据，如HDFS中数据块的物理位置信息。
对于一个有很多分区或很多数据的大表，获取它的元数据可能很耗时，有时需要花上几分钟的时间。因此每个Impala节点都会缓存这些元数据，当后面再查询该表时，就可以复用缓存中的元数据。
如果表定义或表中的数据更新了，集群中所有其它的Impala守护进程在查询该表前， 都必须能收到最新的元数据，并更新自己缓存的元数据。在Impala 1.2或更高版本中，这种元数据的更新是自动的，由catalogd守护进程为所有通过Impala发出的DDL和DML语句进行协调。
对于通过Hive发出的DDL和DML，或者手工改变了HDFS文件的情况，还是需要在Impala中使用refresh语句（当新的数据文件被加到已有的表上）或invalidate metadata语句（新建表、删除表、执行了HDFS的rebalance操作，或者删除了数据文件）。invalidate metadata语句获取metastore中存储的所有表的元数据。如果能够确定在Impala外部只有特定的表被改变，可以为每一个受影响的表使用refresh 表名，该语句只获取特定表的最新元数据。
Impala与HDFS
Impala使用分布式文件系统HDFS作为主要的数据存储介质。Impala依赖HDFS提供的冗余功能，保证在单独节点因硬件、软件或网络问题失效后仍能工作。Impala表数据物理表现为HDFS上的数据文件，这些文件使用常见的HDFS文件格式和压缩算法。
Impala与Hbase
除HDFS外，HBase也是Impala数据存储介质的备选方案。HBase是建立在HDFS之上的数据库存储系统，不提供内建的SQL支持。许多Hadoop用户使用HBase存储大量的稀疏数据。在Impala中可以定义表，并映射为HBase中等价的表，通过这种方式就可以使用Impala查询HBase表的内容，甚至可以联合Impala表和HBase表执行关联查询。
1. OLAP简介
OLAP是Online Analytical Processing的缩写，意为联机分析处理。此概念最早是由关系数据库之父E.F.Codd于1993年提出，至今已有20多年。OLAP允许以一种称为多维数据集的结构，访问业务数据源经过聚合和组织整理的后数据。以此为标准，OLAP作为单独的一类产品同联机事务处理(OLTP)得以明显区分。
在计算领域，OLAP是一种快速应答多维分析查询的方法，也是商业智能的一个组成部分，与之相关的概念还包括数据仓库、报表系统、数据挖掘等。数据仓库用于数据的存储和组织，OLAP集中于数据的分析，数据挖掘则致力于知识的自动发现，报表系统则侧重于数据的展现。OLAP从数据仓库中的集成数据出发，构建面向分析的多维数据模型，再使用多维分析方法从多个不同的视角对多维数据进行分析比较，分析活动以数据驱动。
通过使用OLAP工具，用户可以从多个视角交互式地分析多维数据。OLAP由三个基本的分析操作构成：合并（上卷）、下钻和切片。合并是指数据的聚合，即数据可以在一个或多个维度上进行累积和计算。例如，所有的营业部数据被上卷到销售部门以分析销售趋势。下钻是一种由汇总数据向下浏览细节数据的技术，比如用户可以从产品分类的销售数据下钻查看单个产品的销售数据。切片则是这样一种特性，通过它用户可以获取OLAP立方体中的特定数据集合，并从不同的视角观察这些数据。这些观察数据的视角又叫做维度（例如通过经销商、日期、客户、产品或区域等等，查看同一销售数据）。
OLAP系统的核心是OLAP立方体（或称为多维立方体或超立方体）。它由被称为度量的数值事实组成，这些度量被维度划分归类。一个OLAP立方体的例子如下图所示，数据单元位于立方体的交叉点上，每个数据单元跨越产品、时间、位置等多个维度。通常使用一个矩阵接口操作OLAP立方体，例如电子表格程序的数据透视表，可以按维度分组执行聚合或求平均值等操作。立方体的元数据一般由关系数据库中的星型模式或雪花模式生成，度量来自事实表的记录，维度来自维度表。
OLAP分析所需的原始数据量是非常庞大的。一个分析模型，往往会涉及数千万或数亿条数据，甚至更多，而分析模型中包含多个维度数据，这些维度又可以由用户作任意的组合。这样的结果就是大量的实时运算导致过长的响应时间。想象一个1000万条记录的分析模型，如果一次提取4个维度进行组合分析，每个维度有10个不同的取值，理论上的运算次数将达到10的12次方。这样的运算量将导致数十分钟乃至更长的等待时间。如果用户对维组合次序进行调整，或增加、或减少某些维度的话，又将是一个重新的计算过程。
从上面的分析中可以得出结论，如果不能解决OLAP运算效率问题的话，OLAP将只会是一个没有实用价值的概念。在OLAP的发展历史中，常见的解决方案是用多维数据库代替关系数据库设计，将数据根据维度进行最大限度的聚合运算，运算中会考虑到各种维度组合情况，运算结果将生成一个数据立方体，并保存在磁盘上。用这种以空间换时间的预运算方式提高OLAP的速度。那么，在大数据流行的今天，又有什么产品可以解决OLAP的效率问题呢？且看Hadoop生态圈中适合做OLAP的组件——Impala。
2. Impala简介
（1）Impala是 什么
Impala是一个运行在Hadoop之上的大规模并行处理（MPP）查询引擎，提供对Hadoop集群数据的高性能、低延迟的SQL查询，使用HDFS作为底层存储。它是基于Google Dremel的开源实现。对查询的快速响应使交互式查询和对分析查询的调优成为可能，而这些在针对处理长时间批处理作业的SQL-on-Hadoop传统技术上是无法完成的。
Impala与Hive元数据存储数据库相结合，在这两个组件之间共享数据库表，并且Impala与HiveQL的语法兼容。因此既可以使用Impala也可以使用Hive进行建立表、发布查询、装载数据等操作。Impala可以在已经存在的Hive表上执行交互式实时查询。
（2）为什么要使用Impala
- Impala可以使用SQL访问存储在Hadoop上的数据，而传统的MapReduce则需要掌握Java技术。Impala还提供SQL直接访问HDFS文件系统、HBase数据库系统或Amazon S3的数据。
- Impala在Hadoop生态系统之上提供并行处理数据库技术，允许用户执行低延迟的交互式查询。
- Impala大都能在几秒或几分钟内返回查询结果，而相同的Hive查询通常需要几十分钟甚至几小时完成。
- Impala的实时查询引擎非常适合对Hadoop文件系统上的数据进行分析式查询。
- 由于Impala能实时给出查询结果，使它能够很好地与Pentaho、Tableau这类报表或可视化工具一起使用（这些工具已经配备了Impala连接器，可以从GUI直接执行可视化查询）。
- Impala与Hadoop生态圈相结合，内置对所有Hadoop文件格式（ORC、Parquet等等）的支持。这意味着可以使用Hadoop上的各种解决方案存储、共享和访问数据，同时避免了数据竖井，并且降低了数据迁移的成本。
- Impala缺省使用Parquet文件格式，这种列式存储对于典型数据仓库场景下的大查询是最优的。
（3）适合Impala的使用场景
- 需要低延迟得到查询结果。
- 快速分析型查询。
- 实时查询。
- 需要多次处理相同类型的查询。
（4）Impala架构
Impala架构图如下所示。
Impala服务器是一个分布式、大规模并行处理（MPP）数据库引擎。它由不同的守护进程组成，每种守护进程运行在Hadoop集群中的特定主机上。其中Impalad、Statestored、Catalogd三个守护进程在其架构中扮演主要角色。
Impala守护进程
Impala的核心组件是一个运行在集群中每个数据节点上的守护进程，物理表现为impalad进程。该进程读写数据文件，接收从impala-shell命令行、Hue、JDBC、ODBC提交的查询请求，将查询工作并行分布到集群的数据节点上，并将查询的中间结果返回给中心协调节点。
可以将查询提交至任意一个数据节点上运行的Impala守护进程，此守护进程实例担任该查询的协调器，其它节点提交部分中间结果返给协调器，协调器构建查询的最终结果集。当在试验环境使用impala-shell命令行运行SQL时，出于方便性，通常总是连接同一个Impala守护进程。而在生产环境负载的集群中，可以采用循环的方式，通过JDBC或ODBC接口，将每个查询轮流提交至不同的Impala守护进程，已达到负载均衡。
Impala守护进程持续与statestore进行通信，以确认每个节点健康状况以及是否可以接收新的任务。
当集群中的任何Impala节点建立、修改、删除任何类型的对象，或者通过Impala处理一个insert或load data语句时，catalogd守护进程（Impala 1.2引入）都会发出广播消息。Impala守护进程会接收这种从catalogd守护进程发出的广播消息。这种后台通信减少了对refresh或invalidate metadata语句的需要，而在Impala 1.2版本前，这些语句被用于在节点间协调元数据信息。
Impala Statestore
叫做statestore的Impala组件检查集群中所有数据节点上Impala守护进程的健康状况，并将这些信息持续转发给每个Impala守护进程。其物理表现为一个名为statestored的守护进程，该进程只需要在集群中的一台主机上启动。如果Impala守护进程由于硬件、软件、网络或其它原因失效，statestore会通知所有其它的Impala守护进程，这样以后的查询就不会再向不可到达的节点发出请求。
statestore的目的只是在发生某种错误时提供帮助，因此在正常操作一个Impala集群时，它并不是一个关键组件。即使statestore没有运行或者不可用，Impala守护进程依然会运行，并像通常一样在它们中分法任务。 这时如果一个Impala守护进程失效，仅仅是降低了集群的鲁棒性。当statestore恢复可用后，它会重建与Impala守护进程之间的通信并恢复监控功能。
在Impala中，所有负载均衡和高可用的考虑都是用于Impala守护进程的。statestored和catalogd进程没有高可用的需求，因为这些进程即使出现问题也不会引起数据丢失。当这些进程由于所在的主机停机而变成不可用时，可以这样处理：先停止Impala服务，然后删除Impala StateStore和Impala Catalog服务器角色，再在另一台主机上添加这两个角色，最后重启Impala服务。
Impala Catalog服务
称为Catalog服务的Impala组件将Impala SQL语句产生的元数据改变转发至集群中的所有数据节点。其物理表现为一个名为catalogd的守护进程，该进程只需要在集群中的一台主机上启动，而且应该与statestored进程在同一台主机上。
由于catalog服务的存在，当通过执行Impala语句而改变元数据时，不需要再发出refresh或invalidate metadata语句。然而，当通过Hive执行建立表、装载数据等操作后，在一个Impala节点上执行查询前，仍然需要先发出refresh或invalidate metadata语句。例如，通过Impala执行的create table、insert或其它改变表或改变数据的操作，无需执行refresh and invalidate metadata语句。而如果这些操作是用过Hive执行的，或者是直接操纵的HDFS数据文件，仍需执行refresh and invalidate metadata语句（只需在一个Impala节点执行，而不是全部节点）。
缺省情况下，元数据在Impala启动时异步装载并缓存，这样Impala可以立即接收查询请求。如果想让Impala等所有元数据装载后再接收查询请求，需要设置catalogd的配置选项load_catalog_in_background=false。
（4）开发Impala应用
Impala SQL方言
Impala的核心开发语言是SQL，也可以使用Java或其它语言，通过JDBC或ODBC接口与Impala进行交互，许多商业智能工具都使用这种方式。对于特殊的分析需求，还可以用C++或Java编写用户定义的函数（UDFs），补充SQL内建的功能。
Impala的SQL方言与Hive组件（HiveQL）在语法上高度兼容。正因如此，对于熟悉Hadoop架构上SQL查询的用户来说，Impala SQL并不陌生。当前，Impala SQL支持HiveQL语句、数据类型、内建函数的一个子集。Impala还包含一些附加的符合工业标准的内建函数，用于简化从非Hadoop系统移植SQL。
对于具有传统数据库或数据仓库背景的用户来说，下面关于SQL方言的内容应该是非常熟悉的：
- 包含where、group by、order by、with等子句的select语句（Impala的with子句并不支持递归查询），连接操作，处理字符串、数字、日期的内建函数、聚合函数、子查询、in和between这样的比较操作符等。这些select语句与SQL标准是兼容的。
- 分区表在数据仓库中经常使用。把一个或多个列作为分区键，数据按照分区键的值物理分布。当查询的where子句中包含分区键列时，可以直接跳过不符合过滤条件的分区，这也就是所谓的“分区消除”。例如，假设有10年的数据，并且查询语句中有类似where year = 2015、where year > 2010、where year in (2014, 2015)的where子句，则Impala跳过所有不匹配年份的数据，这会大大降低查询的I/O数量。
- 在Impala 1.2及其以上版本中，UDFs可以在select和insert...select语句中执行定制的比较和转换逻辑。
如果对Hadoop环境不够熟悉但具有传统数据库或数据仓库背景，需要学习并实践一下Impala SQL与传统SQL的不同之处：
- Impala SQL专注于查询而不是DML，所以没有提供update或delete语句。对于没用的陈旧数据，典型的做法是使用drop table或alter table ... drop partition语句直接删除，或者使用 insert overwrite语句将老数据替换掉。
- 在Impala中，所有的数据创建都是通过insert语句，典型情况是通过查询其它表批量插入数据。insert语句有两种插入数据的方式，insert into在现有数据上追加，而insert overwrite则会替换整个表或分区的内容（效果就像先truncate table再insert一样）。Impala没有insert ... values的插入单行的语法。
- 比较常见的情况是，在其它环境建立表和数据文件，然后使用Impala对其进行实时查询。相同的数据文件和表的元数据在Hadoop生态圈的不同组件之间共享。例如，Impala可以访问Hive里的表和数据，而Hive也可以访问在Impala中建立的表及其数据。许多其它的Hadoop组件可以生成Parquet和Avro格式的文件，Impala也可以查询这些文件。
- Hadoop和Impala的关注点在大数据集上的数据仓库型操作，因此Impala包含一些对于传统数据库应用系统非常重要的SQL方言。例如，可以在create table语句中指定分隔符，通过表读取以逗号和tab做分隔的文本文件。还可以建立外部表，在不迁移和转换现有数据文件的前提下读取它们。
- impala读取的大量数据可能不太容易确定其长度，所以不能强制字符串类型数据的长度。例如，可以定义一个表列为string类型，而不是象char(1)或varchar(64)限制字符串长度。（在Impala 1.2及其以后版本中，可以使用char和varchar类型限制字符串长度。）
可以通过下面的接口连接Impala，并向Impala守护进程提交请求。
- impala-shell命令行接口
- Hue基于web的用户界面
- JDBC
- ODBC
每个impalad守护进程运行在集群中的不同节点上，监听来自多个端口的请求。来自impala-shell和Hue的请求通过相同的端口被路由至impalad守护进程，而JDBC和ODBC的请求发往不同的impalad监听端口。
（5）Impala与Hadoop生态圈
Impala可以利用Hadoop生态圈中许多熟悉的组件，并且可以和这些组件交换数据，即可作为生产者也可作为消费者，因此可以灵活地加入到ETL管道中。
Impala与Hive
Impala的一个主要目标是让SQL-on-Hadoop操作足够快，以吸引新的Hadoop用户，或开发Hadoop新的使用场景。在实际中，许多Hadoop用户使用Hive来执行长时间运行的、面向批处理的SQL查询，而Impala可以利用这些已有的Hive架构。Impala将它的表定义存储在一个传统的MySQL或PostgreSQL数据库中，这个数据库被称为metastore，而Hive也将其元数据存储在同一个的数据库中。通过这种方式，只要Hive表定义的文件类型和压缩算法为Impala所支持，所有列的数据类型也是Impala所支持的类型，Impala就可以访问它。
Impala最初被设计成致力于提高查询的性能，这就意味着在Impala里，select语句能够读取的数据的类型比insert语句能够插入的数据的类型要多Impala可以读取使用Hive装载的Avro、RCFile或SequenceFile文件格式的数据。
Impala查询优化器也可以利用表和列的统计信息。在Impala 1.2.2版本前，使用Hive里的analyze table语句收集这些信息，在Impala 1.2.2及其更高版本中，使用Impala的compute stats语句收集信息。compute stats更灵活也更简单，并且不需要再impala-shell和Hive shell之间来回切换。
Impala的元数据和元数据存储
前面讨论Impala如何与Hive一起使用时提到，Impala使用一个叫做metastore的数据库维护它的表定义信息。同时Impala还跟踪其它数据文件底层特性的元数据，如HDFS中数据块的物理位置信息。
对于一个有很多分区或很多数据的大表，获取它的元数据可能很耗时，有时需要花上几分钟的时间。因此每个Impala节点都会缓存这些元数据，当后面再查询该表时，就可以复用缓存中的元数据。
如果表定义或表中的数据更新了，集群中所有其它的Impala守护进程在查询该表前， 都必须能收到最新的元数据，并更新自己缓存的元数据。在Impala 1.2或更高版本中，这种元数据的更新是自动的，由catalogd守护进程为所有通过Impala发出的DDL和DML语句进行协调。
对于通过Hive发出的DDL和DML，或者手工改变了HDFS文件的情况，还是需要在Impala中使用refresh语句（当新的数据文件被加到已有的表上）或invalidate metadata语句（新建表、删除表、执行了HDFS的rebalance操作，或者删除了数据文件）。invalidate metadata语句获取metastore中存储的所有表的元数据。如果能够确定在Impala外部只有特定的表被改变，可以为每一个受影响的表使用refresh 表名，该语句只获取特定表的最新元数据。
Impala与HDFS
Impala使用分布式文件系统HDFS作为主要的数据存储介质。Impala依赖HDFS提供的冗余功能，保证在单独节点因硬件、软件或网络问题失效后仍能工作。Impala表数据物理表现为HDFS上的数据文件，这些文件使用常见的HDFS文件格式和压缩算法。
Impala与Hbase
除HDFS外，HBase也是Impala数据存储介质的备选方案。HBase是建立在HDFS之上的数据库存储系统，不提供内建的SQL支持。许多Hadoop用户使用HBase存储大量的稀疏数据。在Impala中可以定义表，并映射为HBase中等价的表，通过这种方式就可以使用Impala查询HBase表的内容，甚至可以联合Impala表和HBase表执行关联查询。