选择时间范围持续时间

调度程序的一个关键设置是它的时间范围持续时间。持续时间设置调度程序运行您为其定义的所有微批处理的时间量。此设置对如何从 Apache Kafka 加载数据有显著的影响。

在每一时间范围期间会发生什么

要了解正确的时间范围持续时间，首先需要了解在每一时间范围期间发生了什么。

时间范围持续时间在添加到调度程序的微批处理之间分配。此外，每一时间范围都有一些开销，需要花时间处理微批处理。在每个微批处理中，也有一些开销，这减少了微批处理在从 Kafka 加载数据方面花费时间。下图大致显示了每一时间范围是如何划分的：

正如您所见，时间范围中只有一部分时间用于实际加载流式传输数据。

调度程序如何对微批处理排列优先顺序

首先，调度程序将时间范围中的时间均匀地分给各个微批处理。然后，它依次运行每个微批处理。

在每个微批处理中，专门花大量时间来通过 COPY 语句加载数据。此语句使用 KafkaSource UDL 加载数据。它会一直运行到发生以下两种情况之一：

它到达为微批处理定义的主题和分区的数据流的末端。在这种情况下，微批处理提前完成处理。
它到达调度程序设置的超时时间。

当调度程序处理时间范围时，它会记下哪些微批处理提前完成。然后，它会安排它们在下一时间范围首先运行。如果以这种方式安排微批处理，则可以让调度程序将时间范围中的更多时间分配给在加载数据方面花费最多时间的微批处理（或许还没有足够的时间到达其数据流的末端）。

例如，请考虑下图。在第一时间范围期间，调度程序在微批处理之间平均分配时间。微批处理 #2 使用分配给它的所有时间（如填充区域所示），而其他微批处理并未这样。在下一时间范围中，调度程序重新排列这些微批处理，使提前完成的微批处理首先进行。它还将更少的时间分配给运行时间较短的微批处理。假定这些微批处理再次提前完成，调度程序便能够将时间范围中的剩余时间分配给微批处理 #2。当调度程序运行时，这种优先级的转移将会继续进行。如果一个主题的流量激增，调度程序会为读取该主题的微批处理分配更多的时间作为补偿。

时间范围持续时间太短会发生什么

如果将调度程序的时间范围持续时间设置得太短，微批处理可能没有足够的时间来加载它们负责读取的数据流中的所有数据。在最坏的情况下，当在每一时间范围期间读取大容量主题时，微批处理可能会落后更多。如果不加以解决，这个问题可能会导致消息永远无法加载，因为在微批处理有机会读取它们之前，它们就已经在数据流中过期了。

在极端情况下，调度程序可能无法在每一时间范围期间中运行每一个微批处理。如果时间范围持续时间太短，以至于大部分时间都花在开销任务（如提交数据和准备运行微批处理）上，便会发生这个问题。每个微批处理为了从 Kafka 加载数据而运行的 COPY 语句的最短持续时间为 1 秒。再加上处理数据加载的开销。一般来说，如果时间范围持续时间短于 2 秒乘以调度程序中的微批处理数，那么一些微批处理可能会没有机会在每一时间范围中运行。

如果调度程序在一个时间范围期间运行每个微批处理超时，那么它在下一时间范围期间会通过优先安排前一时间范围中没有运行的微批处理来做出补偿。这个策略确保每个微批处理都有机会加载数据。但是，这并不能解决问题的根本原因。最好的解决方案是增加时间范围持续时间，为每个微批处理分配足够的时间来在每一时间范围期间加载数据。

时间范围持续时间太长会发生什么

长时间范围持续时间的一个缺点是增加了数据延迟。这个延迟是从 Kafka 发出数据到可在数据库中查询数据之间的时间。较长的时间范围持续时间意味着微批处理的每次执行之间有更多的时间。这意味着更新数据库中的数据之间的间隔时间更长。

这种延迟可能并不重要，具体取决于应用。在确定时间范围持续时间时，请考虑数据可能会延迟到整个时间范围持续时间是否将导致问题。

使用长时间范围持续时间时要考虑的另一个问题是，关闭调度程序所需的时间。只有在当前 COPY 语句完成之后，调度程序才会关闭。根据时间范围持续时间的长度，这个过程可能需要几分钟。

最短时间范围持续时间

为添加到调度程序的每个微批处理至少分配两秒钟。如果时间范围持续时间短于该下限，vkconfig 实用程序将会发出警告。在大多数情况下，您都希望时间范围持续时间更长。如果每个微批处理两秒钟，几乎没有时间来加载数据。

平衡时间范围持续时间要求

要确定部署的最佳时间范围持续时间，请考虑您对数据延迟的敏感程度。如果不是在对来自 Kafka 的数据流式传输执行时间敏感型查询，可以使用默认的 5 分钟甚至更长的时间范围持续时间。如果需要数据延迟更短，那么请考虑从 Kafka 读取的数据量。如果时间范围持续时间较短，那么大容量数据或者流量有明显峰值的数据可能会导致问题。

针对不同需求使用不同的调度程序

假定您要加载的流式传输数据来自少数您希望以低延迟查询的 Kafka 主题，以及其他具有大量数据但您可以承受更长时间延迟的主题。在这种情况下，选择“中间”时间范围持续时间可能无法满足任一需求。更好的解决方案是使用多个调度程序：创建两个调度程序，其中一个调度程序的时间范围持续时间较短，仅读取需要以低延迟查询的主题；另一个调度程序的时间范围持续时间较长，用于从大容量主题加载数据。

例如，假定您要通过 Kafka 将流式传输数据从物联网 (IOT) 传感器网络加载到 Vertica。您可以使用其中的大部分数据定期生成报告并更新仪表板显示。这两个用例对时间都不是特别敏感。但是，正在从中进行加载的三个主题确实包含时间敏感型数据（系统故障、入侵检测和连接中断），这些数据必须立即触发警报。

在这种情况下，可以创建两个调度程序，其中一个调度程序的时间范围持续时间为 5 分钟或更长，用于读取包含非关键数据的大多数主题；第二个调度程序的时间范围持续时间至少为 6 秒（但最好更长），用于仅加载来自三个时间敏感型主题的数据。希望这些主题中的数据量足够小，以至于短时间范围持续时间不会导致问题。