【51CTO.com原創稿件】七年一劍，華麗蛻變。自2012年起連續6年15場峰會，凝聚大量技術專家，博觀而約取，厚積而薄發。2018WOT全球軟件與運維技術峰會5月18日揚帆起航，圍繞12大核心熱點，匯聚海內外60位一線專家，打造高端技術盛宴!

在5月18日下午的C會場“大數據處理技術”專場中，PingCAP聯合創始人兼CTO黃東旭將帶來精彩的分享。會前，51CTO記者有幸采訪到他，針對HTAP數據庫和TiDB進行了深入的交流。

PingCAP聯合創始人兼CTO 黃東旭

創立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這幾年發展的如此之快，與他選擇了開源的戰略密不可分。

5月18-19日，北京•粵財JW萬豪酒店，全球最值得關注的IT技術盛宴與您不見不散。2018WOT全球軟件與運維技術峰會一定是您發現全新思路、挖掘最新思想、拓展人脈的重要平臺。

目前我們的各項票種已全面發售。需要提醒您的是，購票越早，折扣越大!與KOL零距離交流，呈現不一樣的“英雄盛宴”!

點擊官網了解詳情：wot.51cto.com

9折預售中，搶票從速。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】