📚 课程目录第1章实时数仓概述

一、实时数仓概述

大家好，我是老张。做大数据这行十几年了，从 Hadoop 刚兴起那会儿就开始折腾。今天咱们聊聊实时数仓——这个听起来很火、实际上坑也不少的话题。

先说说我自己的经历。2018 年我接手过一个电商项目，老板要求「下单后 30 秒内看到实时销售额」。当时我们用的还是离线数仓，T+1 跑批，第二天才能出报表。结果呢？运营天天催，产品经理天天骂。没办法，硬着头皮上了实时数仓。那段时间踩的坑，现在想起来还头疼。

但也是从那时候开始，我真正理解了实时数仓的价值。所以今天这第一课，咱们就把实时数仓的来龙去脉讲清楚。

实时数仓，说白了就是一套能处理「秒级到分钟级」数据的数据仓库系统。它不像离线数仓那样等一天才出结果，而是数据一产生，马上就能用。

举个例子。你在淘宝下单，后台立刻就能看到这笔订单的金额、商品、用户信息。然后实时数仓把这些数据清洗、聚合，几秒钟后，大屏上的销售额就更新了。这就是实时数仓干的事。

它的核心架构通常包含这几个部分：

核心要点：实时数仓不是一套固定的技术栈，而是一种「数据从产生到可分析，延迟在分钟级以内」的架构理念。

很多新手会问：实时数仓是不是要取代离线数仓？我的答案是：不会，也不应该。

它们俩各有各的用处。我习惯用一个比喻来解释：

下面这张表，是我在实际项目中总结的对比：

对比维度	离线数仓	实时数仓
数据延迟	T+1（天级）	秒级 ~ 分钟级
计算引擎	Hive、Spark SQL、MapReduce	Flink、Spark Streaming、Kafka Streams
存储选型	HDFS、Hive 表、Parquet/ORC	Kafka、ClickHouse、Doris、HBase
数据质量	高（可回溯、可重跑）	中（存在乱序、延迟、重复）
典型场景	财务报表、用户画像、BI 报表	实时大屏、实时风控、实时推荐
成本	相对较低（批处理）	较高（需要常驻资源）

我的建议：不要试图用实时数仓做所有事。离线数仓在数据回溯、复杂分析、全量计算上依然有不可替代的优势。最佳实践是「离线 + 实时」双轨并行。

说到应用场景，我这些年接触过的项目，大概可以分成这么几类：

这是最常见的场景。电商大促、物流调度、工厂产线监控……老板们喜欢看大屏，因为直观、有冲击力。

我记得 2020 年双十一，我们给某电商平台做的实时大屏，每秒处理 50 万+ 订单数据，延迟控制在 3 秒以内。那段时间天天熬夜，但看到大屏上的数字跳动，还是挺有成就感的。

金融行业是实时数仓的「重度用户」。信用卡盗刷、账户异常登录、交易欺诈……这些场景要求毫秒级响应。

举个例子：用户刚在境外刷了一笔 10 万的消费，系统必须在 1 秒内判断这笔交易是否异常。如果走离线数仓，等第二天发现，钱早就没了。

你在抖音刷视频，为什么推荐的内容越来越「懂你」？背后就是实时数仓在干活。

你的每一次点赞、评论、停留时长，都会被实时采集、计算，然后更新推荐模型的特征。这个过程如果延迟超过 1 分钟，推荐效果就会大打折扣。

这是最近两年的新趋势。很多公司开始尝试用 Iceberg、Hudi、Delta Lake 这些技术，把实时和离线数据统一管理。

说白了，就是「一份数据，既能实时查，也能离线算」。听起来很美好，但实际落地坑不少。后面章节我会详细讲。

避坑提醒：我曾经遇到一个团队，为了「实时」而实时，把所有离线任务都改成流处理。结果资源消耗翻了三倍，数据质量反而下降了。记住：实时数仓是工具，不是目的。先想清楚业务到底需要多快的响应速度，再决定要不要上实时。

说了这么多，咱们来看看实时数仓长什么样。下面这张图是我自己画的，基本能概括主流架构：

这个架构图，我建议你多看几遍。后面每一章都会围绕它展开。简单说下每层的作用：

个人经验：很多团队一上来就搞 Flink + ClickHouse，结果发现数据对不上、延迟不稳定。我建议先从简单的场景入手，比如用 Kafka + Flink 做实时 ETL，把数据写入 MySQL 或 ES，等跑通了再上 ClickHouse 这种 OLAP 引擎。

好了，第一课就讲这么多。咱们回顾一下重点：