生动示例解说大数据“三驾马车”。
我是我：“缘起于美丽，相识于邂逅，厮守到白头！”
众听众：“呃，难道今天是要分享如何作诗？！”
我是我：“大家不要误会，今天主要的分享不是如何作诗，而是《揭秘：‘撩’大数据的正确姿势》，下面进入正题。”
话说当下技术圈的朋友，一起聚个会聊个天，如果不会点大数据的知识，感觉都融入不了圈子，为了以后聚会时让你有聊有料，接下来就跟随我的讲述，一起与大数据混个脸熟吧，不过在“撩”大数据之前，还是先揭秘一下研发这些年我们都经历了啥？
缘起：应用系统架构的从 0 到 1
揭秘：研发这些年我们都经历了啥？
大道至简。生活在技术圈里，大家静下来想想，无论一个应用系统多庞大、多复杂，无非也就是由一个漂亮的网站门面 + 一个丑陋的管理模块 + 一个闷头干活的定时任务三大板块组成。
我们负责的应用系统当然也不例外，起初设计的时候三大模块绑在一起（All in one），线上跑一个 Tomcat 轻松就搞定，可谓是像极了一个大泥球。
衍化至繁。由于网站模块、管理平台、定时任务三大模块绑定在一起，开发协作会比较麻烦，时不时会有代码合并冲突出现；线上应用升级时，也会导致其它模块暂时不能使用，例如如果修改了一个定时任务的配置，可能会导致网站、管理平台的服务暂时不能用。面对诸多的不便，就不得不对 All in one 的大泥球系统进行拆解。
随着产品需求的快速迭代，网站 WEB 功能逐渐增多，我们起初设计时雄心勃勃（All in one 的单体架构），以为直接按模块设计叠加实现就好了，谁成想系统越发显得臃肿（想想也是走弯路啦！）。所以不得不改变实现思路，让模块服务下沉，分布式思想若现——让原来网站 WEB 一个系统做的事，变成由子系统分担去完成。
应用架构的演变，服务模块化拆分，随之而来的就是业务日志、业务数据散落在各处。随着业务的推广，业务量逐日增多，沉淀的数据日益庞大，在业务层面、运维层面上的很多问题，逐渐开始暴露。
-
在业务层面上，面对监管机构的监管，整合提取散落在各地的海量数据稍显困难；海量数据散落，想做个统计分析报表也非常不易。
-
在运维层面上，由于缺少统一的日志归档，想基于日志做快速分析也比较困难；如果想从散落在各模块的日志中，进行调用链路的分析也是相当费劲。
面对上述问题，此时一个硕大的红色问号出现在我们面前，到底该如何解决？
面对结构化的业务数据，不妨先考虑采用国内比较成熟的开源数据库中间件 Sharding-JDBC、MyCat 看是否能够解决业务问题；面对日志数据，可以考虑采用 ELK 等开源组件。如果以上方案或者能尝试的方式都无法帮我们解决，尝试搬出大数据吧。
那到底什么时候需要用大数据呢？大数据到底能帮我们解决什么问题呢？注意，前方高能预警，门外汉“撩”大数据的正确姿势即将开启。
邂逅：一起撬开大数据之门
槽点：门外汉“撩”大数据的正确姿势
与大数据的邂逅，源于两个头痛的问题。第一个问题是海量数据的存储，如何解决？第二个问题是海量数据的计算，如何解决？
面对这两个头痛的问题，不得不提及谷歌的“三驾马车”（分布式文件系统 GFS、MapReduce 和 BigTable），谷歌“三驾马车”的出现，奠定了大数据发展的基石，毫不夸张地说，没有谷歌的“三驾马车”就没有大数据，所以接下来很有必要逐一认识。
大家都知道，谷歌搜索引擎每天要抓取数以亿计的网页，那么抓取的海量数据该怎么存储？
谷歌痛则思变，重磅推出分布式文件系统 GFS。面对谷歌推出的分布式文件系统 GFS 架构，如 PPT 中示意，参与角色着实很简单，主要分为 GFS Master（主服务器）、GFS Chunkserver（块存储服务器）、GFS Client（客户端）。
不过对于首次接触这个的你，可能还是一脸懵 ，大家心莫慌，接下来容我抽象一下。
GFS Master 我们姑且认为是古代的皇上，统筹全局，运筹帷幄。主要负责掌控管理所有文件系统的元数据，包括文件和块的命名空间、从文件到块的映射、每个块所在的节点位置。说白了，就是要维护哪个文件存在哪些文件服务器上的元数据信息，并且定期通过心跳机制与每一个 GFS Chunkserver 通信，向其发送指令并收集其状态。
GFS Chunkserver 可以认为是宰相，因为宰相肚子里面能撑船，能够海纳百川。主要提供数据块的存储服务，以文件的形式存储于 Chunkserver 上。
GFS Client 可以认为是使者，对外提供一套类似传统文件系统的 API 接口，对内主要通过与皇帝通信来获取元数据，然后直接和宰相交互，来进行所有的数据操作。
为了让大家对 GFS 背后的读写流程有更多认识，献上两首歌谣。
到这里，大家应该对分布式文件系统 GFS 不再陌生，以后在饭桌上讨论该话题时，也能与朋友交涉两嗓子啦。
不过这还只是了解了海量数据怎么存储，那如何从海量数据存储中，快速计算出我们想要的结果呢？
面对海量数据的计算，谷歌再次创新，推出了 MapReduce 编程模型及实现。
MapReduce 主要是采取分而治之的思想，通俗地讲，主要是将一个大规模的问题，分成多个小规模的问题，把多个小规模问题解决，然后再合并小规模问题的结果，就能够解决大规模的问题。
也有人说 MapReduce 就像光头强的锯子和锤子，世界上的万事万物都可以先锯几下，然后再锤几下，就能轻松搞定，至于锯子怎么锯，锤子怎么锤，那就是个人的手艺了。
这么解释不免显得枯燥乏味，我们不妨换种方式，走进生活真实感受 MapReduce。
斗地主估计大家都玩过，每次开玩之前，都会统计一副牌的张数到底够不够，最快的步骤莫过于：分几份给大家一起数，最后大家把数累加，算总张数，接着就可以愉快地玩耍啦... ...这不就是分而治之的思想吗？！不得不说架构思想来源于人们的生活！
再举个不太贴切的例子来感受MapReduce 背后的运转流程，估计很多人掰过玉米，每当玉米成熟的季节，地主家就开始忙碌起来。
首先地主将一亩地的玉米分给处于空闲状态的长工来处理；专门负责掰玉米的长工领取任务，开始掰玉米操作（Map 操作），并把掰好的玉米放到在麻袋里（缓冲区），麻袋装不下时，会被装到木桶中（溢写），木桶被划分为蓝色的生玉米木桶、红色的熟玉米木桶（分区），地主通知二当家来“收”属于自己的那部分玉米，二当家收到地主的通知后，就到相应的长工那儿“拿回”属于自己的那部分玉米（Fetch 操作），二当家对收取的玉米进行处理（Reduce 操作），并把处理后的结果放入粮仓。
一个不太贴切的生活体验 + 一张画得不太对的丑图 = 苦涩难懂的技术，也不知道这样解释，你了解了多少？不过如果以后再谈大数据，知道 MapReduce 这个词的存在，那这次的分享就算成功（哈哈）。
MapReduce 解决了海量数据的计算问题，可谓是力作，但谷歌新的业务需求一直在不断出现。众所周知，谷歌要存储爬取的海量网页，由于网页会不断更新，所以要不断地针对同一个 URL 进行爬取，那么就需要能够存储一个 URL 不同时期的多个版本的网页内容。谷歌面临很多诸如此类的业务场景，面对此类头痛的需求，该怎么办？
谷歌重磅打造了一款类似以“URL + contents + time stamp”为 key，以“html 网页内容”为值的存储系统，于是就有了 BigTable 这个键值系统的存在（本文不展开详述）。
至此，两个头痛的问题就算解决了。面对海量数据存储难题，谷歌推出了分布式文件系统 GFS、结构化存储系统 BigTable；面对海量数据的计算难题，谷歌推出了 MapReduce。
不过静下来想想，GFS 也好、MapReduce 也罢，无非都是秉承了大道至简、一人掌权、其它人办事、人多力量大的设计理念。另外画龙画虎难画骨，建议闲暇之余也多些思考：为什么架构要这么设计？架构设计的目标到底是如何体现的？
基于谷歌的“三驾马车”，出现了一大堆开源的轮子，不得不说谷歌的“三驾马车”开启了大数据时代。了解了谷歌的“三驾马车”的设计理念后，再去看这些开源的轮子，应该会比较好上手。
好了，门外汉“撩”大数据就聊到这儿吧，希望通过上文的分享能够了解几个关键词：大道至简、衍化至繁、谷歌三驾马车（GFS、MapReduce、BigTable）、痛则思变、开源轮子。
白头：番外篇
扯淡：不妨换一种态度
本文至此也即将接近尾声，最后是番外篇~
首先，借用日本剑道学习心诀“守、破、离”，希望我们一起做一个精进的人。
最后，在有限的时间内要多学习，不要停下学习的脚步，在了解和使用已经有的成熟技术之时，更要多思考，开创适合自己工作场景的解决方案。
【本文是51CTO专栏机构宜信技术学院的原创文章，微信公众号“宜信技术学院( id: CE_TECH)”】
