揭秘“撩”大数据的正确姿式：生动示例解说大数据“三驾马车”

我是我：“缘起于美丽，相识于邂逅，厮守到白头！”

众听众：“呃，难道今天是要分享如何做诗？！”

我是我：“你们不要误会，今天主要的分享不是如何做诗，而是《揭秘：‘撩’大数据的正确姿式》，下面进入正题。”

话说当下技术圈的朋友，一块儿聚个会聊个天，若是不会点大数据的知识，感受都融入不了圈子，为了之后聚会时让你有聊有料，接下来就跟随个人讲述，一块儿与大数据混个脸熟吧，不过在“撩”大数据以前，仍是先揭秘一下研发这些年咱们都经历了啥？

缘起：应用系统架构的从 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）、痛则思变、开源轮子。

白头：番外篇

扯淡：不妨换一种态度

本文至此也即将接近尾声，最后是番外篇~

首先，借用日本剑道学习心诀“守、破、离”，但愿咱们一块儿作一个精进的人。

最后，在有限的时间内要多学习，不要停下学习的脚步，在了解和使用已经有的成熟技术之时，更要多思考，开创适合本身工做场景的解决方案。

文章来源：宜信技术学院 & 宜信支付结算团队技术分享第6期-宜信支付结算部支付研发团队高级工程师许赛赛《揭秘：“撩”大数据的正确姿式》

分享者：宜信支付结算部支付研发团队高级工程师许赛赛

原文首发于公号-野指针