经典的离线批处理（Hadoop/Hive）+ 实时OLAP（Doris）混合架构方案。Hive负责海量数据的ETL和分层建模，Doris负责对外提供毫秒级的查询服务。

以下从架构分层、数据流转、技术使用三个维度，为你拆解这套架构的设计思路和落地要点。

一、整体架构设计

核心设计理念是：**用Hive做”数据加工厂”，用Doris做”数据服务窗口”**。

Hive → Doris 数据流转架构图

graph TD
    subgraph 数据源层
        A1[业务数据库<br>MySQL/PostgreSQL]
        A2[日志文件<br>埋点日志/服务器日志]
        A3[外部数据<br>第三方API/文件]
    end

    subgraph 数据采集层
        B1[离线采集<br>Sqoop/DataX]
        B2[实时采集<br>FlinkCDC/Canal]
        B3[日志采集<br>Flume/Filebeat]
    end

    subgraph 消息中间件层
        C[Kafka<br>实时数据通道]
    end

    subgraph 离线数仓层_Hive
        D1[ODS层<br>操作数据层]
        D2[DWD层<br>明细数据层]
        D3[DWS层<br>汇总数据层]
        D4[ADS层<br>应用数据层]
    end

    subgraph 数据导出层
        E[数据导出<br>Spark/Flink 写入Doris]
    end

    subgraph 实时OLAP层_Doris
        F1[Doris<br>明细/聚合表]
        F2[Doris<br>物化视图/ Rollup]
    end

    subgraph 应用层
        G1[BI报表<br>Superset/帆软]
        G2[即席查询<br>Ad-hoc]
        G3[数据大屏<br>实时Dashboard]
        G4[数据API<br>接口服务]
    end

    A1 --> B1 --> D1
    A2 --> B3 --> C --> D1
    A3 --> B1 --> D1
    A1 --> B2 --> C --> D1
    
    D1 --> D2 --> D3 --> D4
    D4 --> E --> F1 --> F2
    
    F2 --> G1 & G2 & G3 & G4
  • 数据处理（离线部分）：Hadoop存储海量原始数据，Hive进行ETL和分层建模
  • 数据服务（实时部分）：Doris作为查询引擎，对外提供BI报表、即席查询、数据大屏等服务
  • 数据流转：Hive ADS层的数据通过Spark或Flink批量写入Doris

这套架构可以很好地平衡数据加工的复杂度和查询响应的性能。

二、数仓分层设计 (Hive侧)

分层设计是数仓的灵魂。标准的分层如下：

分层 全称 核心作用 数据特征 存储引擎
ODS 操作数据层 原始数据”原样”落地，保持与源系统一致 未清洗、未加工、分区存储 Hive (ORC/Parquet)
DWD 明细数据层 数据清洗、维度退化、数据脱敏、数据规范化 清洗后的明细数据、业务过程建模 Hive (ORC/Parquet)
DWS 汇总数据层 按主题（用户、商品、店铺）进行轻度汇总 预聚合、宽表、每日汇总 Hive (ORC/Parquet)
ADS 应用数据层 为具体报表定制的数据集 高度聚合、结果表、少量数据 Hive / Doris
DIM 公共维度层 存储业务实体的一致性维度信息 缓慢变化、描述性属性、高复用 Hive / Doris

各层具体说明：

  • ODS层：保持数据原貌，不做任何处理。注意处理增量/全量同步策略，数据存储格式建议使用ORC或Parquet，压缩比高且查询性能好
  • DWD层：进行数据清洗（去重、补全）、维度退化（将维度表的属性退化到事实表中，减少Join）。这是最耗时但价值最高的一层，建议使用Star Schema或宽表模型
  • DWS层：按天轻度聚合。例如：用户ID + 日期 粒度的下单次数、下单金额等。DWS层能极大提升查询性能
  • ADS层：直接对接BI报表。通常是DWS层指标的进一步计算（如环比、同比、漏斗计算）
  • DIM层：存储用户、商品、日期、地区等维度信息。建议维度数据在Doris中也保存一份，用于Join查询

三、技术实现与交互使用

1. 数据流转：如何从Hive到Doris？

Doris可以通过外表功能直接查询Hive数据，但通常建议将计算好的数据导入Doris表中。

最佳实践：Insert into Select

  • 利用Spark或Flink任务，读取Hive中的ADS层数据
  • 通过Doris的INSERT INTO tbl SELECT ...语法，将数据写入Doris
  • 如果数据量较大，建议使用Broker Load或Stream Load方式，性能更好

2. Doris层的设计（服务层）

数据进入Doris后，还需进一步设计以应对高并发查询：

  • 模型选择：
    • Unique Key模型：存储DIM维度表或需要更新的ADS结果表
    • Aggregate Key模型：存储DWS汇总层数据，可配合REPLACE_IF_NOT_NULL等聚合函数使用
    • Duplicate Key模型：存储DWD明细数据，支持灵活的查询分析
  • 分区与分桶：
    • 分区：按时间分区（dt），便于管理数据生命周期
    • 分桶：选择高基数的列（如user_id、order_id）进行Hash分桶，利用Doris的MPP架构加速查询

3. 查询与API

  • 应用接入：Doris兼容MySQL协议，可以直接使用JDBC或Python连接，无需复杂的API封装
  • BI工具：主流BI工具（如Superset、帆软、Tableau）可直接连接Doris进行图表展示

四、架构优势与适用场景

优势

  1. 存储成本低：Hadoop存储海量历史数据，成本低廉；Doris只存储”热”数据或汇总结果
  2. 计算能力强：Hive适合处理复杂、大规模的ETL作业；Doris适合高并发、低延迟的分析查询
  3. 数据一致性好：通过分层建模，统一了数据口径，避免指标混乱

适用场景

  • 互联网企业的用户行为分析、订单报表
  • 电商大促期间的实时大屏 + 离线历史对比
  • 存在大量历史数据需要查询，且对响应速度有要求的BI场景

五、踩坑与优化建议

  1. 小文件问题：Hive中容易产生大量小文件，拖慢NameNode。可以在Hive SQL最后增加INSERT OVERWRITE ... SELECT ... DISTRIBUTE BY ...语句进行文件合并
  2. 数据倾斜：大表Join时，空值或热点Key容易导致倾斜。可以考虑对倾斜Key加随机数打散，或使用Doris的Colocation Join（协同定位）优化
  3. Doris写入频率：切忌高频小批量写入Doris（例如每条都写），建议攒批写入（如每5分钟或每100MB写入一次），以平衡实时性和系统负载
  4. 维度数据实时更新：DIM层如果放在Hive，变更需重建分区，延迟较高。建议将频繁变动的维度表（如用户状态）同步到Doris的Unique表中，实时更新

六、 参考连接

1. Apache DolphinScheduler: 是一个分布式易扩展的可视化DAG工作流任务调度开源系统。适用于企业级场景，提供了一个可视化操作任务、工作流和全生命周期数据处理过程的解决方案。https://dolphinscheduler.apache.org/zh-cn/docs/3.2.0/about/introduction
2. Dinky 是一个开箱即用的一站式实时计算平台，以 Apache Flink 为基础，连接数据湖仓等众多框架，致力于流批一体和湖仓一体的建设与实践。https://www.dinky.org.cn/
3. DataX 是阿里云 [DataWorks数据集成](https://www.aliyun.com/product/bigdata/ide) 的开源版本，在阿里巴巴集团内被广泛使用的离线数据同步工具/平台。https://github.com/alibaba/DataX
4. **Apache Flink** 是一个在有界数据流和无界数据流上进行有状态计算分布式处理引擎和框架。https://nightlies.apache.org/flink/flink-docs-release-2.0/zh/
5. Apache Doris 是一个用于实时分析和搜索的数据库。它能够对实时数据进行大规模的闪电般快速的分析。https://doris.apache.org/
6. Doris docs:  https://doris.apache.org/docs/4.x/gettingStarted/quick-start#use-docker-for-quick-deployment