大家最近肯定看到了我司 PingCAP 大量放出的招聘信息，2.7 億美刀 D 輪融資，眾多優(yōu)質(zhì)客戶，5.0 版本提升，等等。

如果對我司沒什么了解的可以看看官網(wǎng)咱們的產(chǎn)品 TiDB，和 招聘列表（持續(xù)更新中）。

這里想以個人的角度來講一下咱們的招聘。作為在 PingCAP 3 年半的菜鳥，我不會給你吹 PingCAP 多 NB，讓你趕緊來。而是盡量把問題列出來，看有沒有興趣一起來解決（主要是技術(shù)和技術(shù)管理的突破），趟過這些坑，PingCAP 就成了。

一、先談錢。

首先我要勸退短期內(nèi)迫切需要大量現(xiàn)金的同學(xué)。

能通過面試進 PingCAP 的，肯定也能進 BAT、TMD 幾個大廠。

薪酬結(jié)構(gòu)上，PingCAP 的現(xiàn)金部分勉強能跟上幾大廠，但大廠的股票是實實在在的，到了成熟期就是現(xiàn)金。

PingCAP 則是期權(quán)，你得等到上市或者被收購才能變現(xiàn)。

大廠的業(yè)務(wù)面、股價都相對穩(wěn)定。PingCAP 期權(quán)則有較大的想象空間，如果業(yè)務(wù)發(fā)展順利，從你進來后價值翻番翻番是沒什么問題的，等到可兌現(xiàn)的時候，總收益就比大廠高。

在 2.7 億刀之前，公司基本盤是靠一大批理想主義的天才少年撐住的。（和天才少女，是的咱們有漂亮妹子程序員）

拿到 2.7 億刀前后，高級別的人才招聘占比增大了很多，海外也不少 FLAG 和傳統(tǒng)數(shù)據(jù)庫大廠的資深簡歷。做為一個基層我的感覺是雖然咱還是窮創(chuàng)業(yè)公司，但糧草是足的，支持得住這場硬仗。而且，如果你有 PingCAP 稀缺的技能（下面我展開講），那么議價權(quán)更在你手上。

所以 PingCAP 屬于優(yōu)質(zhì)價值投資，小幾年內(nèi)不急著大錢用，又看好 PingCAP、TiDB 的發(fā)展，那么可以投。

二、個人發(fā)展。

對于年輕的同學(xué)來講，PingCAP 知名度和美譽度還不錯，對履歷來講是有益的，不輸大廠吧個人覺得。

然后從技術(shù)上來講，代碼是開源的水平大家都清楚，公司內(nèi)強者無數(shù)，可以一起學(xué)習(xí)提升。

對于老鳥來說，PingCAP 當(dāng)前在業(yè)務(wù)突破階段（下面展開），處于臨門一腳的時間點。早于這個時間的公司業(yè)務(wù)還沒摸索清楚，風(fēng)險太大；晚于這個點的公司主業(yè)務(wù)已經(jīng)成熟，發(fā)揮空間小很多。

TiDB 是 ”分布式 + 數(shù)據(jù)庫”，任何其一領(lǐng)域都是計算機科學(xué)王冠上的明珠。公司的目標(biāo)市場的深度也可以讓你安安心心做 20 年純技術(shù)。

三、業(yè)務(wù)狀況。

當(dāng)前 PingCAP 的發(fā)力點有幾個，一個個來。

A、社區(qū)用戶：數(shù)量眾多，包括美團、知乎、小米等不少大中廠，TiDB 是諸多技術(shù)團隊的優(yōu)先解決方案。但也要看到，用戶對產(chǎn)品成熟度、性能期望比 TiDB 現(xiàn)狀要高。（出于成本考慮大多都運行在較高壓力下，也就對 TiDB 的要求更高）

各位客戶爸爸的上線意愿挺強的，只要 TiDB 成熟度、性能做好（下面展開），那么 TiDB 大量接入核心業(yè)務(wù)，成為開源、互聯(lián)網(wǎng)企業(yè)的事實標(biāo)準(zhǔn)是可以期待的，這條賽道上競品不多。

B、國內(nèi)金融客戶：當(dāng)前客戶有浦發(fā)銀行，光大銀行、中國銀聯(lián)、北京銀行等，金融客戶是咱們商業(yè)健康發(fā)展的主要動力之一。國內(nèi)還有大量金融客戶在國產(chǎn)化轉(zhuǎn)型，目前咱們和競品處于有來有回的膠著戰(zhàn)斗中，沒有哪家明顯領(lǐng)先。

當(dāng)前挑戰(zhàn)是性能，需要在延遲、穩(wěn)定性等性能指標(biāo)上拉開顯著優(yōu)勢。咱們進場競標(biāo)的機會很多，如果性能能再上一個臺階，這波是可以吃好的。

C、上云：部署有兩種方式，非托管的和托管（TiDB Cloud 服務(wù)，部署在 AWS / GCP）。

非托管不少海外大中廠如 PayPay（日本一家移動支付平臺）、Square、Shopee，海外用戶付費意愿較高，只要 TiDB 產(chǎn)品做好（還是成熟度、性能），順利收錢是水到渠成的。

托管服務(wù)當(dāng)前也已經(jīng)上線，但比起競品（Aurora 等）來說成本還沒有拉開差距，所以業(yè)務(wù)量還小。

上云成本是咱們中長期的發(fā)力焦點，涉及包括存儲層等很多方面的大幅度調(diào)整優(yōu)化。個人相信成本下來之后，托管服務(wù)是明日之花。

總的看，PingCAP 已經(jīng)在市場扎下了根，但上升空間還很大。在這幾年的開拓下，客戶已經(jīng)準(zhǔn)備好了，對 TiDB 是非常歡迎、開放的。咱們唯一需要做的，就是把產(chǎn)品打磨好，性能做上去。

只欠臨門一腳，就等產(chǎn)品提升。

再嘮叨一句，國內(nèi)互聯(lián)網(wǎng)、IT 業(yè)絕大部分以業(yè)務(wù)運營為主導(dǎo)，基礎(chǔ)開發(fā)部門說到底還是為業(yè)務(wù)服務(wù)的。

而像 PingCAP 這樣以技術(shù)推動業(yè)務(wù)的公司，幾乎可以說絕無僅有。對于專注技術(shù)的同學(xué)可以把這點考慮進去。（招聘崗位覆蓋技術(shù)和非技術(shù)，不要誤會）

四、TiDB 產(chǎn)品現(xiàn)狀。

TiDB 從 1.0 到馬上要發(fā)布的 5.0，基本上每年穩(wěn)步迭代一個大版本且進步飛速，有目共睹，眾多客戶爸爸也都用行動和錢包給咱們點了贊，不啰嗦，這里主要講講存在的問題。

歸納起來有三個方面：1、要的功能沒有；2，功能不好用不穩(wěn)定出漏子；3，性能不夠優(yōu)秀，包括線性擴展性、吞吐、延遲、性能穩(wěn)定性、硬件成本等。

不爽的客戶爸爸可以來論壇一起 吐槽，在內(nèi)部重視程度很高，如果長時間沒解決那就是太難搞、或者暫時沒資源搞，畢竟咱們當(dāng)前只是個不到 400 人的創(chuàng)業(yè)公司，看看這波招賢能不能把戰(zhàn)斗力提上來。

第一個不算問題，沒有就等吧，等不到那就...

第二個主要來源于過去對產(chǎn)品定位不夠清晰，想要的太多，單個功能點投入資源、時間遠遠不夠，以及工程管理有欠缺。

在這個問題上，有成熟項目管理經(jīng)驗的大佬如果愿意過來，會有很大的發(fā)展空間，得能上能下：能深入到一線挖掘問題（拿以往方案直接套估計是不行的）、分析原因，又能在更高層次對問題進行抽象歸納，然后給出靠譜的落地方案。

2020 下半年咱們就來了這樣一位老師，指出了咱們不少問題，對功能進行了大規(guī)模精簡，但之前鋪太開了，要收回來逐個做精做細還需要時間。

但這樣的大佬一位是遠遠不夠的，要解決的問題很多，需要很多接地氣的技術(shù)管理人才，也許就是你。

第三點性能問題，部分原因是和第二點相關(guān)（事情鋪太開每項投入不夠），部分原因是隊伍的工程優(yōu)化能力相對于產(chǎn)品要求來說還不足（大佬很多，但性能要求高，挑戰(zhàn)也是巨大的，涉及性能的點很多，工作量也很大）。

瓶頸主要是存儲層（計算層擴展容易，相對壓力小一點），這是當(dāng)前我負責(zé)的部分，下面會展開。

五、組織管理。

麻雀雖小，PingCAP 不僅只有技術(shù)團隊，技術(shù)外的我不熟所以只聊技術(shù)團隊。

PingCAP 做事要看結(jié)果，這個在哪里都一樣，大家應(yīng)該有共識，不啰嗦。

咱們這對出成果的期望時間點比較注重，如果需要較長時間才能出來的事情，那需要做好總規(guī)劃，分解出執(zhí)行計劃，周期性（一般按周）披露進展避免走偏。

這里我本來想聊挺多事情，包括執(zhí)行力的雙刃劍、信息傳遞鏈長度等等，也算吐槽吧。但喝完兩杯咖啡，仔細思考之后，我想所有的小吐槽在這個鮮明的特征下顯得瑕不掩瑜：聽取末端聲音，持續(xù)變革。

也就是說在 PingCAP，不管你在什么位置，只要不是純情緒發(fā)泄，把問題提出來，不管是技術(shù)方面還是管理方面還是其他，絕大部分時候問題都能得到研究，如果多數(shù)人（leader 層，也就是基層管理者）覺得必要的話，就會改進。

而只要有需要，這改進動作可以非常大（可以達到 CEO、創(chuàng)始人這級）、非?？臁?/p>

還有個值得拿出來聊的，是工作邊界不明晰，也是雙刃劍。壞處是在強調(diào)執(zhí)行、成果的環(huán)境下，你可能陷入涉及超出你能力范圍的大坑出不來，而你和你上級都沒察覺到。好處是可以百無禁忌地跨過組、職位的限制來做任何事情、出成果，并得到贊賞。

小結(jié)一下就是，不管是新秀還是老兵，如果你期望一個理想的環(huán)境，來了就有成熟體系帶著飛，把份內(nèi)事做精做透就行，那大廠更適合你。

PingCAP 是個不成熟，但有快速進化動力的地方，你需要和公司一起成長，把碰到的障礙挑出來（做起來其實挺難的，很多人就把問題憋著），一起尋找改進方案，推動變革。

六、加班問題。

首先沒有 996。數(shù)據(jù)庫這種項目不是靠蠻力能做好的，吃好喝好充分休息，才能高質(zhì)量作戰(zhàn)。

咱們提倡課余多讀讀 paper，關(guān)注下前沿，抬頭看路，如果是焦點問題那就劃入課內(nèi)研究。

咱們有北上廣深杭成、灣區(qū)等多地辦公室，大家都習(xí)慣 remote、分布式的工作方式，卡考勤時間意義不大（當(dāng)然開會要準(zhǔn)時）。最重要的還是結(jié)果導(dǎo)向，從承諾到結(jié)果有清晰的自我追蹤和密切溝通。

但咱們上線項目多，人力少，oncall 等需要緊急處理的事情工作量確實也很大，（在過去）給研發(fā)端的沖擊不能忽視，也讓小部分同學(xué)感覺疲憊。

在 2020 下半年咱們進行了改進，通過一個輪值小組來擋住這個沖擊，有一定成效，應(yīng)該還有提升空間。

小結(jié)一下：沒 996，出活最重要。緊急事情還是會加班，改進中。

七、TiDB 存儲層（TiKV）

這里專門講講我在的組，給咱拉點人。這里存儲層包括 Raft、Raftstore、MVCC 模型、存儲引擎，不包括上云特化的特性（有特攻小隊專門負責(zé)）。

上面說過性能問題是咱們業(yè)務(wù)能上一臺階的關(guān)鍵點之一，而存儲層是最大的瓶頸。

在上面列的吞吐、成本、穩(wěn)定性等等一系列性能問題當(dāng)中，延遲又是最突出的一項。

所以存儲層在中近期（一兩年）的目標(biāo)就是性能，2021 年的核心是降延遲。至于給計算層、用戶層的特性、接口，基本不會變動。

對于延遲問題，去年已經(jīng)投入了比較大的精力，幾個大的來源基本定位清楚了，一個是長尾放大（主要是”上層 一”對”下層多”引起，比如寫操作過程涉及一個 TiDB 請求多個 TiKV，單 TiKV 內(nèi)也有類似放大現(xiàn)象），一個是 消息派發(fā)模塊 Batch-System 的調(diào)度問題，還有是 Raftstore 的 IO 模型比較低效。

Raftstore IO 的改進已經(jīng)在做，但其它的還沒人力開搞，所以這里很缺人，有興趣盡快來一起。

在性能問題解決之后，咱們也有些腦洞想在存儲層進行。（要比較久以后了，下面內(nèi)容就先做做夢）

比如重構(gòu) Region 與Raft Group 一對一的模型，大幅降低 Raft Group 數(shù)量。

比如改進 MVCC 存儲模型，3 個 CF 是不是過于低效？歷史數(shù)據(jù)是不是可以分離存放？

比如上云的特化存儲，利用低成本但延遲較高的存儲（S3 等）降低成本。

比如把現(xiàn)在一大堆性能配置參數(shù)改成自適應(yīng)（舉例，IO 效率和 IO 請求體積作為 XY 是一個凸曲線，簡單采樣就可以定位到最佳體積），從而避免人工調(diào)參，以及當(dāng)環(huán)境變化（負載、硬件）時可以快速自我調(diào)整。

比如自研存儲引擎代替 RocksDB（對標(biāo) CockroachDB 的 Pebble），其實天才少年遲先生已經(jīng)完成了一個初版 AgateDB，性能還不錯。

我自己在新引擎上也有些想法，想通過匹配用戶模式、惰性 compact 來降低資源消耗（這個文檔 是一些我對引擎的理解，用于對齊思路再引出新設(shè)計的，里面公式?jīng)]有仔細校驗過肯定有錯，發(fā)現(xiàn)了麻煩私下郵件我，臉皮薄公開處刑不好看 :P）

八、投簡歷來吧！

如果你想先摸摸情況，那發(fā)郵件，我加你微信聊（還在努力擼延遲問題，所以不一定顧得過來），覺得不需要尬聊的就直接郵件簡歷到 liucong@pingcap.com，合適的我作為內(nèi)推蹭點奶粉錢。（投存儲層的我蹭不到 :D）

存儲層我會參與面試，之前有同學(xué)說我這面試難過，這里澄清一下，我是真的菜，作為面官可能比你更虛更緊張。一般不會因為知識點沒到位而刷人，重點看基礎(chǔ)能力素質(zhì)，看“在什么情況下，如何解決問題”，基本問法是“行為面試法”，不用特別準(zhǔn)備。

期待你的投送，來共舉大事?。ㄠ]件，切勿 APP 或網(wǎng)站內(nèi)私信）

歡迎轉(zhuǎn)發(fā)擴散。

PingCAP 劉聰

2021-02-07

如何找自己的職位：用以下職位名在 https://job.pingcap.com/alljob 中查找：

分布式存儲系統(tǒng)研發(fā)工程師
分布式調(diào)度研發(fā)工程師
數(shù)據(jù)庫內(nèi)核開發(fā)（優(yōu)化器）
數(shù)據(jù)庫內(nèi)核開發(fā)（Real-Time Analytics）
Cloud 研發(fā)工程師
Cloud 研發(fā)工程師（Operator）
資深數(shù)據(jù)庫研發(fā)工程師 (General)
資深數(shù)據(jù)庫研發(fā)工程師 (Optimizer)
資深數(shù)據(jù)庫研發(fā)工程師 (Runtime)
Tools 研發(fā)工程師
資深分析引擎研發(fā)工程師
Web 研發(fā)工程師
后端研發(fā)工程師
Site Reliability Engineer
工程效率研發(fā)工程師
數(shù)據(jù)庫測試工程師
數(shù)據(jù)庫安全工程師
數(shù)據(jù)庫產(chǎn)品經(jīng)理
Application Team Leader
Chaos Engineer PM
IT 工程師
運維開發(fā)工程師
前端開發(fā)工程師
前端開發(fā)工程師（社區(qū)官網(wǎng)方向）
資深/高級/中級 TiDB DBA
資深互聯(lián)網(wǎng)架構(gòu)師
社區(qū) BD 經(jīng)理
開發(fā)者社區(qū)運營
資深社區(qū)運營
Community Marketing Specialist 
行業(yè)高級架構(gòu)師 (零售/物流/制造/電商方向)
行業(yè)高級架構(gòu)師 (金融方向)
高級數(shù)據(jù)庫架構(gòu)師
高級應(yīng)用架構(gòu)師 (Java 方向)
資深/高級/中級 TiDB 交付 DBA
資深渠道合作總監(jiān)
資深行業(yè)銷售總監(jiān)
資深售前技術(shù)總監(jiān)
品牌經(jīng)理
高級營銷策劃與運營
高級產(chǎn)品市場經(jīng)理
Field Marketing Specialist
法務(wù)經(jīng)理
高級項目經(jīng)理
高級銷售運營經(jīng)理
渠道銷售經(jīng)理
PTC PM
Inside Sales
資深商務(wù)經(jīng)理