概述盖雅在腾讯云 TCHouse-D 2.0 基础上无缝升级至 3.0 版本依托其全新存算分离架构、软硬结合的资源隔离能力与优化的查询引擎实现了数仓性能与运维效率的双重飞跃。通过原生支持的弹性资源调度精准匹配月结等高并发峰值需求结合进一步增强的 MySQL 协议兼容性最大化复用存量 SQL 资产配合全托管模式下的智能运维能力大幅释放人力成本。一、导语随着业务规模的快速扩张盖雅工场面临不断增长的数据规模与越发复杂的实时分析需求等业务挑战。线上运行着的腾讯云 TCHouse-D 2.0 数仓集群面临了极大的压力计算资源缺乏有效隔离高峰时段常出现报表查询响应迟滞、性能下降等问题常规的通过增加临时资源又存在查询中断、数据异常等异常导致客户体验严重受损。为解决上述问题近期盖雅技术团队顺利完成了从腾讯云 TCHouse-D 2.0 数仓升级到 3.0。目前该平台已经支撑了盖雅工场上千个租户的实时报表需求报表查询时效性整体可达亚秒级相较2.0架构查询耗时平均降低 60%资源成本降低20%大幅实现了降本提效深得各业务及数据部门的认可。二、公司介绍盖雅工场是一家以「科技让劳动力更高效」为使命的中国科技企业致力于为全球企业提供智能化劳动力管理云服务。通过覆盖企业人效管理全生命周期的咨询SaaS软件运营服务解决方案助力企业实现人效提升与数字化转型。依托「人效九宫格」方法论盖雅工场围绕企业用工四大核心命题——「需要多少人」「实际多少人」「干得怎么样」「怎样找到人」构建了全场景产品矩阵通过智能排班云实现AI驱动的劳动力预测与灵活调度借助实时考勤云与精益工时云精准管控工时成本利用激励性薪酬与即时支付系统激发员工效能、通过人效洞察看板掌握实时人效状态结合零工管家云与岗位外包服务打通灵活用工生态。同时通过人效诊断培训与数字化监测服务为企业提供从战略到落地的闭环支持。技术层面盖雅工场以AIML智能排班引擎为核心通过毫秒级分布式计算引擎支撑海量数据处理并依托多语言、多时段、多币种架构服务全球客户。在生态层面盖雅坚持关键零组件战略通过盖雅I/O 平台和 OpenAPI 平台对接上下游厂商涵盖核心人事、薪酬、绩效、协同、员工体验、硬件设备等领域头部厂商为客户一同打造无缝链接的优质体验。从理念传播到技术赋能从运营服务到生态整合盖雅工场始终聚焦劳动力管理的「降本、增效、合规、体验」现已为超过34个国家与地区的1800多家企业提供全链路人效提升价值。三、业务介绍及痛点聚合报表服务作为盖雅工场的核心数据服务为数千家企业级 SaaS 租户提供高并发、低延迟的实时报表分析能力。其全面覆盖劳动力人员结构、动态流动、考勤核算、薪酬计算、离职分析及审批流程等关键业务环节为企业运营决策提供实时、准确的数据支撑。随着盖雅工场全球化业务的持续扩展聚合报表服务承载了近百个 MySQL 实例、超五万张表的数据处理与整合。当前 TCHouse-D 2.0 架构存在资源弹性不足、租户资源竞争、存算耦合难以扩展及缺乏物化视图等核心瓶颈导致高峰响应延迟、资源利用率低与复杂查询性能不佳等问题影响了客户服务体验与业务发展。1初期架构初期使用自建的 TiDB 和 StarRocks 集群支持上述业务需求共有两条链路。链路1自建 Data Migration - TiDB链路2自研 Flink CDC Kafka - StarRocks22.0架构随着业务高速发展盖雅基于原有自建方案平滑升级到 TCHouse-D 2.0。源端 MySQL 数据经过 WeData 的数据集成进行自动数据转换后入库到 TCHouse-D 中进行聚合分析和实时自定义分析。同时为提升业务连续性还对关键业务部署了主备双集群容灾方案。当主集群发生故障时可自动或手动快速切换至备用集群最大限度缩短业务中断时间确保数据安全和服务高可用。3问题和挑战随着盖雅工场全球化业务的推进聚合报表服务积累的数据规模越来越大查询并发量也随之攀升。在月结等周期性业务场景中客户业务呈现显著的波峰波谷特征。同时由于不同客户间的计算资源缺乏有效隔离高峰时段常出现报表查询响应迟滞、性能下降等问题导致客户体验严重受损。a. 在月结、定时查询等场景中业务会有显著的波峰波谷资源需求存在时空差异。现有架构缺乏横向和纵向弹性伸缩能力难以动态匹配资源需求。这直接导致业务高峰时响应速度下降低谷时资源闲置整体服务体验与效率受到制约。b. 在当前架构下由于缺少有效的租户级资源隔离机制不同租户的计算任务在业务高峰期会集中调度至同一计算组引发资源竞争。这种资源争抢会导致关键查询任务延迟增加、响应时间波动进而影响整体服务的性能稳定性和查询效率。同时也对实时同步链路带来侵害数据延迟、任务中断。c. 目前为存算一体架构该架构下计算与存储资源紧耦合难以根据业务负载的变化实现独立、灵活的扩缩容在计算密集型业务场景下回造成存储资源的浪费。存储资源不能独立扩展和按需配置长期来看提升总体成本并降低系统整体的资源利用率与稳定性。资源的升降配动作面临着集群不可用状况造成数据同步任务中断、数据查询异常。d. 在当前架构下由于缺乏物化视图功能系统在面对大数据量下的复杂分析查询时存在显著的性能瓶颈。复杂查询尤其是涉及聚合、多表关联的操作无法借助预计算机制进行加速每次请求均需进行全量计算与数据扫描导致查询响应时间普遍延长至分钟级难以满足实时交互的业务要求。四、选型思路为降低集群运维成本、提升实时查询效率支持高并发下的多维度即席分析能力。盖雅决定引入新的高性能 OLAP 分析型数据仓库来解决越发灵活的查询场景针对场景的 OLAP 引擎需要满足以下技术特性● 性能强能够对灵活随机的查询逻辑对于条件、聚合、关联等查询逻辑都有比较良好的性能支持● 支持高并发查询开放式系统支持满足数百租户并发的常业务分析需求和洞察报表需求● 分布式结构能支持海量数据的场景也易于扩展规模应对数据增长● 具备良好的资源隔离能力同时支持软隔离和硬隔离软隔离降低不同租户间的业务影响硬隔离确保读写查的操作相互之间互不影响● 低 SQL 改造成本原本在 MySQL 中的查询 SQL 尽量少改造甚至不改造就能查询并且还兼顾有很好的性能优化表现● 支持灵活资源弹性高峰期可以弹性增加某个租户下的资源量灵活应对月结等场景● 存算分离架构减少存储和集成任务的冗余简化架构的同时还减轻对上游的压力● 统一数仓构建运维简单缩减运维人力的投入和成本的支出实现降本提效● Apache 顶级项目社区活跃有广泛的用户使用经验基础。随着盖雅业务规模持续扩张、查询场景愈发灵活为进一步降低集群运维成本、提升实时查询效率、强化高并发多维度即席分析能力同时全面匹配分布式扩展、资源隔离、SQL 兼容、弹性伸缩、存算分离、统一数仓等核心技术诉求盖雅决定将 Doris 从 2.0 升级至 3.0 版本。存算分离架构可减少存储冗余、简化技术栈、减轻上游压力资源隔离能力既能降低多租户间业务干扰又能保障读写查操作互不影响灵活的资源弹性扩缩可轻松应对月结等高峰期流量波动同时进一步优化查询性能与 SQL 兼容性让原有 MySQL 查询语句几乎无需改造即可高效运行搭配更简洁的统一数仓构建与运维体系显著缩减人力投入与运维成本。全面支撑盖雅多租户高并发报表分析与业务洞察需求实现性能、稳定性、成本、运维效率的全方位提升为后续业务高速增长提供更强大的数仓底座。此外在公有云生态位面腾讯云 WeData 提供腾讯云数据仓库的数据集成能力通过白屏化操作即可高效实现业务库到Doris的实时数据同步并支持自动批量建表、字段类型自动映射、高负载情况下自动限流等功能有效提升迁移效率并保障业务稳定。五、新的架构及方案腾讯云在2025年在 TCHouse-D 2.0 的基础上推出了云原生存算分离的新架构(TCHouse-D 3.0)。TCHouse-D 3.0 存算分离版适用的典型业务场景如下成本敏感的海量数据存储场景如果业务数据量达到 PB 级或者需要存储大量的历史冷数据存算分离版本是首选。具有明显“波峰波谷”的弹性负载场景例如电商大促双 11、直播高峰、金融日终结算等场景。多业务负载隔离多租户场景当公司内部有多个部门如营销、财务、风控共享同一套数据时。湖仓一体与联邦查询加速已经有大量数据存储在数据湖Hive, Hudi, Iceberg中TCHouse-D 3.0 存算分离版可以作为高性能的计算引擎直接对接现有的对象存储基座。读写分离场景在实时数仓中高频的数据写入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 官网详情腾讯云数据仓库 TCHouse-D 存算分离操作指南-文档中心-腾讯云六、应用实践1、引入物化视图增量刷新降低高峰期计算压力腾讯云数仓 TCHouse-D 3.0 对物化视图能力进行持续演进通过同步与异步两种模式覆盖了从实时聚合到复杂建模的全场景需求同步物化视图强一致单表模式核心定位为“实时预计算引擎”。数据随基表同步写入确保强一致性与零维护成本。该模式专为单表高频、固定维度的聚合分析场景设计通过预聚合大幅降低查询延迟。异步物化视图多表模式核心定位为“复杂查询加速器”。支持多表 Join 与自定义刷新策略实现最终一致性。针对超大规模数据支持分区级增量刷新显著降低 I/O 开销。该模式是多表关联加速、近实时报表及简化 ETL 链路的理想选择。在 TCHouse-D 2.0 中盖雅通过 Dolphin Scheduler 的调度工具定时调度 ETL 作业为下游系统准备数据。升级到 TCHouse-D 3.0 之后针对一些 BI 分析类业务如“人效洞察”等采用异步物化视图的方式来替代之前复杂的 ETL 调度任务不仅大幅简化了处理过程还大幅提升了 ETL 的执行效率。数据处理流程图如下典型业务 SQL:展开代码语言SQL自动换行AI代码解释select tt1.personid, sum(case when classcodeL01 then payhours else 0 end ) 出差, sum(case when classcodeA02 then payhours else 0 end ) 调休假, sum(case when classcodeC01 then payhours else 0 end ) 事假, sum(case when classcodeB01 then payhours else 0 end ) 病假 , sum(case when classcodeA03 then payhours else 0 end ) 婚假, sum(case when classcodeA06 then payhours else 0 end ) 产假, sum(case when classcodeA10 then payhours else 0 end ) 工伤假, sum(case when classcodeJ01 then payhours else 0 end ) sum(case when classcodeJ02 then payhours else 0 end ) sum(case when classcodeJ05 then payhours else 0 end ) sum(case when classcodeK01 then payhours else 0 end ) 年假, sum(case when classcodeA08 then payhours else 0 end ) 护理假, sum(case when classcodeA20 then payhours else 0 end ) 路程假, sum(case when classcodeA04 then payhours else 0 end ) 丧假, sum(case when classcodeA30 then payhours else 0 end ) 社会活动假, sum(case when classcodeA12 then payhours else 0 end ) 探亲假, sum(case when classcodeA05 then payhours else 0 end ) 产检假, sum(case when classcodeA21 then payhours else 0 end ) 育儿假, sum(case when classcodeA29 then payhours else 0 end ) 独生子女陪护假, sum(case when classcodeD01 then payhours else 0 end ) 平时加班, sum(case when classcodeD02 then payhours else 0 end ) 假日加班, sum(case when classcodeD03 then payhours else 0 end ) 节日加班, sum(case when classcodeE02 then payhours else 0 end ) 夜班天数小, sum(case when classcodeE01 then payhours else 0 end ) 夜班天数大, sum(case when classcodeI07 then payhours else 0 end ) 实际出勤, sum(case when classcodeI13 then payhours else 0 end ) 实际出勤工时, sum(case when classcodeH01 then payhours else 0 end ) 旷工天数, sum(case when classcodeI11 then payhours else 0 end ) 应出勤, sum(case when classcodeD07 then payhours else 0 end ) 应兑现 from gaiatest.atdpersonpaycode tt1 inner join gaiatest.atd_attendance_class tt2 on tt1.paycodett2.id GROUP BY tt1.personid在考勤月结的业务高峰期考勤员需通过批量重算来确保员工本考勤周期的结果准确性。由于该业务 SQL 逻辑复杂且数据规模庞大高频的大规模计算不仅导致查询延迟高更会引发严重的计算资源争抢在业务波峰阶段给系统稳定性带来了巨大压力。为破解这一瓶颈我们引入了TCHouse-D 3.0 的异步物化视图方案。首先在存储层通过按月分区实现按分区的增量刷新其次将复杂的业务逻辑计算下沉至物化视图并配置 5 分钟精度的微批增量刷新。 这一改进将复杂的实时计算转化为轻量级的预取操作使查询耗时从3s 骤降至 200 ms在实现性能15 倍提升的同时极大地降低了 CPU 与 IO 资源的负载。改造成异步物化视图后展开代码语言SQL自动换行AI代码解释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 classcodeL01 then payhours else 0 end ) 出差, sum(case when classcodeA02 then payhours else 0 end ) 调休假, sum(case when classcodeC01 then payhours else 0 end ) 事假, sum(case when classcodeB01 then payhours else 0 end ) 病假 , sum(case when classcodeA03 then payhours else 0 end ) 婚假, sum(case when classcodeA06 then payhours else 0 end ) 产假, sum(case when classcodeA10 then payhours else 0 end ) 工伤假, sum(case when classcodeJ01 then payhours else 0 end ) sum(case when classcodeJ02 then payhours else 0 end ) sum(case when classcodeJ05 then payhours else 0 end ) sum(case when classcodeK01 then payhours else 0 end ) 年假, sum(case when classcodeA08 then payhours else 0 end ) 护理假, sum(case when classcodeA20 then payhours else 0 end ) 路程假, sum(case when classcodeA04 then payhours else 0 end ) 丧假, sum(case when classcodeA30 then payhours else 0 end ) 社会活动假, sum(case when classcodeA12 then payhours else 0 end ) 探亲假, sum(case when classcodeA05 then payhours else 0 end ) 产检假, sum(case when classcodeA21 then payhours else 0 end ) 育儿假, sum(case when classcodeA29 then payhours else 0 end ) 独生子女陪护假, sum(case when classcodeD01 then payhours else 0 end ) 平时加班, sum(case when classcodeD02 then payhours else 0 end ) 假日加班, sum(case when classcodeD03 then payhours else 0 end ) 节日加班, sum(case when classcodeE02 then payhours else 0 end ) 夜班天数小, sum(case when classcodeE01 then payhours else 0 end ) 夜班天数大, sum(case when classcodeI07 then payhours else 0 end ) 实际出勤, sum(case when classcodeI13 then payhours else 0 end ) 实际出勤工时, sum(case when classcodeH01 then payhours else 0 end ) 旷工天数, sum(case when classcodeI11 then payhours else 0 end ) 应出勤, sum(case when classcodeD07 then payhours else 0 end ) 应兑现 from gaiatest.atdpersonpaycode tt1 inner join gaiatest.atd_attendance_class tt2 on tt1.paycodett2.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 倍以上确保了在业务波峰弹性扩容时查询性能能够实现平滑无感过渡。七、收益总结盖雅在腾讯云 TCHouse-D 2.0 基础上无缝升级至 3.0 版本依托其全新存算分离架构、软硬结合的资源隔离能力与优化的查询引擎实现了数仓性能与运维效率的双重飞跃。通过原生支持的弹性资源调度精准匹配月结等高并发峰值需求结合进一步增强的 MySQL 协议兼容性最大化复用存量 SQL 资产配合全托管模式下的智能运维能力大幅释放人力成本。性能再提升基于 3.0 优化的执行引擎在多表关联、复杂聚合及高并发即席分析场景下查询效率较 2.0 版本显著提升实时性表现更为优异极致弹性伸缩依托存算分离架构实现计算资源与存储资源的独立弹性扩缩月结等高峰期可秒级扩容租户资源潮汐效应下成本控制更精准运维与开发提效完善的资源隔离能力简化了租户管理复杂度近乎零改造的 SQL 兼容特性进一步提升开发效率全托管模式下大幅简化运维复杂度架构与成本优化通过存算分离优化存储冗余结合架构统一与资源按需分配对比 2.0 版本进一步降低整体集群成本实现降本提效的最大化。八、未来规划截止目前盖雅大部分数据分析类业务已从腾讯云数据仓库 TCHouse-D 2.0 升级到 3.0在性能和稳定性上都有明显提升深得各数据和业务部门的认可。未来盖雅将与腾讯云大数据团队深化战略协作共同推进技术产品迭代共创场景解决方案持续增强实时数据计算与分析能力。未来关注的重点能力包括AI FunctionTCHouse-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、搜特征