Impala的可扩展性注意事项

本节介绍了群集大小和数据量如何影响Impala表的SQL性能和架构设计。 通常，添加更多群集容量可减少由于内存限制或磁盘吞吐量引起的问题。 另一方面，较大的集群更可能具有其他类型的可扩展性问题，例如导致查询性能问题的单个慢节点。

与可扩展性和性能调优相关的一个很好的技巧来源是Impala Cookbook演示。 随着新功能的出现和新基准的执行，这些幻灯片会定期更新。

许多表或分区对Impala目录性能和内存使用的影响

由于Hadoop I / O针对读取和写入大文件进行了优化，因此Impala针对包含相对较少的大型数据文件的表进行了优化。 包含数千个表或包含数千个分区的表的模式在启动期间或DDL操作（如ALTER TABLE语句）期间可能会遇到性能问题。

重要：

由于Impala 2.5及更高版本中catalogd守护程序的默认堆大小发生了更改，因此升级到Impala 2.5后可能需要执行以下过程来增加编目内存限制，即使以前不需要也是如此。

对于具有大量表，分区和数据文件的模式，catalogd守护程序可能会遇到内存不足错误。 要增加catalogd守护程序的内存限制：

1. 通过在群集上运行该守护程序的主机上运行以下命令，检查catalogd守护程序的当前内存使用情况：

jcmd catalogd_pid VM.flags 
jmap -heap catalogd_pid

2. 确定编目堆的足够大的值。 您可以使用JAVA_TOOL_OPTIONS环境变量来设置最大堆大小。 例如，以下环境变量设置指定最大堆大小为8 GB。

JAVA_TOOL_OPTIONS="-Xmx8g"

3. 在不使用群集管理软件的系统上，将此环境变量设置放入catalogd守护程序的启动脚本中，然后重新启动catalogd守护程序。
4. 使用与之前相同的jcmd和jmap命令验证新设置是否有效。

Impala Statestore的可扩展性注意事项

在Impala 2.1之前，statestore只向其订阅者发送了一种消息。此消息包含订阅者订阅的任何主题的所有更新。它还使订阅者知道statestore没有失败，相反，statestore使用成功向订阅者发送心跳以决定订阅者是否失败。

在单个消息中组合主题更新和故障检测导致具有大量表，分区和HDFS数据块的集群中的瓶颈。当statestore因传输元数据更新而过载时，心跳消息的发送频率较低，有时会导致订阅者超时与statestore的连接。增加订户超时并降低statestore心跳的频率可以解决问题，但是当statestore失败或重新启动时响应速度会降低。

从Impala 2.1开始，statestore现在在单独的消息中发送主题更新和心跳。这允许statestore发送和接收稳定的轻量级心跳流，并消除了根据固定调度发送主题更新的要求，从而减少了statestore网络开销。

statestore现在具有statestored守护程序的以下相关配置标志：

参数	解释
-statestore_num_update_threads	默认是10， 专用于发送主题更新的statestore中的线程数。 您通常不需要更改此值。
-statestore_update_frequency_ms	默认是2000，statestore尝试向每个订户发送主题更新的频率（以毫秒为单位）。 这是一个尽力而为的价值; 如果statestore无法满足此频率，则会尽快发送主题更新。 您通常不需要更改此值。
-statestore_num_heartbeat_threads	默认是10， statestore中专用于发送心跳的线程数。 您通常不需要更改此
-statestore_heartbeat_frequency_ms	默认是1000， statestore尝试向每个订户发送检测信号的频率（以毫秒为单位）。 此值应该适用于大型目录和最多约150个节点的群集。 除此之外，您可能需要增加此值以使心跳消息之间的间隔更长。

如果群集启动需要很长时间，并且impala-shell始终显示此Impala守护程序尚未准备好接受用户请求，则statestore可能需要很长时间才能将整个目录主题发送到群集。 在这种情况下，请考虑将–load_catalog_in_background = false添加到目录服务配置中。 此设置可阻止statestore在集群启动时将整个目录加载到内存中。 而是在第一次访问表时加载每个表的元数据。

缓冲池对内存使用的影响（Impala 2.10及更高版本）

Impala 2.10及更高版本中提供的缓冲池功能改变了Impala在查询期间分配内存的方式。 所需的大部分内存都是在查询开始时保留的，以避免在出现内存不足错误之前查询可能运行很长时间的情况。 实际的内存估计和内存缓冲区通常比以前更小，因此可以同时运行更多查询或处理比以前更大量的数据。

缓冲池功能包括一些可以微调的查询选项：第339页的BUFFER_POOL_LIMIT查询选项，第342页的DEFAULT_SPILLABLE_BUFFER_SIZE查询选项，第356页的MAX_ROW_SIZE查询选项和第362页的MIN_SPILLABLE_BUFFER_SIZE查询选项。

作为Impala用户，缓冲池的大多数效果都是透明的。 溢出期间的内存使用现在更稳定，更可预测，而不是随着更多数据溢出到磁盘而迅速增加。 从用户角度来看，主要的变化是在查询包含长字符串，多列或产生非常大的行的其他因子组合的列的表时需要增加MAX_ROW_SIZE查询选项设置。 如果Impala遇到的行太大而无法使用默认查询选项设置进行处理，则查询将失败并显示错误消息，建议增加MAX_ROW_SIZE设置。

溢出到磁盘的SQL操作

当Impala接近超过特定主机上的内存限制时，某些内存密集型操作会将临时数据写入磁盘（称为溢出到磁盘）。

结果是成功完成的查询，而不是因内存不足错误而失败。 由于额外的磁盘I / O要写入临时数据并将其读回，因此权衡会降低性能。减速可能会很大。 因此，虽然此功能可提高可靠性，但您应优化查询，系统参数和硬件配置，以使此溢出很少发生。

注意：在Impala 2.10及更高版本中，还可以参阅Impala的可扩展性注意事项（第668页），了解Impala内存分配的更改，这些更改可能会更改溢出到磁盘的查询的详细信息，以及溢出操作中涉及的内存和磁盘空间。

什么类型的查询可能会溢出到磁盘：

几个SQL子句和构造需要可以激活溢出机制的内存分配：

• 当查询对具有数百或数十亿个不同值的列使用GROUP BY子句时，Impala会在内存中保留相似数量的临时结果，以累积组中每个值的聚合结果。
• 当大表连接在一起时，Impala会将连接列的值保留在内存中的一个表中，以将它们与另一个表中的传入值进行比较。
• 当ORDER BY子句对大型结果集进行排序时，每个节点都会在内存中对结果集的部分进行排序。
• DISTINCT和UNION运算符构建内存数据结构，以表示到目前为止找到的所有值随着查询的进行消除重复。

为查询中的连接节点激活溢出到磁盘功能时，Impala不会为该主机上的该连接操作生成任何运行时筛选器。查询中的其他连接节点不受影响。

Impala如何处理溢出的临时磁盘空间：
默认情况下，存储在大型排序，连接，聚合或分析功能操作期间使用的中间文件在目录/ tmp / impala-scratch中。操作完成后将删除这些文件。 （多个并发查询可以执行使用“溢出到磁盘”技术的操作，而不会发生任何名称冲突
\对于这些临时文件。）您可以通过使用 - scratch_dirs =“path_to_directory”配置选项启动impalad守护程序来指定其他位置。您可以指定单个目录或逗号分隔的目录列表。临时目录必须位于本地文件系统上，而不是HDFS中。您可以为不同的主机指定不同的目录路径，具体取决于可用存储设备的容量和速度。在Impala 2.3或更高版本中，Impala成功启动（如果无法在其中一个临时目录中创建或读取和写入文件，则会出现警告Impala成功启动（向日志写入警告）。如果Impala少于1 GB该目录所在的文件系统，Impala仍在运行，但会向其日志写入警告消息。如果Impala在查询期间遇到读取或写入暂存目录中的文件的错误，Impala会记录错误并且查询失败。

SQL运算符的内存使用情况：

在Impala 2.10及更高版本中，SQL运算符（例如GROUP BY，DISTINCT和join）在使用附加内存或激活溢出到磁盘功能之间的转换方式已更改。溢出到磁盘所需的内存是预先保留的，当EXPLAIN_LEVEL查询选项设置为2或更高时，您可以在EXPLAIN计划中检查它。

溢出功能的基础结构会影响受影响的SQL运算符（如GROUP BY，DISTINCT和连接）使用内存的方式。在参与查询的每个主机上，查询中的每个此类运算符都需要内存来存储数据行和其他数据结构。 Impala为每个支持spill-to-disk的操作员预先保留一定量的内存，足以执行操作员。如果操作员累积的数据多于保留内存中可容纳的数据，则可以保留更多内存以继续处理内存中的数据，或者开始将数据溢出到磁盘上的临时暂存文件。因此，具有spill-to-disk支持的操作员可以通过使用大量内存来加速执行来适应不同的内存限制，同时通过将数据溢出到磁盘来容忍低内存条件。

数据量取决于该主机正在处理的数据部分，因此运营商最终可能在不同主机上消耗不同数量的内存。

添加于：此功能已添加到Impala 1.4中的ORDER BY子句中。此功能已扩展为涵盖Impala 2.0中的连接查询，聚合函数和分析函数。在Impala 2.2中，每个运算符溢出所需的内存工作区大小从512 MB减少到256 MB。溢出机制经过重新设计，以利用Impala缓冲池功能，并在Impala 2.10中更加可预测和稳定。

避免溢出到磁盘的查询：

由于额外的I / O会对这些类型的查询施加显着的性能开销，因此请尝试使用以下步骤来避免这种情况：

1. 检测查询溢出到磁盘的频率，以及写入多少临时数据。请参阅以下来源：

   • impala-shell解释器中PROFILE命令的输出。此数据显示每个主机的内存使用情况以及整个群集的内存使用情况。 WriteIoBytes计数器报告在查询期间为每个操作员写入磁盘的数据量。 （在Impala 2.9中，计数器名为ScratchBytesWritten;在Impala 2.8及更早版本中，它被命名为BytesWritten。）
   • Impala调试Web用户界面中的“查询”选项卡。选择要检查的查询，然后单击相应的配置文件链接。此数据分解了群集中单个主机的内存使用情况，该主机是您连接到其Web界面的主机。

2. 使用一种或多种技术来降低查询溢出到磁盘的可能性：

   • 如果可行，请增加Impala内存限制，例如，如果可以将可用内存增加的量超过在特定节点上写入磁盘的临时数据量。请记住，在Impala 2.0及更高版本中，您可以将SET MEM_LIMIT作为SQL语句发出，这样可以微调JDBC和ODBC应用程序中查询的内存使用情况。

   • 增加群集中的节点数，以增加Impala可用的聚合内存，并减少每个节点上所需的内存量。

   • 为运行Impala守护程序的主机添加更多内存。

   • 在具有Impala和其他Hadoop组件之间共享资源的群集上，使用资源管理为Impala分配更多内存的功能。有关详细信息，请参阅第682页的资源管理。

   • 如果内存压力是由于运行许多并发查询而不是一些内存密集型查询， 考虑使用Impala许可控制功能来降低并发查询数量的限制。通过隔离资源最密集的查询，可以避免内存使用量的激增并缩短总体响应时间。有关详细信息，请参阅第682页的“准入控制和查询队列”。

   • 使用以下一种或多种技术调整具有最高内存要求的查询：

     • 对大规模连接和聚合查询中涉及的所有表运行COMPUTE STATS语句。
     • 尽量减少在连接列中使用STRING列的过程。更喜欢数字值。
     • 检查EXPLAIN计划，以了解用于最多资源的执行策略 - 密集查询。有关详细信息，请参阅使用EXPLAIN计划进行性能调整（第664页）
     • 如果Impala仍然选择次优执行策略，即使可用统计信息，或者对于大型或快速更改的表保持最新统计信息是不切实际的，请向资源最密集的查询添加提示以选择正确的执行策略。有关详细信息，请参阅第406页的优化程序提示。

   • 如果由于溢出导致查询遇到大量性能开销，请启用DISABLE_UNSAFE_SPILLS查询选项。此选项可防止内存使用量过高的查询溢出到磁盘。有关详细信息，请参见第345页的DISABLE_UNSAFE_SPILLS查询选项（仅限Impala 2.0或更高版本）。在使用前面的步骤调整有问题的查询时，此选项设置将取消越来越少的查询。

测试溢出到磁盘的性能影响：

要人为地引发溢出，要测试此功能并了解性能影响，请使用内存限制至少为2 GB的测试环境。发出不带参数的SET命令以检查MEM_LIMIT查询选项的当前设置。设置查询选项DISABLE_UNSAFE_SPILLS = true。这个选项限制“溢出到磁盘”功能，以防止预先知道的查询中的磁盘使用失控不是最理想的。在impala-shell中，根据前面解释的标准运行您希望占用大量内存的查询。大表的自联接是一个很好的选择：

 select count(*) from big_table a join big_table b using
 (column_with_many_values);

何时使用DISABLE_UNSAFE_SPILLS：

您可能想知道，为什么不一直打开DISABLE_UNSAFE_SPILLS。使用此选项的频率和频率取决于您的系统环境和工作负载。

DISABLE_UNSAFE_SPILLS适用于具有即时查询的环境，其性能特征和内存使用情况事先未知。它可以防止不必要地使用大量内存的“最坏情况”查询。因此，您可以在开发新SQL代码时在会话中启用此选项，即使它已针对现有应用程序关闭。

表和列统计信息通常是最新的组织可能会一直打开此选项，同样为了避免未经测试的查询的最坏情况，或者ETL管道中的问题导致表没有统计信息。启用DISABLE_UNSAFE_SPILLS可以让您在这种情况下“快速失败”并立即收集统计信息或调整有问题的查询。

某些组织可能会关闭此选项。例如，您可能拥有足够大的表，以致COMPUTE STATS需要大量时间才能运行，因此在加载新数据后重新运行是不切实际的。如果您已经检查过查询的EXPLAIN计划并知道它们正在高效运行，则可能会关闭DISABLE_UNSAFE_SPILLS。在这种情况下，您知道任何溢出的查询都不会过度耗费内存消耗。

查询大小和复杂性的限制

查询的最大大小和复杂性存在硬编码限制。 目前，查询中的最大表达式数为2000.您可能会超过商业智能工具或其他查询生成器生成的大型或深层嵌套查询的限制。

如果您能够自定义此类查询或生成它们的查询生成逻辑，请使用可以表示多个值或范围的单个运算符（如IN或BETWEEN）替换重复表达式的序列。 例如，而不是大量的OR子句：

WHERE val = 1 OR val = 2 OR val = 6 OR val = 100 ...

使用 in 子句

WHERE val IN (1,2,6,100,...)

Impala I / O的可扩展性注意事项

Impala积极地并行化其I / O操作，因此可以连接到每个主机的磁盘越多越好。 Impala使用大块上的批量读取操作快速从磁盘检索数据，大多数查询都是CPU绑定的而不是I / O绑定的。

由于通常由Impala查询完成的顺序扫描并不会从SSD的随机访问功能中获益，因此旋转磁盘通常为Impala数据提供最具成本效益的存储类型，与SSD相比，性能损失很小或没有。

资源管理功能（如YARN，Llama和许可控制）通常会限制高并发环境中的内存量，CPU或查询总数。 目前，Impala I / O没有限制机制。

Table布局的可扩展性注意事项

由于在Metastore数据库中检索和更新表元数据的开销，尝试将表中的列数限制为最大约2000.虽然Impala可以处理比这更宽的表，但Metastore开销可能会变得很大，导致 查询性能比实际数据量慢于预期。

要最大限度地减少与Metastore数据库和Impala查询计划相关的开销，请尝试将任何分区表的分区数限制为几万。

如果表中的数据量使得运行探索性查询变得不切实际，请考虑使用TABLESAMPLE子句将查询处理限制为表中的一定百分比的数据。 此技术减少了查询启动的开销，读取数据的I / O以及在查询期间处理中间结果所需的网络，CPU和内存量。 有关详细信息，请参见第329页的TABLESAMPLE子句。

大型群集的Kerberos相关网络开销

当Impala启动时，或每次kinit刷新后，Impala会向KDC发送一些同时发出的请求。对于具有100个主机的群集，KDC可能能够在大约5秒内处理所有请求。对于具有1000个主机的群集，处理请求的时间大约为500秒。 Impala还会与这些与Kerberos相关的请求同时发出许多DNS请求。

在处理这些身份验证请求时，任何提交的Impala查询都将失败。在此期间，KDC和DNS可能很慢地响应来自Impala之外的组件的请求，因此其他安全服务可能会暂时受到影响。

在Impala 2.12或更早版本中，要降低启动一组新身份验证请求的kinit续订频率，请增加impalad守护程序的kerberos_reinit_interval配置设置。目前，默认值为60分钟。考虑使用更高的值，例如360（6小时）。

在Impala 3.0中删除了kerberos_reinit_interval配置设置，不再需要上述步骤。

避免HDFS缓存数据的CPU热点

您可以使用HDFS缓存功能（如第657页上的“使用Impala的HDFS缓存（仅限Impala 2.1或更高版本）”中所述，使用Impala减少频繁访问的表或分区的I / O和内存到内存复制。

在此功能的早期阶段，您可能已经发现启用HDFS缓存导致很少或没有性能提升，因为它可能导致“热点”：而不是I / O来读取跨群集并行化的表数据， I / O减少了，但处理数据块的CPU负载可能集中在一台主机上。

要避免热点，请为使用HDFS缓存的表包含WITH REPLICATION子句和CREATE TABLE或ALTER TABLE语句。该子句允许多个主机缓存相关数据块，因此可以共享CPU负载，从而减少任何一台主机上的负载。请参见第242页的CREATE TABLE语句， 有关详细信息，请参见第210页的ALTER TABLE语句。

由于Impala调度处理不同主机上的数据块的工作方式，在某些情况下仍可能出现具有高CPU负载的HDFS缓存数据的热点。在Impala 2.5及更高版本中，调度改进意味着HDFS缓存数据的工作在具有特定数据块的缓存副本的所有主机中得到更好的划分。当多个主机具有数据块的缓存副本时，Impala会分配工作
处理该块对于当前查询所做的工作量最少的工作（就读取的字节数而言）。如果使用此基于负载的调度算法，热点仍然存在，则可以启用查询选项SCHEDULE_RANDOM_REPLICA = TRUE以进一步分配CPU负载。此设置会导致Impala随机选择一个主机来处理缓存的数据块，如果调度算法在决定哪个主机完成的工作量最少时遇到一个平局。

具有文件句柄缓存的NameNode流量的可伸缩性注意事项

影响负载较重的集群的一个可扩展性方面是HDFS NameNode在每个HDFS文件打开时查找详细信息的负载。 Impala查询通常会访问许多不同的HDFS文件。例如，在分区表上执行全表扫描的查询可能需要读取数千个分区，每个分区包含多个数据文件。访问Parquet文件的每一列还涉及单独的“打开”调用，这进一步增加了NameNode的负载。高NameNode开销可以为Impala查询添加启动时间（即增加延迟），并降低还需要访问HDFS文件的非Impala工作负载的总体吞吐量。
在Impala 2.10及更高版本中，您可以通过为HDFS文件句柄启用缓存功能来减少NameNode开销。可以访问由不同查询访问的数据文件，甚至在同一查询中多次访问的数据文件，无需新的“打开”调用，也无需再从NameNode获取文件详细信息。

在Impala 3.2及更高版本中，文件句柄缓存也适用于远程HDFS文件句柄。这由impalad的cache_remote_file_handles标志控制。建议您使用默认值true，因为当您的群集有许多远程HDFS读取时，此缓存可防止NameNode过载。

由于此功能仅涉及HDFS数据文件，因此它不适用于非HDFS表（如Kudu或HBase表）或将数据存储在云服务（如S3或ADLS）上的表。

默认情况下启用此功能，并缓存20,000个文件句柄。要更改该值，请为每个impalad守护程序将配置选项max_cached_file_handles设置为非零值。从初始默认值20000开始，如果NameNode请求加载仍然很大，则向上调整;如果更重要的话，减少每个主机上的额外内存使用量，则向下调整。每个缓存条目消耗6 KB，这意味着缓存20,000个文件句柄需要每个Impala执行程序最多120 MB。确切的内存使用情况取决于实际缓存的文件句柄数量;当文件句柄从缓存中逐出时，内存被释放。

如果在缓存文件句柄时手动HDFS操作将文件移动到HDFS Trashcan，Impala仍会访问该文件的内容。这是对先前行为的改变。以前，访问垃圾箱中的文件会导致错误。此行为仅适用于删除HDFS文件的非Impala方法，而不适用于TRUNCATE TABLE或DROP TABLE等Impala机制。

如果文件被Impala之外的HDFS操作删除，替换或附加，则使文件信息保持最新的方法是在表上运行REFRESH语句。

文件句柄缓存条目在缓存填满时被逐出，或者基于一段时间未访问缓存时的超时时间。

要评估特定工作负载的文件句柄缓存的有效性，请发出PROFILE impala-shell中的语句或检查Impala Web UI中的查询概要文件。查找CachedFileHandlesHitCount（理想情况下应该是高）与CachedFileHandlesMissCount（理想情况下应该是低）的比率。在开始任何评估之前，运行几个代表性查询以“预热”缓存，因为第一次访问每个数据文件时始终记录为缓存未命中。

要查看有关每个impalad实例的文件句柄缓存的指标，请检查Impala Web UI中的/ metrics页面，特别是impala-server.io.mgr.cached-file-handles-miss-count，impala-server.io字段。 .mgr.cached- file-handles-hit-count和impala-server.io.mgr.num-cached-file-handles。

如何使用专用协调器配置Impala

运行Impala守护程序的每个主机都充当协调器和执行程序，默认情况下，管理元数据缓存，查询编译和查询执行。 在此配置中，Impala客户端可以连接到任何Impala守护程序并发送查询请求。

在针对大规模查询的高度并发工作负载期间，双重角色可能会导致可伸缩性问题，因为：

• 主机充当协调器所需的额外工作可能会影响其在后续查询阶段执行其他工作的能力。例如，协调器可能会在包含大量查询片段的查询中遇到大量网络和CPU开销。每个协调器都缓存所有表分区和数据文件的元数据，这需要协调器配置大型JVM堆。应该使用默认的JVM堆配置仅限执行程序的Impala守护程序，这会留下更多可用于处理联接，聚合和查询执行程序执行的其他操作的内存。

• 将大量主机充当协调器可能会导致不必要的网络开销，甚至是超时错误，因为每个主机都与Statestored守护程序进行通信以进行元数据更新。

• 当有大量负载较重的主机充当协调员时，更有可能超过准入控制功能强加的“软限制”。检查IMPALA-3649和IMPALA-6437以查看增强功能的状态以缓解此问题。

以下因素可能进一步加剧上述问题：

• 由于查询并发性和/或查询复杂性导致的大量并发查询片段
• 与分区/文件/块数相关的大型元数据主题大小
• 大量协调节点
• 在同一资源池中使用大量协调器

如果出现此类可伸缩性瓶颈，则在Impala 2.9及更高版本中，您可以为每个Impala后台程序主机分配一个专用角色，作为协调程序或执行程序，以解决问题。

• 所有显式或负载平衡的客户端连接都必须转到协调器主机。这些主机执行网络通信以使元数据保持最新，并将查询结果路由到适当的客户端。专用协调器主机不参与I / O密集型操作（如扫描）和CPU密集型操作（如聚合）。

• 执行程序主机执行密集的I / O，CPU和内存操作，这些操作构成了每个查询的大部分工作。执行程序确实与Statestored守护程序进行通信以获取成员资格状态，但专用执行程序主机不处理查询的最终结果集。

使用专用协调员可提供以下好处：

• 通过限制需要缓存元数据的Impala节点数来减少内存使用量。
• 通过避免协调器瓶颈提供更好的并发性。
• 消除查询过度录取。
• 通过将元数据广播限制为a来减少Statestored守护程序上的资源，尤其是网络利用率节点子集。
• 通过减少工作负载压力，提高高度并发工作负载的可靠性和性能协调员。专用协调员需要50％或更少的连接和线程。
• 减少所需的显式元数据刷新次数。
• 如果在特定主机上出现瓶颈或其他性能问题，可以提高可诊断性，您可以缩小范围原因更简单，因为每个主机都专用于整个Impala工作负载中的特定操作。

在具有专用协调器/执行器的此配置中，您无法通过impala-shell或商业智能工具等客户端连接到专用执行器主机，因为只有协调器节点支持客户端连接。

确定专用协调员的最优数量

您应该拥有最少数量的协调器，这些协调器仍然可以满足群集中的工作负载要求。粗略估计是每50个执行者1名协调员。

为了保持健康状态和最佳性能，建议您将Impala使用的所有资源（包括CPU，线程数，连接数和RPC）的峰值利用率保持在80％以下。

请考虑以下因素来确定群集中正确的协调员数量：

• 并发查询的数量是多少？
• DDL的工作负载百分比是多少？
• 各个阶段（合并，运行时过滤器，结果集大小等）的平均查询资源使用量是多少？
• 群集中有多少Impala守护进程（impalad）？
• 是否有高可用性要求？
• 计算/存储容量减少因子

从以下一组步骤开始，确定协调员的初始数量：

1. 如果您的群集节点少于10个，我们建议您配置一个专用协调器。在DataNode上部署专用协调器以避免丢失存储容量。在大多数情况下，一个专用协调器足以支持群集上的所有工作负载。
2. 如果专用协调器CPU或网络峰值利用率为80％或更高，则添加更多协调器。每50个执行者可能需要1个协调员。
3. 如果Impala服务由分配了动态资源池的多个工作组共享，则每个池使用一个协调器以避免对准入的入口控制。
4. 如果需要高可用性，则协调员数量增加一倍。一个设置为活动集，另一个设置为备份集。

高级调整

使用以下准则进一步调整吞吐量和稳定性。

1. DML语句的并发性通常不依赖于协调器的数量或集群的大小。返回大型结果集（10,000多行）的查询会在协调器上消耗更多的CPU和内存资源。如果工作负载有许多此类查询，请添加一个或两个协调器。

2. DDL查询（不包括COMPUTE STATS和CREATE TABLE AS SELECT）仅在协调器上执行。如果您的工作负载包含许多并发运行的DDL查询，则可以添加一个协调器。

3. 协调器上的CPU争用可能会在并发性很高时减慢查询执行速度，尤其是对于非常短的查询（<10s）。添加更多协调器以避免CPU争用。

4. 在具有50个以上节点的大型群集上，随着查询复杂性的增加，从协调器到执行器的网络连接数可以快速增长。协调员比执行者的增长要大得多。如果工作负载很复杂，则添加一些协调器，即（平均碎片数* Impalad数）> 500，但内存/ CPU使用率较低，以共享负载。观看IMPALA-4603和IMPALA-7213以跟踪解决此问题的进度。

5. 对DML语句使用多个协调器时，将查询划分到不同的组（组数=协调器数）。为每个组配置单独的动态资源池，并将每组查询请求定向到特定的协调器。这是为了避免在入场时进行查询。

6. 前端连接要求不是确定专用协调员数量的因素。考虑在客户端设置连接池，而不是添加协调器。对于短期解决方案，您可以在协调器上增加fe_service_threads的值以允许更多客户端连接。

7. 一般而言，您应该拥有极少数的协调员，因此不需要考虑减少存储容量。在非常小的集群（少于10个节点）上，在DataNode上部署专用协调器以避免存储容量减少。

部署专用协调员和执行人员

本节介绍为Impala配置专用协调器和专用执行程序角色的过程。

• 专用协调器：它们应位于边缘节点上，而不运行其他服务。它们不需要大型本地磁盘，但仍需要一些可用于Spilling的磁盘。它们至少需要相同甚至更大的内存分配。
• （专用）执行程序：它们应像往常一样与DataNode共存。具有此设置的主机数通常随着群集变大而增加，并处理更多表分区，数据文件和并发查询。

要配置专用协调器/执行程序，请在每个主机上为impalad守护程序指定以下启动标志之一：

• 对于不充当Impala查询执行程序的每个主机，is_executor = false。这些主机专门用作查询协调器。此设置通常适用于相对较少数量的主机，因为最常见的拓扑是几乎所有DataNode都在执行查询。
• 对于不充当Impala查询协调器的每个主机，is_coordinator = false。这些主机仅作为执行者。具有此设置的主机数通常随着群集变大而增加，并处理更多表分区，数据文件和并发查询。随着查询协调的开销增加，将该工作集中在专用主机上变得更加重要。

元数据管理

本主题描述了可用于控制Impala如何管理其元数据以提高性能和可伸缩性的各种旋钮。

元数据自动失效的启动选项

为了保持元数据的大小，catalogd会定期扫描所有表，并使那些最近未使用的表无效。 catalogd中有两种类型的配置。

• 使用–invalidate_tables_timeout_s标志进行基于时间的失效：Catalogd使指定时间段内最近未使用的表无效（以秒为单位）。此标志需要应用于impalad和catalogd。

• 使用–invalidate_tables_on_memory_pressure标志进行基于内存的失效：当catalogd中的Java垃圾回收后内存压力达到JVM堆大小的60％时，Impala会使最近最少使用的表的10％失效。此标志需要应用于impalad和catalogd。

元数据的自动失效提供了更高的稳定性，同时内存不足的可能性更低，但该功能可能会导致性能问题并可能需要调整。

注意：这是Impala 3.1中的预览功能，通常不可用。

从目录服务器加载增量统计信息

从Impala 3.1开始，添加了一个新配置设置–pull_incremental_statistics，默认情况下设置为true。在启用此设置的情况下启动Impala catalogd和impalad协调器时：

• 新创建的增量统计信息的大小会更小，从而减少catalogd守护程序的内存压力。您的用户可以在同一目录中保留更多表和分区，并且由于内存不足问题而导致编目崩溃的可能性更低。
• 增量统计信息不会复制到impalad，并且会根据需要从catalogd访问，从而减少了impalad的内存占用。

我们不建议您更改默认设置–pull_incremental_statistics。

使用Hive Metastore通知事件自动元数据同步

启用此功能后，catalogd将以可配置的间隔轮询Hive Metastore（HMS）通知事件并处理以下更改：

注意：这是Impala 3.2中的预览功能，通常不可用。

• 在表收到ALTER TABLE事件或ALTER，ADD或DROP其分区时使表无效。
• 在收到CREATE TABLE或CREATE DATABASE事件时添加表或数据库。
• 在收到DROP TABLE或DROP DATABASE事件时从catalogd中删除表。

此功能由–hms_event_polling_interval_s标志控制。启动catalogd并将–hms_event_polling_interval_s标志设置为非零值以启用该功能并以秒为单位设置轮询频率。我们建议该值小于5秒。

不支持以下用例：

• 不支持不在HMS中生成事件的操作，例如从Spark向现有表/分区添加新数据。
• 将一个Impala集群中的数据添加到现有表/分区不会同步到另一个Impala集群。仅同步新表和分区。
• 不支持ALTER DATABASE事件，当前忽略这些事件。
  默认情况下，此功能处于关闭状态，并且–hms_event_polling_interval_s标志设置为0。

为基于事件的自动元数据同步配置HMS

作为使用基于HMS事件的元数据同步的第一步，将以下条目添加到Hive Metastore服务的hive-site.xml。

<property>
   <name>hive.metastore.transactional.event.listeners</name>
         <value>org.apache.hive.hcatalog.listener.DbNotificationListener</value>
</property>

禁用基于事件的自动元数据同步

如果将–hms_event_polling_interval_s标志设置为catalogd的非零值，则会为所有数据库和表启用基于事件的自动失效。如果希望对使用事件同步哪些表或数据库进行细粒度控制，可以使用impala.disableHmsSync属性在表或数据库级别禁用事件处理。

使用impala.disableHmsSync键添加DBPROPERTIES或TBLPROPERTIES时，将打开或关闭基于HMS事件的同步。 impala.disableHmsSync属性的值确定是否需要为特定表或数据库禁用事件处理。

• 如果’impala.disableHmsSync’=‘true’，则忽略该表或数据库的事件，并且不与HMS同步。
• 如果’impala.disableHmsSync’='false’或未设置impala.disableHmsSync，则如果–hms_event_polling_interval_s全局标志设置为非零，则启用与HMS的自动同步。
• 要为新数据库禁用基于事件的HMS同步，请在Hive中将impala.disableHmsSync数据库属性设置为当前，Impala不支持设置数据库属性：

CREATE DATABASE <name> WITH DBPROPERTIES ('impala.disableHmsSync'='true');

• 要为表启用或禁用基于事件的HMS同步：

 CREATE TABLE <name> WITH TBLPROPERTIES ('impala.disableHmsSync'='true' |
 'false');

• 要在表级别更改基于事件的HMS同步：

 ALTER TABLE <name> WITH TBLPROPERTIES ('impala.disableHmsSync'='true' |
 'false');

设置表和数据库级属性时，表级属性优先。如果未设置表级属性，则使用数据库级属性来评估是否需要处理事件。

如果属性从true（意味着跳过事件）更改为false（意味着不跳过事件），则需要发出手动INVALIDATE METADATA命令来重置事件处理器，因为它不知道已跳过了多少事件。过去并不知道事件中的对象是否是最新的。在这种情况下，事件处理器的状态将更改为NEEDS_INVALIDATE。

基于事件的自动元数据同步的度量标准

您可以使用catalogd的Web UI来检查自动无效事件处理器的状态。

默认情况下，catalogd的调试Web UI位于http：// impala-server-hostname：25020（非安全
cluster）或https：// impala-server-hostname：25020（安全集群）。

在Web UI下，有两个页面显示负责HMS事件处理器的度量标准基于事件的自动元数据同步

• / metrics＃events
• /events

这提供了事件处理器的度量的详细视图，包括最小值，最大值，平均值，中值
/ metrics＃events页面上列出的所有计数器的持续时间和费率指标。