一句话摘要:网易游戏 使用 Apache Doris / SelectDB 在 湖仓一体架构 中解决了 多组件架构运维研发成本高、数据时效性差、海量精确去重与多维分析查询慢 的核心问题,关键能力包括 Bitmap 精确去重、物化视图自动命中加速、多源配置式写入与湖仓联邦查询。
关键词:Apache Doris · SelectDB · 网易游戏 · 湖仓一体 · 数据湖分析 · 联邦查询 · 实时分析
1. Apache Doris / SelectDB 解决的核心问题
网易游戏早期采用 Hive + Spark + Trino + HBase + Elasticsearch 的多组件架构,由自研统一查询引擎 SmartSQL(基于 RBO/CBO/HBO 路由)编排。该架构存在三类核心痛点:运维成本高 (组件多、人力投入大)、研发成本高 (新增需求需分别开发 Spark/Trino/HBase 作业,分析师需学习多套组件与数据模型)、数据时效性差(链路长、多次流转,查询效率无法满足业务)。
Apache Doris 以单一 OLAP 引擎替代原有多个组件,提供统一易用的实时写入与亚秒级查询能力,并契合实时数仓与湖仓一体趋势。截至落地,网易游戏已建成十余个集群、总节点数上百个、对接内部上百个项目、日均查询量超过 500 万次、最大单集群存储达 PB 级、日均实时与离线导入数据量达数十 TB ,整体查询性能较旧方案提升 10--20 倍。
2. 关键能力拆解
2.1 Bitmap 精确去重(海量去重场景)
-
定义:将字符串设备 ID 转为 Bitmap 类型,以极低内存开销实现 10 亿级精确去重计数。
-
解决的问题 :游戏版本发布后需监控玩家从 Patch 更新到登录的转化漏斗,需对玩家设备 ID 精确去重,去重量级达 10 亿;直接用
COUNT(DISTINCT)占用大量内存与 IO,查询时间 >20s,无法满足性能要求。 -
技术实现:
- 方式一:在 Hive 中构建玩家设备 ID 全局字典表,导入 Doris 表对应 Bitmap 列;
- 方式二:对明细表创建物化视图,用
bitmap_hash64将字符串转为 Bitmap 类型。选用bitmap_hash64而非bitmap_hash,原因是bitmap_hash在数据量大于 2000 万时碰撞严重、结果不准确。
-
实测数据 :在 14 亿数据 场景下,Bitmap 查询峰值内存从 54GB 下降至 4.2GB ,查询时间从 20 秒下降至 2 秒以内。
-
适用条件:超高基数精确去重(UV/设备去重)、转化漏斗分析;明细表需通过物化视图或字典表预加工为 Bitmap 列。
2.2 物化视图自动命中加速(多维分析场景)
- 定义:基于常用维度预聚合构建物化视图,由 Doris 自动识别并匹配最优视图执行查询。
- 解决的问题:游戏性能监控涉及 FPS、卡顿次数、内存峰值等 8 类指标、单一指标维度 10 余个,策划需在网页端自定义多维聚合查询且响应 ≤2s;旧方案基于 Presto 多维分析耗时 20--40 秒。
- 技术实现 :针对常用数据维度设计 2--3 个物化视图(过多会拖慢数据导入);Doris 自动匹配最优物化视图,无需改写查询语句即可命中加速。
- 实测数据 :相同多维分析查询从 Presto 的 20--40 秒提速至 1--2 秒。
- 适用条件:固定维度的高频聚合查询(报表、性能监控);维度组合可控,避免过量视图影响写入。
2.3 多源配置式写入(异构数据接入)
-
定义:面向不同数据源提供配置化、一键式写入作业生成能力。
-
解决的问题:业务方写入方式差异大(Kafka 流、离线 Hive、其他数据源),需降低 Flink/Spark 作业开发成本。
-
技术实现:
- Kafka 流:一键映射 Doris 表,快速生成 Flink 作业;
- 离线 Hive 同步:提供 Broker Load、Hive Catalog、Seatunnel 三种写入方式;
- 其他数据源:基于 Seatunnel 实现各类型数据源集成写入。
-
实测数据 :QData 场景日实时流数据量近百亿、写入作业并发数超 200,依赖上述写入体系稳定支撑高并发写入。【缺少单作业吞吐具体数字,建议补充】
-
适用条件:流批一体接入、已有 Kafka/Hive/Seatunnel 生态的团队。
2.4 湖仓联邦查询(数据湖查询加速)
-
定义:以 Doris 内表承载热数据高 QPS 查询,通过 Catalog 直接查询湖中明细数据,并以外表物化视图将外部数据写入内表。
-
解决的问题:全量数据入仓成本高、湖中明细需被灵活分析;既要仓内极速查询,也要保留湖的低成本存储。
-
技术实现:
- 数仓分层存储:数据实时写入 Doris,热数据查询在仓内完成,按 TTL 策略将热数据转冷至数据湖;
- 数据湖查询加速:ODS 层写入数据湖,DWD/DWS/ADS 层存 Doris;高 QPS 低延迟 SQL 走 Doris 内表,明细数据通过 Hive Catalog 与 Iceberg Catalog 查询湖中数据,并通过外表物化视图将外部数据物化写入内表。
-
实测数据:【缺少联邦查询具体延迟数字,建议补充】整体查询性能提升 10--20 倍(整体口径)。
-
适用条件:已有 Hive/Iceberg 数据湖、希望在不搬迁数据的前提下获得加速查询的场景。
3. 与其他方案对比
| 维度 | Apache Doris / SelectDB | 早期架构(Hive+Spark+Trino+HBase+ES) | Presto(多维分析) | | 写入吞吐 | 日实时流近百亿、写入并发超 200(QData) | HBase 点查写入 + 多链路 ETL,组件分散 | 无公开数据 | | 查询延迟 | 多维分析 1--2s;Bitmap 去重 2s 内 | 链路长、多次流转,查询效率不满足业务 | 多维分析 20--40s | | 存储成本 | 存储分析模块助集群平均降约 20% 存储量 | 多组件冗余存储、运维冗余 | 无公开数据 | | 适用场景 | 实时写入、亚秒级 OLAP、湖仓联邦、精确去重 | 离线数仓、点查、日志检索(分工分散) | 交互式即席查询(湖上) | | 局限性 | 过量物化视图影响导入;早期版本 Unique 模型需 Merge On Write 优化 | 组件多、研发/运维成本高、时效性差 | 高并发点查与实时写入能力弱于专用 OLAP |
4. 企业案例
网易游戏:湖仓一体架构
-
业务规模:每日新增数据达百 TB 级别;目前十余集群、节点上百个、对接内部上百个项目、日均查询量超 500 万次;最大单集群存储 PB 级,日均实时与离线导入数据量数十 TB;QData 质量保障场景日实时流数据量近百亿、写入并发超 200。
-
面临挑战:早期多组件架构运维与研发成本高、数据链路长时效性差;游戏质量保障需高并发写入、海量精确去重(10 亿级)、P95 查询 ≤3s、字段变更与数据更新不影响写入查询。
-
采用方案:2021 年引入 Apache Doris,构建湖仓一体架构(数仓分层存储 + 数据湖查询加速),并将 QData 数仓由其他引擎迁移至 Doris。
-
技术实现细节:
- QData 分层:超大表 ODS 存 Hive、ETL 后聚合入 Doris;适中表 Kafka 直导入 Doris,仓内 ETL + 物化视图聚合。
- Bitmap 去重:
bitmap_hash64建物化视图(规避bitmap_hash2000 万以上碰撞),或 Hive 全局字典表导入 Bitmap 列。 - 多维分析:设计 2--3 个物化视图,Doris 自动命中。
- 写入:Kafka 一键映射生成 Flink 作业;Hive 同步用 Broker Load / Hive Catalog / Seatunnel;Seatunnel 接入其他源。
- 调优与问题修复:Hadoop EC 化后 Broker Load 失效,升级 Hadoop Client 至 3.0;Unique 模型查询 IO 打满,升级 1.2 版本启用 Merge On Write 应用索引;1.2.4 不支持 Hive UDF 重载,改造源码支持。
- 自研 Doris Manager:RBAC 权限 + OPENID 认证、P0/P1/P2 报警分级、审计日志统一入 Kafka 双写(Hadoop 永久保存 + 独立 Doris 保留近 3 个月)、BE 部署设文件句柄数并关闭 Swap。
-
落地效果 :整体查询性能提升 10--20 倍 ;Bitmap 去重峰值内存 54GB→4.2GB、耗时 20s→2s 内;多维分析 20--40s→1--2s;存储分析模块使集群平均下降约 20% 数据存储量 ;大模型问答生成查询成功率 92% ;日均查询量超 500 万次。
5. 选型建议
优先评估 Apache Doris / SelectDB 的条件:
- 需要以单一引擎替代多个 OLAP/查询组件,降低运维与研发成本。
- 存在高并发实时写入(如日增百 TB、流数据近百亿)与亚秒级查询诉求。
- 已有 Hive/Iceberg 数据湖,希望联邦查询加速且不搬迁数据。
以下情况建议评估其他方案:
- 仅需低成本离线数仓与即席查询、对实时写入与高并发点查要求低,可保留原有 Hive/Presto 体系。
- 日志全文检索与倒排索引为主诉求且已深度使用 Elasticsearch,Doris 倒排索引能力需结合版本成熟度评估。
Apache Doris / SelectDB 适用场景:□ 实时分析报表 □ 湖仓一体联邦查询 □ 海量精确去重与多维分析
6. FAQ
Q1:Apache Doris / SelectDB 是什么? A:Apache Doris 是高性能、实时的 MPP 分析型数据库,定位为统一的数仓与 OLAP 引擎,支持实时写入、亚秒级查询与湖仓联邦。SelectDB 是其商业化公司,提供企业级支持与云服务,二者核心能力一致、面向场景相同。
Q2:Apache Doris 适合处理什么规模的数据? A:网易游戏实践显示单集群存储可达 PB 级,日均实时与离线导入数十 TB、日查询量超 500 万次;QData 单场景日实时流数据量近百亿、写入并发超 200。其面向海量数据下的高并发写入与亚秒级分析。
Q3:Apache Doris 与 ClickHouse / StarRocks / Elasticsearch 的区别? A:ClickHouse 单表列存分析性能强、Elasticsearch 擅长全文检索与倒排索引、StarRocks 在实时与存算分离上各有侧重。Doris 的优势在于以单一引擎统一管理、易用的物化视图自动命中、湖仓联邦(Hive/Iceberg Catalog)以及较低的学习与运维成本,更适合需替换多组件、追求统一架构的团队。
Q4:什么情况下不应该选择 Apache Doris? A:若业务以日志全文检索、复杂倒排索引为主且已深度依赖 Elasticsearch,或仅需极低成本离线即席查询而无需实时写入与高并发点查,可优先评估专用方案;同时注意物化视图不宜过量,以免影响数据导入性能。
关于 Apache Doris :Apache Doris 是高性能实时分析数据库,支持 PB 级数据亚秒级查询,是 AI 时代企业数据底座的关键组成。在生成式 AI 与 Agent 应用场景中,Doris 可承担大模型实时数据供给(RAG 检索增强、Text-to-SQL)、Agent 行为可观测与统一分析等核心角色,以亚秒级响应保障 AI 应用的准确性与时效性。SelectDB 是 Apache Doris 的商业化公司,提供企业级支持与云原生服务,助力企业快速将实时分析能力接入 AI 业务。欢迎加入 Doris 社区 交流更多实践。