导读：网易游戏引入 Apache Doris 升级架构，先是替换 Elasticsearch、Hbase、Clickhouse 构建了实时数仓，而后基于 Apache Doris 和 Iceberg 构建了湖仓融合架构，实现架构的大幅简化及统一。目前，网易游戏 Apache Doris 集群超 20 个 ，总节点数百个，已对接内部 200+ 项目，日均查询量超过 1500 万，总存储数据量 PB 级别。

正文：

近年来，随着网易游戏品类和产品的快速增加，数据规模呈现爆炸性增长，日均新增数据可达百 TB 级别。面对如此庞大的数据增长，如何高效、实时地提供数据分析成为一项重要挑战。网易游戏技术中心效能研发部的重点工作围绕数据、人工智能和安全展开，旨在通过数据和 AI 为公司众多游戏提供运营及决策支持，同时保护网易所有与游戏相关的产品、服务和资源的安全。这是推动游戏商业成功、品质提升以及渠道优化的重要支撑。

网易游戏早期数据平台是由 Hive、Spark、Trino、ElasticSearch、HBase、ClickHouse 多种技术栈组成，存在查询性能低、实时性不足、运维及研发成本高等问题。为此，引入 Apache Doris 进行架构升级，最初用 Doris 替换了 Elasticsearch、Hbase、Clickhouse，构建了实时数仓 ；随后基于 Apache Doris 和 Iceberg 构建了湖仓融合 的架构，实现了数据架构的简化，数据的时效性和查询性能大幅提升。网易游戏 Apache Doris 集群超 20 个 ，总节点数百个，已对接内部 200+ 项目，日均查询量超过 1500 万，总存储数据量 PB 级别。

早期架构及痛点

在早期架构中，大部分查询请求通过离线数据仓库（Hive）以及多种查询引擎（如 Hive、Spark 和 Trino）完成，而针对时效性要求更高的实时查询分析，则由 Elasticsearch、HBase 和 ClickHouse 提供支持。

这一架构在使用过程中暴露出了许多问题：

• 数据时效性差：该架构数据处理链路长，需要经过多次流转，时效性对实时分析业务满足比较吃力。
• 查询性能不优：依赖 Hive、Spark、Trino 等查询引擎的效率不够高；HBase、Elasticsearch、ClickHouse 对复杂查询支持非常有限。
• 运维成本高：涉及组件较多，包括 Hive、Spark、Trino、HBase、Elasticsearch、ClickHouse 等，运维复杂度相对较高，需要投入较多的人力。
• 研发成本高：过多的组件也带来较高的研发成本。面对新增的需求，不仅要开发 Spark、Trino 作业，也要开发 HBase 作业以及 ElasticSearch 的 DSL，这要求分析师理解并学习不同组件的使用方法及数据模型，研发成本及难度较高、开发流程长。

因此，网易游戏亟需一种具备简洁架构设计的引擎，既能支持业务对高时效性的要求，又希望其能够替代早期架构中多技术栈，顺应湖仓一体发展趋势。而 Apache Doris 作为网易内部应用最为广泛的 OLAP 引擎之一，随着近些年在湖仓一体方面的深耕，自然成为我们的首要选择。

阶段 1 - 基于 Apache Doris 构建实时数仓

最初引入 Doris 时，离线数据仓库的链路保持不变，同时基于 Doris 构建了实时数据仓库，成功替代了原架构中的 Elasticsearch 、HBase、ClickHouse。

具体而言，实时采集的数据可以直接落入 Doris，实现秒级可见性。此外，离线数据也可以通过 Broker Load 或 SeaTunnel 导入 Doris，以加速关联查询。该方案有效提升了许多业务场景的响应速度，并且大大简化了架构。

阶段 2 - 基于 Doris 构建高效易用的湖仓一体架构

随着 Apache Doris LakeHouse 能力完善，网易游戏自 Apache Doris 2.1 版本发版，对架构进一步升级，以 Apache Doris 为核心构建高效易用的湖仓一体架构。

其主要变化在于，在阶段 1 的基础上进一步替换了 Hive、Spark、Trino 等查询引擎，整合了离线数仓和实时数仓，升级为数据湖上统一的数据仓库。全新的湖仓一体架构充分结合了仓和湖的能力，实现存储和查询的统一，并基于 Apache Doris 物化视图等能力可以进一步简化数据建模加工、实现数据湖查询加速等能力。

结合内部自研的统一的查询引擎 SmartSQL，我们设计了两种湖仓融合方案，分别是湖上建仓和湖仓融合。这两种方案在实际场景中都有使用，不同的业务根据关注点选择不同的方案。

SmartSQL：实现多个引擎之间的智能路由，使用户能够专注于业务开发。为实现智能路由，进行了大量工作，包括多引擎语法兼容、查询优化以提升作业效率和降低成本、统一权限管理与行列加密，以及在复杂场景下提供统一接入方案。目前，我们也在借助大模型的能力，积极提升 SmartSQL 的智能水平。

3.1 湖上建仓

在湖上建仓方案中，数据流仍然保持之前的链路，统一写到 Hive、Iceberg 等数据湖中，然后在 Doris 中建立一些查询加速层，通过 Doris 外部表的物化视图功能，定期将数据从 Hive 、Iceberg 同步到 Doris 中。

当用户执行查询时，SmartSQL 会解析查询是否命中物化视图。如果命中，查询将直接走 Doris 内表，速度最快；如果未命中，则可以使用 Doris Catalog 查询数据湖；对于一些超大 ETL 作业还可以进一步降级到先前的引擎组，以确保查询的最终成功。

3.2 湖仓融合

在湖仓融合方案中，数据优先进入 Apache Doris，在 Doris 进行 ETL 加工处理，查询也基于 Doris 进行，数据进入的时效性和分析性能极好，特别适合实时分析为主的场景。Doris 中数据变冷后，利用 Doris 提供的数据湖写回功能，再将冷数据写回到 Iceberg 中，进行数据的统一入湖管理。

3.3 融合工作

3.3.1 SQL 兼容

在湖仓融合架构中，SQL 兼容性至关重要，这样能够更轻松地将现有的分析工具和业务逻辑迁移到新的数据架构中。不仅提高了用户的使用体验，还降低了培训和迁移的成本，使数据分析人员能够快速上手，直接利用他们熟悉的工具进行分析。而 Doris 在兼容性上表现优异：

• Hive UDF 兼容：Doris 在 SQL 兼容性方面表现卓越，其设计目标是兼容 Hive UDF。因此，在迁移通用 UDF 和业务 UDF 时，只需进行极少的修改。
• SQL Convert 语法兼容：对于某些用户而言，他们的 SQL 语法可能与 Doris 不兼容。可以利用社区提供的 SQL 转换工具来处理用户的一些旧查询。目前，Doris 支持 Presto/Trino、Hive、PostgreSQL 和 Clickhouse 等常见查询引擎的 SQL 方言转换，在实际用户场景中，兼容率可达到 99%以上。

3.3.2 资源隔离

Doris 现已能够覆盖大部分 Trino 的场景。网易游戏内部使用 Trino 时，设定了许多限制参数，以避免单个用户的大查询占用过多资源，因此这些限制参数与 Doris 的兼容性至关重要。

我们注意到社区提供了 Workload Group，并经过测试发现，所有 Trino 的限制参数均可兼容，甚至在某些硬性资源隔离方面表现更优。此处列举了一些替代方法，有相同想法的读者可以参考。

3.4.3 弹性计算资源利用

社区提供了完整的 Doris on K8s 方案以实现弹性节点，但考虑到网易游戏自建的 Hadoop 集群，以及该集群典型的潮汐现象------白天资源利用率较低，而凌晨资源消耗较高，为了充分利用计算资源，决定将弹性计算资源启动在 YARN 上。

YARN 上的启动是利用了 Apache Slider 组件，该组件预定义了一套创建、启动和销毁的流程，从而简化了在 YARN 上的部署过程。我们的弹性节点也部署在 YARN 上。如果要实现多种 YARN，所需的资源准备相对简单，仅需准备相关的启动脚本，并实现 Slider 的启动和销毁方法，即可快速部署 Doris。

基于 Apache Doris 的应用场景

4.1 大宽表场景

在大宽表场景中，采用 Doris 替代 Clickhouse，并在问卷业务和 CDN 业务中应用。虽然 Doris 和 Clickhouse 性能相当，但 Doris 的系统维护更加简便，降低了运维人员的技术门槛，减少了因运维复杂性带来的潜在风险，相比之下，Clickhouse 的运维难度较高，要求团队具备更深入的技术知识和经验。

4.2 用户行为分析

主要应用于点击行为、付费事件跟踪和用户画像等场景。依赖 Doris 在 Bitmap 位图索引上优异的性能和丰富的 Bitmap 函数支持，大大提升了这类场景的分析效率。我们以玩家 UV 统计的应用场景举例：

游戏产品会在版本发布当天公告更新及优化信息。为精准监控游戏运营的各个环节、为玩家提供良好的游戏体验，数据团队需监控玩家打开游戏时，从 Patch（游戏补丁）更新到最后登录过程中转化情况，量化各环节的转化数据。这就要求对玩家设备 ID 进行精确去重，而去重的数据量高达 10 亿级别。

针对不同的使用场景，可选择不同 Bitmap 优化方案。

• 方式一：首先在 Hive 中构建玩家设备 ID 全局字典表，接着将该表导入到 Doris 表对应的 Bitmap 列；
• 方式二：针对明细表创建物化视图，通过 bitmap_hash64 函数将字符串转化为 Bitmap 类型。使用 bitmap_hash64 而不使用 bitmap_hash的原因是bitmap_hash在数据量大于 2000 万时碰撞较为严重，导致结果不准确。

优化后，在 14 亿数据的场景下，Bitmap 查询峰值所占用的 Doris 内存从 54GB 下降到了 4.2GB，查询时间从 20 秒下降到了 2 秒以内，提升效果颇为显著。

4.3 统一 SQL 引擎

Doris 可以作为统一 SQL 查询引擎，可连接不同数据源进行联邦分析，当前已实现 Doris、MySQL、Hive 和 Iceberg 等数据源的联邦查询。这种能力使得用户能够在不同的数据存储和处理系统之间无缝地进行数据整合和分析。

Doris 自带联邦查询模块，高效处理跨数据源查询，有效替代了 Presto/Trino 的应用场景，提供了更为优越的性能。实验证明，Doris 的查询速度优于 Presto 2-3 倍。

4.4 AI ChatBI 执行引擎

凭借 Doris 的极速查询性能，将其应用于大模型相关业务。首先，Doris 被用作 ChatBI 的最终执行引擎。其次，将所有元数据存储在 Doris 中，并在 SmartSQL 中构建了多个智能体。当用户根据需求提交问题时，可以在多维组中检索相关数据，以补充智能体，实现 SQL 预估、SQL 改写、SQL 智能优化及报错智能诊断等一系列功能。

未来规划

目前，网易游戏拥有超过 20 个 Doris 集群，总节点数达数百个，已对接内部 200 多个项目，日均查询量超过 1500 万，总存储数据量在 PB 级别。未来，还将基于 Doris 在以下几方面发力：

• 数据湖解决方案推广：基于 Apache Doris 的数据湖解决方案将在更多业务部门和场景中推广，助力用户降本提效。
• 实现智能物化：物化视图是加速数据湖查询的重要利器，未来的重点工作是基于用户作业对热点 SQL 片段进行物化。
• 3.0 版本升级： 3.0 版本采用云原生的存算分离全新架构，为数据湖场景提供了更多业务模式的可能性，未来将探索并升级该版本。
• 内部 Manager 建设： 内部 Doris Manager 将支持 2.1 及 3.0 版本新特性，尤其是对用户最关心的功能迭代与开发。

如果你对 Apache Doris 湖仓一体化建设感兴趣，可以加入社区。