資料重新整理中的並行改進(一)

昨天按照計劃進行了系統升級，多多少少還是碰到了一些問題。
有一個問題不算緊急，但是也在計劃之中需要進行調優和改進。是關於資料的複製重新整理的使用。為了更加清楚的描述問題，自己畫了下面的一個簡單的示意圖來說明。
其實真實環境要遠遠比這個複雜，這是簡單說明問題點到為止即可。
這是一個資料字典資料型資料，也算是靜態資料，配置資料等的重新整理示意圖，資料的源頭只有一個，資料都在active的一個schema上，其他幾個類似的節點都在維護這樣一套類似的結構，但是因為節點都是分散式的，所以都分散在不同的機器上，資料的重新整理目前是採用物化檢視來做的。遠端的重新整理是透過db link+物化檢視來完成的。
對於下層應用來說，還是根據業務規則連線到不同的節點中。

大體的情況就是如此，在生產中進行資料重新整理的時候，如果進行並行複製，其實對於主節點還是有很大的壓力的。而且目前的重新整理情況也是一個序列的方式。
比如我們存在表a,b,c
則在不同的節點中進行重新整理的時候，是先重新整理a，在各個節點一次重新整理，然後重新整理b，然後繼續重新整理c，依次類推。在最後的時候，只需要切換對應的快照schema即可。即上圖中紅色和藍色的部分，最後把schema進行切換即可，對於應用來說是透明的，如果資料出現問題進行undo也是很輕鬆的事情。
所以在採用重新整理的時候，也是考慮了主節點中的負載和壓力，採用了序列的方式進行重新整理，但是一方面保證了壓力，但是重新整理時間就是一個比較明顯的問題了。時間會隨著節點的增多而進行指數級增長。
在儘可能不改動邏輯，少改動邏輯的情況進行的調研情況，得知這種資料的重新整理頻率還是不高的，可能幾周才會進行這樣的一次重新整理，而且在重新整理的過程中，對於應用app1來說優先順序是比較高的，app1中的重新整理完成之後，會有一些業務的預處理，對於app2,app3的資料重新整理速度就沒有很嚴格的要求了。慢一些還是可以接受的。
所以的改進思路就是分成兩部分來處理，兩條腿走路。對於app1優先重新整理，而且對於app1中的表進行並行切分。
比如裡面有15張表，就可以分成多個並行重新整理session來處理。一方面重新整理的都是不同的表，不會有之前熱點快的爭用的情況，而且這個過程完成了就對後續的處理優先順序就會大大降低。依賴性就大大降低了。

當然了這個過程還有很多的細節需要考慮，主要的一個思路就是對於近上千張靜態資料表進行快速的重新整理，有幾個要點需要考慮。
一個就是並行切分的把握，因為資料字典表的資料量相對來說不算很大，總體來說分割槽表還是很少存在的，所以進行並行切分的時候可能直接根據segment的情況就能夠得到一個大體的資料分佈情況了。
優先重新整理app1需要的節點之後，對於後續的節點可以還是保留原有的方式進行重新整理即可。
看起來思路還是比較簡單的，但是能夠使得方案落地還是需要做不少的工作，後續對切分的細節進行分享。