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
