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

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

（一）數據的產生

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

• 數據采集：存在車型多樣、解析規則復雜、數據包體積大、需要永久保留等特點。

• 數據處理：存在數據量大、時效性要求高，處理過程復雜等特點。

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

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

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

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

（二）數據的處理和使用

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

第一階段是脫敏階段。在采集回來的數據，先逐幀進行敏感的數據定位和模糊，并且將數據中存在的敏感數據脫離。

第二階段是推理階段。在脫敏完成后，會進入推理階段，這時需要在每一幀的數據上進行打標簽分類，并對標簽進行管理，便于以后的數據查詢和篩選使用。

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

第四階段是訓練階段。在標注階段完成后，數據集將進行模型訓練，并追蹤數據的使用情況。

（三）數據處理應用場景

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

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

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

由于公司規模和云環境的龐雜，數據管理對于公司來講可能逐漸成為了一個嚴峻的任務，特別是當一個人負責多個云上的 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 秒之間。

（一）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 工具的優秀表現和卓越性能，確實值得表揚。它為毫末智行提供了高效、可靠和可擴展的數據存儲和處理解決方案，并為企業帶來了更好的數據管理和處理能力。

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

• 更強的數據可靠性和可用性

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

• 更強的擴展性

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

• 更低的運維成本

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

• 更低的云成本

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

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

遷移至 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 自動升級時任務失敗。并且當自動升級失敗之后，缺乏批量操作功能無法直接跳過失敗任務，只能逐一手動完成操作任務，還是比較遺憾的。

當前，毫末智行的數據量約為 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 的原因。