汽車之家資料庫服務化平臺從0到1的實踐過程

導語： 本文根據藺瑞超老師在2018年5月12日【第九屆中國資料庫技術大會(DTCC)】現場演講內容整理而成。

藺瑞超  汽車之家高階資料庫專家

汽車之家MySQL技術負責人. 負責公司MySQL的運維體系建設, 以及資料庫相關平臺設計和實現工作。

摘要： 分享一下汽車之家資料庫服務化平臺從0到1的實踐過程。詳細介紹平臺的整體架構，技術棧以及各系統模組的工程化實現方案。希望給正在做資料庫自動化，平臺化的同學一些借鑑和啟發。

服務化平臺目標及發展歷程

汽車之家整體平臺的目標是實現資料庫運維自動化、自助化、服務化。目前，智慧技術發展迅速，智慧運維成為主流，汽車之家後續也將朝向智慧化發展。

2014年之前汽車之家資料平臺基於SQL Server，2014年之後開始使用MySQL，目前，兩個體系同時使用，平臺建設相容SQL Server和MYSQL兩套體系。2014年，汽車之家基本是純手工，做了一些標準化的工作和一些規範的制定以及落地。2015年，主要做一些工具化的東西，比如寫一些自動化相關的指令碼工具。2016年，開始逐漸構建系統來解決問題。2017年，為了配合公司私有云的戰略，把資料庫服務作為服務平臺去建設。未來，我們會向智慧化運維方向進行探索。

服務化平臺技術棧

汽車之家目前平臺的技術棧主要基於Python加Go，包括社群的一些比較優秀的元件。

服務化平臺系統架構

 

這是汽車之家的基本系統架構，最底層是MYSQL、SQL Server，現在在跟進分散式資料庫的評估，後續會有一些相關場景的落地。之上是基礎元件、資訊採集層。基礎元件主要包括運維的基礎設施。資訊採集層包括元資訊、效能資料以及查詢日誌等。然後在這些資訊的上層做了很多運維、資料相關的元件系統，完成我們的運維工作。

整體架構的上層是一些服務的Portal，主要是面向開發同學和DBA同學的服務單元。灰色部分是在做的以及未來的考量，藍色部分和綠色部分是已經實現的功能。

運維設施

服務的自動化構建，是開發同學提出資源申請, 一直到服務交付的完整流程。我們主要實現了資料庫服務的自動化部署，包括MySQL叢集建設、SQL Server部署 以及Slave自動構建。

整個實驗方案是基於Salt來實現的部署模組，部署採用Celery分散式非同步任務框架來做任務的非同步化。整個流程會結合系統平臺部的資源申請和裝機的流程，協調互動。

服務化自動化架構

這是整個架構，從服務申請到資源交付的全流程實現。系統平臺系統提供流程申請以及裝機, 之後和我們DB自動部署平臺做互動，請求過之後, 我們會非同步和salt做互動。

基於Salt實現了兩個部署模組，分別支援SQL Server和MySQL，未來開發模組來支援分散式資料庫的部署。

服務化自動化構建

 

在請求過來之後，DBA對它做一些配置, 比如選擇版本和埠, 例項數量等資訊。

選擇完之後進行非同步部署。

可以在這邊看到它的狀態和日誌情況。

這邊會把最終部署結果反饋回來，如果有問題，DBA同學需要去處理。

備份恢復體系

做DBA運維, 備份恢復是我們最重要的一塊工作。目前的備份由全備和日誌增量來實現，整個備份過程中需要加密，然後進行恢復較驗。

備份恢復體系，由DB伺服器端做備份，透過備份程式把整個備份推到Buffer Storage。整個過程它會把備份資訊寫入我們平臺的資料庫，整個階段都會跟元資訊做相關的互動。這一共分為4個流程,從開始備份到上傳Buffer環境，在Buffer環境做一個資料恢復性較驗，最終把整個資訊更新到我們資料庫裡，來後續供我們備份恢復或者叢集構建的時候使用。

高可用架構

關於高可用，我們主要還是傳統型的HA方案。

整個公司多個機房之間部署了內部DNS解析服務，所有的業務和DB之間的互動全部都透過DNS來做。整個基本的架構就是MHA加半同步。MHA提供原有功能對DNS做支援。運營解析會有對應介面，我們切完之後可以實時更新DNS Cache，讓它生效，這樣可以保證切換時間對業務影響比較小。對於SQL Server，我們引入了Always ON來實現秒級HA方案。

未來我們主要考慮基於MySQL叢集的一些技術，以及分散式資料庫技術來實現真正的高可用方案的升級換代。

SQL實時分析

SQL查詢的分析，目前我們透過MYSQL 的Slow log以及實時查詢取樣來進行實時分析。整個實現方案透過HEKA元件，我們可以把日誌流做實時採集，然後推到Kafka。另外，我們把TiDB的SQLParser剝離出來，用在這個地方。消費端主要做格式化和資訊落地，落地完成之後做統計分析，除此之外就是視覺化。

HEKA實時採集

 

這是大家都很熟悉的Slow log的格式，在Slow log裡的SQL就是這個樣子。

這塊主要對Slow log按照一定的規則做split，把split內容用一套正則做模式匹配，把對應的關鍵指標提取出來，最後就形成了這個格式。這個可以直接的推到kafka，然後消費端對資訊進行解析。

這是一個實時的SQL資訊，我們用的元件vc-mysql-sniffer，可以生成固定的日誌格式，這個日誌格式分析完之後就是這個樣子。

最終我們可以拿到SQL的執行時間，SQL的來源以及SQL執行的Database等資訊。把這些資訊實時的推到Kafka之後，就可以做相關的消費和解析。

SQL實時分析

這是我們解析的架構，由HEKA把Slow log 和我們採集的SQL的Log實時化的推到Kafka，Kafka把這些資訊推到訊息系統。我們在消費端實現了資訊的消費，然後透過parser做解析，生成特定的格式進行落庫，落到我們的MetaDB，再透過MetaDB上的計算任務做統計。後續我們可能會把美團開發的SQL Adviser引入到這個流程。Error Log也是透過同樣的機制採到ELK裡，供我們後續做一些相關的分析使用。

資料設施——需求

 

資料傳輸的型別主要是全備和增量；功能需求主要包括資料脫敏、抽取任務的延遲情況、結構變更感知和異構傳輸同步。另外，整個系統要簡單、靈活，讓DBA能夠解決常見的問題，能夠很快的做響應。

CDC獲取及技術選型

關於變化的資料獲取，常見方案有這幾種, 日誌解析，用Trigger或類似方式記錄資料變更，還有一種就是基於時序的SQL邏輯抽取。我們採用的方案有兩個，一個是邏輯抽取(AutoLine) 和BinLog解析。

AutoLine（邏輯抽取）

——邏輯複製

AutoLine本質上是一個分散式的排程系統。

如果站到一個表的資料角度來看，整個時序就是這樣的一個情況，不斷的有資料在變化。

這些資訊怎麼獲取、抽取、怎麼把它遷移到需求地呢?

在一個點對整個表做一次歷史資料的抽取，之後根據它的資料修改時間把它的增量資料抽取出來，把增量部分落置到對端，每一張表都是這樣的邏輯。

如果表特別多的時候，也就是多個任務做小單元化的資料抽取，就把所有的單元變成任務，所有的任務都可以被排程。實現的方式其實很簡單，增量的同步肯定要獲取增量的資料，我們實驗的這套系統就可以支援異構的資料庫，並且它還可以按需擴容和故障自愈。

 

整個系統架構本質上是排程系統，基於Celery非同步任務框架來實現的 。系統設計的時候會有不同的優先順序佇列。

下邊的Worker執行每個任務單元。Worker是可以人為控制的，可以根據任務量判斷給多少Worker。

現在我們的系統分了全量、增量，增量裡面又分為分鐘級和小時級的排程，因為每個組的排程頻率是單獨可控的，所以只要排程正常，每個分組裡的任務狀態正常，並且不斷的有Worker來執行各種任務的小時排程單元，就可以實現整個資料的遷移。

Worker在執行一個任務片的時候，任務片可能會因為意外情況導致失敗。於是有了任務片故障自愈功能。任務片出現了問題之後，它的狀態會自動歸為可排程狀態。排程完成之後會更新任務的元資訊來表示資料遷移到了哪個時間點。

結構感知是一個邏輯抽取，不適合做結構感知。所以，我們基於這套框架做了結構對比度的功能，它會定期的校驗任務的主庫和配置的資訊是否對等，如果不對等會觸發一個結構同步動作，然後進行更新。

所有的任務在排程的過程中都是互相獨立的，每一個任務都可能會延遲，這個延遲時間在做計算的時候是有要求的。我們會根據它所在組的排程區間對它做延遲校驗，如果它延遲了，我們會把相關的資訊反饋到系統層面，讓相關同學去處理。

透過觀察我們排程系統的介面，我們可以實時監控任務執行情況。

在增量的情況下，任務執行效率很高，幾秒鐘之內就可以將任務片遷移到目標庫。

日誌解析——技術選型

對於技術選型，開源元件有很多，比如Alibaba Canal、Linkin DATABUS、Tungsten replicator、MaxScale CDC等等。透過評估, 選擇了自主開發，用Python(團隊比較熟悉)來實現日誌的解析。

日誌解析

整個系統有幾個核心的元件，第一個是日誌解析，也就是把自己偽裝成一個Slave，然後不斷的獲取Binlog的Stream裡面的Event來做相關的處理，它會把Event的資料換成Json格式，序列化後投遞到Kafka。

在整個解析中，我們加入了一個冪等訊息分發。在異常的時候，Kafka因為一些異常的情況會導致訊息重發，因此我們為每個訊息生成了一個MD5值，訊息端可以基於這個值做訊息的冪等性校驗。

還有一個是解析端高可用，就是我們在做日誌解析的時候，如果我的主庫或者解析源掛掉，可以換到下一個節點去做解析。

快照處理

 

做資料接入的時候，會需要一個歷史資料，於是我們引入了快照處理的模組。這個模組利用了一個MYSQL特性，因為我們使用的版本是Percona，Percona把Consistent Snapshot從MariaDB取過來，在此基礎上實現了一個session克隆。當開多個執行緒的時候，可以用同一個Snapshot去抽取，實現真正的併發。

快照的建立，首先連線資料庫要開啟RR模式，然後透過START TRANSACTION WITH CONSISTENT SNAPSHOT命令開啟快照，這個快照可以拿到Binlog的位點，然後透過函式可以拿到當前連線的session id。

日誌應用

當Snapshot、Binlog都存在的情況下， Apply端消費對應任務的topic，處理資料的Snapshot，然後做Apply增量。因為已經有位點了，每一個Json訊息裡面都會包含訊息對應的Binlog的位置和它的file，這樣就可以做增量的消費，在消費過程中，如果對資料準確要求很高，可以對每一個訊息做校驗。

系統結構

這是當前系統的架構，有Dumper解析模組，還有Snapshot，主要做集備做併發執行，把訊息以同樣的格式提供到訊息緩衝Kafka系統，消費端就可以基於Snapshot加解析端增量來實現實時化的消費。

目前的訊息端可以支援這幾個方面：

• SQL Server、MySQL

• 實時計算平臺

• 快取更新策略

• 搜尋引擎索引的實時更新