13TB的StarRocks大資料庫遷移過程

zping發表於2024-12-02
大資料資料庫

公司有一套StarRocks的大資料庫在大股東的騰訊雲環境中，透過騰訊雲的對等連線打通，透過dolphinscheduler排程datax離線抽取資料和SQL計算彙總，還有在大股東的特有的Flink叢集環境，該環境開發了flink開發程式包部署，實時同步資料。

公司業務帆軟報表平臺有40張左右的報表連線的Starrocks大資料庫。Starrocks大資料庫整個庫大小超過13TB+

因各種原因，大股東的騰訊雲環境不再讓使用，打通的對等連線也會斷開，需要把Starrocks及相關的服務等遷移回來：

1，Dolphinscheduler分散式排程：排程Datax抽取指令碼和SQL計算彙總指令碼

2，重新部署StarRocks資料庫叢集

3，實時同步幾十張實時同步的表

4，同步現有StarRocks的歷史資料到新的叢集中

5，實時Flink聚合的表

因涉及的報表和東西多，再2023年就公司說要遷回來，但情況一說，太複雜了，就一直拖著不遷移。

但到2024年4，5月份，公司大股東說必須要遷移，公司讓儘快研究StarRocks遷移事情，這件事又落自己頭上，想想頭大，這麼多事情，測試方案，部署環境，買機器，實時同步，歷史資料處理等等，這次沒辦法只能向前做，從2024年5月份到現在2024年11月份，遷移工作是被動做做停停的，到現在完成差不多，抽空把過程總結寫下來：

1，Dolphinscheduler分散式排程

1.1 為省成本，請大股東的運維遠端在公司騰訊雲現有機器上部署DS排程，部署的版本一致，在個別機器記憶體做擴容

1.2 以前海豚的排程後設資料庫匯出，部署到公司的MySQL，這樣任務和排程就和以前一樣。

1.3 海豚排程的Datax指令碼，因以前他們用了CFS服務共享磁碟用一套，這邊做不了，只能在3臺機器上各部署一套路徑一致的datax抽取指令碼

2，部署StarRocks資料庫叢集

考慮相容問題，沒有使用最新的StarRocks 3 版本，用的騰訊雲EMR叢集的Starrocks2.5版本，省去自建和維護的很多事情。

3，實時同步

1，使用Flink叢集

以前做的程式是在其特殊Flink API環境開發，拿以前的程式直接部署到Flink叢集就無法使用，要麼重新開發，我不擅長Flink這塊，只能放棄！

2，騰訊雲---流計算Oceanus

諮詢騰訊雲的技術支援，推薦Oceanus，可以實現Flink SQL實現實時同步，發現還有多表同時同步的，覺得終於可以解決這個實時同步問題了，就買了一個月的Oceanus服務，測試了多表，透過Microsoft VS Code搜尋目錄下的帆軟報表，找出實時同步的表，然後按庫多表同時同步，但是部署6個任務後，按庫多表同時同步，經常報錯，不穩定，後來諮詢，騰訊雲說多表同步不穩定的確不推薦，但我一個表一個job任務，那要多少任務，肯定不行，沒辦法不能使用！

3，Java程式實現實時同步

研發同學，說以前做個單個表的同步，沒辦法，只能讓他透過java程式來實現同步，透過讀取binlog程式寫到庫裡，後來把這6個整理的幾十個任務表提供，他寫java程式同步，可以使用。

4，StarRocks歷史資料同步

諮詢大股東，他們遷移StarRocks到騰訊雲的EMR，歷史資料是透過StarRocks外部表來做，但公司說要節省成本折扣更多，把StarRocks買到另外一個騰訊雲賬號上，再打通到現在公司的騰訊雲，這樣就有3個騰訊雲賬號，又沒法把新賬號騰訊雲和大股東騰訊雲打通，結果導致2個Starrocks不通，不能透過外部遷移歷史資料，沒辦法，這時就想到用自己做的開源pydatax來同步，但要拼接處src_table_column表，直接透過SQL就可以出來如下： 

select  TABLE_NAME,GROUP_CONCAT(replace(COLUMN_NAME,'etl_process_time','now() as etl_process_time')) cols from 
(select TABLE_NAME,COLUMN_NAME,ORDINAL_POSITION
from information_schema.`columns` 
where TABLE_SCHEMA='db'
and TABLE_NAME like 'bo_ods%' order by TABLE_NAME asc,ORDINAL_POSITION asc ) t
GROUP BY  TABLE_NAME order by TABLE_NAME asc

以上表是離線的，實時的也是類似。獲取到src_table_column資訊，透過下列SQL獲取寫入到datax_config_wm表

SELECT TABLE_NAMe,
CONCAT("INSERT INTO datax_config_wm (type, src_table_name, json_id, des_table_name, relation,dcondition, ",
"src_table_column, des_table_column, server_type, ordernum, status, etl_type, etl_column, etl_num, last_etl_date, note, ",
"create_time) VALUES ('1','",TABLE_NAMe,"','",'9',"','",TABLE_NAMe,"',","'t','","1=1","','",GROUP_CONCAT(COLUMN_NAME),"'",
 'ss#stt')
FROM (
select * from information_schema.`columns` where TABLE_SCHEMA='report_srdw'
and TABLE_NAME in (
select TABLE_NAME from information_schema.`tables` where TABLE_SCHEMA='report_srdw' and ENGINE='StarRocks'
and TABLE_NAME   like 'bo_ods_%')
order by TABLE_NAME asc,ORDINAL_POSITION asc
) t
group by TABLE_NAME;

注：這個'ss#stt'字元，是用來替換成下列字元: 

, '*', 0, 22.001, 1, 0, '', 14, CURRENT_DATE(), 'wm', now());

生成完成後，copy和修改pydatax讓其讀取配置表datax_config_wm，離線是T+1，同步歷史資料。

已經部署的海豚排程已經每天在同步資料。歷史資料就透過pydatax同步資料，遇到特別大的表，導致抽取查詢超時，修改引數成6000秒：

set global query_timeout=6000;

但改完個別表大還是超時，這時對這個表分割多次同步，直接修改datax_config_wm的加上範圍就可。

幾天時間，實時和離線的322張表歷史資料就同步完成，部分大表抽取資訊如下，看出Datax的能達到12萬行+/秒的速度，6.6億多條同步要 91分鐘。

5，實時Flink聚合的表

帆軟報表用到實時聚合表，但是研發同學沒有實時聚合功能，查詢實時報表，分析雖然做了好多聚合表，但實際只有5張表使用，

想想就使用StarRocks 的物化檢視，替換原有聚合表，對報表透明無感知，這5張表的聚合對應修改成聚合後的物化檢視。

上線後，有3張物化檢視的源實時表老是同步出錯，不得不取實時表改成T+1的資料表，和產品經理溝通後，對應的報表的顯示的"實時"也加上"昨天"。

以上修改後，正式切換線上帆軟報表連線成新的StarRocks 庫，觀察線上的客戶使用情況。

總結：

1，該遷移前後花了好幾個月時間，有點長！

2，難到不難，大量的細心的工作需要做！

3，資料同步工具 pydatax 又一次出色完成其高效簡單的資料遷移任務。

相關文章