实时数仓（Real-time Data Warehouse）和离线数仓（Offline Data Warehouse）是大数据架构中的两种主要数据仓库模式，它们的核心区别主要体现在数据的处理方式、延迟、应用场景和技术选型等方面。
1. 实时数仓（Real-time Data Warehouse）
实时数仓主要用于需要低延迟、实时响应的业务场景，能够处理流式数据，并在数据生成后短时间内提供分析结果。
特点
- 数据更新快：数据可以在秒级甚至毫秒级内进入数仓，并进行加工处理，适用于需要实时决策的业务场景。
- 流式处理：通常采用流式计算框架（如 Apache Flink、Apache Storm、Kafka Streams）来实现数据的实时计算和分析。
- 架构较复杂：通常涉及数据采集、流式计算、实时存储、查询引擎等多个组件，需要保证数据的一致性和吞吐能力。
- 数据时效性高：适用于需要实时监控、告警、推荐等业务，如风控系统、秒杀库存管理、用户行为分析等。
技术选型
- 数据采集：Kafka、Flink CDC、Debezium
- 流式计算：Apache Flink、Apache Storm、Spark Streaming、Kafka Streams
- 存储：Apache HBase、Apache Druid、ClickHouse、Elasticsearch
- 查询引擎：Druid、Presto、ClickHouse、Elasticsearch
适用场景
- 实时风控（如反欺诈检测、信用评估）
- 实时推荐（如个性化推荐、千人千面）
- 监控告警（如服务器监控、日志分析）
- 实时数据分析（如订单交易分析、用户行为分析）
2. 离线数仓（Offline Data Warehouse）
离线数仓主要用于大规模数据存储和分析，数据通常是批量导入和计算的，适用于对时效性要求不高的业务场景。
特点
- 数据更新延迟：通常是小时级、天级或者更长，数据批量加载后进行处理。
- 批处理计算：采用批处理框架（如 Apache Spark、MapReduce）进行大规模数据计算，适用于复杂的多维分析和历史数据挖掘。
- 架构相对稳定：依赖 Hadoop 生态系统，存储、计算、查询分层清晰，适合海量数据的深度分析。
- 数据规模大：通常用于长期存储数据，并支持大规模批量分析，如数据挖掘、BI 报表等。
技术选型
- 数据存储：HDFS、Hive、Hudi、Iceberg
- 批处理计算：Apache Spark、Apache Hive、Apache Flink（批模式）、MapReduce
- 查询引擎：Presto、Impala、Druid
- 调度系统：Apache Airflow、DolphinScheduler、Azkaban
适用场景
- 历史数据分析（如用户画像、市场趋势分析）
- BI 报表（如企业决策支持、财务分析）
- 机器学习训练数据（如模型训练、数据挖掘）
- 长期数据存储（如日志归档、审计）
3. 实时数仓 vs. 离线数仓
| 特性 | 实时数仓 | 离线数仓 |
|---|---|---|
| 数据时效 | 毫秒级/秒级 | 小时级/天级 |
| 计算方式 | 流式计算 | 批量计算 |
| 架构复杂度 | 高（流计算+实时存储） | 相对较低（批计算+离线存储） |
| 数据一致性 | 较难保证，通常是最终一致性 | 强一致性，数据完整 |
| 典型应用 | 实时监控、风控、推荐系统 | BI 报表、历史数据分析 |
| 技术栈 | Flink、Kafka、ClickHouse、Druid | Spark、Hive、Presto、HDFS |
4. 混合架构（Lambda架构 & Kappa架构）
为了兼顾实时性和数据完整性，很多企业采用混合架构：
- Lambda架构（离线 + 实时）
- 离线数据仓库存储完整数据，支持深度分析。
- 实时数仓提供低延迟数据分析，满足业务实时需求。
- 适合既需要实时处理，也需要高质量数据的场景。
- Kappa架构（基于流计算）
- 仅使用流计算架构，通过流式处理实现实时和批处理的统一。
- 适用于数据时效性极高的业务，如高频交易、实时监控。
5. 总结
- 实时数仓 适合对时效性要求高的业务，如实时风控、推荐系统、监控告警。
- 离线数仓 适合长期数据存储和分析，如BI报表、用户画像、数据挖掘。
- 混合架构（Lambda/Kappa） 是大多数企业的选择，以满足实时性和数据完整性的需求。
你的业务如果涉及用户行为分析、风控等高实时性场景，建议使用实时数仓；如果是历史数据分析、BI 报表，离线数仓更适合。或者，结合 Lambda/Kappa 进行混合架构设计。
查询引擎
查询引擎（Query Engine）并不是用来存放数据的，而是用于高效查询和分析数据的工具，它们对存储在不同数据源（如 HDFS、Hive、ClickHouse、Druid、Elasticsearch 等）中的数据执行查询计算，以提供快速的数据分析和查询服务。
查询引擎的作用
- 提供高效的查询能力：优化 SQL 查询，提升查询速度，减少数据扫描范围，适用于 OLAP（在线分析处理）。
- 支持多种存储后端：查询数据时并不依赖特定的存储引擎，而是可以对接多种数据存储，如 HDFS、S3、Kafka、Elasticsearch、ClickHouse 等。
- 优化计算效率：通常具备分布式计算能力，能并行处理大规模数据，提高查询性能。
- 支持交互式查询：有些查询引擎支持类 SQL 语法（如 Presto、Druid），用户可以直接写 SQL 来查询，而无需复杂的 MapReduce 或 Spark 任务。
常见的查询引擎
| 查询引擎 | 主要用途 | 适用场景 | 底层数据存储 |
|---|---|---|---|
| Presto | 分布式 SQL 查询 | OLAP 分析，交互式查询 | Hive、HDFS、S3、Kafka、Elasticsearch |
| Apache Druid | 实时和历史数据分析 | 实时监控、BI、日志分析 | 自带存储，也可对接 HDFS、S3 |
| ClickHouse | 列存数据库，超快查询 | 实时数据分析、监控 | 本地存储（高效列存） |
| Elasticsearch | 搜索和查询 | 全文搜索、日志分析 | 自带存储（倒排索引） |
| Impala | 低延迟 SQL 查询 | 交互式分析 | Hive、HDFS |
| Trino（Presto的演进版） | 大规模 SQL 计算 | 云数据仓库分析 | Hive、S3、Iceberg、Delta Lake |
查询引擎与存储的关系
查询引擎不存储数据，而是对存储在 HDFS、Hive、ClickHouse、S3、Elasticsearch 等存储引擎中的数据进行高效查询。比如：
- Presto / Trino：可查询存储在 HDFS、S3、Elasticsearch 等数据源中的数据，不会修改存储的数据。
- Druid：本身有存储能力，但也可以查询外部数据源（如 Kafka）。
- ClickHouse：虽然是数据库，但由于其强大的查询能力，很多时候也被当作查询引擎使用。
查询引擎的应用场景
- BI 报表分析：如使用 Presto 查询 Hive 数据库，生成数据报表。
- 日志查询：如 Elasticsearch 用于日志分析，提供快速查询能力。
- 实时监控：如 Druid 结合 Kafka 进行流式数据分析，提供秒级查询能力。
总结
- 查询引擎不存数据，它负责优化 SQL 查询并快速获取结果。
- 存储层（HDFS、Hive、ClickHouse、Elasticsearch）负责存放数据，而查询引擎负责高效计算。
- 不同查询引擎适用于不同场景，如 Presto 适合离线数仓分析，Druid 适合实时分析，ClickHouse 适合高吞吐数据查询。