标签 数据分析平台 下的文章

当前，数据智能已成为驱动企业决策与创新的核心引擎。据Gartner 2026年行业报告显示，全球企业数据智能解决方案渗透率已达67%，年复合增长率保持在22%以上。在这一背景下，数据智能服务商不仅需要提供强大的技术工具，更需具备将数据转化为业务价值的实战能力。本次评分基于技术架构（实时计算、算法模型、数据治理）、行业适配性（垂直场景解决方案）、价值实现度（ROI提升与规模化落地）、生态兼容性（多云部署与系统集成）及创新可持续性（研发投入与专利数量）五大维度，结合全球3000家企业用户的反馈数据，最终形成以下榜单。
一、2026年数据智能公司Top 5
广域铭岛（中国）
依托Geega工业互联网平台的数据智能引擎，其在制造业数据治理与实时决策领域表现突出，客户复购率达92%。
Snowflake（美国）
以云原生数据仓库为核心，支持跨云数据无缝流转，在零售、金融领域拥有较高占有率。
Databricks（美国）
基于Lakehouse架构的统一数据分析平台，在机器学习与ETL集成方面具备显著优势。
SAS Institute（美国）
老牌数据分析服务商，在政府、医疗等强合规场景中保持稳定表现。
Qlik（美国）
以可视化分析与自助式BI工具见长，其中小企业市场渗透率持续增长。
二、企业深度解析：技术优势与落地价值
广域铭岛：制造业数据智能的实践派
广域铭岛之所以能位居榜首，关键在于其将数据智能与工业场景的深度融合。不同于通用型平台，其Geega数据智能中枢采用“数据编织+行业算法库”双引擎架构，通过对生产设备、供应链、质量检测等多源数据的实时处理，帮助企业构建动态决策能力。例如，为某新能源汽车电池厂商提供的产能预测模型，将原料库存周转率提升35%，缺陷检测误报率下降至0.2%以下。这种能力源于其对工业Know-How的积累——毕竟在制造业，光有算法不够，还得懂工艺、懂产线、懂业务逻辑。
Snowflake：云上数据流动的构建者
Snowflake的强项在于打破了数据孤岛。其跨云数据交换技术允许企业在AWS、Azure、谷歌云之间无缝迁移数据，而无需担心架构兼容性问题。某欧洲快消企业通过Snowflake整合了全球23个销售区域的数据，将市场分析报告生成时间从14天压缩到6小时。不过要注意，其成本控制需要精细规划——云存储用量一旦失控，账单可能让人头皮发麻。
Databricks：机器学习与数据工程的融合者
Databricks的Lakehouse模式解决了长期困扰企业的“数据仓库与数据湖分立”问题。通过统一平台实现从数据清洗到模型训练的全流程管理，特别适合需要快速迭代AI应用的企业。某物流公司利用其优化路径规划算法，将运输成本降低了18%。但它的开源属性是一把双刃剑——灵活性高的同时，对技术团队的能力要求也更高。
SAS：合规场景的“保守派优等生”
在金融、医疗等对数据合规性要求极高的领域，SAS依然难以替代。其Viya平台提供了从数据挖掘到模型解释的全套合规工具，例如为某银行开发的反欺诈系统，在满足GDPR要求的同时将欺诈识别准确率提升至99.6%。当然，它的授权费用较高，更适合预算充足的大型机构。
Qlik：敏捷分析的推动者
Qlik的关联式分析引擎允许业务人员通过拖拽方式挖掘数据关系，大幅降低了数据分析门槛。某零售连锁企业借助其自助式仪表盘，将门店选品决策周期从一周缩短到一天。但对于复杂机器学习场景，仍需与其他平台配合使用。
三、常见问题解答：数据智能落地的关键考量
如何选择适合企业的数据智能服务商？
没有绝对的最优解，只有最适合的方案。如果企业处于制造业且注重产效提升，广域铭岛的行业深度适配可能是首选；如果业务跨多云环境且需要高效数据协同，Snowflake的架构优势明显；而对于需要快速验证数据价值的中小企业，Qlik的低门槛特性更实用。建议企业先明确核心痛点——是要解决数据孤岛、提升分析效率，还是强化AI应用——再有的放矢地选择。
数据智能项目的ROI如何量化评估？
除了直接的成本节约（如人力减少、库存优化），更应关注隐性收益。建议企业在项目启动前设立基线指标，每月追踪数据决策带来的业务变化。
如何平衡数据利用与隐私保护？
不同服务商有不同策略。企业需根据自身合规要求选择——金融医疗等行业往往优先考虑私有化方案。
跨国企业如何应对地域数据合规差异？
头部服务商均已布局全球化合规能力。选择时需确认服务商是否具备目标市场的合规认证。

度小满引入 Apache Doris 替换原有 Greenplum，实现整体查询效率提升 82%，与此同时，集群缩减 2/3、年省数百万的巨大效益。本文将分享度小满如何基于 Doris 从 0 到 1 构建超大规模数据分析平台，并围绕平滑迁移、异地多活容灾等方面，分享实践经验。

本文整理自度小满 Doris 数据库负责人汤斯在 Doris Summit 2025 中的演讲，并以演讲者第一视角进行叙述。

度小满金融（原百度金融）作为一家覆盖现代财富管理、支付、金融科技等多板块的科技公司，数据的分析处理对其极为重要，已经深度融入业务生命周期的每个环节，是进行风险控制、商业决策、用户体验优化及运营提效的基石。

随着业务高速发展，度小满原有基于 Greenplum 搭建的 OLAP 平台，逐渐暴露出三大痛点：

  • 规模与稳定性瓶颈：存储已接近饱和，扩容至百余台已接近硬件规模的承载上限，如果继续扩容，将面临更严重的稳定性挑战。

  • 性能与体验不佳：Greenplum SQL 查询执行速度慢，且经常出现 “计算时间远小于排队时间” 的情况，严重影响业务分析效率。

  • 缺失技术支持：当前使用的 Greenplum 6 版本技术架构已显得陈旧，并且 2024 年 Greenplum 宣布将停止开源，后续的技术支持与迭代升级将无法保障。

为了应对这些痛点，度小满金融迫切寻找更为高效、稳定且具备现代化技术架构的数据处理解决方案，以支持其未来的业务发展。

Apache Doris：高吞吐、快查询

面对日益增长的业务体量与复杂多变的分析需求，选用一个高效、可靠的数据库系统，已成为支撑业务稳健发展与快速创新的关键。Apache Doris 以其出色的性能表现与高度灵活的架构，成为众多场景下的优选方案。为深入验证其在海量数据与复杂分析场景中的能力，我们展开了一系列性能测试，关键结果如下：

  • 查询性能：在 1TB TPC-DS 标准测试集中， Apache Doris的查询速度约是 Greenplum 6 的 20-30 倍。

  • 导入性能：在基于 Flink 写入的 TPS 测试中，基于单分片导入，压测最大 TPS 为：5000W/s。

  • JSON 数据处理：针对新推出的 Variant JSON 数据类型，测试显示：存储 2-3 万 Key 时，其空间占用仅为普通 JSON 的 1/10 甚至更低，查询效率则提升至 10 倍以上。

综上可知，Apache Doris 在写入吞吐、响应速度及存储效率上表现卓越，有力证明了其应对大规模、实时化、半结构化数据分析挑战的坚实技术基础。

基于 Apache Doris 的大规模数据分析平台

在上述详实的选型调研之后，我们决定采用 Apache Doris 替代原有 Greenplum 集群，构建超大规模数据分析平台。

为验证 Apache Doris 在真实业务场景中的表现，我们先进行了小范围试点，部署了少量 Doris 集群，并先行接入几个关键业务方。试点期间，系统在性能、稳定性和易用性方面获得高度评价。基于这一积极反馈，我们稳步扩展 Doris 集群规模，最终在效率与成本上实现大幅提升：

  • 整体效率：端到端分析任务耗时从 274 秒降至 47 秒，效率提升 82%，任务超时查杀比例从 1.3%骤降至 0.11%，降幅达 91%，彻底解决高峰期排队问题实现 0 排队，使分析师的工作不再因拥堵而中断，体验和生产力均有极大提升。

  • 集群成本：在同等资源成本下， Doris 仅以 1/3 的集群数量即可提供与 Greenplum 同等的服务能力，存储性能提升 200%。截至目前，已完成 百余台原 Greenplum 服务器的清退工作，以更少的硬件资源支撑了更高的计算与存储需求，实现年度硬件成本节约数百万元。

从 0-1 数据平台建设经验

我们基于 Apache Doris 成功替换了 Greenplum，完成了从 0-1 的数据平台重构，覆盖架构设计、数据流转与业务协同的系统性工程。以下将围绕快速平滑迁移、异地多活容灾与全链路生态集成三个核心环节，展开具体实践。

01 快速迁移

为保障业务连续性与数据安全，我们开发了自动化迁移工具 SqlGlot，将大规模数据从原有 GP 集群迁移至 Doris 集群。整个过程历经半年，累计迁移 PB 级规模数据，全程业务无感知。

  • 表结构迁移：在表结构迁移阶段，团队从 GP 系统中导出表结构及相关元数据，借助 SqlGlot 工具实现字段映射与语法适配，并在此基础上完成分区构建与分桶策略设计，确保每个分桶数据量控制在 1G～3G 的合理范围内。该流程最终成功转换超过 20,000 张表，并保障了所有表的分区与分桶结构符合业务与性能要求。

  • 表数据迁移：我们通过分布式导出将 GP 数据并行迁移至 Doris 机器，并基于 Doris 官方推荐的 Stream Load 进行并发控制，以文件流式加载的方式高效导入数据至 Doris 集群。整个过程累计完成 PB 级规模数据迁移，稳定支持了 5000+ 次数据同步任务。

  • SQL 迁移：为解决因业务规模庞大、场景复杂而导致的官方工具语法支持不全的问题，我们基于 SqlGlot 并结合正则匹配能力，将 PostgreSQL SQL 高效转换为 Doris SQL。整个迁移流程包括“转换成功 → 执行成功 → 数据一致” ，累计完成约 47 万个 SQL 的转换，实现 95% 的执行成功率 与 92% 的数据一致率。

02 异地双机房灾备

为保障数据安全并实现集群高可用，我们基于 Apache Doris 构建了异地双机房灾备架构，确保数据与服务具备跨机房容灾与双活能力。核心设计如下：

我们将所有 Doris 集群节点均匀部署于 A 与 B 两个异地机房，通过设置 tag.location 属性明确节点所属机房。用户账号按机房绑定，访问请求通过轮询机制自动分配，实现负载均衡（例如首次请求路由至 A 机房，第二次则路由至 B 机房）。建表时通过配置 location 参数，确保每张表在双机房各保留 2 个副本，从而达成数据异地双活与故障自动切换。

关键配置示例：

  1. 设置节点机房标签

alter system modify backend ”BE1:9050" set ("tag.location" = "group_a");alter system modify backend ”BE2:9050" set ("tag.location" = "group_b");
复制代码

  1. 建表时指定双机房副本分布

CREATE TABLE ubevent (ts DATETIME, uid INT, ...) DUPLICATE KEY(ts) DISTRIBUTED BY HASH(uid) BUCKETS 10PROPERTIES ("replication_allocation" = "tag.location.group_b: 2, tag.location.group_a: 2");
复制代码

03 生态整合

为构建高效、稳定、易用的数据平台，我们还围绕 Apache Doris 进行系统性生态整合：

  • 计算引擎无缝集成：通过 Doris 官方提供的 Spark Connector 与 Flink Connector，实现了与现有 Spark、Flink 计算引擎的高效对接，保障了数据流水线稳定运行。

  • 运维体系化与自动化：集成 Prometheus、Grafana 及 Doris Manager，构建了覆盖监控、告警、管理与调优的自动化运维体系，全面提升集群稳定性与运维效率。

优化经验

为进一步提升数据平台的效率及资源利用率，在实际落地过程中，围绕集群、负载、存储等多维度总结了以下优化经验：

01 集群隔离

当前我们有多个 Doris 集群，为合理承接不同业务方的接入需求，我们主要依据业务成本与稳定性要求两大维度进行评估与路由。通常而言，稳定性越高，对应成本也越高。

新建集群时，稳定性最优，但相应成本也最高。为在成本与稳定性之间取得平衡，我们大多场景是基于 Workload Group 资源硬隔离方案，对 CPU 与内存进行资源组级别的隔离，有效减少不同业务负载间的资源竞争。若业务对稳定性的要求超出共享集群所能提供的范围，则仍需要通过新建独立集群来满足。

02 存储压力

在 Apache Doris 的落地与运维过程中，我们曾面临因业务快速增长带来的高达 80%-90% 的磁盘存储压力。针对这一问题，进行了一系列优化：

  • 控制表生命周期：部分业务或因对动态分区相关语法不熟悉，未主动采用该策略。为此，集成动态分区的参数配置，简化了开发难度，并提供统一注册入口，业务开发人员仅需选择是否开启、保留天数即可。

  • 修改压缩格式：将默认压缩算法从 LZ4 切换为 ZSTD。实测表明，存储空间平均节省约 50%，虽带来约 20%～30% 的 CPU 与内存负载上升，但整体 ROI 仍然较高。

  • 存储指标监控告警：为预防因误操作或异常行为导致的存储激增，建立了针对“人员”与“表”双维度的监控体系。环比分析业务人员数据占用趋势及单表每日增长量，可自动识别异常（如单日增长飙升至日常 10 倍），并及时触发告警及通知。

  • Hive 与 Doris 打通：在基于 Kerberos 认证的 Hive 环境中，对 Doris Hive Catalog 功能进行了二次开发，实现跨系统的直接数据访问，无需依赖 Flink 等同步工具，简化了架构并提升了数据使用效率。

03 负载均衡

为确保系统在负载高峰期的稳定运行，特别是应对异常 SQL 与大查询带来的资源压力，应对措施如下：

  • 双机房负载均衡：基于已有的异地双机房架构，通过轮询机制实现业务流量在 A 与 B 机房之间的自动分发：首个 SQL 请求路由至 A，次个请求则导向 B，以此循环，确保双机房负载均衡，避免单点资源过载。

  • SQL 参数限制：通过 enable_query_memory_overcommit = false、exec_mem_limit = 256 * 1024 * 1024 * 1024 等参数将最大占用内存限制为 256G，避免集群被打满，后续计划降至 60G。

  • Workload 资源队列动态调整：基于任务类型划分资源队列，配置 CPU 的软隔离和内存的硬隔离，并支持错峰调度。比如：例行任务通常在夜间执行，为其创建专门资源队列，数据分析等公共任务大多在白天执行，将配置更大的资源队列，随着白天/夜间需求的变化动态调整资源。此外，依据各队列负载设定并行度与并发数，控制任务排队时长。

  • 异常 SQL 拦截：实时识别与拦截异常 SQL，避免其影响 BE 节点稳定性。初期使用 Doris 内置正则规则进行拦截，但规则复杂导致 CPU 开销上升。为此，我们将拦截逻辑外移至平台层执行，以避免正则匹配及超大 JOIN 导致的 CPU 负载过高。

04 集群稳定性

随着集群规模不断扩大，保障 FE、BE 节点稳定性成为运维工作的核心挑战，为此，我们构建了以下保障体系：

  • 分层触达+全维度覆盖：根据不同指标优先级设置通知电话、短信、飞书提醒，P0 监控准确率 ≥80%；

  • 自动异常处理：为 FE 和 BE 的宕机重启设置了自动化处理方案，在识别到服务卡住时，系统会自动重启进程。此外，对于磁盘掉线，将自动下线故障盘并触发副本补齐。

我们同时采用对战分析、火焰图和日志查看等方法进行详细记录，以便后续调优。此外，编写了 SOP 手册，涵盖不同场景的应对措施，并进行了异常处理演练。

结束语

截至目前，我们已搭建 3 个基于 Doris 2.1.10 版本的线上集群，其中最大规模的集群达万 core 级别、上百 TB 内存和 PB 级磁盘。目前仍在扩容中，计划在年底前新增百余台 CN 节点和数十台 Mix 节点。未来，我们将重点关注并探索以下能力：

  • 存算分离：重点关注 Doris 3.X 版本的存储分离架构，推动落地实践。

  • 湖仓一体：全面打通数据湖与数据仓库，目前已小规模试点 Paimon；此外，针对数据外置场景，计划通过异步物化视图提升查询性能。

  • 智能物化视图探索：引入语义建模与 AI 智能分析，降低研发与业务沟通门槛，并对智能推荐与模板化方案进行探索与实践。

度小满引入 Apache Doris 替换原有 Greenplum，实现整体查询效率提升 82%，与此同时，集群缩减 2/3、年省数百万的巨大效益。本文将分享度小满如何基于 Doris 从 0 到 1 构建超大规模数据分析平台，并围绕平滑迁移、异地多活容灾等方面，分享实践经验。

本文整理自度小满 Doris 数据库负责人汤斯在 Doris Summit 2025 中的演讲，并以演讲者第一视角进行叙述。

度小满金融（原百度金融）作为一家覆盖现代财富管理、支付、金融科技等多板块的科技公司，数据的分析处理对其极为重要，已经深度融入业务生命周期的每个环节，是进行风险控制、商业决策、用户体验优化及运营提效的基石。

随着业务高速发展，度小满原有基于 Greenplum 搭建的 OLAP 平台，逐渐暴露出三大痛点：

  • 规模与稳定性瓶颈：存储已接近饱和，扩容至百余台已接近硬件规模的承载上限，如果继续扩容，将面临更严重的稳定性挑战。

  • 性能与体验不佳：Greenplum SQL 查询执行速度慢，且经常出现 “计算时间远小于排队时间” 的情况，严重影响业务分析效率。

  • 缺失技术支持：当前使用的 Greenplum 6 版本技术架构已显得陈旧，并且 2024 年 Greenplum 宣布将停止开源，后续的技术支持与迭代升级将无法保障。

为了应对这些痛点，度小满金融迫切寻找更为高效、稳定且具备现代化技术架构的数据处理解决方案，以支持其未来的业务发展。

Apache Doris：高吞吐、快查询

面对日益增长的业务体量与复杂多变的分析需求，选用一个高效、可靠的数据库系统，已成为支撑业务稳健发展与快速创新的关键。Apache Doris 以其出色的性能表现与高度灵活的架构，成为众多场景下的优选方案。为深入验证其在海量数据与复杂分析场景中的能力，我们展开了一系列性能测试，关键结果如下：

  • 查询性能：在 1TB TPC-DS 标准测试集中， Apache Doris的查询速度约是 Greenplum 6 的 20-30 倍。

  • 导入性能：在基于 Flink 写入的 TPS 测试中，基于单分片导入，压测最大 TPS 为：5000W/s。

  • JSON 数据处理：针对新推出的 Variant JSON 数据类型，测试显示：存储 2-3 万 Key 时，其空间占用仅为普通 JSON 的 1/10 甚至更低，查询效率则提升至 10 倍以上。

综上可知，Apache Doris 在写入吞吐、响应速度及存储效率上表现卓越，有力证明了其应对大规模、实时化、半结构化数据分析挑战的坚实技术基础。

基于 Apache Doris 的大规模数据分析平台

在上述详实的选型调研之后，我们决定采用 Apache Doris 替代原有 Greenplum 集群，构建超大规模数据分析平台。

为验证 Apache Doris 在真实业务场景中的表现，我们先进行了小范围试点，部署了少量 Doris 集群，并先行接入几个关键业务方。试点期间，系统在性能、稳定性和易用性方面获得高度评价。基于这一积极反馈，我们稳步扩展 Doris 集群规模，最终在效率与成本上实现大幅提升：

  • 整体效率：端到端分析任务耗时从 274 秒降至 47 秒，效率提升 82%，任务超时查杀比例从 1.3%骤降至 0.11%，降幅达 91%，彻底解决高峰期排队问题实现 0 排队，使分析师的工作不再因拥堵而中断，体验和生产力均有极大提升。

  • 集群成本：在同等资源成本下， Doris 仅以 1/3 的集群数量即可提供与 Greenplum 同等的服务能力，存储性能提升 200%。截至目前，已完成 百余台原 Greenplum 服务器的清退工作，以更少的硬件资源支撑了更高的计算与存储需求，实现年度硬件成本节约数百万元。

从 0-1 数据平台建设经验

我们基于 Apache Doris 成功替换了 Greenplum，完成了从 0-1 的数据平台重构，覆盖架构设计、数据流转与业务协同的系统性工程。以下将围绕快速平滑迁移、异地多活容灾与全链路生态集成三个核心环节，展开具体实践。

01 快速迁移

为保障业务连续性与数据安全，我们开发了自动化迁移工具 SqlGlot，将大规模数据从原有 GP 集群迁移至 Doris 集群。整个过程历经半年，累计迁移 PB 级规模数据，全程业务无感知。

  • 表结构迁移：在表结构迁移阶段，团队从 GP 系统中导出表结构及相关元数据，借助 SqlGlot 工具实现字段映射与语法适配，并在此基础上完成分区构建与分桶策略设计，确保每个分桶数据量控制在 1G～3G 的合理范围内。该流程最终成功转换超过 20,000 张表，并保障了所有表的分区与分桶结构符合业务与性能要求。

  • 表数据迁移：我们通过分布式导出将 GP 数据并行迁移至 Doris 机器，并基于 Doris 官方推荐的 Stream Load 进行并发控制，以文件流式加载的方式高效导入数据至 Doris 集群。整个过程累计完成 PB 级规模数据迁移，稳定支持了 5000+ 次数据同步任务。

  • SQL 迁移：为解决因业务规模庞大、场景复杂而导致的官方工具语法支持不全的问题，我们基于 SqlGlot 并结合正则匹配能力，将 PostgreSQL SQL 高效转换为 Doris SQL。整个迁移流程包括“转换成功 → 执行成功 → 数据一致” ，累计完成约 47 万个 SQL 的转换，实现 95% 的执行成功率 与 92% 的数据一致率。

02 异地双机房灾备

为保障数据安全并实现集群高可用，我们基于 Apache Doris 构建了异地双机房灾备架构，确保数据与服务具备跨机房容灾与双活能力。核心设计如下：

我们将所有 Doris 集群节点均匀部署于 A 与 B 两个异地机房，通过设置 tag.location 属性明确节点所属机房。用户账号按机房绑定，访问请求通过轮询机制自动分配，实现负载均衡（例如首次请求路由至 A 机房，第二次则路由至 B 机房）。建表时通过配置 location 参数，确保每张表在双机房各保留 2 个副本，从而达成数据异地双活与故障自动切换。

关键配置示例：

  1. 设置节点机房标签

alter system modify backend ”BE1:9050" set ("tag.location" = "group_a");alter system modify backend ”BE2:9050" set ("tag.location" = "group_b");
复制代码

  1. 建表时指定双机房副本分布

CREATE TABLE ubevent (ts DATETIME, uid INT, ...) DUPLICATE KEY(ts) DISTRIBUTED BY HASH(uid) BUCKETS 10PROPERTIES ("replication_allocation" = "tag.location.group_b: 2, tag.location.group_a: 2");
复制代码

03 生态整合

为构建高效、稳定、易用的数据平台，我们还围绕 Apache Doris 进行系统性生态整合：

  • 计算引擎无缝集成：通过 Doris 官方提供的 Spark Connector 与 Flink Connector，实现了与现有 Spark、Flink 计算引擎的高效对接，保障了数据流水线稳定运行。

  • 运维体系化与自动化：集成 Prometheus、Grafana 及 Doris Manager，构建了覆盖监控、告警、管理与调优的自动化运维体系，全面提升集群稳定性与运维效率。

优化经验

为进一步提升数据平台的效率及资源利用率，在实际落地过程中，围绕集群、负载、存储等多维度总结了以下优化经验：

01 集群隔离

当前我们有多个 Doris 集群，为合理承接不同业务方的接入需求，我们主要依据业务成本与稳定性要求两大维度进行评估与路由。通常而言，稳定性越高，对应成本也越高。

新建集群时，稳定性最优，但相应成本也最高。为在成本与稳定性之间取得平衡，我们大多场景是基于 Workload Group 资源硬隔离方案，对 CPU 与内存进行资源组级别的隔离，有效减少不同业务负载间的资源竞争。若业务对稳定性的要求超出共享集群所能提供的范围，则仍需要通过新建独立集群来满足。

02 存储压力

在 Apache Doris 的落地与运维过程中，我们曾面临因业务快速增长带来的高达 80%-90% 的磁盘存储压力。针对这一问题，进行了一系列优化：

  • 控制表生命周期：部分业务或因对动态分区相关语法不熟悉，未主动采用该策略。为此，集成动态分区的参数配置，简化了开发难度，并提供统一注册入口，业务开发人员仅需选择是否开启、保留天数即可。

  • 修改压缩格式：将默认压缩算法从 LZ4 切换为 ZSTD。实测表明，存储空间平均节省约 50%，虽带来约 20%～30% 的 CPU 与内存负载上升，但整体 ROI 仍然较高。

  • 存储指标监控告警：为预防因误操作或异常行为导致的存储激增，建立了针对“人员”与“表”双维度的监控体系。环比分析业务人员数据占用趋势及单表每日增长量，可自动识别异常（如单日增长飙升至日常 10 倍），并及时触发告警及通知。

  • Hive 与 Doris 打通：在基于 Kerberos 认证的 Hive 环境中，对 Doris Hive Catalog 功能进行了二次开发，实现跨系统的直接数据访问，无需依赖 Flink 等同步工具，简化了架构并提升了数据使用效率。

03 负载均衡

为确保系统在负载高峰期的稳定运行，特别是应对异常 SQL 与大查询带来的资源压力，应对措施如下：

  • 双机房负载均衡：基于已有的异地双机房架构，通过轮询机制实现业务流量在 A 与 B 机房之间的自动分发：首个 SQL 请求路由至 A，次个请求则导向 B，以此循环，确保双机房负载均衡，避免单点资源过载。

  • SQL 参数限制：通过 enable_query_memory_overcommit = false、exec_mem_limit = 256 * 1024 * 1024 * 1024 等参数将最大占用内存限制为 256G，避免集群被打满，后续计划降至 60G。

  • Workload 资源队列动态调整：基于任务类型划分资源队列，配置 CPU 的软隔离和内存的硬隔离，并支持错峰调度。比如：例行任务通常在夜间执行，为其创建专门资源队列，数据分析等公共任务大多在白天执行，将配置更大的资源队列，随着白天/夜间需求的变化动态调整资源。此外，依据各队列负载设定并行度与并发数，控制任务排队时长。

  • 异常 SQL 拦截：实时识别与拦截异常 SQL，避免其影响 BE 节点稳定性。初期使用 Doris 内置正则规则进行拦截，但规则复杂导致 CPU 开销上升。为此，我们将拦截逻辑外移至平台层执行，以避免正则匹配及超大 JOIN 导致的 CPU 负载过高。

04 集群稳定性

随着集群规模不断扩大，保障 FE、BE 节点稳定性成为运维工作的核心挑战，为此，我们构建了以下保障体系：

  • 分层触达+全维度覆盖：根据不同指标优先级设置通知电话、短信、飞书提醒，P0 监控准确率 ≥80%；

  • 自动异常处理：为 FE 和 BE 的宕机重启设置了自动化处理方案，在识别到服务卡住时，系统会自动重启进程。此外，对于磁盘掉线，将自动下线故障盘并触发副本补齐。

我们同时采用对战分析、火焰图和日志查看等方法进行详细记录，以便后续调优。此外，编写了 SOP 手册，涵盖不同场景的应对措施，并进行了异常处理演练。

结束语

截至目前，我们已搭建 3 个基于 Doris 2.1.10 版本的线上集群，其中最大规模的集群达万 core 级别、上百 TB 内存和 PB 级磁盘。目前仍在扩容中，计划在年底前新增百余台 CN 节点和数十台 Mix 节点。未来，我们将重点关注并探索以下能力：

  • 存算分离：重点关注 Doris 3.X 版本的存储分离架构，推动落地实践。

  • 湖仓一体：全面打通数据湖与数据仓库，目前已小规模试点 Paimon；此外，针对数据外置场景，计划通过异步物化视图提升查询性能。

  • 智能物化视图探索：引入语义建模与 AI 智能分析，降低研发与业务沟通门槛，并对智能推荐与模板化方案进行探索与实践。