{
    "componentChunkName": "component---src-templates-blog-blog-detail-tsx",
    "path": "/blog/pcloud-as-the-icloud-on-database",
    "result": {"pageContext":{"blog":{"id":"Blogs_350","title":"TiDB Hackathon 2021 — pCloud : 做数据库上的 iCloud丨pCloud 团队访谈","tags":["TiDB Hackathon 2021"],"category":{"name":"社区动态"},"summary":"本篇文章将介绍 TiDB Hackathon 2021 pCloud 团队赛前幕后的精彩故事。","body":"![二等奖 pCloud.mp4](https://img1.www.pingcap.com/prod/p_Cloud_94f7113cd3.mp4)\n\n曾几何时，人们在换手机时如何将数据备份/恢复还是一个令人头疼的问题。iCloud 的出现将 iPhone 的备份管理解决得无比漂亮，而且非常深入人心，现在 iPhone 用户换手机已经是一件没什么压力的事情。  \n\n而对于每一个数据库用户而言，数据库备份/恢复也是一项刚需，虽然备份管理经常被人忽视，但是一出事就是大事，对于企业来说没有数据就没有一切，**数据备份恢复是防范灾难于未然的强力手段**。据统计，企业中约有 11% 的成本和精力分配在了数据备份管理上。\n\n![01.png](https://img1.www.pingcap.com/prod/01_af1662dd63.png)\n\n目前，TiDB 用户可以使用 BR 做全量备份，并持续做增量备份，利用这些备份就可以恢复数据，但是它只能恢复到做备份的几个时间点，粒度还不够精细。而使用 TiCDC 或者 binlog 虽然可以精细地记录增量的事件，恢复数据到全量备份之后的任意时间点，但 BR 本身还没有原生支持 PiTR （point-in-time recovery）。即使实现了该功能，现在业界的解决方案也面临着复杂、易碎、高成本等问题，那 DBA 做数据恢复能不能像换 iPhone 那样简单呢？\n\npCloud 团队在本届 TiDB Hackathon 中开发了 pCloud 项目——一个全面托管在云端的 SaaS 服务，可以一站式托管数据库的备份/恢复，支持 Time Travel （恢复到任意时间点），并且底层基于 S3 存储，存储成本极低。pCloud 团队凭借这一项目一举获得了“二等奖”和“云启资本特别赞助最佳市场潜力奖”。\n\n![winner-pCloud.jpeg](https://img1.www.pingcap.com/prod/winner_p_Cloud_dc5b959e7f.jpeg)\n\n> pCloud 是一个非常有意思的项目，东旭同学直接上场带货，先抛开他个人现场极大的感染力，从实际来看，pCloud 真的做得很不错。虽然现场东旭只是展示了产品效果，聊了聊商业模式，但我知道这个项目的底层实现还是很有挑战。这也给了下一届 TiDB Hackathon 参赛同学另一种参考：一个项目，大家有时候更容易关注技术本身，但如果我们是做一个产品或一个 SaaS 服务，对于用户的理解和商业的理解也非常关键。所以，即使大家觉得自己对 TiDB 没太多理解，写不了太 hardcore 的程序，也可以从另外的方向来突破。\n> <p align=\"right\">——评委唐刘</p>\n\n## 团队：pCloud 是如何组成的？\n\npCloud 的团队由 4 位选手组成，其中包括第一次以选手身份参赛的我司 CTO 黄东旭。在往届比赛中他都是评委，但一直心里痒痒想当次选手，想到 Hackathon 比赛项目一届比一届硬核，今年如果再不赶紧上车，以后估计更没戏了。这次他在战队里的主要角色是贡献项目 idea ，画产品原型图，并作为产品经理指导团队开发。\n\n**黄东旭**：决定参赛的时候，我先去找了龙恒（ TiMatch 队长），问他我有一个很牛的 idea 你要不要干一下？他说自己已经决定做 TiMatch 了，但还是帮我找来了栾成、王浩和峻岑三位队员。\n\n**栾成**：当时东旭找我的时候跟我描述了一下他的想法，说需要一个前端工程师，我就想到了之前知乎同事里有一位前端大佬王浩，人在新加坡，当时他们那边应该是圣诞节，正好有时间就同意加入进来，在 pCloud 里主要负责前端网站的搭建。峻岑和我一直都在 PingCAP 做备份恢复，这次的主要工作就是把现有的工具（如 BR 等）接到 pCloud 上，做一些适配工作。\n\n**黄东旭**：虽然我是第一次参加，但是作为资深评委，我知道项目的完成度其实还是挺重要的，所以找到了一个好的前端等于已经成功了一半。\n\n![03.png](https://img1.www.pingcap.com/prod/03_ed953cf4d5.png)\n（ 东旭：我专门请设计师设计了一个产品 logo，一个好的 logo 等于成功的一半~）\n\n## 起源：一次商业模式的头脑风暴\n\n**黄东旭**：大概在 2020 年初，我们有一次关于 TiDB 可规模化商业模式的头脑风暴。一般来说，数据库的商业模式基本都是卖个服务什么的，但我隐隐约约觉得 open source 是一个很像 ToC 的东西，有没有可能用一些 ToC 的思路去看看 TiDB 的商业化呢？  \n\n过去做商业数据库的商业模式基本上就是收服务费，被保护的场景越重要，能收的服务费就越多。但是这个思路在“开源+云”时代发生了重大的变化：第一，Cloud 会变成一个特别普及的东西；第二，开源数据库超过了闭源数据库，它的成熟度已经基本上能够满足大多数核心的业务场景需求，开源数据库用户变成了一个非常庞大的群体；第三，Cloud 有一个好处，它把交付实现了标准化，并且付费的门槛降低了。当年 ToC 端出现了微信、支付宝等快速支付渠道，将支付门槛变得特别低，才有了爱奇艺这些订阅模式。  \n\n所以，基于这三个前提，你就会找到一个新思路：找到用户旅程中的通用路径，先不管核心不核心，极致优化用户（开发者）体验，然后利用云的基础设施把成本做低，最后利用流量入口 + PLG 走病毒式传播的路线。pCloud 这个项目的关键在于——第一，企业级用户能不能找到一个低门槛的支付渠道， 比如 SaaS；第二，这个模式一定要特别轻，不能特别贵，必须得找到一个非常自动化的切入点。因为一旦涉及到人工提供服务，这个事情就废了；第三，这个东西的用户群体要足够广， Database 本身是一个使用群体特别广的东西，而在 Database 里其实有一些东西的使用群体也特别广，那就是备份恢复。  \n\n在 ToC 领域里，关于消费者有一个冲动消费的心理学，这需要有几个前提：第一，你马上就能理解这个东西是什么；第二，好像我一定需要；第三就是这东西得特便宜。这些都具备了，消费者就可能产生冲动消费的心理。所以，我们借用了 iCloud 换手机的概念，给大家制造一个错觉，这个东西我一定需要。因为大家都需要 iCloud ，我们就把这个概念平移到 DBA 领域。如果你是一个普通消费者，其实很容易就被这样的概念吸引并付费。\n\n## 挑战：看起来不硬核，但工程度复杂\n\n![04.png](https://img1.www.pingcap.com/prod/04_bb6e65ef20.png)\n\n**栾成**：整体来说，我觉得最困难的是要把这些资源整合在一起，并且屏蔽掉很多技术细节，给用户呈现出的是一个更简化、更易用的界面。在此之前，备份 PiTR 、 TiUP 以及 SaaS 服务都是一些很零散的东西，但在这次效果展示中，我们要把它们整合在一起，这其实是要花一些功夫的。例如将 TiUP 集成到 PiTR ，实际上背后是起了很多个组件去运行备份的，然后再把增量的数据写到 S3。\n\n**陈昱**：我自己聊过一个类似的项目，他们的软件真要用起来的话，在做实施时要投入大量的人力物力。而最好的商业模型应该是所有东西都让客户 self service ，客户能够自己解决绝大多数问题。这样的话整个东西才容易 scalable ，但现在市场上很多产品都做的太复杂了，以至于实施团队可能比工程团队还多。  \n\n很多人觉得，这个项目最大的硬伤就是看起来没有那么硬核，单从技术、社区的分数上来说，我并没有给这个项目打特别高的分数。但最后就因为这个产品的理念——「简洁易用」打动了我，所以给了一个特别奖项。这让我想到 snowflake 和 Databricks 打口水仗， Databricks 说的永远都是性能， snowflake 则强调产品的易用性。\n\n**黄东旭**：老实说我觉得很多团队或者项目在尝试什么都做，想满足客户五花八门的需求，设计的产品就特别复杂。但我在这个项目里就想尝试一个理念——我非常清楚我的客户是谁，我会清晰地画出一个边界，如果超出了这个边界的复杂度，就不是我的客户。边界里的这些客户，会以一个非常顺畅的用户旅程以及非常低廉的价格去使用这个产品。简而言之，是我的客户他就会用得很爽。我相信这样的客户如果能够把量做起来，也会是一个好的商业模式。\n\n## pCloud 项目的亮点是什么？\n\n**黄东旭**：再来说这个项目里其实有几个比较硬核的点：首先，企业的备份肯定不是全量备份，而是增量备份。增量备份就要面临一些问题，比如说要回退到任意一个时间点，同时在这个时间点上不能破坏事物的隔离性，我们通过精心设计的 PiTR 技术（全量+增量），可以以很低的成本保存全量备份，支持恢复到任意时刻的数据；第二是高可用，我们要假设它跟外网的连接一直是通的，如果网络不通，那你在本地的缓存该怎么处理。如果这个网络是联通的，你可以直接在 SaaS 服务上实时看到数据中心里这些集群的状态。第三，满足全球安全合规，数据支持非对称加密存储。个人用户其实不太关心信息安全，但是企业用户一定会需要这个功能，这也可以作为这个产品商业化的服务之一。  \n\n总的来说，这个项目比起改数据库内核来说虽然不是那么硬核，但是我们用了非常多时髦的技术，它其实是一个工程复杂度很高的产品。在组队的时候，我甚至还想找一个财务同学帮我设计一个更合理的计费模型，但后来觉得这有点太复杂了，最后只用了一个比较简单的技术。但如果这个产品要继续深挖下去的话，计费其实也是一个挺复杂的模块。\n\n## pCloud 项目的假想客户是谁？\n\n评委陈昱认为 Hackathon 中绝大多数队伍的风格更像工程师范，技术讲得比较多，但产品设计理念相对来说就少很多，相较而下，东旭对 pCloud 项目的介绍风格在整个 Hackathon 中就显得特别不一样，甚至在比赛中已经想好了整个项目未来的商业化模式，这令作为投资人的他好感大增。\n\n![05.png](https://img1.www.pingcap.com/prod/05_c3609d2ab7.png)\n\n**黄东旭**：国内有一些中小型创业公司，他们可能觉得云端的 RDS 太贵，就自己买了虚拟机，在上面部署 TiDB 或 MySQL ，跑了一些企业级应用。因为预算控制，他们一般不会请专职的 DBA ，又不希望工程师的时间花在这些东西上，那他们可能就是这个产品的目标客户了。在我设想的第一阶段商业模式中， pCloud 本身会成为一个“上云的桥梁”。数据的备份使用 S3 存储在云端，特别漂亮的是 S3 是一个云中立的标准协议，每一个云都会有 S3 协议的对象存储服务，所以第二个阶段的商业模式需要走向：渠道的商业模式，这个阶段需要做两件事情：  \n\n1. 开源（不是 Open Source，而是开源节流那个开源），支持更多的数据库作为 PiTR 的数据源（把服务扩展到 MySQL PG Oracle 之类的）；\n2. 提供一键恢复到云数据库的能力（例如 TiDB Cloud，Aurora，RDS，Snowflake）。\n\n渠道的商业模式是引流，这个阶段必然是各个云数据库厂商争夺用户的阶段，pCloud 如果运作得好，就是一个天然的流量池，玩法很多。一个很好的例子就是 2019 年 MongoDB 收购 mLab，大概就是相似的逻辑。  \n\n当然这个阶段也不是永久的，我说过数据库的终局一定在云端，所以 pCloud 下一个阶段故事的模板大概是 FiveTran + Rockset，变成云端的数据计算平台，但是 pCloud 有更好的基础（拥有全量数据），这个阶段需要引入云端 ETL 和 Serverless 用于降低在云上数据处理和分析的成本，这个阶段是没有天花板的（参考 Snowflake）。  \n\n当未来社区用户需要上云时，这其实就是一个比较巧妙的工具。他们可以通过 pCloud 直接恢复数据到 TiDB 的 DBaaS 上，连导入数据、迁移数据这些工具都不需要了。\n\n## pCloud 完成度离假想的商业模式还有多少工程距离？\n\n**黄东旭**：需要分两部分看，第一是 PiTR 的成熟度，第二个是 pCloud 的成熟度。pCloud 蛮简单的，关键是 PiTR 的成熟度。我会确保它在 PingCAP 的 Roadmap 上。\n\n**栾成**：没错，主要还是 PiTR 本身的质量、性能和所支持的场景。大家都知道， 1TB 数据和 1GB 数据肯定是不同数量级的难度，关键点还是要看这个工具的稳定性以及性是否能满足要求。我记得比赛时 FAQ 有一个问题，如果数据量非常大，出口的 IDC 带宽打满怎么办？我们就需要做一些类似于数据压缩的处理，主要难点在这方面。\n陈昱 ：备份可能永远都是刚需，但做得既易用又好用的云备份确实是比较少的。这东西并不一定要在 TiDB 的生态里面做，本质上它是一个数据库的通用需求，有人愿意的话是完全可以独立成立一家公司，在云上面做 TiDB 或其他任何云数据库的云备份功能，而这也是我看到的这个项目的潜力所在。  \n\n## 参加 TiDB Hackathon 的感受与收获\n\n虽然在 Hackathon 比赛中取得了二等奖，但东旭仍然觉得诚惶诚恐，感叹今年的选手们都太强了。\n\n**黄东旭**：我觉得明年我还是应该去当评委，不当选手了。本来也想做点硬核的项目，但在初赛看到有那么多非常硬核的项目我就觉得心有余而力不足了。以后去当评委，我还可以在评委讨论的时候把一些特别专业的技术语言翻译成人话，给其他评委讲清楚。  \n\n这次 Hackathon 略有一些遗憾，我们有很多想做的功能其实还没有做，比如密钥管理。但是因为 Hackathon 是一个两天的比赛， 需要快速搞个 Demo 出来，但我内心的产品经理之魂是在燃烧的。\n\n**王浩**：因为我不是 PingCAP 员工，也不是数据库社区的人，所以我感觉整个社区的同学都很硬核，有激情。我也感觉到整个社区都特别在意硬核这件事情，所有人好像都认为改内核才是一件很酷的事情。我觉得如果要扩大参赛群体，拿到更多 idea 的话，可以专门设置一两个奖项，给一些看起来比较软的项目，比如一些 PM 那种 idea 的项目，让更多社区外的人也可以参与进来，贡献自己的东西。\n\n**栾成**：我个人也觉得 Hackathon 的项目之间其实很难对比，比如说一个很硬核的性能调优项目和一个很新颖的 idea 之间如何评判是比较困难的。我期望下一届组委会能把这些项目分开评比，独立设奖。\n\n**余峻岑**：今年参赛我感觉还是挺开心的，能够自由写代码，把自己的 idea 做出来，这就是 Hackathon 最吸引人的地方。我个人希望下一次 Hackathon 能够更热闹一些，好吃的多一点。\n\n**陈昱**：我觉得今年最大的感受是项目质量比去年普遍都要高。作为旁观者，我感觉本届 Hackathon 中 PingCAP 以外的参赛者比例大幅增加了，有了更加多元化的 idea 碰撞。其实，TiDB Hackathon 这么一年一年做下来，好做的 idea 肯定都会被做完，这迫使以后选手要想在赛事里脱颖而出，就得去找更加硬核的 idea。\n\n> 延展阅读：点击查看更多 [TiDB Hackathon 2021 优秀项目分享](https://pingcap.com/zh/blog/?tag=TiDB%20Hackathon%202021)","date":"2022-02-24","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"pcloud-as-the-icloud-on-database","file":null,"relatedBlogs":[]}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}