本文分享自華為雲社群《存算分離之bucket表——【玩轉PB級數倉GaussDB(DWS)】》，作者： yd_278301229 。
原文詳情：https://bbs.huaweicloud.com/blogs/393338?utm_source=juejin&utm_medium=bbs-ex&utm_campaign=ei&utm_content=content
在雲原生環境，使用者可以自由配置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資料：
【一起來玩轉PB級數倉GaussDB(DWS)，分享你的技術經驗與體驗心得，赢開發者大禮包！】第19期有獎征文火熱進行中！（https://bbs.huaweicloud.com/blogs/388439）
關注#華為雲開發者聯盟#，第一時間了解華為雲新鮮技術~