從微信支付在實際案例中，許中清介紹了騰訊云分布數(shù)據(jù)庫DCDB for Postgres-XZ在數(shù)據(jù)治理過程中面臨的數(shù)據(jù)傾斜、成本優(yōu)化、數(shù)據(jù)遷移等能力，以及在解決這些問題的過程中Postgres-XZ的一系列優(yōu)化和內(nèi)核優(yōu)化，包括映射關(guān)系表（shardmap）、虛擬節(jié)點組、多維分片策略、不停機(jī)數(shù)據(jù)搬遷等功能。

騰訊云分布式數(shù)據(jù)庫DCDB系列產(chǎn)品，對內(nèi)支持騰訊內(nèi)部業(yè)務(wù)的發(fā)展，對外為企業(yè)提供強(qiáng)有力的服務(wù)，已經(jīng)贏得廣泛客戶的信任與口碑，積極推動了騰訊云的快速發(fā)展。

Postgres-XZ是什么？

Postgres-XZ是騰訊自研的，基于MPP架構(gòu)分布式關(guān)系型數(shù)據(jù)庫集群，內(nèi)部代號為PGXZ。PGXZ是面向OLTP應(yīng)用，兼容PostgreSQL協(xié)議，支持分布式事務(wù)和跨節(jié)點復(fù)雜查詢的一款分布式數(shù)據(jù)庫。目前已經(jīng)在微信支付商戶系統(tǒng)中運行近3年，管理超過230個節(jié)點和400T的數(shù)據(jù)量，也是全球最大的PostgreSQL集群之一。

PGXZ的架構(gòu)如下圖，其中GTM負(fù)責(zé)分布式事務(wù)管理，DataNode負(fù)責(zé)存儲數(shù)據(jù)，Coordinator負(fù)責(zé)對數(shù)據(jù)進(jìn)行分發(fā)、聚合等操作，Coordinator本身不負(fù)責(zé)保存業(yè)務(wù)數(shù)據(jù)。Coordinator通過將分布Key上值進(jìn)行Hash路由到各個DataNode上。

另外，PGXZ引入了邏輯路由層，在Coordinator上實現(xiàn)映射關(guān)系表（shardmap）。數(shù)據(jù)分布關(guān)鍵字（Distribute Key）先被Hash出ShardId，然后用ShardId查詢ShardMap表找到數(shù)據(jù)對應(yīng)的DataNode。路由過程如下圖：

防數(shù)據(jù)傾斜

但凡是分布式集群，數(shù)據(jù)分布不均衡和負(fù)載分布不均衡就天然存在，這叫做數(shù)據(jù)傾斜；數(shù)據(jù)傾斜導(dǎo)致會負(fù)載和數(shù)據(jù)集中在一兩個節(jié)點，進(jìn)而嚴(yán)重影響集群的擴(kuò)展甚至正常運行。 解決數(shù)據(jù)傾斜，是數(shù)據(jù)治理的最主要目標(biāo)之一。

通過分析，我們發(fā)現(xiàn)數(shù)據(jù)傾斜的主要原因：分片關(guān)鍵字（Distribute Key）本身引入的傾斜：因為業(yè)務(wù)數(shù)據(jù)本身的特征，導(dǎo)致在某個分布Key值的記錄數(shù)特別多，例如交易類業(yè)務(wù)，以賬戶ID作為關(guān)鍵字，然而某賬戶ID交易量特別大，也會導(dǎo)致數(shù)據(jù)傾斜。

首先，通過管理shardmap，PGXZ確保數(shù)據(jù)均勻的寫入DataNode。同時，通過shardmap的動態(tài)管理， PGXZ可以動態(tài)將部分?jǐn)?shù)據(jù)從負(fù)載較高的節(jié)點遷移到負(fù)載較低的節(jié)點，進(jìn)而保證進(jìn)一步的均衡。當(dāng)然，這里的分片策略不僅僅是來解決傾斜。

某些特殊情況，例如大多數(shù)業(yè)務(wù)存在2/8原則，即前20%商戶可能產(chǎn)生超過80%的交易和數(shù)據(jù)，銀行業(yè)務(wù)、社保業(yè)務(wù)、電商業(yè)務(wù)都存在類似情況，我們實際應(yīng)用中也發(fā)現(xiàn)，微信支付系統(tǒng)中的京東賬戶，采用動態(tài)遷移數(shù)據(jù)本身已經(jīng)無法解決數(shù)據(jù)傾斜的問題了，因為京東賬戶的數(shù)據(jù)量和負(fù)載要求甚至超出一個DataNode物理上限。PGXZ為了解決這種問題，引入了虛擬節(jié)點組技術(shù)，即由多個DataNode組成一個（或多個）虛擬的DataNode（組），來承載那僅有20%商戶產(chǎn)生的80%的交易和數(shù)據(jù)（如下圖Huge Key Group）。

冷熱數(shù)據(jù)分離

在數(shù)據(jù)治理過程中，成本一直是我們關(guān)注的地方。由于分布式集群本身設(shè)備采用x86服務(wù)器，相對于某些方案，成本已經(jīng)很低了。但PGXZ并不滿足，因為騰訊內(nèi)部PGXZ集群規(guī)模還在快速增長，我們可以預(yù)見突破1000臺設(shè)備之日可待；而這么大規(guī)模，全部采用高端x86設(shè)備，成本也是非?？植赖?；因此，我們提出了在數(shù)據(jù)庫層的冷熱數(shù)據(jù)分離，降低存儲成本的方案。

在大部分?jǐn)?shù)據(jù)庫系統(tǒng)中，數(shù)據(jù)有明顯的冷熱特征。顯然當(dāng)前的訂單被訪問的概率比半年前的訂單要高的多。根據(jù)經(jīng)驗來講，越是數(shù)據(jù)量增長快的系統(tǒng)，這種冷熱特征越明顯。將冷數(shù)據(jù)存儲到帶有大容量磁盤的服務(wù)器上，將熱數(shù)據(jù)放在價格更昂貴的ssd上明顯更合理。傳統(tǒng)方案是通過拆解系統(tǒng)，但PGXZ通過將冷熱數(shù)據(jù)分布存儲到Cold Group/Hot Group來大幅度降低硬件成本。

以下圖架構(gòu)是一套完整的架構(gòu)舉例，我們將PGXZ將DataNode從冷/熱、大Key/小Key 兩個維度分成四個：

每一個DataNode Group都有獨立的ShardMap空間(shard到datanode的映射表）；每一個DataNode Group都有不同的Hash策略。比如，對于每一個record，Coodinator(CN)首先會根據(jù)DistributedKey和create time判斷該record路由到哪一個group。然后采用這個group內(nèi)的hash策略、并查找這個group的shardmap進(jìn)一步路由到某一個DataNode。

Coordinator首先根據(jù)record的create time判斷是冷數(shù)據(jù)還是熱數(shù)據(jù)，然后查詢Huge Key List(PGXZ也提供接口由用戶指定)判斷record是屬于Small Key Group還是 Huge Key Group。最后在指定的Group里面通過hash和查找ShardMap找到對應(yīng)的DataNode。

為什么每個Group采用不同的Hash策略？最直接的原因就是2/8原則讓關(guān)鍵字（Distribute Key）本身引入的嚴(yán)重的分布不均勻。因此在Big Key Group我們通過(distribute key, create time)復(fù)合列將大商戶的數(shù)據(jù)hash到不同的shard，保證超大商戶能夠存儲到集群中。那么，為什么小商戶不統(tǒng)一使用這種多列的hash策略呢？因為對于數(shù)據(jù)量小的商戶，路由到一個DataNode可以避免對單個賬戶寫操作時的分布式事務(wù)和讀操作時的跨接點查詢。最后，Small Key Group(Hot/Cold)的Hash策略完全一樣，Huge Key Group(Hot/Cold)的Hash策略也完全一樣，只是他們各自屬于不同的shardmap空間。

在線遷移能力

解決了傾斜問題，我們看看看自動擴(kuò)容/縮容，越是發(fā)展快的業(yè)務(wù)，越是重視如果不影響業(yè)務(wù)運行快速擴(kuò)容/縮容。當(dāng)集群規(guī)模不足以支撐業(yè)務(wù)量的增長時，需要增加新的節(jié)點，PGXZ會自動將一部分shard從原來的Datanode無縫遷移到新節(jié)點上?；蛘弋?dāng)節(jié)點數(shù)據(jù)出現(xiàn)傾斜時，系統(tǒng)自動將shard從負(fù)載較高的節(jié)點遷移到負(fù)載較低的節(jié)點。那這是怎么做到的呢？

通過以上描述了PGXZ集群中的數(shù)據(jù)分布策略，我們分析可得到在PGXZ中，有三種類型的數(shù)據(jù)遷移：

  1. 熱數(shù)據(jù)變冷，遷移到Cold Group。這是跨Group遷移
  2. 小賬戶變大，簽到 Huge Key Group。這也是跨Group遷移
  3. 擴(kuò)容或者因為均衡的原因，在一個Group內(nèi)部的節(jié)點之間進(jìn)行遷移。

而對PGXZ數(shù)據(jù)遷移的目標(biāo)是：

  1. 不影響業(yè)務(wù)。
  2. 保證數(shù)據(jù)完全一致。

綜合上述要求，PGXZ提出了一系列解決方案。對于擴(kuò)容來說，加節(jié)點操作很簡單，但真正的難點和重點是，再保證高可用和數(shù)據(jù)一致性的基礎(chǔ)上，不停機(jī)就能完成數(shù)據(jù)的遷移。PGXZ的解決方案是根據(jù)遷移目標(biāo)，設(shè)定一系列任務(wù)(Shard Moving Task)關(guān)鍵點，并對這些關(guān)鍵點進(jìn)行拆解分析并加以實現(xiàn)。

一個分布式遷移任務(wù)（Shard Moving Task）由一個三元組（源source, 目標(biāo)target, 分片Shards）來定義：從源節(jié)點遷移分片中的數(shù)據(jù)到目標(biāo)節(jié)點。整個流程一共分成5個大步驟：遷移存量數(shù)據(jù)、遷移增量數(shù)據(jù)、數(shù)據(jù)檢驗、切換路由、清理（如下圖）：

遷移存量：顧名思義，就是將需要搬遷的分片的存量數(shù)據(jù)從源節(jié)點搬遷到目標(biāo)節(jié)點。此時業(yè)務(wù)依然在寫，為保證二者存量數(shù)據(jù)遷移不會存在重復(fù)或遺漏的數(shù)據(jù)？PGXZ的方案是是將開始導(dǎo)出存量數(shù)據(jù)和開始記錄增量這兩個動作使用同一個數(shù)據(jù)庫快照(Snapshot)。這里要說明下，在路由切換之前，這些目標(biāo)節(jié)點中的數(shù)據(jù)對外不可見。

追增量：為確保重做增量數(shù)據(jù)的同時，新的增量數(shù)據(jù)寫入順利，PGXZ采取多輪迭代的方式來追增量數(shù)據(jù)。每一輪的增量數(shù)據(jù)會越來越少（搬遷的速度比新增的速度快），因此每一輪迭代的重做時間逐輪收斂，直到收斂到某一個可配置的閾值，我們就進(jìn)入下一個步驟數(shù)據(jù)校驗。

數(shù)據(jù)校驗：PGXZ支持嚴(yán)格的數(shù)據(jù)校驗，要求遷移后，不僅數(shù)據(jù)條數(shù)一要致，而且內(nèi)容也必須完全一致。但是傳統(tǒng)的校驗需要花費很多的時間，而且，為了保證源節(jié)點數(shù)據(jù)不再新增，必須有一個加鎖（只讀）的過程。PGXZ的方案是，不是等到源節(jié)點統(tǒng)計完成之后才解除阻塞，而是統(tǒng)計校驗語句獲取快照解除阻塞；因此，所以這個加鎖的時間并不長，通常在5ms以內(nèi)。

再追變更：如果數(shù)據(jù)校驗的時間較長，這段時間源節(jié)點上又會產(chǎn)生較多增量數(shù)據(jù)，因此流程需要再次追變更，過程與第二步中的追變更完全一樣，在某一輪迭代的重做時間達(dá)到某個閾值時，開始進(jìn)入下一步：切換路由。

切換路由：切換路由需要加鎖，也就是阻塞源節(jié)點上對這些遷移的分片的寫操作，業(yè)務(wù)在這些分片上的寫操作會失敗。在路由切換完之后再解除源上的寫阻塞。需要注意的是，在阻塞寫的這段時間，切換路由之前，還有最后一輪增量迭代需要在目標(biāo)節(jié)點上重做。根據(jù)我們在現(xiàn)網(wǎng)中經(jīng)驗，這段阻塞部分shard上寫的時間絕大部分情況在20ms以內(nèi)，通?？梢宰龅叫∮?0ms。，而且由于擴(kuò)容時，并非所有節(jié)點數(shù)據(jù)都去做遷移，因此這個影響也有限。

清理：解鎖、停止源節(jié)點上的記錄增量數(shù)據(jù)的過程，清理源節(jié)點上的重復(fù)數(shù)據(jù)。

最后根據(jù)我們在微信支付多次擴(kuò)容操作中的統(tǒng)計，主要關(guān)注每次遷移鎖讀寫的時間，我們一共進(jìn)行了135個遷移任務(wù)。每一次切換路由時鎖業(yè)務(wù)的時間主要分布在20ms~25ms之前，平均阻塞時間時15.6ms。總的來說，大家感受到的微信支付等一系列服務(wù)幾乎是全年無休的持續(xù)服務(wù)的，也注意證明，我們PGXZ的遷移等運維操作，幾乎是對業(yè)務(wù)沒有影響的。

據(jù)經(jīng)驗來看，在一個分布式機(jī)器的運維過程中，除了日常巡檢和故障排除以外，大部分的自動運維工作都在數(shù)據(jù)遷移上；比如擴(kuò)容搬遷、冷熱數(shù)據(jù)搬遷等等；因此，如果能使用云服務(wù)，例如騰訊云的關(guān)系型數(shù)據(jù)庫CDB，分布式數(shù)據(jù)庫DCDB等，這類工作極大的簡化，不僅提升每一個業(yè)務(wù)的效率，還能讓大家更加專注于業(yè)務(wù)開發(fā)，提升業(yè)務(wù)價值。

以上就是PGXZ數(shù)據(jù)治理策略的主要內(nèi)容。

分享到

zhangnn

相關(guān)推薦