2020-47 周报:人会被忘记,除非因为作品被记住

By: Jeff Hu
Posted: November 20, 2020

序言

嘛,了解我的人应该都知道,我有写日记的习惯。大概从高二开始,陆陆续续记下了很多文字,自己也愈发享受那种沉溺在文字中与自己对话的快感。

此外,我是个内心活动很丰富的人,简单地说就是想法很多。如果不记下来,倏地一下让那些有趣的想法溜过去,回想起来就会觉得很可惜。于是杂七杂八的随想也写了不少。

回顾自己写过的内容,其实不太成体系。大概是因为受众只有我自己一个人,所以写得比较草率。但我觉得很多想法和观点其实是有整理一番拿出来和朋友们讨论的价值的。再者,把这些内容梳理出来展现给更多的人看,是一种更深层次的自省——写作的时候可以把自己想象成第三人称的读者,超离感来得更强烈些,可以促成更有深度的内容。

相比于自己写的东西,其实我读的内容更多、更杂一些。世界上本没有多少原创的观点,大都是受输入的内容潜移默化产生的「我想到了 xxx,我也太天才了」的幻觉。因此,你的想法能有多深刻、多宏伟,全仰赖你读过哪些东西。当然,积极的思考也是必不可少的,但拒绝输入而只是闭门冥思,则终究走不了太远。为此,我最近特别地在观察自己接受的输入。坦白地说,我大概有 30% 的输入是有价值的,而其他 70% 则落到了低效、泛泛而览或是纯粹的时间浪费之中。

我希望能尽可能地放大有价值的输入,同时规避无效的输入——后者不仅浪费时间还消耗精力,不如把这个时间节约给睡觉。

那我想到的解决这个问题的好办法,也是同样把自己接受到的有价值的内容分享出来,最好附带上自己的看法或者评论。

因此,呈现在大家面前的就是一份这样的汇报。我会尽可能忠实的把我一周记录下来的内容整理成一篇比较有可读性的文章,虽然会有不可避免的碎片性,但我会尽可能提高这样的汇报给各位读者带来的价值。此外,非常希望正在阅读此文的你能给我一些反馈或者和我讨论某些观点,这会极大地鼓励我坚持分享下去。

Quote of the Week

人会被忘记,除非因为作品被记住。 —虎

我是一个程序员,这是毋庸置疑的。

程序员并不等价于 coffee in, code out(喝进咖啡,产出代码)的机器人。好的代码是会因为带上了程序员的思考而闪光的。而这种付出了严肃的思考而产出的精妙代码,也会带上感情色彩。

如果不是程序员的你可能难以想象,解读一份前人留下的精妙代码,和作者产生超越时空的思想共鸣的那种「打了一个激灵」般的 thrill(激动)。

不过,能产生这种美妙的感觉得有一个前提——这份代码得是开源的。

程序员的作品是程序,这个有点近乎于冷笑话的陈述其实说明了一个比较悲哀的事情。对于很多程序驱动的改变世界的人类创作来说,其背后付出最多汗水的程序员很难拿到应有的归功。如果这个创作还是闭源的,那程序员得见天日的可能就更小了。

因此,那些鼎鼎大名的程序员,绝大多数都是写开源代码的。

人会被忘记,除非因为作品被记住。

也谈内卷。

我常说的一句话是「人生有两大陷阱,一个是和别人作比较,另一个是想证明自己。」

这句话不是我原创的,而是一个住在北京地下室的一个打工人。他听说做平面设计很赚钱,于是乎花了 9100 块钱报名去学 Photoshop,最后还是没能找到平面设计的工作。重新做回锅炉工后,他认真地给自己写了一封信,标题叫《人生两大陷阱》。

An image from Notion

知道这句话是因为我半年前听的一个一席演讲。是一个设计师讲他改造北京给外来务工人员居住的地下室环境的故事。过去半年了,我对这个一席演讲最有印象的就是这一句话——我全然记不得这个演讲者的名字和这个演讲的标题,但凭借「北京」、「地下室改造」、「设计师」这几个关键字的组合,我成功找到了他的名字,随后是这个演讲。

人会被忘记,除非因为作品被记住。

回到内卷。

这句话之所以给我留下很深的印象,是因为这位在我们看来身处底层的朋友,竟然能说出如此具有借鉴意义的话。当时,也就是今年四月,处在最后的延毕决定边缘徘徊的我,在看到这句话之后,顿时释然了。我那时想读 PhD 的动机很不纯粹,一方面是和别人作比较,另一方面就是想证明自己。

因此当我茫然中看到这个一席演讲、从这位朋友写给自己的信中听到人生这两大陷阱的教训时,说如雷贯耳、振聋发聩都不及我当时感觉之万一——我遂果断放弃了胡思乱想,选择了到现在看来毫无后悔的正确决定。

到今天,这两大陷阱仍然对我适用,并有了外延的含义。

我在日记中写下

想到内卷的一个逃离途径,一个是从纯粹的追求技术走向带有人文关怀的事业,这些东西是没有硬性指标来造成攀比的,可以从外部促成「不和别人作比较」的条件,从而逃出人生陷阱之一;第二个是日拱一卒,坚持做事情、产生进度,逃出只想证明自己而没有行动的陷阱。问题就完满解决了。

算是给这两个陷阱提供了解决方案。

这周做的事情。

「硬核警告,非同行可以跳过这段,此外术语很多难以翻译,按我的使用习惯保留了英文。」

因为在公司的 OKR 是让产品更稳定,为此这个月的工作重点都是在修 bug 上。这周大部分时间也是在复现 bug、修 bug、review 代码中渡过的。

此外还看了不少 TiFlash 的资料,了解了其作为 Raft Learner 是如何异步复制 Raft Log 并在查询的时候通过复制进度校验和等待实现一致性读的——读马老师(我司 RA Team 负责人)写的文章真是如坐春风。

TiDB HTAP 深度解读
这个文章之前由于内部流程原因暂时先撤下了,现在正好是其中所讨论的论文正式发布的时候,所以这里也就把文章重新发布下,看过的同学可以不用再看了,不过帮忙重新点个赞是欢迎的 :) 另外这次 VLDB Google 发了 F1 Lightning 的论文,也是 HTAP 主题,还提到了 TiFlash,不过分析的有些错误,到时候也许也会写一篇新的论文分享来说 F1。 好了,如下是原先的正文。 这个专栏之前一直都没有正经写过任何读论文分享,如果有空的话(立 flag)我们也会找时间多发一些论文分享。这次就算开个头,比较特殊的是,这篇 VLDB 论文是 PingCAP 写的,关于 TiDB HTAP 架构。所以这篇解读,是以作者团队(中的一部分)的视角来写的。 原文在此 ,欢迎指正。 考虑到再往后内容有点偏技术,可能会让不少读者被劝退。趁大家还在看,这里赶紧说下 VLDB 是数据库领域最好的两个顶级学术会议之一,论文被接受至少证明我们的 HTAP 架构并不是商业话术,或者某种自 High 的说辞,而是真实有料的。作为草根起家且汲取他人论文养分成长的公司,这次算是换我们有所回馈吧。 另外再打个广告,TiDB 4.0 引入的列存引擎 TiFlash 正是整个 TiDB HTAP 架构的关键模块,如果仍未了解个中奥妙,无需读完全文,欢迎现在就与我们联系体验 :) 至此,本文的宣传作用已经达到,剩下就是技术本身了。 论文整体介绍了一下 TiDB 的架构和设计,对 TiDB 有兴趣的同学推荐完整看下,会对理解架构有很大帮助。不过既然重点是 HTAP,那么在我看来比较重要的地方是这三点: 后面我也会着重说一下这三部分。 之前看到过阿里的李教授在访谈中关注过我们的列存更新设计,那么这里就斗胆先说下大佬关心的话题

随后因为需要在周会上汇报 RA 组的工作进展,因此看了 TiFlash on Cloud 的设计稿,主要关注的是 storage 层的改造,因此还了解了 TiFlash 的存储结构——即首先切分 Segment,再在 Segment 上维护类似 LSM Tree 的只追加的 Delta Layer 和定时 Compaction 写盘的 Stable Layer,因为 Segment 和整个 Range 空间比起来小得多,因此相比 LSM Tree 可以只维护两层,减少了读时的归并次数,因此读取性能更好一些。这方面的学习还是一个 on going 的过程。下面这篇文章我还只看了一半。

另外一个就是在关注基于 Apache-Arrow 项目衍生出来的各种 SQL-Engine,感觉这里面应该有东西可以搞,刚好公司里也有同事注意到了这个事情,我接下来会认真地调研一下。

业余时间我在做 6.824 的 Raft Lab,这周在写 Lab2B。其实我去年 7 月左右就开始动手写了,不过当时写完 Lab1 和 Lab2A 就摸了。现在算是重拾起来,会更认真地把它做完的!这次我很有信心,原因有二

  1. 我对 Go 了解得更深了、用得更熟练了
  2. 我组织了一批高年级的复旦计算机同学一起在学,每周日早上都会固定时间 meeting 一次进行讨论

如果你对此也感兴趣,可以找我拉你到学习组织里来~(目前限制只开放给复旦的同学)。回头我有空的话可能会整理下会议记录开放出来。

接下来要做的事情。

这个周末会去 Gopher China(欢迎会场戳我)、参加一个骑行活动、一个饭局、准备一次小会议。

下周工作继续推进 bug fix,如果对参加 TiDB 开发有兴趣,欢迎成为我们的社区贡献者~我整理了一个 bug list,可以去找数字后带!的 issue 修修玩。有问题的话可以在社区 slack 里 @Zhfeng Hu 问~

此外预告一篇技术文章,标题都想好了,《数据库优化器原理,看这一篇就够了》。

老营销号了(逃