每日一博 | 揭秘“撩”大数据的正确姿势:生动示例解说大数据“三驾马车”
我是我:“缘起于美丽,相识于邂逅,厮守到白头!”
众听众:“呃,难道今天是要分享如何作诗?!”
我是我:“大家不要误会,今天主要的分享不是如何作诗,而是《揭秘:‘撩’大数据的正确姿势》,下面进入正题。”
话说当下技术圈的朋友,一起聚个会聊个天,如果不会点大数据的知识,感觉都融入不了圈子,为了以后聚会时让你有聊有料,接下来就跟随我的讲述,一起与大数据混个脸熟吧,不过在“撩”大数据之前,还是先揭秘一下研发这些年我们都经历了啥?
缘起:应用系统架构的从 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期-宜信支付结算部支付研发团队高级工程师许赛赛《揭秘:“撩”大数据的正确姿势》
分享者:宜信支付结算部支付研发团队高级工程师许赛赛
原文首发于公号-野指针
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
XWiki 11.10.2 发布,协作式应用开发平台
XWiki 11.10.2 发布了,XWiki 是一个用 Java 编写的开源 wiki 和应用平台。它的开发平台特性允许创建协作式 Web 应用,同时也提供了构建于平台之上的打包应用(第二代 wiki,又名应用程序 wiki)。与第一代 wiki 是用于内容协作不同,第二代 wiki 可用于创建协作式 Web 应用程序。XWiki 同时兼具两代 wiki 功能。 XWiki Commons、XWiki Rendering与XWiki Platform一起发布并具有相同的版本。 新版是个 Bug 修复版本,更新内容有: 切换到德语时出现 “http” 数据库访问错误 在基于 docker 的测试框架中配置扩展时不考虑额外的 JAR 导出所有页面时仅提交过滤器 可以单击导出而无需选择任何页面 未正确考虑在 DW 的孤立依赖项步骤中取消选择所有扩展名 使用历史记录替换导入会导致找不到附件文件 部分 XAR 导出包括未选择的页面 当 OS 用户帐户名称包含美元符号时,带有历史记录的 XAR 导出失败 升级到模板应用程序 v1.0.5 如果事件多于 21,则将事件标记为已读时,通知计数不显...
- 下一篇
Chromium Microsoft Edge 浏览器删除了 Beta 标签
微软离基于 Chromium 的浏览器的发布越来越近,因此该公司最近开始推出一项更改,以确认我们处于该应用程序的最终开发阶段。 德国网站WU透露,微软已开始为许多测试人员删除 beta 标签,这意味着 Microsoft Edge 的现有安装不再表明它们属于 beta 程序。 不过显然的是,这项更改还正在分阶段向用户推出,因此并不是每个用户都会看到 beta 标签的消失。而在另一方面,大众对于删除 beta 标志的原因也颇感兴趣,并陷入了热烈的讨论。 微软将于 1 月 15 日发布稳定版本的新浏览器,在 Windows 10 系统上,它将通过 Windows Update 推送。微软方面曾确认,Chromium Edge 的稳定版本将与Canary,Dev 和 Beta channels 的测试版本并行工作。换句话说,稳定的构建不会替代 beta sibling,因此实际上并没有删除 beta 标志的必要。 微软曾表示:”在安装下一版本的 Microsoft Edge 的稳定版本之前,更新不会改变用户体验。安装 Microsoft Edge Beta,Dev 或 Canary 不会在 ...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果