摘要：設(shè)計從年開始提供全量導(dǎo)入工具，它以多線程操作錯誤重試斷點續(xù)傳以及修改一些專屬配置來提升數(shù)據(jù)導(dǎo)入速度。此外，多線程的線上導(dǎo)入也代表資料是亂序插入的，新的數(shù)據(jù)范圍會與舊的重疊。現(xiàn)時只支持經(jīng)導(dǎo)出的備份。此外亦同時將文件分割為大小差不多的區(qū)塊默認(rèn)。

作者：Kenny Chan

TiDB-Lightning Toolset 是一套快速全量導(dǎo)入 SQL dump 文件到 TiDB 集群的工具集，自 2.1.0 版本起隨 TiDB 發(fā)布，速度可達(dá)到傳統(tǒng)執(zhí)行 SQL 導(dǎo)入方式的至少 3 倍、大約每小時 100 GB，適合在上線前用作遷移現(xiàn)有的大型數(shù)據(jù)庫到全新的 TiDB 集群。

TiDB 從 2017 年開始提供全量導(dǎo)入工具 Loader，它以多線程操作、錯誤重試、斷點續(xù)傳以及修改一些 TiDB 專屬配置來提升數(shù)據(jù)導(dǎo)入速度。

然而，當(dāng)我們?nèi)鲁跏蓟粋€ TiDB 集群時，Loader 這種逐條 INSERT 指令在線上執(zhí)行的方式從根本上是無法盡用性能的。原因在于 SQL 層的操作有太強的保證了。在整個導(dǎo)入過程中，TiDB 需要：

保證 ACID 特性，需要執(zhí)行完整的事務(wù)流程。

保證各個 TiKV 服務(wù)器數(shù)據(jù)量平衡及有足夠的副本，在數(shù)據(jù)增長的時候需要不斷的分裂、調(diào)度 Regions。

這些動作確保 TiDB 整段導(dǎo)入的期間是穩(wěn)定的，但在導(dǎo)入完畢前我們根本不會對外提供服務(wù)，這些保證就變成多此一舉了。此外，多線程的線上導(dǎo)入也代表資料是亂序插入的，新的數(shù)據(jù)范圍會與舊的重疊。TiKV 要求儲存的數(shù)據(jù)是有序的，大量的亂序?qū)懭霑?TiKV 要不斷地移動原有的數(shù)據(jù)（這稱為 Compaction），這也會拖慢寫入過程。

TiKV 是使用 RocksDB 以 KV 對的形式儲存數(shù)據(jù)，這些數(shù)據(jù)會壓縮成一個個 SST 格式文件。TiDB-Lightning Toolset使用新的思路，繞過SQL層，在線下將整個 SQL dump 轉(zhuǎn)化為 KV 對、生成排好序的 SST 文件，然后直接用 Ingestion 推送到 RocksDB 里面。這樣批量處理的方法略過 ACID 和線上排序等耗時步驟，讓我們提升最終的速度。

TiDB-Lightning Toolset 包含兩個組件：tidb-lightning 和 tikv-importer。Lightning 負(fù)責(zé)解析 SQL 成為 KV 對，而 Importer 負(fù)責(zé)將 KV 對排序與調(diào)度、上傳到 TiKV 服務(wù)器。

為什么要把一個流程拆分成兩個程式呢？

Importer 與 TiKV 密不可分、Lightning 與 TiDB 密不可分，Toolset 的兩者皆引用后者為庫，而這樣 Lightning 與 Importer 之間就出現(xiàn)語言沖突：TiKV 是使用 Rust 而 TiDB 是使用 Go 的。把它們拆分為獨立的程式更方便開發(fā)，而雙方都需要的 KV 對可以透過 gRPC 傳遞。

分開 Importer 和 Lightning 也使橫向擴(kuò)展的方式更為靈活，例如可以運行多個 Lightning，傳送給同一個 Importer。

以下我們會詳細(xì)分析每個組件的操作原理。

Lightning 現(xiàn)時只支持經(jīng) mydumper 導(dǎo)出的 SQL 備份。mydumper 將每個表的內(nèi)容分別儲存到不同的文件，與 mysqldump 不同。這樣不用解析整個數(shù)據(jù)庫就能平行處理每個表。

首先，Lightning 會掃描 SQL 備份，區(qū)分出結(jié)構(gòu)文件（包含 CREATE TABLE 語句）和數(shù)據(jù)文件（包含 INSERT 語句）。結(jié)構(gòu)文件的內(nèi)容會直接發(fā)送到 TiDB，用以建立數(shù)據(jù)庫構(gòu)型。

然后 Lightning 就會并發(fā)處理每一張表的數(shù)據(jù)。這里我們只集中看一張表的流程。每個數(shù)據(jù)文件的內(nèi)容都是規(guī)律的 INSERT 語句，像是：

INSERT INTO `tbl` VALUES (1, 2, 3), (4, 5, 6), (7, 8, 9);  
INSERT INTO `tbl` VALUES (10, 11, 12), (13, 14, 15), (16, 17, 18);
INSERT INTO `tbl` VALUES (19, 20, 21), (22, 23, 24), (25, 26, 27);

Lightning 會作初步分析，找出每行在文件的位置并分配一個行號，使得沒有主鍵的表可以唯一的區(qū)分每一行。此外亦同時將文件分割為大小差不多的區(qū)塊（默認(rèn) 256 MiB）。這些區(qū)塊也會并發(fā)處理，讓數(shù)據(jù)量大的表也能快速導(dǎo)入。以下的例子把文件以 20 字節(jié)為限分割成 5 塊：

Lightning 會直接使用 TiDB 實例來把 SQL 轉(zhuǎn)換為 KV 對，稱為「KV 編碼器」。與外部的 TiDB 集群不同，KV 編碼器是寄存在 Lightning 進(jìn)程內(nèi)的，而且使用內(nèi)存存儲，所以每執(zhí)行完一個 INSERT 之后，Lightning 可以直接讀取內(nèi)存獲取轉(zhuǎn)換后的 KV 對（這些 KV 對包含數(shù)據(jù)及索引）。

得到 KV 對之后便可以發(fā)送到 Importer。

因異步操作的緣故，Importer 得到的原始 KV 對注定是無序的。所以，Importer 要做的第一件事就是要排序。這需要給每個表劃定準(zhǔn)備排序的儲存空間，我們稱之為 engine file。

對大數(shù)據(jù)排序是個解決了很多遍的問題，我們在此使用現(xiàn)有的答案：直接使用 RocksDB。一個 engine file 就相等于本地的 RocksDB，并設(shè)置為優(yōu)化大量寫入操作。而「排序」就相等于將 KV 對全寫入到 engine file 里，RocksDB 就會幫我們合并、排序，并得到 SST 格式的文件。

這個 SST 文件包含整個表的數(shù)據(jù)和索引，比起 TiKV 的儲存單位 Regions 實在太大了。所以接下來就是要切分成合適的大小（默認(rèn)為 96 MiB）。Importer 會根據(jù)要導(dǎo)入的數(shù)據(jù)范圍預(yù)先把 Region 分裂好，然后讓 PD 把這些分裂出來的 Region 分散調(diào)度到不同的 TiKV 實例上。

最后，Importer 將 SST 上傳到對應(yīng) Region 的每個副本上。然后通過 Leader 發(fā)起 Ingest 命令，把這個 SST 文件導(dǎo)入到 Raft group 里，完成一個 Region 的導(dǎo)入過程。

我們傳輸大量數(shù)據(jù)時，需要自動檢查數(shù)據(jù)完整，避免忽略掉錯誤。Lightning 會在整個表的 Region 全部導(dǎo)入后，對比傳送到 Importer 之前這個表的 Checksum，以及在 TiKV 集群里面時的 Checksum。如果兩者一樣，我們就有信心說這個表的數(shù)據(jù)沒有問題。

一個表的 Checksum 是透過計算 KV 對的哈希值（Hash）產(chǎn)生的。因為 KV 對分布在不同的 TiKV 實例上，這個 Checksum 函數(shù)應(yīng)該具備結(jié)合性；另外，Lightning 傳送 KV 對之前它們是無序的，所以 Checksum 也不應(yīng)該考慮順序，即服從交換律。也就是說 Checksum 不是簡單的把整個 SST 文件計算 SHA-256 這樣就了事。

我們的解決辦法是這樣的：先計算每個 KV 對的 CRC64，然后用 XOR 結(jié)合在一起，得出一個 64 位元的校驗數(shù)字。為減低 Checksum 值沖突的概率，我們目時會計算 KV 對的數(shù)量和大小。若速度允許，將來會加入更先進(jìn)的 Checksum 方式。

從這篇文章大家可以看到，Lightning 因為跳過了一些復(fù)雜、耗時的步驟使得整個導(dǎo)入進(jìn)程更快，適合大數(shù)據(jù)量的初次導(dǎo)入，接下來我們還會做進(jìn)一步的改進(jìn)。

現(xiàn)時 Lightning 會原封不動把整條 SQL 命令拋給 KV 編碼器。所以即使我們省去執(zhí)行分布式 SQL 的開銷，但仍需要進(jìn)行解析、規(guī)劃及優(yōu)化語句這些不必要或未被專門化的步驟。Lightning 可以調(diào)用更底層的 TiDB API，縮短 SQL 轉(zhuǎn) KV 的行程。

另一方面，盡管我們可以不斷的優(yōu)化程序代碼，單機(jī)的性能總是有限的。要突破這個界限就需要橫向擴(kuò)展：增加機(jī)器來同時導(dǎo)入。如前面所述，只要每套 TiDB-Lightning Toolset 操作不同的表，它們就能平行導(dǎo)進(jìn)同一個集群?？墒?，現(xiàn)在的版本只支持讀取本機(jī)文件系統(tǒng)上的 SQL dump，設(shè)置成多機(jī)版就顯得比較麻煩了（要安裝一個共享的網(wǎng)絡(luò)盤，并且手動分配哪臺機(jī)讀取哪張表）。我們計劃讓 Lightning 能從網(wǎng)路獲取 SQL dump（例如通過 S3 API），并提供一個工具自動分割數(shù)據(jù)庫，降低設(shè)置成本。

TiDB-Lightning 在導(dǎo)入時會把集群切換到一個專供 Lightning 寫入的模式。目前來說 Lightning 主要用于在進(jìn)入生產(chǎn)環(huán)境之前導(dǎo)入全量數(shù)據(jù)，所以在此期間暫停對外提供服務(wù)還可以接受。但我們希望支持更多的應(yīng)用場景，例如回復(fù)備份、儲存 OLAP 的大規(guī)模計算結(jié)果等等，這些都需要維持集群在線上。所以接下來的一大方向是考慮怎樣降低 Lightning 對集群的影響。