科技猎一拍脑袋就要用MapReduce？你以为你是Google啊
大数据文摘作品，原作者 | Ozan Onay，编译 | 高宁，朱璇，Aileen。
MapReduce,Hadoop,Kafka……似乎每天都有新的名词出现，每天都会有看似很酷的新技术诞生。是否我们现在的系统框架已经过时了？是否应该效仿谷歌、亚马逊或者领英的技术和方式？
本文作者提出的UNPHAT方法非常实用，它教你如何在急着行动前，清醒的想一想，最适合自己的选择才是对的。
除了技术/系统框架的抉择，这个方法对解决生活中的任何问题都是不错的启发。
21世纪，每个人都多少有些谷歌狂热症，似乎按照谷歌的方式做事，我就能得到谷歌的财富。比如，作为一名软件工程师，我是否该效仿谷歌建立MapReduce框架？是否应该像领英一样用Kafka来搭建系统？
伯克利计算机学院教授Joe Hellerstein会在每次课上会告诫他的本科生：“你不是谷歌，你经营的可不是全球最大的互联网数据服务。”
有兴趣可参考视频： 链接
事实上，这个世界上目前只有5家公司在运行着足够巨大需要MapReduce框架的程序。而对于其他公司，只是在 I/O(输入输出)上做了很多不必须的防错工作。
你们的数据中心大楼有多少层？谷歌的有4层，上图就是他们位于俄克拉荷马州梅斯县的数据中心。
这当然也涉及了更多不必要的费用的产生：一方面你需要做更多的I/O，另一方面你需要从一个使用了很久、相对成熟的系统转移到一个你并不熟悉的系统。这其实是一种大的退步。有多少Hadoop的用户清醒地权衡过这些得失？又有多少用户能对此做出明智的决定？
如果你正在使用的技术来源于一家大公司，但是你的业务情景完全不同，你将很难从容地用他们的技术来实现同样的效果。
恩，是的，这是另一篇“不要盲目崇拜新技术”的文章。
尝试新技术前，先试试UNPHAT法则
软件工程师有时会为些荒诞不羁的事情而疯狂。当需要选择实用哪一种技术时，我们会从社交网络里中某人的评论，跳到另一个人的博客，不断的摇摆不定下不了决心，最终陷入到一种疯狂的状态。迷茫中，我们总是朝着那些好像最耀眼的光芒漂游着，却忘记了我们真正寻找的是什么。
下一次，当你发现自己在网上了搜索 某些很酷的技术去（重新）搭建架构时，请先用这个UNPHAT 法则对这个新技术进行审视：
- Understand (理解）：在你理解问题之前，不要开始思考解决方案。应该从问题入手，而不是从答案入手。在问题的领域思考如何结局，而不是在“解决方案的领域”里选择解决办法。
- Numerate(列举）：请列举出多个候选方案，而不是直接选择你喜欢的那个。
- Paper (论文）：选定一个候选方案。如果你找到一篇候选方案的论文的话，请阅读它。
- Historical Context (历史背景）：在设计和开发候选方案时，请考虑相关方法的历史背景。
- Advantage （优势）：权衡利弊。决定使用什么样的优先级来排序所列出的利弊。
- Think! (思考！)： 冷静而谦逊地思考这个解决方案与你的问题的匹配状况。考虑出现什么样的情况，你会改变自己的想法？例如，数据集小到什么程度，你会决定放弃使用Hadoop？
你不是亚马逊
下面是一个很简单的使用UNPHAT方法的例子。我最近和某家公司就是否使用Cassandra对夜间产生的大批量工作流数据进行读取的问题展开了讨论。
我读过Dynamo的论文，而且我知道Cassandra是一个Dynamo的衍生物，所以我清楚地了解这些分布式数据库将读写可用性放在第一位（亚马逊希望所有的“添加到购物车”行为永远不会失败）。我也知道他们是通过部分降低数据库的一致性来提高它的读写可用性，这会对传统关系型数据管理系统中的几乎所有特性都会产生一定影响。但是与我交谈的这家公司并不需要将读写可用性放在第一位，因为他们的传输模式是一天进行一次大批量的读写。
亚马逊出售大批量商品。如果“添加到购物车”功能偶尔发生故障，他们可能会损失很多收益，但是你的使用场景也是这样吗？
这家公司之所以想要使用Cassandra是因为PostgreSQL在读取文件时需要好几分钟的时间，他们认为这是一个硬件限制问题。在问了几个问题后，我们确定了如果需要从固态硬盘中读取一个5000万行、80字节宽的表格的完整的文件，大概需要5秒。虽然这个速度比较慢，但是仍比实际查询快了2个数量级。
此时，我需要再多问一些问题（来理解他们的问题），并衡量为防止问题变得严重的5个策略（列出多个候选方案！），但是我已经很清楚地知道使用Cassandra是一个完全错误的解决方案。他们需要去做的是耐心调试原有的结构，或者重新搭建一些数据结构，或者选择其他的技术方案（应该不需要）……但肯定不是亚马逊为购物车所搭建的高读写可用性的关键值存储方案！
你不是领英
我很惊奇地发现有个学生的公司选择使用Kafka来搭建他们的系统。而他们的业务流程只有每天几十条高价值交易，如果生意好的话，可能一百多条。对于这个吞吐量而言，一个人手工去进行记录就可以完成数据库存储了。
相对而言，Kafka是为了处理领英上所有的待分析的事件而设计的：这是一个很巨大的数字。即使是几年前，这个数字可以达到每天处理万亿事件，在高峰时期可以超过每秒一千万的信息量。我同意Kafka对于低吞吐量的工作负荷同样有效，但是相比之下，低了十个数量级的数据真的需要Kafka吗？
上图：太阳虽然很大，但也只是比地球大六个数量级。
或许工程师们根据预期需要和对Kafka理论基础的充分理解，“确实”做了一个经过考量的决定。但我估计他们是被一些社交网站（通常是合理的评论）中对Kafka的热情所洗脑，而几乎没有考虑它是否适合这个问题。毕竟……这个是差了十个数量级的情况。
回到亚马逊
比亚马逊分布式数据存储架构更受欢迎的是能支持他们规模化的面向服务的体系结构：service-oriented architecture（SOA）。Werner Vogels在2006年对Jim Gray的采访中提到，在2001年亚马逊意识到他们扩展前端受到限制，从而设计了一个面向服务的架构最终解决了这个问题。这种想法在工程师中产生了巨大影响，甚至只有几个工程师和很少的用户的创业公司都开始将他们的APP分解为一系列的迷你服务了。
但是当亚马逊决定迁移到SOA的时候，他们已有大概7800名雇员，而且销售额超过了三十亿美金。
上图：旧金山的比尔·格雷厄姆礼堂可以容纳7000人。而亚马逊决定转向到面向服务的框架（SOA）的时候，它的雇员大约有7800人。
我并不是说当你有7800名雇员的时候你才可以转向SOA。只是希望你可以思考，SOA对你的问题而言是最好的解决方案吗？你的问题到底是什么，以及你是否可以使用其他方法解决？
如果你说你的50人的工程师团队如果没有SOA就会难以运转，那么我会很好奇为什么那么多大公司使用一个很大但是管理得很好的单个应用程序也可以做的很好。
即使谷歌也不是谷歌
使用大型数据流引擎类似Hadoop和Spark也会特别有趣：通常，传统的数据库管理系统（DBMS）更适合于整体的工作负载，有时候数据量非常小，甚至可以存储在内存中。你知道可以使用10000美元购买一个千兆的内存条（RAM）吗？即使您拥有十亿用户，它仍可以为每个用户提供1kb的内存。
或许对于你的工作负载而言可能还不够，你需要对硬盘进行读写。但是你需要对数以千计的磁盘进行读写吗？确切的说，你拥有多少数据呢？GFS（可扩展的分布式文件系统）和MapReduce是为了处理整个网络的计算量而创造的，例如，在整个网络上重建搜索引擎……
上图：硬盘驱动器的每千兆字节的成本（美元）。今天的硬盘驱动器价格比2003年（GFS研究论文发布那年）低了很多很多。
或许你已经阅读了GFS和MapReduce的相关论文，而且很感谢谷歌的问题出现在输入输出量而不是容量上：他们进行分布式存储，因为磁盘存储需要太长时间。在2017年你将使用的硬件设备会有多大的输入输出量呢？考虑到你不会需要和谷歌一样的输入输出量，你是否只需要买一个更好的磁盘呢？使用SSD你会花多少钱呢？
或许你期望可以进行规模化。但是你有进行过数学计算吗？你累积数据的速度会比SSD价格下降的速度更快吗？你的业务需要增长多少，你的数据才会多到不能放在一台机器上。在2016年，Stack Exchange网站每天收到2亿个请求，而他们的后台仅仅是4台SQL服务器，一台主要服务于Stack Overflow网站，一台为其他事物服务，其他两台用来保存副本。
再次重申，你走完整个UNPHAT流程后，可能仍然决定使用Hadoop或者Spark。这个决定有可能是正确的。最重要的是，对于这个问题，你真的选择了最合适的工具。在这一点上，谷歌做的很好：当他们发现MapReduce不是构建索引最合适的工具后，他们就不再使用它了。
最重要的是理解问题
我上面提到的并不是全新的内容，但也许它能引起你的思考，或许使用UNPHAT对你来说有难以置信的效果。如果是这样，你可以尝试Rich Hickey谈话中（https://www.youtube.com/watch?v=f84n5oFoZBc）所提到的“吊床推动发展”，或者Polya书中（https://www.amazon.com/How-Solve-Mathematical-Princeton-Science/dp/069111966X）写到的“如何解决一个问题”，或者Hamming的课程中（https://www.youtube.com/playlist?list=PL2FF649D0C4407B30）所提到的“科学和工程实践的艺术”。我们希望你可以去思考并真正的了解你正在尝试解决的问题！
最后，我想以Ploya书中令人警醒的一段话作为结尾：
去回答一个你不明白的问题是愚蠢的。为了一个你并不想要的结局而努力是悲哀的。
原文链接