背景
这是一家大型制造集团。为监控及预测工厂设备运行情况，IT部门在数据云平台DataSimba上按天执行数据作业，每24小时对工厂设备的日志数据进行分析，发现能对业务起到很好的辅助作用，效果不错。
“要不升级为每1个小时跑一次，会不会更好？”
客户萌生了这样的想法。然而，在预期获得更快、更及时的数据结果用于设备管理的同时，数据云平台的生产压力也骤增了23倍。
面对突增的压力，工程师们发现数据云平台反馈出了一些异常……
问题解析
【问题一】
原本按天调度的作业现改为小时调度，但目前不想扩充资源，所有作业真的能在单位调度周期（一小时）内跑完吗？性能有没有优化空间？
解：
针对这个问题，奇点云DataSimba工程师首先查看相关时间范围的 “作业最晚执行时长” ，发现在3:00-4:00、5:00-6:00，作业的最晚执行时长都超过了1小时（图1-1），确实存在小时作业跑不完的情况。
而通过图1-2发现，上述2个时间段，作业实例数量也远超均值（分别为5381、4477）。从而分析对应时间点的“作业实例数量”变多，导致“作业最晚执行时长”超过1小时。
对比业务调整前后的“作业实例平均运行时长”，发现作业平均运行时长从1分36秒（图2-1）变成了4分22秒（图2-2）左右。由此判断系统因为业务的变化产生了一些“压力”。
结合系统的调用流程分析，监控相关核心服务的“JVM Memory Pools”情况后发现：在对应实例高峰期时，负责文件的存储域出现了大量Young GC，且频繁伴随Full GC的情况（图3-1、3-2）。同时，对应接口耗时也从300ms上升到了30s。从而快速定位问题：在大量作业下发的场景，存储域的系统GC会导致 “作业平均运行时长”指标数值变大的情况。
奇点云工程师从客户环境需求出发，调整了存储域JVM的参数及年轻代和老年代的占比，最终将“作业平均运行时长”降回至1分30秒左右（图3-3），对应的“作业晚执行时长”也没有超过1小时的情况，也就是说作业均在调度周期内完成。
问题一指标解读：
- 作业实例数量：时间范围*内产生作业实例的数量。
- 作业最晚执行时长：一批任务应该在周期内执行完毕。作业最晚执行时长=一批作业中最晚执行完的任务完成时间点-该调度周期的起始时间点。例如，调度周期为每小时调度一次，发现1:00-2:00时间段内的一批作业中，最晚执行的作业在2:15完成，“作业最晚执行时长”则是1小时15分钟。说明作业在对应调度周期未执行完，需要调整。
- 作业实例平均运行时长：时间范围内的作业实例运行总时长/时间范围内实例总数量。
对于此类问题，往往通过查看指标变化趋势来分析排查。
*时间范围：“作业实例数量”、“作业最晚执行时长”、“作业实例平均运行时长”均可由DataSimba用户自行配置选择，例如1:35-5:32等。
【问题二】
似乎出现了一些作业长时间未运行，影响了整体业务的正常产出？
解：
DataSimba作业状态流转如图4所示，工程师通过分析“未运行”、“等待”、“运行中”三种状态的作业数量及“运行中超过一定阈值时间（本场景设定为30分钟）的作业数量”，即可判断目前调度系统是否正常，是否需要人为干预。
平台对此类作业定义了阶段阈值以便监控，如图5显示，客户环境“运行中超过30分钟”的作业数量是1，而同样时间范围内“作业平均运行时长”通常仅为1分钟左右（图3-3），工程师立即判断出运行中的作业出现了异常情况。
同时，在异常监控指标中，“互斥锁Exclusive (X）LOCK数量”数量也是1（图6）。经确认，“互斥锁Exclusive (X）LOCK表列表”就是当下“运行中超过30分钟”的job所引用的表，从而判断作业存在锁表的情况。在客户调整调度逻辑后，该问题得到解决，且再也没有复现过。
问题二指标解读：
DataSimba部署完成后，会根据系统资源规格配置作业的“调度并发数”。通过“等待资源”（的作业数）和“执行中”（的作业数）的指标，结合以下场景规则，即可判断出调度服务是否正常。
- 场景一：“等待资源”（的作业数）大于0，且“执行中”（的作业数）等于“调度并发数”，则证明目前调度正常。
- 场景二：“等待资源”（的作业数）大于0，且“执行中”（的作业数）长时间小于“调度并发数”，则证明调度资源目前的部分作业执行节点可能出现了下线的情况。
- 场景三：“等待资源”（的作业数）大于0，如果“执行中”（的作业数）等于0，则证明目前作业无法正常提交，调度服务异常。
- 场景四：“等待资源”（的作业数）一直增长，长时间没有降低趋势，并且长时间“运行中的作业数”的数量等于“调度并发数”，则证明当下调度能力无法支撑业务，需要联系运维结合目前集群资源调整作业调度并发数。
【问题三】
怀疑个别作业在平台中显示的运行时长，似乎大于作业本身在集群上真正运行时长。
解：
在检查“作业实例平均运行时长”指标时，奇点云工程师发现，部分作业“作业执行时长”远远大于“作业集群执行时长”，该现象在调度高峰期较为明显。
经排查，工程师发现是因为服务内部日志的写入效率产生瓶颈，导致系统调度时长变长，增加了作业执行时长。
因此工程师将服务日志的行写模式（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架构的流批一体技术。
