專訪 | 黃東旭：如何運用 HTAP 數據庫幫到你？來聽聽 TiDB 的故事

日前，我司 CTO 黃東旭接受了即將開幕的 WOT2018 全球軟件與運維技術峯會記者的採訪，介紹了 TiDB 做爲 HTAP 數據庫的技術思考及應用狀況，以及 PingCAP 自創立以來對開源的一些心得，如下是報道原文。Enjoy～

做者：查士加

創立 PingCAP 的理由異常簡單

黃東旭提到，本身與朋友一同創業，理由很簡單，源自一個需求。彼時，黃東旭與劉奇（現任 PingCAP CEO）同屬豌豆莢的分佈式存儲團隊，當時的他們開源了 Codis，解決了豌豆莢內部緩存的擴展性問題，數據庫問題成了硬骨頭。如何構建一個對業務端透明，兼具良好的擴展性和完整的分佈式事務支持的數據庫，是構建新一代微服務架構的核心問題之一。當時，團隊在開源社區並無找到比較好的方案，分庫、分表、中間件，這些傳統作法在涉及到業務大的改動時會帶來很大的運維成本，如何完全解決這個問題呢?

受當時 Google 發表的一系列在分佈式數據庫方面的論文（Spanner/F1）啓發，PingCAP 的初創團隊打算從頭開始實現一個新一代的關係型數據庫，來解決關係型數據庫的擴展性問題。由此看來，PingCAP 創立的初衷很簡單，就是幾個工程師想要解決一個很困難的技術問題，同時想經過開源的方式幫到你們。

TiDB 研發早期經歷的那些事兒

在 TiDB 研發早期，從 SQL 層開始，第一個開源的 TiDB 版本其實並無存儲引擎，後端存儲是 HBase，爲了加入存儲層，也爲了驗證 SQL 的正確性，PingCAP 團隊決定爲 HBase 加入分佈式事務的支持，直接對接在 TiDB SQL 層的後端，這種方法確實可行。可是考慮到性能和其餘一些因素，PingCAP 很快決定用 Rust 從新實現一個全新的分佈式存儲層，也就是後來的 TiKV。彼時 Rust 仍是一門比較新的語言，且以學習曲線陡峭著稱，整個團隊成員都沒有相關經驗，好在獲得了 Rust 語言官方的諸多支持，PingCAP 和 Rust 語言共同成長了起來，現在，TiKV 已是 Rust 社區的明星項目，同時 PingCAP 也是多個知名項目（如 gRPC 等）的 Rust 語言開源實現的主要維護者。黃東旭表示看到 Rust 語言愈來愈火，感到很是的高興和欣慰。

PingCAP 是國內首家開源的新型分佈式數據庫公司，其獨立研發的分佈式數據庫產品 TiDB 是一款定位於 HTAP（Hybrid Transactional/Analytical Processing）混合事務/分析處理數據庫的融合、創新型數據庫產品。爲了實現這一目標，TiDB 在架構上將計算和存儲層進行高度的抽象和分離，對混合負載的場景經過 IO 優先級隊列，智能副本調度，行列混合存儲等技術使其變爲可能。另外，在 TiSpark 項目中，將 TiDB 的存儲層和 Spark 的計算引擎高效地鏈接在一塊兒，讓用戶也可以在 Spark 生態系統下實時的對數據庫中的數據進行復雜分析。

黃東旭認爲，HTAP 給開發者提供了一個實時數據分析方面的新思路，不須要再去維護另外一個離線的數據倉庫，既減輕了 ETL 的工做，又能節省很大一部分的創建數據倉庫所用到的存儲和計算成本，HTAP 將是將來的重要趨勢。

HTAP 數據庫的三類應用場景

一是大中臺的場景。例如，前臺的數據庫已經分庫分表或已水平拆分，TiDB 能夠做爲全部線上生產庫的從庫，實時將數據同步到一個大的 TiDB 集羣上，在這一層將數據打通，能夠直接進行復雜的跨庫、跨表、跨業務的實時 SQL 查詢，因爲這是基於 MySQL 的協議和語法，對業務的侵入性很小，開發者無需再去學習新的查詢語法。

二是爲微服務提供強一致的持久化數據層（the source of truth）。其實微服務乃至後來的 Serverless 架構，一個核心的問題就是持久化數據層，要將無狀態的業務邏輯容器化、服務化很方便，可是帶狀態的存儲層在知足 SQL 和強一致甚至 ACID 的狀況下實現彈性伸縮，在現有的方案下仍十分困難，而 TiDB 能夠完美的在這類架構中填補這一空白。

三是 MySQL 分庫分表的完美替代品。TiDB 與 MySQL 的語法、MySQL 社區的工具（如 Mydumper/PhpMyAdmin 等）完美兼容，可以讓 MySQL 應用無需修改即可直接運行。這讓不少用了 MySQL 的業務在遇到大數據量的場景時，可以無縫的切換。

TiDB 解決 MySQL 可擴展性的實現原理

TiDB 產品的總體架構是分層的，由分佈式 SQL 層（TiDB）、分佈式 KV 存儲引擎（TiKV）以及管理整個集羣的 PD 模塊組成。無限水平擴展是 TiDB 的一大特色，這裏所說的水平擴展包括兩方面：計算能力和存儲能力。TiDB Server 負責處理 SQL 請求，隨着業務的增加，能夠經過簡單的添加 TiDB Server 節點，在提高總體處理能力的同時，提供更高的吞吐能力。TiKV 負責存儲數據，隨着數據量的增加，能夠部署更多的 TiKV Server 節點，解決數據 Scale 的問題。PD 會在 TiKV 節點之間以 Region 爲單位進行調度，將部分數據遷移到新加的節點上。因而可知，企業在業務的早期能夠只部署少許的服務實例，隨着業務量的增加，可以便捷地按照需求添加 TiKV 或 TiDB 實例。

據介紹，目前，包括摩拜單車、同程旅遊、餓了麼、360 金融、遊族網絡、今日頭條、蓋婭互娛、猿輔導、易果集團、去哪兒網等 200 餘家不一樣行業的領先企業已經將 TiDB 應用在實際的生產環境中，涉及互聯網、遊戲、金融、政府、電信、製造業等多個領域。

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

今日頭條：用 TiDB 替換原有的主從 MySQL 數據庫

以今日頭條爲例，今日頭條 APP 的自研 S3 存儲系統，數據量級已近上百億。在用 TiDB 前，今日頭條的元數據存在 MySQL 2.8TB 的磁盤裏，由於數據量增加迅速，致使磁盤不夠用，只能用分庫分表的方案，當時的方案是 MyCAT。可是分庫分錶帶來一些問題，如：沒法作 OLAP 分析;有丟數據的問題，數據雖然已經 commit，實際並無保存下來;還有鏈接的問題，有些業務沒有帶分片鍵的查詢，會消耗很是多的鏈接，形成沒有鏈接的狀況。

現在，今日頭條使用 TiDB 替換了原有的主從 MySQL 數據庫，上線後效果很是明顯：

• TiDB 支撐着今日頭條 OLTP 系統裏數據流量較大、QPS 較高的場景。例現在日頭條、抖音;
• QPS 一直在上升，目前均值十幾萬;
• 已經穩定運行近半年，作過一次擴容。

典型 OLTP+OLAP 混合場景案例

易果集團是一個典型的 OLTP+OLAP 混合場景的案例。在上線 TiDB 以前，易果集團的實時系統已經遇到了瓶頸：

• SQL Server 當數據量到達必定階段，性能出現拐點，彈性擴展很難實現;
• HDFS+Hive+Spark+Presto+Kylin 方案在數據量增大的狀況下，ETL 愈來愈慢，很難知足更復雜的 OLAP 需求，與此同時，業務對實時或者準實時的需求愈來愈強烈。

經過對 Greenplum、Kudu、TiDB 等多個方案的選型評估，最終易果集團選擇了 TiDB 的方案：使用 Flume、Syncer 數據實時同步到 TiDB，並使用 TiSpark 替換 Hadoop 進行實時數倉業務。目前，在 TiDB 的支持下，易果集團 T+1 數倉已升級爲實時數倉，TiDB 自然的知足了數據量線性擴展的問題，同時還節省了大量的運維成本。TiDB 做爲一款 HTAP 數據庫，爲易果集團建立實時、統一的混合數據庫提供了可能。

基礎軟件選擇開源社區戰略更加適宜

最後，黃東旭表示，開源是一種很是先進的軟件開發模式和推廣模式，對於基礎軟件來講，開源是一種很重要的手段。他引用了開源社區裏流傳甚廣的一句話：只要眼睛足夠多，Bug 無處藏。從這個邏輯的角度來看，對於基礎軟件來講，用戶越多，使用場景越多，見過的 Workload 越多，獲得相應的反饋越多，這些來自一線的反饋可以更好的讓你看清方向和產品存在的缺陷，更快的迭代以達到更加完美的狀態，避免閉門造車；另一方面，社區和生態會成爲你最大的護城河，從而構建真正的商業壁壘。黃東旭總結，PingCAP 這幾年發展的如此之快，與他選擇了開源的戰略密不可分。