即使將范圍從大數據縮小到數據庫這個細分領域，PingCAP 依然是家非常特殊的公司，其產品 TiDB 是市面上為數不多面向 HTAP 場景的數據庫。
傳統意義上，數據庫分成事務性數據庫(TP)和分析性數據庫(AP)。
近幾年興起的 NoSQL 數據庫、如 MongoDB、基于 Hadoop 的 Hbase，更多都是分析性數據庫，通過分布式架構解決大規模的數據查詢、分析問題。
然而，承載生產系統的事務性數據庫卻始終被傳統數據庫廠商所把持，Oracle、IBM 等占據傳統大型企業市場，中小企業及互聯網公司則大多數采用開源技術 MySQL，鮮有新技術、新公司能夠進入這個市場。
2012 年，Google 的 Spanner 橫空出世，這是一款基于分布式架構的事務性數據庫。受到 Google 的啟發，國外出現了 CockroachDB(蟑螂數據庫)等一系列解決 TP 問題的新興數據庫廠商，但國內市場幾乎還是空白，找不到研發這類數據庫的創業公司。
2015 年，PingCAP 成立，填補了國內的空白。
互聯網背景的團隊，用開源模式做數據庫
與市面上其他數據庫廠商不同的是，PingCAP 創始團隊大多數來自大型互聯網公司，如豌豆莢、京東等，幾乎沒有來自傳統IT或者數據庫廠商。
互聯網的背景，創始團隊每名成員都經歷過數據指數級增長的時期，具備處理海量數據的經驗，做數據庫產品會優先考慮擴展性。
同時，因為互聯網公司大多會采取 MySQL 技術，因此 TiDB 最先兼容的是 MySQL 協議，這使得 PingCAP 更容易獲取客戶。
互聯網還有個特點是開源為先，PingCAP 從第一天就確立了用開源方式做數據庫的打法。但與其他團隊不同的是，PingCAP 的創始人劉奇等人，曾經是分布式緩存項目 Codis 的作者，具備開源社區運營的能力，懂得如何借助社區力量發展產品。
開源社區一方面會擴大 PingCAP 產品的覆蓋面，帶來潛在的客戶;另一方面，通過開源社區的運營，PingCAP 將更多精力放在核心產品 TiDB 的研發，其他功能可以一部分由開源社區用戶來實現。
此外，通過用戶反饋，PingCAP 可以了解用戶的潛在需求，作為 TiDB 研發的一個參考。
產品同時支持 TP 和 AP ，強一致性和擴展性是主要特點
最初，TiDB 只是解決 TP 問題，但在實際應用過程中，直接讓客戶用新數據庫替代原先的 MySQL 數據庫難度很大，尤其當數據庫廠商是一家名不見經傳的初創公司。
多數企業客戶的做法是前端仍然保留傳統 MySQL 數據庫，將 TiDB 數據庫作為背后的數據集市，與前端數據庫相連，但這個數據集市的實時性要遠好于 Hadoop 架構的數據集市，可以運行在實際生產系統。
當按照這種方式運行一段時間，客戶認可 PingCAP 的產品后，會逐步替換掉 MySQL 數據庫，將 TiDB 作為前端數據庫。
當客戶將 TiDB 數據庫作為數據集市來使用時，因為前端數據庫要從這個數據集市中查詢數據，因此，對 TiDB 數據庫的查詢功能提出更高要求。TiDB 調整了自己的數據庫執行器，進行 AP 功能的拓展。
這樣一來，TiDB 同時支持 TP 和 AP 功能，成為分布式 HTAP(Hybrid Transactional/Analytical Processing)數據庫產品。
TP 場景下，TiDB 具備強一致性的特點，可以承載金融等對數據一致性敏感度很高的行業。與傳統數據庫相比，TiDB 可擴展性是最大優勢。TiDB 可以通過不斷增加機器來提升性能。
AP 場景下，與 Hbase 等相比，PingCAP 的實時性更好，處理數據的速度更快。
現階段主要覆蓋互聯網金融、游戲等互聯網領域 ，銷售線索主要來自開源社區
與傳統企業相比，互聯網公司更加容易嘗試新技術，互聯網背景出身的團隊也更加能夠清楚互聯網公司的業務特點。
同時，互聯網公司的發展速度大多遠超傳統企業，數據量增長速度極快，對改善底層技術架構、提升數據庫性能的需求更加強烈，特別是在游戲行業、互聯網金融行業。
這些因素促使 PingCAP 早期客戶大多數來自互聯網企業，同程旅游、360 金融、摩拜單車等都陸續成為 PingCAP 的客戶。
截至 2017 年底，PingCAP 整體團隊規模達到 100 人左右，其中超過 80% 是研發，只有一名全職銷售。
一名銷售的獲客能力非常有限，PingCAP 主要還是通過開源社區的方式獲客，銷售人員只負責跟進有意向的企業。2017 年，應用在實際生產環境的用戶達到 200 家，最終產生十幾家付費客戶。
現階段，PingCAP 重點仍然放在產品打磨和社區運營上，尚未進入到產品大范圍推廣階段，因此，2018 年 PingCAP 會考慮進入金融、醫療、物流等傳統行業，但不會大范圍增加銷售團隊，仍然會采取較為謹慎的市場策略。
近期，愛分析對 PingCAP 創始人劉奇進行訪談，他對 PingCAP 的業務模式、未來戰略，以及數據庫行業未來發展趨勢等方面，進行闡述，現將部分訪談內容分享。
基于解決數據庫擴展性問題的初衷 ，產品可同時滿足 TP 和 AP 業務需求
愛分析：您創立 PingCAP 的初衷是什么？
劉奇： 我在京東工作的時候就已經有這個想法，當時沒有一個可以很好實現擴展的數據庫，最普遍的做法是分庫分表。但這種方式存在缺點，第一它的彈性擴展能力比較差，第二是易用性比較差，第三是編程的心智負擔比較大，第四是表達力比較弱。
當時我在做一個項目，也需要分布式數據庫，但是市面上沒有令人滿意的產品。
所以，最開始的定位是想解決自己的問題，中間我們還開發了一個分布式緩存，之后我們開始著手解決數據庫擴展性的問題，就出來創業了。
愛分析：數據庫作為底層技術，客戶選擇供應商會非常謹慎，最初是如何獲取客戶的？
劉奇： 2016 年，我們拿到了云啟資本的 A 輪融資之后，開始考慮怎么去獲取第一批用戶。的確，用戶將一個新的數據庫應用到線上是存在風險的，誰愿意拿自己線上的業務去冒險嘗試一個全新的數據庫?
蓋婭互娛是我們第一個用戶。那個時候，他們的 MySQL 數據庫出現了問題，線上查詢速度特別慢，整個系統已經卡頓到無法使用，不嘗試使用新的技術已經很難開展業務。我們當時的產品還在測試階段，他們就開始推動這個數據庫上線。
因為采用新的數據庫到線上確實是存在風險的，因此很多用戶采用另一個方式來做。線上有一堆 MySQL 在運行，他們在后面搭建一個大的數據集群，把所有的數據全部匯到這里，看起來有點像數倉。因為我們本身是兼容協議的，我們可以把數據復制過來，他們來進行實時查詢。
在游戲行業或者是實時性要求比較高的風控管理，他們就急需要這種技術來解決問題。
我們目前披露了很多金融案例，有相當一部分都是用在實時風控這個場景。好處是不直接針對線上業務，風險相比線上 MySQL 要小，而又剛好解決了他們的痛點。
這個階段之后，客戶如果覺得技術足夠穩定，他會把線上撤下來，再把我們的產品推到最前面去，來支撐所有業務。
當客戶把我們的數據庫當作數倉的時候，其實查詢的復雜程度很高，我們的數據庫能幫助客戶做一些以前不敢做的事情，一個 SQL 查詢語句甚至好幾頁紙那么長。
那么問題來了，我們的設計本身并不是為了 AP 業務，而查詢這個功能是側重 AP 的，因此我們在優化執行器的時候，也做了相應的調整，做了 AP 功能的拓展。
這樣一來，我們的產品能同時支持線上 TP 和 AP 業務，我們的產品就變成 HTAP。
當把這個產品做好之后，我們發現產品的特點十分明顯，在這個領域沒有一個強有力的競爭對手，而且這個產品是滿足用戶需求的。很多時候用戶的需求并不能簡單的分為 TP 還是 AP，實際上是沒有明確定義的，甚至客戶并不關心這些，只希望能夠解決自身的問題。
愛分析：從數據寫入和查詢上看，存在行與列的差別，TiDB 如何在一個表里實現的？
劉奇： 行列只是一個存儲的形式，從技術角度來講還是可以做行列變化的。
比如說把冷數據慢慢的后臺轉成列存，然后最新寫入的數據仍然使用行存。前臺還是一個標準的行存，根據數據的冷熱，轉換成行存還是列存。
其實，最新的論文已經提出了新的觀點，數據的存儲并不純粹的是行存或者列存，而是根據訪問頻率，經常訪問的數據使用行存，并不需要掃整個表，實現的方式還是很多樣的。
愛分析：谷歌在做 Spanner 的時候強調其擴展性，在算力上要求是不是比較低？
劉奇： 這是以前谷歌的一個理念，但這樣的話，如果去做一些相對比較復雜的運算的時候，數據庫的反應時間會比較長，這是存儲格式決定的。
不過，谷歌 2017 年的論文當中，已經把存儲格式改成了偏混存的形式。我們跟谷歌的迭代路線是一樣的，而且我們的存儲格式改的更早，因為我們更早的遇到了用戶的實際需求。
愛分析：算法和擴展性是否存在一定的矛盾，復雜的算法會不會影響其擴展性能？
劉奇： 算法和擴展性沒有什么關系，算法主要影響執行的效率。
比如，如果是列存的話，執行效率更高，比如說銀行對所有賬戶的金額進行求和，如果是列存的話會很簡單，但是行存的話要掃描每一行中的金額數據，執行效率很低，但在下層的計算層面并不會有太大的差別。
愛分析：在推到前臺的時候，數據庫要做哪方面的調整？
劉奇： 要根據整個系統的負載，來決定使用多少并發度，會做一些優化。
假設有 100 臺機器，有這樣一個數據集群，均勻地推到每一臺機器上計算，并發度很高的情況下，每臺機器人可能都很忙，這個時候再給它增加任務是沒有用的，機器會崩潰的。
但如果有一個“聰明”的調度器，對指令進行控制，在保持高并發的狀態下，調度不同的機器進行不同運算，這樣機器不至于很忙，不過帶來的問題是，會帶來比較長的延遲。
當然，同樣的數據可能不一定要運用 CPU 來運算，可以用 GPU 或者 FPGA，這對調度器的要求就更高了，按照發展趨勢來看，調度器的能力是衡量一個數據庫性能的重要指標。
愛分析：TiDB 是如何實現實時性的？
劉奇： 因為他本身就是一個分布式的結構，性能是可以繼續擴展的，前面有多少數據的輸入都無所謂。如果現在覺得算的不夠快，通過加機器就可以實現計算。
速度的快慢還跟計算有關系，有的計算是推不到所有的節點上去的。比如，我要把所有的數據拿回來做排序，這就沒有辦法讓所有節點來做。
這種情況，優化器的作用比較重要，它會識別哪些計算需要推到下面做并行運算，哪些只要做出決定就可以。
愛分析：MySQL 構架，數據遷移到 TiDB 能否做到無感遷移？
劉奇： 我們從一開始設計的時候就考慮到了這個問題，針對 MySQL 可以做到無感遷移，如果是 Oracle 或者 DB2 的其它協議的話，可能涉及到改代碼的問題。
愛分析：面向其它協議，遷移的周期有多長？
劉奇： 這個還要考慮業務的復雜度，比如，原來的業務有 10 萬條 SQL，只要都要驗證一遍，如果本身業務比較復雜，那就會比較快。MySQL 協議這邊，我們很快就可以做 POC。
愛分析：下一步有沒有考慮去支持 Oracle 或 DB2 的快速遷移？
劉奇： 我們沒有這方面的打算，因為新的業務已經不用這些技術了。如果考慮這些的話，目的就是切入老項目。在切入老項目時兼容性存在一個問題，用戶需要知道新技術的兼容性到底是多少?我能不能放心的使用新技術替換?
兼容性不僅是功能的兼容，Bug 也要兼容，真正做到 100% 兼容是很難的，企業原來的程序員可能也離職了，如果去替換老的業務，工作量、風險都會很大。
現階段互聯網金融、游戲等偏互聯網行業是重點行業 ，適用于數據量大、業務復雜性高的場景
愛分析：產品主要針對哪些行業的客戶？
劉奇： 我們在商業化的過程中，最重要的是把產品做出來，然后根據客戶的需求去完善它的功能。
另外，我們的產品是開源的。開源的好處是當用戶在使用過程中會及時反饋他們的使用體驗和遇到的問題，在這個過程中會發現我們的潛在用戶是誰。
我們的第一個用戶是游戲公司，這其實是超出了我們的預計的，我們認為可能是互聯網優先，因為互聯網對新技術比較激進。
游戲行業也有其特點，游戲公司最賺錢的肯定是爆款游戲的運營，一天的流水可能就有幾千萬。他們希望自己的基礎設施是足夠穩定、強大的，一旦遇到瓶頸再去停機改造，那造成的損失就會很大，因此，他們也希望通過新的技術來解決問題。
再一個就是互聯網以及傳統行業，互聯網企業在使用我們的新產品的時候，表現得還是很保守的 ，因為前面已經有那么多的 MySQL 在使用，突然換新的技術他們會覺得風險很高。
不過，像互聯網金融這類企業對實時性要求還是很高的，要通過實時的信息進行風控管理，以前的方案是無法滿足的，所以會選擇使用我們的產品。
愛分析：TiDB 的應用場景有哪些？
劉奇： 我們的數據庫通用性比較強，一般是面向新的業務需求，我們自身并沒有將數據庫設計成面向某一行業的產品。
說到我們產品的優勢，客戶的數據量必須達到億級別以上，如果數據量比較小，就沒有必要上分布式數據庫;另外，就是業務的復雜性要比較高，這樣我們的優勢更加明顯。
愛分析：下一步會重點側重哪幾個行業？
劉奇： 從營收的角度來講，金融應該會是我們重點布局的一個行業，像物流、醫療等其他領域數據增速也比較快。
團隊主要來自互聯網公司 ，銷售人員極少
愛分析：2017 年 PingCAP 的用戶推廣進展？
劉奇： 我們在 2017 年運行在生產環境的用戶達到 200 個，產品客單價比較高，付費用戶要少一些。
愛分析：TiDB 是一個開源技術，在提供企業級產品時會做哪些強化？
劉奇： 雖然我們提供一個開源技術，但還是有部分是閉源的，比如監控運維組件，備份工具，安全性工具等。
對于企業應用來說，它必須具備很漂亮的用戶界面、很方面的操作工具，這是我們企業版提供的方式。
還有一部分，我們叫做 Database & Service，我們提供的不僅是一個數據庫，而是一個數據庫平臺，企業用戶可以申請 TiDB 數據集群。如果沒有這個東西，可能就需要管理員手動處理，使用體驗差別是很大的。
愛分析：TiDB 是如何收費的？
劉奇： 我們現在有兩方面考慮：一方面可以利用云部署，我們可以看到騰訊云的數據庫入口，這個商業模式比較簡單，與云上的其它產品一樣，按照租賃的方式進行收費。
另一方面，可以買我們的 subscription，也可以買我們的 license，按照節點數來計算。
愛分析：公司的團隊規模？
劉奇： 現在公司大概 100 個人，研發占比比較高，有 82 個。銷售人員只有 1 個，銷售比較少是因為用戶都是自己找過來的，我們在這方面沒有太大的投入。
我們對研發的要求還是很高的，包括研發人員對外面的支持、響應的速度等。雖然看上去不會像 Oracle 那么夸張，但有很多外部公司在給我們做貢獻。
比如，調度器方面的代碼很多是摩拜貢獻的，很多場景下的優化是今日頭條貢獻的，包括韓國三星研究院等，還有很多人在幫我們做測試，這也體現了開源技術的一個好處。
愛分析：研發人員會承擔一部分售前的工作嗎？
劉奇： 在 17 年的時候還存在一些研發人員做售前工作的情況，但 18 年我們會做出一些調整，這也是我們一個很重要的任務。
人員結構的建設要形成一個完整的體系，售前、實施、研發各司其職，根據不同階段的問題安排不同的人去解決。
愛分析：銷售人員比較少的情況下，是不是對社區的運營提出更高的要求？
劉奇： 我認為研發人員比較多，跟社區的交流就會比較快。社區中最主要的用戶是開發者，與開發者的交流肯定是研發人員更加順暢，銷售人員沒法替代這個角色。比如，用戶提出有部分代碼存在問題，研發的響應速度會很快。
像今日頭條、摩拜、同程這些規模比較大的用戶，都是因為存在痛點主動聯系到我們，不需要銷售去做額外的工作。
當然，社區中還存在許多規模比較小的用戶，小的用戶雖然沒有那么大的付費能力，但對社區來說也是有直接作用的。
他們會用自己的場景進行測試，發現很多我們從來沒有遇見過的問題，他們所提供的這些信息對我們來說也是十分重要的，因此我們會花費比較大的力氣來運營社區。
愛分析：PingCAP 的團隊背景以互聯網居多？
劉奇： 對，互聯網出身的多一些，都是規模比較大的互聯網公司，都體會過數據量大了之后帶來的痛苦。
另外，還有來自傳統行業的，售前有來自金融行業的，他對金融行業的使用場景更加清楚一些。
愛分析：切入傳統行業的話，是不是對人員結構的要求有變化？
劉奇： 目前我們還不是這么想的，我們希望通過產品就能夠直接拿下客戶，能夠體現我們產品的優勢。如果是用誰的數據庫都一樣的客戶，我們是不會去爭取的，這也不是我們的強項。
愛分析：產品的研發和社區的維護，精力如何平衡？
劉奇： 我們肯定會先做好一個基礎版，才會在社區中推廣，當遇到 Bug 的時候一定要去修復，不然會影響到很多人的使用，兩者共同推進，并不沖突。
內部研發方面，我們會快速的開發很多新的功能，這些不會馬上就應用到穩定版本，而是先在社區發布一個 Beta 版本，通過用戶測試發現 Bug，我們來進行修復，在不斷的溝通之后，我們才會發布穩定版。
在這個過程當中，我們需要通過社區讓用戶不斷的進行測試來跟我們反饋。因為產品行不行并不是我們自己說了算的，而是用戶來判斷的。
TP 和 AP 融合是未來趨勢 ，數據庫市場未來會更加多樣化
愛分析：CAP 原理中的一致性和可用性存在一定的矛盾，怎么進行優化？
劉奇： 我們在未來會提供一個選項，用戶可以根據自己的需求自己選擇，高一致性或者高可用性。比如銀行的數據就要求高一致性，而互聯網應用就更側重高可用性，我們會都提供給用戶，讓用戶來選。
愛分析：NewSQL 技術與之前的技術有什么不同？
劉奇： 歷史上最開始應用的是 SQL，后來為什么會出現 NoSQL，是因為 SQL 不能擴展，雖然 NoSQL 具備了擴展的能力，但表達力比較差，可能還不支持事務處理，不具備 SQL 的傳統優勢。
NewSQL 就相當于同時具備了兩個優勢，既能很好的擴展，又能具備 SQL 的事務處理能力和表達力。
愛分析：下一步 TP 和 AP 是有融合的趨勢嗎？
劉奇： 我們認為是這樣的，用戶是不關心是 TP 還是 AP 的，解決問題就是硬道理，也不管是線上還是線下，能實時實現我肯定不愿意等一天。
TP 和 AP 分開這是歷史原因造成的，在數據庫剛誕生的時候并沒有去區分。現在技術能做得到，肯定還是希望融合在一塊。數據分析比較復雜的情況可能還會存在單獨的 AP，但我們的產品還在快速的迭代，最后還是要看誰的性能更勝一籌。
愛分析：分布式數據庫平臺領域將來會不會產生另一個 Oracle？
劉奇： 因為歷史原因，短時間內 Oracle 的地位是不可替代的，但新的數據庫構架興起的也很快，現在 Oracle 遇到了前所未有的挑戰，我認為在未來兩年，將會有 20% 的傳統數據庫被新的數據庫取代。
看現在我們的用戶增速，這個趨勢還是相當明顯的。
愛分析：未來市場的格局會發生哪些變化？
劉奇： 我覺得市場會變得更加多樣化。
首先，現在的需求非常碎片化，傳統數據庫不能很好的表達，例如對Streaming 要求越來越高。
關系型數據庫的優勢是通用性比較強，也比較均衡。但有些場景用現在的數據庫框架是很難適應的，肯定不會比專門的設計的數據庫用起來順暢，如圖數據庫等。
從發展趨勢來看，當 NoSQL 出來的時候，大家會考慮它能替代什么樣的場景，后來發現 NoSQL 還是存在很多約束的。NewSQL 的出現確實會改變市場格局，應該以后會有兩三家比較大體量的公司吃掉大部分市場，但小公司依然存在。
愛分析：開源技術的發展會不會影響到數據庫公司的業務？
劉奇： 其實開源技術已經存在很長時間了，像 MySQL 已經有二十幾年的歷史，但企業級應用畢竟不是那么簡單，還存在很多問題需要團隊去解決。
未來不會有完全免費的數據庫，就算是開源的也是要收費的。
愛分析：互聯網公司一般會自己開發基礎設施，會不會對 PingCAP 造成影響？
劉奇： 這個事情要分國內和國外來看，國內的公司喜歡建設私有云，國外差別就比較大，很多國外公司都把自己的私有云給拆掉了，原因也很簡單，自己部署私有云的效率并不如直接使用成熟的公有云。
現在很多互聯網公司不想再像過去那樣被 Oracle 這樣的公司 Lock in，我既要用你的數據庫，又必須具備一定的掌控力。因為互聯網公司成長是很快的，需求的變化也更加明顯，他們希望對數據庫具有一定的理解力和掌控力，以方便互聯網企業修改數據代碼，滿足自身定制化的需求。
愛分析：云廠商最后會不會成為數據庫企業的競爭對手？
劉奇： 數據庫跟云的關系，有點像 APP 和 APP Store 的關系。云廠商可能也會做數據庫，但更多的應該是一種合作關系。
