背景

这是一家大型制造集团。为监控及预测工厂设备运行情况，IT 部门在数据云平台 DataSimba 上按天执行数据作业，每 24 小时对工厂设备的日志数据进行分析，发现能对业务起到很好的辅助作用，效果不错。

“要不升级为每 1 个小时跑一次，会不会更好？”

客户萌生了这样的想法。然而，在预期获得更快、更及时的数据结果用于设备管理的同时，数据云平台的生产压力也骤增了 23 倍。

面对突增的压力，工程师们发现数据云平台反馈出了一些异常……

问题解析

【问题一】

原本按天调度的作业现改为小时调度，但目前不想扩充资源，所有作业真的能在单位调度周期（一小时）内跑完吗？性能有没有优化空间？

解：

针对这个问题，奇点云 DataSimba 工程师首先查看相关时间范围的“作业最晚执行时长”，发现在 3:00-4:00、5:00-6:00，作业的最晚执行时长都超过了 1 小时（图 1-1），确实存在小时作业跑不完的情况。

而通过图 1-2 发现，上述 2 个时间段，作业实例数量也远超均值（分别为 5381、4477）。从而分析对应时间点的“作业实例数量”变多，导致“作业最晚执行时长”超过 1 小时。

图1-1 作业最晚执行时长

图1-2 作业实例情况

对比业务调整前后的“作业实例平均运行时长”，发现作业平均运行时长从 1 分 36 秒（图 2-1）变成了 4 分 22 秒（图 2-2）左右。由此判断系统因为业务的变化产生了一些“压力”。

图2-1 业务调整前，作业实例平均运行时长

图2-2 业务调整后，作业实例平均运行时长

结合系统的调用流程分析，监控相关核心服务的“JVM Memory Pools”情况后发现：在对应实例高峰期时，负责文件的存储域出现了大量 Young GC，且频繁伴随 Full GC 的情况（图 3-1、3-2）。同时，对应接口耗时也从 300ms 上升到了 30s。从而快速定位问题：在大量作业下发的场景，存储域的系统 GC 会导致 “作业平均运行时长”指标数值变大的情况。

图3-1、图3-2 JVM：Young GC 和Full GC

 奇点云工程师从客户环境需求出发，调整了存储域 JVM 的参数及年轻代和老年代的占比，最终将“作业平均运行时长”降回至 1 分 30 秒左右（图 3-3），对应的“作业晚执行时长”也没有超过 1 小时的情况，也就是说作业均在调度周期内完成。

图3-3 优化后的作业平均运行时长

问题一指标解读：

• 作业实例数量：时间范围*内产生作业实例的数量。

• 作业最晚执行时长：一批任务应该在周期内执行完毕。作业最晚执行时长=一批作业中最晚执行完的任务完成时间点-该调度周期的起始时间点。例如，调度周期为每小时调度一次，发现 1:00-2:00 时间段内的一批作业中，最晚执行的作业在 2:15 完成，“作业最晚执行时长”则是 1 小时 15 分钟。说明作业在对应调度周期未执行完，需要调整。

• 作业实例平均运行时长：时间范围内的作业实例运行总时长/时间范围内实例总数量。

对于此类问题，往往通过查看指标变化趋势来分析排查。

*时间范围：“作业实例数量”、“作业最晚执行时长”、“作业实例平均运行时长”均可由 DataSimba 用户自行配置选择，例如 1:35-5:32 等。

【问题二】

似乎出现了一些作业长时间未运行，影响了整体业务的正常产出？

解：

DataSimba 作业状态流转如图 4 所示，工程师通过分析“未运行”、“等待”、“运行中”三种状态的作业数量及“运行中超过一定阈值时间（本场景设定为 30 分钟）的作业数量”，即可判断目前调度系统是否正常，是否需要人为干预。

图4 DataSimba作业状态流转图

 平台对此类作业定义了阶段阈值以便监控，如图 5 显示，客户环境“运行中超过 30 分钟”的作业数量是 1，而同样时间范围内“作业平均运行时长”通常仅为 1 分钟左右（图 3-3），工程师立即判断出运行中的作业出现了异常情况。

图5 作业运行中阶段阈值详情

 同时，在异常监控指标中，“互斥锁 Exclusive (X）LOCK 数量”数量也是 1（图 6）。经确认，“互斥锁 Exclusive (X）LOCK 表列表”就是当下“运行中超过 30 分钟”的 job 所引用的表，从而判断作业存在锁表的情况。在客户调整调度逻辑后，该问题得到解决，且再也没有复现过。

图6 互斥锁Exclusive (X）LOCK数量

问题二指标解读：

DataSimba 部署完成后，会根据系统资源规格配置作业的“调度并发数”。通过“等待资源”（的作业数）和“执行中”（的作业数）的指标，结合以下场景规则，即可判断出调度服务是否正常。

• 场景一：“等待资源”（的作业数）大于 0，且“执行中”（的作业数）等于“调度并发数”，则证明目前调度正常。

• 场景二：“等待资源”（的作业数）大于 0，且“执行中”（的作业数）长时间小于“调度并发数”，则证明调度资源目前的部分作业执行节点可能出现了下线的情况。

• 场景三：“等待资源”（的作业数）大于 0，如果“执行中”（的作业数）等于 0，则证明目前作业无法正常提交，调度服务异常。

• 场景四：“等待资源”（的作业数）一直增长，长时间没有降低趋势，并且长时间“运行中的作业数”的数量等于“调度并发数”，则证明当下调度能力无法支撑业务，需要联系运维结合目前集群资源调整作业调度并发数。

图7 作业运行状态情况

 【问题三】

怀疑个别作业在平台中显示的运行时长，似乎大于作业本身在集群上真正运行时长。

解：

在检查“作业实例平均运行时长”指标时，奇点云工程师发现，部分作业“作业执行时长”远远大于“作业集群执行时长”，该现象在调度高峰期较为明显。

经排查，工程师发现是因为服务内部日志的写入效率产生瓶颈，导致系统调度时长变长，增加了作业执行时长。

因此工程师将服务日志的行写模式（Line writing）调整为缓冲块写入（Buffer block）模式，最终“作业执行时长”接近“作业集群执行时长”，符合预期。目前 DataSimba 4.5 之后的版本也均采用了缓冲块写入。

问题三指标解读：

• 作业集群执行时长：作业真正在对应计算引擎上执行的时间。

• 系统调度时长：作业在调度系统中流转时长，比如：作业从入队列到出队列的时间，同步作业状态的时间，处理作业日志的时间等。

• 作业执行时长： 等于“作业集群执行时长”加“系统调度时长”。假设作业实际运行耗时指标为 2 分 15 秒，集群实际执行耗时为 2 分 03 秒，也就是“系统调度时长”为 12 秒，这 12 秒是调度系统在处理作业流转所花的时间。

“可观测”本质上是数据云平台的数据自应用

企业级数据云平台（云数仓/数据中台等同类数据基础设施）往往非常复杂，所涉及到的作业、任务、资源众多，在平台上工作的工程师也通常来自各部门，有各自的操作习惯和使用需求。除了本篇案例所介绍生产压力突增的情况，也常出现因业务逻辑改变，需要调整关联关系却出现问题等情况。

“为啥又崩了？”

“不可能，我测试的时候没问题啊。”

当企业不再只用数据做单点创新尝试，而让数据深入业务、影响业务，这样的回答在企业场景中就多少有些不负责任了。

企业级的数据云平台产品，不仅要有好用的功能，也要在客户环境中真正“扛造”，能给用户明晰的反馈和指引，以便及时定位问题、发现潜在风险，从而帮助企业的工程师们实现对平台的自运维、自交付。

这就是“可观测性”在数据云平台要承担的重任：

通过关键指标，精准呈现平台的硬件、进程、业务等整体状态，提升平台内部状态的“能见度”，从而提升企业用户“自交付、自运维”的易用性，降低平台的使用及运维门槛，提升发现、定位并解决问题的效率。

• 啥是可观测性？

Gartner 把应用可观测性（Applied Observability）列入“2023 年十大战略技术趋势”，并做出如下解释：在任何相关方采取任何类型的行动时，都会产生包含了数字化特征的可观测数据，如日志、痕迹、API 调用、停留时间、下载和文件传输等。应用可观测性以一种高度统筹和整合的方式，将这些可观测的特征数据进行反馈，创造出一个决策循环，从而提高组织决策的有效性。

说人话，“可观测性”本质是对系统产出的日志、数据埋点、系统指标、链路追踪等核心数据的治理，通过“场景+数据+指标”，构建并不断完善内部系统的“指标体系”，来辅助保障稳定性。

系统在构建其“可观测性”时，通常依循以下路径：盘点事前、事中、事后各场景下的常见问题，分析本质，明确问题场景的对应指标，收集并清洗相应数据，最终通过可视化的方式对外呈现。

• “可观测”本质上是数据产品

在奇点云看来，“可观测”本质上是一套数据产品（而非定时脚本），它应当用数据来实现对平台内部情况的观测，用数据辅助用户科学地了解平台情况、指导行动。在经过一定时间的沉淀后，可观测相关数据还可用于企业训练智能算法，实现平台的智能运维。

在数据云平台 DataSimba，奇点云形成了包括血缘治理模型、问题排错模型、运维巡检模型等在内的多种数据模型产品，来应对不同场景的可观测需求。

具体而言，DataSimba 会收集、存储平台自身各子系统的数据，例如数据服务请求日志数据、各服务器 Metrics 数据和 DataSimba 内核调用链路 Trace 数据等，将这些数据整理成结构化的数据模型，便于用户调用模型完成高效的查询、分析。

同时结合智能算法，帮助用户更快发现并定位系统中的异常根因。例如，基于时间序列的异常检测算法，能自动捕获在运维场景中的典型异常，包括方差变化、均值变化、尖峰深谷、断崖式跌落、趋势增长等等。

谈及可观测性相关数据模型的由来，奇点云合伙人、CTO 地雷介绍：“我们参考了海内外数据生产的经典方法论，结合奇点云工程师们多年服务沉淀出的知识框架，总结提炼出了这些数据模型及其对应的关键指标。”

以服务稳定性模型为例，服务基础容器环境、服务可用性、响应时间、错误率是描述整体服务健康状态的关键指标。每组指标可再向下拆解，由一系列原子指标构成。

在本篇案例的高并发调度场景下，基于“服务稳定性模型”，奇点云工程师们着重监测了相关基础容器环境的状态、接口响应时间等指标。譬如针对“延迟”，具体指标包括“当前等待作业数量”、“等待作业超过阈值分钟的数量”；针对“吞吐量”（在一定时间内处理的作业数），具体指标则包括“时间范围内的平均运行时长”、“最晚执行时长”、“范围时间内各个运行趋势”等。从而快速定位根因，及时排错处理，提高调度性能。

资深技术专家牧然补充道：“监控系统对主系统的扰动性要足够小。通常来说，监控框架会采集底层日志，再聚合数据、形成图表，这些环节都会有资源消耗。为不影响主系统，监控系统的资源消耗应在可控范围内。DataSimba 可观测性数据模型中很多核心指标主要来自元数据，基本无需另外采集，对主系统造成的压力就更小。”

目前，奇点云数据云平台 DataSimba 专业版、旗舰版、红旗版均提供元仓（元数据数仓）功能，包含平台可观测性的多种数据模型。企业可以直接调用这些数据资产，来完成数据云平台的异常识别、预警提示、自动化运维巡检等高阶管理。

One more thing:

回到开头所述，这家大型制造集团的情况，本质需求是获得更快更及时的数据用于业务。出于历史原因，企业采用了调整调度周期粒度的方式——分钟级、小时级地频繁跑 ODS、DW、ADS 层的数据，同时也导致出现大量额外且重复的计算成本，对系统压力大，灵活性也易受限制。如果从头开始满足此类需求，则更推荐采取 Lambda 或 Kappa 架构的流批一体技术。