bucket表：數倉存算分離中CU與DN解綁的關鍵

摘要：Bucket存盤是資料共享中重要的一環，當前階段，bucket存盤可以將列存中的CU資料和DN節點解綁，

本文分享自華為云社區《存算分離之bucket表——【玩轉PB級數倉GaussDB(DWS)】》，作者：yd_278301229 ，

在云原生環境，用戶可以自由配置cup型號、記憶體、磁盤、帶寬等資源，需要在計算和IO之間做平衡；如果計算和存盤耦合，擴縮容時資料要在節點之間移動，同時還要對外提供計算，性能會大受影響，如果存算分離，計算出和存盤層可以獨立增加節點互不干擾，這其中一個關鍵點是做到資料共享，Bucket存盤是資料共享中重要的一環，當前階段，bucket存盤可以將列存中的CU資料和DN節點解綁，

一、bucket表在存算分離中的作用

通過存算分離，把DWS完全的shared nothing架構改造成計算層shared nothing + 存盤層shared storage，使用OBS替換EVS，OBS對append only存盤友好，與列存CU存盤天然適配；由于存算分離資料共享，對寫的并發性能不高，在OLAP場景下讀多寫少更有優勢，這一點也是和列存相匹配的，目前主要實作的是列存的存算分，
在當前，bucket表在存盤層共享中，為了將CU資料和DN節點解綁，主要做了兩件關鍵的事，CUID和FILEID全域統一管理，我們來看看為什么這兩件事能把CU和DN節點解綁以及帶來的好處，
為了解釋這個問題，先看看目前shared nothing架構中，建庫和存盤資料的程序，

二，當建立一張列存表并存盤資料時，我們在做什么

建一張列存表時，主要要做以下兩步：

1，系統表中建立表的資料，
2，為列存建立CUDesc表、Delta表等輔助表

當存盤資料時，主要做以下幾步：

1，根據資料分布方式，決定資料存盤到哪個DN，
2，把列存存盤時需要的輔助資訊填入CUDesc表、Delta表等輔助表，
3，把存盤用戶資料的CU存盤本地DN，

在上面的程序中，由于DN之間互不干擾，那就需要各自管理自己的存盤的表的資訊，

CUDesc表的一大功能是CU資料的“指路牌”，就像指標一樣，指出CU資料存盤的位置，靠的是CUID對應的CUPoint（偏移量），加上存盤在DN的檔案位置就能標注出具體的CU資料，而檔案名就是系統表中的relfilenode，

由于在MPPDB的存算一體中，資料都存盤在DN節點，DN節點之間互不干擾，CUID和relfilenode各個DN節點自己管理，只要自己不出問題就行了，也就是“各人自掃門前雪莫管他人瓦上霜”，例如下圖，顯示一張列存表在集群中的存盤狀態，

CN把要存盤的資料根據分布演算法（例如對DN數量做除法取余數）把1,3,5存到DN1,把2,4,6存到DN2，DN1此時生成存盤CU檔案的relfilenode是12345，每插入一次CUID，就把該表的CUDesc表CUID自增，DN1只要把自己的資料管理好，與DN2無關，DN2同理，

三，資料共享和擴縮容時，遇到的困難

1，資料共享時遇到的困難

如上所述，當用戶想查詢資料1,2,4,6時，該怎么辦，因為DN1和DN2都不可能單獨完成任務，就需要共享資料了，問題就來了，DN間肯定是想以最小代價來完成資料共享，系統表最小，CUDesc表也很小（就像指標一樣，同等規模下，只有CU資料的1/3000左右），CU資料最大，假如最后決定以DN2來匯聚所有結果，就算DN1把系統表和CUDesc表中的資料傳給DN2，DN2也看不懂，因為在DN2上,relfilenode為12345可能是另外一張表，cudesc表為中CUID為1001的CUPoint也不知道是指向哪兒了（data1,data2），沒辦法，只能是DN1自己計算，最后把data1的CU資料通過stream算子發送給DN2，DN1迫不得已選了最難的那條路，CU的資料量太大，占用了網路帶寬，還需要DN1來參與計算，并發上不去，

2，擴縮容時遇到的困難

當用戶發現DN1,DN2節點不夠用時，想要一個DN3，該怎么辦，根據分布假設的演算法（對DN數量做除法取余數），data3和data6應該要搬去DN3才對，系統表還比較好搬，無非是在DN3上新建一份資料，CUDesc表也好搬，因為資料量小，再把CUID和CUPoint按照DN3的邏輯寫上資料就好了，CU資料也要搬，但是因為CU資料量大，會占用過多的計算資源和帶寬，同時還要對外提供計算，真是打了幾份工，就賺一份工資，

總結起來，困難主要是

1）系統表元資料(計算元資料)

每個節點有自己的系統表元資料，新增dn必須創建“自己方言”的系統表，而實際上這些系統表內容是“相同的”，但是dn之間互相不理解；

2）CUDesc元資料(存盤元資料)

每個節點的CUID自己分配，同一個CUID在不同節點指向不同的資料，CU無法在dn之間遷移，因為遷移后會混亂，必須通過資料重分布生成dn “自己方言的CUID”
CU的可見性資訊(clog/csnlog)各自獨立管理，dn1讀取dn2的cudesc行記錄之后，不知道記錄是否可見

3）CU用戶資料

filepath(relfilenode) dn節點各自獨立管理，dn1不知道到哪里讀取dn2的資料

四、揭秘CU與DN解綁的關鍵——bucket表

1，存盤映射

bucket表的存盤方式如圖，CU的管理粒度不再是DN，而是bucket，bucket是抽象出來的一個概念，DN存盤的，是系統元資料和bucket對應的CUDesc元資料，由于在bucket作為存盤粒度下，CUID和FILEID是全域統一管理的，DN只需要懂全域的規則，并且拿到別的bucket對應的CUDesc元資料，那就可以很方便的去OBS上拿到CU資料了，通過這種方式，把本該存盤在DN上的CU資料，映射到OBS上，可以保證DN間共享資料時相互獨立，換句話說，每個DN都讀的懂其他DN的CUDesc資料，不再需要把CU資料喂到嘴邊了，

2，全域CUID和FILEID表生成

CUID不再是各節點自己管理生成，而是全域唯一的，其原因是CUID與bucket號系結，特定的bucket號只能生成特定的globalCUID，與此同時，relfilenode不再作為存盤的檔案名，而是作為存盤路徑，CU存放的檔案名為relfilenode/C1_fileId.0，fileId的計算只與bukcet號和seqno有關，

這樣V3表就建立起了一套映射關系（以V2表示存算一體表，V3表示為bucket表)：

step 1,資料插入哪一個bucket由分布方式來確定，例如是RR分布，那么就是輪巡插入bucket，
step 2,CUID是多少，由bucket粒度級別的CUID來確定，比如+1自增作為下一個CUID，
step 3,在bucket上存盤bucket粒度級別的fileId，
step 4,生成全域唯一fileId,由bucketid和bucket粒度級別的fileId來生成,對應生成的CU插入該fileId檔案名的檔案，
setp 5,生成全域唯一globalCUID，由bucketid和bucket粒度級別的CUID計算得到全域唯一的globalCUID，

CUDesc表中，也為bucket表新建了一個屬性fileId，用來讓DN查找到OBS上的CU資料所在的檔案，

3，共享資料和擴縮容的便利

如上所述，DN可以通過全域CUID和FILEID來找到CU資料，在資料共享時，不再需要其他DN參與大量的計算和搬遷CU，擴縮容時，也不需要搬遷CU了，只需要正確生成系統表中的資訊和搬遷CUDesc即可，

最后，來看一看bucket表在OBS上存盤的CU資料：

點擊關注，第一時間了解華為云新鮮技術~

標籤：NoSQL

上一篇：MySQL查看資料庫性能常用命令和實戰教學

下一篇：通用表運算式