本文根據陳曉新老師在〖2021 Gdevops全球靈活運維峰會-廣州站〗現場演講内容整理而成。
陳曉新
建信金科 DB産品負責人
- 具有8年MPP資料庫工作經驗，建行自研新一代MPP架構資料庫龍趺MPP DB産品負責人，負責建行4000台Greenplum叢集規劃、搭建、運維和優化。
分享概要
一、研發背景
二、應用解決方案
三、運維解決方案
大家好，我是來自建信金融科技的陳曉新。很榮幸今天能夠在這裡跟大家分享我們在超大規模數倉叢集建設的經驗，我們建信金科通過引進多家合作公司的技術，聯合開發出了名為龍趺MPP DB的新一代雲原生資料倉庫。
該數倉采用中繼資料、計算、存儲三層分離的架構設計，在保留MPP資料庫高性能計算能力的前提下，同時具備高并發、高擴充性、資源動态伸縮、故障自愈等能力，為超大規模資料叢集的建設提供了基礎。
2020年3月，第一個應用在該數倉叢集上完成上線。随後，貼源、公共通路、旅程管理、集團并表、不良資産等等，都陸續上線成功。截止到2021年6月，該數倉叢集規模已經達到16000台伺服器，資料量超過9PB，每天運作上百萬作業，運作SQL達到千萬級别。
表（1）
圖（2）
圖（3）是我們整個龍趺MPP DB的監控大屏圖。可以看到，目前我們的版本是3.9.8，計算叢集規模79套，還有近24小時運作SQL數、近1個小時運作SQL數、連接配接數、資源使用率、各種健康情況等等資訊。
圖（3）
從傳統MPP資料庫，到龍趺MPP DB，這裡我們先做一個簡單的性能對比。
以建行的貼源內建應用為例，如圖（4）。目前我們貼源應用所使用的龍趺MPP DB的計算資源，和以前傳統MPP的計算資源基本相等，但是承載的資料量已經達到了傳統MPP（200TB）的5倍，也就是1000TB。
貼源每天運作7萬個作業，100萬條左右SQL。圖（4）左邊的曲線圖是我們統計的每個時間段完成的作業的數量，上面是base作業對比，上面是stage作業對比。大家可以看到，在每個時間點，紅色代表的龍趺MPP DB的作業完成數量，基本都大于藍色代表的傳統MPP 的作業完成數量。也就是說，在資料量膨脹了5倍的情況下，龍趺MPP DB的性能仍舊可以很好的滿足應用要求。
圖（4）
一、研發背景
建行在這二十幾年的數倉建設中，取得了很大的成果，但也遇到了很多的問題。傳統MPP資料庫産品，普遍存在以下幾個問題：
- 并發能力和擴充性不足，大量分庫分表造成嚴重資料備援；
- 資料的存儲和計算不分離，導緻資料庫孤島情況嚴重；
- 更新、擴容、故障恢複等操作複雜耗時長，運維成本高；
- 非雲原生架構，資源動态排程困難，且難以融入建行雲建設。
為解決上面的幾個問題，我們的龍趺MPP DB應運而生。
龍趺MPP DB邏輯架構可以分成兩個子產品，一個是管理子產品，一個是使用者子產品，如圖（5）。管理子產品主要負責基礎資源的管理、叢集建立、啟停、擴縮容和監控告警等服務。使用者子產品分成3層，也就是中繼資料層、計算層和共享存儲層。
圖（5）
圖（6）就是我們管理控制台的UI界面。所有的資源建立、銷毀、擴縮容、更新、故障自愈，以及監控等操作，都這可以在控制台上完成。
圖（6）
使用者子產品方面，圖（7）是我們的中繼資料叢集，主要用來提供中繼資料持久化存儲和讀寫、事務、鎖管理等服務。中繼資料叢集使用ETCD作為服務發現和負載均衡，使用FDB作為資料存儲層。中間的無狀态服務層負責接收和處理所有計算叢集的中繼資料請求。每一層服務都可以根據負載需求進行擴容，以提升服務能力。
圖（7）
接下來是計算層，如圖（8）。計算層裡，每個計算叢集就是一個獨立計算資源的資料庫服務，使用者可以按需對計算叢集進行建立、删除、擴縮容等操作，作業也可以在已有計算叢集間靈活調配。一套計算叢集并發和擴充能力不足時，使用者可以通過建立叢集來實作并發能力的線性擴充。
圖（8）
最後是共享存儲層，如圖（9）。共享存儲采用對象存儲來持久化存儲使用者資料，資料一次寫入，所有計算叢集共享使用。通過利用對象存儲的海量檔案存儲、高并發、資料高可用性和持久性等能力，滿足了應用海量資料存取、高作業并發、資料安全等方面的需求。
圖（9）
二、應用解決方案
通過采用龍趺MPP DB這樣一種服務分層，資料共享的架構方式，我們對應用解決方案進行優化。如圖（10），原來采用傳統的MPP資料庫，應用建設是立煙囪式的，每個應用需要建立一個甚至多個獨立叢集。不同的叢集間需要進行大量複制資料，管理複雜，且資源浪費嚴重。而采用龍趺MPP DB，應用的計算和并發需求可以通過建立一個個計算叢集去滿足，不再需要資料複制，同時應用作業可以根據需求靈活的實時排程到不同的叢集上，大大提升應用靈活度以及資源使用率。
如圖（10）
三、運維解決方案
在運維方面，龍趺MPP DB也提供了更為高效便捷的解決方案，如圖（11）。由于龍趺MPP DB的計算叢集都是無狀态的，借助IaaS服務的快速資源供給，我們可以很快速的完成部分節點乃至整個叢集的建立或者銷毀。這樣子，我們就可以實作叢集的動态擴容、縮容、更新等操作。當出現節點故障時，也可以快速隔離和恢複故障節點，實作故障自愈，大大提升了運維效率。
圖（11）
過去一年多時間裡，建行龍趺MPP DB叢集的伺服器規模增加了50倍，資料量增加了45倍，已經有幾十個應用在上面運作。但是随着叢集規模的不斷增大和應用負載的不斷增加，原來各種不起眼的小問題也開始被無限方法大，導緻嚴重的連鎖反應：
- 每天百億級别的中繼資料RPC請求如何穩定響應；
- 對象存儲海量的資料存取需求如何高效滿足；
- 超大規模的叢集如何高效運作維護；
- 銀行級别的高可用需求要求如何保障。
針對這些問題，我們進行了下面幾個方面的研究和開發。
中繼資料服務能力提升方面，根據服務類型及負載情況，我們對中繼資料服務進行了拆分和分布式改造，從原來每天可以處理十億級别的RPC請求，提升至可以處理百億級别的RPC請求，服務能力提升的同時，也提高了高可用性，如圖（12）：
圖（12）
存儲服務能力提升這塊，一方面我們通過小檔案合并、資料預取、統一緩存層建立等方式，大大減少了對存儲的壓力；另一方面，針對對象存儲每個bucket可以存儲的對象數和IO能力有限的問題，我們給每個應用都建立獨立的tablespace，每個tablespace根據需求對應若幹個bucket。這樣通過bucket拆分，實作了對共享存儲IO隔離和流量控制，并且避免了單bucket能力不足和傾斜等方面的問題。
圖（13）
而在自動化監控運維方面，前面提到了，龍趺MPP DB已經具備了故障自愈的功能。同時，通過實時收集作業、SQL、存儲、伺服器等運作資料，并對這些資料進行聚合分析，如負載是否符合曆史預期、關鍵作業完成情況等，我們可以進一步判斷資料庫性能是否正常、負載是否傾斜、資源是否充足，并為資源的動态排程和故障分析定位提供支援，如圖（14）、圖（15）。
圖（14）
圖（15）
最後是高可用保障。大家都知道，銀行所使用的系統，對于高可用要求非常高。在原有分布式架構以及故障自愈高可用保障基礎上，我們為了應對叢集級别整體故障、AZ級别服務故障、資料丢失/誤删除等情況，我們還提供了跨AZ部署、中繼資料持續備份、雙活部署等方案，進一步提升了龍趺MPP的高可用服務能力，如圖（16）。
圖（16）
過去幾年，我們完成了無數次的版本疊代和上線優化。一款資料庫産品的成熟發展，需要産品、架構、研發、運維、應用等許許多多人的長期合作和投入。在龍趺MPP DB上，我們：
- 集合了大批建信金科和業界優秀的研發人員；
- 提供了業界最複雜、最豐富、負載最高的應用場景；
- 擁有建行二十幾年的資料倉庫建設和運作經驗，能夠最快的發現産品痛點，提出最貼合使用者需求的産品設計。