确定作业计划反模式
- 批量数据湖摄取
- 批量配置文件摄取
- 批次分段
- 批量目标激活
作业计划时间线视图可帮助您识别可能对数据管道性能和可靠性产生负面影响的常见配置问题。 这些反模式通常会导致作业失败、数据不一致或系统性能降低。 其中三种最常见的反模式通过界面中的警告指示器自动检测和显示。 通过尽早发现这些模式，您可以重新配置作业以在问题影响业务运营之前避免这些问题。
自动检测到的反模式 auto-detection
作业计划在相关摘要卡片上自动检测三个常见的反模式和表面警告指示器。 选择警告指示器以打开一个详细信息面板，其中包含问题的描述、建议的操作以及受影响数据集或目标的列表。
先决条件 prerequisites
在识别反模式之前，您应：
快速参考 anti-pattern-quick-reference
计划重叠 schedule-overlap-pattern
影响严重程度：高 | 主要问题：资源争用
要查找的内容：已计划同时或连续运行多个作业，特别是在资源密集型作业重叠时。
一个常见示例是批量摄取作业与计划分段作业同时运行。 这会造成资源争用，因为这两项操作都需要强大的处理能力和内存。
为什么有问题：
- 资源争用：当多个资源密集型作业同时运行时，它们会争夺系统资源（CPU、内存、I/O），导致所有作业运行速度变慢。
- 不可预测的性能：作业持续时间变得不一致，导致难以规划可靠的时间表。
- 级联延迟：如果作业所需时间超过预期，它们可能会延迟下游相关作业，从而在整个管道中产生连锁反应。
- 增加的失败风险：资源耗尽可能导致作业超时或完全失败。
如何修复它：
- 错开作业计划：确保按顺序运行资源密集型操作，而不是同时运行。
- 添加缓冲时间：在作业之间保留足够的间距以考虑处理变化。
- 查看依赖项：确定哪些作业必须完成，才能让其他作业安全启动。
当作业计划检测到分段运行时间距离计划的目标激活时间太近时，目标激活摘要卡片上将显示一个警告指示器。 选择警告指示器可打开一个面板，其中显示检测到的发生次数、计时冲突的描述、建议以及受影响的目标列表。
计划的作业密度 scheduled-density
影响严重程度：高 | 主要问题：管道瓶颈
要查找的内容：在同一小时内安排了多个批次的数据集过多，尤其是当这些批次紧密栈叠在一起并安排在接近关键处理时段（如分段开始时间）时。
此模式通常包括：
- 多个数据集，每个数据集每天运行多个批次
- 同一小时内集群化的ETL作业（数据湖摄取和配置文件摄取）
- 批量摄取安排在紧靠计划分段窗口之前或期间进行
为什么有问题：
- 管道瓶颈：当来自不同数据集的许多批次在短时间窗口内栈叠时，它们会产生处理瓶颈，可能会使摄取管道不堪重负。
- 配置文件可用性延迟：运行时间过于接近分段开始时间的配置文件摄取作业可能无法及时完成，从而导致受众评估不完整或过时。
- 无法预测的分段：如果分段开始时上游引入作业仍在运行，则可能会根据不完整的数据评估受众，从而导致受众成员身份不正确。
- 级联失败：密集栈叠计划中的单个延迟批次可能会造成多米诺效应，延迟所有后续批次和下游进程。
- 资源紧张：在处理过多并发摄取作业时，系统可能难以分配足够的资源，从而导致处理时间变慢或失败。
如何修复它：
- 合并批次：通过将多个小批次合并到每个数据集的更少、更大的批次中，降低批次频率。
- 平均分布：将摄取作业分散到一整天，而不是在特定的小时内形成群集。
- 添加缓冲时间：确保在配置文件摄取完成和分段开始之间至少有1-2小时的缓冲。
- 审查要求：评估所有数据集是否确实需要多个每日批次。 许多用例使用的频繁更新较少。
当作业计划检测到配置文件摄取作业运行时间太接近计划的分段运行时，分段摘要卡片上将显示一个警告指示器。 选择警告指示器可打开一个显示检测到的发生次数的面板、时间冲突的描述、建议以及受影响数据集的表。
配置文件摄取每日限制 profile-ingestion-daily-limit
影响严重程度：高 | 主要问题：系统护栏
要查找的内容：当每日配置文件摄取运行接近或超过90运行的系统护栏时，配置文件摄取摘要卡上的警告指示器。 选择警告指示器，以查看一个条形图，其中显示所选时段中每一天的每日运行计数。
此图表使用颜色编码的条形图来指示计数相对于限制的下落：
- 红色条（90个或更多运行）：超过每日限制。 处理效率低下可能会影响所有启用配置文件的数据集。
- 橙色条（72到89次运行）：即将达到每日限制。
- 绿色条（低于72次运行）：在可接受的范围内。
为什么有问题：
- 处理效率低下：如果每天超过90次配置文件摄取运行，则会产生处理开销，这可能会影响所有启用配置文件的数据集。
- 资源争用：高总运行数可能会延迟下游分段和激活作业。
- 数据停滞：当配置文件处理持续运行时，单个批次可能需要更长的时间才能完成，这会延迟分段的数据可用性。
如何修复它：
- 降低每个数据集的批次频率：合并批次，以便每天触发的配置文件摄取运行减少。 有关详细指导，请参阅每个数据集过多的批次。
- 审核所有摄取计划：审查所有计划进行配置文件摄取的数据集，并识别那些批次频率不必要的高数据集。
每个数据集的批次过多 excessive-batches-per-dataset
影响严重程度： Medium | 主要问题：处理效率低下
要查找的内容：单个数据集在一天中安排了过多的单个批处理作业，从而在时间线上产生了一个较长的垂直作业栈栈。
此模式涉及单个数据集，其中包含以频繁间隔安排的许多单独的批量摄取作业，有时每天安排几十个批次。
为什么有问题：
- 处理效率低下：每个批处理作业都有开销成本（初始化、验证、元数据更新）。 处理许多小批次比处理更少的大批次效率要低得多。
- 故障表面增加：作业越多，故障机会就越大。 每个失败的批次都需要进行调查和可能的重新处理。
- 不必要的系统负载：频繁的小批量使系统始终忙于处理开销任务而不是实际的数据处理，从而降低了总体吞吐量。
- 延迟的数据可用性：矛盾的是，与合并的批次相比，运行许多小批次可能会延迟下游进程可用的数据。
- 难度检查：跟踪每个数据集数十个单独批处理作业的成功和性能变得操作复杂且耗时。
- 配置文件处理lag：每个配置文件摄取批处理都会触发配置文件处理。 频繁的小批量可能会导致配置文件处理几乎连续运行，从而阻止高效的批量优化。
如何修复它：
- 降低批次频率：对于大多数用例，每个数据集合并到每天较少的批次。
- 增加批次大小：在触发引入之前累积更多数据，而不是立即引入。
- 与业务需求保持一致：验证是否确实需要每小时更新，或者每天/每天两次更新是否足够。
- 实时使用流式传输：切换到真正的实时需求的流式摄取，而不是使用频繁的批次进行模拟。
- 监视每日运行总数：如果多个数据集具有高批次频率，则合并的总数可能会超过系统护栏。 请参阅配置文件摄取每日限制。
后续步骤 next-steps
在识别作业计划中的反模式后：