現代化資料架構升級：毫末智行自動駕駛如何應對年增20PB的資料規模挑戰？

作者：趙國良，毫末智行運維工程師

毫末智行是一家致力於自動駕駛的人工智慧技術公司，其前身是長城汽車智慧駕駛前瞻分部，以零事故、零擁堵、自由出行和高效物流為目標，助力合作伙伴重塑和全面升級整個社會的出行及物流方式。

在自動駕駛領域中，是什麼原因讓毫末智行放棄了 MySQL 而選用分散式資料庫?在進行分散式資料庫選型的時候，為什麼選擇了 OceanBase ?毫末智行運維工程師趙國良分享了這一資料庫替換到落地的歷程和實踐經驗。

1、毫末智行資料庫遷移背景

(一)資料的產生

在毫末智行大資料環境的組織機構業務中，資料的流轉主要可以分為三個週期：資料採集、資料處理和資料管理。在每個不同週期，資料也都具備其相應特點：

• 資料採集：存在車型多樣、解析規則複雜、資料包體積大、需要永 久保留等特點。

• 資料處理：存在資料量大、時效性要求高，處理過程複雜等特點。

• 資料管理：根據業務特性、資料屬性、成本等多個維度，決定了資料管理的複雜度極高。

其中資料採集部分比較抽象，難以理解，因此，我們將以毫末智行自身的案例為例，詳細講解資料採集階段的具體情況，包括：不同的資料應該如何分配任務給不同的車型、如何根據車型和硬體資訊來制定解析規則、為什麼需要永 久保留採集到的資料。

首先，在資料採集中，不同的車型會根據其所分配的任務去採集資料。這些車型可能包括家用轎車、SUV、越野等不同型別。其次，根據車型、硬體型號、雷達位置或影像收集位置等資訊，需要制定一個詳細的解析規則。由於需要考慮各種因素，這個解析規則可能相對複雜。最後，要將收集到的資料進行永 久保留處理。因為在整個訓練過程中，為了應對各種不同的訓練場景，資料經常會透過篩選的方式被反覆使用。

正是因為在資料產生過程中存在以上種種難點及問題，毫末智行逐漸萌生了從 MySQL 逐漸轉為分散式資料庫的想法。

(二)資料的處理和使用

我們的資料處理和使用可以劃分為四個階段：

第一階段是脫敏階段。在採集回來的資料，先逐幀進行敏感的資料定位和模糊，並且將資料中存在的敏感資料脫離。

第二階段是推理階段。在脫敏完成後，會進入推理階段，這時需要在每一幀的資料上進行打標籤分類，並對標籤進行管理，便於以後的資料查詢和篩選使用。

第三階段是標註階段。在推理階段完成之後，進入標註階段，在這個標註階段需要逐幀進行自動標註或者人工檢查，同時需要追蹤資料的流動。

第四階段是訓練階段。在標註階段完成後，資料集將進行模型訓練，並追蹤資料的使用情況。

(三)資料處理應用場景

資料處理階段是大資料應用中的核心環節之一，資料處理過程複雜，且資料標註具有時效性高、資料量大等特點。以下圖為例，它是對資料處理階段的一個簡單概述。

從圖中可以看出，資料處理過程包括左側原始資料中的資料採集、分解、打包到切片的步驟開始，以及資料推理、篩選、分類、自動標註，直到最終資料交付等步驟。整個過程相對複雜，且資料量大。

然而當資料交付完成後，仍然需要保留原始資料、標註結果、資料組織以及資料索引等操作。MySQL 的設計目標是面向 OLTP 場景，遇到處理這種量級的大資料量時會遇到效能瓶頸，且 MySQL 的擴充套件方式比較複雜，難以滿足資料處理階段對擴充套件性的要求。基於上述挑戰，毫末智行決定選用分散式資料庫技術路線，解決資料庫的效能、擴充套件性、可用性和資料一致性問題。

2、為什麼選型OceanBase

由於公司規模和雲環境的龐雜，資料管理對於公司來講可能逐漸成為了一個嚴峻的任務，特別是當一個人負責多個雲上的 RDS 產品和自建 MySQL 例項時，管理難度會進一步提升。以毫末智行為例，我們公司是基於多雲的環境下，每個雲上都有 RDS 產品，以及自建的 MySQL 主從例項。由少數或者單個運維單獨負責資料管理部分，不僅工作量比較大，還會出現難以集中管理的問題。特別是，當公司資料量過億之後，MySQL 的效能就會顯得較為吃力。目前，公司資料量還會以每年 5 億的速度不斷增長，這將對公司的資料管理帶來更大的壓力和挑戰。

另外由於存在大量的範圍查詢，導致 MySQL 頻繁告警的問題，無論是從運維或者研發的角度來看，單獨抽出時間和精力，利用分庫分表或者其他方式進行解決告警頻繁問題所付出的成本過高，並且時間和精力也有限。因此，這也就是為什麼毫末智行要堅持選用分散式資料庫的原因。在選擇分散式資料庫的過程中，毫末智行也瞭解過一些其他資料庫，但相比之下，團隊認為 OceanBase 更適合毫末智行的業務環境。

毫末智行選擇 OceanBase 主要是因為它具備了以下核心能力：原生支援多租戶架構及資源隔離能力、視覺化管控、高度相容 MySQL 生態等。OceanBase 自身的叢集資源管控能力相比於我們測試的其他資料庫更加優秀，它的租戶按需分配等特性也更加符合我們的實際業務需求。遷移至 OceanBase 後，為業務帶來了以下改善：

• 高可用：毫末智行一直使用公有云，最早的 OceanBase 叢集已穩定執行了六個月，雖然期間經歷了一次公有云的故障，但由於 OceanBase 自身的高可用特性，業務並未受到嚴重影響。

• 降低成本：使用 OceanBase 後，雲端成本從使用 MySQL、RDS 時的 10 萬/月縮減至使用 OceanBase 時的 4 萬+/月。此外，透過自動化和智慧化的管理方式，OceanBase 簡化了運維流程，減少了人工干預和操作成本。特別是在公司資料量增長或業務調整時期，解決了之前 MySQL 告警頻繁的問題，幫助運維人員減輕了大量的工作負擔。

• 易於管理：在 採用 OceanBase 之前，運維人員需要自行進入公有云 A 或公有云 B 中分別進行管理，或者是登入 ECS 伺服器去集中管理，這種方式非常複雜且不方便。採用 OceanBase 後，我們可以利用 OCP 進行集中管理多個叢集或在一個叢集中管理多個租戶，這樣就實現了對所有例項的統一管理。之所以沒有選擇 OCP Express 是因為它只能接管單一叢集，而我們公司已經有多個叢集的規劃，所以選擇了 OCP。

• 靈活調整：在靈活調整方面，其實公有云 20S 也可以做到靈活調整，但考慮到可能會存在較短時間的網路抖動風險，我們儘量避免不必要的風險對資料庫造成潛在影響。OceanBase 的多租戶特性可以很好地根據公司業務高峰或低峰快速調整資源並重新進行分配，大大減少了配置變更所帶來的風險。

• 效能提升：OceanBase 的效能也超出了我們的預期。在 MySQL 操作上億條資料時，即使有索引，SQL 執行時間至少會停留一分鐘。經我們的實際測試，將資料遷移到 OceanBase 後，即使是超長的慢 SQL ，執行時間能夠保持在 2 ~ 5 秒之間。

3、OceanBase在毫末智行的落地實踐

(一)OceanBase 的架構特徵

在落地部署 OceanBase 之前，我們首先需要了解其架構特性和工作流程。當一個訪問請求進入系統後，會透過負載均衡器將請求資料轉發到 OBProxy 中，再根據 SQL 的路由轉發功能，請求會被分佈到系統內各個 Zone 中的 Server 節點進行處理。

OceanBase 架構中的一些特徵讓它具有很高的靈活性和可靠性：

• 支援多雲基礎設施：OceanBase 是 share-nothing 架構，同時多租戶的特性相當於具備了雲的彈性和資源池化特性。這意味著它充分利用了雲端計算的彈性、可擴充套件性和高可用性。能夠適配多雲平臺上基於基礎設施的各類儲存系統，為企業提供了更加靈活和可靠的資料儲存和處理能力。

• 多副本策略：為了提高資料的可靠性和可用性，OceanBase 採用了多副本策略。這意味著資料在多個位置都有副本，可以防止某個位置的資料丟失或損壞。這種策略避免單點故障帶來的停機風險，在確保資料的完整性和一致性的同時，提高了系統的可用性和容錯性。

• 同城多活架構：在多副本策略的基礎上，OceanBase 實現了同城多活架構。這意味著即使在一個城市內，不同的機房也可以作為資料副本的儲存位置。這種架構確保了即使某個機房發生故障，系統仍然可以正常執行，並提供了高可用性和容錯能力。

• OMS 遷移工具：OMS 是 OceanBase 提供的一種第三方遷移工具。這種工具可以用於將資料從一個雲環境遷移到另一個雲環境，或者從一個資料庫遷移到另一個資料庫。與傳統的遷移工具相比，OMS 提供了更高的定製性，可以根據企業的需求進行定製化的遷移和資料對比。

綜上所述，從 OceanBase 的技術特徵來看，不但擁有分散式資料庫的可擴充套件性，又具備集中式資料庫的單機效能，在業務需求上兼具可擴充套件性、高可用性以及可排程性，能滿足企業在不同發展階段、不同場景當中對於資料庫的不同要求。

(二)基於混合雲的同城多活架構

上面主要介紹了 OceanBase 架構的多個特徵。接下來會詳細說明下基於混合雲的同城多活架構。同城多活架構透過利用 OMS 工具進行資料遷移，我們能夠將資料從 MySQL 叢集遷移到與它匹配的 OceanBase 叢集，確保遷移過程中的資料完整性和準確性。這種遷移過程的高效性和定製性，使得企業能夠根據自身需求進行資料管理和處理，並提供更好的資料管理和處理能力。

此外，OCP 集中管控工具的使用也為我們提供了更好的管理和監控能力。透過集中管控，能夠更好地管理和監控各個叢集的狀態和效能，確保系統的穩定性和可靠性。

在過去半年中，我們完成了數個超 10 億行資料的表的遷移工作，進一步證明了 OceanBase 的強大功能和卓越效能。這種大規模的資料遷移需要高度的技術能力和精細的管理，而 OceanBase 和 OMS 資料遷移工具的結合，使得這種遷移變得相對簡單和高效。

因此，對於 OMS 工具的優秀表現和卓越效能，確實值得表揚。它為毫末智行提供了高效、可靠和可擴充套件的資料儲存和處理解決方案，併為企業帶來了更好的資料管理和處理能力。

4、遷移至OceanBase帶來了什麼收益

OceanBase 的落地為毫末智行帶來了多方面的收益，包括：

• 更強的資料可靠性和可用性

  OceanBase 實現了城市級別的容災，相比於傳統的 RDS 服務，OceanBase 在容災方面具有更強的能力，能夠更好地應對各種故障和災難場景，確保業務的連續性和穩定性。

• 更強的擴充套件性

  OceanBase 具備動態擴容的能力，能夠實現無感知的平滑擴容。這種特性使得企業在資料量增長或業務調整時期能夠快速響應需求，而無需進行繁瑣的擴容操作，使得企業能夠更好地應對業務增長和變化。

• 更低的運維成本

  OceanBase 透過自動化和智慧化的管理方式，能夠簡化運維流程，減少人工干預和操作成本。特別是在資料量增長或業務調整時期，解決過往 MySQL 告警頻繁的問題，從而幫助運維人員減輕大量的工作負擔。

• 更低的雲成本

  與傳統的 MySQL 或 RDS 相比，OceanBase 在儲存成本和費用成本方面都有顯著的縮減。雲端成本從之前的約 10w/月縮減至 4w+/月，這為企業節省大量的成本，並提高資源的利用效率。

總的來說，OceanBase 的落地為企業帶來了多方面的收益，包括實現城市級別的容災、動態擴容能力、降低運維管理成本以及降低雲的成本等。這些收益有助於企業提高業務的連續性和擴充套件性，降低成本並提高資源利用效率。

5、實踐挑戰與解決方案

遷移至 OceanBase 後，企業能夠獲得多方面的顯著收益，但在落地過程中會遇到一些挑戰。以下是一些常見問題和解決方案：

首先，OCP 接管問題。OCP 接管 OBD 方式部署叢集時會存在許可權問題。這是因為 OBD 是使用 root 使用者進行部署，而 OCP 則要求使用普通使用者進行操作。由於OBD 和 OCP 的許可權管理方式存在差異，因此在利用 OCP 接管其他叢集時，需要確保使用正確的使用者進行操作，否則就會出現許可權不足的問題。

其次，部署問題。OCP 的備份功能能夠確保資料的可靠性和恢復性。但當 OCP 雲部署叢集時，可能會發現叢集備份沒有可恢復的時間區顯示值。這可能是由於 ob_admin 檔案的位置問題導致的。ob_admin 檔案是 OCP 用於管理備份的重要檔案，它記錄了備份的相關資訊。當 ob_admin 檔案位於 temp 目錄下時，它可能無法正確地記錄備份的時間資訊，從而導致沒有可恢復的時間區顯示值的問題。

最後，升級問題。OCP 升級 4.2.1 版本雙節點 Agent 自動升級任務失敗。這是因為在升級時，如果選擇單獨升級了 A 節點，之後手動升級 B 節點，就會導致 Agent 自動升級時任務失敗。並且當自動升級失敗之後，缺乏批次操作功能無法直接跳過失敗任務，只能逐一手動完成操作任務，還是比較遺憾的。

6、未來規劃

當前，毫末智行的資料量約為 20PB ，資料物件接近 60 億。基於過去一年的增長趨勢，以及現在的採集和業務規劃，預計資料物件的體積將會翻倍，三年之後可能會達到 180 億。

而在這些資料當中，目前它的強管理資料約為 2 億，預計三年之後它會增加至6億。針對以上資料相關的索引、特性、標籤、地址等一系列內容都會在 OceanBase 當中進行儲存。因為 OceanBase 具有高效的資料儲存和處理能力，能夠應對資料量增長和資料複雜性的挑戰。這也是毫末智行選擇 OceanBase 的理由之一。未來，對於 OCP、ODC 和 OMS 三個資料庫管理平臺，也有一些想法和規劃：

首先，我們想基於 OCP、ODC 和 OMS 打造一個支援 Web 視覺化的資料庫管理平臺。透過 OCP 對 OceanBase 提供的叢集圖形化管理能力，包括資料庫元件及相關資源的全生命週期管理，故障恢復，效能診斷，監控告警等功能，不僅降低IT運維成本與學習成本，也能夠提高工作效率。

其次，我們想利用 ODC Web 版，完成資料庫審計、資料安全管理和基礎資料開發等工作需求。尤其是在資料安全管理和基礎資料的開發等需求場景下，資料庫審計是非常必要的。雖然目前沒有時間去深入探索 ODC 的一些功能，但已經把這項工作加入未來工作規劃中。

最後，我們想利用 OMS 低風險、低成本、高效率的資料流通特性，將目前剩餘未遷移的 MySQL 資料，全部遷移至 OceanBase 中。OMS 不僅可以節省大量的時間精力，還可以讓業務資料建立在安全、穩定、高效的資料複製架構之上。這也是我們非常滿意 OMS 的原因。