Impala服务器的组件

Impala服务器是一个分布式的大规模并行处理（MPP）数据库引擎。它由不同的守护进程组成，这些进程在集群内的特定主机上运行。

Impala后台

Impala的核心组件是Impala守护进程，物理上由impalad进程表示。Impala 守护进程执行的几个主要功能是。

• 读取和写入数据文件
• 接受来自impala-shell命令、Hue、JDBC或ODBC的查询。
• 并行化查询并在集群中分配工作。
• 将中间查询结果传回中央协调器。

Impala 守护进程可以通过以下方式之一进行部署。

• HDFS和Impala共处一地，每个Impala守护进程作为DataNode运行在同一主机上。
• Impala单独部署在计算集群中，从HDFS、S3、ADLS等远程读取。

Impala守护进程一直与StateStore保持通信，以确认哪些守护进程是健康的，可以接受新的工作。

每当集群中的任何Impala守护进程创建、更改或丢弃任何类型的对象，或者通过Impala处理INSERT或LOAD DATA语句时，它们也会收到来自catalogd守护进程（Impala 1.2中引入）的广播消息。这种后台通信最大限度地减少了对REFRESH或INVALIDATE METADATA语句的需求，在Impala 1.2之前，协调Impala守护进程之间的元数据是需要这些语句的。

在Impala 2.9和更高版本中，您可以控制哪些主机作为查询协调器，哪些主机作为查询执行器，以提高大型集群上高并发工作负载的可扩展性。详情请参见如何使用专用协调器配置Impala。

Impala的状态存储

被称为StateStore的Impala组件检查集群中所有Impala守护进程的健康状况，并不断将其发现传递给每个守护进程。它在物理上由一个名为stesttored的守护进程来表示。您只需要在集群中的一台主机上有这样一个进程。如果一个Impala守护进程由于硬件故障、网络错误、软件问题或其他原因而离线，StateStore会通知所有其他Impala守护进程，以便未来的查询可以避免向无法到达的Impala守护进程发出请求。

因为StateStore的目的是在出错时提供帮助，并向协调器广播元数据，所以它并不总是对Impala集群的正常运行至关重要。如果StateStore没有运行或变得无法访问，Impala守护进程在处理Impala已知的数据时，会像往常一样继续运行并在彼此之间分配工作。如果其他Impala守护进程失败，集群只是变得不那么健壮，而且在StateStore离线时，元数据会随着变化而变得不那么一致。当StateStore重新上线时，它会重新建立与Impala守护进程的通信，并恢复其监控和广播功能。

如果您在StateStore离线时发出DDL语句，访问DDL创建的新对象的查询将失败。

负载均衡和高可用性的大多数考虑因素都适用于impalad daemon。statestored和catalogd守护进程对高可用性没有特殊要求，因为这些守护进程的问题不会导致数据丢失。如果这些守护进程由于特定主机上的故障而不可用，您可以停止Impala服务，删除Impala StateStore和Impala Catalog Server角色，在不同的主机上添加这些角色，然后重新启动Impala服务。

Impala目录服务

称为目录服务的Impala组件将Impala SQL语句中的元数据变化转发到集群中的所有Impala守护进程。它在物理上由一个名为 catalogd 的守护进程表示。您只需要在集群中的一台主机上有这样一个进程。因为请求是通过StateStore守护进程传递的，所以在同一台主机上运行stattored和catalogd服务是有意义的。

目录服务避免了通过Impala发出的语句进行元数据更改时，需要发出refresh和invalidate METADATA语句。当你通过Hive创建表、加载数据等，在那里执行查询之前，确实需要在Impala守护进程上发出REFRESH或INVALIDATE METADATA。

这个功能涉及到Impala的很多方面。

• 有关 catalogd 守护进程的使用信息，请参见安装 Impala、升级 Impala 和启动 Impala。
• 当通过Impala执行CREATE TABLE、INSERT或其他表更改或数据更改操作时，不需要REFRESH和INVALIDATE METADATA语句。如果这些操作是通过Hive或直接在HDFS中操作数据文件来完成的，仍然需要这些语句，但在这些情况下，这些语句只需要在一个Impala守护进程上发出，而不是在所有守护进程上发出。参见REFRESH语句和INVALIDATE METADATA语句，了解这些语句的最新使用信息。

使用--load_catalog_in_background选项来控制何时加载表的元数据。

• 如果设置为false，当表的元数据第一次被引用时就会被加载。这意味着特定查询的第一次运行可能会比后续运行慢。从Impala 2.2开始，--load_catalog_in_background的默认值为false。
• 如果设置为true，即使没有查询需要元数据，目录服务也会尝试加载表的元数据。因此，当运行第一个需要元数据的查询时，元数据可能已经被加载。然而，出于以下原因，我们建议不要将该选项设置为true。

后台加载会干扰特定查询的元数据加载。这可能会在启动时或在元数据失效后发生，持续时间取决于元数据的数量，并可能导致看似随机的长运行查询，难以诊断。
Impala可能会加载可能从未使用过的表的元数据，可能会增加目录大小，从而增加目录服务和Impala Daemon的内存使用量。
负载平衡和高可用性的大多数考虑因素都适用于impalad daemon。statestored和catalogd守护进程对高可用性没有特殊要求，因为这些守护进程的问题不会导致数据丢失。如果这些守护进程由于特定主机上的故障而不可用，您可以停止Impala服务，删除Impala StateStore和Impala Catalog Server角色，在不同的主机上添加这些角色，然后重新启动Impala服务。

注意事项
在Impala 1.2.4和更高版本中，您可以在Hive中创建表后，用INVALIDATE METADATA指定表名，允许您使各个表对Impala可见，而无需对目录元数据进行完整的重新加载。Impala 1.2.4还包括其他变化，使元数据广播机制更快、更灵敏，特别是在Impala启动期间。详情请参见Impala 1.2.4中的新功能。