一、背景信息

在大数据平台中，任务调度、依赖管理、数据产出质量、幂等处理都是保障业务稳定可靠的关键。DataLeap 提供了任务调度依赖、自依赖、偏移量、就近依赖等机制。在产品中可配置不同周期任务（分钟、小时、天、周、月）之间的依赖关系，满足复杂场景下数据开发与调度的场景。下面将基于数据开发与调度配置过程中一些典型场景进行总结。

二、任务调度与依赖设置最佳实践

在 DataLeap 中，您可对不同的任务配置上下游依赖关系，完成数据血缘的构建以及调度，确保数据质量，详细配置方式可参考：任务调度依赖。

2.1 明确任务周期与业务绑定

• 每个任务应清晰定义其调度周期（小时、日等）、定时时间、业务时间（如 ${DATE}／${HOUR}）等。周期任务会按调度类型生成对应数量的“周期实例”。

  变量	含义	格式	示例
  ${DATE}	获取业务时间日期	yyyy-MM-dd	天任务：2019/01/02 8点执行，${DATE} =2019-01-01 小时任务：2019/01/02 8点执行，${DATE} =2019-01-02
  ${date}	获取业务时间日期	yyyyMMdd	天任务：2019/01/02 8点执行，${date} =20190101 小时任务：2019/01/02 8点执行，${date} =20190102
  ${day}	获取业务时间日期	dd	天任务：2019/01/02 8点执行，${day} =01 小时任务：2019/01/02 8点执行，${day} =02
  ${HOUR}	获取业务时间整点	h（整数）	天任务：2019/01/02 8点执行，${HOUR} =0 小时任务：2019/01/02 8点执行，${HOUR} =7
  ${hour}	获取业务时间整点	hh	天任务：2019/01/02 8点执行，${hour} =00 小时任务：2019/01/02 8点执行，${hour} =07
  ${MINUTE}	获取业务时间整分钟	m（整数）	天任务：2019/01/02 08:10点执行，${MINUTE} =0 小时任务：2019/01/02 08:10点执行，${MINUTE} =0 5分钟任务：2019/01/02 08:10点执行，${MINUTE} =5 10分钟任务：2019/01/02 08:10点执行，${MINUTE} =10
  ${minute}	获取业务时间整分钟	mm	天任务：2019/01/02 08:10点执行，${minute} =00 小时任务：2019/01/02 08:10点执行，${minute} =00 5分钟任务：2019/01/02 08:10点执行，${minute} =05 10分钟任务：2019/01/02 08:10点执行，${minute} =10
  ${month}	获取业务时间月份	MM	天任务：2019/01/02 8点执行，${month} =01 小时任务：2019/01/02 8点执行，${month} =01
  ${year}	获取业务时间年份	yyyy	天任务：2019/01/02 8点执行，${year} =2019 小时任务：2019/01/02 8点执行，${year} =2019
  ${timestamp}	获取业务时间时间戳	XXXXXX...（整数）	天任务：2019/01/02 8点执行，${timestamp} =1546272000 小时任务：2019/01/02 8点执行，${timestamp} =1546383600
  ${last_DATE}	获取业务时间所处月份的最后一天	yyyy-MM-dd	天任务：2019/01/02 8点执行，${last_DATE} =2019-01-31 小时任务：2019/01/02 8点执行，${last_DATE} =2019-01-31
  ${last_date}	获取业务时间所处月份的最后一天	yyyyMMdd	天任务：2019/01/02 8点执行，${last_date-1} =20181231 小时任务：2019/01/02 8点执行，${last_date-2} =20181130
  ${last_day}	获取业务时间所处月份的最后一天	dd	天任务：2019/01/02 8点执行，${last_day-1} =31 小时任务：2019/01/02 8点执行，${last_day-2} =30
  ${DTF-xxxx}	自定义时间格式	xxxx	天任务：2019/01/02 8点执行，${DTF-ddMMyy} =010119 小时任务：2019/01/02 8点执行，${DTF-ddMMyy} =020119

  说明

  基本运算法则：往前或者往后n个单位时间

  • ${DATE-n} 获取业务时间往前-n天的日期
  • ${hour+n} 获取业务时间整点往后+n小时的整点

  高级运算法则：${var+x+ym-zd+ph+qi}，其中var代表时间变量，m代表月，d代表天，h代表小时，i代表分钟

  • 例如业务时间=2019-01-01 00:00:00，${date+1+2m}=20190302
  • 例如业务时间=2019-01-01 00:00:00，${hour+3-1h}=02

• 建议在任务代码中使用调度参数（如 ${DATE}／${HOUR}）来做分区筛选、路径拼接等，从而保证任务对业务时间的聚焦与可追溯性。

2.2 配置合理的调度依赖

• 强血缘依赖：如果下游任务取数或加工需要上游任务产出的表／分区数据，那么在调度依赖中应将该上游任务设置为前置，避免任务执行时间不符合预期。
• 选择依赖方式：同周期 vs 跨周期（自依赖）
  • 同周期：下游任务依赖于“当前周期”中上游任务的实例；
  • 跨周期（或自依赖）：下游任务依赖上一个周期或上一个版本的上游任务实例。任务自依赖仅支持跨周期自依赖设置，若任务需要依赖自己上一周期的数据产出，例如当天任务的执行，依赖当前任务昨天的执行结果，您可选择跨周期自依赖设置为是。
    
• 就近依赖原则：在上下游任务周期不一致时，可采用“就近依赖”方式（下游实例依赖与其定时时间最接近、且早于或等于自己的上游实例）。详细内容可参考：就近依赖
• 实例数不一致时的依赖挂载：如上游每天 1 次，小时任务每天 24 次，则默认下游会等待上游天实例完成后并发执行 24 次。若不希望并发，则需要下游任务开启“自依赖”。

2.3 小时级任务 + 自依赖原则

小时级任务，即任务实例生成按小时级周期生成，在上游数据就绪后，即会发起调度执行，小时级任务可以配置周期型上游任务依赖。

• 推荐操作：
  对下游小时任务开启“自依赖”（也可称“本节点跨周期依赖”），意味着每一个小时实例依赖上一个小时实例成功（除了首小时可能还依赖天任务或上游其他任务）。这样就变成串行或半串行，而非并发，从而降低资源冲突、避免多个小时实例同时跑。
  
  在 DataLeap 中，你应查找任务调度属性中“跨周期自依赖/自依赖”开关，并设置“最早回溯时间”（最早回溯时间用于指定从哪一个周期开始不强检上一个周期）。

• 总结：
  因此，对小时任务建议配置如下：

  • 定时时间明确（如每小时 xx 分）
  • 依赖上游所需任务（天维度或小时维度）
  • 自依赖开启：依赖自己上一周期
  • 设置“最早回溯时间”为合理值，以防过早依赖阻塞。
    优势说明：可控制实例启动节奏、减少并发冲突、确保数据依赖顺序性。

• 场景说明：

  场景	【推荐】小时任务设置自依赖	小时任务未设置自依赖
  说明	仅首个生成的小时周期实例依赖上游天任务，其余小时周期实例，依赖自己上一个周期的小时实例。 天任务及上一周期的小时实例执行完成后，当前周期的小时实例才启动调度。此时，即使定时运行时间已到，小时周期实例也不会并发执行。	当配置的是小时任务依赖天任务时，下游小时任务当天生成的所有周期实例依赖上游天任务。待天任务执行完成后，下游所有小时周期实例才启动执行。此时，到达定时运行时间的小时周期实例会并发执行，并且下游小时任务的所有周期实例在执行过程中相互不影响，调度关系如下：
  调度逻辑

2.4 避免多个实例同时调度 / 并发冲突控制

• 控制并发：除了自依赖机制，还可以在调度配置中控制“最大并发数”、“公共资源组”、“独享资源组”等，避免一个窗口触发大量任务。
• 资源隔离：建议将小时级任务与其它周期任务放在不同资源组、不同队列，以防抢资源。DataLeap 中也有队列管理、资源组管理的功能。详见队列管理
• 重试机制与超时控制：任务如果可能被阻塞或重试，应配置合理的重跑次数、间隔、超时值，避免阻塞链条拉长。
• 数据回溯策略：在小时级任务中若某小时未跑或失败，应提前定义回溯策略（如指定补跑业务时间、跳过失败小时等），避免影响后续小时或天任务。

三、小时级任务数据处理最佳实践

在数据开发中，小时级任务由于调度频率高，可能导致并发调度或任务重跑的情况，保证数据处理逻辑幂等尤为关键（“幂等”即任务重复运行不会导致数据错误或重复累加），建议进行以下操作。

3.1 强制使用覆盖式操作而非累加式

• 建议在表分区设计上按小时（如 dt = yyyy-mm-dd, hour = hh）或更细粒度分区。小时作业写入自己的小时分区，并用覆盖写入，从而满足幂等。
• 针对增量更新场景，如果不能覆盖完全，也应采用“先 Delete/Truncate分区 + Insert”或“合并删除逻辑”方式，以保证在作业重跑时不会产生重复。
• 在 SQL 代码或 Spark 等框架中，建议明确写出分区过滤逻辑（如 WHERE dt = '${date}' AND hour = '${hour}'）避免不小心影响其他小时分区。

3.2 任务状态记录与幂等保护

• 在任务入口、任务代码逻辑中建议记录运行状态（如业务时间、小时、开始时间、结束时间、影响行数、异常信息）至统一运维表或元数据表，以便排查、重跑。
• 当任务重新触发时，应检测“该小时分区数据是否已写入并且状态为成功”——若已成功，可选择跳过或重跑并覆盖。

3.3 分区管理与表设计

• 当任务覆盖写入小时分区时，建议设计合理的分区结构，如 dt, hour、甚至 minute。在 StarRocks、ByteHouse、Hudi、Iceberg 等湖仓系统中，良好的分区/排序策略对写入、查询效率、重跑效率都尤为重要。
• 在表建模阶段，应为小时任务结果表预留合适的主键／唯一键（如业务主键 + dt + hour）以防止重复插入。
• 建议保留近期历史小时数据（例如保留过去 24 小时或 7×24 小时）以便即时修复或回溯。对于更长期的数据，可设计按天、按月合并任务，再覆盖或归档。

3.4 任务失败与重跑机制

• 任务失败时，要保证补跑逻辑也遵从幂等原则：补跑的作业也采用覆盖、或者先清旧分区再写新分区。
• 对于小时级任务，如果一个小时失败，应及早触发补跑任务，避免拖延到日任务或汇总任务。
• 在延迟触发或资源不足导致任务延后启动时，应及时对该类任务进行告警配置以及进行补数重跑，避免影响下游任务的产出。

四、任务运维、监控与血缘治理

4.1 血缘关系与依赖检查

• 在调度界面中可利用“依赖预览”功能来提前验证配置是否合理。比如在 DataLeap 中“依赖预览”可查看按照当前设置、某个业务时间下的实例依赖关系。
  
• 血缘关系有助于快速定位某小时作业失败所影响的下游任务，如果需要分析任务／表级血缘依赖，目前数据地图已经支持小时任务表到天任务表的血缘构建，可以前往 数据地图表详情查看 > 血缘关系界面查看。
  

4.2 SLA、告警、基线监控

• 针对核心任务，建议前往任务运维页面建立小时任务的 SLA 指标（如每小时是否正常完成、多少分钟内完成、是否超时）。若小时级任务延迟或失败，可及时触发报警，以免影响后续小时或日级任务。
• 对于幂等性破坏、重复数据、覆盖失败等异常情况，也应触发监控。
• 在运维系统中设定“当某小时失败或重跑次数超过 N 次”时人工介入。

监控操作详见：任务运维。