PingCAP CTO 黄东旭 - 从Basic到数据库TiDB, 探索开源创业的底层逻辑 | S3E1
《从零道一》是一档访谈类播客。我们寻找真诚、有感染力的新一代行业领袖，让TA们的故事和见解被更多人听见。点击“阅读原文”可直接收听本期节目。
-节目简介 -
本期嘉宾 黄东旭 Ed 是PingCAP联合创始人兼CTO。PingCAP是一家企业级开源分布式数据库厂商，在去年完成2.7亿美元的D轮融资，刷新了全球数据库领域的历史。
Ed 本科毕业于东北大学，他是资深的基础软件工程师，架构师，还是狂热的开源爱好者以及开源软件作者，内存数据库 Redis 的高性能集群架构解决方案 Codis 就是 Ed 的作品之一 。生活中，他还是一名摇滚乐手。创立 PingCAP 之前，Ed 先后在微软亚洲研究院、网易有道、豌豆荚工作。2015 年，Ed、刘奇和崔秋一起成立 PingCAP。创业期间，他从零开始研发并开源了 NewSQL 数据库 TiDB, 目前该项目在 GitHub 上累积超过 26,000 关注数量，被 1500 多家不同行业的企业应用于实际生产环境。
本期节目的主要内容包括:
从开始自学 Basic 语言到开源世界，如何在程序开发领域进行持续探索和实践？ PingCAP 背后的故事：创立的契机是什么？如何拿到第一笔投资？PingCAP 独特的社区文化是如何形成的？ 作为联合创始人兼 CTO，在技术上，商业上的权衡和思考
- 收听节目 -
本期节目的时间线：
0:05:42 第一次接触编程 0:12:01 在大学的新尝试 0:20:08 工作与个人追求：从有道词典到豌豆荚 0:24:41 决定创业的契机: 没有BP，如何拿到第一笔投资 0:33:44 数据库，与PingCAP在做的事情 0:38:17 PingCAP的社区文化 0:47:41 运营开源社区中棘手的事情 0:50:41 对海量数据存储的需求有多少 0:54:44 数据库行业的瓶颈，在被什么主导 0:57:25 如何看待数据一致性的问题 1:01:10 在软件开发过程中使用Rust的体验 1:07:24 设计数据库过程中的思考 1:11:57 作为创始人的管理风格 1:13:50 创业五年来的生活和工作的平衡 1:15:34 同步团队成员的目标 1:17:44 创业中本可以做得更好的事情 1:20:07 如何优化用户体验 1:24:00 快问快答
- 文字整理 -
从零道一：Ed 你好，欢迎你做客从零道一。你最近参加了很多的会议，做了很多的演讲，能不能跟我们分享一下 PingCAP 在 2020 年这个特殊的一年发展得怎么样？在今年有什么样大的计划吗？
Ed: 2020 年是对我们来说非常神奇的一年，有好处有坏处吧。
先说坏处，坏处其实就是当时大的经济环境，还是或多或少受到一些影响。整个上半年我们都没有办法去办公室或者去见客户，对我们 To B 行业还是有一些影响的。
但是我觉得一分为二地看。PingCAP 是一家还蛮特殊的公司，从大概 5 年前，刚开始创业的时候，我们坚定地走远程办公的文化或者实践。所以疫情隔离在家不能出去，对我们的工作本身影响倒是没有太大。
但是在业务方面是发生了比较大的一些变化，比如说我们明显感觉到包括电商、线上一些业务，对我们的技术和产品的需求突然变得非常多。
今年正好也是我们开始做国际化的第二个年头。正好因为疫情，大家在对这种在线业务的需求会更多，所以特别是在海外的客户找到我们，做远程的支持和协作，反而推进了我们走国际化的道路。
总体对我们来说是比较特殊的一年，至于技术和产品方面，我觉得还是按部就班，没有什么太大的惊喜，一切都是在计划之中。
从零道一：你很早就接触了编程，当时的情景是什么样子的？
Ed：我开始写 code 的时间还算比较早。我记得大概是差不多 9 岁的时候，我在家里翻到一本我母亲的 basic 教程，然后家里正好又有一个 80 后可能都知道的小霸王学习机，里边有一个 basic 解释器。因为实在太无聊了，小朋友放假好像也没什么可玩的，就开始觉得里面 basic 的程序能够显示出非常多 ASCII art， 打印一堆星星什么，觉得非常炫酷，然后就开始去理解背后它为什么能做到这件事情，就开始学编程，同时就有点感兴趣。
一开始其实就是简单的把书里面的这些程序输入到解释器里面，后来就开始自己去改，改着改着就有感觉了。我觉得当年其实还是很纯粹的，比如很多小朋友喜欢踢球，有人喜欢打游戏，我就喜欢编程，所以对我来说还蛮自然的一件事情。
后来 basic 已经不太能满足我了，大概在 10 岁/11 岁的时候，终于有了第一台自己的电脑，应该是 97 年。那台电脑因为配置很低，连 Windows 都没有。我就开始去好奇，底层的这些东西是怎么工作起来的。从 C 到当时的 8086 汇编，一直尝试去搞懂计算机是怎么运行起来的。这段时间开始去做一些二进制的安全。当年写程序还是这样，对我来说是很享受的一个事情。
后来到初中开始就接触到 Linux 和开源社区，因为我大多数的东西都是自己学，加上我父母也不是做这方面工作的，所以当时 Linux 社区里边有很多资料帮到了我，整个社区也非常 nice。而且当年青春期有点叛逆，觉得 Microsoft 不好，一定要追求自由、开源软件，就开始投身用 Linux。一直到上大学，爱好又开始转移了，就开始去做 ACM/ICPC 算法竞赛。反正一路过来基本上都是爱好。当年大概是这样。
从零道一：你是在哪里出生长大的？
Ed：老家是在广西南宁，西南边陲小城，还挺正常的一个生长环境。我觉得我家那本 basic 的书可能是我妈大学的必修课，就放在那儿，但是我妈也不是搞那方面的东西。
从零道一：当时你的环境下面，有一些同龄人可以去交流吗？
Ed：当时主要是靠杂志、报纸以及比较垂直的论坛。比如说有一些邮件组，然后还有一些 telnet 的纯文本界面的那种论坛，BBS。当时也是拨号上网，就是电话费还比较夸张。有很多那种打包好的一些学习的资料或者 Linux 的一些 文档什么的。
我还记得有很多资料其实是英文的，就不太看得懂。我从小到大英文还可以，就是因为我觉得需要去看一些 menu，或者一些文档，强迫自己去学的。
从零道一：后来你去了东北大学，是一个什么样的状态？当时有没有做一些对自己影响特别大的尝试，现在还记忆特别深刻的？
Ed：因为在小时候就把大学要学的东西全都学完了，在上大学以后就觉得专业课的东西好简单，没什么挑战。面前就有无穷多的时间需要去消磨掉。
所以当时我就去做 ACM 算法比赛。这个事情从大一开始，一直到大三大四，基本上一直在做算法比赛。比如说我天天都在 poj 上去刷题，后来去经常参加熬夜参加 Topcoder 比赛。每年一到 ACM 赛季就去参加 regional 比赛什么的。在学校里我也是 ACM Club 的负责人，也是个小的 community。
我不知道现在怎么样，但是当时全国做 ACM 的人都不算太多，所以这个群体是很小的。大家需要去交流，我就认识了一些很好的朋友，不一定是我们学校的。有些朋友一直到现在还保持着很好的联系。所以去做 ACM 这件事情对我人生影响挺大的。
有两点，第一点是真正从一个野路子的程序员，开始去关注数据结构算法和时间复杂度之类的，能够用更好更高效的方式去写。即使后来做工程，脑子里还会有根弦，比如这个地方明明能用 n*log(n) 的，我就不能用 n^2 的复杂度去做。所以培养了一些比较好的习惯。
第二就是认识了一拨真的非常优秀的朋友，现在可能有一些人已经是中国互联网的中流砥柱了。因为那时候在本科做 ACM、又做得比较好的同学，应该是真的比较喜欢这个东西。
我们这个行业并不是说你的学校成绩有多好，最后就能成功。反而是，如果你真心地喜欢这个行业、喜欢写 code，结果都不会太差。所以兴趣是最好的老师。
后来到大三的时候我在想，东北大学在沈阳，并不是一个 IT 比较发达的城市。所以当时觉得还是应该来北京。然后就跑到北京，在微软亚洲研究院（MSRA）待了一年多，做一些 AI 方面的研究，机器视觉这样的东西。但是当时还没有 deep learning，所以做得还挺痛苦的。觉得以后如果要搞这个，肯定饭都吃不起了是吧？所以后来就投身互联网去了。所以我大三大四基本都是在北京各种实习，毕业后就留在北京了。
说到研究生，我从很早就不太想读研，或者说在学术上做些事情。我觉得计算机还是工业界做的事情比较有意思。学术界就写写论文，好像就没有什么成就感。
从零道一：你毕业后去了北京，然后先后去了微软亚洲研究院、网易有道，然后再到豌豆荚。在这些团队里面，你做的工作内容都是不太一样的类型。再后来到 PingCAP 的时候，是去做底层架构的这种分布式的系统。
确切的说，你是从什么时候开始研究这方面的工作，以及你当时选择这几份工作，都是出于一些什么样的契机？是自然而然的过程，还是自己想去换不同的软件开发类型？
Ed：因为我接触计算机的时间比较早，其实从最底层到最上层的东西，从最底层几乎到汇编，到操作系统，然后再往上到应用的开发，再往上到前端，我还能写 CSS，写过 iOS 的 code，基本上是什么都能做。
但我当时在参加工作以后，其实第一份正经的、full time 的工作是在网易做有道词典。这听起来有点凡尔赛，但是后来做了几年，整个下载量做到好几亿的时候，你就对这种做 to C 端的产品没什么感觉了。
然后开始觉得，我应该追求一些不变的东西，计算机科学从诞生到现在都没发生变化的东西。于是就开始往下面去走。因为我当时的感觉是，越往下的东西就是越不变的东西，然后开始做基础架构（infrastructure）。
我记得当时在豌豆荚的第一个工作是做 WebKit，就是浏览器的内核这块东西，就相当于客户端的一个 infrastructure。
然后在豌豆荚的后半段的时间，我觉得客户端的东西我不太想做了，我想去看看 web server，web 端这种处理 large scale 的这个东西，它的 architecture。然后去做一段时间后端应用（backend application），去做服务什么的。后来发现再往下，它是 infrastructure，software，就类似 database 或者说一些 cache 这种东西。
所以我做的工作的主线非常简单。开始第一份工作，从上面一直往下走，终于找到了我觉得不能再下的东西了，就到数据库（database）了。
但是还没去搞编译器和操作系统，当然未来可能会搞，但是把这个东西做好再说。
所以整个过程其实是蛮自然的，因为我做很多选择，不会去考虑这个东西挣不挣钱，有没有什么蓝图，主要是比较有趣。这点可能比较任性，但是如果你做一个事情都觉得没意思，就是为了挣点钱，反正我是不太会想做这样的事情。
当时去做分布式系统（distributed system）也是因为觉得事情比较有意思。这么多计算机、这么多台服务器是怎么协同在一起去工作的。
因为摩尔定律毕竟失效了，所以分布式系统我觉得还是一个比较迷人的问题。当时我们看到分布式系统里面最难的一个问题就是，我们怎么去把这种关系型数据库（relational database），或者说，把这种传统单机的数据库软件变成一个分布式的架构；但是同时又能保持原来在单机上面的一些，比如说，一致性（consistency）。
当时觉得这个问题就像珠穆朗玛峰一样，没人做过。然后我们就觉得，我靠这东西太牛逼了，一定要做出来，那就好了。那时我们其实也比较膨胀，就觉得自己这么厉害，没有什么东西做不出来的，然后就选择了这个东西。
从零道一：在其他采访中你提到，你们团队在豌豆荚遇到了 MySQL 的规模化的问题，无法在公司内部解决，所以萌发了创立新的数据库的想法。除此之外，是否还有其他的因素影响你走出来，决定辞职、全情投入去做这件事情？
Ed：对，第一个原因就是你说的，豌豆荚那边的系统本身有一个足够大的问题要去解决。第二个是我怎么说服自己去出来创业，这个话题可能平时谈的比较少，今天就在这说一下。
因为当时决定出来创业的时候，大概二十六七岁，觉得还非常年轻，nothing to lose。就算这个事情做得不好，或者说做挂了，大不了回去上班。当时一个心态是说，这个时机或者这个机会看上去还是挺不错的。
但其实我们当年对这件事情的复杂度和创业本身的难度估计得有点错误，当时觉得创业还挺简单的，但现在回头看看还是挺艰辛，同时又运气还挺好的，所以才能做出来。虽然现在其实也还没有做的太好啦，但是如果让我再去回顾这个过程的话，我觉得哇，创业还是挺难的。
所以当时其实比较 naive 是吧，比较幼稚，然后加上 nothing to lose。当时还想过，如果真的受不了就撤呗，无所谓了。但是后来发现，创业起来了以后，它就像你的小孩一样，你不是说不干就不干的。所有人都可以说不干就不干，但是创始人绝对不可以。所以就是还蛮有意思的一个过程。但后来整件事情也超越了单纯去写一个软件这么简单的事情。
从零道一：如果你现在知道创业后会发生那么多难的事情，重新回到二十七八岁再做出选择，会不会因为害怕就不干了？
Ed：我觉得我可能还会干，但是干的过程可能会更加 smart 一点。如果真的能回到过去，用现在的一些经验和认知，有些错误就不会再犯。但是现在说的轻松，当年认知确实还没到，就只能走些弯路，没办法。但还会去创业的，因为确实还比较有意思。
上班的时候，人的成长是一个线性的成长。随着时间的推移，你的经历线性地增加。
创业的话，就是强行把你拉到一个完全陌生的领域，比如说就像一个人不会游泳，啪，直接丢到大海里，你要游泳吧，如果你在 5 分钟之内学不会游泳你就死掉了。创业有点像这样的感觉，它会让你的成长变成非线性的成长。但一旦你去把这件事情做完了以后，回头一看，哇，原来自己成长了这么多。
其实刚刚没有任何一句话提到财务回报，或者说我要赚多少钱。我觉得这些东西都不重要，因为如果你的目标是奔着这些去的，我个人觉得，你长久的支撑的力量是不足的。但是如果你的目标或者期望是个人的成长，以及「我要完成这些很牛逼的事情」，以这种为动机的话，你其实是会进入一个永远不会满足的一个状态。
所以我觉得如果大家要去创业，一定要选一件事：第一，这个东西不要那么简单就能拿得到。第二，这个东西你做起来觉得，哇，这件事情太有意思了，太牛逼了。我一定要马上就要去做。这就是我觉得 startup 的一个很重要的初心。
从零道一：当时你们三个人一起出来的时候，朝着的一个目标是什么？
Ed：这地方稍微有点技术了，因为其实我们当想去做一个可以扩展的 MySQL 嘛，就是 TiDB，当时想解决 MySQL 规模化（scalability）的问题。所以当时的目标很简单，就是把这个东西做出来。
一开始投资人就问，你这个东西市场怎么样啊？
我说，嗯...不知道，反正挺大的。但是这东西确实很难，没人做出来过。同时我们觉得可能大家都会需要，而且这个东西很难，那就做吧。
当时是有点幼稚，但是还好坚持下来了。所以其实初心很简单，就是想把这种做出来，没别的。
从零道一：你们当时见投资人的时候，听说甚至连商业计划书（BP）都没有写，那是怎么样一个场景？
Ed：我靠当时我们这三个人谁知道什么叫 BP 是吧？都不知道有这个概念。当时是决定出来创业了，我们三个人就讨论，谁认识投资人。有一个哥们儿说，我朋友的朋友好像是搞投资的，介绍一下，那就约了聊呗。
但是我觉得这个投资人还是比较果断，也可能当年闲钱比较多吧，就很快。然后我们当年觉得，啊？原来拿投资这么简单啊。
其实我们不是太主流。我们又没有 BP，也不知道什么是 BP，见面就是聊，这个系统的架构应该怎么做、谷歌的几篇论文到底是什么意思啊，F1 什么的，跟他讲了一通。他可能觉得，这几个人看起来有点疯狂啊。
有的时候你会看到，如果有一个 idea 中规中矩，大家都觉得这个事情没什么意外的，或者说人人都觉得这个东西不错，反而可能不一定是个好 idea。什么是好 idea？有些人觉得，我靠这个东西太牛逼了，有些人觉得这个不行，或者说这个不可能做得出来。当有一些人觉得一个 idea 非常 crazy 的时候，可能这才是一个特别好的 idea。
其实当时我们三个人就想做一个，全世界所有这么多大公司都没有做出来，同时也没有人想做的事情。因为大家都觉得这个事情太难了，这不可能做得出来。当时我们也是有点高估自己的能力啦，但是这种东西一旦做出来，那还是挺厉害。
从零道一：我觉得这是非常激励人的一个故事。经纬那位投资人不一定是投产品，可能投的是人。
Ed：对，其实早期投资就是投人。
因为这东西实在太早期了，早期到我们当时出来创业时候一行代码都没开始写呢，只是说有大概的一个想法。不像很多这些创业公司一出来，开始已经可能有一个 demo 或者说一个原型啊什么的。
我们当时想，这个东西大概花个两年时间能写个第一版吧。就这种形态，连个 PPT 都没有，当时就敢投。但如果我是投资人，我在当年可能不太会投我自己，因为太 crazy 了。
从零道一：能不能简单介绍一下 PingCAP 是什么，现在在做什么样的事情？
Ed：我先说做的事情。刚刚反复在提到数据库这件事情，给一些完全没有用过或听说过数据库的听众科普一下数据库。
大家有没有想过，比如说现在我们用的这种 APP、社交网络、电商网站，你每一次在上面看到的这些商品的信息、你登录的 user profile、你的购买记录，或者订单交易记录，到底是存在哪的？
其实都是存储在数据中心里面，一台台服务器上。它跟你在电脑里面用的 Excel 没什么区别，反正都是存在数据库里，存在 Excel 里。你电脑关机了第二天打开，这个数据还在。我们在做的东西就是一个服务器版的 Excel。
但是第二个问题就来了。你有没有想过，比如说你一台电脑 512G 或者说一个 T 的磁盘，全国人民的数据都往你的电脑里存，超过了容量，你应该怎么办？
这时候一个很自然的想法就是搞另外一台服务器，另外一台电脑，把这个数据放一点到这个上面，两个均摊一下。当这个过程扩展到一千台、一万台的时候，你要去查一条记录到底在哪个 Excel 里，都会很痛苦，对吧？
所以，我们在做一个什么东西呢？事实上它也是这种分布式的，多台服务器帮你把这些数据存起来，但是在你查的时候，就像单机的 Excel 一样去操作。我自动帮你去管理这些数据到底存放在哪台服务器上，同时保证数据的一致性，还有故障、自恢复的这些能力都有。
刚才是一个比较 IT 的比喻，然后我举一个更加日常生活的例子。就像我们平时喝水用杯子，杯子是一个容器。你想象一下，数据库就是一个杯子、一个容器。你的数据就像倒到里边的水一样，这个杯子满了，你再往里倒，它就会溢出来。所以我们在做的事情就有点像设计了一种有魔法的杯子，你不管怎么往里面倒水，这个杯子都会自动变大，永远能够帮你把水装下来，你喝的时候也是把它可以当做一个杯子去喝。
所以这也不难理解，为什么我们的客户和用户有好多好多。因为各行各业都需要杯子。现在我们看到的互联网世界，可能是一座座地面上的高楼大厦，我们的工作就有点像在地底下修下水道的。虽然看不见，但是非常重要。
从零道一：在 PingCAP 的社区文化上，你在早期接触到很多 Linux 的社区，你们对自己的产品也使用了开源的形式。那么，PingCAP 构建的社区和其他的社区是否有什么区别？你心里有一个图像吗，还是你们其实是想要做的是一样的事情?
Ed：首先我觉得开源社区文化是有一个类似普世价值观的，比如说平等、共享、开放，这些在大面上一定是一样的。但在中国运营一个开源社区，会有一些具体的动作或者技巧上有点不一样。我就说说我们的一些技巧或者运营的还蛮有意思的东西。
首先，我们社区最重要的是用户。我们一开始是说，整个优化的方向就是能让这个软件有更多的用户。这个事情也比较自然，就像可能很多海外的一些开源社区更重视开发者或者怎么样，但我们一开始更重视用户，因为我们当时假设说，你只有用户足够大，足够多，同时用的足够深入，就像个漏斗一样，自然会有一批人在这些用户里面涌现出来，说我要去掌握你这个东西，我要去改进你这个东西。
所以一开始像一个鸡生蛋蛋生鸡的一个问题。如果你的目标是找开发者来帮我 contribute code，但是他事实上也没在用这个东西，你会做起来很费劲。但是如果你是一个 heavy user，你就有很多的动力去说，我往这个东西里面去 contribute。所以这是第一个有点不一样的，我们觉得 adoption 或者说用户确实特别重要。所以我们会花很多的时间去优化，去尝试或者使用这个东西的体验，这是第一点。
第二点就是说中国的这种社区文化，其实并不是自底向上的。比如我参与过很多美国的一些开发项目，它的活跃开发者的日常工作（day job）其实是另外一件事情，但是可能在业余时间觉得这东西很好玩，我要去 contribute。但是中国这种情况比较少。当然也有，可能主要是一些学生或者说一些业余爱好者，但是至少在我们社区里面不算主流。
我们的主流其实还是一个大的企业或者说里面的一个数据库团队，他可能已经在大规模地使用 database、在使用我们这个产品。
比如公司的 CTO 说，我觉得这个东西我们用了这么多，有点不放心，我是不是应该让团队去派几个人研究这个东西，相当于内部有一个团队去研究它。
这时候那个公司的高管可能会找到 PingCAP，说“我们虽然没有预算，但是会放一些人在上面”。然后我帮你把自己的人培养成我们社区的 committer 或者 contributor。
对于使用的公司来说，有人对这个东西很熟悉，风险得到了控制；对于我来说，我拿到了我的 contribution；对于实际上去做或者去 contribute、在公司里实际上去维护这个东西的人来说，他在一个开源项目上的贡献，对他未来升职加薪，包括如果以后跳到其他公司，人家一看，这原来是一个知名开源项目的 committer，可能是比做一个企业的内部代码更好的一个事情。
所以这三方：我们，使用者公司的高管，以及实际在参与项目的人（拿着工资来 contribute），这三者的利益的链条就打通了。所以我们很多社区里边的一些活跃用户跟在海外那些自底向上的不太一样。这是第二点不一样的地方。
第三个不一样的地方，就是回避不了的问题，包括一些本土化的运营的手段，比如说语言。虽然我们官方主要的在 GitHub 上其实都是用英文在沟通，但是事实上我们 local 的一些活动，或者说一些论坛还是以中文为主，会更本土化一点。其他的我觉得就跟主流的这些开源社区的差不多。
从零道一：PingCAP 的一个项目叫做 PingCAP University，社区里有人评论如果走完这上面的这些课程，甚至就可以直接成为你们公司员工了，就业都有保障了。我觉得这个是一个非常有趣、也非常棒的一个点子。
Ed：这个项目背后其实是这样的。你现在看起来非常 fancy，idea 也很好，但当年我们是一个有点没有办法的选择。因为我们发现招不到人。
在五六年前，中国做这种分布式系统、或者做 database 的人才其实是很少的，大多数集中在一些科研院校或一些大企业里边，基本上也只能到学校里面招校招学生了。同时你又发现缺乏一些培训的资料。所以我们当时说，干脆我就不找那种做过的。
其实我们做的东西也比较前沿。如果你是一个传统的数据库开发者，你会觉得这帮人做的东西还挺奇怪的。所以这有点像特斯拉是吧？如果你去招一个做汽油车的工程师过来一看，这是什么鬼，电动车，这肯定不能那什么。
所以我们就很困惑，没有办法，只能自己做了。所以当时做 PingCAP University 是让我们招聘的池子变得更大一点几乎唯一的手段。如果你学完这个东西了，至少在我们这边面试的时候，大家能说共同的语言。
我们的早期的员工基本都是从来没有做过数据库的，都是摸爬滚打自己总结出来的一些东西。所以也是没有办法的办法。
但是现在运营的这段时间我觉得还挺不错的。而且从长期来看，这个项目慢慢的就不再是只为了扩大 PingCAP 招聘的池子，或者说省一些招聘培训的工作而设置的了。
因为我个人觉得，中国大学计算机教育问题还挺多的，那为什么不自己去做一些跟工业界真的用得上的一些东西，让下一代的大学生能够学点有用的呢。所以后来就慢慢的变成一个偏向公益性质的东西。
从零道一：在运营开源社区的时候，有没有遇到过一些非常棘手的事情？
Ed：我其实比较欣赏像 Linux「仁慈的独裁者」的这种模式。大的方向是由一个很小的群体去决定，然后从小的群体设计出 road map、社区运转的规则。然后让大家在里边力往一处使。
但是第一点是，你一定要设立一个让大家都认同的目标。比如未来 TiDB 应该往哪个方向去，大家认不认同。如果认同的话，你就相信我们，一起往后走。所以社区的脑子部分一定要想的特别清楚，而且他的决断力以及拍板能力要比较强。
我觉得这是 PingCAP 的一个社区文化，并不是说大家各抒己见，自己松散地想做什么做什么。它是一个有点像计划经济的一个社区。
社区这边唯一让我觉得比较困难、或者说自己不太满意的一个事情，就是社区的成长速度可能比我们自己认知提升的速度要快。我没有想出更多的玩法，让大家更开心地去在里边协作和玩。
这听起来有点虚，但是这确实是我的一个特别大的感受。明明有很多资源在你面前，但是当时怎么没想到，为什么没有去 link 起来呢？所以有时候会比较着急。因为很多社区小伙伴的智慧真的是经常会超出你的想象。
从零道一：从技术上来说，TiDB 和 TiKV 的核心是非常高的扩展性。从你的角度来看，现在行业内对于海量数据存储的需求是什么样的？因为 TiDB 是提供一个 scalability，那么在什么情况下会开始用到 scalability？
Ed：有些公司的 CIO 或者 CTO 来找我说，什么时候能用你的东西，或者说你的东西能够解决我什么问题，我一般是这么回答的：当你现在问我能解决什么问题的时候，说明你还没有遇到这个问题。
当你不得不开始要去思考这件事情的时候，或者说有种种迹象，比如说这个系统开始 go down，你开始知道要去思考容量规划，真正去体验痛苦的时候，你一定会来找我的。
因为只有那时候，你才能真正知道我在做什么东西，否则我现在跟你说一大堆技术你肯定听不懂。当你真正开始去维护 bicycle-sharing，或者说去思考我怎么去把北京的订单放在北京的服务器上，把上海的订单放到上海的服务器上，或者说两边这些数据要怎么去交叉去做分析，遇到这种时候，你脑子里就想到一个有个 TiDB 的东西在后面等着就好了。
所以如果要我说一个黄金的标准，就是如果你是一个公司的技术负责人，你在用肉眼可见的时间内，觉得我这个东西，一台服务器或者说几百个 G，这数据量很小，那你其实大可不必去研究什么分布式，或者说 TiDB 什么的。但是当你脑子里开始觉得，是不是未来三个月我的容量就不够了，我的业务是不是要做重构，这种时候就是一个黄金的信号，你这时候想到有这么一个东西。
所以在过去，比如说 10 年前，其实大多数公司都没有这么大的数据量的问题。可能两三台机器、三五台机器，你在业务上设计的好一点，也就解决了。但是现在，比如说一些增长的特别快的互联网公司，或者说一些新的业务，它本身可能就是数据驱动的，一上来可能就是 100 台服务器，这样的这种规模。
比如说像这种三五台或两三台，你还可以说我人肉手动搞一搞；但是达到一定的规模之后，你会发现，花在维护这些东西上的时间，比你再去设计业务、做业务开发的时间还要长的时候，你就真正体会到这个东西的痛苦了。
所以这也是为什么 TiDB 会这么受欢迎的一个原因，它其实降低的是很多开发者的心智负担。你只要关心业务就好了，你不用管底下我怎么帮你分布式的。
从零道一：你见到非常夸张的比较大的一个数据量，大概会在一个什么样的量级？
Ed：我有一些常规的经验值（不是 100%）。一般来说，针对用 MySQL 的一些用户，你发现你的一张表或者说一个数据库可能超过 500 个 G，同时还在肉眼可见的速度增长，可能是一个信号。
第二个信号，一张表里面有超过一亿条记录，同时在高速的增长，你可能要再想一下。
第三点，你的业务的流量非常大，一台机器可能扛不住，你也看到网卡或者 CPU 撑不住了，这可能也是一个 信号。
从零道一：数据不停地往上增长的话，目前数据库行业有没有你觉得会是瓶颈的？在数据库这个圈子里，有没有什么样的东西在主导？不论是 technical 上面，还是社区文化上面。
我可能会想到一些 case，比如说数据库排行网站 DB-Engines Ranking 上，排名第一的是 Oracle，前十的可能有 Redis、MongoDB、MySQL。TiDB作为一个新秀，会不会遇到早期开发推广上的瓶颈？
Ed：其实瓶颈我觉得倒还好。
首先说整个数据库行业是什么东西在主导。
生态（ecosystem）其实是最重要的，就是说到底有多少开发者习惯用这个东西。比如说 MySQL 跟 PostgreSQL，明显很多人可能觉得 PostgreSQL 的设计比 MySQL 更优雅，或者说性能更好，虽然我不这么认为。
但是有一点是真的，MySQL 的生态，或者说 MySQL 的用户（DBA）比 PostgreSQL 要多很多。所以你会看到，如果我是一个新的创业公司的 CIO 或者 CTO，我在选择用一个技术的时候，一定选择用的人多的东西，这就是 ecosystem。所以数据库这个领域，ecosystem 是主导。
对我们来说，我们在早期推广上选择了一个策略，就是不去重新发明一个 ecosystem，而是选择兼容 MySQL 的生态。因为 MySQL 本身已经是最大的一个生态。对于用户来说，他去看待或者使用你的学习成本是很低的。
所以其实早期我们推广的时候，在产品设计理念里边强调的一个点就是，迁移成本（migration cost）尽可能低。这点是我觉得有点取巧，或者有点借力的。但这点非常 work。
早期的从零到一，或者 ice breaking 这个阶段，就是靠着这两点：一是 MySQL 的痛点，二是 MySQL 的 higher user experience。人家一看，我不用改任何代码就能解决我的问题，那为什么不试试呢？一试，觉得确实解决问题，这个飞轮就转起来了。
从零道一：在数据库的性能指标上，我们一般会讲到吞吐量、延时、还有连接数量等等这些数字。特别是关于分布式数据库，延时和吞吐量之间的关系大家都尤为关心。
比如说吞吐量一上去，延时就跟着上去；把延时往下降，吞吐量也要跟着下来。有时候在实际的业务过程中，想要避开数据库的读写瓶颈，比较常见的一种操作是额外再加一层缓存；但额外的一层缓存又带来了额外的数据一致性的问题。您怎么看待这个问题？
Ed：首先要拆开来看 performance。
对于传统的数据库，特别是单机的数据库来说，它的 scale 本身是有限的。其实你在这两者上很难达到一个很好的平衡。因为一台机器总是有限的，流量过来了以后，你要去处理一致性、写 log，各种各样的东西，一台机器要过载了。
对于分布式数据库来说，如果你的业务的 workload 是足够随机的，比如你的订单从不同的地方过来，那么对于分布式数据库来说，他的 throughput 基本可以做到无穷大。它可以通过比较好的、balance 的算法，把 workload 打到不同的机器上。所以如果你的机器越来越多，即使增长，业务也不用改任何东西。只要有足够的带宽，throughput 就可以做到线性扩展。
但是延时（latency）其实是一个恒定的值。你要去实现强一致，他可能需要走多台机器做交互、两机端提交之类的这种算法。通过网络的能力去保证一致性，所以它的 latency 一定会比单机的数据库的 latency 要大，但是优点在于 throughput 可以做到很高。
所以你怎么去利用这个点呢？
在分布式数据库的时代，其实你应该去把分布式数据库当做你整个系统的 the source of truth。无论你的缓存怎么去做刷新也好，整个系统里边一定会有一个最终的 the source of truth。缓存可以失效，但是你知道往一个地方去读，一定能读到最新、最准确的数据。所以你的缓存只是为了加速这个 the source of truth 就好了。
事实上设计的思路也不是太难想，因为过去其实大家都缺少一个非常好用的、可以 scale 的、强一致的 the source of truth。但是现在比如说像 TiDB 这样的 NewSQL database，其实提供了一种可能性，让你的系统架构变得很简单，你不用再去思考缓存里面的一致性。你要觉得这个东西不一致，直接把缓存设置成过期就好了。
很多时候系统的设计确实是 case by case，但是有一些大的东西是不变的。我觉得计算机里面还有一个很好玩的就是，Everything is a trade off。
从零道一: 你们当时怎么招到 Rust（一种编译型编程语言） 开发者的，会不会想到说，后面招不到 Rust 的人了。使用 Rust 开发一个大型项目的实际体验是怎么样的，有哪些优劣，例如它声称的内存安全实际如何。
Ed: 第一点关于招聘。我们其实大概在四五年前，Rust 刚刚 1.0 的时候，那时在创业之前，我和刘奇（CEO）对这种新的东西比较感兴趣，就周末偶尔玩一玩 Rust。后来开始决定用 Rust 写 Database 时，我们是在几个语言里面选 -- Go，C++，Rust。
说实话就完全没有想过未来招聘的问题，因为我们觉得这个语言真的太棒了。这个语言不火，天理难容是吧？所以当时觉得前途可期。因为我跟刘奇也是 Go 在中国早期的用户，眼睁睁地看着 Go 一步一步起来。所以其实跟着一个语言的发展阶段一起成长，会享受很多红利。这是第一点。
第二点，我们觉得一个特别好的 C++的程序员上手 Rust 并不会有太多的困难。所以反而对我们来说也是一个筛选的标准。但是我没有想到的是，这么多年了，它的上手难度确实还是比较高，它的社区还没有像我想象中的那样快速地变大。Anyway，在人才方面我还是比较乐观的。
当时对 Rust 有一些期望，比如说像内存安全，比如说 zero cost abstraction。好话就不说了，大家到处都看得到。
但是它也有一些不好的地方，在早期我们写的时候社区什么东西都没有，基本上所有东西都给自己造，包括什么 RPC 的库， grpchtv2 都没有的。
比如说有一点可能比较 tech，有时候你用 Rust 那一套去管理内存，比如说什么 Rc，Box 什么的，可能还不如 GC。有的时候你设计得不好，有点偷懒说“算了，我就不用什么所有权什么，直接找一个 Box 分配”，发现有时候有些内存不一定真的要分配，其实转一下所有权就过来了。比如说明明可以浅拷贝的，你非得要深拷贝，像这种代码多了以后，你就会发现它的内存分配的效率还不如用 GC 的语言高效，所以这是一个 dark side。这就是从侧面表达 Rust 的 learning curve 其实还是比较高的。
Rust 有一点我个人特别不爽的，也可能语言还在快速的成长期吧，做同一件事情，它有太多种办法去做了。这件事情其实是跟 C++一样的问题，它很不利于社区的推广，而且往往做一件事情性能最好的方式不一定是最显然的。
从零道一：程序里面内存管理一直都是一个非常有趣的话题，TiKV 里面使用 unsafe 的桥段多吗？
Ed：不多，我觉得我们其实是坚持的比较好的。
从零道一：在整个软件的开发过程中，你觉得 Rust 对产品的影响如何？它的度量有哪些？
Ed：如果说 Go 语言还是像当年那样，进步不是那么快的话，我会觉得还是 Rust 好一点。但现在这几年 Go 本身的进步也很快，所以就稍微有一点抵消了。但是目前来说，Rust 还是一个比较好的选择，确实在 performance 和代码本身的表达力上有一个平衡。
C++是很好，但是如果没有一个特别牛逼的架构师，或者说对 C++非常了如指掌的人，在这么一个复杂和庞大的系统上去做的话，会比较麻烦。其实我们的团队，至少早期我们在起这个项目的时候，并没有这种 C++特别牛的人，反正我觉得我 C++肯定不行。
选 Rust 感觉像是戴上手铐再去写，那这个肯定很安全。我们宁可选择安全一点。目前我觉得还算是满足预期。
但是为了去追求平衡、开发效率，我觉得 Go 的开发效率还是很高的。所以我们有的时候原型会先用 GO 去写，然后去验证这个东西，work 了以后再去把它移植到 Rust 上面，大概这么一个 workflow。其实现在写 Rust 的环境已经很好了，至少有项目可以给你参考了。
从零道一：有没有哪些东西是随着你在数据库行业里面越待越久，做底层设计越来越久，开始有一些认知被刷新了？
Ed：我觉得有几个点。
第一点可能会别人比较受用的是，在设计数据库或者说做软件的过程中，能分层的就分层。一个大的问题，你总是可以去把它抽象成不同的层。不同的层内部是一个很高的内聚。分层带来的好处其实远比简单地去做一个分工要明显。
最明显的好处，就是不同的人或者不同代码可以放在不同的地方。但是做分层的过程会迫使你去思考，比如说这个引擎迫使你去用 API、或者一个契约或协议的方式去思考软件的设计。我觉得分层其实是早期 TiDB 设计中最重要的决策之一。
第二个其实刚才我也提到了，任意复杂的系统，其实都是构建在一些最简单、最显然的原子在规则上面，你去找到这些原子，然后去把它实现出来，让这个系统自己生长出来。这稍微有点抽象。
第三点是，有可能会出错的地方它一定会出错。评价一个系统的质量，比如说对于 TiDB 来说，我们用来做测试的代码的数量，应该比我们数据库内核还要大一个数量级。测试其实是考验系统设计的很重要的一个方面。能出错的地方一定会出错，所以你要不然就强行自己在测试里边去模拟这些错误，让自己提早的犯错。因为对于一个分布式系统来说，你的 deterministic 的 testing 是不存在的，所以你只能靠这种 simulation 去模拟系统，比如网线断了，或者磁盘卡顿了，然后加大让你的系统出错的概率，这个可能是一个比较能 work 的一个方法。
关于 DB 这一块，我觉得认知上比较重要的一点，可能跟技术不太相关了，对于一个软件来说，它真正的核心竞争力到底是什么？到底是性能、功能，还是代码，whatever。
一个软件真正的核心竞争力，其实是它的迭代速度。迭代速度怎么来？这就是为什么我们要开源。我这边统计了一下 TiDB 的代码的变化率，就是每周提交多少个 PR、合并到多少个 PR。如果从一年两年的维度来看，它几乎在每年以超过 50%的速度在迭代自身。比如说拿现在 TiDB 的 performance 跟一年前的这个时间点做对比，基本上性能高 100%，延迟降 100%，质量又好很多。所以如果你是静态地看一个软件，去做横向对比，其实没什么意义。你应该永远去纵向对比。这是一些 takeaways。
从零道一：创业给你带来非常大的一个转变是身份上的转变。你不仅仅是作为 PingCAP 的一员，也是 CTO、联合创始人。你现在带领的团队成员到达一个什么样的规模？
Ed：你要说带领多大的团队，那其实整个公司就是一个团队。
管理风格方面，我更喜欢把我自己定位成一个 Coach。你站在创始人的角度，很难说直接去管理一个大团队，因为你并不是一个职业经理人对吧？有时候我觉得创始人是唯一对整个公司都负责的一个位置。比如你可能是一个团队的 manager，但是创始人会自动让你把屁股放在整个公司的层面上。
所以当你的公司大了之后，很危险的一个思想是说，我自己非常 diving 到某一个 specific 的东西或者一个小团队上面。所以你必须得抽离出来，你应该一定要有一个更大的视角去看。因为你是创始人，这个没有办法。如果以后你要创业，就知道这种感觉了。
从零道一：创业 5 年以来，在心态或者生活和工作的平衡上是怎么样的？
Ed：Work-Life Balance，没有什么 Balance。我觉得这属于我的爱好之一吧。做这件事情，加上这个公司本身，把这些东西做出来，我还挺 enjoy 这个过程的，所以也不能说这个是 work。work 就是 life 对吧？所以就没有什么 balance 了，本身就是 life。
第二是我确实有一些爱好是跟我的本职工作完全没有关系的，比如说琴，还有一些艺术的东西。
但我觉得从更深层次上来看，它又是统一的。我不知道你有没有读过一本书叫做《黑客与画家》。在我很小的时候，对于编程或计算机的喜爱归根结底可能是对一种美和秩序的渴求。
音乐艺术无非是美的一个另外一种表达方式，写程序也是一种方式，所以它本质上其实是一样的。但是通过比如弹弹琴，事实上也是一种放松，放空一下。
从零道一：在实际工作当中你是如何调动团队成员的热情的，向着同一个目标进发的？我们其实会碰到一些例子，比如大家虽然在谈论同一件事情，但其实脑子里面想的最终的样貌是不一样的。
Ed：这个问题每个公司都会遇到。
我觉得有个解法，大家在去真正在开始做事情之前，应该花更多的时间去拉平每个人的认知。很多时候大家可能觉得“好像差不多了”就开始干了，但事实上并没有达成一致。
我们之前包括到现在，这个问题我觉得或多或少也还会存在。因为其实人跟人之间的语言是很弱的东西，比如说像编程里边通过消息来去传递，你总是没有共享内存来的准确是吧？
所以到底是不是真的达成一致了，在前期一是要在团队内部营造出一种大家都可以各抒己见的文化和氛围。大家不要心里有话藏着憋着，一定要说出来。第二就是充分沟通。即使大家最后达不成一致，知道大家的不一致可能也是一种一致，对不对？
至于很多人说“企业文化”什么的，我觉得这些都是 baseline。我觉得如果你连这个公司想做什么事情都不太认可，那你加入来干嘛？所以其实如果在大的方向上互相认同，剩下的我觉得就是沟通了。
但是绝大多数我见过的朋友团队沟通还会不够。在做一个具体事情之前，对这件事情目标过程的认知大面上一致，但是落地上会不一致。但这个是有解决办法的，就是沟通。
从零道一：这五年来，有没有哪些事情觉得其实原本可以做得更好？
Ed: 其实是有的，但这种都是马后炮。我觉得有很多事情，多了去了。
我先说一个技术的问题，在用 Rust 写 TiKV 之前，我们先用 Java 在 HBase 上去做了一个 TiKV 的实现。当时其实最早他的一个是它并不是现在这样使用 Go，Rust，它底下是 Hbase。
那个东西浪费了我个人差不多半年的时间，但是后来觉得在 HBase 上不行。Performance 太差了，这个东西没法改，那个社区也不是我们自己的，没法控制，而且学 Java 太痛苦了。这是我个人觉得做得不太好的一个技术上的决定。
第二个，从商业和战略上说，因为我们都是基础架构工程师（infrastructure engineer），其实我们早期对于用户体验这件事情关注是不够的，对可运维性或者说安装部署这些事情投入不够。包括工具这块，其实觉得还是做内核比较牛逼。
但反而其实你会发现，一个数据库软件它周边的生态是很重要的。所以后来我们就一直在补课，在 ecosystem、易用性这些东西上去补课。其实这一块如果更早地去做设计可能会更好。
我觉得生态工具、刚才 Java 和 HBase 的决策是我每次回想都会觉得：哇， so stupid，为什么这么笨。而且如果能早一点去认知到自己其实并不是一个工程师，这种认知的改变如果发生得更早，会更好一点。
从零道一：在用户体验上面，你现在是怎样去解决的？
Ed: 其实这说起来很简单。第一首先你得重视，你得把自己当做一个没有用过这个东西的人，真正去体验，看看到底什么地方用户会卡着，是吧。你自己当下用户你就知道了，这是第一点。
第二点，不要害怕跟用户去聊。我可能每年要花很多时间一对一地跟实际使用我们的 database 的用户去做深入沟通。
有很多做开源软件的，特别喜欢听人家说：感谢感谢，好用好用，牛逼牛逼。但是听不进批评。这个东西就不好用，或者说你一坨屎什么的。我最近这个认知也是有点改变，好话就听听就得了，反而像骂你的东西，在背后可能有可以挖掘的地方。因为人一般不会莫名其妙地骂你是吧，肯定有理由。虽然人家可能比较激动，但是背后你一挖掘，搞不好确实是很不好用的。
从零道一：在技术上面难点方面，你后面经历过怎样一个思想斗争？
Ed: 当时特别早期，也没什么人，就一两个人来搞的，所以说你们都不知道，这是黑历史。后来我就不说了，确实还挺斗争的。
但是当时是先写出来，勉强能跑再说，quick and dirty。所以这里面又有一个 takeaway，有一些路看起来是捷径，但其实你回头看都是弯路。如果有一件事情，听起来就觉得好像挺难的，但是最终的收益可能会更大，你一定去选择那条看起来更难的那条路。千万不要选择一条一眼看过去就挺简单、能出活的路，这一定要小心。因为你的大脑会倾向于选择短期能获得 reward 的路径，忽略掉长期的收益。长期的事情在短期可能会更痛苦，所以很多时候你的情绪或决定是下意识地写在你基因里面的。
像刚才 HBase，我可能写三个月就能看到一个成果，但是用 Rust 从零开始写，可能要写更长时间、更不确定或者更难。但当时我就是因为觉得，这个东西好像马上就能看到效果，要不就做了吧。其实就是不要偷懒。
从零道一：保罗·格雷厄姆（《黑客与画家》的作者）提到他们在很早的时候用 Lisp 写东西。其实在选择一个非常难的东西的时候，可能也在创造一个技术壁垒，如果大家都很容易去做的事情，谁都可以去立马抄出来。
Ed: 其实这个跟语言没有太大关系了，而是选择一个长期更难且正确的事。这听起来是鸡汤，但是确实我们实际上的体感告诉我们，有些事情它虽然是看上去短期完全没好处，但是你长期一旦坚持下去，它带来的好处真的很多，就像社区这种事情是吧。
从零道一：接下来是有趣的快问快答环节，你可以用第一反应去回答。网上说你是科技圈内的著名艺术青年，有好几个标签，黑客、CTO、摇滚乐手、开源爱好者。在这几个角色中，你会最享受哪一个？
Ed: 程序员。我还是比较喜欢写程序，本质上我可能还是比较享受造物过程的一个人。
而且我虽然比较喜欢艺术，但是艺术这一部分跟 engineer 也一直不太冲突。我比较喜欢的包括音乐、画画，其实更多是让自己开心。但是我对这世界表达的方式可能更习惯于写程序这件事情。
从零道一：如果可以和《黑客与画家》的作者保罗·格雷厄姆吃一顿饭的话，你会想要和他聊些什么？
Ed: 我们对很多事情的世界观是比较接近的。
一是找认同，我觉得可能会挺有趣的。第二我可能会跟他聊一些好玩的东西。
我不会去聊什么，我们一起做一些早期投资、你有没有投我什么的，这都很无聊。本来我刚开始在想问他，未来会看什么样的技术的方向什么的，但我觉得这个问题太 boring 了。
从零道一：《黑客与画家》里面有一个章节叫做 100 年后的编程语言，你觉得 100 年后的数据库可能会长成什么样子？
Ed: 我觉得 100 年后可能都不一定有数据库这种东西存在了，或者说 100 年后数据的访问、或者数据的获取，都不是以现在我们能想象到的形式出现了。搞不好脑机接口就出现了，是吧？计算机可能都不存在了，可能都植入到大脑里面了。
100 年是很长的跨度。比如说我们现在想 100 年前，谁都不知道什么叫计算机，是吧？所以我觉得 100 年后数据库就不存在了，这是我的判断。计算机可能也不存在了。
从零道一：最喜欢的家乡食物是什么？
Ed: 我是广西人，特别喜欢老友粉，是一种米粉。但我不喜欢桂林米粉。
从零道一：如果突然有了三个月的时间可以随意支配，会想要做点什么事情？
Ed: 我可能会写一个小型的操作系统。这个是我一直的一个想法。如果有一个长的假期，可能自己会做这么一个东西来玩。
从零道一: 最近有没有买到一些什么特别心仪的东西？
Ed：我的钱可能主要都花在买效果器，或者说一些单块，这些其他用的东西上。确实有，但是过于小众了。我买到一块我很喜欢的吉他效果器，在闲鱼上。关注了很久，终于有人开始卖了。
从零道一：最近有没有收到过令你比较印象深刻的一些建议？
Ed: 其实刚才提到了一条，就是听好话不太重要，听坏话更可能会对你的认知更有收获，我觉得这是一个很好的建议。
从零道一：给刚入职场的程序开发领域的年轻人有什么样的建议？无论是做上层还是下层这一块的。
Ed: 我觉得无论如何都要去找到你这个行业，或者说你的一些不变的东西。刚才其实我在介绍我的经历里边的时候也是一样，我觉得这是一个不错的方法。
不要被一些新的技术给迷惑了，而是说不断地问自己，什么东西是 10 年后、5 年后都不变的。
从零道一：关于书籍你会有什么样的推荐？
Ed: 如果推荐特别好玩的书，我推荐两种类型的。
一种类型的是正经的，比如说商业什么的。我最近其实读了几本书觉得还挺不错的，一个是 No Rules Rules《不拘一格》，讲 Netflix 的企业文化那本，我觉得还挺棒。
还有一本是红帽的，叫the open organization: igniting passion and performance，是讲开源的 culture、红帽的历史和企业文化之类的一本书，也很棒。
另外一本是《客户说》，拉姆·查兰写的。如果你是一个公司的销售负责人，或者如果你是在搭商业团队的话，这本书其实是有很多可操作性的东西。这三本是我最近读的书。
但其实我平时读的更多的是一些跟商业没有太大关系的书。比如说像最近我读了一本特别好的书，叫《宇宙的最后三分钟》。我特别喜欢读这种很奇怪的科普。他讲宇宙的结局是大概什么样子的，比如说如果太阳毁灭了，银河系就会毁灭，所有信息都毁灭了，到最后一周、最后三分钟，大概会发生什么事情，是一本科普的书。
最近我还在读一本，觉得也挺不错的，是《禅宗与精神分析》。讲一些禅宗的东西，有一点点宗教，用心理学或者说科学的方式来去解释禅宗的一些东西，挺好玩的一本书。
我不知道大家喜不喜欢看科幻小说，其实小说我基本只看科幻，推荐两本。一本叫《群星》，这本我就不剧透了，还挺好看的。还有一本是我最近正在看叫《月球城市》。这是那部特别有名的电影《火星救援》的剧本作者最近写的另外一本书。也是那种很好玩、工程师特别喜欢的，话唠同时又很硬的科技的风格的的小说，很棒。
从零道一：最近在生活上或者是工作上遇到的最暖心的事情是什么？
Ed: 其实我经常遇到很多非常暖心的事情。比如说最近 TiDB 的 Hackathon，我看到了很多小伙伴或者素不相识的一些人，因为这个活动一起很开心地去玩，我也觉得很暖。大家这种很纯粹的热情，让我很感动。
从零道一：感谢 Ed 给我们带来的非常精彩的分享，也祝 PingCAP 在新的一年里越来越好，也非常期待你们会给技术圈内带来的更多更强更快的服务。
Ed: 谢谢！
- 往期精选 -
- 《从零道一》听众群 -
欢迎加入从零道一听众群，与嘉宾、主持人和其他听友交流互动。入群步骤：
1. 添加从零道一小助手微信（id: goto_helper)，并备注“听众群”