曾幾何時，人們在換手機時如何將資料備份/恢復還是一個令人頭疼的問題。iCloud 的出現將 iPhone 的備份管理解決得無比漂亮，而且非常深入人心，現在 iPhone 使用者換手機已經是一件沒什麼壓力的事情。
而對於每一個資料庫使用者而言，資料庫備份/恢復也是一項剛需，雖然備份管理經常被人忽視，但是一出事就是大事，對於企業來說沒有資料就沒有一切，資料備份恢復是防範災難於未然的強力手段。據統計，企業中約有 11% 的成本和精力分配在了資料備份管理上。
目前，TiDB 使用者可以使用 BR 做全量備份，並持續做增量備份，利用這些備份就可以恢復資料，但是它只能恢復到做備份的幾個時間點，粒度還不夠精細。而使用 TiCDC 或者 binlog 雖然可以精細地記錄增量的事件，恢復資料到全量備份之後的任意時間點，但 BR 本身還沒有原生支援 PiTR （point-in-time recovery）。即使實現了該功能，現在業界的解決方案也面臨著複雜、易碎、高成本等問題，那 DBA 做資料恢復能不能像換 iPhone 那樣簡單呢？
pCloud 團隊在本屆 TiDB Hackathon 中開發了 pCloud 專案——一個全面託管在雲端的 SaaS 服務，可以一站式託管資料庫的備份/恢復，支援 Time Travel （恢復到任意時間點），並且底層基於 S3 儲存，儲存成本極低。pCloud 團隊憑藉這一專案一舉獲得了“二等獎”和“雲啟資本特別贊助最佳市場潛力獎”。
pCloud 是一個非常有意思的專案，東旭同學直接上場帶貨，先拋開他個人現場極大的感染力，從實際來看，pCloud 真的做得很不錯。雖然現場東旭只是展示了產品效果，聊了聊商業模式，但我知道這個專案的底層實現還是很有挑戰。這也給了下一屆 TiDB Hackathon 參賽同學另一種參考：一個專案，大家有時候更容易關注技術本身，但如果我們是做一個產品或一個 SaaS 服務，對於使用者的理解和商業的理解也非常關鍵。所以，即使大家覺得自己對 TiDB 沒太多理解，寫不了太 hardcore 的程式，也可以從另外的方向來突破。
——評委唐劉
團隊：pCloud 是如何組成的？
pCloud 的團隊由 4 位選手組成，其中包括第一次以選手身份參賽的我司 CTO 黃東旭。在往屆比賽中他都是評委，但一直心裡癢癢想當次選手，想到 Hackathon 比賽專案一屆比一屆硬核，今年如果再不趕緊上車，以後估計更沒戲了。這次他在戰隊裡的主要角色是貢獻專案 idea ，畫產品原型圖，並作為產品經理指導團隊開發。
黃東旭：決定參賽的時候，我先去找了龍恆（ TiMatch 隊長），問他我有一個很牛的 idea 你要不要幹一下？他說自己已經決定做 TiMatch 了，但還是幫我找來了欒成、王浩和峻岑三位隊員。
欒成：當時東旭找我的時候跟我描述了一下他的想法，說需要一個前端工程師，我就想到了之前知乎同事裡有一位前端大佬王浩，人在新加坡，當時他們那邊應該是聖誕節，正好有時間就同意加入進來，在 pCloud 裡主要負責前端網站的搭建。峻岑和我一直都在 PingCAP 做備份恢復，這次的主要工作就是把現有的工具（如 BR 等）接到 pCloud 上，做一些適配工作。
黃東旭：雖然我是第一次參加，但是作為資深評委，我知道專案的完成度其實還是挺重要的，所以找到了一個好的前端等於已經成功了一半。
（ 東旭：我專門請設計師設計了一個產品 logo，一個好的 logo 等於成功的一半~）
起源：一次商業模式的頭腦風暴
黃東旭：大概在 2020 年初，我們有一次關於 TiDB 可規模化商業模式的頭腦風暴。一般來說，資料庫的商業模式基本都是賣個服務什麼的，但我隱隱約約覺得 open source 是一個很像 ToC 的東西，有沒有可能用一些 ToC 的思路去看看 TiDB 的商業化呢？
過去做商業資料庫的商業模式基本上就是收服務費，被保護的場景越重要，能收的服務費就越多。但是這個思路在“開源+雲”時代發生了重大的變化：第一，Cloud 會變成一個特別普及的東西；第二，開源資料庫超過了閉源資料庫，它的成熟度已經基本上能夠滿足大多數核心的業務場景需求，開源資料庫使用者變成了一個非常龐大的群體；第三，Cloud 有一個好處，它把交付實現了標準化，並且付費的門檻降低了。當年 ToC 端出現了微信、支付寶等快速支付渠道，將支付門檻變得特別低，才有了愛奇藝這些訂閱模式。
所以，基於這三個前提，你就會找到一個新思路：找到使用者旅程中的通用路徑，先不管核心不核心，極致優化使用者（開發者）體驗，然後利用雲的基礎設施把成本做低，最後利用流量入口 + PLG 走病毒式傳播的路線。pCloud 這個專案的關鍵在於——第一，企業級使用者能不能找到一個低門檻的支付渠道， 比如 SaaS；第二，這個模式一定要特別輕，不能特別貴，必須得找到一個非常自動化的切入點。因為一旦涉及到人工提供服務，這個事情就廢了；第三，這個東西的使用者群體要足夠廣， Database 本身是一個使用群體特別廣的東西，而在 Database 裡其實有一些東西的使用群體也特別廣，那就是備份恢復。
在 ToC 領域裡，關於消費者有一個衝動消費的心理學，這需要有幾個前提：第一，你馬上就能理解這個東西是什麼；第二，好像我一定需要；第三就是這東西得特便宜。這些都具備了，消費者就可能產生衝動消費的心理。所以，我們借用了 iCloud 換手機的概念，給大家制造一個錯覺，這個東西我一定需要。因為大家都需要 iCloud ，我們就把這個概念平移到 DBA 領域。如果你是一個普通消費者，其實很容易就被這樣的概念吸引並付費。
挑戰：看起來不硬核，但工程度複雜
欒成：整體來說，我覺得最困難的是要把這些資源整合在一起，並且遮蔽掉很多技術細節，給使用者呈現出的是一個更簡化、更易用的介面。在此之前，備份 PiTR 、 TiUP 以及 SaaS 服務都是一些很零散的東西，但在這次效果展示中，我們要把它們整合在一起，這其實是要花一些功夫的。例如將 TiUP 整合到 PiTR ，實際上背後是起了很多個元件去執行備份的，然後再把增量的資料寫到 S3。
陳昱：我自己聊過一個類似的專案，他們的軟體真要用起來的話，在做實施時要投入大量的人力物力。而最好的商業模型應該是所有東西都讓客戶 self service ，客戶能夠自己解決絕大多數問題。這樣的話整個東西才容易 scalable ，但現在市場上很多產品都做的太複雜了，以至於實施團隊可能比工程團隊還多。
很多人覺得，這個專案最大的硬傷就是看起來沒有那麼硬核，單從技術、社群的分數上來說，我並沒有給這個專案打特別高的分數。但最後就因為這個產品的理念——「簡潔易用」打動了我，所以給了一個特別獎項。這讓我想到 snowflake 和 Databricks 打口水仗， Databricks 說的永遠都是效能， snowflake 則強調產品的易用性。
黃東旭：老實說我覺得很多團隊或者專案在嘗試什麼都做，想滿足客戶五花八門的需求，設計的產品就特別複雜。但我在這個專案裡就想嘗試一個理念——我非常清楚我的客戶是誰，我會清晰地畫出一個邊界，如果超出了這個邊界的複雜度，就不是我的客戶。邊界裡的這些客戶，會以一個非常順暢的使用者旅程以及非常低廉的價格去使用這個產品。簡而言之，是我的客戶他就會用得很爽。我相信這樣的客戶如果能夠把量做起來，也會是一個好的商業模式。
pCloud 專案的亮點是什麼？
黃東旭：再來說這個專案裡其實有幾個比較硬核的點：首先，企業的備份肯定不是全量備份，而是增量備份。增量備份就要面臨一些問題，比如說要回退到任意一個時間點，同時在這個時間點上不能破壞事物的隔離性，我們通過精心設計的 PiTR 技術（全量+增量），可以以很低的成本儲存全量備份，支援恢復到任意時刻的資料；第二是高可用，我們要假設它跟外網的連線一直是通的，如果網路不通，那你在本地的快取該怎麼處理。如果這個網路是聯通的，你可以直接在 SaaS 服務上實時看到資料中心裡這些叢集的狀態。第三，滿足全球安全合規，資料支援非對稱加密儲存。個人使用者其實不太關心資訊保安，但是企業使用者一定會需要這個功能，這也可以作為這個產品商業化的服務之一。
總的來說，這個專案比起改資料庫核心來說雖然不是那麼硬核，但是我們用了非常多時髦的技術，它其實是一個工程複雜度很高的產品。在組隊的時候，我甚至還想找一個財務同學幫我設計一個更合理的計費模型，但後來覺得這有點太複雜了，最後只用了一個比較簡單的技術。但如果這個產品要繼續深挖下去的話，計費其實也是一個挺複雜的模組。
pCloud 專案的假想客戶是誰？
評委陳昱認為 Hackathon 中絕大多數隊伍的風格更像工程師範，技術講得比較多，但產品設計理念相對來說就少很多，相較而下，東旭對 pCloud 專案的介紹風格在整個 Hackathon 中就顯得特別不一樣，甚至在比賽中已經想好了整個專案未來的商業化模式，這令作為投資人的他好感大增。
黃東旭：國內有一些中小型創業公司，他們可能覺得雲端的 RDS 太貴，就自己買了虛擬機器，在上面部署 TiDB 或 MySQL ，跑了一些企業級應用。因為預算控制，他們一般不會請專職的 DBA ，又不希望工程師的時間花在這些東西上，那他們可能就是這個產品的目標客戶了。在我設想的第一階段商業模式中， pCloud 本身會成為一個“上雲的橋樑”。資料的備份使用 S3 儲存在雲端，特別漂亮的是 S3 是一個雲中立的標準協議，每一個雲都會有 S3 協議的物件儲存服務，所以第二個階段的商業模式需要走向：渠道的商業模式，這個階段需要做兩件事情：
開源（不是 Open Source，而是開源節流那個開源），支援更多的資料庫作為 PiTR 的資料來源（把服務擴充套件到 MySQL PG Oracle 之類的）；
提供一鍵恢復到雲資料庫的能力（例如 TiDB Cloud，Aurora，RDS，Snowflake）。
渠道的商業模式是引流，這個階段必然是各個雲資料庫廠商爭奪使用者的階段，pCloud 如果運作得好，就是一個天然的流量池，玩法很多。一個很好的例子就是 2019 年 MongoDB 收購 mLab，大概就是相似的邏輯。
當然這個階段也不是永久的，我說過資料庫的終局一定在雲端，所以 pCloud 下一個階段故事的模板大概是 FiveTran + Rockset，變成雲端的資料計算平臺，但是 pCloud 有更好的基礎（擁有全量資料），這個階段需要引入雲端 ETL 和 Serverless 用於降低在雲上資料處理和分析的成本，這個階段是沒有天花板的（參考 Snowflake）。
當未來社群使用者需要上雲時，這其實就是一個比較巧妙的工具。他們可以通過 pCloud 直接恢復資料到 TiDB 的 DBaaS 上，連匯入資料、遷移資料這些工具都不需要了。
pCloud 完成度離假想的商業模式還有多少工程距離？
黃東旭：需要分兩部分看，第一是 PiTR 的成熟度，第二個是 pCloud 的成熟度。pCloud 蠻簡單的，關鍵是 PiTR 的成熟度。我會確保它在 PingCAP 的 Roadmap 上。
欒成：沒錯，主要還是 PiTR 本身的質量、效能和所支援的場景。大家都知道， 1TB 資料和 1GB 資料肯定是不同數量級的難度，關鍵點還是要看這個工具的穩定性以及性是否能滿足要求。我記得比賽時 FAQ 有一個問題，如果資料量非常大，出口的 IDC 頻寬打滿怎麼辦？我們就需要做一些類似於資料壓縮的處理，主要難點在這方面。 陳昱 ：備份可能永遠都是剛需，但做得既易用又好用的雲備份確實是比較少的。這東西並不一定要在 TiDB 的生態裡面做，本質上它是一個資料庫的通用需求，有人願意的話是完全可以獨立成立一家公司，在雲上面做 TiDB 或其他任何雲資料庫的雲備份功能，而這也是我看到的這個專案的潛力所在。
參加 TiDB Hackathon 的感受與收穫
雖然在 Hackathon 比賽中取得了二等獎，但東旭仍然覺得誠惶誠恐，感嘆今年的選手們都太強了。
黃東旭：我覺得明年我還是應該去當評委，不當選手了。本來也想做點硬核的專案，但在初賽看到有那麼多非常硬核的專案我就覺得心有餘而力不足了。以後去當評委，我還可以在評委討論的時候把一些特別專業的技術語言翻譯成人話，給其他評委講清楚。
這次 Hackathon 略有一些遺憾，我們有很多想做的功能其實還沒有做，比如金鑰管理。但是因為 Hackathon 是一個兩天的比賽， 需要快速搞個 Demo 出來，但我內心的產品經理之魂是在燃燒的。
王浩：因為我不是 PingCAP 員工，也不是資料庫社群的人，所以我感覺整個社群的同學都很硬核，有激情。我也感覺到整個社群都特別在意硬核這件事情，所有人好像都認為改核心才是一件很酷的事情。我覺得如果要擴大參賽群體，拿到更多 idea 的話，可以專門設定一兩個獎項，給一些看起來比較軟的專案，比如一些 PM 那種 idea 的專案，讓更多社群外的人也可以參與進來，貢獻自己的東西。
欒成：我個人也覺得 Hackathon 的專案之間其實很難對比，比如說一個很硬核的效能調優專案和一個很新穎的 idea 之間如何評判是比較困難的。我期望下一屆組委會能把這些專案分開評比，獨立設獎。
餘峻岑：今年參賽我感覺還是挺開心的，能夠自由寫程式碼，把自己的 idea 做出來，這就是 Hackathon 最吸引人的地方。我個人希望下一次 Hackathon 能夠更熱鬧一些，好吃的多一點。
陳昱：我覺得今年最大的感受是專案質量比去年普遍都要高。作為旁觀者，我感覺本屆 Hackathon 中 PingCAP 以外的參賽者比例大幅增加了，有了更加多元化的 idea 碰撞。其實，TiDB Hackathon 這麼一年一年做下來，好做的 idea 肯定都會被做完，這迫使以後選手要想在賽事裡脫穎而出，就得去找更加硬核的 idea。