點擊藍字? 關注我們
本文共計3569字 預計閱讀時長11分鐘
導語
騰訊云數據倉庫TCHouse-D助力蓋雅工場構建了架構簡潔、查詢高效的報表平臺。目前該平臺已經支撐了蓋雅工場上千個租戶的實時報表需求，報表查詢時效性整體可達亞秒級，相較原架構，查詢耗時平均降低70%，整體開發效率提升50% ，資源成本降低20%，大幅實現了降本提效，深得各業務及數據部門的認可。
作者：蓋雅工場技術中臺
公司簡介
蓋雅工場成立于2009年，是一家以「科技讓勞動力更高效」為使命的中國科技企業，致力于為全球企業提供智能化勞動力管理云服務。通過覆蓋企業人效管理全生命周期的咨詢+SaaS軟件+運營服務解決方案，助力企業實現人效提升與數字化轉型。
目前，蓋雅工場的客戶分布在全球32個國家與地區，每天為全球1,800余家客戶的600余萬員工提供蓋雅的服務。
蓋雅工場專注于解決企業在勞動用工方面的四大問題：「需要多少人」、「實際多少人」、「干得怎么樣」、「怎樣找到人」，利用科技手段預測勞動力需求并排班，優化調度勞動力安排并補充靈活勞動力，管理多樣化勞動力隊伍的出勤與時間，分析并提升勞動力效率與銷售效能，同時連接勞動力市場中的企業與一線員工，實現降本增效、滿意且合規。
業務介紹及早期痛點
聚合報表服務是蓋雅工場最核心的數據服務，為上千SaaS租戶提供實時報表，覆蓋勞動力人員分布、勞動力流動、離職、考勤、薪酬和審批流等關鍵業務環節。隨著蓋雅工場全球化業務的推進，聚合報表服務積累了海量數據，上游數據來自近百個MySQL實例，原始庫表數量超5萬張，然后需要根據不同場景進行實時分析，向B端用戶提供人員分布、流動離職、考勤、薪酬和審批流等實時報表，業務報表數量達到數千張。
1. 早期架構
早期使用自建的 TiDB 和 StarRocks 集群進行支持上述需求。
鏈路1：自建 Data Migration -> TiDB
鏈路2：自研 Flink CDC +Kafka -> StarRocks
2. 問題和挑戰
隨著蓋雅工場全球化業務的推進，聚合報表服務積累的數據規模越來越大，查詢并發也越來越高，為應對不斷增長的查詢分析訴求，蓋雅自建了多套集群，運維成本和資源成本不斷提升。但即便這樣，在業務高峰期租戶集中查詢時，還是存在報表服務訪問慢等問題，導致客戶體驗嚴重受損。
1) 為了應對實時計算任務，自建了多套 Flink + TiDB/StarRocks 集群，整體計算和分析鏈路長、維護難度大，且集群異常無原廠支持；
2) 性能不足：月底和月初會帶來周期性的業務高峰，TiDB 數據庫查詢嚴重性能不足，且集群人工擴容流程冗長、擴容過程持續數小時、期間業務讀寫均受到影響；
3) 開發效率低+缺乏資源隔離：歷史 SQL 代碼執行效率低，多張表聯合查詢并通過 SQL 做權限管控，一個租戶 SQL 可能占滿 TiDB 集群 CPU；
4) 自研的數據同步服務覆蓋場景有限：TiDB集群部署較早版本陳舊，與業務側數據庫 MySQL 8.0版本無法完全兼容性，數據同步異常頻率較高；自研的 Flink CDC 同步工具覆蓋技術場景有限，需不斷迭代滿足線上場景；
5) 公司 BI 類產品無統一的數據倉庫，搭建了多套數倉庫，數據沒有實現高效共享，存在資源浪費的情況；
選型思路
為降低集群運維成本、提升實時查詢效率，蓋雅決定引入一款新的實時數倉來搭建新的數據平臺，同時希望新的 OLAP 引擎可以具備以下能力：
1)性能強，可以在海量數據場景下實現快速響應；
2)支持高并發查詢，可滿足日常業務的報表分析需求；
3)支持 Join 操作，可滿足不同業務用戶靈活多變的分析需求；
4)具備良好的資源隔離能力，降低不同租戶間的業務影響；
5)統一數倉構建，運維簡單，縮減運維人力的投入和成本的支出，實現降本提效；
6)社區活躍，在使用過程中遇到問題，可迅速得到解決。
綜合以上要求，蓋雅快速定位了Apache Doris ，Apache Doris具備強悍的多表Join查詢能力、高并發能力，完全可以滿足蓋雅日常的業務報表分析需求。除此之外，Apache Doris可以同時支持實時數據服務、交互數據分析和離線數據處理多種場景，并且架構簡單，可有效降低集群運維成本。
同時，蓋雅也了解到騰訊云數據倉庫 TCHouse-D 這款產品。作為一款云上的實時數倉產品，騰訊云數據倉庫TCHouse-D 100%兼容開源Apache Doris，具備企業級的高可用能力，且提供全托管的產品服務，可很方便的進行精細化集群管理、資源快速伸縮、數據備份恢復、異常監控及巡檢定位等操作，同時在業務開發過程中TCHouse-D還會提供專家指導，蓋雅基本無需關注集群運維，即可快速完成業務開發上線。
另外在數據同步方面， 騰訊云數據倉庫TCHouse-D無縫集成了騰訊云WeData的數據集成 ，通過白屏化操作即可高效實現業務庫到TCHouse-D的實時數據同步，并支持自動批量建表、字段類型自動映射、高負載情況下自動限流等功能，有效提升遷移效率并保障業務穩定。
新的架構及方案
基于以上優勢，蓋雅最終選擇與騰訊云大數據合作，并采用騰訊云數據倉庫 TCHouse-D + 騰訊云 WeData 來搭建新的實時報表體系，架構如下：
源端 MySQL 數據經過 WeData 的數據集成進行自動數據轉換后，入庫到 TCHouse-D 中進行聚合分析和實時自定義分析。另外為保障數據安全，針對關鍵業務還創建了主備集群進行容災，若主集群發生業務問題，可快速切換至備集群，避免長時間業務影響。
數據流向如下圖所示：
應用實踐
1.庫表設計
考勤業務是蓋雅產品的核心功能，而考勤中的一個核心點是“時間”，因此在初期設計階段，為了更好地發揮騰訊云數據倉庫 TCHouse-D 的性能，蓋雅技術團隊結合專家建議，參考以下實踐進行了庫表設計：
Key列選擇：將最常用的查詢條件字段加到 key 列，區分度越大、頻次越高的查詢字段越往前放；
分區設置：基于時間創建Range動態分區，提升查詢性能的同時，可支持分區的生命周期管理；
分桶設置：先對表的數據量進行預估，視情況配置分桶數，保障每個分桶大小保持在 1-10G 之間；
索引設置-盡量命中前綴索引：最常?的查詢字段盡量放在表的最前面，以此命中前綴索引；如果不能，放到分桶字段?；
索引設置：大基數列（5000以上，如身份證號）進行“in”或者“=”查詢時，選擇 BloomFilter 索引；
索引設置：非主鍵列查詢，引入倒排索引進行加速；
副本設置：考慮數據安全，副本數設置為3。
2.表原子替換
在考勤月結期間，考勤員為了獲得員工本考勤周期最準確的考勤結果，通常會發起批量重算員工考勤記錄的操作。由于此場景下業務表無法設定一個增量字段來存儲數據，后端的處理動作是先刪除歷史數據再寫入最新數據(亦即批量全刪全寫)，這給 BI 分析師構建員工每日考勤模型帶來了相同困境。早期他們采用全刪全寫，但勢必會存在后端在刪除、前端客戶在查詢的現象，造成無法查看數據的異常。
為解決此場景痛點，數據工程師使用“表原子替換”功能，通過 CREATE TABLE LIKE 語句創建一個相同結構的新表，將新數據導入新表后，即可通過替換操作原子替換舊表，過程中實現數據版本的秒級切換，全程對業務透明。類似的場景，在蓋雅的業務中還有很多。
----- 創建新表（保留原表結構）
CREATE TABLE new_table LIKE old_table; ?----- 導入新數據（全量）：
INSERT INTO new_table SELECT ...; ?----- 原子替換（零中斷切換）：
ALTER TABLE old_table REPLACE WITH TABLE new_table
[PROPERTIES("swap" = "true")]3.數據管理
數據質量的好壞直接決定了數據同步、數據查詢的效率，對后續業務實施尤為重要，所以在數據管理方面，蓋雅技術中臺制定了約束規范：
數據庫/表命名：不支持以數字開頭，中劃線-命名；
數據表主鍵：必須有獨立的主鍵且主鍵列長度需<160（注：特殊場景，如業務表無獨立主鍵而是聯合主鍵，聯合主鍵第一個欄位需存儲經常變化的數據，且聯合主鍵欄位總數<=3，聯合主鍵欄位總長度需<160）
業務表管理：禁止修改字段名稱(包含欄位字母的大小寫互換)
數據存儲：欄位中存儲的數據總長度需<65533字節，如業務庫表中存有圖片base64、html等超文本的數據，此類的數據表無法進行同步
4.數據同步
使用騰訊云 WeData 進行MySQL數據實時同步，同步過程中無需進行SQL/代碼開發，即可自動進行一鍵自動建表、字段類型映射、數據精度對齊、DML過濾、DDL同步等操作，大幅降低了操作成本，且過程中WeData會實時監控TCHouse-D的集群負載情況，進行自動限速，保障集群健康。
5.數據備份與恢復
使用TCHouse-D的備份恢復功能周期性的將數據導入到對象存儲COS中進行備份，避免數據誤刪除或丟失的情況發生。比如當因某些原因導致Flink同步任務失敗、無法從 Checkpoint進行啟動時，可讀取最新的數據進行同步，歷史缺失數據通過外部表進行修復，使得同步任務能夠快速恢復。
6.監控告警
將騰訊云產品（騰訊云數據倉庫TCHouse-D、WeData數據集成）兩類告警接入蓋雅飛書，做到實時預警。
另外對于重要的單表，我們還會通過程序進行比對，如比對業務庫數據和TCHouse-D的數據，來進行數據質量、報表質量稽查告警。
收益總結
蓋雅工場將自建TiDB+StarRocks完全遷移到騰訊云TCHouse-D上，借助其向量化查詢、數據預聚合、豐富的索引等方式實現了查詢性能的巨大提升，通過TCHouse-D的集群彈性伸縮能力實現快速擴縮容，并配合合理業務拆分+Workload Group資源組的方式對集群內租戶進行資源隔離，充分避免不同租戶見的資源搶占。配合WeData數據集成，實現全程自動化同步與智能限流，避免集群過載。
1.性能提升：同配置下TCHouse-D 2.0比TiDB查詢效率平均提升70%；
2.彈性伸縮：基于全托管的TCHouse-D+專線實現多云統一數據報表，業務高峰快速水平擴縮容。
3.開發運維降本：統一技術棧，標準SQL開發，開發效率提升50%；無需關注集群運維，運維成本大幅降低；
4.成本降低：通過性能優化和架構整合，TCHouse-D對比TiDB+StarRocks節省20%成本。
未來規劃
截至目前，蓋雅95%的數據分析類業務已遷移至騰訊云數據倉庫TCHouse-D，并得到了很好的效果，深得各數據部門、業務部門的認可。未來蓋雅將繼續深度加強同騰訊云大數據團隊的合作，配合產品的不斷更新迭代，進一步提升實時數據處理的能力。近期關注的重點能力包括：
部分列更新：減少不必要的數據寫入和鎖競爭，降低I/O和CPU開銷，實現數據更新和查詢性能的雙重提升；
異步物化視圖：空間換時間，支持分區級數據自動增量刷新，進一步提升復雜查詢報表的性能；
基于CCR的主備容災：通過CCR實現主備集群間的實時同步，降低集群綜合負載，提升主備容災的及時性和易用性；
存算分離：升級至騰訊云數據倉庫 TCHouse-D的存算分離版本，降本的同時，進一步提升資源彈性、和資源隔離能力，更好的應對業務波峰波谷問題，并提升不同租戶間的資源隔離效果。
最后，感謝騰訊云大數據團隊，感謝其對問題的快速響應和積極的技術支持。
END
關注騰訊云大數據╳探索數據的無限可能
?點擊閱讀原文
了解更多產品詳情
分享給認識的人吧
)
