一文看懂数据云平台的“可观测性”技术实践

背景

这是一家大型制造集团。为监控及预测工厂设备运行情况,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 架构的流批一体技术。