实时数仓和离线数仓还分不清楚？看完就懂了
目录
一、什么是离线数仓
1. 批处理
2. 数据时效性
3. 高容量
4. 数据存储
二、什么是实时数仓
1. 实时性
2. 快速响应
3. 高吞吐量
4. 数据存储
三、实时数仓和离线数仓的区别
1.架构上
2.建设方法上
3.数据保障上
四、实时数仓建设方案
1. 明确业务需求与目标
2. 技术栈选型
3. 保障与监控
五、数仓的架构设计
1.离线大数据架构
2.Lambda 架构
3.Kappa 架构
六、总结
实时数仓？离线数仓？是不是经常听到这两个词，却总有点分不清它们到底有啥不一样？别担心，这几乎是每个数据新手都会遇到的困惑。简单来说，它们最核心的区别就在于“快慢”和“怎么处理数据”。 这篇文章就用最直白的语言，带你快速搞懂两者的定义、特点、常用技术和应用场景，三分钟让你心里明明白白！
正文开始之前，先给大家分享一份《数据仓库建设解决方案》，包括调研、需求梳理、建设规范、建模全流程，从数据标准的规范到报表体系的建设都提供明确的建设思路，高效解决常见的口径不一致、报表查询慢等问题。需要自取：数据仓库建设解决方案 - 帆软数字化资料中心（复制到浏览器打开）
一、什么是离线数仓
一句话理解：离线数仓是一个专门用来存储和处理批处理数据的系统。
它的数据处理和分析都是基于批处理作业来进行的，主要靠sqoop、hive这些技术来搭建，处理的是T+1的离线数据。
具体怎么做呢？
离线数仓目前主要是通过定时任务每天拉取新增的增量数据，导入到hive表里，然后根据各个业务的需求，创建相关的主题维度数据，对外提供的是T+1的数据查询接口。一般有这么几个特点：
1. 批处理
数据会在一定的时间周期内收集、存储起来，然后一次性进行处理。听着是不是很熟？很多需要汇总一段时间数据的场景都会用到这种方式。
2. 数据时效性
通常都是T+1，也就是说数据产生后的下一个时间单位，比如小时或者天，才会进行处理。
3. 高容量
设计的时候就考虑到了要存储大量的历史数据，所以在存储能力上很有优势。
4. 数据存储
一般会存在HDFS、Hive这些系统里，这样才能支持大规模数据的存储和查询。
二、什么是实时数仓
一句话理解：实时数仓指的是能够实时处理和分析数据的系统。
但它要保证数据仓库里的数据是最新、最准确的，而且能实时响应用户的查询和分析需求。
具体怎么做呢？
实时数仓目前主要是用canal这类数据采集工具，把原始数据写到Kafka这样的数据通道里，最后一般会存到HBase这类存储系统中，对外能提供分钟级甚至秒级的查询方案。一般有这么几个特点：
1. 实时性
能实时或者接近实时地处理数据，通常在秒级或者分钟级内就能完成数据的收集、处理和分析。
2. 快速响应
可以迅速响应用户的查询和分析需求，给用户提供即时的数据支持。
3. 高吞吐量
随着实时技术的发展，现在实时数仓的数据吞吐量也比较高了。
4. 数据存储
一般存在Kafka、HBase、Redis、Clickhouse这些系统中，这些系统能支持快速的数据读写和查询。
三、实时数仓和离线数仓的区别
看到这里，你可能会好奇，实时数仓和离线数仓具体有哪些不一样的地方？别急，这部分就来详细说说它们的区别，帮你更清晰地分辨两者。
1.架构上
实时数仓和离线数仓区别挺明显的，实时数仓主要用Kappa架构，离线数仓则以传统大数据架构为主。Lambda架构可以算是两者的中间态。
2.建设方法上
实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论，产出事实宽表。另外，实时数仓中实时流数据的join有隐藏的时间语义，建设的时候可得注意了。如果觉得自建麻烦，可以考虑借助成熟工具。
比如FineDataLink，能一键配置数据同步任务，无需代码就能完成CDC采集和实时计算，还自带错误重试和监控功能，能帮技术团队搭建数仓时省下不少精力。FineDataLink体验地址→免费FDL激活（复制到浏览器打开）
3.数据保障上
实时数仓因为要保证实时性，所以对数据量的变化很敏感。用过来人的经验告诉你，在大促这类场景下，得提前做好压测和主备保障工作，这和离线数据有明显区别。
一句话总结：
实时数仓主要解决数据时效性问题，结合机器学习框架能处理实时推荐、实时获取广告投放效果等智能化业务场景。
但归根到底，实时数仓的建设得早日提上日程，毕竟未来企业对数据时效性的要求会越来越高，实时数仓能很好地解决这个问题。
四、实时数仓建设方案
实时数仓的建设需要围绕时效性、稳定性、可扩展性展开，建设方案一般可以分为以下三个环节：
1. 明确业务需求与目标
用过来人的经验告诉你，建实时数仓前必须先把业务需求吃透。
这3个问题必须先搞清楚：
- 数据的实时性要求是秒级还是分钟级
- 数据量大概有多大
- 需要支持哪些查询维度和分析场景
这些基础问题没弄明白，后面很容易做无用功。
举个典型例子：
电商的实时销量监控和金融的实时风控，对实时性和数据处理精度的要求就完全不同。
2. 技术栈选型
（1）数据采集层：一般用Canal、Debezium这类工具捕获业务数据库的binlog，或者用Flink CDC直接拉取实时数据变更，然后写入Kafka作为数据缓冲通道。
关键点：
这里要注意保证数据不丢不重，尤其是高并发场景下的断点续传能力。
（2）数据处理层：主流用Flink进行实时清洗、转换和关联，比如实时关联用户行为数据和订单数据，计算最新的转化漏斗。
关键点：
这一步既要保证计算准确，又要能扛住流量波动，所以得做好背压机制和资源动态调整。
（3）数据存储层：根据查询场景选存储工具，简单key-value查询用Redis，复杂聚合分析用ClickHouse、Doris，海量明细数据存储用HBase。很多企业会结合多种存储，各取所长。
（4）服务层：提供低延迟查询接口，比如用Flink SQL直接查结果表，或把实时结果推到API网关供业务调用。
3. 保障与监控
监控告警必须跟上，要实时监控数据延迟、处理失败率、资源占用等指标，一旦出现异常能及时告警。
关键点：
要做好容灾备份，在大促等流量高峰前做好压测，确保系统稳定运行。
简单来说，实时数仓建设的核心是平衡好实时性、准确性和成本，根据业务需求选对架构和工具才是关键。
五、数仓的架构设计
接下来咱们再深入看看数仓的架构设计，不同的架构在数据处理和应用上各有特点，这对实际建设数仓很重要。
1.离线大数据架构
数据源会通过离线的方式导入到离线数据中，下游应用根据业务需求，要么直接读取DM，要么加一层数据服务，比如MySQL或者Redis。从模型层面看，数据仓库分为三层：
（1）ODS（操作数据层）：用来保存原始数据，这是最基础的数据层。
（2）DWD（数据仓库明细层）：会根据主题定义好事实与维度表，保存最细粒度的事实数据。
（3）DM（数据集市/轻度汇总层）：在DWD层的基础上，根据不同的业务需求做轻度汇总。
典型的数仓存储是HDFS/Hive，ETL可以用MapReduce脚本或者HiveSQL来实现。
2.Lambda 架构
Lambda架构有个大问题，就是同样的需求得开发两套一样的代码。这可不是小事，两套代码不仅开发起来麻烦，同一个需求，既要在批处理引擎上实现，又要在流处理引擎上实现，还得分别构造数据测试，保证两者结果一致。而且后期维护更费劲，比如需求变了，得分别改两套代码，各自测试结果，两个作业还得同步上线，你说麻烦不麻烦？
另外，资源占用也会增多，同样的逻辑计算两次，整体资源消耗肯定会增加，多出实时计算那部分的资源占用。
3.Kappa 架构
Lambda架构虽然满足了实时的需求，但带来了更多开发和运维工作。
其实它的架构背景是那时候流处理引擎还不完善，流处理的结果只能作为临时的、近似的值提供参考。
后来随着Flink等流处理引擎的出现，流处理技术成熟了，为了解决两套代码的问题，LinkedIn的Jay Kreps提出了Kappa架构。
Kappa架构可以看作是Lambda架构的简化版，说白了，就是把Lambda架构里的批处理部分去掉就行。
在Kappa架构里，需求修改或者历史数据重新处理，都通过上游重放来完成。
它最大的问题是流式重新处理历史数据的吞吐能力比批处理低，但这个可以通过增加计算资源来弥补。
六、总结
离线数仓基于批处理技术，擅长处理海量历史数据，提供T+1时效性的分析结果；而实时数仓则依托流处理技术，实现数据的秒级/分钟级处理与分析，满足高时效性业务需求。二者在架构设计、建设方法、数据保障及应用场景上各具特色，企业需结合自身业务对数据时效性、处理规模及成本效益的具体要求，审慎选择或融合建设。明确区分并合理运用实时与离线数仓能力，是最大化数据价值、赋能敏捷决策的基础。