一拍脑袋就要用MapReduce?你以为你是Google啊

大数据文摘作品,转载要求见文末

原作者 | Ozan Onay

编译 | 高宁,朱璇,Aileen

导读:MapReduce,Hadoop,Kafka……似乎每天都有新的名词出现,每天都会有看似很酷的新技术诞生。是否我们现在的系统框架已经过时了?是否应该效仿谷歌、亚马逊或者领英的技术和方式?

本文作者提出的UNPHAT方法非常实用,它教你如何在急着行动前,清醒的想一想,最适合自己的选择才是对的。

除了技术/系统框架的抉择,这个方法对解决生活中的任何问题都是不错的启发。

21世纪,每个人都多少有些谷歌狂热症,似乎按照谷歌的方式做事,我就能得到谷歌的财富。比如,作为一名软件工程师,我是否该效仿谷歌建立MapReduce框架?是否应该像领英一样用Kafka来搭建系统?

伯克利计算机学院教授Joe Hellerstein会在每次课上会告诫他的本科生:“你不是谷歌,你经营的可不是全球最大的互联网数据服务。”

有兴趣可参考视频:

https://archive.org/details/ucberkeley_webcast_NSKvCVFmk2E

事实上,这个世界上目前只有5家公司在运行着足够巨大需要MapReduce框架的程序。而对于其他公司,只是在 I/O(输入输出)上做了很多不必须的防错工作。

你们的数据中心大楼有多少层?谷歌的有4层,上图就是他们位于俄克拉荷马州梅斯县的数据中心。

这当然也涉及了更多不必要的费用的产生:一方面你需要做更多的I/O,另一方面你需要从一个使用了很久、相对成熟的系统转移到一个你并不熟悉的系统。这其实是一种大的退步。有多少Hadoop的用户清醒地权衡过这些得失?又有多少用户能对此做出明智的决定?

如果你正在使用的技术来源于一家大公司,但是你的业务情景完全不同,你将很难从容地用他们的技术来实现同样的效果。

恩,是的,这是另一篇“不要盲目崇拜新技术”的文章。

尝试新技术前,先试试UNPHAT法则

软件工程师有时会为些荒诞不羁的事情而疯狂。当需要选择实用哪一种技术时,我们会从社交网络里中某人的评论,跳到另一个人的博客,不断的摇摆不定下不了决心,最终陷入到一种疯狂的状态。迷茫中,我们总是朝着那些好像最耀眼的光芒漂游着,却忘记了我们真正寻找的是什么。

下一次,当你发现自己在网上了搜索 某些很酷的技术去(重新)搭建架构时,请先用这个UNPHAT 法则对这个新技术进行审视:

1. Understand (理解):在你理解问题之前,不要开始思考解决方案。应该从问题入手,而不是从答案入手。在问题的领域思考如何结局,而不是在“解决方案的领域”里选择解决办法。

2. Numerate(列举):请列举出多个候选方案,而不是直接选择你喜欢的那个。

3. Paper (论文):选定一个候选方案。如果你找到一篇候选方案的论文的话,请阅读它。

4. Historical Context (历史背景):在设计和开发候选方案时,请考虑相关方法的历史背景。

5. Advantage (优势):权衡利弊。决定使用什么样的优先级来排序所列出的利弊。

6. 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书中令人警醒的一段话作为结尾:

去回答一个你不明白的问题是愚蠢的。为了一个你并不想要的结局而努力是悲哀的。

原文链接:https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

深度学习与计算机视觉

稀牛学院最新线上课程,带你了解人工智能领域中,计算机视觉的理论基础前沿应用!不仅有完善的班级管理,更是首次承诺足量GPU的培训课程!

关于转载如需转载,请在开篇显著位置注明作者和出处(转自:大数据文摘 | bigdatadigest),并在文章结尾放置大数据文摘醒目二维码。无原创标识文章请按照转载要求编辑,可直接转载,转载后请将转载链接发送给我们;有原创标识文章,请发送【文章名称-待授权公众号名称及ID】给我们申请白名单授权。未经许可的转载以及改编者,我们将依法追究其法律责任。联系邮箱:zz@bigdatadigest.cn。

原文发布于微信公众号 - 大数据文摘(BigDataDigest)

原文发表时间:2017-08-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏java思维导图

八年Java架构学习经验总结:第六点尤为重要!

你有没有静下心来思考过:同样是做了x年Java开发,为什么你的技术比别人差很多?为什么别人每月28K你却只有10K?

1252
来自专栏微信公众号:Java团长

以Java后端高级开发为例,讲述面试前的准备点

由于我做了比较长时间的技术面试官,根据我的面试体会,不少同学收到面试后,什么准备也不会做,到时候就来了。

1242
来自专栏大数据技术学习

大数据的存储与备份,更离不开技术与创新

根据IDC研究报告,未来10年全球数据量将以40%多的增长速度呈直线上升趋势,2020年,全球的数据量将达到35ZB(35,000,000PB),是2010年的...

2508
来自专栏极限编程

我在ThoughtWorks中的敏捷实践

E项目是一个在线的物资跟踪监控系统。由ThoughtWorks团队为客户提供的一套完善的软件交付服务。

1103
来自专栏王亚昌的专栏

【观点】风雨20年:我所积累的20条编程经验

从11岁时,我就一直在编程,并且一直都很喜欢技术和编程。这些年来,我积累了一些艰难又容易的经验。作为一名程序员,你或许还没这些经验,但我会把它们献给那些想从中学...

1151
来自专栏喔家ArchiSelf

浅谈FPGA与音频处理器的结合

FPGA通常是面向通信行业,尽管其主要开发者仍然专注于通信应用, 但他们越来越关注存储和服务器市场。

1014
来自专栏云计算爱好者

简单科普云计算相关内容

云计算将是下一个网络大事件,我们先来看看什么是云计算,以及它究竟怎么工作的,同时它真的安全吗?这些疑问,我们简单地提供一些云计算的概念,让大家了解...

2715
来自专栏Java技术栈

面试 Java 高级后端开发,要准备哪些知识点?

由于我做了比较长时间的技术面试官,根据我的面试体会,不少同学收到面试后,什么准备也不会做,到时候就来了。

1061
来自专栏速成应用小程序开发平台

微信小程序与APP和公众号优势到底在哪里?为何能突出重围?

小程序确实过于诱人,根据阿拉丁小程序统计平台发布的2018年上半年小程序生态白皮书,截至目前,微信小程序C端用户达到2.8亿,小程序总量达100万,相对于今年年...

1483
来自专栏疯狂的小程序

重点解读:用小程序给公众号涨粉10w的7大行业案例

2017年1月9日,张小龙宣布小程序上线,到今天、刚好一周年; 期间陆陆续续出现了拼多多、摩拜单车、语音红包、头脑王者、心理测试等爆款小程序。今天来和大家聊聊如...

8078

扫码关注云+社区