摘要：作者申礫本文是招聘職位深度解讀系列的第一篇，我司申礫老師將為大家介紹團(tuán)隊(duì)一群無(wú)法抑制內(nèi)心技術(shù)騷動(dòng)的人。在數(shù)據(jù)遷移的過(guò)程中，我們支持對(duì)數(shù)據(jù)的以及內(nèi)容按照一定規(guī)則做轉(zhuǎn)換，實(shí)現(xiàn)分庫(kù)分表的合并等復(fù)雜的操作。

作者：申礫

本文是 PingCAP 招聘職位深度解讀系列的第一篇，我司 Engineering VP 申礫老師將為大家介紹 TiDB 團(tuán)隊(duì)（一群無(wú)法抑制內(nèi)心技術(shù)騷動(dòng)的人!）。

簡(jiǎn)單來(lái)說(shuō)，TiDB 是一個(gè)分布式高可用且能夠水平擴(kuò)展的關(guān)系型數(shù)據(jù)庫(kù)，這個(gè)數(shù)據(jù)庫(kù)的內(nèi)核包含三個(gè)組件，其中的 SQL 層組件的名字也叫做 TiDB。這個(gè)組件負(fù)責(zé)所有和 SQL 計(jì)算相關(guān)的事情以及和客戶端（業(yè)務(wù)）之間的交互，這是一個(gè)承上啟下的核心模塊。除了負(fù)責(zé) TiDB 組件之外， TiDB 團(tuán)隊(duì)還負(fù)責(zé)開(kāi)發(fā)與其他數(shù)據(jù)庫(kù)之間的數(shù)據(jù)遷移和同步組件，比如 TiDB 自身的 Binlog 模塊以及讀取 MySQL 之類數(shù)據(jù)源 Binlog 的組件。

TiDB 研發(fā)工程師職位信息:

https://www.pingcap.com/recruit-cn/engineering/tidb-engineer/

招聘職位上的「崗位職責(zé)」簡(jiǎn)單寫(xiě)了下面三點(diǎn)：

負(fù)責(zé)分布式數(shù)據(jù)庫(kù)查詢優(yōu)化器和執(zhí)行引擎相關(guān)的設(shè)計(jì)，開(kāi)發(fā)，文檔撰寫(xiě)和新人指導(dǎo)；

負(fù)責(zé)分布式數(shù)據(jù)庫(kù) SQL 層的設(shè)計(jì)，開(kāi)發(fā)和性能優(yōu)化；

參與分布式數(shù)據(jù)庫(kù)底層系統(tǒng)存儲(chǔ)系統(tǒng)的設(shè)計(jì)。

這里可以做的事情非常多，下面我會(huì)詳細(xì)地介紹。

數(shù)據(jù)庫(kù)最難的部分在于如何保證正確性，這個(gè)是需要具備嚴(yán)謹(jǐn)思維+想象力的工程問(wèn)題，也是我們每一個(gè)工程師日常必須考慮的問(wèn)題。

我們需要以負(fù)責(zé)且懷疑一切的態(tài)度去審視每一行代碼；需要以嚴(yán)謹(jǐn)且狡詐的方式想出各種套路方法（“陰謀陽(yáng)謀/奇技淫巧”）去吊打自己的產(chǎn)品；需要嚴(yán)肅且堅(jiān)決地拒絕任何可能帶來(lái)不確定性的變更；需要在每次遇到問(wèn)題的時(shí)候都反思今后如何避免出現(xiàn)類似的問(wèn)題。

這是一個(gè)極端重要且有技術(shù)難度的事項(xiàng)，所以我把它放在第一點(diǎn)來(lái)介紹。

一個(gè)好的架構(gòu)決定了產(chǎn)品的好壞。SQL 引擎是一個(gè)非常復(fù)雜的東西，涉及到大量的模塊，如何安排這些模塊，并解決這些模塊之間復(fù)雜的交互是非常重要的事情。

DDL 是 SQL 引擎最基本的功能之一，有人覺(jué)得不就是建個(gè)表、刪個(gè)表嗎？其實(shí)不是，難點(diǎn)在于如何在分布式數(shù)據(jù)庫(kù)上支持不阻塞業(yè)務(wù)的 DDL 變更，特別是在海量數(shù)據(jù)上做 DDL，如何既快又好。例如如何在線修改一個(gè)十億級(jí)別 Table 的某一列的類型？當(dāng)然這一切的前提都是保證 DDL 操作的正確性，這點(diǎn)在分布式數(shù)據(jù)庫(kù)中有很多點(diǎn)需要考慮，不信的話可以來(lái)一起踩坑。

一條 Query 的查詢計(jì)劃好壞可能會(huì)導(dǎo)致執(zhí)行時(shí)間的巨大差別，優(yōu)化器就是 SQL 引擎的軍師。我們需要考慮各種數(shù)據(jù)分布、各種優(yōu)化手段、各種等價(jià)變化，在合理的時(shí)間內(nèi)選出一條不那么差的查詢計(jì)劃。這里說(shuō)“不那么差”聽(tīng)起來(lái)不那么靠譜，但是在 Query 比較復(fù)雜的情況下，潛在的查詢計(jì)劃搜索空間非常龐大，既要找到好的查詢計(jì)劃，又希望縮短搜索時(shí)間，這是一個(gè)非常有挑戰(zhàn)的事情。希望你能來(lái)和我們一起做一個(gè)“總能選出最好的查詢計(jì)劃”的優(yōu)化器。

在優(yōu)化器搜索并評(píng)估所有候選查詢計(jì)劃的過(guò)程中，統(tǒng)計(jì)信息的準(zhǔn)確與否非常重要，它是 SQL 引擎的情報(bào)官，優(yōu)化器擁有準(zhǔn)確的統(tǒng)計(jì)信息才能做出正確的決策，就像軍師有精確且及時(shí)的情報(bào)才能給出正確的行動(dòng)方案。在海量的數(shù)據(jù)中（百億級(jí)別）如何快速計(jì)算統(tǒng)計(jì)信息，反應(yīng)數(shù)據(jù)真實(shí)分布；在繁忙的生產(chǎn)系統(tǒng)中，如何讓統(tǒng)計(jì)信息跟上數(shù)據(jù)的變動(dòng)，提供更及時(shí)的信息，這些都是有挑戰(zhàn)的事情。

軍師根據(jù)正確的情報(bào)制定了好的作戰(zhàn)計(jì)劃之后，還需要驍勇的將軍去執(zhí)行，在這里就是執(zhí)行引擎。我們?cè)?2.0 和 2.1 兩個(gè)版本中，都對(duì)執(zhí)行引擎做了大量改進(jìn)，一些語(yǔ)句的運(yùn)行時(shí)間有了幾倍甚至數(shù)量級(jí)的提升。我們會(huì)考慮到如何提升 CPU 使用率、減少 Cache miss、減少 TLB miss，通過(guò) Pipeline、并行等模式提升執(zhí)行速度。

作為一個(gè)新興的數(shù)據(jù)庫(kù)，我們需要考慮幫助用戶平滑的遷移（全量+增量）已有數(shù)據(jù)庫(kù)（主要面對(duì) MySQL）到 TiDB 中來(lái)，當(dāng)然我們也提供一套組件來(lái)實(shí)時(shí)同步數(shù)據(jù)變動(dòng)到數(shù)據(jù)庫(kù)外面。主要包括下面三個(gè)組件：

TiDB Data Migration?（簡(jiǎn)稱 DM）

TiDB Binlog

TiDB Lightning

DM 是一個(gè)數(shù)據(jù)遷移平臺(tái)，同時(shí)支持全量遷移（MyDumper+Loader）以及增量遷移（讀取 MySQL Binlog），我們需要把這個(gè)工具做的穩(wěn)定、高效、易于使用。在數(shù)據(jù)遷移的過(guò)程中，我們支持對(duì)數(shù)據(jù)的 Schema 以及內(nèi)容按照一定規(guī)則做轉(zhuǎn)換，實(shí)現(xiàn)分庫(kù)分表的合并等復(fù)雜的操作。除了實(shí)現(xiàn)這些功能之外，還會(huì)致力于讓各種操作盡量簡(jiǎn)單方便，可視化同步狀態(tài)。

Binlog 是 TiDB 自身的 binlog 模塊，能夠把 TiDB 集群的實(shí)時(shí)變動(dòng)發(fā)送出去，通過(guò) binlog 可以給 TiDB 增加一個(gè)從集群，這個(gè)從集群可以是另一個(gè) TiDB 集群，也可以是一個(gè) MySQL 實(shí)例。另外也可以將 binlog 寫(xiě)入消息隊(duì)列中被其他系統(tǒng)消費(fèi)，用于其他用途，只要知道 binlog 數(shù)據(jù)的 protobuf 定義即可。這里的難點(diǎn)在于如何保證正確性、性能、穩(wěn)定性，特別是如何保證多個(gè)節(jié)點(diǎn)的 binlog 數(shù)據(jù)按照事務(wù)保證輸出順序，數(shù)據(jù)不重不丟不亂且延遲低。

Lightning 是一個(gè)專門為 TiDB 開(kāi)發(fā)的數(shù)據(jù)批量導(dǎo)入工具，可以讀取 MyDumper 的輸出格式或者是 CSV 格式的文件，將數(shù)據(jù)導(dǎo)入 TiDB 集群。相比通過(guò) SQL 接口導(dǎo)入數(shù)據(jù)，Lightning 可以跳過(guò)分布式事務(wù)、數(shù)據(jù)唯一性約束檢查、Raft 協(xié)議，將 SQL 文本直接轉(zhuǎn)換為 TiKV 底層的 RocksDB SST file，再將 SST file 注入到 TiKV 集群中。極大地縮短了導(dǎo)數(shù)據(jù)時(shí)間，目前內(nèi)部的一個(gè)測(cè)試場(chǎng)景中，導(dǎo)入單表 1TB 的 SQL 文本耗時(shí) 2 小時(shí)，我們還在持續(xù)優(yōu)化這個(gè)工具，盡可能縮短這個(gè)時(shí)間。

這里把性能放在了最后，并不是說(shuō)它是不重要的部分，相反它是最重要的部分之一。大家可以看我們的文檔，每次發(fā)布新版本都會(huì)給出性能改進(jìn)的對(duì)比結(jié)果，大多數(shù)用戶在接觸 TiDB 之后也會(huì)關(guān)心性能指標(biāo)。

我們現(xiàn)在主要通過(guò) OLTP（比如 Sysbench， TPC-C）以及 OLAP （TPC-H）兩套測(cè)試體系來(lái)評(píng)估 TiDB 的性能，并且在同時(shí)針對(duì)這兩類場(chǎng)景做性能優(yōu)化。這里有非常多的事情可以做。我們希望能把性能提升到極致。

作為一個(gè)硬核的代碼「團(tuán)伙」，僅僅「舉頭望明月，低頭寫(xiě)代碼」是無(wú)法滿足我們內(nèi)心的技術(shù)騷動(dòng)的，我們希望把 TiDB 這個(gè)項(xiàng)目和整個(gè)開(kāi)源世界連接起來(lái)，所以希望你能和我們一起一些事情讓更多的人了解 TiDB：

《TiDB 源碼閱讀》是面向開(kāi)發(fā)者的系列文章，幫助 Contributors 了解 TiDB 的實(shí)現(xiàn)細(xì)節(jié)，讓數(shù)據(jù)庫(kù)內(nèi)核這個(gè)東西在大家眼中不再神秘，希望越來(lái)越多的人能參與到 TiDB 這個(gè)項(xiàng)目中來(lái)，做一個(gè)世界頂級(jí)的開(kāi)源數(shù)據(jù)庫(kù)項(xiàng)目。

Talent Plan?是面向在校學(xué)生準(zhǔn)備的數(shù)據(jù)庫(kù)開(kāi)發(fā)課程，希望通過(guò) 3~4 周的導(dǎo)師帶學(xué)，讓同學(xué)們能夠了解如何做一個(gè)分布式數(shù)據(jù)庫(kù)，能夠基于 TiDB 開(kāi)發(fā)新的功能，做一些和數(shù)據(jù)庫(kù)研究相關(guān)的實(shí)驗(yàn)項(xiàng)目。目前已經(jīng)有多名同學(xué)將自己的畢業(yè)設(shè)計(jì)題目選為 TiDB 相關(guān)的事情。

除了「寫(xiě)文章，做導(dǎo)師」，我們也非常鼓勵(lì)大家走出公司做分享，各位可能已經(jīng)在國(guó)內(nèi)各大技術(shù)會(huì)議上看到了 PingCAPer 的身影，其實(shí)這只是冰山一角。我們?cè)诟鞯囟加卸ㄆ谂e辦的 Infra Meetup，有對(duì)外公開(kāi)的技術(shù)方案評(píng)審和 Paper Reading，有高校實(shí)驗(yàn)室交流，有海外會(huì)議布道。在過(guò)去的一年中，我們舉辦或參加了八十多場(chǎng)技術(shù)/學(xué)術(shù)交流活動(dòng)，把 TiDB 的旗幟插到了世界各地。

我們希望大家能全面發(fā)展，這些活動(dòng)的存在也是想給大家足夠的舞臺(tái)來(lái)施展才華，作為拜仁球迷，我想說(shuō)：“在 PingCAP 你甚至可以寫(xiě)代碼?！?/strong>