現今，網約車已成為民眾日常出行不可或缺的選擇。伴隨“互聯網+出行”模式的快速推進，龐大的出行數據應運而生，如同構建了城市交通系統的數字神經脈絡。與此同時，對高效數據存儲與深入數據分析的需求也在持續攀升。
T3 出行于2019年應運而生，是由一汽集團、東風汽車和長安汽車這三大中央企業聯手創建的智能出行服務平臺。歷經五年的蓬勃發展，T3 出行的日訂單峰值已躍升至300萬以上。隨著T3 出行業務的急劇擴張，一個穩定可靠、高性能且安全的數據庫系統變得至關重要。在全面評估性能、成本等各項因素后，T3 出行決定采用OB Cloud 作為數據庫技術的堅強后盾。
1、T3出行的數據庫挑戰：海量數據下的性能瓶頸
T3 出行研發總監高建豐經常對團隊成員強調：“數據庫穩，則系統穩。如果沒有一個穩定的數據庫系統，就不可能有一個穩定的交易系統。”
T3 出行最初將其數據庫部署在 MySQL 上。然而，隨著訂單量的快速增長，傳統集中式數據庫面臨的挑戰逐漸顯現。高建豐分享道，盡管 MySQL 能夠支持很高的 KPS（每秒查詢次數），但其存儲的數據量卻非常有限。當數據量達到幾百萬條時，系統便接近其上限，從而導致性能下降和內存消耗增加等問題。
為了擴容，最常見的方式就是分庫分表，但分庫分表也存在技術局限性。首先，查詢性能、靈活性不強。通常只能按照訂單、司機或乘客等單個特定維度查詢數據，不能進行多維度的查詢。其次，數據庫的水平擴展困難，且容易造成資源浪費。根據 T3 出行的業務畫像，波峰波谷明顯，非早晚高峰時段，大量的 MySQL 資源日常閑置；而早晚高峰時段，MySQL 連接數與規格綁定，數量有限，容易出現資源碎片化，導致數據庫使用成本不斷增加。
為了解決擴容問題，T3 出行的研發團隊采用了分庫分表策略，但這一方法的技術局限性也很快顯現。
- 首先，分庫分表后的查詢性能和靈活性較差，通常只能按照訂單、司機或乘客等單一特定維度進行查詢，難以支持多維度的復雜查詢。
- 其次，數據庫的水平擴展變得更加困難。早晚高峰時段，MySQL連接數與規格綁定，容易出現資源碎片化，導致數據庫使用成本不斷增加，而在非高峰時段，大量 MySQL 資源處于閑置狀態，造成資源浪費。
- 另外，即便分了八庫八表，海量數據存儲困難的問題依然存在，三四年前的歷史數據如何存儲？有人提出使用 MySQL+HBase+MongoDB 等解決方案支撐數據存儲與查詢。但一方案也帶了來新的問題：技術棧眾多。目前，T3 出行系統運行著的 TP 和 AP 類數據庫近 20 個。
“大部分運維同學是很崩潰的。”高建豐說到：“近 20 個數據庫需要耗費大量的資源和人力去維護，而且也沒有哪個運維同學對這 20 個技術棧都非常熟悉。”
而更大問題在于，數據從 TP 數據庫同步到 AP 數據庫，涉及數據復制、提取、清洗等環節，每一次數據同步都有可能引起數據延遲或丟失，難以實現 100% 的完美遷移。
為了保障系統高可用，T3 出行采用雙云雙地圖戰略，交易系統部署在阿里云上，大數據系統部署在騰訊云上，利用多云架構分散風險。但云上系統如何快速切換，數據如何流轉是 T3 出行數據庫團隊不得不面對的課題。
2、海量數據最優解：一體化云數據庫OB Cloud
基于上述問題，T3 出行開始尋求新的數據解決方案。
高建豐認為，滿足 T3 出行海量數據的數據庫，應該滿足四大條件：
- MySQL 數據庫可以快速、平滑地遷移，不需要投入太多人力資源，也無需修改代碼，要對業務層無感知。
- 替換之后，性能需要有所提升。
- 成本上，需要通過數據壓縮、CPU 資源利用等多種角度降低數據庫成本。
- 運維層面，要減輕運維團隊的工作量。
2023 年 6 月，T3 出行開始接觸 OB Cloud，并進行了大量測試。在性能、成本、遷移難度、運維等多個層面的測試結果都遠超預期，最終，T3 出行選擇 OB Cloud 作為數據庫底座。
一開始，T3 出行將司機任務、訂單監控、虛擬號、開放平臺等部分非核心業務放在作為試點，將數據量較大的單庫單表場景遷移至 OB Cloud 上。切換過程非常順利，且運行穩定，在兼容性、成本與性能等方面表現良好。高建豐對試點運行的結果做了以下幾點總結：
- OB Cloud 完善的周邊生態，讓遷移過程十分順利，無代碼適配成本。
- OB Cloud 與阿里云、騰訊云等多種云平臺靈活對接，云上數據流轉自由，有效支撐 T3 出行的雙云雙地圖戰略。
- 基于 LSM-Tree 存儲引擎，OB Cloud 可以極大壓縮數據存儲空間，解決了 T3 出行未來幾年的數據存儲難題。
- OB Cloud 原生分布式能力可平滑擴展，在早晚高峰的高并發場景下自動擴容，且在司機端、乘客端無感知。
- OB Cloud 采用多副本多活策略，能有效提高資源計算密度，業務高峰時段也保證系統性能。?
- 通過 HTAP+多模一體化，統一管理 20 多種技術棧，不但提升了系統性能，運維同學的壓力也大大減輕。
2024 年年初，T3 出行開始將訂單、結算、支付、風控、營銷等核心業務系統逐步都遷移至 OB Cloud。截至目前，T3 出行超過 50% 的業務平穩運行在 OB Cloud 之上，預計在 2025 年年初，實現所有系統的切換。
在降本層面，以會員業務為例，一開始，T3 出行對會員業務進行八庫八表的拆分，后來遷移至 OB Cloud 采用三副本方式，以單庫單表的形式支撐業務。切換之后，會員業務的成本降低超過 50%。全部業務切換至 OB Cloud 后，預計 RDS for MySQL 共 400+ 個實例，縮減至 25 個 OceanBase 集群，大幅度降低業務系統的數據存儲規模，存儲空間減少 80% 以上。得益于存儲壓縮技術和 CPU 資源利用率提升，整體數據庫成本縮減 30%。
“因為我們使用 OB Cloud 的時間并不長，在一開始設計時也做了特別多的冗余。待業務平穩運行之后，降本會更加明顯。”高建豐介紹說。
使用 OB Cloud 后，在早晚高峰的高并發場景下，T3 出行的數據庫性能提升 75%，大表查詢性能提升 12%，寫入性能提升 90%，終端的司機和乘客在使用時可明顯感知到業務的響應速度提升，整體的使用體驗也有了質的提升。
此外，OB Cloud 穩定性非常高，T3 核心交易系統搭載 OB Cloud 平穩運行，OceanBase 駐場人員運維和響應的速度非常快，一年來無任何生產事故。得益于 OceanBase 原生金融級高可用，T3 出行所有業務均實現機房級故障 RPO=0 的能力。
3、TP+AP、多模+AI，借助 OB Cloud 拓展業務更多可能
目前，T3 出行主要用 OB Cloud 替換了 MySQL 的場景，未來考慮替換 HBase、Redis 等場景，用 OB Cloud 統一管理，更大程度簡化技術棧，減輕運維壓力。
TP 與 AP 割裂的兩個系統，對人力資源和機器資源造成了極大的浪費，借助 OB Cloud 的 HTAP 能力，分析不分數據報表，進一步擴展了業務的邊界。
另外，T3 出行還考慮基于 OB Cloud 進一步探索多云部署，T3 目前面臨的雙活問題主要是網絡問題、應用問題和數據問題。網絡和應用雙活容易實現，底層的數據雙活可以借助 OB Cloud 來支持，屏蔽不同云廠商之間的底層差異，實現跨云主備庫、雙活能力，探索業務跨云災備能力的實踐。?
OceanBase ?現已支持 365天 免費試用，點擊立即開啟 >>?
