📚 课程目录第1章实时数仓运维全景概览

1. 实时数仓运维全景概览

大家好，我是老张。做实时数仓运维这些年，踩过的坑比吃过的盐还多。今天咱们先聊聊全景——你得知道实时数仓是怎么演变成今天这个样子的，运维到底难在哪，以及监控体系该怎么搭才不白费力气。

说白了，实时数仓不是一天建成的。从离线批处理到准实时，再到真正的流式处理，架构在变，运维的麻烦也在变。我刚开始带团队那会儿，大家觉得实时数仓不就是把批处理跑快一点嘛？结果呢？数据延迟、状态不一致、任务OOM……问题一个接一个。

核心观点：实时数仓运维的本质，是在「数据正确性」和「系统稳定性」之间找平衡。监控不是为了看指标，而是为了在出问题前发现苗头。

先画张图，帮你快速建立整体认知。这是我个人习惯——看架构先看全貌，再抠细节。

这张图我画了好几次才满意。你看，从左到右，架构在变简单，但运维的挑战反而更隐蔽了。

做实时数仓运维，跟离线完全是两码事。离线任务跑慢了，最多明天出报表晚一点。实时任务出问题，业务方五分钟内就找上门了。

我总结了一下，主要挑战集中在四个方面：

挑战维度	具体表现	我踩过的坑
数据一致性	实时链路中数据丢失、重复、乱序	曾经因为Kafka分区重分配，导致某大促活动数据重复计算了3小时
状态管理	Flink状态后端膨胀、Checkpoint失败	有一次状态大小飙到200GB，Checkpoint超时导致任务连续重启
资源隔离	实时任务与离线任务争抢资源	YARN队列没配好，实时任务被离线任务挤到OOM
延迟敏感	端到端延迟要求秒级甚至毫秒级	某风控场景要求延迟<500ms，Kafka消费积压直接触发报警

⚠️ 特别注意：实时数仓最怕「静默故障」——任务还在跑，但数据已经不对了。我曾经遇到过Flink任务一直显示Running，但Sink端已经三天没收到新数据了。所以监控不能只看任务状态，必须看数据流。

很多团队一上来就搭Grafana，堆了一堆图表，结果出问题的时候还是靠人工翻日志。为什么？因为监控设计没想清楚。

我个人习惯，设计监控体系先问三个问题：

想清楚这些，再动手。下面这张表是我团队一直在用的监控分层模型：

监控层级	核心指标	常用工具	告警优先级
L1 基础设施	CPU、内存、磁盘、网络IO	Prometheus + Node Exporter	P3（低优先级，但需关注趋势）
L2 计算引擎	Checkpoint耗时、背压、Task失败率	Flink Metrics + Grafana	P1（高优先级，直接影响任务）
L3 数据链路	Kafka消费延迟、数据吞吐量、分区倾斜	Kafka Exporter + Burrow	P1（高优先级，数据流中断）
L4 业务指标	数据正确率、端到端延迟、产出SLA	自研数据质量平台	P0（最高优先级，业务受损）

💡 我的经验：告警不是越多越好。我见过一个团队配置了200多条告警规则，结果每天告警轰炸，真正出问题的时候反而没人看了。建议按「P0/P1/P2/P3」分级，P0必须电话通知，P3只发邮件周报。

原则这东西，说起来简单，做起来难。我结合自己的实战经验，提炼了三条：

原则一：从业务反推监控
别先想用什么工具，先想业务方最关心什么。比如大屏看板，业务方只关心「数据更新了没」「延迟多少秒」。那你的监控就应该围绕「数据新鲜度」和「端到端延迟」来设计。
原则二：监控要有「根因分析」能力
告警只是告诉你「出问题了」，但运维需要知道「为什么出问题」。比如Kafka消费延迟，原因可能是：上游数据量突增、Flink任务处理能力下降、下游写入变慢。监控体系应该能快速定位到具体环节。
原则三：自动化兜底，人工只做决策
能自动恢复的别让人动手。比如Flink任务挂了，自动重启；Kafka分区倾斜，自动Rebalance。人工只负责「要不要改代码」「要不要扩资源」这类决策。

一句话总结：好的监控体系，不是让你24小时盯着屏幕，而是让你在出问题前就收到预警，并且知道该从哪里下手。

这一章我们聊了实时数仓的架构演进、运维挑战和监控设计原则。说白了，实时数仓运维的核心就三件事：

后面的章节，我会带着大家一步步搭建完整的监控体系，从指标采集到告警配置，再到故障排查实战。嗯，咱们慢慢来。