Google七年工作总结

学习



Google可能给自己带来的最大收益就是学习。 Google有很多东西是真的only google can do的，包括但不限于

• F1，和F1 UDF/TVF对我思考SQL的重塑，包括分离query engine和data store，还有cross datastore query
• Spanner至今为止似乎仍然是唯一一个auto partition+global distribution+serializability的db
• Spanner Queue几乎是我用过最方便的Queue System之一，尤其是方便的exactly once semantic
• Capacitor文件的设计思路，和Capacitor是如何提升query speed，甚至是Capacitor的下一代设计
• RPC相较于http api的诸多方便
• boq/pod的方便，对async的严格管理

从另一个角度看，google也是最方便你学习的地方，几乎所有代码，所有doc，都是对所有FTE开放的，有很多很多值得读的内部文档，我就不在这一一列举了。但是我非常庆幸这是我的第一份工作，而且我呆了整整七年时间，最遗憾的就是没有多学一点，一方面是工作强度有时候不低，自己忙于手上的事儿，第二是自己还是不够努力。

办公室环境



Google总体上来说没有那么拼搏，相比于我现在的组，我觉得人均产出大概是1：3，现在的组人均产出是以前google组的三倍。我并不认为这是一种优点或者缺点，我认为一个公司大到一定程度，所有人都卷只会造成一个结果，就是人员流动性难免会逐渐变大，这其实不利于持久的创新，大家往往因此而不能长远的看问题，觉得自己干两三年就走了，自然也就不容易对质量很上心，我认为我当下的组就有这种问题，因为要move fast，就会因此犯更多的错误。总结起来应该还是：

• 我要明白当前组的最重要目标是什么 => 我的工作对这个目标有什么作用
• 工作不是一成不变的，目标也是一直变化的  => 有些工作需要大干快上，有些工作则需要精雕细琢

我在工作中经常看到做事情的方式和目标不太匹配，比如over-design，又比如too simple design。这些往往是因为不了解真正的目标而做的项目。举例来说，我曾经用了三年时间把我组里的一个data pipeline变成streaming system, 原始的目的是降低延迟，可是在做的过程中，就很容易把事情做成了为了streaming而streaming，而忘记了当初的目标。 三年的第一个月我就有了design doc，现在看来是很可笑的，其实可能用半年的时间尝试几种prototype，一年半左右就能做出一个接近最优解的方案了，但是先入为主的相信了streaming，这是从一开始就误解了目标。


我认为我在原来的组里是top 1% productivity， 现在大概是top 10%，我觉得非常明显的是，虽然我以前是top 1%，但是很多看似懒惰的人却经常可以清晰的指出我工作的错误，然后达到事半功倍的效果，现在的组，大家更容易轻易相信自己说的，或者是团队说的，忘记了事实验证，从而会犯更多错误，所以实际的产出可能没有1：3那么大的差距，可能只有1：1.5，多出来的这0.5甚至都不是因为大家更努力了，只是因为公司小的时候，扯皮的时间稍微少一些，然后绝对的coaster少一些（小公司layoff的反应速度快很多）

做项目的经验



做了不少项目，累积了一些正面或者负面的经验，大体上总结如下：

• 多prototype，我之前的组的缺点之一就是design doc太精美，但是精美的design doc背后没有大量的试验数据支撑。我认为一个项目，尤其是偏infra的项目，需要大量的prototype来支撑，design doc应该更像paper而不是prd，也许团队可以做1~2页的idea doc，但是20页的design doc背后没有任何prototype试验是非常危险的
• 用更高一层的角度来思考自己的项目：这和上一个部分讨论的类似，每个人的项目要和整个团队甚至整个公司的目标结合在一起看才行，如果没有这样的视野，很容易忘记真正的目标：比如一个pipeline分成三部分A->B->C，我的项目是提高B的速度，但是也许提高A/C的速度就能让客户满意了，那么就没必要死磕B。了解全方面的需求才能让自己的scope更上一层楼
• Team Building: 我在这方面非常差，我觉得我的team member都很愿意和我合作，但是我的大领导往往容易怀疑我，在这方面的我可能就是大家说的老中不擅长manage up吧。我在政治斗争方面一直都挺失败的，虽然获得了想要的scope，但是没能获得想要的promotion或者是package

Manager or not



基于我非常不擅长政治斗争的原因，我觉得我当不了manager，虽然尝试过但是最终放弃了，我觉得我也许可以在一个<100人的startup成为全公司的TL，但是却很难在google当好一个L6，主要还是实在受不了政治斗争过程中过度的，不以做好项目为目的的利益交换。这样的官僚主义习气在我原来的组是很浓厚的，因为从Sundar到我中间隔了六七层，这些人难免考虑的是自己的利益，而自己的利益往往又不完全是和项目的好坏绑定的，最有趣的现象就是，往往哪个组干的烂，他们就能提出一个更宏伟的方案来改进他们的系统，而宏伟的方案的核心目的是招更多的人。


还有很多很多我想说的，但是其他信息大多数都过于敏感，或者涉及到太具体的例子，就不一一举出了。但是是否适合做manager，从功利的角度讲，就是自己是否适合做manager，有没有那样的政治斗争的天赋。

Tfiygoi 发表于 2024-9-22 14:59
lz大神，我在某个summit远处见过你！想请教一下你说的Spanner Queue exactly once更好的semantic指的是什 ...

不是什么spanner独有的东西。

如果我们把queue想象成database table row，scanner负责从row里读出push message，然后push（这个过程肯定涉及到你说的lease）。

方便的exactly once是指：对于receiver来说，ack的过程就是一个delete row transaction，在这个txn里可以方便的做需要exactly once的操作（想象一下我的message是扣款10元，那么如果message和余额都在spanner里，就可以方便的扣款），再比如我还可以在transaction里给下一个queue发message，都可以轻松保证exactly once。

当用strong consistency db来存message，这个方便就是自然而然的。但是在spanner以前是很少有serializability+global distribution+local paxos reliability的db的。

补充内容 (2024-09-23 07:38 +08:00):

• 不是大神
• 我咋不记得我参加过啥summit？除非是我自己组的很小的summit
• 就我观察到的很多利用其它queue system（比如kafka，pubsub，sqs），都是通过external strong consistency db实现的exactly once

我相信lz能力是很强的。但在公司做事不是高考，不懂政治是做不到1% productivity的，10%都非常难。

MetaMLE 发表于 2024-9-22 17:26
从Google开始career应该是正确的
还有tensorflow TPU这些

大部分人都是产品组的，学会了业务逻辑不就是proto搬运工，大部分人都废了

或者说压根没好过

以及industry里面目前需要的都是拧螺丝的

楼主是大神，在哪里都会很厉害

. Waral dи,openai 大神，我们普通人就想写写业务逻辑 混个饭吃哈哈哈哈

"RPC相较于http api的诸多方便"

难道不是场景不同，有时候用grpc，有时候用rest / http 什么的？

lz是gcp做infra的，研究的比较底层的存储 和 query。

谢谢分享，
不过很多东西说的太绝对了，
还比如说小强db，tidb都是strong consistency in theory

匿名用户 发表于 2024-09-22 12:55:46
谢谢分享，
不过很多东西说的太绝对了，
还比如说小强db，tidb都是strong consistency in theory

spanner真正challenge了CAP，tidb和小强还在用raft🤡

lz有xhs吗？

exactly once semantic在aws sqs里也早就有了

太强了👍 感觉俺在亚麻啥也没有学到

delta42 发表于 2024-9-22 11:49
我相信lz能力是很强的。但在公司做事不是高考，不懂政治是做不到1% productivity的，10%都非常难。

确实如此，可能我的政治斗争水平就是在慢慢进步吧，天赋有限但是仍然在努力学习中。