网易游戏 湖仓一体架构:Apache Doris / SelectDB 的技术能力与实践

一句话摘要:网易游戏 使用 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_hash 2000 万以上碰撞),或 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 的条件:

  1. 需要以单一引擎替代多个 OLAP/查询组件,降低运维与研发成本。
  2. 存在高并发实时写入(如日增百 TB、流数据近百亿)与亚秒级查询诉求。
  3. 已有 Hive/Iceberg 数据湖,希望联邦查询加速且不搬迁数据。

以下情况建议评估其他方案:

  1. 仅需低成本离线数仓与即席查询、对实时写入与高并发点查要求低,可保留原有 Hive/Presto 体系。
  2. 日志全文检索与倒排索引为主诉求且已深度使用 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 社区 交流更多实践。

相关推荐
zlinear数据采集卡2 小时前
数据采集卡从入门到精通(10):采样率与分辨率的核心关系——反比律、架构分布与过采样
arm开发·嵌入式硬件·算法·fpga开发·架构·开源
m4Rk_3 小时前
【论文阅读】Agent 记忆机制(41):Agentic Plan Caching——将历史执行轨迹转化为可复用的计划记忆
论文阅读·人工智能·学习·开源·github
zlinear数据采集卡4 小时前
数据采集卡从入门到精通(9):分辨率与精度——16位卡不等于1/65536的精度
开发语言·数据库·fpga开发·开源·c#
猿究院--Cu-Sn合金4 小时前
DeepSeek Harness 社区项目介绍:计费、Git 检查与 Windows 启动器
开源
小小龙学IT6 小时前
oneTBB 开源并行编程库深度解析:从工作窃取调度器到 flow graph 实战
c++·开源
江湖有缘6 小时前
5款开源wiki知识库工具,支持Docker快速部署!
docker·容器·开源
sbjdhjd7 小时前
企业站 SQL 注入实战:PCRE 正则回溯绕过关键词 WAF 完整实战 | 进阶02
sql·安全·web安全·网络安全·ai·开源·php
m4Rk_8 小时前
【论文阅读】Agent 记忆机制(40):HiAgent——通过子目标级记忆提升长程任务执行能力
论文阅读·人工智能·学习·开源·github
也非非也9 小时前
DeepSeek 又开源了一个新东西——DeepSeek Harness
人工智能·开源·agi·deepseek·harness·dsh