软件工程师对于最荒渺的事情非常热衷。我们倾向于认为自己是超理性的，但是当我们面临一种技术选择的时候，我们最终会陷入一种疯狂状态——从一个人的Hacker News评论跳到另一个人的博客文章，直到变得麻木，我们无助地漂浮朝着最明亮的光线倾斜，并且俯卧在它的前面，而忽略了我们最初寻找的东西。
这不是理性的人做出决定的方式，而是软件工程师决定使用MapReduce的方式。
正如Joe Hellerstein在他的本科数据库课程[1]上所说的（在54分钟）：
问题是世界上有5家公司从事如此大的工作。对于其他所有人……你正在为实际上不需要的容错能力执行所有这些I/O。人们在2000年代有点Google的狂热：“我们将像Google一样做所有事情，因为我们也运行着世界上最大的互联网数据服务” [横摆倾斜，等待笑声]
你们的数据中心大楼有几层？Google在俄克拉荷马州梅斯县的数据中心是4层。
拥有比所需更多的容错能力可能听起来不错，但考虑到成本：不仅会做更多的I/O，而且可能会从一个成熟的系统（如事务，索引和查询优化器）过渡到某种相对不成熟的系统上。真是倒退了一大步[2]。有多少Hadoop用户自觉地进行了这些折衷？有多少用户明智地进行了这些折衷？
目前，MapReduce/Hadoop仅仅是一个简单的目标（soft target），即使开发人员已经意识到目标不是很合适。但是，可以从更广泛的角度进行同样的观察：如果你使用的技术源于一家大公司，但是你的用例却大不相同，那么你就不太可能达到同样的效果；不，应该说你可以通过模仿巨人会带来相同的财富这种仪式主义信念而达成目标。
好吧，其实：这是又一篇“不要崇拜”的文章。但是等一下！我为你准备了一份有用的清单，你可以用来做更好的决定。
酷科技？UNPHAT
下一次当你正在搜索一些酷的新技术，用于构建（重构）你的架构时，我强烈建议你先停下来，然后遵循UNPHAT原则：
在没有理解（Understand）问题之前，不要考虑解决方案。你的目标主要应该是在问题领域而不是在解决方案领域“解决”问题。
列举（eNumerate）多个候选解决方案。而不是一开始就按自己喜欢的方式行事！
考虑一种候选解决方案，如果有相关论文，那么要阅读该论文（Paper）。
确定候选解决方案当初设计或开发的历史背景（Historical context）。
权衡利（Advantages）弊。确定哪些不是优先考虑的，哪些是需要优先实现的。
多想想（Think）！冷静而谦逊的思考一下该解决方式是否真的适合你的问题。基于哪些事实情况，你才会改变想法？例如，在你选择不使用Hadoop之前，数据需要多小才行？
你也不是亚马逊
应用UNPHAT原则非常简单。最近我和一家公司有过一次交流，这家公司曾经短暂的考虑过将Cassandra用于主要对数据读取的工作流，这些数据在夜间加载：
阅读了Dynamo的论文，并知道Cassandra是它的一个紧密的衍生物后，我了解到这些分布式数据库优先考虑写可用性（Amazon希望“添加到购物车”操作永远不会失败）。我也挺欣赏他们通过牺牲一致性以及存在于传统RDBMS中差不多每个功能特性来做到这一点。但是与我交流的那家公司不需要优先考虑写可用性，因为访问模式要求每天只需要进行一次大的写操作就行。
亚马逊卖很多东西。如果“添加到购物车”偶尔失败，他们将损失很多钱。你的用例是否相同？
该公司之所以选择Cassandra，是因为PostgreSQL查询需要消耗比较长的时间，他们认为这是由于硬件的限制导致的。经过几个问题之后，我们得出数据表大约在有5000万行和80字节宽的时候，那么在需要完整的文件扫描（FileScan）情况下，也需要大约5秒钟才能从SSD上读取全部内容。速度很慢，但是比实际查询快2个数量级。
在这一点上，我真的很想问更多问题（question）（理解真正的问题（problem）！），并开始权衡问题发展的5种策略（列举多个候选解决方案！），但很显然，Cassandra是一个完全错误的解决方案。他们所需要做的只是进行一些耐心的调整，也许重新建模一些数据，也许（但可能不是）另一种技术选择……但肯定不是亚马逊为其购物车创建的高写入可用性键值存储！
你也不是LinkedIn
我很惊讶的发现我的一个学生公司选择使用Kafka构建他们的系统。这很让人惊讶，据我所知，他们的业务每天仅处理几十笔非常高价值的交易——好的情况下一天有几百笔。以这样的吞吐量，他们的数据存储改成人工记录到本子上都可以。
相比之下，Kafka设计之初用于处理LinkedIn上所有分析事件的吞吐量：一个巨大的数字。即使在几年前，每天也有大约1万亿个事件发生，每秒峰值超过1000万条消息[3]。当然Kafka仍可用于较低吞吐量的工作，但要低10个数量级？
太阳虽然很大，但也只是比地球大6个数量级。
也许工程师确实根据他们的预期需求和对Kafka原理的充分理解做出了明智的决定。但是我的猜测是，他们更多受社区（通常是合理的）对Kafka的热情感染，却丝毫没有考虑这是否适合这项工作。我的意思是……10个数量级！
再说一遍，你不是亚马逊
比Amazon分布式数据存储更受欢迎是他们认为可扩展（scale）的架构模式：面向服务的架构。正如沃纳·沃格斯（Werner Vogels）在2006年接受吉姆·格雷（Jim Gray）采访[4]时指出的那样，亚马逊在2001年意识到面向服务的体系结构对于扩展前端有很大帮助。这种想法慢慢的在不同的工程师之间传播，在刚开始只有几个工程师在做这件事的时候，几乎很少有用户把他们的应用拆分成不同的小服务（nanoservices）。
但是当亚马逊决定迁移到SOA时，他们拥有大约7800名员工，销售额超过30亿美元[5]。
旧金山的比尔·格雷厄姆礼堂可容纳7,000人。迁移到SOA时，亚马逊大约有7,800名员工。
这并不是说你应该推迟SOA，直到达到7,800名员工的水平……只是，请自己考虑一下。这是解决你问题的最佳方法吗？你的问题到底是什么？还有其他解决方法？
如果你告诉我，你的50人工程师团队在没有SOA的情况下会陷入瘫痪，那么我想知道，为什么有很多大公司在一个大的但是组织良好的单应用程序上依然可以做的很好。
甚至Google也不是Google
大规模数据流引擎（如Hadoop和Spark）的使用可能特别有趣：传统DBMS通常更适合工作负载，有时数据量非常小，甚至可以容纳在内存中。你是否知道可以10,000美元左右购买1 TB的RAM？即使你有十亿用户，这也将为每个用户提供1KB的RAM。
可能这还不足以满足你的工作负载，因此你需要读写磁盘。但是，你是否需要读写几千个磁盘？你到底有多少数据？GFS和MapReduce就是为了处理整个Web上的计算问题应运而生的，例如……在整个Web上重建搜索索引。
硬盘价格现在比GFS论文发表那年的2003年要低得多。
也许你已经阅读了GFS和MapReduce的论文，并意识到Google的部分问题不是容量，而是吞吐量：它们分散存储，因为从磁盘流式传输字节花费的时间太长。但是，你在2017年使用的设备的吞吐量是多少？考虑到你不会需要像Google那样多的设备，那么你能买更好的吗？使用SSD会花多少钱？
也许你希望做扩展。但是你有做过计算吗？是不是可能存在数据的累积速度快于SSD价格下降的速度？你的业务需要增长多少才会让所有数据不再适合保存在一台机器？截至2016年，Stack Exchange每天处理2亿个请求，仅由四台SQL服务器提供支持[6]：一个主服务器用于Stack Overflow服务，一个主服务器用于所有其他内容服务以及两个备用服务器。
同样，你可能经历了类似UNPHAT的过程，但仍然决定使用Hadoop或Spark。这项决定甚至可能是正确的决定。重要的是你实际上使用了正确的工具来完成工作。Google非常了解这一点：一旦他们确定MapReduce不是构建索引的正确工具，便会停止使用它。
首要任务，理解问题
我的文章信息不是最新的，但也许是当前你看到的版本，或者UNPHAT让你印象深刻，最终让你应用它。如果没有，你可以尝试看看Rich Hickey的演讲Hammock驱动的开发[7]，或Polya的书如何解决[8]，或Hamming的课程科学与工程的艺术[9]。我们所有人恳求的是多思考！并真正了解你要解决的问题。用Polya让人深思的话说：
回答你不理解的问题是愚蠢的。为不是自己期待的结果的工作而工作是可悲的。
相关链接：
https://archive.org/details/ucberkeley_webcast_NSKvCVFmk2E
https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html
https://engineering.linkedin.com/kafka/running-kafka-scale
https://queue.acm.org/detail.cfm?id=1142065
http://media.corporate-ir.net/media_files/irol/97/97664/reports/2001annualreport.pdf
https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/
https://www.youtube.com/watch?v=f84n5oFoZBc
https://www.amazon.com/How-Solve-Mathematical-Princeton-Science/dp/069111966X
https://www.youtube.com/playlist?list=PL2FF649D0C4407B30
原文链接：https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb
Kubernetes管理员认证（CKA）培训
本次CKA培训在北京开班，基于最新考纲，通过线下授课、考题解读、模拟演练等方式，帮助学员快速掌握Kubernetes的理论知识和专业技能，并针对考试做特别强化训练，让学员能从容面对CKA认证考试，使学员既能掌握Kubernetes相关知识，又能通过CKA认证考试，学员可多次参加培训，直到通过认证。点击下方图片或者阅读原文链接查看详情。
