導語：面對HTAP能力的需求與雲原生時代的趨勢，以及國產化的浪潮，某郵儲銀行攜手OceanBase打造了雲原生時代下的國產分散式資料庫場景實踐體驗。以下內容整理自某郵儲銀行運維方DBA的自述。
業務痛點
我們有一套針對業務內部的運營資料歸集系統，各地的服務網點都將各類生產資料、經營資料及運營資料進行上報，還有前端使用者埋點資料、各子系統生產資料表單彙集，資料來源的格式多樣，資料聚合程度不一，計算方式複雜多樣。目前，我們採用兩種方式進行資料採集。
- 人工上報：透過員工自行製表、填表將資料上報至系統中的固定頁面，進行運算。
- 機器抓取：一些老系統或無法提供介面，就需要透過RPA自動化機器人抓取資料，這是整個基礎資料的來源。抓取資料後彙總，並用Java在程式中進行計算，將資料沉澱至報表，以供前臺實時讀取。
面對每天的資料增長，而且內部運營系統的資料不能直接完成實時分析，需要將其彙總成特定格式進行轉換計算，做成戰略皮膚，提供頂層決策分析能力。我們使用的資料庫系統是MySQL，在大眾印象中，MySQL側重於OLTP(聯機事務處理)，在OLAP（線上分析處理）方面的效能如高可用、備份等方面表現較弱，這些痛點在我們使用MySQL的過程中也確實感受到了。而隨著我們業務併發量的提高和資料量的增長，既要求較強的OLTP能力，又需要OLAP能力的支撐，且軟硬體及服務成本不斷升高。面對傳統關係型資料庫的許多技術難題，比如海量資料下sacle in or out（彈性擴充套件）的算力不足、不能原生解決單點故障和全鏈路高可用、OLTP+OLAP場景無法實現一體化，我們決定探索HTAP（混合事務分析處理）資料庫，實現降本增效的目標。
產品調研
在決定探索HTAP資料庫後，我們最先了解到的是OceanBase。因為公司有一個專案正在使用阿里雲的PolarDB，但PolarDB必須在雲端部署，而我們的業務需求是本地部署，所以，OceanBase成為我們的首個研究目標。OceanBase相容MySQL的特性很吸引我們，而最終選擇OceanBase是出於以下幾個因素。
- 因素1：穩定可靠。 OceanBase十二年穩定可靠的產品力和在支付寶全核心場景替換MySQL的實踐，以及應用於眾多行業多個大型客戶核心場景，為我們在業務場景中使用它建立了信心。
- 因素2：AP效能優秀。 在類似的OLAP場景中，我們曾經使用過GBase、PostgreSQL、Greenplum，在複雜的SQL查詢方面速度較慢，並且當使用者量大的時候再連線這些資料庫，都會出現各種各樣的問題，也有可能是我們自身資源不足的導致的。我們在測試OceanBase的效能時，採用現有環境即2核40C80執行緒、256GB記憶體的環境，測試了TPS和QPS， 以下是在3000併發量下Sysbench的讀寫混合測試結果。這個測試結果完全滿足了業務要求。
SQL statistics:
queries performed:
read: 2405494
write: 687284
other: 343642
total: 3436420
transactions: 171821 (2859.31 per sec.)
queries: 3436420 (57186.17 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 60.0903s
total number of events: 171821
Latency (ms):
min: 29.15
avg: 104.83
max: 414.93
95th percentile: 155.80
sum: 18012703.78
Threads fairness:
events (avg/stddev): 572.7367/30.91
execution time (avg/stddev): 60.0423/0.02
因素3：運維簡單。 目前的業務需求需要在AP與TP之間找到一個平衡點，如果AP場景和TP場景使用不同的資料庫，勢必會增加技術棧的深度，增大運維難度，而業務對於兩種使用場景並不是強依賴的關係。使用混合型的HTAP產品，無疑是最好的選擇，也是一種良好的探索與嘗試。OceanBase運維簡單，只需一套OCP工具就能搞定。且系統告警提供了豐富的擴充套件功能，可以與現有監控對接。運維人員每天只是關注重要數值，觀察有沒有報警，運維管理比較輕鬆。
因素4：國產化趨勢。 我們無法預料MySQL在未來是否會被限制，也無法確定是否所有系統都會逐漸成Linux，但可以肯定的是要防患於未然。因此，研究完全國產自研且開源的資料庫是一條出路，未來如果真要替換全部系統，至少到那時我們已經有一定的技術積累和沉澱，能夠應對引進軟體限制的問題。
因素5：適用業務且容錯。 OceanBase主打HTAP，具有高可用和容災能力，非常適用於我們的業務。同時，我們要應用資料庫的系統不完全是生產系統，而是一個後臺的報表，它處於核心系統與邊緣系統之間，有一定的容錯性，因此，決定先在這個報表環境中嘗試使用OceanBase。
因素6：及時響應。 OceanBase開源後社群活動與響應都很積極，雖然有些生態還在完善，但是能感覺到OceanBase開源的產品力在顯著提高。
場景實踐
決定使用OceanBase後，我們開始了環境部署，表1列出部署引數。
圖1 OceanBase三節點部署架構
上文提到，隨著業務資料量的增大，我們原本使用的MySQL不符合業務要求，部署OceanBase後，我們開始重構系統和底層資料底座，經歷了以下四個階段。
第一，POC階段。 “如果有什麼問題或者和MySQL不一致，你們就直接報錯，我們看如何解決”，這是我當時對OceanBase的研發支援人員說的話，但我驚喜地發現，OceanBase能夠與我們使用的MySQL 5.7.18版本良好相容，可以輕鬆實現零成本遷移。在此過程中，我們遇到了兩個問題，一是SQLSTATE[0A000]: Feature not supported: 1235 while parameter _ob_enable_prepared_statement is disabled, prepared statement not supported，透過引數調整，輕鬆搞定；二是應用資料的遷移人員在使用Navicat進行遷移的時候，出現了一些結構化語句不相容的問題，我們驚喜地發現Navicat16.1版本開始，有了OceanBase的專用驅動連線，使用後相容性問題完美解決。
第二，資料遷移階段。 我們使用了OceanBase 遷移服務（OceanBase Migration Service，OMS）完成了MySQL資料的線上無縫遷移。
第三，資料庫側改造階段。 我們的應用測試基本不用改造，就將MySQL的分割槽資料、表結構等遷移到了OceanBase，並且一切執行正常，查詢效能和查詢效率都超出預期。同時，對於開發人員來說，他們無需投入學習成本，在OB上操作與此前在mysql上無異。
第四，實際上線階段。 在該階段，我們暫停了業務寫入，等待系統遷移完成，並在新業務流量寫入OceanBase叢集后，觀察業務波動。割接後近一個月的試用，系統執行穩定，分析資料處理時間縮短到了原來的1/3，達到了我們的使用預期。
業務收穫
以上就是我們應用OceanBase的實踐過程。從業務角度看，在此次的資料庫實踐中，我們有五點收穫。
- 原生的高可用體系： OceanBase基於PAXOS協議高可用，避免單點故障，RPO=0。
- 無感知的DDL： OceanBase DDL無感知，可以加快業務迭代效率。
- 完善的管理平臺： OCP平臺整合了部署、監控、診斷等功能，大大降低了運維與開發成本。
- 線上擴充套件能力： 後期業務資料體系可以透過橫向增加機器資源實現scale in or out。
- 賦能HTAP能力： 資料讀寫與實時統計分析場景用一個資料產品解決。
當然，對於OceanBase，我們也有三個期望與建議。
- 希望OCP實現整合效能測試。
- 使用SATA硬碟實際測試出的TPS是官網的1/2，建議使用SSD作為硬碟儲存。
- 期望OceanBase能在更多場景替換MySQ，並不斷完善其三地五中心等高階能力。
不得不說，隨著國產化浪潮和雲原生趨勢的推動，企業對資料產品的要求日趨增高。面對老牌資料產品的能力，或許勇於嘗試一些優秀的新型產品才能找到良好的解決方案。此次對OceanBase的探索，讓我們解決了以往在高可用、線性擴充套件、儲存成本等方面遇到的難題，並且，在擁有了HTAP能力的同時還能持續降低業務成本。