标签 集群架构 下的文章

小T导读:作为国内领先的智能办公整体方案提供商,成都极企科技有限公司已为全球上万家企业提供智能化建设方案,覆盖办公楼宇与园区面积已超百万平米。为应对日益增长的物联网数据接入需求,极企科技引入 TDengine TSDB 时序数据库,实现海量设备数据的实时采集、高效存储与智能分析,显著提升了设备监控系统的响应速度与数据处理能力。本文将分享这一智慧楼宇解决方案基于 TDengine的应用经验与实践成果。

背景和痛点

我们的智慧楼宇解决方案主要面向集团总部、新建办公大楼、政府园区等行业头部客户。这类客户普遍具备完善的 IT 基础与多年的办公系统建设经验,正处于从传统办公向智能化、数字化升级的关键阶段。在这一过程中,他们对智能化办公、物联网和数字化管理有较高的认知与明确的建设需求,期望通过新一代技术手段实现办公环境的智能协同与运营效率的全面提升。

在某大厦智能化项目中,共有 30 层楼宇,部署近万台传感器设备,涵盖人体感应、空气质量、厕位、烟雾、电量、水浸等多种类型。所有传感器均以秒级频率上报数据,日均数据量高达数千万条,对系统的数据采集与处理能力提出了极高要求。

该项目面临设备数据高频采集、多维度实时分析(设备状态、能耗、故障预测)以及历史数据长期存储三大挑战。传统关系型数据库在此类场景中存在明显不足,如写入性能瓶颈、查询延迟高、存储成本激增等问题。以 MySQL 和 PostgreSQL 为例,在存储设备时序数据时,由于缺乏原生的时间分区支持,当单表数据量超过千万级后,查询性能会出现断崖式下降,需人工分表分库,运维复杂度激增。同时,未压缩的原始数据占用空间庞大,存储成本高昂。

为什么选择 TDengine TSDB

在智慧楼宇项目的建设过程中,数据接入规模大、处理链路复杂、系统稳定性要求高,对底层数据库的性能与可靠性提出了极高要求。经过多方技术选型与验证,我们最终选择了 TDengine TSDB 作为核心时序数据库,主要基于以下考虑:

  • 高效数据接入能力:支持 MQTT 数据写入方式,可通过低代码方式快速接入业务平台,实现高并发数据写入,确保近万台传感器上报数据的完整与可靠。
  • 强大的流式计算能力:具备实时数据聚合与分析能力,能够对上报的时序元数据进行整合并高效供给业务平台,同时通过多副本机制保障数据高效写入与可靠备份。
  • 完善的技术支持体系:提供一对一、7×24 小时技术支持服务,确保项目在开发、部署及运维阶段的稳定运行。
  • 国产化与生态兼容性:作为 100% 自主可控的时序数据库,TDengine TSDB 符合信创标准,并已与华为云、麒麟软件等生态厂商完成深度集成,满足极企科技在国产化替代中的技术选型需求。
  • 领先的综合性能与可拓展性:在同类型数据库中,TDengine TSDB 在数据压缩率、写入速度、分析效率及分布式架构等方面表现突出,后续版本还将持续增强易用性与 AI 能力,支持更多的功能和场景,助力企业进一步提升应用效果。

TDengine TSDB 落地实践

架构描述

系统采用 Node-Red 作为数据流控制与可视化管理核心,实现全链路的数据采集、处理与展示。整体架构如下:

  1. 各类传感器采集的数据首先由 Node-Red 进行预处理后写入 EMQ 消息中间件;
  2. TDengine TSDB 通过 taosX 模块从 EMQ 中高效读取并存储数据,实现时序数据的集中管理;
  3. EMQ 再通过 Restful / WebSocket 接口从 TDengine TSDB 获取所需数据,为上层业务应用与可视化系统提供实时访问能力。

智能应用场景示例

  • 当指定区域内连续 5 分钟无人时,系统自动关闭照明;
  • 当某项监测指标超过设定阈值时,自动触发告警并记录相关信息;
  • 当检测到某区域无人时,系统自动关闭空调以节约能源。

项目初期采用 3 节点集群架构,数据库配置为 3 副本模式,以实现系统高可用与数据冗余,具体配置如下:

系统上线后该集群运行稳定,能够高效处理全部传感器采集数据,全面满足项目预定的各项指标。在确认技术架构稳定可靠后,我们将订阅模式变更为永久模式,将长期使用以 TDengine TSDB 为核心的技术架构。

数据库建模

  1. 超级表定义
CREATE STABLE IF NOT EXISTS airsensor (
  ts timestamp,        时间
  pm25 int,        PM2.5
  pm10 int,        PM1.0
  tvoc int,                TVOC
  co2 int,                二氧化碳
  formaldehyde float,        甲醛
  noise float,        噪音
  temperature float,                温度
  humidity float,        湿度
  light int,                光照
  h2s int,                硫化氢
  ch4 int,                甲烷
  co int,                一氧化碳
  no2 float,        二氧化氮
  h2 int,                氢气
  odor float        异味
) TAGS (
  position NCHAR(200),
  space NCHAR(20),
  floor_area NCHAR(20),
  floor NCHAR(20),
  area NCHAR(20),
  device_code NCHAR(20),
  device_id int,
  factory NCHAR(50),
  model NCHAR(50)
);

  • 流计算

    • 会议室人员判定
    create stream if not exists mroom_stream trigger at_once into mroom_stream_status (ts,status) tags(
        space,
        floor_area,
        floor,
        area 
    ) subtable(
        cast(
            concat('mss_', space, '_', floor_area, '_', floor, '_', area) as varchar
        )
    ) as
    SELECT
        _wstart as ts,
        case
            when sum(status) > 0 then 1
            else 0
        end as status
    FROM
        bxserver.humensensor partition by space,
        floor_area,
        floor,
    area interval(1m) fill(value,-1);

  • 楼层用电量统计
select _wstart as ts, max(total_kwh)-min(total_kwh) as used from bxserver.powersensor partition by tbname interval(1d);

  • 订阅数据

落地效果

  • 针对电量传感器采集的元数据通过 TDengine TSDB 转换后的每个楼层用电量统计如下:

  • 针对每个设备状态上报数据通过 TDengine TSDB 转化为设备告警情况如下:

  • 针对空气传感器采集的数据,系统通过 TDengine TSDB 进行转换与分析,并根据当前区域的平均温度执行相应的温控策略:

TDengine 应用经验分享

  1. 时钟同步问题

在使用过程中,我们发现某会议室的人体传感器流计算结果存在异常,最近一分钟的数据未被正常计算。经排查,原因是服务器时间未与时间服务器同步。安装并配置 NTP 服务完成时间同步后,流计算功能恢复正常。

  1. 查询 SQL 语句优化

powersensor_loop 表按行记录传感器的瞬时实测值。为计算当天的用电量,需要对相邻两行取差值后再用 SUM 求和。最初我们采用的是如下嵌套子查询方案,不仅执行时间长,而且占用较大的临时空间:

select TO_CHAR(_wstart, 'YYYY/MM/DD HH24:MI:00') as ts, TO_CHAR(_wstart, 'HH24') as hour, sum(kwh) as kwh, space,floor_area,floor,type from (select _rowts as ts, diff(kwh) as kwh, space, floor_area, floor, area, device_id, loop, type frombxserver.powersensor_loop partition by space, floor_area, floor, area, device_id, loop, type) where ts >= TO_UNIXTIMESTAMP('2025-08-28 00:00:00') and ts <= TO_UNIXTIMESTAMP('2025-08-28 23:59:59') partition by space, floor_area, floor, type interval(1d) order by floor asc;  

powersensor\_loop 表结构如下图所示:

经分析发现,上述嵌套查询语句只在外层添加了时间范围条件,而内层查询未作限制,导致内层查询需读取全量数据,执行耗时长且占用大量临时空间。优化后,我们将时间范围条件前移至内层查询,使其仅在指定时间范围内读取数据,从而显著减少数据扫描量并提升执行效率。

select TO_CHAR(_wstart, 'YYYY/MM/DD HH24:MI:00') as ts, TO_CHAR(_wstart, 'HH24') as hour, sum(kwh) as kwh, space,floor_area,floor,type from (select _rowts as ts, diff(kwh) as kwh, space, floor_area, floor, area, device_id, loop, type frombxserver.powersensor_loop where ts >= TO_UNIXTIMESTAMP('2025-08-28 00:00:00') and ts <= TO_UNIXTIMESTAMP('2025-08-28 23:59:59') partition by space, floor_area, floor, area, device_id, loop, type) partition by space, floor_area, floor, type interval(1d) order by floor asc;

未来规划

当前系统使用的版本为 TDengine TSDB 3.3.6,因流计算暂不支持 diff 函数,无法直接计算相邻数据差值。后续我们计划升级至最新版本 3.3.8,新版本已支持 diff 函数,可将每日电量数据的差值计算结果直接写入流计算结果表,进一步简化后续的查询与汇总分析流程。

关于成都极企科技

成都极企科技有限公司成立于 2014 年,注册资本 392 万元,专注于智能化办公解决方案的研发与落地。公司具备自主软硬件研发能力,已取得多项国家专利及资质认证,为全球上万家企业提供智能化解决方案,累计完成超过百万平方米的办公楼宇与园区智能化建设。客户涵盖美团、爱奇艺、腾讯、阿里、联想、华为、富力、金地等行业头部企业,形成了从硬件设计、软件开发到工程实施的一体化核心竞争力。

关于作者

何铮,公司创始人兼项目带头人,毕业于电子科技大学,国家特聘专家。拥有二十年办公领域产品开发经验,带领企业完成三轮千万级融资。

度小满引入 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 = falseexec_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 = falseexec_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 智能分析,降低研发与业务沟通门槛,并对智能推荐与模板化方案进行探索与实践。