2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔ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 集群。

設(shè)計(jì)

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ì)對外提供服務(wù)，這些保證就變成多此一舉了。此外，多線程的線上導(dǎo)入也代表資料是亂序插入的，新的數(shù)據(jù)范圍會(huì)與舊的重疊。TiKV 要求儲(chǔ)存的數(shù)據(jù)是有序的，大量的亂序?qū)懭霑?huì)令 TiKV 要不斷地移動(dòng)原有的數(shù)據(jù)（這稱為 Compaction），這也會(huì)拖慢寫入過程。

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

架構(gòu)

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

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

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

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

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

Lightning

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è)行號，使得沒有主鍵的表可以唯一的區(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 對，稱為「KV 編碼器」。與外部的 TiDB 集群不同，KV 編碼器是寄存在 Lightning 進(jìn)程內(nèi)的，而且使用內(nèi)存存儲(chǔ)，所以每執(zhí)行完一個(gè) INSERT 之后，Lightning 可以直接讀取內(nèi)存獲取轉(zhuǎn)換后的 KV 對（這些 KV 對包含數(shù)據(jù)及索引）。

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

Importer

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

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

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

最后，Importer 將 SST 上傳到對應(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)入后，對比傳送到 Importer 之前這個(gè)表的 Checksum，以及在 TiKV 集群里面時(shí)的 Checksum。如果兩者一樣，我們就有信心說這個(gè)表的數(shù)據(jù)沒有問題。

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

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

總結(jié)和下一步計(jì)劃

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

提升導(dǎo)入速度

現(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 的行程。

并行導(dǎo)入

另一方面，盡管我們可以不斷的優(yōu)化程序代碼，單機(jī)的性能總是有限的。要突破這個(gè)界限就需要橫向擴(kuò)展：增加機(jī)器來同時(shí)導(dǎo)入。如前面所述，只要每套 TiDB-Lightning Toolset 操作不同的表，它們就能平行導(dǎo)進(jìn)同一個(gè)集群?？墒?#xff0c;現(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è)置成本。

在線導(dǎo)入

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

轉(zhuǎn)載于:https://my.oschina.net/zhaiyuan/blog/2990340

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的TiDB Ecosystem Tools 原理解读系列（二）TiDB-Lightning Toolset 介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。