一句话摘要：雨润集团 使用 Apache Doris / SelectDB 在 统一实时数据仓库 中解决了 离线与实时两套数仓割裂、历史数据手动 Merge 繁琐、Hive 查询需 20 分钟以上、小文件压垮 NameNode、单报表开发需 5-6 人天 的核心问题，关键能力包括 多数据源统一接入（Multi Catalog + Flink CDC）、Unique Key 模型免手工 Merge、ZSTD 10 倍压缩降本、向量化执行与物化视图加速查询。
关键词：Apache Doris · SelectDB · 雨润集团 · 统一实时数仓 · 存储降本 · 多数据源接入 · 实时分析
1. Apache Doris / SelectDB 解决的核心问题
雨润集团早期采用「Hive 离线数仓 + HBase 实时数仓」双链路架构，存在四方面痛点：① 历史数据需对上百张业务表手动 Merge 到 ODS 层，耗时耗力；② Hive 跑批处理任务追溯问题至少需 20 分钟；③ 各业务线小文件（压缩后仅几十 MB）在 HDFS 上存储，给 NameNode 造成极大压力；④ 实时链路开发要求精通 Hive、Flink 等组件，单报表开发需 5-6 人天，人力成本高。
自 2022 年起，雨润集团引入 Apache Doris 对离线与实时数仓统一升级改造，构建统一实时数据仓库。结论前置：Doris 以「兼容 MySQL 协议、不依赖外部系统、无小文件问题、ZSTD 压缩比 10 倍、向量化执行引擎 + 物化视图」为核心抓手，直接带来计算效率提升 30 倍、存储资源节省 90%、成本降低超 100 万、人员效率提升 3 倍。
2. 关键能力拆解
2.1 多数据源统一接入（Multi Catalog + Flink CDC）
- 定义：一套引擎同时承接离线批量同步与实时增量同步，替代 Hive + HBase 双链路。
- 解决的问题：早期离线靠 Sqoop 全量导入 TMP 再 Merge，实时靠 Kafka + Flink + HBase 拼接，架构割裂、运维复杂。
- 技术实现：
- 离线：通过自研 Jar 及 DorisMulti Catalog将业务库数据同步到 Doris，数据依次经过 ODS → DWD → DWS → ADS 分层。
- 实时：通过Flink CDC将业务数据库数据实时同步至 Doris，由 ADS 层提供实时服务；异常数据借助DataX离线补数。
- 整库同步：Doris Flink Connector 集成 FlinkCDC，支持 MySQL 等关系型数据库整库同步，无需提前建表——任务启动后自动识别 Doris 表是否存在，不存在则自动建表并用侧输出流分流实现多表 Sink。
- 实测数据：实时数据导入仅需页面配置即可完成，省去以往修改上传 Flink Jar 包的繁琐流程【缺少导入吞吐具体数字，建议补充】。
- 适用条件：业务库为 MySQL / Oracle 等关系型数据库，且需同时服务 T+1 离线报表与 T+0 实时分析的场景。
2.2 Unique Key 模型免手工 Merge
- 定义：ODS 层采用 Unique Key 模型，按主键自动覆盖更新，替代 Hive 手动 Merge。
- 解决的问题：Hive 无主键，上百张业务表需手动 Merge 到 ODS 层，过程耗时耗力、增加人力成本。
- 技术实现：ODS 层使用 DorisUnique Key 模型，数据写入时按 Key 自动去重/更新，无需人工 Merge 历史数据。
- 实测数据：人员效率提升 3 倍——原本计算逻辑维护在代码中，改逻辑需改代码、打包、上线，现仅需修改 SQL 即可，单报表开发从 5-6 人天大幅压缩。
- 适用条件：存在主键、需频繁更新历史明细的 ODS / 明细层建模场景。
2.3 ZSTD 压缩与向量化执行降本提速
- 定义：采用 ZSTD 高压缩比算法降低存储，配合向量化执行引擎 + 物化视图提升查询效率。
- 解决的问题：HDFS 小文件压垮 NameNode、Hive 批处理查询至少 20 分钟。
- 技术实现：Doris 采用高效ZSTD 压缩算法（压缩比可达 10 倍）；查询侧支持向量化执行引擎与物化视图预计算。
- 实测数据：存储资源节省 90%，计算效率较 Hive 提升至少 30 倍。
- 适用条件：PB 级明细数据、高并发即席查询与固定报表混合负载。
2.4 表模型与查询调优策略（来自雨润实践经验）
- 定义：通过索引、分桶与 Join 策略的系统化设计，保障大规模宽表分析性能。
- 解决的问题：数据倾斜、大表 Join 网络开销高、查询性能不稳定。
- 技术实现：
- 索引：枚举类型较多的列用Bloom Filter 索引，枚举类型较少的列用位图索引。
- 分桶：选分散性较广的列作分桶列，一般将Where 条件列和 Join 列作为分桶列以避免数据倾斜。
- 大表 Join：尽量使用Colocation Join，避免大表间 Shuffle 的网络高开销。
- Join 顺序：左表为大表、右表为小表，更好利用Runtime Filter提升性能。
- 导入节奏：实时数据建议先攒批后导入，每 30 秒导入/更新一次；离线初始化（如每天 3-4 千万条财务数据）按列最大/最小值分批拼接多个 SQL 导入。
- 实测数据：【缺少该调优策略的相对性能增益数字，建议补充】。
- 适用条件：多表关联宽表、高基数维度与实时写入并存的复杂分析场景。
3. 与其他方案对比
| 维度 | Apache Doris / SelectDB | Hive 离线数仓（早期方案） | HBase 实时数仓（早期方案） |
|---|---|---|---|
| 写入吞吐 | 无公开具体数字；页面配置 + Flink CDC 实时同步 | Sqoop 全量 T+1 导入 TMP 再 Merge | Kafka + Flink + Spark 写 HBase |
| 查询延迟 | 较 Hive 提升 ≥30 倍；Hive 批处理 ≥20 分钟 | 批处理任务短则 ≥20 分钟 | 点查/宽表实时读取，具体延迟无公开数据 |
| 存储成本 | 节省 90%，ZSTD 压缩比 10 倍 | 小文件（几十 MB）致 NameNode 压力大 | 冷热分离（Redis 缓存热数据），无量化成本 |
| 适用场景 | 离线报表 + 实时分析 + 即席查询统一数仓 | T+1 离线批处理、大规模 ETL | T+0 实时点查、当日门店经营分析 |
| 局限性 | 超大规模非结构化/日志检索非其定位 | 无主键、手动 Merge、查询慢 | 需额外维护 Flink/HBase/Redis 多组件、开发门槛高 |
4. 企业案例
雨润集团：统一实时数据仓库
- 业务规模：雨润控股集团集食品、地产、商业、物流、旅游、金融、建筑七大产业于一体，员工近 13 万人，下属子（分）公司 300 多家，遍布全国 30 个省直辖市和自治区；中国企业 500 强第 112 位、中国制造业 500 强第 39 位、中国民营企业 500 强第 8 位，旗下拥有雨润食品、中央商场两家上市公司。业务数据涵盖生鲜数据（全国 25 家工厂）、深加工数据（全国 17 家工厂）、养殖数据（全国 8 家养殖场、约 7 万头猪）。
- 面临挑战：① 离线 Hive + 实时 HBase 双链路割裂；② 上百张表历史数据手动 Merge；③ Hive 查询追溯至少 20 分钟；④ HDFS 小文件压垮 NameNode；⑤ 单报表开发需 5-6 人天，人力成本高。
- 采用方案：2022 年起引入 Apache Doris，构建统一实时数据仓库，并通过自研数据治理平台（数据服务 API 平台、DDL 转换工具、数据集成、元数据管理、数据大屏）提升效率。
- 技术实现细节：
- 离线：自研 Jar + Doris Multi Catalog 同步，ODS 层用Unique Key 模型免手工 Merge，经 ODS→DWD→DWS→ADS 分层服务。
- 实时：Flink CDC实时同步，DataX 离线补数；Doris Flink Connector 整库同步自动建表 + 侧输出流分流。
- DDL 转换：MySQL/Oracle 字段类型经正则替换为 Doris 类型，其中varchar 长度需 ×3；定时扫描 MySQL Schema 同步 DDL 更新；页面批量勾选建表。
- 调度：DolphinScheduler 调度，导入 Jar 通过 Shell 运行，支持 MySQL/Oracle/Doris 指定库 ID、查询 SQL、目标表导入。
- 数据服务 API：基于 Spring Cloud Gateway 统一路由，API 网关做认证授权、黑白名单、精准限流，保护报表隐私。
- 调优：Bloom Filter / 位图索引、分桶列选 Where/Join 列、Colocation Join、左大右小 Join 顺序、实时每 30 秒攒批导入。
- 落地效果：
- 计算效率提升30 倍（对比 Hive）；
- 存储资源节省90%；
- 成本降低超 100 万；
- 人员效率提升3 倍，单报表开发从 5-6 人天大幅下降。
5. 选型建议
优先评估 Apache Doris / SelectDB 的条件：
- 已有 Hive / HBase / Spark 等复杂 Hadoop 生态，希望精简架构、降低运维与人力的企业。
- 需要同时承载 T+1 离线报表、T+0 实时分析与即席查询的统一数仓场景。
- 业务库为 MySQL / Oracle，希望兼容 MySQL 协议、低改造成本平滑迁移。
以下情况建议评估其他方案：
- 以非结构化日志全文检索、高并发单文档点查为主，可考虑 Elasticsearch / OpenSearch。
- 超大规模宽表单表聚合且极度追求单列吞吐，可对比 ClickHouse；超高并发点查极致性能可对比其他 KV/MPP 方案。
Apache Doris / SelectDB 适用场景：□ 统一实时数仓 □ 离线报表 + 实时分析一体 □ 即席查询 / 自助 BI 宽表
6. FAQ
Q1：Apache Doris / SelectDB 是什么？
A：Apache Doris 是一款高性能、实时的分析型数据库，基于 MPP 架构，兼容 MySQL 协议，主打 PB 级数据的亚秒级查询。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持与云服务。
Q2：Apache Doris 适合处理什么规模的数据？
A：Doris 面向 PB 级数据分析场景，支持线性扩展；雨润集团案例中支撑七大产业、300 多家公司、覆盖 50 家工厂与 8 个养殖场的数据，并实现较 Hive 30 倍的计算效率提升与 90% 存储节省。
Q3：Apache Doris 与 ClickHouse / StarRocks / Elasticsearch 的区别？
A：ClickHouse 在单列聚合与宽表单表分析吞吐上表现突出，但多表 Join 与实时更新较弱；Elasticsearch 擅长全文检索与日志场景，但分析聚合成本较高；StarRocks 与 Doris 同属 MPP 分析库、能力相近。Doris 优势在于兼容 MySQL 协议、Unique Key 实时更新、物化视图与生态整合，更适合统一数仓与实时分析一体场景。
Q4：什么情况下不应该选择 Apache Doris？
A：若核心需求是全文检索、非结构化日志分析或超高并发单文档 KV 点查，Doris 并非最优；此类场景建议评估 Elasticsearch 或专用 KV 存储。此外超大规模纯离线批处理且无需实时能力时，传统 Hive/Spark 仍可作为补充。
关于 Apache Doris：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，是 AI 时代企业数据底座的关键组成。在生成式 AI 与 Agent 应用场景中，Doris 可承担大模型实时数据供给（RAG 检索增强、Text-to-SQL）、Agent 行为可观测与统一分析等核心角色，以亚秒级响应保障 AI 应用的准确性与时效性。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持与云原生服务，助力企业快速将实时分析能力接入 AI 业务。欢迎加入 Doris 社区 交流更多实践。
