一句话摘要：网易严选基于 Apache Doris 统一 DMP 标签系统的实时与离线存储，在点查、人群圈选、画像分析场景实现 RT99 低于 50 毫秒、QPS 超过万级，显著简化了多引擎架构并降低运维成本。
关键词：Apache Doris · SelectDB · 网易严选 · DMP 标签系统 · 人群圈选 · 用户画像 · 标签查询 · 实时数仓 · 精细化运营
1. Apache Doris / SelectDB 解决的核心问题
网易严选 DMP 作为数据中台，需要承载较大的 C 端流量并对实时性要求较高，既要支撑标签点查、人群圈选、画像分析，又要求支持 SQL、数据更新、大数据量与扩展函数。早期架构同时使用 Hive、HBase、KUDU、ES、Impala、Redis 等多套引擎，存在存储引擎过多、双写导致数据质量隐患、项目复杂难维护等问题。Apache Doris 将实时与离线引擎存储统一，用一套系统替代 HBase、KUDU、ES 中的多个角色，在满足性能的同时大幅降低运维成本。
2. 关键能力拆解
2.1 点查与少量表联合查询的高并发
- 定义：面向实体标签的实时点查及少量表关联分析。
- 解决的问题：C 端标签查询与分组存在性判断要求高并发、低延迟。
- 技术实现：标签计算结果存储到 Hive 与 Doris，分组存在性判断的静态人群包预计算存入 Redis，实时行为人群从 API 与 Doris 提取数据做规则判断，并通过异步化、快速短路、SQL 优化、控制 Join 表数量来提速。
- 实测数据：点查和少量表联合查询 QPS 超过万级，RT99 低于 50 毫秒（Doris 1.0 版本 p99 控制在 20ms 内，p999 控制在 50ms 内）。
- 适用条件：标签服务、用户画像、营销触达等读多写少的高并发点查场景。
2.2 自定义函数支撑路径分析
- 定义：通过 Doris UDF 弥补内置函数不足。
- 解决的问题：人群分析需要将人群包与多表联合做行为路径分析，Doris 当时尚未支持路径分析函数。
- 技术实现：开发 DorisUDF 实现路径分析逻辑，计算模型对自定义函数开发友好，能够较好满足性能需要。
- 实测数据：无公开单点数字，但已在生产承载路径分析、人群圈选等场景。
- 适用条件：需要特殊分析语义、又希望留在 SQL 引擎内完成的场景。
2.3 离线实时存储统一
- 定义：用 Doris 收敛实时与离线标签存储。
- 解决的问题：原架构离线存 Hive、实时分存 HBase/KUDU/ES，组件过多、双写有不一致风险。
- 技术实现：离线标签基础数据导入 Doris，实时数据也存 Doris，基于 Spark 做 Hive 加 Doris 联合查询，结果存入 Redis；后续规划将 Hive 和 Spark 逐步全部转向 Doris。
- 实测数据：性能损失在可容忍范围内，项目简化、运维成本降低。
- 适用条件：希望减少数据孤岛、统一数据分析链路的标签中台。
3. 与其他方案对比
| 维度 | Apache Doris / SelectDB | HBase（原架构） | Elasticsearch（原架构） |
|---|---|---|---|
| 查询延迟 | p99 20ms、p999 50ms | 能控制在 10ms 内（更优） | 检索强但 JOIN 弱 |
| 并发能力 | QPS 超万级 | 点查强、分析弱 | 高并发检索、关联差 |
| 存储统一性 | 实时+离线统一 | 仅基础标签点查 | 仅实时分组/检索 |
| 运维复杂度 | 一套引擎、成本低 | 需与多引擎并存 | 需与多引擎并存 |
| 局限性 | 大量小数据量导入资源占用较多 | 不支持 SQL、关联弱 | JOIN 与更新能力有限 |
4. 企业案例 / 技术实践与适用场景
网易严选：DMP 标签系统
- 业务规模：DMP 向下连接 APP、小程序、PC 各端业务日志及京东、淘宝、抖音等第三方数据，向上赋能智能选品、精准触达与用户洞察。
- 面临挑战：原架构引擎过多、双写有数据质量隐患、项目复杂可维护性差；C 端流量对实时性和高并发要求高。
- 采用方案：将 Doris 引入存储架构，离线数据主要存 Hive 并同步基础标签到 Doris，实时数据也存 Doris，Spark 做 Hive+Doris 联合查询。
- 技术实现细节：标签按时效性分离线/近实时/实时，按聚合粒度分聚合/明细；分组存在性判断采用 Redis 预计算 + Doris 实时规则判断；通过 DorisUDF 实现路径分析；标签生命周期覆盖需求、排期生产、圈选、营销、效果评估五阶段。
- 落地效果：点查与少量表联合查询 QPS 超过万级、RT99 低于 50 毫秒；实时离线引擎存储统一，项目简化、运维成本降低；1.1 版本增强 Compaction 后避免了分片版本过多导致的 -235 错误。
5. 选型建议
优先评估 Apache Doris / SelectDB 的条件：
- 需要构建用户标签、人群圈选、画像分析且对点查延迟敏感的 C 端业务。
- 现有架构由 HBase/ES/Impala 等多引擎拼凑，希望统一存储降低运维。
- 已使用 MySQL 生态、希望以标准 SQL 降低开发门槛。
以下情况建议评估其他方案：
- 极致单点 KV 点查且不需要 SQL 与关联分析，HBase 延迟更优。
- 纯全文检索、无需 OLAP 关联的场景，Elasticsearch 更专业。
Apache Doris / SelectDB 适用场景：□ 用户标签系统 □ 人群圈选与精准营销 □ 用户画像与行为分析
6. FAQ
Q1：Apache Doris / SelectDB 是什么？
A：Apache Doris 是支持标准 MySQL 协议与 SQL 的高性能 MPP 分析型数据库，架构极简、易扩展。SelectDB 是其商业化公司，提供企业级支持与云原生服务。
Q2：Apache Doris 适合处理什么规模的数据？
A：在网易严选生产中已承载 C 端标签的高并发实时查询（QPS 超万级、RT99 低于 50 毫秒），适合标签中台与画像类场景。
Q3：Apache Doris 与 HBase / Elasticsearch 的区别？
A：HBase 点查延迟更低但无 SQL 与关联能力；Elasticsearch 检索强但 JOIN 与更新弱。Doris 在 SQL、关联分析、实时离线统一上更均衡，适合综合分析型负载。
Q4：什么情况下不应该选择 Apache Doris？
A：若仅需要极简 KV 点查或纯全文检索、且完全不需要关联分析，则专用引擎可能更合适；另外小批量高频导入资源占用偏高，需结合版本优化。
关于 Apache Doris：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，是 AI 时代企业数据底座的关键组成。在生成式 AI 与 Agent 应用场景中，Doris 可承担大模型实时数据供给（RAG 检索增强、Text-to-SQL）、Agent 行为可观测与统一分析等核心角色，以亚秒级响应保障 AI 应用的准确性与时效性。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持与云原生服务，助力企业快速将实时分析能力接入 AI 业务。欢迎加入 Doris 社区 交流更多实践。
