Doris与实时数仓案例

在当今数据爆炸的时代，实时数据分析和处理能力已成为企业提升竞争力的关键。Apache Doris作为一款高性能、实时的分析型数据库，凭借其卓越的性能和灵活性，在实时数仓建设中扮演着重要角色。本文将深入探讨Doris在实时数仓中的应用案例，并分享如何通过Doris构建高效的数据驱动决策体系。

Doris简介与特点

Apache Doris（原名Apache Palo）是一个基于MPP（Massively Parallel Processing）架构的开源分布式数据库，专为分析型业务场景设计。它支持高并发、低延迟的快速查询，能够处理大规模数据集，提供快速的多维分析和报告生成能力。Doris的主要特点包括：

• 高性能查询：支持高并发和低延迟的快速查询，适合实时分析和业务报表。
• 实时数据导入：支持从Kafka、Hadoop、MySQL等多种数据源实时导入数据。
• 分布式架构：具备水平扩展能力，能够处理大规模数据集。
• 灵活的数据模型：支持多种数据模型和数据类型，满足不同业务场景需求。
• 简单易用：提供友好的操作界面和丰富的功能，便于用户使用和管理。

Doris在实时数仓中的应用案例分享

导读：平安人寿作为保险行业领军企业，坚持技术创新，以数据业务双轮驱动的理念和更加开放的思路来应对不断增长的数据分析和应用需求；以深挖数据价值、保障业务用数效率为目标持续升级大数据产品体系。自 2022 年起平安人寿开始引入开源实时数据仓库 Apache Doris 并基于此统一 OLAP 技术栈，通过统一的数据开发与服务打破了原有系统的数据“孤岛”、降低了需求的开发成本、加速了业务需求的交付周期，并满足了业务方更高数据时效性与查询响应度的要求，最终形成更开放、灵活、可扩展的企业级管理与分析大数据产品体系，实现数据价值的最大化释放，助力企业由“粗放型”业务增长转变为“精细化”效益提升。

保险业务的持续拓展，离不开企业的数字化战略创新。平安人寿秉承“一站式服务”的理念，以数据驱动服务质量，并早在 2005 年已经建立了离线数仓，将业务系统的数据集中存储于 Oracle 中并按业务需求开发数据报表，同时根据寿险的不同业务主题搭建了数据集市，以加快报表生成。

随着大数据时代的到来，传统数据库出现性能瓶颈，基于 Oracle 的数据仓库无法满足海量数据的存储、处理与应用需求，因此在 2016 年平安人寿引入了 Hadoop 建立寿险大数据平台。在近十年的大数据技术探索中，以提升数据质量、加快业务数据分析效率、加速数据价值变现为目标，平安人寿基于大数据平台构建了数据中台并引入数据治理体系，全方位保障业务用数效率、提升数据生产力。在数据应用层引入了多个开源大数据处理和分析组件，结合业务对于分析的实际需求开发了多个数据应用系统，为业务用户分析决策提供支持。

如今，随着数智化时代的到来，数据价值的重要性得到更深度认可，深挖数据价值成为新的目标。在此背景下，平安人寿坚持技术创新，以更加开放的思路来应对不断增长的数据分析和应用需求，升级大数据产品体系正是其中至关重要的一步。

为了进一步提升数据应用效率、降低多组件带来的运维和使用成本，平安人寿自 2022 年起开始引入开源实时数据仓库 Apache Doris，对多个数据应用系统进行了升级，基于 Apache Doris 统一了 OLAP 引擎层技术栈。Apache Doris 的引入为平安人寿大数据产品体系打破了原有系统的数据“孤岛”、统一了数据开发与应用层查询服务，降低了需求的开发成本、加速了业务需求的交付周期，并满足业务方更高数据时效性与查询响应度的要求，最终形成更开放、灵活、可扩展的企业级管理与分析大数据产品体系，实现数据价值的最大化释放。

本文将深入探讨大数据产品体系中应用系统的迭代升级经验，分享平安人寿在数据开发与服务化平台的创新应用实践，并介绍如何基于 Apache Doris 极速分析与融合统一的特性，助力企业运营效率提升、业务决策高效，实现由“粗放型”业务增长转变为“精细化”效益提升，通过以数据驱动的数智化转型，推进保险企业高质量发展。

早期大数据产品体系总览

早期大数据产品体系如上图所示，数据流转过程主要分为离线与实时两条链路：

• 离线数据通过 Sqoop 、ETL 工具接入，借助 MapReduce、Spark 或 Tez 计算引擎对数据进一步处理转化、层层加工，基于 Hive 搭建离线数仓，并分别借助 PostgreSQL、Presto、Druid、HBase、Clickhouse 以及 Kylin 等不同组件支持离线数据查询与检索。
• 实时数据通过 Kafka 消息队列实时写入，借助 Flink 计算处理，并将计算好的指标结果存储于 PostgreSQL 中，与离线数据关联查询支持上游应用层实时分析。

基于实际的分析需求，平安人寿开发了各类数据应用系统以支持不同业务人群进行决策分析，包括面向管理层的报表分析系统、面向总部运营人员的即席查询系统、面向一线业务人用的多维分析系统以及面向总部与分公司营销人员的人群圈选系统。

针对各类应用系统，在分析过程中对 OLAP 性能有不同的要求，具体如下：

• 报表分析系统：管理层需要通过报表全景分析对经营数据进行探查，了解各线业务经营情况，以支持业务洞察、问题定位、趋势预测以及经营全貌概览。当管理者在查看数据时，对于报表产出时效性与查询速度有较高的要求，通常单个报表页面涉及成千上百个指标计算，这时则需要 OLAP 能够支持高并发和低延迟响应，使报表响应时间控制在百毫秒以内。
• 即席查询：总部运营人员需要通过可视化分析直观地展示寿险理赔、核保、保全等数据结果，使运营人员能够更好地理解数据、及时地作出业务决策。在该场景中，实时、灵活地查询数据是业务运营人员最主要的诉求，因此 OLAP 需要满足数据及时更新与快速响应。
• 多维分析系统：一线业务人员结合指标数据进行多维分析，从不同角度来审视业务的衡量指标，以支持更细致的业务数据剖析。该场景是企业内最常见的应用场景，承接了一线业务 90 % 的查询流量，每日数据查询访问量高达数十万，对后台数据计算与前台响应的速度要求较高，且希望能够进行更复杂的指标二次开发。
• 人群圈选系统：总部与分公司营销人员需要通过对客户数据汇总计算后形成寿险用户属性、用户行为、用户消费等维度标签。营销人员借助多个标签找到潜在用户群体，以更精准投放与推广寿险产品。因此，灵活的开发与关联查询标签数据是营销人员最主要的诉求。

早期应用痛点

由于早期架构基于多个 OLAP 组件（包括 Presto 、PostgreSQL、Hive、Kylin、Druid、Clickhouse 以及 HBase）提供计算存储与查询服务，虽然能够满足业务要求，但架构复杂与链路过长势必会增加运维成本、学习成本，同时也无法保障系统之间多源数据的一致性。

更重要的是，随着用户规模的增长与业务场景多样化，数据的写入效率、查询时效性、后台稳定性也逐渐无法得到保证，时常影响业务分析效率。接下来，将详细为大家分析以上业务应用痛点、选型过程以及相应的解决方案，希望为读者带来关于架构升级的新视角。

01 报表分析系统

早期主要基于 Hive 与 PostgreSQL 支持该应用场景，当业务全域数据经过 ETL 清洗处理后，全量存储于 Hive 中。为了满足管理层快速查看报表的需求，开发人员首先会将数据进行多轮处理清洗，并采用预汇总结果的方式，将计算好的指标数据导入 PostgreSQL 中。

虽然这种方式能够应对查询低延迟响应的要求，但指标结果多轮计算会导致数据处理链路过长、各类成本的叠加，例如将数据拆分存储至 14 个 PostgreSQL 库中所造成的存储冗余与资源成本增加、将报表异地聚合与定制化开发所造成的开发成本增加、将 PostgreSQL 与应用端交叉使用所造成的运维成本增加等。

02 即席查询

早期即席查询场景由多个组件共同支持，其中 Hive 负责离线数据分层存储、PostgreSQL 用于存储指标结果数据、Presto 则作为查询引擎对 Hive 中数据查询下压。然而，由于业务查询严重依赖 PostgreSQL 中的指标数据，一旦未提前计算好指标，查询压力将全部交给 Presto，容易造成资源浪费、查询响应延迟等问题。同时，该系统的权限管理不清晰、业务之间没有资源隔离限制，所有业务运营人员均可以查询 Hive 底层中的数据，造成临时表多、查询任务并发过高、资源抢占等问题。

03 多维分析系统

早期该场景利用 Druid 组件提供维度与指标存储查询服务。在业务数据激增的过程中，平台容易出现导数失败或系统故障，Druid 节点重启时常需要 24 小时，系统超长重启时间对业务中断带来了巨大的风险。

同时，Druid 在查询性能中存在一定的局限性，如不支持关联查询、不支持精细去重。在理赔与用户数据 Join 的查询场景下，业务人员只能先将所需数据形成宽表满足查询需求；在面对用户数据精细去重时，只能对 Druid 组件功能改造。这些局限性不仅使查询复杂度增加，也会消耗大量的人力、学习、开发等成本。

04 人群圈选系统

早期该系统借助 HBase 提供标签计算与存储、Clickhouse 与 Kylin 作为人群圈选的查询引擎。 在标签构建过程中，由于 HBase 只能通过主键进行查询，不支持二级索引，无法使用复杂的查询语句和条件进行数据检索，开发人员需要通过主键来设计和实现标签查询，增加开发难度和复杂性。同时，HBase 的扩展能力也存在一定局限性，比如无法处理数字或日期等复杂数据类型、无法展开更细粒度的追踪调用。 在标签查询过程中，当系统面对 200 人的并发查询需求，Clickhouse 时常难以承载，需要借助 Kylin 通过 Cube 预聚合索引来分担查询压力。然而在两个组件共同提供服务时，Clickhouse 与 Kylin 配合灵活度不足成为目前系统最大的痛点之一。以查询 Array 字段为例，Clickhouse 支持 Array 而 Kylin 不支持，涉及到相关字段查询时，非常依赖于后端人工判断数据在哪种数据库中，再发送查询请求给 Clickhouse。除此之外，两个组件皆无法支持多表关联查询，也无法提供灵活的数值区间圈选。

大数据产品体系组件选型与思考

在上述各应用痛点中不难发现，组件过多容易出现数据存储冗余、数据不一致等问题，开发人员也需要来回导数整合组件之间的数据流，加重开发运维成本。并且，组件之间还会加重数据孤岛的现象，使数据之间缺乏关联与共享。基于此，我们希望选出一款综合性强、灵活度高的组件，能够统一 OLAP 技术栈，打通平台之间的数据读取，覆盖日常分析场景需求，实现高效导数与极速分析。除此之外，为了将数据治理更体系化，还希望引入的 OLAP 组件支持指标、标签等维度数据统一计算与存储，借用 API 为上游应用层提供统一查询服务。

在经过调研选型后，如图所示，我们发现 Apache Doris 非常符合升级需求，不仅能够覆盖常规业务场景，满足写查性能需求，同时，基于 Apache Doris 统一技术栈也将大幅度降低架构复杂度，减少运维、开发以及使用成本，最大化提升架构性能。因此，平安人寿基于 Apache Doris 开启了新架构的升级之旅。

大数据产品体系基于 Apache Doris 融合统一的演进之路

在未引入 Apache Doris 之前，大数据产品体系借助不同 OLAP 组件提供数据存储、计算与查询服务。引入 Apache Doris 后，平安人寿以 OLAP 引擎统一为基础，在 Apache Doris 集群之上构建了一体化指标与标签设计平台，形成 “上下经营一张表”，完善经营指标管理体系，并通过 API 接口直通应用层，面向多种场景的统一数据服务。

01 引擎优化：基于 Apache Doris 逐步统一 OLAP 技术栈

目前，平安人寿已使用 Apache Doris 替换了 HBase、PostgreSQL 、Presto 、Druid 组件，统一指标标签计算存储，支持报表分析、即席查询以及多维分析的应用，并已上线了管理层的报表应用系统、总部与一线运营人员的可视化分析系统。同时，平安人寿也已完成 Apache Doris 与各类数据源适配，进一步替换 Clickhouse、Kylin 组件。预计在今年 11 月份，Apache Doris 将上线并应用于营销机构人群圈选系统的生产使用。

通过 Apache Doris 一套系统同时满足数据存储、计算与查询服务，不仅避免了数据多轮计算带来的重复开发与冗余存储问题，更满足了更灵活、更细粒度、更高效的查询分析。平安人寿在应用上线后取得如下收益：

• 降低各类资源成本：借助 Apache Doris 丰富的数据模型，数据无需经过多轮预聚合汇总，能够大幅度简化数据处理流程，降低运维成本的同时释放了原 14 个 PostgreSQL 数据库的资源成本压力。
• 提升开发与查询效率：统一指标与标签数据开发在降本的同时更加速了业务交付时间，开发周期由原来的两周缩短至一天，效率提升 14 倍。在引入 Apache Doris 后，借助 Doris 设置了查询层级权限，使业务人员只可访问数据 ADS 层中的数据，解决数仓各表交叉使用的问题，提升指标数据复用率与使用效率；借助 Doris 优异的高并发性能满足了报表分析与多维分析场景下的秒级毫秒级的查询响应需求，查询提速达 5-10 倍。
• 打破数据孤岛，实现闭环管理：在统一技术栈的优势下，Apache Doris 打破了各类应用系统数据孤岛的现象，为业务人员提供了更全面的数据、更细粒度的维度查询，实现精细化的查询分析、一致的业务洞察视角、闭环式的数据管理，使企业上下更精准地掌握寿险经营走向。

02 语义与服务层优化：基于 Apache Doris 统一指标和标签服务

当统一了 OLAP 技术栈后，平安人寿进一步引入统一语义层，将复杂查询语句进行拆解转化，简化加速 SQL 语句执行效率，并借助数据服务 API 接入的方式，连接各业务应用层。

借助这种方式，平安人寿全域数据从采集接入后进入 Doris 数仓，业务人员在后台通过拖拽实现指标标签数据自助定义和自动计算，生成的 SQL 会发送至 Doris ADS 层中。其中，若涉及复杂的多表关联查询，SQL 语句会在语义层中过滤，生成简单的执行语句。借助通用的 API 服务，调用 Doris 库中数据，统一支持业务分析在客户经营、代理人、保单、产品、理赔等方面的需求。目前，平安人寿基于统一服务化平台已支持日均数百万次的数据调用，每张报表的查询响应时间实现 200 - 300 ms ，实现多场景下极速、统一的数据服务。

至此，平安人寿从数据设计直通数据服务，有效避免业务之间冗余开发与重复使用，缩短业务交付周期，加速查询响应时间。基于高内聚低耦合的统一服务平台，使查询分析能够及时配合业务需求变更，确保了企业内外数据流转的流畅性。

Doris与实时数仓案例分享2：

导读：随着网易游戏品类及产品的快速发展，游戏数据分析场景面临着越来越多的挑战，为了保证系统性能和 SLA，要求引入新的组件来解决特定业务场景问题。为此，网易游戏引入 Apache Doris 构建了全新的湖仓一体架构。经过不断地扩张，目前已发展至十余集群、为内部上百个项目提供了稳定可靠的数据服务、日均查询量数百万次，整体查询性能得到 10-20 倍提升。

网易游戏数据与平台服务部旨在通过数据科技为网易旗下众多游戏提供运营及决策支持，是推动游戏商业成功、品质提升以及渠道优化的重要支撑。近年来，随着网易游戏品类及产品的快速增加，数据规模呈爆炸性增长，每日新增数据达百 TB 级别，不仅需要对玩家基本行为指标（活跃度、付费情况、用户新增等）进行分析，还需深入游戏内部复杂数据，对譬如游戏行为、游戏性能等详细信息进行分析。面对如此大规模的数据增长，如何高效实时的提供数据支持成为必须面对的一大挑战。

为了满足各大业务场景对实时分析时效性的要求，同时保证数据快速写入和极速查询，网易游戏数据与平台服务部亟需一个合适的 OLAP 引擎补充原有的离线数仓架构体系。经过大量的产品调研，Apache Doris 与网易游戏技术中心的整体要求高度契合。因此在 2021 年引入了 Apache Doris，并经过不断地发展，目前已发展至十余集群，为内部上百个项目提供稳定可靠的服务。

本文将分享网易游戏在选型数据仓库架构升级过程中的思考以及基于 Apache Doris 构建湖仓一体全新架构的解决方案，并分享 Apache Doris 在关键业务场景中的落地实践。此外，本文也将分享网易游戏在 Apache Doris 集群运维上的建设及管理经验，以供读者思考或借鉴。

早期架构及挑战

早期数据架构如上图所示，数据主要来源于业务数据库、游戏日志及接口数据，通过实时与离线两条链路对数据进行加工。在查询入口层面，我们自研了统一查询引擎 SmartSQL，可基于 RBO、CBO 和 HBO 实现对 Trino、Spark 和 Hive 的智能查询路由。如果用户想要进一步加速查询，数据将通过 ETL 计算成结果数据写入至 HBase 中供点查访问。此外，日志数据还将额外写入一份至 Elasticsearch 中，为日志分析场景提供数据支持。

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

• 运维成本高：涉及组件较多，包括 Apache Hive、Spark、Trino、HBase、Elasticsearch 等，运维复杂度相对较高，需要投入较多的人力。
• 研发成本高：过多的组件也带来较高的研发成本。面对新增的需求，不仅要开发 Spark、Trino 作业，也要开发 HBase 作业，这要求分析师理解并学习不同组件的使用方法及数据模型，研发成本及难度较高、开发流程长。
• 数据时效性差：该架构数据处理链路长，需要经过多次流转，时效性和查询效率均无法满足业务需求。

为了应对早期架构的局限性和挑战，我们在选择新的 OLAP 解决方案时，重点考虑了以下几个核心需求：

• 具备简洁的架构设计，能够满足多种业务场景的同时降低系统组件的复杂度，进而降低运维成本、提高系统的稳定性。
• 提供统一易用的能力，可由单一组件替代之前架构中的多个组件，降低用户的学习和使用成本，提高研发效率。
• 具备实时高效的数据处理能力，能够支持实时数据的高并发写入和亚秒级查询响应，满足业务对高时效性的要求。同时希望新引擎符合实时数仓及湖仓一体发展趋势。

基于以上需求，经过深入评估，我们最终选择了 Apache Doris 作为 OLAP 解决方案，以下是具体的选型依据：

基于 Apache Doris 构建全新的湖仓一体架构

随着 Apache Doris 湖仓一体的能力日趋成熟，我们基于 Apache Doris 构建了全新的湖仓一体架构，并针对不同应用场景设计了不同的数据解决方案：

• 数仓分层存储： 将数据实时写入 Apache Doris 中，所有热数据的查询均在 Apache Doris 数据仓库中进行，根据 TTL 策略将热数据转冷至数据湖中；
• 数据湖查询加速： 将 ODS 层数据写入数据湖中，DWD、DWS、ADS 层则存储在 Apache Doris 中。上层数据应用在执行查询时，对于高 QPS 和低延迟要求的 SQL 直接走 Doris 内表，明细数据则通过 Apache Doris 提供的 Hive Catalog 以及 Iceberg Catalog 查询湖中数据，同时还可通过外表物化视图将外部数据经过物化视图写入内表。

全新的湖仓一体架构充分结合了仓和湖的能力，实现存储和查询的统一，并基于 Apache Doris 物化视图等能力可以进一步简化数据建模加工、实现数据湖查询加速等能力。

Apache Doris 在网易游戏质量保障中心场景下的应用

QData 是网易游戏质量保障中心下属的大数据团队，团队职责是从质量角度出发，针对游戏产品生命周期中的支付、奖励、性能、登录等主题，为游戏提供实时监控、离线分析、报表等服务，以提升游戏性能、优化设备表现。

该业务场景的特点以及对 OLAP 引擎选型时的要求如下：

• 日实时流数据量近百亿，写入作业并发数超 200，要求 OLAP 引擎能够支持高并发写入；
• 在某些分析场景下，需要用到 Hive 历史数据，要求支持从 Hive 中快速同步大量历史数据；
• 需要完整支持行为分析类型的函数，且要求 P95 指标查询不超过 3s；
• 日常会有变更字段和更新数据的需求，要求引擎支持数据更新且不影响正常写入和查询；

而这些需求与 Doris 功能特性十分契合，因此数据与平台服务部与 QData配合将 QData 的数仓从其他引擎迁移到了 Doris 中。

全新数仓架构如上图所示，我们将 Doris 数仓分为 ODS、DWD、DWS 层：

• 对于超大表，ODS 层数据仍然保存在 Hive 中，进一步 ETL 之后再将聚合后的数据导入到 Doris 中实现查询加速。
• 对于规模适中的表，Kafka 数据直接导入 Doris 中，通过仓内 ETL 和物化视图的方式实现数据聚合、查询加速。

01 Bitmap 查询提速

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

如果直接使用COUNT(DISTINCT)往往会占用大量内存和 IO，并且查询时间 >20s，特别是当表中有大量不同的值时，查询性能受到的影响更大，无法满足性能要求，因此我们提供以下两种方式进行优化：

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

针对不同的使用场景，我们可选择不同 Bitmap 优化方案。优化后，在 14 亿数据的场景下，Bitmap 查询峰值所占用的 Doris 内存 从 54GB 下降到了 4.2GB，查询时间从 20 秒下降到了 2 秒以内，提升效果颇为显著。

02 物化视图提速查询

游戏性能是玩家游戏时最直观的体验，良好的性能可以确保游戏流畅度、响应速度和画面质量。性能问题可能导致卡顿、延迟或崩溃，严重影响玩家满意度和游戏口碑和留存。因此需要对玩家游戏时的性能数据进行进行监控和分析。

衡量游戏性能相关的数据指标有很多，例如：FPS、卡顿次数、内存峰值等 8 种，单一指标相关的维度多达 10 余 个。而游戏策划等部门希望在网页端可针对多种指标和多个维度进行自定义聚合查询，查询响应时延需要控制在 2s 内。

对于该需求，我们可以基于常用的数据维度设计物化视图，来满足用户绝大部分自定义聚合查询的需求。 Doris 的一大优势在于能够自动识别并匹配最优物化视图进行查询，因此建议可设计 2-3 个物化视图，过多的物化视图可能会对数据导入速度造成影响。相较于之前基于 Presto 进行多维分析时查询耗时长达 20-40 秒的情况，使用 Doris 后的查询时间已经提速至 1-2 秒。这不仅提升了用户体验，也为数据分析工作带来了极大的便利和效率。

03 多种写入方式配置式作业生成

在数据写入方面，考虑到不同业务方的写入方式不同，我们在部门层面提供了多样化的写入方式。对于 Kafka 流，提供了一键映射 Doris 表的功能实现快速开发 Flink 作业；对于离线 Hive 数据的同步，提供了 Broker Load、Hive Catalog、Seatunnel 三种方式写入；对于其他数据源数据的同步，基于 Seatunnel 可实现各类型数据源的集成写入。

04 基于自研大模型问答和拖拽式生成查询

我们研发了大模型问答系统，提供基于大模型问答的查询模式和拖拽式生成查询。用户可以通过自然问答的方式便捷地生成 Doris SQL 查询语句，也可通过界面化拖拽式操作生成 SQL 查询语句，并迅速获取到 SQL 执行结果以及对应的图表显示。在大模型生成查询方面，成功率高达 92%。同时，为了满足不同用户的需求和习惯，我们仍然支持用户通过 JDBC 接口对接自己的报表系统，旨在为用户提供更灵活、高效的数据查询体验。

05 QData 场景下的问题整理

在 QData Doris 集群的使用过程中，我们遇到了一些问题，借此机会将这些问题及其相应的解决方案整理如下，以供大家参考。

• Hadoop 上的数据经过一段时间会被 EC 化处理、节约存储成本，但 EC 化后的数据无法通过 Broker Load 导入，因此将 Broker Load 依赖的 Hadoop Client 版本升级至 3.0，解决了部分冲突、实现正常导入。
• 用户在查询 TB 级大表分区时，在完成分区过滤的情况下，仍会出现 IO 打满情况，这是因为使用 Unique 模型查询的时候，进行了两次聚合操作，第一次是把数据进行 Compaction，第二次才实际用到过滤条件。临时的解决办法是跟用户沟通是否可以修改模型，根本的解决方法是升级集群版本，借助 1.2 版本的 Merge On Write 特性，使得查询能够应用索引。
• 在 1.2.4 版本中， 用户把 Java UDF Hive UDF 迁移到 Doris 中后发现 Doris 不支持 Hive UDF 的重载，所以我们把源码做了改造，使其能够支持 Hive UDF 的重载。

大规模集群的运维管理

自网易互娱内部引入 Apache Doris 后，经过两年多的发展，集群已形成了非常可观的规模：

• 总集群十余个，国内/海外均有布局，总节点数达上百个；
• 内部项目对接数达到上百个，日均查询量超过 500 万；
• 最大单集群存储数据总量达到 PB 级，日均通过实时作业以及离线导入的数据量达到数十 TB。

面对如此庞大的集群规模，如何高效管理成为重点关注的问题。以下是我们对于 Apache Doris 集群管理运维的思考：

• 基础建设：在确定 Apache Doris 选型后，首先需要制定部署规范、运维规范；其次需做好业务接入规范，提前与业务沟通、明确不同业务场景下适用的机型规格；同时需完善各类基准测试，建设完备的元数据元信息，以确保提供标准统一、性能可靠的数据服务。
• 监控报警：首先需梳理集群监控的分级指标，将 Doris 报警级别分为 P0、P1、P2 三个等级，并根据不同的等级设定报警规则和升级机制，部分指标提供用户侧的报警功能。然后统一监控入口，设定好监控大屏，能够通过大屏快速获取到所有集群节点的状态信息（可基于官方提供的 Prometheus 模板迭代建设）。
• 安全性的保障：制定备份规范、及时进行数据备份，进行周期性故障演练，确保出现故障时能够稳定快速的恢复。不仅如此，还需要配置集群巡检规则、巡检机器环境，如 Doris BE 部署时要求设置文件句柄数、关闭 Swap 等，确保机器环境处于健康状态。
• 平台化及可视化：将上述规范平台化、可视化，通过自动化工具和脚本进行集群运维管理，避免人工操作失误带来的风险。同时平台还可为业务方提供数据报表、分析和审计等功能，帮助业务方了解集群状况及发展趋势。

01 自研 Doris Manager 系统

基于上述集群运维目标及方向思考，我们内部自研了一套 Doris Manager 系统，实现对 Doris 集群的可视化管理，架构图如下：

基础服务层的 Galaxy 和 Aladdin 都是网易游戏内部的系统， Galaxy 是内部配置管理中心，Aladdin 是流程管理平台，这两个平台结合可以实现集群运维部署的标准化。以 Doris 集群服务注册启动的流程为例，第一步启动 FE Master，第二步注册 FE FOLLOWER，第三步启动 FE FOLLOWER，第四步注册 BE，第五步启动 BE，这些固定的步骤可以在 Aladdin 平台创建为流程。当 Aladdin 将上述流程定义好之后，通过接口形式提供给 Doris Manager 调用，进而实现集群一键部署和扩缩容等运维操作。

• 在平台安全方面：在认证上，使用了内部的 OPENID 打通内部权限，基于 RBAC 的权限模型能够较好的划分权限层级，区分不同角色的平台视角。在审计追踪上，记录管理平台上发生的任何行为，便于追踪操作历史；
• 在集群服务功能方面：针对用户最关心的内容设计了集群状态、综合功能、查询导入这几个模块，帮助用户监控集群状态、分析各类资源的使用情况；
• 在集群运维方面：设计了集群部署及托管、进程守护、数据备份、服务扩缩容等功能，以确保集群的稳定运行及高效管理；
• 在用户接入方面：通过 Gateway 网关实现白名单管控，通过负载均衡实现服务的高可用。

02 Doris Manager 数据流转

Doris Manager 平台的各类分析模块主要有以下 5 个数据来源：

• Doris 审计日志：虽然官方提供的 Audio Log 插件，可以将审计日志写回到相应的 Doris 集群，但这种方式不便管理多集群场景。因此，我们将所有集群的审计日志统一采集到 Kafka 中（考虑到不同版本 Doris 的审计日志格式存在差异，因此进入 Kafka 流后，将对审计日志标准化处理，确保从多个 Doris 版本采集到的审计日志指标统一），然后对清洗后的审计日志进行双写，其一接入 Hadoop 集群，满足内部对审计日志永久保存的需求，其二接入独立的 Doris 集群，该集群将保留近 3 个月审计日志，以供 Doris Manager 进行用量分析、成本计算，并满足用户查看历史 Query 的需求。
• FE/BE 日志：日志是观测性的重要指标之一，由于早期的 Doris 版本没有倒排索引功能，因此我们将 FE/BE 日志采集到 Elasticsearch 中，通过在 Doris Manager 平台调用 Elasticsearch 提供的接口，实现问题日志的快速检索。同时借助 Elasticsearch 配置集群日志级别的报警，比如 WARN 日志阈值报警、 Error 日志报警、关键字报警等。
• Cluster API 数据：Doris 提供了丰富的 API，Doris Manager 可通过调用集群 API 获取到各种类型的信息，并将所需信息参与到模块计算中。需要注意的是，某些 API 会随着 Doris 的迭代发生变化，因此多个 Doris 版本间的接口兼容也是引入新版本时要着重测试的地方。
• Fe Meta：在 information_schema 库下存放了大量的元数据信息，可以直接获取库、表、分区等各类信息。
• 集群 Metrics：Metrics 最直接体现集群运行的健康度等信息、FE/BE Metrics 是分析集群状态最佳的数据来源。

将这些数据采集到 Doris Manager 之后，我们通过内部规则、行业规范、配置约束和集群现状等现状设计了一系列分析模块，获取到分析结论可供管理员和用户进行查询分析、存储分析以及成本计算等行为。

集群服务状态管理的设计实现

为帮助用户侧掌控集群各类运行状态，减少管理侧的运维人力成本，我们主要聚焦存储、导入和查询这三方面进行模块设计，设计目标如下：

• 查询：帮助用户全方位了解集群查询情况，提速查询。
• 导入：帮助用户掌控实时和离线导入的数据增量情况，导入问题报错辅助排查，减少人力运维。
• 存储：帮助用户减少冗余存储，节约存储成本，减轻元数据管理压力。

01 查询分析模块

集群查询消耗的总资源和各用户消耗的资源都需要量化，以便开展用量预警、性能分析等工作。因此我们设计了 “查询概览” 模块，该模块主要有以下几个功能，帮助用户从全局概览上了解集群的查询性能变化情况。

• 支持查看集群近 3 个月各指标的走势，包括数量、Cputime、Memory、P 系列指标；
• 统计集群内各用户消耗查询资源占比；
• 以表格的形式精确展示指标详情，所有统计指标支持导出下载。

Doris 对于 Running Query 的可观测支持度还在逐步完善中，而在某些场景下用户需要了解实时 Running Query 的情况，便于 Kill 误提交或者不合理的大查询。因此 Doris Manager 设计了 “当前查询” 的模块，可自动刷新并获取当前运行的查询数量，帮助用户查看正在运行的 SQL。

慢查询治理对集群安全运行至关重要，不仅能及时释放数据库资源、降低安全风险，还能提高 SQL 质量和可维护性、提升用户的使用体验。为了帮助用户感知集群的慢查询，Doris Manager 设计了 “查询分析” 模块，支持按库/按时间查看慢查询汇总分布、查看慢查询在时间轴上的分布，同时支持按照查询时间、查询语句、查询用户、Catalog 和阈值等维度来查看并导出慢查询信息，以便更好的管理和优化数据库性能。

在执行计划上，Doris Manager 提供了两种展示形式，一种是图形化的、比较直观，另一种是文字类型的，帮助用户初步快速地定位慢查询问题。每条慢查询记录后均设有便捷的操作按钮，用户只需点击即可直接查看查询计划，从而对查询速度慢的原因进行初步分析，无需再繁琐地切换终端去执行EXPLAIN等语句。

对于一些无法通过执行计划来定位的慢 SQL，官方提供了 Profile 功能，因此 Doris Manager 对其功能进行了集成—— “Profile 管理” 模块。假设发现 Scan Node 耗时过长，很可能是 Bucket 参数设置不当所致，基于这些 Profile 信息，平台侧将提供针对性的诊断与优化建议，方便用户调整并优化查询性能。

在日常稳定使用集群服务时，用户可能不会频繁登录平台关注查询情况，这可能会使用户忽视掉某些查询 SQL 速度的下降。因此 Doris Manager 开发了 “查询报表” 模块，可在每日上班前推送查询报表，该报表包含前一日的慢查询分布、明细数据以及各项查询指标值，通过该方式及时让业务洞察上一日的查询情况、做出相应的优化调整。

02 导入分析模块

在导入方面，Doris Manager 同样也设计了 “导入概览” 模块，并将实时和离线的导入数据分开统计，让管理员和用户更清晰了解各类型导入指标的走势，辅助用户评估导入规模的变化。而对于导入具体的指标，则可以进入到 “集群监控” 页面查看指标分钟级别的走势。

在导入报错指南上，Doris Manager 设计了 “报错分析” 模块用于分析报错返回的 URL， 这是因为如 Flink Doris Connector、Seatunnel、Spark Load 等写入方式底层都是通过 Stream Load 写入数据。当发生错误时，Doris 将返回一个报错 URL，但由于公司内部网络隔离，相关端口并未对用户开启，因此用户无法访问报错链接，而且某些报错内容对于刚接触 Doris 的用户理解起来较困难，因此我们基于 Stream Load 源码梳理了日常常见的报错信息，并整理到 Doris Manager 中形成知识库，作为智能诊断的支撑。

03 存储分析模块

当用户的集群投入运行一段时间后，表数量和数据量通常会持续增长，直到迫切需要治理，而用户往往难以准确判断哪些数据表仍具有使用价值。因此 Doris Manager 通过解析用户的查询语句，设计了 “热度分析” 模块。在页面左上角通过计算汇总的每个库、每张表的热度信息来给集群打分，帮助用户直观地了解集群数据使用率。右上角则按照库维度按照利用率评分升序展示信息，帮助用户确认存储治理的优先级。

页面的下方则可以按照库、表、分区粒度展示和导出对应粒度下资源的创建、时间、更新时间、表数据量、表行数、Tablet 数、最近 7 天/15 天/30 天的读热度、以及最后的查询时间信息。该模块帮助所有集群平均下降约 20% 的数据存储量。

Tablet 是 Doris 中的重要概念，是数据移动、复制等操作的最小物理存储单元。因此 Tablet 治理一直是 Doris 运维人员需要重点关注的内容。如果不规范设置 Bucket 数会带来较严重的负面问题，影响集群的整体性能和稳定性。具体来说不规范分为两种情况，一种是 Tablet 设置得过多，一种是 Tablet 设置得过少。

当 Tablet 数量过多时，主要分为三种情况：

• 可删除表：通过向用户提供表热度信息，帮助用户判断可删除的表；
• 非分区表：采用重删重插的方式，通过优化表的存储结构，进而减少 Bucket 的数量；
• 分区表：
  • 动态分区：当 Bucket 出现异常时，借鉴 Doris Auto Bucket 思维，结合历史数据进行分析和拟合，计算出最理想的 Bucket 数量，基于此来修改动态分区值。如果空分区过多时，可以提醒用户调整参数，减少预创建分区数；
  • 静态分区：只能根据每个分区的推荐值来重建分区。

当 Tablet 数量过少时，与过多时的治理方式一致，区别仅为增大 Bucket 值。

虽然我们在业务接入阶段会给用户同步建表规范，但是仍然无法杜绝不遵守规范的行为，而用户也无法感知当前集群 Tablet 的分布是否合理，管理员给集群业务方提出修改要求后，业务方也不知道用哪种方式去处理。因此 Doris Manager 结合上述治理思路开发了 “Tablet 分析” 模块，该模块会按库、按表、按分区展示 Tablet 实际值和预期值，对于存在差异的行，提供了“点击进入优化”的按钮，按钮背后的逻辑则是治理规则的应用。首先给用户展示基础信息，并评估等级，等级取决于预期值和实际值的差异，分为紧急、严重、提醒、健康四类，然后提供表热度走势图，辅助用户判断这张表是否还在被使用中，最后是将优化方案及所需详细的操作步骤和相关 SQL 展示给用户，帮助用户快速完成 Tablet 的治理。

结束语

自网易游戏内部最初引入 Apache Doris 至今， 已建成十余个集群、为内部上百个项目提供稳定可靠的服务、日均查询量数百万次，Apache Doris 已成为网易游戏内部数据服务体系中不可或缺的一部分。

后续我们也将继续跟随社区版本迭代节奏，截至发文前，Apache Doris 2.1 系列版本已经逐步稳定，该版本推出许多重磅功能是我们非常关注的，后续我们也会将工作重点聚焦于以下几方面：

• 存算分离： 期望引入更廉价的存储介质，同时希望在数据湖场景下更灵活的进行弹性部署。
• 倒排索引： 鉴于内部使用 Elasticsearch 的用户对倒排索引比较感兴趣，且 Apache Doris 倒排索引的能力已趋于成熟，后续将尽快测试并应用。
• 资源隔离：新版本的内置调度功能和 Workload Group 能更好地简化架构和隔离资源，我们希望在业务场景上使用进而完善湖仓融合方案。
• 完善 Doris Manager：我们希望 Doris manager 能够提供 On K8S 小实例部署模式，降低用户在专属集群需求上的接入门槛。另外计划建设 Doris manager 对新版本特性的管理支持，比如推出跨集群数据同步等功能。

总结与未来规划

一站式数据门户是平安人寿大数据产品体系自始至终的构建目标，基于 Apache Doris 统一 OLAP 多个技术栈，并将标签与指标标准化开发与管理，共同提供统一的数据服务，使业务分析师能够进行自助式的数据探查，减少对技术人员的依赖，同时，通过方便快捷地访问、分析和可视化各种数据资源，实现数据高效、低成本的交付。

未来，平安人寿将进一步拓展 Apache Doris 湖仓一体化的应用，使用 Doris 替换 Presto 进行数据湖查询分析，让数据和计算在湖与仓之间自由流动。同时，还将引入 Apache Doris 多租户和资源隔离方案，完善应用系统间负载均衡性能，避免导数过程中出现任务并发高、CPU 内存占用大、查询性能受阻的风险，减少多用户数据操作时在同一集群内被干扰，将集群资源更合理的分配给各个应用系统。

最后，非常感谢飞轮科技团队一直以来对平安人寿的技术支持，加速平安人寿数智化转型进程。至此，各级业务人员能够加速数据分析效率，帮助企业及时发现和解决问题，从而提升运营效率；管理层能够通过海量数据洞察市场趋势、客户需求以驱动业务决策。

平安人寿将持续推动保险行业转型进程，带来更多业务机会与产品创新，也将持续参与 Apache Doris 的社区建设，将相关成果贡献回馈社区，实现价值共享！

Doris在实时数仓中的优势与挑战

优势

1. 高性能查询：Doris支持高并发和低延迟的快速查询，满足实时分析和业务报表的需求。
2. 实时数据导入：支持从多种数据源实时导入数据，保证数据的时效性和准确性。
3. 分布式架构：具备水平扩展能力，能够处理大规模数据集，满足企业不断增长的数据需求。
4. 灵活的数据模型：支持多种数据模型和数据类型，满足不同业务场景的需求。

挑战

1. 数据一致性：在实时数仓中，如何保证数据的一致性是一个重要挑战。Doris通过两阶段提交（2PC）和Flink CheckPoint机制来保证数据的一致性。
2. 资源消耗：实时数据处理需要消耗大量的计算资源和存储资源。如何优化资源使用，降低成本，是企业在实施实时数仓时需要考虑的问题。
3. 运维管理：随着数据量的增加和业务场景的复杂化，实时数仓的运维管理难度也会增加。企业需要建立完善的运维管理体系，确保系统的稳定性和可靠性。

结论

Apache Doris凭借其高性能、实时性、灵活性和易用性，在实时数仓建设中展现出了强大的优势。通过案例分享，我们可以看到Doris在广告点击数据分析、用户行为分析、外卖业务数据统计等多个场景中均取得了显著成效。未来，随着大数据和人工智能技术的不断发展，Doris将在更多领域发挥重要作用，为企业构建高效的数据驱动决策体系提供有力支持。

希望本文能够为关注Doris与实时数仓的读者提供有价值的参考和启示，助力企业在数据驱动的道路上走得更远、更稳。