摘要：日前，我司黃東旭接受了即將開幕的全球軟件與運(yùn)維技術(shù)峰會(huì)記者的采訪，介紹了作為數(shù)據(jù)庫的技術(shù)思考及應(yīng)用情況，以及自創(chuàng)立以來對(duì)開源的一些心得，以下是報(bào)道原文。黃東旭表示看到語言越來越火，感到非常的高興和欣慰。

日前，我司 CTO 黃東旭接受了即將開幕的 WOT2018 全球軟件與運(yùn)維技術(shù)峰會(huì)記者的采訪，介紹了 TiDB 作為 HTAP 數(shù)據(jù)庫的技術(shù)思考及應(yīng)用情況，以及 PingCAP 自創(chuàng)立以來對(duì)開源的一些心得，以下是報(bào)道原文。Enjoy～

作者：查士加

黃東旭提到，自己與朋友一同創(chuàng)業(yè)，理由很簡(jiǎn)單，源自一個(gè)需求。彼時(shí)，黃東旭與劉奇（現(xiàn)任 PingCAP CEO）同屬豌豆莢的分布式存儲(chǔ)團(tuán)隊(duì)，當(dāng)時(shí)的他們開源了 Codis，解決了豌豆莢內(nèi)部緩存的擴(kuò)展性問題，數(shù)據(jù)庫問題成了硬骨頭。如何構(gòu)建一個(gè)對(duì)業(yè)務(wù)端透明，兼具良好的擴(kuò)展性和完整的分布式事務(wù)支持的數(shù)據(jù)庫，是構(gòu)建新一代微服務(wù)架構(gòu)的核心問題之一。當(dāng)時(shí)，團(tuán)隊(duì)在開源社區(qū)并沒有找到比較好的方案，分庫、分表、中間件，這些傳統(tǒng)做法在涉及到業(yè)務(wù)大的改動(dòng)時(shí)會(huì)帶來很大的運(yùn)維成本，如何徹底解決這個(gè)問題呢?

受當(dāng)時(shí) Google 發(fā)表的一系列在分布式數(shù)據(jù)庫方面的論文（Spanner/F1）啟發(fā)，PingCAP 的初創(chuàng)團(tuán)隊(duì)打算從頭開始實(shí)現(xiàn)一個(gè)新一代的關(guān)系型數(shù)據(jù)庫，來解決關(guān)系型數(shù)據(jù)庫的擴(kuò)展性問題。由此看來，PingCAP 創(chuàng)立的初衷很簡(jiǎn)單，就是幾個(gè)工程師想要解決一個(gè)很困難的技術(shù)問題，同時(shí)想通過開源的方式幫到大家。

在 TiDB 研發(fā)早期，從 SQL 層開始，第一個(gè)開源的 TiDB 版本其實(shí)并沒有存儲(chǔ)引擎，后端存儲(chǔ)是 HBase，為了加入存儲(chǔ)層，也為了驗(yàn)證 SQL 的正確性，PingCAP 團(tuán)隊(duì)決定為 HBase 加入分布式事務(wù)的支持，直接對(duì)接在 TiDB SQL 層的后端，這種方法確實(shí)可行。但是考慮到性能和其他一些因素，PingCAP 很快決定用 Rust 重新實(shí)現(xiàn)一個(gè)全新的分布式存儲(chǔ)層，也就是后來的 TiKV。彼時(shí) Rust 還是一門比較新的語言，且以學(xué)習(xí)曲線陡峭著稱，整個(gè)團(tuán)隊(duì)成員都沒有相關(guān)經(jīng)驗(yàn)，好在得到了 Rust 語言官方的諸多支持，PingCAP 和 Rust 語言共同成長(zhǎng)了起來，如今，TiKV 已經(jīng)是 Rust 社區(qū)的明星項(xiàng)目，同時(shí) PingCAP 也是多個(gè)知名項(xiàng)目（如 gRPC 等）的 Rust 語言開源實(shí)現(xiàn)的主要維護(hù)者。黃東旭表示看到 Rust 語言越來越火，感到非常的高興和欣慰。

PingCAP 是國(guó)內(nèi)首家開源的新型分布式數(shù)據(jù)庫公司，其獨(dú)立研發(fā)的分布式數(shù)據(jù)庫產(chǎn)品 TiDB 是一款定位于 HTAP（Hybrid Transactional/Analytical Processing）混合事務(wù)/分析處理數(shù)據(jù)庫的融合、創(chuàng)新型數(shù)據(jù)庫產(chǎn)品。為了實(shí)現(xiàn)這一目標(biāo)，TiDB 在架構(gòu)上將計(jì)算和存儲(chǔ)層進(jìn)行高度的抽象和分離，對(duì)混合負(fù)載的場(chǎng)景通過 IO 優(yōu)先級(jí)隊(duì)列，智能副本調(diào)度，行列混合存儲(chǔ)等技術(shù)使其變?yōu)榭赡?。另外，?TiSpark 項(xiàng)目中，將 TiDB 的存儲(chǔ)層和 Spark 的計(jì)算引擎高效地連接在一起，讓用戶也能夠在 Spark 生態(tài)系統(tǒng)下實(shí)時(shí)的對(duì)數(shù)據(jù)庫中的數(shù)據(jù)進(jìn)行復(fù)雜分析。

黃東旭認(rèn)為，HTAP 給開發(fā)者提供了一個(gè)實(shí)時(shí)數(shù)據(jù)分析方面的新思路，不需要再去維護(hù)另一個(gè)離線的數(shù)據(jù)倉庫，既減輕了 ETL 的工作，又能節(jié)省很大一部分的建立數(shù)據(jù)倉庫所用到的存儲(chǔ)和計(jì)算成本，HTAP 將是未來的重要趨勢(shì)。

一是大中臺(tái)的場(chǎng)景。例如，前臺(tái)的數(shù)據(jù)庫已經(jīng)分庫分表或已水平拆分，TiDB 可以作為所有線上生產(chǎn)庫的從庫，實(shí)時(shí)將數(shù)據(jù)同步到一個(gè)大的 TiDB 集群上，在這一層將數(shù)據(jù)打通，可以直接進(jìn)行復(fù)雜的跨庫、跨表、跨業(yè)務(wù)的實(shí)時(shí) SQL 查詢，由于這是基于 MySQL 的協(xié)議和語法，對(duì)業(yè)務(wù)的侵入性很小，開發(fā)者無需再去學(xué)習(xí)新的查詢語法。

二是為微服務(wù)提供強(qiáng)一致的持久化數(shù)據(jù)層（the source of truth）。其實(shí)微服務(wù)乃至后來的 Serverless 架構(gòu)，一個(gè)核心的問題就是持久化數(shù)據(jù)層，要將無狀態(tài)的業(yè)務(wù)邏輯容器化、服務(wù)化很方便，但是帶狀態(tài)的存儲(chǔ)層在滿足 SQL 和強(qiáng)一致甚至 ACID 的情況下實(shí)現(xiàn)彈性伸縮，在現(xiàn)有的方案下仍十分困難，而 TiDB 可以完美的在這類架構(gòu)中填補(bǔ)這一空白。

三是 MySQL 分庫分表的完美替代品。TiDB 與 MySQL 的語法、MySQL 社區(qū)的工具（如 Mydumper/PhpMyAdmin 等）完美兼容，可讓 MySQL 應(yīng)用無需修改便可直接運(yùn)行。這讓很多用了 MySQL 的業(yè)務(wù)在遇到大數(shù)據(jù)量的場(chǎng)景時(shí)，能夠無縫的切換。

TiDB 產(chǎn)品的整體架構(gòu)是分層的，由分布式 SQL 層（TiDB）、分布式 KV 存儲(chǔ)引擎（TiKV）以及管理整個(gè)集群的 PD 模塊組成。無限水平擴(kuò)展是 TiDB 的一大特點(diǎn)，這里所說的水平擴(kuò)展包括兩方面：計(jì)算能力和存儲(chǔ)能力。TiDB Server 負(fù)責(zé)處理 SQL 請(qǐng)求，隨著業(yè)務(wù)的增長(zhǎng)，可以通過簡(jiǎn)單的添加 TiDB Server 節(jié)點(diǎn)，在提升整體處理能力的同時(shí)，提供更高的吞吐能力。TiKV 負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，隨著數(shù)據(jù)量的增長(zhǎng)，可以部署更多的 TiKV Server 節(jié)點(diǎn)，解決數(shù)據(jù) Scale 的問題。PD 會(huì)在 TiKV 節(jié)點(diǎn)之間以 Region 為單位進(jìn)行調(diào)度，將部分?jǐn)?shù)據(jù)遷移到新加的節(jié)點(diǎn)上。由此可見，企業(yè)在業(yè)務(wù)的早期可以只部署少量的服務(wù)實(shí)例，隨著業(yè)務(wù)量的增長(zhǎng)，能夠便捷地按照需求添加 TiKV 或 TiDB 實(shí)例。

據(jù)介紹，目前，包括摩拜單車、同程旅游、餓了么、360 金融、游族網(wǎng)絡(luò)、今日頭條、蓋婭互娛、猿輔導(dǎo)、易果集團(tuán)、去哪兒網(wǎng)等 200 余家不同行業(yè)的領(lǐng)先企業(yè)已經(jīng)將 TiDB 應(yīng)用在實(shí)際的生產(chǎn)環(huán)境中，涉及互聯(lián)網(wǎng)、游戲、金融、政府、電信、制造業(yè)等多個(gè)領(lǐng)域。

其中，今日頭條和易果集團(tuán)都是比較典型的案例。

以今日頭條為例，今日頭條 APP 的自研 S3 存儲(chǔ)系統(tǒng)，數(shù)據(jù)量級(jí)已近上百億。在用 TiDB 前，今日頭條的元數(shù)據(jù)存在 MySQL 2.8TB 的磁盤里，因?yàn)閿?shù)據(jù)量增長(zhǎng)迅速，導(dǎo)致磁盤不夠用，只能用分庫分表的方案，當(dāng)時(shí)的方案是 MyCAT。但是分庫分表帶來一些問題，如：無法做 OLAP 分析;有丟數(shù)據(jù)的問題，數(shù)據(jù)雖然已經(jīng) commit，實(shí)際并沒有保存下來;還有連接的問題，有些業(yè)務(wù)沒有帶分片鍵的查詢，會(huì)消耗非常多的連接，造成沒有連接的情況。

如今，今日頭條使用 TiDB 替換了原有的主從 MySQL 數(shù)據(jù)庫，上線后效果非常明顯：

TiDB 支撐著今日頭條 OLTP 系統(tǒng)里數(shù)據(jù)流量較大、QPS 較高的場(chǎng)景。例如今日頭條、抖音;

QPS 一直在上升，目前均值十幾萬;

已經(jīng)穩(wěn)定運(yùn)行近半年，做過一次擴(kuò)容。

易果集團(tuán)是一個(gè)典型的 OLTP+OLAP 混合場(chǎng)景的案例。在上線 TiDB 之前，易果集團(tuán)的實(shí)時(shí)系統(tǒng)已經(jīng)遇到了瓶頸：

SQL Server 當(dāng)數(shù)據(jù)量到達(dá)一定階段，性能出現(xiàn)拐點(diǎn)，彈性擴(kuò)展很難實(shí)現(xiàn);

HDFS+Hive+Spark+Presto+Kylin 方案在數(shù)據(jù)量增大的情況下，ETL 越來越慢，很難滿足更復(fù)雜的 OLAP 需求，與此同時(shí)，業(yè)務(wù)對(duì)實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)的需求越來越強(qiáng)烈。

通過對(duì) Greenplum、Kudu、TiDB 等多個(gè)方案的選型評(píng)估，最終易果集團(tuán)選擇了 TiDB 的方案：使用 Flume、Syncer 數(shù)據(jù)實(shí)時(shí)同步到 TiDB，并使用 TiSpark 替換 Hadoop 進(jìn)行實(shí)時(shí)數(shù)倉業(yè)務(wù)。目前，在 TiDB 的支持下，易果集團(tuán) T+1 數(shù)倉已升級(jí)為實(shí)時(shí)數(shù)倉，TiDB 天然的滿足了數(shù)據(jù)量線性擴(kuò)展的問題，同時(shí)還節(jié)省了大量的運(yùn)維成本。TiDB 作為一款 HTAP 數(shù)據(jù)庫，為易果集團(tuán)創(chuàng)建實(shí)時(shí)、統(tǒng)一的混合數(shù)據(jù)庫提供了可能。

最后，黃東旭表示，開源是一種非常先進(jìn)的軟件開發(fā)模式和推廣模式，對(duì)于基礎(chǔ)軟件來說，開源是一種很重要的手段。他引用了開源社區(qū)里流傳甚廣的一句話：只要眼睛足夠多，Bug 無處藏。從這個(gè)邏輯的角度來看，對(duì)于基礎(chǔ)軟件來說，用戶越多，使用場(chǎng)景越多，見過的 Workload 越多，得到相應(yīng)的反饋越多，這些來自一線的反饋能夠更好的讓你看清方向和產(chǎn)品存在的缺陷，更快的迭代以達(dá)到更加完美的狀態(tài)，避免閉門造車；另外一方面，社區(qū)和生態(tài)會(huì)成為你最大的護(hù)城河，從而構(gòu)建真正的商業(yè)壁壘。黃東旭總結(jié)，PingCAP 這幾年發(fā)展的如此之快，與他選擇了開源的戰(zhàn)略密不可分。