本文介绍Scheduled SQL功能的常见问题。

如何保证SQL分析的数据准确性?

数据延迟写入或实例的调度配置不恰当时,可能发生数据分析不准确问题。
  • 数据写入存在延迟。例如数据写入日志服务延迟了5分钟,实例执行时间为12:03:00,SQL时间窗口为相对一分钟,即[12:02:00,12:03:00),则查询不到最新的数据。
  • 数据写入日志服务到能够被查询到,这期间存在延时(一般少于3秒)。即使延时很低,也存在数据漏查的风险。例如实例执行时间为12:03:30,SQL时间窗口为相对一分钟,即[12:02:30,12:03:30),对于12:03:29秒写入的日志,不能保证在12:03:30肯定能够查询到。
  • 同一分钟内包含不同时间的日志时,由于日志索引的构建,时间较迟的日志的索引可能落盘到较早的时间点。例如实例执行时间为12:03:30,SQL时间窗口为相对一分钟,即[12:02:30,12:03:30)。如果在12:02:50秒写入日志,这些日志时间为12:02:20、12:02:50等,那么这些日志的索引可能落盘在12:02:20这个时间点,导致在[12:02:30,12:03:30)期间查询不到日志。
使用Scheduled SQL时,建议根据业务情况,同时兼顾数据实时性和准确性。
  • 考虑数据上传日志服务存在延迟情况,您可以结合数据采集延迟以及业务能够容忍的最大结果可见延迟,设置执行延迟SQL时间窗口(结束时间往前一点),避免实例执行时SQL时间窗口内的数据未全部到达。
  • 建议SQL时间窗口按分钟对齐(例如整分钟、整小时),以保证上传局部乱序数据时的数据准确度。

如何防止SQL分析执行失败?

  • 确保输入正确的SQL语法。
  • 确保已为待分析的字段创建正确的索引。例如查询和分析语句为* | select uid,则您需要为uid字段开启统计功能。更多信息,请参见配置索引
  • 确保已配置正确的权限。例如执行SQL分析的权限,读取日志库数据的权限。
  • 确保已提供足够的计算资源。例如您使用的是免费资源池,存在Project级别的SQL分析并发执行限制。更多信息,请参见查询与分析的使用限制
  • 避免使用逻辑过于复杂的SQL语句以及SQL时间窗口设置过大,否则将导致计算超时(服务端超时时间为10分钟)。

通过Scheduled SQL作业写入数据到目标库时,是否进行索引检查?

日志服务将Scheduled SQL的计算结果写入目标库时,不做索引检查。如果目标库未配置索引,则您无法进行SQL分析,但不影响日志消费和查询操作。

建议您在创建Scheduled SQL作业前,完成目标库的索引配置。如果未提前配置索引,可通过重建索引功能为历史数据配置索引。具体操作,请参见重建索引

某个实例执行超时,是否会影响后续的执行计划?

某个实例执行超时不会影响后续的执行计划的生成。新实例的调度时间是延续上一个实例的调度时间,但是后续实例的创建时间和执行时间会延迟,并且需要花费时间来追赶原定的执行计划,逐步缩减结果数据的延迟。

一般来说,追赶固定的数据量时,调度周期越大,追赶速度越快。例如:
  • 追赶一天的数据量,调度周期为1分钟时,需要执行1440个实例,每个实例运行20秒。
  • 追赶一天的数据量,调度周期为1小时时,需要执行24个实例,每个实例运行2分钟。

    日志服务提供服务分布式查询和分析能力,在面对更多数据时将使用更多的计算资源。

写入到目标库的数据如何溯源?

通过Scheduled SQL写入到目标库的数据,默认被添加如下__tag__字段,用于数据溯源。
  • __tag__:__instance_id__:2b06486746f0cb38-5bffe67493825-1e2606a:作业实例的ID
  • __tag__:__job__:from_now:作业名称
  • __tag__:__project__:ali-sls-etl-staging:作业所属于的Project
  • __tag__:__schedule_time__:1618474200:作业的调度时间,Unix时间戳,单位:秒。
  • __tag__:__trigger_time__:1618474259:作业的执行时间,Unix时间戳,单位:秒。