存算分离，性能跃升：盖雅工场TCHouse-D 3.0升级实现查询效率再提升60%

点击蓝字 关注我们

Tencent Cloud Big Data

本文共计7125字 预计阅读时长22分钟

01

导语

随着业务规模的快速扩张，盖雅工场面临不断增长的数据规模与越发复杂的实时分析需求等业务挑战。线上运行着的腾讯云 TCHouse-D 2.0 数仓集群面临了极大的压力（计算资源缺乏有效隔离，高峰时段常出现报表查询响应迟滞、性能下降等问题，常规的通过增加临时资源，又存在查询中断、数据异常等异常），导致客户体验严重受损。为解决上述问题，近期盖雅技术团队顺利完成了从腾讯云 TCHouse-D 2.0 数仓升级到 3.0。

目前该平台已经支撑了盖雅工场上千个租户的实时报表需求，报表查询时效性整体可达亚秒级，相较 2.0 架构，查询耗时平均降低 60%，资源成本降低 20%，大幅实现了降本提效，深得各业务及数据部门的认可。

02

公司介绍

盖雅工场是一家以「科技让劳动力更高效」为使命的中国科技企业，致力于为全球企业提供智能化劳动力管理云服务。通过覆盖企业人效管理全生命周期的咨询+SaaS 软件+运营服务解决方案，助力企业实现人效提升与数字化转型。

依托「人效九宫格」方法论，盖雅工场围绕企业用工四大核心命题——「需要多少人」「实际多少人」「干得怎么样」「怎样找到人」，构建了全场景产品矩阵：

• 通过智能排班云实现AI驱动的劳动力预测与灵活调度；
• 借助实时考勤云与精益工时云精准管控工时成本；
• 利用激励性薪酬与即时支付系统激发员工效能、通过人效洞察看板掌握实时人效状态；
• 结合零工管家云与岗位外包服务打通灵活用工生态。同时，通过人效诊断培训与数字化监测服务，为企业提供从战略到落地的闭环支持。

技术层面，盖雅工场以 AI+ML 智能排班引擎为核心，通过毫秒级分布式计算引擎支撑海量数据处理，并依托多语言、多时段、多币种架构服务全球客户。

在生态层面，盖雅坚持关键零组件战略，通过盖雅 I/O 平台和 OpenAPI 平台对接上下游厂商，涵盖核心人事、薪酬、绩效、协同、员工体验、硬件设备等领域头部厂商，为客户一同打造无缝连接的优质体验。

从理念传播到技术赋能，从运营服务到生态整合，盖雅工场始终聚焦劳动力管理的「降本、增效、合规、体验」，现已为超过 34 个国家与地区的 1800 多家企业提供全链路人效提升价值。

03

业务介绍及痛点

聚合报表服务作为盖雅工场的核心数据服务，为数千家企业级 SaaS 租户提供高并发、低延迟的实时报表分析能力。其全面覆盖劳动力人员结构、动态流动、考勤核算、薪酬计算、离职分析及审批流程等关键业务环节，为企业运营决策提供实时、准确的数据支撑。随着盖雅工场全球化业务的持续扩展，聚合报表服务承载了近百个 MySQL 实例、超五万张表的数据处理与整合。当前 TCHouse-D 2.0 架构存在资源弹性不足、租户资源竞争、存算耦合难以扩展及缺乏物化视图等核心瓶颈，导致高峰响应延迟、资源利用率低与复杂查询性能不佳等问题，影响了客户服务体验与业务发展。

1) 初期架构

初期使用自建的 TiDB 和 StarRocks 集群支持上述业务需求，共有两条链路。

链路1：自建 Data Migration->TiDB

链路2：自研 Flink CDC+Kafka->StarRocks

2) 2.0架构

随着业务高速发展，盖雅基于原有自建方案平滑升级到 TCHouse-D 2.0。源端 MySQL 数据经过 WeData 的数据集成进行自动数据转换后，入库到 TCHouse-D 中进行聚合分析和实时自定义分析。同时为提升业务连续性，还对关键业务部署了主备双集群容灾方案。当主集群发生故障时，可自动或手动快速切换至备用集群，最大限度缩短业务中断时间，确保数据安全和服务高可用。

3) 问题和挑战

随着盖雅工场全球化业务的推进，聚合报表服务积累的数据规模越来越大，查询并发量也随之攀升。在月结等周期性业务场景中，客户业务呈现显著的波峰波谷特征。同时，由于不同客户间的计算资源缺乏有效隔离，高峰时段常出现报表查询响应迟滞、性能下降等问题，导致客户体验严重受损。

1. 在月结、定时查询等场景中，业务会有显著的波峰波谷，资源需求存在时空差异。现有架构缺乏横向和纵向弹性伸缩能力，难以动态匹配资源需求。这直接导致业务高峰时响应速度下降，低谷时资源闲置，整体服务体验与效率受到制约。
2. 在当前架构下，由于缺少有效的租户级资源隔离机制，不同租户的计算任务在业务高峰期会集中调度至同一计算组，引发资源竞争。这种资源争抢会导致关键查询任务延迟增加、响应时间波动，进而影响整体服务的性能稳定性和查询效率。同时，也对实时同步链路带来侵害（数据延迟、任务中断）。
3. 目前为存算一体架构，该架构下计算与存储资源紧耦合，难以根据业务负载的变化实现独立、灵活的扩缩容，在计算密集型业务场景下会造成存储资源的浪费。存储资源不能独立扩展和按需配置，长期来看提升总体成本，并降低系统整体的资源利用率与稳定性。资源的升降配动作，面临着集群不可用状况，造成数据同步任务中断、数据查询异常。
4. 在当前架构下，由于缺乏物化视图功能，系统在面对大数据量下的复杂分析查询时存在显著的性能瓶颈。复杂查询（尤其是涉及聚合、多表关联的操作）无法借助预计算机制进行加速，每次请求均需进行全量计算与数据扫描，导致查询响应时间普遍延长至分钟级，难以满足实时交互的业务要求。

04

选型思路

为降低集群运维成本、提升实时查询效率，支持高并发下的多维度即席分析能力。盖雅决定引入新的高性能 OLAP 分析型数据仓库来解决越发灵活的查询场景，针对场景的 OLAP 引擎需要满足以下技术特性：

• 性能强，能够对灵活随机的查询逻辑，对于条件、聚合、关联等查询逻辑都有比较良好的性能支持；
• 支持高并发查询，开放式系统支持满足数百租户并发的常业务分析需求和洞察报表需求；
• 分布式结构，能支持海量数据的场景，也易于扩展规模应对数据增长；
• 具备良好的资源隔离能力，同时支持软隔离和硬隔离，软隔离降低不同租户间的业务影响，硬隔离确保读写查的操作相互之间互不影响；
• 低 SQL 改造成本，原本在 MySQL 中的查询 SQL 尽量少改造，甚至不改造就能查询，并且还兼顾有很好的性能优化表现；
• 支持灵活资源弹性，高峰期可以弹性增加某个租户下的资源量，灵活应对月结等场景；
• 存算分离架构，减少存储和集成任务的冗余，简化架构的同时还减轻对上游的压力；
• 统一数仓构建，运维简单，缩减运维人力的投入和成本的支出，实现降本提效；
• Apache 顶级项目，社区活跃，有广泛的用户使用经验基础。

随着盖雅业务规模持续扩张、查询场景愈发灵活，为进一步降低集群运维成本、提升实时查询效率、强化高并发多维度即席分析能力，同时全面匹配分布式扩展、资源隔离、SQL 兼容、弹性伸缩、存算分离、统一数仓等核心技术诉求，盖雅决定将 TCHouse-D 从 2.0 升级至 3.0 版本。

存算分离架构可减少存储冗余、简化技术栈、减轻上游压力；资源隔离能力，既能降低多租户间业务干扰，又能保障读写查操作互不影响；灵活的资源弹性扩缩，可轻松应对月结等高峰期流量波动；同时进一步优化查询性能与 SQL 兼容性，让原有 MySQL 查询语句几乎无需改造即可高效运行，搭配更简洁的统一数仓构建与运维体系，显著缩减人力投入与运维成本。全面支撑盖雅多租户高并发报表分析与业务洞察需求，实现性能、稳定性、成本、运维效率的全方位提升，为后续业务高速增长提供更强大的数仓底座。

此外，在公有云生态位面，腾讯云 WeData 提供腾讯云数据仓库的数据集成能力，通过界面化操作即可高效实现业务库到 TCHouse-D 3.0 数仓的实时数据同步，并支持自动批量建表、字段类型自动映射、高负载情况下自动限流等功能，有效提升迁移效率并保障业务稳定。

05

新的架构及方案

腾讯云在2025年在 TCHouse-D 2.0 的基础上，推出了云原生存算分离的新架构(TCHouse-D 3.0)。TCHouse-D 3.0 存算分离版适用的典型业务场景如下：

1. 成本敏感的海量数据存储场景：如果业务数据量达到 PB 级，或者需要存储大量的历史冷数据，存算分离版本是首选。
2. 具有明显“波峰波谷”的弹性负载场景：例如电商大促（双 11）、直播高峰、金融日终结算等场景。
3. 多业务负载隔离（多租户场景）：当公司内部有多个部门（如营销、财务、风控）共享同一套数据时。
4. 湖仓一体与联邦查询加速：已经有大量数据存储在数据湖（Hive, Hudi, Iceberg）中，TCHouse-D 3.0 存算分离版可以作为高性能的计算引擎，直接对接现有的对象存储基座。
5. 读写分离场景：在实时数仓中，高频的数据写入（Insert/Routine Load）往往会抢占查询业务的资源，需要通过读写分离的方式，保障查询性能不受影响。

盖雅升级到 TCHouse-D 3.0 后，WFM 数仓应用架构图如下，在一份数据的基础上，通过不同的计算组做到资源隔离，保证写入、ETL、查询三者之间相互不影响。

1. 数据共享：
   1. 避免数据冗余：多集群共享底层对象存储，均可访问底层数据，避免了冗余数据存储；
   2. 单位存储成本下降：基于对象存储本身的高可靠性，TCHouse-D 3.0 版无需在分布式数仓系统中维护数据副本，同时，也无需预设存储容量大小，按实际使用量付费，因此 3.0 版本的单位存储成本大幅下降。
2. 计算隔离：多集群之间的计算资源是完全独立的，可用于隔离不同的工作负载。每个集群可以按需购买不同规格的计算和本地缓存资源，并根据业务负载进行自动弹性。例如：常驻计算组 A 专门承载来自 MySQL 业务库的实时写入负载，而查询负载则分发到弹性计算组 C；计算组 C 可根据月结期间的业务负载高峰进行灵活的升降配，且升配的期间不影响计算组 A 的实时写入；
3. 多读多写：多集群在数据读写方面具有独立对等的特性，能够并行写入数据。例如：常驻计算组 A 和 B 均可以写入数据，且一旦数据提交生效，所有集群均可立即查询到最新的数据。同时，计算组 A 配置了主动同步预热的功能，可以自动将最新的写入数据直接同步到计算组 C 的本地缓存，避免了计算组 C 去远端对象存储读书节的性能损耗，有效提升了计算组 C 的查询性能；
4. 灵活弹性：在这个架构下，可随时拉起新的专有计算组，为战略客户提供极致的使用体验；当业务波峰波谷呈现强周期性时，可为计算资源配置分时弹性和规则弹性，以进一步提升资源利用率。

点击文末【阅读原文】查看更多腾讯云 TCHouse 3.0 官网详情

06

应用实践

1.引入物化视图，增量刷新，降低高峰期计算压力

腾讯云数仓 TCHouse-D 3.0 对物化视图能力进行持续演进，通过同步与异步两种模式，覆盖了从实时聚合到复杂建模的全场景需求：

• 同步物化视图（强一致单表模式）：核心定位为“实时预计算引擎”。数据随基表同步写入，确保强一致性与零维护成本。该模式专为单表高频、固定维度的聚合分析场景设计，通过预聚合大幅降低查询延迟。
• 异步物化视图（多表模式）：核心定位为“复杂查询加速器”。支持多表 Join 与自定义刷新策略，实现最终一致性。针对超大规模数据，支持分区级增量刷新，显著降低 I/O 开销。该模式是多表关联加速、近实时报表及简化 ETL 链路的理想选择。

在 TCHouse-D 2.0 中，盖雅通过 Dolphin Scheduler 的调度工具，定时调度ETL作业，为下游系统准备数据。升级到 TCHouse-D 3.0 之后，针对一些 BI 分析类业务，如“人效洞察”等，采用异步物化视图的方式，来替代之前复杂的 ETL 调度任务，不仅大幅简化了处理过程，还大幅提升了 ETL 的执行效率。

数据处理流程图如下：

典型业务 SQL:

select tt1.personid,
sum(case when classcode='L01' then payhours else 0 end )    '出差',
sum(case when classcode='A02' then payhours else 0 end )    '调休假',
sum(case when classcode='C01' then payhours else 0 end ) '事假',
sum(case when classcode='B01' then payhours else 0 end ) '病假'   ,
sum(case when classcode='A03' then payhours else 0 end ) '婚假',
sum(case when classcode='A06' then payhours else 0 end ) '产假',
sum(case when classcode='A10' then payhours else 0 end ) '工伤假',
sum(case when classcode='J01' then payhours else 0 end )+
sum(case when classcode='J02' then payhours else 0 end )+
sum(case when classcode='J05' then payhours else 0 end )+
sum(case when classcode='K01' then payhours else 0 end ) '年假',
sum(case when classcode='A08' then payhours else 0 end ) '护理假',
sum(case when classcode='A20' then payhours else 0 end ) '路程假',
sum(case when classcode='A04' then payhours else 0 end ) '丧假',
sum(case when classcode='A30' then payhours else 0 end ) '社会活动假',
sum(case when classcode='A12' then payhours else 0 end ) '探亲假',
sum(case when classcode='A05' then payhours else 0 end ) '产检假',
sum(case when classcode='A21' then payhours else 0 end ) '育儿假',
sum(case when classcode='A29' then payhours else 0 end ) '独生子女陪护假',
sum(case when classcode='D01' then payhours else 0 end ) '平时加班',
sum(case when classcode='D02' then payhours else 0 end ) '假日加班',
sum(case when classcode='D03' then payhours else 0 end ) '节日加班',
sum(case when classcode='E02' then payhours else 0 end ) '夜班天数小',
sum(case when classcode='E01' then payhours else 0 end ) '夜班天数大',
sum(case when classcode='I07' then payhours else 0 end ) '实际出勤',
sum(case when classcode='I13' then payhours else 0 end ) '实际出勤工时',
sum(case when classcode='H01' then payhours else 0 end ) '旷工天数',
sum(case when classcode='I11'  then payhours else 0 end ) '应出勤',
sum(case when classcode='D07'  then payhours else 0 end ) '应兑现'
from gaiatest.atdpersonpaycode tt1
inner join gaiatest.atd_attendance_class tt2 
on tt1.paycode=tt2.id
GROUP BY tt1.personid

在考勤月结的业务高峰期，考勤员需通过批量重算来确保员工本考勤周期的结果准确性。由于该业务 SQL 逻辑复杂且数据规模庞大，高频的大规模计算不仅导致查询延迟高，更会引发严重的计算资源争抢，在业务波峰阶段给系统稳定性带来了巨大压力。

为破解这一瓶颈，我们引入了 TCHouse-D 3.0 的异步物化视图方案。首先，在存储层通过按月分区实现按分区的增量刷新；其次，将复杂的业务逻辑计算下沉至物化视图，并配置5分钟精度的微批增量刷新。 这一改进将复杂的实时计算转化为轻量级的预取操作，使查询耗时从 3s+ 骤降至 200ms，在实现性能 15倍 提升的同时，极大地降低了 CPU 与 IO 资源的负载。

改造成异步物化视图后：

create materialized view Monthly_attendance_results 
REFRESH COMPLETE ON SCHEDULE EVERY 5 minute
DISTRIBUTED BY HASH(personid) BUCKETS 3
PROPERTIES 
("enable_nondeterministic_function" = "true") 
as 
select tt1.personid,
sum(case when classcode='L01' then payhours else 0 end )	'出差',
sum(case when classcode='A02' then payhours else 0 end )	'调休假',
sum(case when classcode='C01' then payhours else 0 end ) '事假',
sum(case when classcode='B01' then payhours else 0 end ) '病假'	,
sum(case when classcode='A03' then payhours else 0 end ) '婚假',
sum(case when classcode='A06' then payhours else 0 end ) '产假',
sum(case when classcode='A10' then payhours else 0 end ) '工伤假',
sum(case when classcode='J01' then payhours else 0 end )+
sum(case when classcode='J02' then payhours else 0 end )+
sum(case when classcode='J05' then payhours else 0 end )+
sum(case when classcode='K01' then payhours else 0 end ) '年假',
sum(case when classcode='A08' then payhours else 0 end ) '护理假',
sum(case when classcode='A20' then payhours else 0 end ) '路程假',
sum(case when classcode='A04' then payhours else 0 end ) '丧假',
sum(case when classcode='A30' then payhours else 0 end ) '社会活动假',
sum(case when classcode='A12' then payhours else 0 end ) '探亲假',
sum(case when classcode='A05' then payhours else 0 end ) '产检假',
sum(case when classcode='A21' then payhours else 0 end ) '育儿假',
sum(case when classcode='A29' then payhours else 0 end ) '独生子女陪护假',
sum(case when classcode='D01' then payhours else 0 end ) '平时加班',
sum(case when classcode='D02' then payhours else 0 end ) '假日加班',
sum(case when classcode='D03' then payhours else 0 end ) '节日加班',
sum(case when classcode='E02' then payhours else 0 end ) '夜班天数小',
sum(case when classcode='E01' then payhours else 0 end ) '夜班天数大',
sum(case when classcode='I07' then payhours else 0 end ) '实际出勤',
sum(case when classcode='I13' then payhours else 0 end ) '实际出勤工时',
sum(case when classcode='H01' then payhours else 0 end ) '旷工天数',
sum(case when classcode='I11'  then payhours else 0 end ) '应出勤',
sum(case when classcode='D07'  then payhours else 0 end ) '应兑现'
from gaiatest.atdpersonpaycode tt1
inner join gaiatest.atd_attendance_class tt2 
on tt1.paycode=tt2.id
GROUP BY tt1.personid;
 

2.存算分离架构下，系统不仅具备良好的弹性伸缩能力，还需针对查询延迟敏感型业务进行优化，确保查询性能不降级

TCHouse-D 3.0 全新的存算分离架构，确保了计算层和存储层都能独立缩扩容，互不干扰。当弹起新的计算节点时，由于计算节点不再存储持久化数据（仅存储本地缓存），新增节点时无需经历漫长的数据副本均衡（Rebalance）过程，即刻就可以参与计算。这与 TCHouse-D 2.0 存算一体模式核心的差异在于从“数据迁移”转变为“元数据迁移+按需拉取”。

为避免水平扩容后漫长的数据副本均衡过程，盖雅在 TCHouse-D 2.0 期间主要通过垂直升配来提升集群的处理能力，通常升配过程需要 10 分钟左右，升配结束后恢复实时数据同步链路，还需要大约 20 分钟左右来追齐数据。升级到 TCHouse-D 3.0 之后，一方面可以通过读写分离的方式，来规避变配对实时写入的影响；另一方面，也通过 3.0 基于负载自动弹性伸缩的能力，轻松应对业务负载的变化，大幅降低人工介入的运维压力。

虽然 TCHouse-D 3.0 存算分离架构支持按需拉取，但远端 I/O 带来的延迟明显高于本地 Cache 命中。为了高效利用有限的本地缓存，TCHouse-D 3.0 采用了 LRU/TTL 等一系列的精细化管理算法。同时还提供“查询触发”、“导入同步”、“主动预热”等方式让数据直接进入本地缓存。其中，“多集群间预热”在多集群（Multi-Cluster）场景下，可以将集群 A 的热点信息同步给新创建的集群B，让 B 快速从远端加载热数据，消除“冷启动”瓶颈。

譬如盖雅考勤月结业务，对查询响应耗时要求十分极致，在业务峰值期间根据负载情况自适应弹性扩容计算节点时，系统必须在应对流量陡增的同时，确保查询性能“零损耗”。这就要求新扩容的空节点能够实现热数据的快速迁入（Cache Rebalance）与预热，以消除冷启动带来的性能抖动。针对该类极致性能场景，腾讯云数仓 TCHouse-D 研发团队对内核级 Cache Rebalance 机制进行了深度优化。通过引入异步并发批处理技术，优化了缓存搬迁任务的调度算法。这一改进显著缩短了新节点上线后的数据预热周期，尤其在海量缓存场景下，数据就绪效率实现跃升，确保了集群扩容后的性能平滑过渡。在盖雅生产环境的实测验证中，这一系列优化使缓存重平衡效率提升了 6 倍以上，确保了在业务波峰弹性扩容时，查询性能能够实现平滑无感过渡。

07

收益总结

盖雅在腾讯云 TCHouse-D 2.0 基础上无缝升级至 3.0 版本，依托其全新存算分离架构、软硬结合的资源隔离能力与优化的查询引擎，实现了数仓性能与运维效率的双重飞跃。通过原生支持的弹性资源调度，精准匹配月结等高并发峰值需求，结合进一步增强的 MySQL 协议兼容性，最大化复用存量 SQL 资产，配合全托管模式下的智能运维能力，大幅释放人力成本。

• 性能再提升：基于 3.0 优化的执行引擎，在多表关联、复杂聚合及高并发即席分析场景下，查询效率较 2.0 版本显著提升，实时性表现更为优异；
• 极致弹性伸缩：依托存算分离架构，实现计算资源与存储资源的独立弹性扩缩，月结等高峰期可秒级扩容租户资源，潮汐效应下成本控制更精准；
• 运维与开发提效：完善的资源隔离能力简化了租户管理复杂度，近乎零改造的 SQL 兼容特性进一步提升开发效率，全托管模式下大幅简化运维复杂度；
• 架构与成本优化：通过存算分离优化存储冗余，结合架构统一与资源按需分配，对比 2.0 版本进一步降低整体集群成本，实现降本提效的最大化。

08

未来规划

截至目前，盖雅大部分数据分析类业务已从腾讯云数据仓库 TCHouse-D 2.0 升级到 3.0，在性能和稳定性上都有明显提升，深得各数据和业务部门的认可。未来，盖雅将与腾讯云大数据团队深化战略协作，共同推进技术产品迭代，共创场景解决方案，持续增强实时数据计算与分析能力。未来关注的重点能力包括：

• AI Function：TCHouse-D 4.0 新增了 AI_EXTRACT（信息提取）、AI_SENTIMENT（情感分析）和 AI_SUMMARIZE（文本总结）等 AI 函数。数据分析师可以直接用 SQL 调用大模型（LLM）处理表中的文本，极大地简化了AI应用的链路
• “向量+搜索+分析”三位一体的多模分析：TCHouse-D 4.0 引入了原生向量索引（Vector Index）以及增强型全文检索，可在 TCHouse-D 4.0 系统内，用一套标准 SQL 同时完成
• 统计分析（求和、聚合、大宽表）
• 全文检索（搜日志、搜文档）
• 向量检索（RAG、搜特征）

最后，感谢腾讯云大数据团队，感谢其对问题的快速响应和积极的技术支持。

Tencent BigData

关注腾讯云大数据╳探索数据的无限可能

往期精彩

求点赞

求分享

求喜欢