作者：張恆巖，作業幫 DBA 團隊負責人

作業幫是中國領先的在線教育平台，將人工智能、大數據等技術與教育教學深度融合，打造覆蓋教、學、考、評、管、研等全場景智慧教育解決方案。在技術底層，作業幫一直尋求能夠助力業務發展的數據庫，從2022年開始調研OceanBase至今，已在多個核心業務中大規模使用OceanBase。本文詳述作業幫AI業務及多雲架構的數據庫方案和運維經驗。

AI業務挑戰及解決方案

隨着AI技術的爆發式普及，及其在各行業的深度融合，作業幫的業務場景中也逐步引入了多種AI驅動功能，如智能客服、問答機器人與AI寫作等。這些場景對RAG（檢索增強生成）架構與向量知識庫提出了更高要求，涉及大規模向量存儲、高併發檢索性能、低延遲實時響應等關鍵技術需求。同時，基於作業幫多雲架構的現狀，我們在選型適配的AI技術底座時，主要面臨兩大挑戰。

挑戰一：LLM內容存儲與審核。

你有沒有這樣的感觸？業務大量使用大模型後，會快速消耗數據庫的存儲空間。 作業幫內部有很多集羣，每天的數據增長達到10TB級別，存儲成本壓力陡增。同時，對於像AI寫作、智能問答等業務場景中產生的海量AI生成內容、用户多輪次對話，不僅需要冷熱數據並存，還有審核需求。為了減輕存儲壓力，通常會採取清理冷數據的方式，這在MySQL數據庫中，會帶來大量磁盤碎片。

挑戰二：RAG 對向量數據庫需求突增。

為了保證用户在使用產品時，擁有更快、更精確的搜索結果、業務側希望增加向量數據庫以支撐更好的產品能力與用户體驗。

起初，DBA團隊傾向於購買雲服務快速解決業務需求。但現實情況卻不允許這樣做。作業幫的應用服務為多雲架構，雲上購買PaaS服務難以實現多雲部署，若自建多雲數據庫服務，DBA團隊投入的精力與成本過高。考慮到集羣情況，即少量大集羣和大量碎片化小集羣，而不同業務對向量數據庫的規模需求差異較大，需要部署一套可根據業務規模靈活使用的向量數據庫，以避免資源浪費。

基於上述背景，當我們在選擇向量數據庫方案時，考慮Milvus與OceanBase向量數據庫兩種方案。對於前者，新增一個自運維的數據庫類型需要大量的建設工作，人力成本與時間成本較高。而作業幫其他業務早在2022就使用了OceanBase，不需要我們重新搭建技術棧，故而選擇了OceanBase支撐AI業務。

那麼，使用OceanBase怎麼解決上述技術挑戰呢？

首先，在大模型場景中，經過實測，OceanBase對存儲空間的佔用約為MySQL的1/6，可以實現對存儲成本的極致壓縮。同時，由於OceanBase的分佈式特性，單集羣的數據承載量是MySQL的兩倍以上。另外，得益於OceanBase的合併機制能夠進行碎片整理，避免磁盤碎片化問題。

其次，對於向量數據庫的需求，則使用OceanBase 4.3.5版本的向量能力支撐。OceanBase支持多雲，不需要我們重複建設，能夠快速承接AI業務，其天然的多租户架構也可以顯著提升資源使用率。11月中，OceanBase發佈了輕量化的AI原生數據庫——seekdb，能夠更好地應對碎片化小集羣的向量數據處理需求。

另外值得一提的是，OceanBase社區活躍且相比其他開源數據庫擁有更高的支持力度。當我們在AI業務中落地OceanBase時，社區版的技術人員在多方面給予我們很多幫助，如各種查詢性能優化、召回效果優化、SDK使用問題等方面，顯著降低了向量數據庫的上線週期。

作業幫多雲架構設計與優化

上文提到作業幫為多雲架構，在AI業務中部署OceanBase時，需要綜合考慮：

• 多個機房和多雲之間專線故障的問題；
• 多雲架構中業務對降本增效的要求；
• OceanBase與雲原生服務的融合問題。作業幫在早期完成了雲原生改造，業務基本部署在K8s中，而OceanBase不被建議部署在K8s集羣中。

多雲架構選型

對於業務租户架構的選型，可選方案如下圖所示。圖左為方案一，在三個雲上部署3 ZONE。圖右為方案二，通過跨雲的主備租户複製的方式搭建多雲集羣。

最終我們選擇了方案二，這是因為：

• 跨雲專線的耗時約5ms，如果採用方案一，性能損耗明顯；方案二的性能表現更好。
• 主備租户切換可控，遇到故障可以靈活切換方案。
• 兼容多雲專線故障場景。假設三個雲間的專線出現故障，每個雲便成為了孤島，這時方案二能夠更好地解決問題。

多雲架構設計之讀寫分離

考慮到備租户機房可以實現本地讀，減少跨雲帶寬和耗時，以及備租户承擔一部分讀流量可以優化成本，我們基於方案二增加了讀寫分離設計。

我們通過自研代理與ODP運維進行業務的本地讀，即將備租户所在機房的讀流量調度到備租户，進而實現本地讀。由於我們目前使用的OceanBase4.2.5版本的OCP不足以感知主備租户之間的延遲，因此，我們進行了針對性的改造，實現備租户延遲自動摘流。如此一來，帶來兩個好處。

一是提升資源使用率。因為備租户的資源規模和主租户相同，對於業務來説，冷備存在50%的容量冗餘，所以我們通過本地讀的方式將50%的讀流量轉化到備租户，能夠充分利用備租户資源。

二是避免一致性風險。主備租户切換往往會面臨一個問題：備租户內沒有流量時可能會有數據一致性風險或者性能承載風險。因此，將50%的讀流量轉化到備租户也可以使切換更加可靠。

對於OCP的部署方案，我們採用了比較傳統的三雲部署。這是因為我們對OCP的性能要求不高，可以接受跨雲的性能損耗。同時，由於主備租户切換的邏輯依賴於OCP，如果OCP再依賴主備租户切換就變成了循環依賴。為避免這種情況，我們需要解耦高可用之間的互相依賴。

多雲架構設計之雲原生代理

因為OceanBase不被建議部署在K8s中，所以我們在客户端和運維平台ODP中加入了一層雲原生代理。這是一個輕量級的代理，部署在K8s集羣內部，它起到兩個作用：

• 一是不完全處理MySQL協議或者OceanBase協議，而是用於雲原生的服務發現和服務觀測。
• 二是從MySQL遷移OceanBase時，可能會因為OceanBase的用户名長度被框架約束，或特殊字符存在兼容性問題，雲原生代理能夠處理OceanBase認證包，且對性能沒有損耗。用户可以使用和MySQL一樣的用户名及密碼連接OceanBase。

除雲原生代理外，我們還在雲原生層增強了ODP高可用機制的作用。這是因為 ODP在一些情況下會出現四層探活生效但SQL無法正式返回的情況，我們的做法是通過增加協議層探活，確保ODP的高可用機制完全可靠。

多雲架構設計之租户隔離及單雲閉環

為了更好的排查問題，我們在訪問鏈路中設置了租户隔離及單雲閉環。首先，將 ODP 與租户/集羣多對多關係梳理為一對一或一對多模式，這是因為不同租户 ODP 與雲原生代理獨立部署，避免相互影響，降低問題排查難度。其次從客户端到 ODP 設置單雲閉環，只有ODP到OB Server間存在跨雲，以降低跨雲延遲和帶寬佔用。

多雲方案需要配合日常演練，通常我們會進行兩類演練。一類是主備租户的日常切換，即選擇業務的某一個集羣，在低峯期切換主備租户，業務側只能感知瞬間的抖動。另一類演練以半年為週期，測試機房宕機進行主備租户的容災切換。

業務應用規模及大規模運維經驗

目前OceanBase已在作業幫多個核心業務上線，共部署40+集羣、200+租户、20000+核，還在快速增長中。從驗證到規模化部署OceanBase，用時三年。

2022年，OceanBase4.0版本發佈時，我們注意到其特性能夠解決我們在分佈式數據庫多雲部署的問題，便和OceanBase社區進行了深度交流。從2023年我們配置OceanBase周邊工具到2024年正式在AI業務和出海業務上線，期間對OceanBase進行了全方位的適配測試，包括兼容性、性能、穩定性等。

今年我們的主要工作是將核心服務加速遷移至OceanBase，因為作業幫的資源用量將近數萬核的規模，所以我們需要建設配套的規模化運維能力以支持核心業務的規模化上線OceanBase。在此過程中，我們積累了大量的大規模運維經驗。

1.將OCP融入數據庫運維平台

首要建議就是把OceanBase的運維平台OCP融入企業的數據庫運維平台，它可以在多方面發揮重要價值，降低運維複雜度，

首先，OCP有助於標準化配置，加速問題的發現和解決。作業幫多雲架構設計複雜，且包含了許多自定義的邏輯關係，雖然無法在OCP中維護，但可以通過它將自定義邏輯關係、功能或任務統籌、管理，實現快速部署，比如，用户可以一鍵完成OBServer、ODP、自研代理的部署。同時，由於每個雲上使用的資源如物理機規格不一致，也可以通過OCP將租户資源規格標準化，有效降低租户的資源碎片化風險。

其次，基於OCP建設自定義運維功能，非常便捷。例如，某些時候我們需要監控一些特殊指標，即使OCP的監控報警功能已經完善，但也不自帶該指標，就需要我們進行自建該功能；再例如主備租户的批量切換，一個一個切換太耗時，就需要在運維平台中實現批量切換的能力。在上述場景中，基於OCP能夠非常便捷地建設運維功能，實現我們需要的能力。

通過OCP運維體系，作業幫的運維服務已經實現了研發人員的自助能力，包括集羣申請、審批、成本分攤、資源水平/垂直擴容，以及SQL查詢、審計等，更好地支撐大規模業務的運維。

2.使用OceanBase的最新穩定版本

對於使用OceanBase4.X版本的朋友，建議直接升級到最新的穩定版本。我們最初使用OceanBase 3.x版本，後來升級到4.x版本，並經歷了從V4.2.1.2升級到V4.2.5.2，再到V4.2.5.6，以及在AI業務中使用最新的V4.3.5。得到的經驗是：新版本的性能、穩定性及其他功能的支持均最好。對於AP能力和向量能力的需求，則選擇AP能力較強的版本或向量能力較強的版本。

除選擇合適的版本外，我們還針對不同的業務類型配備不同的集羣，相當於將OceanBase集羣看作資源池：

• 對於核心業務，提供獨佔集羣，降低業務間的互相干擾；
• 對於非核心業務或小業務，提供共享集羣，降低機器成本和業務的接入成本。同時提供一套能讓業務人員自主遷移的方案，以便後續業務擴大或業務重要性提升時順利從共享集羣遷移至獨佔集羣。

3. 數據分佈不均衡的解決思路

在一些場景中，我們可能會遇到數據分佈不均衡的情況。例如作業幫某個核心集羣，內含4個租户，在水平擴容時，OCP顯示發起一個用户租户的unit_num擴容操作成功了。當4個租户的擴容任務都完成後，我們發現某個節點的磁盤數據持續增長甚至打滿。

經排查後得知，當OCP認為擴容任務已經完成時，均衡算法已經把日誌流的邏輯分佈好了，但是日誌流實體還沒有位於對應的位置，需要繼續遷移。因此，我們會在對應的機器上看到對應磁盤數據持續上漲。同時，由於我們當時使用的V4.2.5.2版本只考考分區數量，在擴容過程中放大了數據傾斜，最終導致磁盤空間被佔滿。

我們的做法是逐個調整日誌流所在 unit_group 解決磁盤佔滿的問題，並通過數據庫平台限制租户擴容必須在後台日志流實體完成遷移後，才能繼續下一個擴容。

對於這類情況，我們需要避免日誌流分裂時 bad case導致的不均衡，OceanBase 4.2.5_bp4版本修復了該問題，可將數據庫版本升級至V4.2.5_bp4及更高版本。另外，建議將Balance 相關的表確認負載均衡任務完成，觸發一次分區均衡，待分區均衡完成後再對其他租户unit_num 進行調整。

4. 避免租户 unit_num 擴容後長時間不結束

這是使用老版本的一個常見問題。可以查看 transfer task history 表，若顯示錯誤碼 -7114，就是因為transfer 時有活躍事務導致unit_num擴容後無法結束。 對於該問題的解決辦法：

• 對於V4.2.5_bp2之前的版本，等待活躍事務完成後再執行transfer，或者由 transfer 主動殺死活躍事務。

alter system set  _enable_balance_kill_transaction = 'true' tenant='xxx';

• 若使用V4.2.5_bp2 和 V4.3.5 及更高版本，推薦打開 transfer 不殺活躍事務的特性就可以解決。

alter system set _enable_active_txn_transfer='true' tenant='xxx';

5. 解決OMS同步鏈路延遲的方法

OMS是我們常用的數據遷移工具，如果集羣承載了流量非常大的業務，可能會產生數據同步鏈路延遲。我們在使用OMS將數據從OceanBase同步到Kafka時，遇到了這個問題。

主要原因是作業幫所有的核心服務都要經過大數據平台的數據採集，當上遊寫入壓力過大時，便會導致下游的數據同步延遲。對此，由於作業幫是多雲部署的集羣架構，優化方式比較複雜，具體包括：

• 將多雲部署的 OMS 的 store 和 incr-sync 調度到離上下游更近的實例中。
• 通過拆分租户，拆分任務等方式控制單個鏈路的寫入壓力。
• 使用 oms connector_utils.sh 工具分析性能瓶頸，根據提示修改相關配置
  • 加大併發：sink.workerNum=64 ；
  • 調整大內存：coordinator.connectorJvmParam 20-30gb ；
  • 調整 source.useBetaListener=true 使用 LogMessage 加速解析，減少中間對象；
  • 調整 source.useSchemaCache=true 使用 Schema 緩存，減少中間對象。

總結

總的來説，OceanBase在作業幫AI業務落地的關鍵契機在於兩方面：一方面是大模型業務帶來了存儲數據的指數級增長，原來的MySQL難以支撐；另一方面源自RAG服務對向量數據庫的需求。而OceanBase的功能、性能、穩定性等測試結果都符合我們的預期，能夠切實解決業務痛點，且適配多雲架構。

使用OceanBase後，大磁盤存儲成本相較MySQL降低了40%~50%，在業務快速增長的情況下，業務快速增長的情況下，避免了頻繁分庫分表。此外，我們提供了基於標準的多雲向量數據庫方案，提升了業務研發效率，真正詮釋了什麼是數據庫技術助力業務發展。

目前作業幫的數據庫SLA標準達到99.99，藉助OceanBase的運維工具，我們打造了自動化運維、自動化遷移，運維保障體系愈發完善，實現了業務人員的自助運維。