Impala架构设计与实现解析

先看几个核心判断：

Impala Server的组件

Impala的底层架构，是一个分布式的MPP数据库引擎。简单说，就是把一个查询拆成多个小任务，分散到不同节点并行执行。这套系统的核心，是由几个在不同节点上、各有分工的守护进程组成的。

Impala守护进程

这一切的核心，就是集群里每台DataNode上都在跑的impalad进程。它的活儿很杂：读写数据、接收查询命令（来自impala-shell、Hue、JDBC或ODBC）、把查询拆散并行分发，最后再把中间结果汇总，送回协调节点。

你可以随便选一个DataNode上的impalad提交查询，这个节点就自动扮演了本次查询的协调者（Coordinator）。其他节点把局部结果传回给协调者，由它拼成最终的完整结果集。从实验角度讲，如果你图方便，一直连着同一个impalad也行；但在生产集群里，最佳实践是通过JDBC/ODBC接口，用轮询方式把请求均匀分散到不同节点上，实现负载均衡。

impalad会持续跟statestore沟通，时刻确认兄弟节点们是否安好、能不能接活儿。这是节点健康检查的核心机制。

一旦某个Impala节点在执行SQL时创建、修改或删除了什么对象（包括INSERT、LOAD DATA等操作），它还会从catalogd进程（Impala 1.2引入）那里收到广播通知，把元数据的变天信息通知给全集群。这套后台通信机制，大大减少了在Impala 1.2之前那种靠人工手动跑REFRESH或INVALIDATE METADATA来同步元数据的麻烦。

Impala Statestore

Statestore的职责很纯粹：它负责监控所有DataNode上impalad的健康状态，并持续把最新情况广播给每个impalad。它对应的守护进程名字叫statestored，通常只需要在集群里起一个实例就够了。

一旦某个impalad挂掉——不管是硬件故障、网络问题还是软件崩溃——statestore会立刻通知所有其他impalad：“别往那个地址发请求了。” 这样后续查询就能自动绕开那个失联节点。

话说回来，statestore的存在意义是在出问题时帮忙兜底，但它本身并不是集群正常运转的必需品。如果statestore挂了，impalad照样能干活，该查的数据继续查、该跑的查询照样跑——只是集群的抗风险能力下降了，因为一旦再出状况，大家无法第一时间知道。等statestore重新上线后，它会自动恢复与所有impalad的通信，监控功能也会重新上岗。

负载均衡和高可用性，大多数情况下是针对impalad进程来考虑的。而statestored和catalogd这两个进程不需要特别的高可用配置——它们的问题也不会导致数据丢失。如果它们所在的主机挂了，标准操作是：先停掉Impala服务，去掉旧的StateStore和Catalog Server角色，把这些角色添加到另外的主机上，再重启服务。

Impala Catalog Service

Catalog Service（目录服务）干的事，是把Impala SQL执行过程中产生的元数据变更，广播给集群里所有的DataNode。它的守护进程叫catalogd。同样，整个集群只需要一台机器跑一个实例。由于这些变更消息是走statestore管道传递的，所以通常建议把它和statestored放在同一台主机上，这是个靠谱的部署选择。

正是这个目录服务，让之前版本里那种手动敲REFRESH或INVALIDATE METADATA的痛苦得到了极大缓解。如果你是通过Impala执行的CREATE TABLE、INSERT或其他数据变更操作，这些元数据是自动同步的，不再需要手动刷。只有在通过Hive改了表、或者直接在HDFS里加删文件时，才仍然需要手动执行这些语句。而且好消息是：此时你只需要在一个Impala节点上执行，不用全集群每个节点敲一遍。

另外，默认情况下，Impala启动后的元数据加载是异步的，所以它能立刻开始接受查询请求。如果你偏要它把全量元数据都加载完了再放行，可以通过catalogd的配置选项--load_catalog_in_background=false来强制同步加载。

再次强调一下高可用的问题：statestored和catalogd的故障不会导致数据丢失，所以不需要像对impalad那样做复杂的HA配置。如果它俩挂在了某台主机上，处理步骤依旧是：停服务、删角色、挪到新主机上、重启。很简单。

开发Impala程序

Impala的核心开发语言是SQL。当然，你也可以通过标准JDBC和ODBC接口，用Ja va或其他语言集成它——很多BI工具就是这么干的。如果要做更复杂的分析库，还可以用C++或Ja va写UDF（用户自定义函数），来补充内置函数的功能。

Impala SQL方言概览

Impala的SQL方言高度兼容Apache Hive的HiveQL。所以，凡是接触过Hadoop SQL的用户，上手基本没难度。当然，Impala目前只支持HiveQL语句、数据类型和内置函数的一个子集。另外，它也内置了一些面向行业场景的常用函数，方便从非Hadoop系统迁移过来。这些细节属于锦上添花。

从传统数据库或数据仓库转过来的用户，会发现下面这些东西很眼熟：

• SELECT语句包含WHERE、GROUP BY、ORDER BY、WITH等子句。
• JOIN、字符串/日期/数字处理函数、聚合函数、子查询、IN()和BETWEEN这类比较运算符都有。
• 分区表的概念也是一脉相承：你可以把一列或多列当作分区键，数据物理上按这个规则排列。查询时如果WHERE条件引用了分区键（比如WHERE year=2015），Impala会直接跳过不匹配的分区，大幅减少I/O。
• 在Impala 1.2及以上，UDF可以在SELECT和INSERT...SELECT语句里执行自定义的比较和转换逻辑。

但对于同样这批用户，下面这几条可能需要花点功夫适应Hadoop环境：

• Impala专注于查询，DDL/DML相对简洁。没有UPDATE和DELETE。数据过时了怎么办？要么DROP TABLE，要么ALTER TABLE...DROP PARTITION，要么用INSERT OVERWRITE整体替换。所有数据写入都是通过INSERT语句批量完成的——从其他表SELECT出来再INSERT进去是常规操作。
• INSERT INTO是追加，INSERT OVERWRITE是先清空再写入，相当于TRUNCATE + INSERT。
• 虽然也支持INSERT...VALUES这样的小批量插入，但从数据量和效率角度来看，真正的王牌是INSERT...SELECT，它可以从一个表复制并转换大量数据，一步到位。
• 很多场景下，你会用其他工具把表定义和数据文件准备好，然后让Impala挂上去跑实时查询。Impala跟Hive之间的表和元数据天然共享——同一份文件、同一个Metastore。Hive的表Impala能用，Impala的表Hive也能访问。Parquet、A vro等格式的文件也被很多Hadoop组件共享，Impala可以直接查询。
• 由于Hadoop和Impala面向的是大数据集的数据仓库场景，它的SQL里也包含了一些你以前在传统数据库导入工具里才能见到的东西。比如创建表时，你可以指定分隔符，让Impala直接读取逗号或制表符分隔的文本文件。外部表则直接读取已有数据文件，不移动、不转换。另外，Impala不强制对字符串设长度限制——你可以直接定义成STRING。（Impala 2.0及更高版本也支持CHAR和VARCHAR等限长类型。）

Impala编程接口概览

你可以通过下面这些方式连接并提交请求给Impala守护进程：

• impala-shell：命令行交互工具。
• Hue：Web界面。
• JDBC / ODBC：标准数据库接口。

这些选项让Impala可以嵌入异构环境，甚至能在非Linux平台上运行JDBC/ODBC应用，和各种BI工具对接。每个节点上的impalad进程会在多个端口上监听不同来源的请求：来自impala-shell和Hue的请求走同一端口；JDBC和ODBC请求走另一个独立端口。

Impala如何融入Hadoop生态系统

Impala借用了Hadoop生态中许多成熟的组件。它既消费数据也生产数据，因此在ETL和ELT管道里灵活性很强。

Impala和Hive协同工作

Impala的目标很明确：让SQL-on-Hadoop反赌、足够快，以吸引新的用户群体、开辟新的使用场景。在不违背这一目标的前提下，它大量利用了现有Hive已经搭建好的基础设施。

具体来说，Impala把表定义信息存在传统的MySQL或PostgreSQL数据库里，也就是Hive保存表元数据的同一个地方——这个中央数据库叫Metastore。所以，只要所有的列都用到Impala支持的数据类型、文件格式和压缩编解码器，Impala就能直接读取Hive定义或加载的表。

在最初阶段，Impala更聚焦于查询性能，所以用它SELECT能读的数据类型，比用INSERT写进去的要丰富得多。如果要用A vro、RCFile或SequenceFile这些格式的数据，建议先用Hive把数据加载好。

关于表统计信息：Impala的查询优化器也依赖于表和列的统计信息。早先版本，你需要用Hive来跑ANALYZE TABLE。从Impala 1.2.2开始，改用Impala自带的COMPUTE STATS语句即可。这条语句设置简单、更可靠，也省去了你在impala-shell和Hive shell之间来回切换的麻烦。

Impala元数据和Metastore

前面提到，Impala的表定义信息集中在Metastore这个中央数据库中。除此之外，Impala还会跟踪数据文件的一些低层级元数据，包括：

• HDFS中文件块的实际物理位置。

对于表数据量大、分区多的场景，拉取全量元数据非常耗时，有时甚至要花几分钟。所以每个Impala节点都会把这些信息缓存起来，后续针对同一表的查询就能复用。需要注意的是：如果表定义或数据发生了变更，在再次查询之前，集群里所有其他impalad都必须收到最新元数据，并替换掉过时的缓存。

从Impala 1.2开始，通过Impala发出的所有DDL和DML语句，catalogd会自动协调元数据的更新。对于通过Hive执行的DDL/DML，或者手动改了HDFS里文件的情况，你仍然需要手动处理：

• REFRESH：用于新数据文件添加到已有表时。
• INVALIDATE METADATA：用于全新表创建、表被删除、HDFS做了重新平衡、或数据文件被删除时。

INVALIDATE METADATA会拉取Metastore中所有表的元数据。如果你知道只有特定的几张表发生了变更，可以只对它们执行REFRESH table_name，这样只会拉取目标表的最新数据，高效得多。

Impala如何使用HDFS

Impala把HDFS作为主要的数据存储介质，利用它的冗余机制来防止单点硬件或网络故障。Impala表数据在物理上就是HDFS上的数据文件，文件格式和压缩编解码器全部沿用HDFS生态。当新数据文件出现在表对应的目录下时，Impala会自动全部读取——不管文件名是什么。新写入的数据则会放到由Impala控制命名的文件中。

Impala如何使用HBase

除了HDFS，Impala还支持以HBase作为数据存储。HBase是构建在HDFS之上的一个数据库存储系统，没有SQL支持。很多Hadoop用户已经在里面存了大量数据，特别是稀疏数据集。你只需要在Impala里定义一个表，并把它映射到HBase里对应的表，就可以直接用Impala查询HBase的内容，甚至做Impala表和HBase表之间的Join。具体的操作细节，可以参考“使用Impala查询HBase表”相关章节（第685页）。

总的来说，Impala架构的精髓，在于这套分布式MPP引擎与Hadoop生态的深度耦合，以及它在组件分工、元数据管理和数据存储上的巧妙设计。理解了这几个关键点，也就理解了Impala为什么能跑得这么快、用起来这么顺。