管理调度程序资源和性能
调度程序的性能受调度程序中的微批处理数、每个微批处理中的分区和 Vertica 群集中的节点影响。使用资源池为调度程序分配一部分系统资源，并微调这些资源，以优化 Vertica 的自动加载。
以下各节详细介绍了调度程序资源池配置和处理场景：
调度程序和资源池
Vertica 建议您始终专门为每个调度程序创建一个 资源池。调度程序假定自身独占使用分配的资源池。为调度程序使用单独的池，有助于优化它对 Vertica 群集性能的影响。您可以使用 CREATE RESOURCE POOL 语句在 Vertica 中创建资源池。
如果没有为调度程序创建和分配资源池，它将使用 GENERAL 资源池的一部分。Vertica 建议您不要将 GENERAL 池用于生产环境中使用的调度程序。这种回退到使用 GENERAL 池的举措，是为了在测试调度程序配置期间提供方便。当您准备好部署调度程序时，请创建一个您已根据特定需求进行调整的资源池。每次启动使用 GENERAL 池的调度程序时，vkconfig 实用程序都会显示一条警告消息。
如果没有为调度程序分配足够的资源，则有可能会导致错误。例如，如果调度程序无法从预期的数据帧中加载所有主题的数据，则可能会显示错误：OVERSHOT DEADLINE FOR FRAME。
有关资源池的详细信息，请参阅资源池架构。
关键资源池设置
微批处理是一个工作单元，它在一个时间范围持续时间内处理单个 Kafka 主题的分区。以下资源池设置在 Vertica 如何加载微批处理和处理分区中发挥着重要作用：
- PLANNEDCONCURRENCY 决定调度程序同时发送给 Vertica 的微批处理（COPY 语句）的数量。在每一时间范围开始时，调度程序都会创建 PLANNEDCONCURRENCY 指定的调度程序线程数。每个调度程序线程连接到 Vertica，每次加载一个微批处理。如果微批处理数大于调度程序线程数，调度程序将额外的微批处理放入队列，并在线程变得可用时加载它们。
- EXECUTIONPARALLELISM 决定每个节点用于处理微批处理分区的最大线程数。当一个微批处理加载到 Vertica 时，它的分区会均匀地分布在群集中的节点之间。在每一时间范围期间，节点最多为每个分区创建一个线程。每个线程一次从一个分区读取数据，直到处理完成或该时间范围结束。如果分区数大于所有节点上的线程数，则在线程可用时处理剩余的分区。
- QUEUETIMEOUT 提供对资源计时的手动控制。将资源池参数 QUEUETIMEOUT 设置为 0 即可允许调度程序管理计时。在所有的微批处理都得到处理后，调度程序将等待该时间范围的剩余时间来处理下一个微批处理。具有适当大小的配置包括为了应对流量高峰而规划的休息时间。有关时间范围持续时间大小所带来影响的信息，请参阅选择时间范围持续时间。
例如，以下 CREATE RESOURCE POOL 语句将创建一个名为 weblogs_pool 的资源池，它同时加载 2 个微批处理。Vertica 群集中的每个节点为每个微批处理创建 10 个线程来处理分区：
=> CREATE RESOURCE POOL weblogs_pool
MEMORYSIZE '10%'
PLANNEDCONCURRENCY 2
EXECUTIONPARALLELISM 10
QUEUETIMEOUT 0;
对于三节点 Vertica 群集，weblogs_pool 为每个节点提供的资源将最多创建 10 个线程来处理分区，或者每个微批处理最多总共 30 个线程。
并发加载多个微批处理
在某些情况下，调度程序中的微批处理可能比可用的 PLANNEDCONCURRENCY 多。下面的几张图说明了当没有足够的调度程序线程同时加载每个微批处理时，调度程序如何将微批处理加载到单个 Vertica 节点中。虽然资源池的 PLANNEDCONCURRENCY (PC) 设置为 2，但是调度程序必须加载三个微批处理：A、B 和 C。为简单起见，将 EXECUTIONPARALLELISM (EP) 设置为 1。
首先，调度程序加载微批处理 A 和微批处理 B，而微批处理 C 等待：
当任何一个微批处理完成加载后，调度程序加载任何剩余的微批处理。在下图中，微批处理 A 已完全加载到 Vertica 中。调度程序继续加载微批处理 B，并使用新的可用调度程序线程加载微批处理 C：
调度程序继续发送数据，直到将所有微批处理加载到 Vertica 中，或该时间范围结束。
试用 PLANNEDCONCURRENCY 来优化性能。请注意，设置得过高可能会在每一时间范围的开始创建太多的连接，从而导致 Vertica 或 Kafka 的可扩展性压力。将 PLANNEDCONCURRENCY 设置得过低则不能充分利用 Vertica 的多处理能力。
Vertica 中的并行处理
资源池设置 EXECUTIONPARALLELISM 限制每个 Vertica 节点为处理分区创建的线程数。下图演示了在 EXECUTIONPARALLELISM 不足以为每个分区创建一个线程时，三节点 Vertica 群集如何处理具有九个分区的主题。这些分区均匀地分布在 Vertica 群集中的节点 1、节点 2 和节点 3 之间。调度程序的资源池将 PLANNEDCONCURRENCY (PC) 设置为 1，将 EXECUTIONPARALLELISM (EP) 设置为 2，因此当调度程序加载微批处理 A 时，每个节点最多创建 2 个线程。每个线程一次从一个分区进行读取。没有为其分配线程的分区必须等待处理：
当线程处理完为其分配的分区后，剩下的分区将在线程可用时分配给线程：
在调度程序的资源池上设置 EXECUTIONPARALLELISM 时，请考虑调度程序中所有微批处理的分区数。
并发加载分区主题
具有多个分区的单个主题可能会从增加并行加载或降低事务大小中受益。使用 --max-parallelism微批处理，可以动态地将具有多个分区的主题拆分为多个负载均衡的微批处理，每个微批处理均由原始微批处理的分区的子集组成。调度程序使用其资源池中可用的 PLANNEDCONCURRENCY 来同时加载动态拆分的微批处理。
调度程序资源池中的 EXECUTIONPARALLELISM 设置决定每个节点为处理其单个微批处理的部分分区而创建的最大线程数。拆分微批处理使每个节点都能够为同一工作单元创建更多的线程。当有足够的 PLANNEDCONCURRENCY 并且每个节点分配的分区数大于调度程序资源池中的 EXECUTIONPARALLELISM 设置时，使用 --max-parallelism 拆分微批处理并在每个节点上创建更多线程来并行处理更多分区。
下图演示了双节点 Vertica 群集如何使用 PLANNEDCONCURRENCY (PC) 和 EXECUTIONPARALLELISM (EP) 均设置为 2 的资源池来加载和处理微批处理 A。因为调度程序只加载一个微批处理，所以有 1 个调度程序线程未使用。每个节点为每个调度程序线程创建 2 个线程来处理分配给它的分区：
将微批处理 A 的 --max-parallelism 选项设为 2 将使调度程序可以动态地将微批处理 A 拆分为 2 个更小的微批处理 A1 和 A2。因为有 2 个调度程序线程可用，所以子集微批处理会同时加载到 Vertica 中。每个节点为每个调度程序线程创建 2 个线程来处理微批处理 A1 和 A2 的分区：
使用 --max-parallelism 防止由大容量 Kafka 主题组成的微批处理中出现瓶颈。它还为需要额外处理（如文本索引）的微批处理提供更快的加载。