企业官网建设流程全解析

导语

随着盖雅全球化业务的推进，盖雅面临不断增长的数据规模与越发复杂的实时分析需求等业务挑战。当前盖雅的报表平台在月结期高峰时间段，存在数仓负载过高的威胁，在某些极端情况下，会引发查询响应迟滞、性能下降等问题，导致客户体验严重受损。为解决上述问题，近期盖雅技术团队顺利通过引入全球领先的统一数据平台 MongoDB 分流数仓压力。

目前该功能已经成功上线，并且在某家租户完成了某个报表的改造并且完成功能/性能验收，

公司介绍

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

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

• 通过智能排班云实现AI驱动的劳动力预测与灵活调度；

• 借助实时考勤云与精益工时云精准管控工时成本；

• 利用激励性薪酬与即时支付系统激发员工效能、通过人效洞察看板掌握实时人效状态；

• 结合零工管家云与岗位外包服务打通灵活用工生态。同时，通过人效诊断培训与数字化监测服务，为企业提供从战略到落地的闭环支持。

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

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

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

盖雅报表平台痛点

当前报表平台主要通过执行预先配置的 SQL，在数仓（Doris 数据库）侧完成数据查询与结果返回。这种模式在日常访问量下可满足使用需求，但在月结高峰时段，大量报表任务叠加，数仓资源占用显著上升，导致查询链路出现明显压力，具体表现为报表查询响应迟滞、性能下降等问题。

随着业务规模扩大和报表使用人数增长，该问题的影响范围正在扩大，已对用户查询体验和业务分析时效性造成一定制约。

当前在月结场景中，某些大型客户因员工规模大、考勤数据量高，考勤员需要集中查询员工刷卡记录用于核对与结算。该类查询通常涉及多个大体量明细表关联、时间区间过滤、汇总统计，SQL 复杂度较高，单次查询资源消耗较大。

同时，该报表在短时间内集中爆发，呈现“高频+高并发”特征，导致数仓计算与 IO 压力显著上升，不仅影响考勤员操作效率，也会挤占其他客户的报表任务资源，放大整体系统负载风险。该问题已成为月结高峰阶段影响平台稳定性和用户体验的关键瓶颈。

选型思路

为了解决月结高峰期的痛点，数仓团队决定引入 MongoDB 来提高月结数仓的稳定性，支持高并发下的查询能力，针对这部分场景的 MongoDB 查询需要以下技术支持：

将部分落在 Doris 数仓的高频查询转移到 MongoDB，分担 Doris 数仓负载压力；

• 高效支持高频率查询，针对报表查询人数量比较多，有效支持高并发查询；

• 高性能，快速查询响应能力；

• 预处理数据能力，提前把数据写入 MongoDB 中；

• 支持结果集筛选功能；

• 保留支持报表数据权限功能；

• 保留原有报表功能，和原报表风格一致，不影响客户体验；

• 实施团队无需了解 MongoDB 相关技术以及 MongoDB 语法，简洁的页面低代码配置报表。

MongoDB 是面向文档的操作型数据库，采用灵活的 BSON 结构存储数据，能够快速适配业务字段变化，特别适合报表、日常快速查询等数据场景。

它支持高并发读写与水平扩展，可通过副本集和分片机制保障可用性与吞吐能力，在查询人数较多时仍保持稳定性能。

MongoDB 提供丰富索引能力（单字段、复合、全文等），可显著提升筛选、排序效率。结合聚合数仓和预处理策略，可提前将 Doris 数仓查询结果写入 MongoDB 集合，降低查询的复杂度，缩短响应时间。

同时，它支持按条件过滤结果集，与原有的聚合报表模块的 Doris 数仓查询配合，构建高性能、可扩展的数据查询体系。

MongoDB 报表架构以及方案

结合盖雅报表实际需求，以及 Doris 和 MongoDB 的各自的长处，我们将一张报表分割成三部分，即左数据集（SQL 查询）、右数据集（MongoDB 查询）、以及这两个数据集的关联条件，如下：

SQL 数据集

SQL 数据集，又称为主数据集，它具有如下特点：

• 以SQL的形式，在数仓（如Doris数据库）查询，保证实时性。SQL数据集决定了整个报表的维度。一般来说，盖雅的报表，目前主要的报表维度包括：

  1. 以人为维度，报表中一个人有一条记录

  2. 人天为维度，一个人一天有一条记录

  3. 人月为维度，一个人一个月有一条记录

  4. 组织维度，一个组织一条记录

• 在 SQL 数据集做权限卡控。

MongoDB 数据集

MongoDB 数据集，又称为副数据集，它具有如下特点：

在 MongoDB 查询，这部分的数据，往往是比较复杂的 SQL 慢查询，因此需要提前准备好，在非高峰期通过 ETL 工具从 Doris 查询以后并且清洗完成，写入 MongoDB。不保证实时性，一般来说是 T+1，或者查上月数据。

MongoDB 里面的数据查询不做权限卡控。

关联条件

关联条件是两个数据集做关联的时候，实现数据共享的机制。目前常见的关联关系包括如下：

• 人维度：SQL.personid = Mongo.perosnid

• 人天/人月维度：SQL.personid = Mongo.personid and SQL.日期= Mongo.日期

• 组织维度：SQL.unitid = Mongo.unitid

系统架构

架构特点

把业务逻辑简单，但是筛选复杂（如模糊查询、组织查询、权限卡控），并且需要强实时性的部分放在 Doris 处理，充分发挥 SQL 查询灵活、功能强大的特点，规避 MongoDB 做复杂筛选功能相对较弱的缺点。这部分查询 SQL 简单，Doris 负载很低。

把业务逻辑复杂、SQL 性能很慢的查询，在业务非高峰期（如半夜凌晨）查询好以后，用 ETL 工具写入 MongoDB。等到高峰期查询的时候，这部分提前已经预处理好的数据，在 MongoDB 查询，性能非常快。

应用实践

客户：某大型客户

报表名：月度原始打卡数据表

原报表痛点

• 月结高峰期查询请求集中，单日查询次数可达 1700+，系统承压明显；

• 核心查询依赖原始打卡表等大体量明细表，扫描成本高、响应易波动；

• 业务功能复杂，需同时支持时间区间筛选、人员属性过滤与汇总统计，资源消耗大。

原始打卡表以新增写入为主，更新操作极少，数据一旦入库基本保持稳定。结合客户实际使用习惯，查询场景通常集中在月结阶段，主要检索上月完整周期的打卡记录，而非当天实时数据。

也就是说，该类数据对实时性要求不高、对查询稳定性与响应效率要求更高，因此具备明确的架构优化空间，可通过预处理与 MongoDB 查询分流提升整体性能。

改造实践

预处理数据：每天在数仓低峰期，通过ETL工具，把最近3个月的原始打卡数据，从 Doris 数仓取出，预处理存入 MongoDB。

SQL 查询部分：大幅简化 SQL 结果集获取的逻辑，只保留人员的复杂筛选，不牵涉到复杂的具体业务数据（如打卡，考勤），同时保留了实时性（如员工组织架构变动）以及非常重要的数据权限卡控。

MongoDB 部分查询：查询阶段通过 person_id 与 月份 直接检索 MongoDB 中已预处理完成的原始打卡数据。由于在 person_id + 月份 上提前建立了组合索引，查询可快速命中，整体响应稳定在毫秒级，显著提升了月结场景下的检索效率。

• 索引优化：为常用查询字段创建合适的索引，尤其是复合索引，遵循等值查询（ESR）原则，提升查询效率。例如，对于包含多个查询条件的场景，合理设计索引顺序可以避免全表扫描，显著减少查询延迟。

• 覆盖查询（Covered Query）‌：通过确保索引中包含查询所需的所有字段，MongoDB 可以直接从索引中获取数据，无需访问原始文档，从而减少 I/O 操作，提升响应速度。

关联合并结果集：通过 person_id 关联 SQL 结果集和 MongoDB 结果集，返回给客户。

db.getSiblingDB('hronehrcore_aqs').test_report.find({tenant: { $in:["0056bdf4-7350-430b-bd47-3fa0d16dfee0","006b329b-549c-4489-a160-92d4eaa12daf","008c7701-8f76-4e47-8624-9826fe67272d","0147e043-6eb4-40c8-80bd-420096ce7ad1","017ce07a-5a68-41cc-a44f-020e0236d7d1","01810204-515f-4b35-8375-1e2f7f27802a","0187b41d-7989-499f-a12d-cf0481bf857e","01faf4a2-b22b-4c4b-8903-e694af929aa7","026a7658-52a5-42dd-8452-7ea0352a4915","0281afea-1e76-46ff-b706-4ea626430818","02ea6c0f-4256-4604-9df0-6fe937bf3c09","02f786f0-93e6-4ba4-8176-a49cd5970874","03134c59-01b7-4635-867d-29c5522ac01c","03482717-5c19-463c-94fb-9b3f872fb0a0","036b01c8-223f-412f-86e1-9ae5e92d71f6","036c7e04-4e42-44ab-9934-6dc7629e51a1","036e0ffe-5e79-4cc5-8090-bf66dda63a16","039f5b56-3c28-4d71-aa7f-6694c1c4328d","03b12223-af09-4cf8-82eb-e59a5597ddb7","04153942-5dc7-4de0-a824-958517b836de","0442b60b-9cdd-459a-8722-5152474359f3","045cda52-9ac4-475c-831b-62000ac0e742","0469c86b-7235-40b0-9a48-c3ae9a21a3cd","04be4562-57f6-4e68-b1c3-1dbb2390fdd6","04d14c7e-7478-440d-881b-358922437455"]}time: hronehrcore}})})

改造性能提升

数仓团队做了测试对比，结果如下：

• 改造前的 SQL 报表： 查询次数 13 次 ，平均耗时 0.52 秒

• 改造后的 MongoDB 报表： 查询次数 11 次 ，平均耗时 0.06 秒

性能提升在8倍以上。同时，由于该报表的查询量接近整个集群大概10%的量，因此迁移至 MongoDB 可以大约节省10%左右的Doris资源。

收益总结

通过建设 MongoDB 报表查询链路，将部分高频、重复性报表请求迁移到更适合快速读取的文档模型中，收益主要体现在以下几个方面：

1. 有效地分流了 Doris 数仓负载。在月结高峰期，作为业务数据副本，在高并发量查询时提供分流和缓存能力，转移数仓压力。

2. MongoDB 作为数据中间副本，为数据 ETL 提供持久化介质，让数据清洗流程更敏捷。

3. MongoDB 报表结合预处理写入、索引优化，报表查询响应时间明显缩短，用户体验更加稳定流畅。

4. 更好地支撑高并发场景。在高并发场景下，MongoDB 对读请求的承载能力更强，能够更好支撑集中访问与突发流量，减少慢查询与超时风险。

5. 扩展了报表平台的数据源能力，由原先仅支持单一关系型数据库，升级为同时支持文档型数据模型，进一步提升了高频查询场景下的读取效率与架构灵活性。

整体来看，该方案在性能、稳定性和扩展性上均带来显著收益，也为后续缓存策略和多数据源协同提供了更清晰的技术路径。

未来规划

当前，数仓团队只是针对某个客户的某一个报表迈出了第一步，在性能和稳定性上都有明显提升，未来，数仓团队会探索更多的 MongoDB 应用场景，未来关注的重点能力包括：

1. 分析和改造更多的现有报表，特别是业务需求特别复杂的报表，分析和探索借助 MongoDB 提升这部分报表性能的可行性。

2. 评估纯 MongoDB 报表模式的可行性。当前报表能力仍依赖 Doris SQL 实现部分功能，后续将针对特定场景探索以 MongoDB 查询与聚合能力替代关系型 SQL 的可能性，逐步验证在满足业务需求前提下减少对关系型数仓的依赖。

3. 进一步提升 MongoDB 报表的时效能力。现阶段方案以 T+1 为主，后续将围绕增量同步、准实时写入与查询链路优化持续演进，逐步实现兼顾实时性、稳定性与性能的 MongoDB 报表服务。