1、引言
??在某些場景下客戶可能會有數據(庫)遷移的需求,即需要在集群之間遷移數據的場景。數據遷移一般用于滿足災備冗余、系統環境變更,甚至是機房規劃建設等要求。本文將討論在VERTICA集群之間復制數據的不同方法和區別。
2、要求
??在進行企業級數據倉庫集群遷移時,一般需要滿足數據安全性、數據一致性、現有生產集群不受影響、停機時間最短和遷移后業務正確性的硬性要求。因此在遷移過程中我們一般遵守以下原則:
??確保數據安全性: 在技術允許的條件下,要絕對保證數據的安全性,要絕對避免數據損失、丟失等風險。
??確保停機時間最短: 在數據庫遷移過程中,業務系統停機是不可避免的,但是應該盡量縮短停機時間。
??分步驟實施: 企業級VERTICA數據倉庫集群一般節點多、數據量大,所以數據庫遷移過程中必須能夠分階段實施、階段把控。
3、策略
??結合以往的VERTICA數據庫遷移經驗,列舉了下列幾種常用的VERTICA同步數據的方法,并梳理了各類方法的功能差異:
| 方法 | EXPORT TO VERTICA | COPY FROM VERTICA | EXPORT© FROM | COPYCLUSTER | REPLICATE |
|---|---|---|---|---|---|
| 同步數據 | Yes | Yes | Yes | Yes | Yes |
| 同步表結構 | No | No | No | Yes | Yes |
| 指定列數據同步(Columns) | Yes | Yes | Yes | No | No |
| 指定數據集同步(Select) | Yes | No | Yes | No | No |
| 連接源庫 | Yes | Yes | Yes | - | - |
| 節點數一致性限制 | - | - | - | Yes | Yes(Enterprise) |
| 庫名稱一致性限制 | - | - | - | Yes | - |
??通常會根據遷移數據的實際要求(全量同步、對象級同步、差異同步等),從上述提到的方法中選擇最優的方式。針對不同的場景,上述的某種方法可能比其他方法更適合,應仔細選擇適合的解決方案。有些方法可能具有更大的靈活性,但也會存在其他限制。譬如:在vbr中使用copycluster選項,則要求停止目標數據庫;COPY和EXPORT語句允許使用SQL命令執行數據移動任務,但需提前創建表對象。
??此外,如果可以接受額外的CPU開銷,那么COPY FROM VERTICA或 EXPORT TO VERTICA方法可以從網絡壓縮中獲益,啟用CompressNetworkData參數即可通過網絡傳輸壓縮后的數據,從而解決由于網絡性能限制數據同步效率的問題。
3.1、EXPORT TO VERTICA
??允許將整個表、表中的特定列或SELECT語句的結果導出到另一個數據庫。
=> CONNECT TO VERTICA testdb USER dbadmin PASSWORD '' ON 'VertTest01', 5433;
CONNECT
=> EXPORT TO VERTICA testdb.customer_dimension FROM customer_dimension;
Rows Exported
---------------
23416
(1 row)
=> DISCONNECT testdb;
DISCONNECT
3.2、COPY FROM VERTICA
??與EXPORT語句類似,但不允許導出SELECT語句結果集。
=> CONNECT TO VERTICA vmart USER dbadmin PASSWORD '' ON 'VertTest01',5433;
CONNECT
=> COPY customer_dimension FROM VERTICA vmart.customer_dimension;
Rows Loaded
-------------
500000
(1 row)
=> DISCONNECT vmart;
DISCONNECT
3.3、EXPORT TO PARQUET
??先使用EXPORT TO PARQUET將庫內數據導出至庫外進行落地存儲,然后通過COPY FROM將數據加載至目標庫。
vsql -h sourceDB <<-EOF
EXPORT TO PARQUET(directory = 'hdfs:///user1/data') AS
SELECT * FROM public.T1;
<<-EOF
wait
vsql -h targetDB <<-EOF
COPY public.T1 FROM 'hdfs:///user1/data/*.parquet' PARQUET;
<<-EOF
??3.1至3.3小節中涉及的數據同步方案的主要限制有:
- ??目標庫中的表必須已存在。
- ??目標庫關閉自增列(建議)。
- ??目標庫中的列與源列必須具有相同或兼容的數據類型。
- ??CONNECT to VERTICA打開與目標(源端)數據庫的連接。
3.4、COPY CLUSTER
??集群復制(COPY CLUSTER)是VERTICA備份恢復工具vbr的一個功能選項,可將數據庫復制到另一個集群,實際上是一個Backup + Restore操作。雖然該方案存在很多限制:譬如兩個集群中應具有相同的數據庫版本、相同的節點數量、相同的數據庫名稱和相同的節點名稱,另外需停掉目標數據庫。但作為官方支持的備份恢復工具,它的靈活性高一些,并允許在單個操作中進行備份和恢復。

??另外,得益于VBR的備份機制,如果copy cluster任務被迫需要中斷,再次啟動(同一個配置文件)時無需重新發送已同步過的數據文件,可實現“斷點續傳”的功能。
# 1.Stop targetDB
$ /opt/vertica/bin/admintools -t stop_db -d targetDB
# 2.Create vbr.ini
$ /opt/vertica/bin/vbr --setupconfig
$ cat copycluster.ini
[Misc]
snapshotName = CopyVmart
tempDir = /tmp/vbr
[Database]
dbName = vmart
dbUser = dbadmin
dbPassword = password
dbPromptForPassword = False
[Transmission]
encrypt = False
port_rsync = 50000
[Mapping]
; backupDir is not used for cluster copy
v_vmart_node0001= test-host01
v_vmart_node0002= test-host02
v_vmart_node0003= test-host03
# 3.Run vbr copycluster
/opt/vertica/bin/vbr --config-file copycluster.ini --task copycluster
# 4.Start targetDB
$ /opt/vertica/bin/admintools -t start_db -d targetDB
注意:copycluster選項會覆蓋目標集群中的所有現有數據。
3.5、REPLICATE OBJECTS
??對象復制(Replicating objects)能夠將特定表從一個數據庫復制到另一個數據庫。與copycluster一樣,均為VBR的一個功能項,不同之處在于replicate更加靈活,比如:
replicate可以雙向同步數據,可以靈活指定特定表進行同步。replicate不再強制要求節點個數(企業模式仍需)、庫名稱必須一致。replicate比完全備份要快,可以節省備份位置的磁盤空間。
$ cat object_replication.ini
[Misc]
snapshotName = backup_snapshot
dest_verticaBinDir = /opt/vertica/bin
restorePointLimit = 3
objects = mytable, myschema, myothertable
objectRestoreMode = coexist
[Database]
dbName = mydatabase
dbUser = dbadmin
dbPromptForPassword = True
[Mapping]
v_exampledb_node0001 = destination_host0001
v_exampledb_node0002 = destination_host0002
v_exampledb_node0003 = destination_host0003
v_exampledb_node0004 = destination_host0004
$ vbr -t replicate -c object_replication.ini
4、案例
4.1、基于VBR異地遷移PB級數倉集群
??為滿足自身業務發展和機房建設規劃要求,制定了對某平臺VERTICA倉庫進行異地遷移的目標。遷移之初,源端數據庫已有2萬多張表模型,共計約1.3PB的業務數據(壓縮比約1.9)。經過多方調研最終決定采用VBR copy cluster方式進行遷移。

??完成本案例遷移歷時5天(操作窗口7個小時/日),實際操作時長共36.5小時,速率約17.3TB/h。通過事后復盤及經驗總結,使用該方式的主要優勢有:
??生產不受影響: 使用VBR進行數據遷移期間,可同時對源數據庫進行數據裝載、處理和查詢操作,不影響源數據庫的業務運行,對業務性能影響小。由于遷移效率高、停服時間短,遷移期間及割接當日均未影響業務運行。
??安全可靠: VERTICA事務處理機制能夠保證已提交的數據文件不再修改,vbr基于文件進行同步,因此能夠避免遷移后數據不一致的風險。
??節約成本: 屬于VERTICA自有功能,使用方式簡潔,無需采購其它第三方服務,節約遷移成本。
4.2、使用EXPORT TO VERTICA遷移異構模式集群
??為充分利用EON模式架構優勢實現數據集市業務場景需求,計劃將原有數據集市業務場景遷移至EON模式VERTICA集群。經過權衡后,決定放棄使用“將企業數據庫遷移到Eon模式(Migrating an Enterprise Database to Eon Mode)”策略(集群規模不一致且shards需要與源節點數一致等限制),而采用EXPORT TO VERTICA方式進行數據遷移。

??遷移時,源端數據庫已有4萬多張表模型,共計約140TB的業務數據。整體數據遷移流程如下:
??1、部署EON模式VERTICA集群: 共享存儲為HADOOP集群
??2、遷移數據庫對象: 如用戶、角色、模式、表、projection、視圖、權限等數據庫對象
??3、鎖定源庫: 關閉數據庫會話,將源數據庫置為readonly
??4、數據同步: 按表進行并發數據同步
??5、數據稽核: 記錄數核對、列最大(?。┲?,行hash值核對
??完成本案例數據遷移共用時8小時(操作窗口為割接當日12時至次日1點)。
4.3、統一數據存儲,實現湖倉一體
??數據文件標準化是數據管理的基礎性工作,是數據資產管理的核心活動之一。對理清數據構成、打通數據孤島、加快數據流通、提升數據價值有著至關重要的作用。因此為滿足數據管理要求,實現各平臺數據有效交互和共享,本案例通過使用EXPORT TO PARQUET方法,將VERTICA數據導出為parquet格式文件,用于大數據平臺各系統間數據共享。

??與TEXT、JSON、CSV等格式相比,Parquet格式是Hadoop生態圈主流的列式存儲格式,非常適用于OLAP場景,其按列存儲和掃描具有更高的壓縮比、更小的IO操作。同時,VERTICA支持對其進行列裁剪、謂詞下推,可以讓QUERY計算離數據盡可能近。VERTICA官方說明如下:
When working with external tables in the Parquet and ORC columnar formats, Vertica tries to improve performance in the following ways:
- By pushing query execution closer to the data so less has to be read and transmitted. Vertica uses the following specific techniques: predicate pushdown, column selection, and partition pruning.
- By taking advantage of data locality in the query plan.
- By analyzing the row count to get the best join orders in the query plan.
5、參考
[1] Copying Data Between Vertica Databases
[2] Copying Data Between Similar Vertica Clusters
[3] Improving Query Performance




