📚 课程目录第3章监控体系架构设计

3. 监控体系架构设计：分层架构与技术选型

元数据质量监控体系，说白了就是一套从数据采集到最终展示的流水线。我见过不少团队，上来就写代码，结果做到一半发现采集层扛不住压力，或者存储层查个数据要等半天。嗯，这就是架构设计没想清楚。

我个人习惯，先把整个体系拆成四个逻辑层：采集层、存储层、计算层、应用层。每一层各司其职，层与层之间通过标准接口通信。这样哪怕以后要换某个组件，也不会牵一发动全身。

核心原则：分层不是目的，解耦才是。每一层只关心自己的事，不要越俎代庖。

先看一张整体架构图，后面我们再逐层拆解。

这张图我画了很多遍。你会发现，数据是从下往上流的——采集层把原始元数据捞上来，存到存储层，计算层再跑规则做分析，最后应用层展示结果。反过来，配置和指令是从上往下推的。

采集层是整个体系的起点。数据进不来，后面全是空谈。我在项目中遇到过最头疼的问题，就是采集器把源库拖垮了。你想想看，元数据监控本来是为了保障质量，结果反而成了生产事故的导火索。

采集层要干三件事：

我的建议：采集层一定要做「采集链路监控」。我曾经因为一个采集任务挂了三天没发现，导致质量报告全是空的。后来我强制要求：每个采集任务必须上报心跳和延迟，超过阈值立刻告警。

技术选型上，我一般这样配：

避坑指南：我曾经用全量采集的方式每天扫一次所有表，结果某个大表有 10 万个分区，采集任务跑了 6 个小时还没结束。后来改成增量采集 + 分片并行，才把时间压到 15 分钟以内。

存储层要存四类数据：

你可能会问，为什么不用一个库全存了？我试过，结果很惨。元数据是结构化的，质量结果需要快速写入，时序数据要支持聚合查询。混在一起，查询性能一塌糊涂。

我的推荐方案：

关键点：存储层一定要做数据生命周期管理。元数据快照保留 30 天，质量结果保留 90 天，时序数据可以保留更久但需要降采样。不然磁盘会爆，我吃过这个亏。

计算层是大脑。它从存储层读取数据，跑质量规则，产出评分和异常。

计算层包含几个核心模块：

技术选型上，我建议：

个人经验：规则引擎不要一开始就搞得太复杂。我见过有人花三个月写了一个通用规则引擎，结果上线后发现 80% 的规则其实就是简单的 SQL 查询。先跑起来，再慢慢迭代。

应用层是面向用户的。不管底层多牛，用户看不到就等于零。

应用层主要提供：

技术选型上，我倾向：

注意：应用层最容易犯的错是「大而全」。我见过一个团队把看板做了 50 个图表，结果用户根本不知道看哪个。后来砍到 8 个核心指标，反而好评如潮。少即是多。

说了这么多技术，最后聊聊选型原则。我踩过太多坑了，总结成四条：

总结一句话：架构设计没有银弹。分层是为了控制复杂度，选型是为了匹配现实。把每一层该做的事做好，层与层之间解耦，体系自然就稳了。