摘要：設(shè)計(jì)從年開始提供全量導(dǎo)入工具，它以多線程操作錯(cuò)誤重試斷點(diǎn)續(xù)傳以及修改一些專屬配置來提升數(shù)據(jù)導(dǎo)入速度。此外，多線程的線上導(dǎo)入也代表資料是亂序插入的，新的數(shù)據(jù)范圍會(huì)與舊的重疊。現(xiàn)時(shí)只支持經(jīng)導(dǎo)出的備份。此外亦同時(shí)將文件分割為大小差不多的區(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 倍、大約每小時(shí) 100 GB，適合在上線前用作遷移現(xiàn)有的大型數(shù)據(jù)庫到全新的 TiDB 集群。

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

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

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

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

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

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

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

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

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

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

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

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

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

然后 Lightning 就會(huì)并發(fā)處理每一張表的數(shù)據(jù)。這里我們只集中看一張表的流程。每個(gè)數(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 會(huì)作初步分析，找出每行在文件的位置并分配一個(gè)行號(hào)，使得沒有主鍵的表可以唯一的區(qū)分每一行。此外亦同時(shí)將文件分割為大小差不多的區(qū)塊（默認(rèn) 256 MiB）。這些區(qū)塊也會(huì)并發(fā)處理，讓數(shù)據(jù)量大的表也能快速導(dǎo)入。以下的例子把文件以 20 字節(jié)為限分割成 5 塊：

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

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

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

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

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

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

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

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

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

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

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

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

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