你不是 Google，不要试图模仿它

编者按：没错，Google用了一些很酷的技术，你想用吗？当然。不过，在布拉德菲尔德学院教计算机科学的 Ozan Onay 建议你先坐下来想一想，搞清自己的问题是什么，看看是否有必要使用新奇的技术。

软件工程师因为一些可笑的事物而疯狂。我们会认为自己是超级合理的，但是当我们选择一门技术时，最终却陷入了迷乱：从一个人在Hacker News留下的评论到另一个人的博客文章，我们神智混乱，茫然无助朝着最明亮的亮光前进，匍匐在光明之前，忘了我们最初追求的是什么。

我们所说的并不是理智之人如何做决策，而是说软件工程师为何决定使用 MapReduce。

Joe Hellerstein给学生上数据库课程时说过：

“在世界上，可能只有5家公司有如此多的员工。对于其它人来说……你从事相关的I/O工作，对容错性提出很高要求，这种要求是没有必要的。2000年代，人们因Google而狂热：‘我们做一切事都要按Google的方式进行，因为我们也运营着世界上最大的互联网数据服务。”

在容错率上提出更高要求，超过你的需要，听起来不错，不过要考虑一下成本：你不只要做更多的I/O工作，还要从成熟的系统（包括交易、索引、查询优化器）转向相对破旧的系统。简直就是重大的倒退。有多少Hadoop用户无意中妥协？又有多少用户的妥协是明智的？

就目前而言，MapReduce/Hadoop只是一个软目标，甚至连“货物崇拜者”（当货物崇拜者看见外来的先进科技物品，便会将之当作神祇般崇拜。）也知道飞机偏离了航线。从更广泛的层面上我们也可以看到同样的现象：如果你使用一门技术，这门技术原本是针对大企业的，你的使用情况大不相同，可能无法得到预料的结果；不能，模仿巨头就能获得同样的财富，这只是仪式般的信念，无法变成现实。

我有一张实用的清单供你检查，你可以用它来制定更好的决策。

很酷的技术？UNPHAT 

下一次，如果你发现自己模仿Google，想将一些很酷的新技术拿来用，我希望你停下来，用UNPHAT标准检查一下：

1、在真正理解（Understant）问题之前，不要考虑新的解决方案。你的目标应该是在问题的范围之内“解决”大部分问题，而不是在解决方案内解决。

2、枚举（eNumerate）多个候选解决方案，不要选那些你喜欢的。

3、考虑候选解决方案，如果有论文（Paper）拿来读一读。

4、候选解决方案是如何设计的？如何开发出来的？搞清它的历史环境（Historical Context）。

5、搞清优点（Advantages）和缺点。为了将优先的事情做好，搞清哪些事情是非优先的。

6、思考（Think)！冷静一点，谦虚一点，多想想这个方案能从多大程度上解决你的问题。如果要让你改变想法，事实必须有多大的变化？例如，如果让你不选择Hadoop，数据必须小多少？

你也不是亚马逊

使用UNPHAT法很直白。最近我与一家企业交流，这家公司要在夜间处理数据，当中包括大量读取操作的工作流，它想使用Cassandra。

读了Dynamo的论文之后，我知道Cassandra分布式数据库将“写操作”放在优先位置（亚马逊需要完成“加入购物车”的动作，不能出现错误）。我还知道，亚马逊选择这种技术牺牲了一致性，传统RDBMS的每一个功能也都牺牲了。不过与我交流的公司没有必要将写操作放在优先位置，因为它的读取模式是每天大规模写一次。

这家公司为什么考虑Cassandra？因为用PostgreSQL查询问题需要几分钟，他们认为是硬件局限性造成的。问了几个问题之后，我发现表格有大约5000万行，80字节宽，能不能用5秒左右的时间从所有SSD中读取数据。仍然很慢，但是比实际查询速度快了很多很多。

在这件事情上，我想问更多的问题（理解问题），当问题出现时我权衡了5种策略（枚举多个候选解决方案），有一点很明显，选择Cassandra是完全错误的。它们要做的是优化系统，可能还要对一些数据重新建模，或者（也可能不是）选择另一种技术……显然不是Cassandra技术，亚马逊将关键值存储起来，这些数据高度重视写操作，它们是为购物车创建的。

你也不是LinkedIn

我的一名学生创办了一家公司，他的公司根据Kafka搭建系统，我感到很惊讶。为什么吃惊？因为据我所知，他们的企业每天只处理几十宗高价值交易——最多可能几百宗。既然处理的数据如此少，最好的数据库可能是让人写在实体书上。

对比一下，Kafka是用来处理LinkedIn所有分析事件的：海量的数字。放在几年前，每天这样的事件可能有1万亿件，高峰时期每秒1000万条信息。我知道，即使吞吐量低，Kafka仍然可以使用，但是如果少了10个数量级呢？

可能工程师做出这样的决定是因为他们预计未来需求会大增，或者对Kafka的基本原理有着深刻的理解。不过照我猜测，可能是社区对Kafka热情高涨，影响了他们，工程师没有深入思考它是否适合自己。我的意思是处理的信息少了10个数量级！

再次重申，你不是亚马逊

与亚马逊分布式数据库相比，让它可以扩展的架构模式更流行，也就是以服务为中心的架构。2006年，Jim Gray采访Werner Vogels，当时Werner Vogels说亚马逊早在2001年就意识到它们想扩展前端相当吃力，最终以服务为中心的架构帮上大忙。这种观点得到了工程师的推崇，结果一些只有几名工程师、没有多少用户的创业公司也将自己的App打碎，放进微服务。

当亚马逊决定向SOA转移时，它的员工数量已经达到8700人，销售额超过30亿美元。

并不是说你的员工数量达到8700人才能使用SOA……只是你应该多掂量掂量自己。要解决你的问题，它的方案真的是最好的吗？你的问题到底是什么，能不能用其它办法解决？

如果你告诉我，说你们有50人的工程团队，如果没有SOA工作将无法开展下去，我会感到奇怪，因为有许多更大的企业只有更大、但是组织更好的单一应用，它们同样做得很好。

甚至连Google都不是Google

使用大规模数据流引擎（比如Hadoop、Spark）是一件相当有趣的事：不过许多时候传统DBMS够用了，与工作流更匹配，有时数据的数量很小，完全可以放进内存中。你知道吗，花1万美元就可以买1TB的内存？即使你有10亿用户，每位用户也可以分派1KB的内存。

对你来说也许不够，你要将数据写入硬盘，从硬盘上读取。但是你要从无数的硬盘中完成读写操作吗？你到底有多少数据？GFS与MapReduce之所以开发出来，是为了处理基于整个网络的计算问题，例如为整个网络重建搜索索引。

你也许已经读过GFS和MapReduce的相关论文，知道Google的部分问题不在于容量，而在于吞吐量：它采用分布式存储方式，主要是字节流离开硬盘需要太长的时间。2017年，你所使用的设备吞吐量如何？假设你需要的数量没有Google多，你能否购买更好的？使用SSD到底要花多少钱？

也许你想在未来扩容。那么你计算过吗？数字的增长速度比SSD价格下跌的速度快吗？当你所有的数据不再适合用一台机器处理时，你的企业需要变得有多大？截止2016年，Stack Exchange每天处理2亿查询量，它只用了4台SQL服务器：一台服务器处理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的话说就是：“回答你不理解的问题是愚蠢的，为了一个你不想要的结果工作是悲哀的。”

【编译组出品】编辑：杨志芳