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

最新推荐文章于 2025-09-13 03:50:03 发布

原创

最新推荐文章于 2025-09-13 03:50:03 发布 · 995 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#可观测性 #数据中台 #奇点云

文章讲述了大型制造集团在将数据作业调度从每天一次升级到每小时一次后，面临数据云平台DataSimba性能压力增加的问题。工程师通过分析作业实例数量、执行时长等关键指标，发现了存储域的GC问题和锁表情况，以及日志写入效率瓶颈。通过优化JVM参数、调整日志写入模式和监控系统，成功降低了作业运行时长并提升了平台的可观测性，确保了系统的稳定性和自运维能力。

背景

这是一家大型制造集团。为监控及预测工厂设备运行情况，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会导致 “作业平均运行时长”指标数值变大的情况。<