你不是Google,一语点醒技术人

标签: google 技术 | 发表时间:2017-06-20 03:18 | 作者:
出处:http://mp.weixin.qq.com
策划|Ozan Onay
编辑|薛命灯

软件工程师总是着迷于荒唐古怪的事。我们看起来似乎很理性,但在面对技术选型时,总是陷入抓狂——从 Hacker News 到各种博客,像一只飞蛾一样,来回折腾,最后精疲力尽,无助地飞向一团亮光,跪倒在它的前面——那就是我们一直在寻找的东西。

真正理性的人不是这样做决定的。不过工程师一贯如此,比如决定是否使用 MapReduce。

Joe Hellerstein 在他的大学数据库教程视频中说道:

世界上只有差不多 5 个公司需要运行这么大规模的作业。至于其他公司……他们使用了所有的 IO 来实现不必要的容错。在 2000 年代,人们狂热地追随着 Google:“我们要做 Google 做过的每一件事,因为我们也运行着世界上最大的互联网数据服务。”

超出实际需求的容错没有什么问题,但我们却为此付出了的惨重的代价:不仅增加了 IO,还有可能让原先成熟的系统——包含了事务、索引和查询优化器——变得破碎不堪。这是一个多么严重的历史倒退!有多少个 Hadoop 用户是有意识地做出这种决定的?有多少人知道他们的决定到底是不是一个明智之举?

MapReduce 已经成为一个众矢之的,那些盲目崇拜者也意识到事情不对劲。但这种情况却普遍存在:虽然你使用了大公司的技术,但你的情况却与他们大不一样,而且你的决定并没有经过深思熟虑,你只是习以为常地认为,模仿巨头公司就一定也能给你带来同样的财富。

是的,这又是一篇劝大家“不要盲目崇拜”的文章。不过这次我列出了一长串有用的清单,或许能够帮助你们做出更好的决定。

很酷的技术?UNPHAT

如果你还在使用 Google 搜索新技术来重建你的软件架构,那么我建议你不要再这么做了。相反,你可以考虑应用 UNPHAT 原则。

  1. 在彻底了解(Understand)你的问题之前,不要急着去寻找解决方案。你的目标应该是在问题领域内“解决”问题,而不是在方案领域内解决问题。

  2. 列出(eNumerate)多种方案,不要只把眼睛盯在你最喜欢的方案上。

  3. 选择一个候选方案,并阅读相关论文(Paper)。

  4. 了解候选方案的产生背景(Historical context)。

  5. 比较优点(Advantages)和缺点,扬长避短。

  6. 思考(Think)!冷静地思考候选方案是否适合用于解决你的问题。要出现怎样异常的情况才会让你改变注意?例如,数据要少到什么程度才会让你打消使用 Hadoop 的念头?

你不是 Amazon

UNPHAT 原则十分直截了当。最近我与一个公司有过一次对话,这个公司打算在一个读密集的系统里使用 Cassandra,他们的数据是在夜间加载到系统里的。

他们阅读了 Dynamo 的相关论文,并且知道 Cassandra 是最接近 Dynamo 的一个产品。我们知道,这些分布式数据库优先保证写可用性(Amazon 是不会让“添加到购物车”这种操作出现失败的)。为了达到这个目的,他们在一致性以及几乎所有在传统 RDBMS 中出现过的特性上做出了妥协。但这家公司其实没有必要优先考虑写可用性,因为他们每天只有一次写入操作,只是数据量比较大。

他们之所以考虑使用 Cassandra,是因为 PostgreSQL 查询需要耗费几分钟的时间。他们认为是硬件的问题,经过排查,我们发现数据表里有 5000 万条数据,每条数据最多 80 个字节。如果从 SSD 上整块地读取所有数据大概需要 5 秒钟,这个不算快,但比起实际的查询,它要快上两个数量级。

我真的很想多问他们几个问题(了解问题!),在问题变得愈加严重时,我为他们准备了 5 个方案(列出多个候选方案!),不过很显然,Cassandra 对于他们来说完全是一个错误的方案。他们只需要耐心地做一些调优,比如对部分数据重新建模,或许可以考虑使用(当然也有可能没有)其他技术……但一定不是这种写高可用的键值存储系统,Amazon 当初创建 Cassandra 是用来解决他们的购物车问题的!

你不是 LinkedIn

我发现一个学生创办的小公司居然在他们的系统里使用 Kafka,这让我感到很惊讶。因为据我所知,他们每天只有很少的事务需要处理——最好的情况下,一天最多只有几百个。这样的吞吐量几乎可以直接记在记事本上。

Kafka 被设计用于处理 LinkedIn 内部的吞吐量,那可是一个天文数字。即使是在几年前,这个数字已经达到了每天数万亿,在高峰时段每秒钟需要处理 1000 万个消息。不过 Kafka 也可以用于处理低吞吐量的负载,或许再低 10 个数量级?

或许工程师们在做决定时确实是基于他们的预期需求,并且也很了解 Kafka 的适用场景。但我猜测他们是抵挡不住社区对 Kafka 的追捧,并没有仔细想过 Kafka 是否适合他们。要知道,那可是 10 个数量级的差距!

再一次,你不是 Amazon

比 Amazon 的分布式数据库更为著名的是它的可伸缩架构模式,也就是面向服务架构。Werner Vogels 在 2006 年的一次访谈中指出,Amazon 在 2001 年时就意识到他们的前端需要横向伸缩,而面向服务架构有助于他们实现前端伸缩。工程师们面面相觑,最后只有少数几个工程师着手去做这件事情,而几乎没有人愿意将他们的静态网页拆分成小型的服务。

不过 Amazon 还是决定向 SOA 转型,他们当时有 7800 个员工和 30 亿美元的销售规模。

当然,并不是说你也要等到有 7800 个员工的时候才能转向 SOA……只是你要多想想,它真的能解决你的问题吗?你的问题的根源是什么?可以通过其他的方式解决它们吗?

如果你告诉我说,你那 50 个人的公司打算转向 SOA,那么我不禁感到疑惑:为什么很多大型的公司仍然在乐此不彼地使用具有模块化的大型单体应用?

甚至 Google 也不是 Google

使用 Hadoop 和 Spark 这样的大规模数据流引擎会非常有趣,但在很多情况下,传统的 DBMS 更适合当前的负载,有时候数据量小到可以直接放进内存。你是否愿意花 10,000 美金去购买 1TB 的内存?如果你有十亿个用户,每个用户仅能使用 1KB 的内存,所以你的投入远远不够。

或许你的负载大到需要把数据写回磁盘。那么你需要多少磁盘?你到底有多少数据量?Google 之所以要创建 GFS 和 MapReduce,是要解决整个 Web 的计算问题,比如重建整个 Web 的搜索索引。

或许你已经阅读过 GFS 和 MapReduce 的论文,Google 的部分问题在于吞吐量,而不是容量,他们之所以需要分布式的存储,是因为从磁盘读取字节流要花费太多的时间。那么你在 2017 年需要使用多少设备吞吐量?你一定不需要像 Google 那么大的吞吐量,所以你可能会考虑使用更好的设备。如果都用上 SSD 会给你增加多少成本?

或许你还想要伸缩性。但你有仔细算过吗,你的数据增长速度会快过 SSD 降价的速度吗?在你的数据撑爆所有的机器之前,你的业务会有多少增长?截止 2016 年,Stack Exchange 每天要处理 2 亿个请求,但是他们只用了 4 个 SQL Server,一个用于 Stack Overflow,一个用于其他用途,另外两个作为备份复本。

或许你在应用 UNPHAT 原则之后,仍然决定要使用 Hadoop 或 Spark。或许你的决定是对的,但关键的是你要用对工具。Google 非常明白这个道理,当他们意识到 MapReduce 不再适合用于构建索引之后,他们就不再使用它。

先了解你的问题

我所说的也不是什么新观点,不过或许 UNPHAT 对于你们来说已经足够了。如果你觉得还不够,可以听听 Rich Hickey 的演讲“吊床驱动开发(Hammock Driven Development)”,或者看看 Polya 的书《How to Solve It》, 或者学习一下 Hamming 的课程“The Art of Doing Science and Engineering”。我恳请你们一定要多思考!在尝试解决问题之前先对它们有充分的了解。最后送上 Polya 的一个金句名言:

回答一个你不了解的问题是愚蠢的,到达一个你不期望的终点是悲哀的。

今日荐文

点击下方图片即可阅读

StackOverflow 创始人关于如何高效编程的清单


如果你想知道未来的架构如何发展,推荐一场汇聚国内外顶尖架构师的线下会议:ArchSummit 全球架构师峰会,从大数据框架到移动轻应用 ,从低延迟架构设计到人工智能落地,这里只谈最优秀的架构实践。大会将于 7 月 7 日深圳开幕,目前 9 折最后一周,点击“阅读原文”,看看对你有何启发?

相关 [google 技术] 推荐:

[技术贴]不用翻墙上Google+,Youtube

- Ken - 草榴社區
修改C:\Windows\System32\drivers\etc下的hosts文件,用记事本打开. 将下面的字段添加进去,保存即可(注:每行一条,前面不要有空格)也可以直接下载我的hosts文件  覆盖即可  http://filemarkets.com/file/cjwdluo/27a50499/.

免费的晚餐--Google技术学习

- - 企业架构 - ITeye博客
作者: 江南白衣,原文出处:  http://blog.csdn.net/calvinxiu/archive/2007/01/31/1498597.aspx. 如果说Google的搜索引擎是免费的早餐,Gmail们是免费的午餐的话,.      http://labs.google.com/papers/ 就是Google给开发人员们的一份免费的晚餐.

Google Images才是Google最有价值的技术

- - 比特客栈的文艺复兴
社交网络这种低效率的内容整合见鬼去吧. Google Images是怎样把一张图转化为搜索关键词与搜索结果的. 用户只要输入一张图,而且根本不需要是完整的图片(例如QQ群里右键的截图). 图像处理算法找到对应完整的图片记录(图片结果). 找到引用图片的网站,抽取常见关键字(网页结果). 关键字联想,寻找最匹配的网页(维基,提供关键词解释,等于图片注释).

探索Google App Engine背后的奥秘(1)--Google的核心技术

- Hui Hui - DBA Notes
作者:ikewu 发布在 dbanotes.net. 投稿人吴朱华曾在IBM中国研究院从事与云计算相关的研究,现在则致力于云计算技术. 本系列文章基于公开资料对Google App Engine的实现机制这个话题进行深度探讨. 在切入Google App Engine之前,首先会对Google的核心技术和其整体架构进行分析,以帮助大家之后更好地理解Google App Engine的实现.

Google 向新版 Linux 内核贡献技术

- flypen - 谷奥——探寻谷歌的奥秘
本月初刚刚发布的 Linux 2.6.35 版内核中,包含了 RPS 和 RFS 这两项由 Google 贡献的新技术. RPS 的全称是 Receive Packet Steering,这项技术将流入的数据包分布给所有可用的 CPU 去处理,而 RFS (Recevie Flow Steering) 则负责计算哪个核心最适合处理哪项工作.

Google+用户群生相:大多为男性 木讷懂技术

- 宏劼 - cnBeta.COM
社交网站数据统计公司称,Google+用户大多数为男性,其比例或高达86.8%. 这些人生性木讷,但是对于技术有很深刻的理解. 从社交网站选定个人资料页面中收集数据的第三方网站SocialStatistics称,谷歌社交网站Google+的男性用户比例高达86.8%. 而专 门追踪调查Google+用户信息的网站findpeopleonplus称,Google+上的男性用户占到了全部用户的73.7%.

逃离 Google——不再酷的公司,落后的技术!?

- Ray - 爱范儿 · Beats of Bits
之前我们报道过 Google Wave 的开发者 Lars Rasmussen 跳槽到 Facebook 的一些感受. 最近,另一位 Google Wave 的成员 Dhanji Prasanna 也在拿到了 2010 年的年度奖金后离开了 Google,他在博客中撰文称,有 8 个 Google Wave 项目组的同事在过去两个月相继离开了 Google.

桌面版 Google Maps 开始测试用 WebGL 替换 flash 技术

- 可可 - 谷奥——探寻谷歌的奥秘
如果你喜欢Google Maps for Android那远比桌面版流畅的界面,那么现在是时候尝试新事务了. 如果你使用Chrome 14+或Firefox 8+浏览器,且显卡支持WebGL标准,那么现在打开Google Maps即可在左侧看到一个提示:“Want to try something new?”,点击之后Google Maps就不会再使用flash技术来显示街景了,而换用WebGL(Google称其为MapGL),且可显示出跟Android手机上一样的3D地图界面.

传Google已提出收购Yahoo广告技术业务方案

- - 36氪
据科技博客 BusinessInsider报道,消息人士透露Google已于3月前向Yahoo提出收购其广告技术业务的方案. 该方案在Scott Thompson还在担任Yahoo CEO时就已提出,但是当时没有获得通过,不过该谈判至今仍在进行. 之前有消息称, Accenture和IBM都对Yahoo的广告技术和客户感兴趣.