为什么说,MapReduce,颠覆了互联网分层架构的本质?
为什么说,MapReduce系统架构,颠覆了互联网分层架构的本质?
下图是一个典型的,互联网分层架构:
客户端层:典型调用方是浏览器browser或者手机APP
站点应用层:实现核心业务逻辑,从下游获取数据,对上游返回html或者json
服务层:业务服务,数据服务,基础服务,对上游提供友好的RPC接口
数据缓存层:缓存加速访问存储
数据固化层:数据库固化数据存储
同一个层次的内部,例如端上的APP,以及web-server,也都会进行MVC分层:
view层:展现
control层:逻辑
model层:数据
工程师骨子里,都潜移默化的实施着分层架构设计。
互联网分层架构的本质究竟是什么呢?
如果我们仔细思考会发现,不管是跨进程的分层架构,还是进程内的MVC分层,都是一个“数据移动”,然后“被处理”和“被呈现”的过程。
如上图所示:
数据处理和呈现,需要CPU计算,而CPU是固定不动的:
db/service/web-server都部署在固定的集群上
端上,不管是browser还是APP,也有固定的CPU处理
而数据是移动的:
跨进程的:数据从数据库和缓存里,转移到service层,到web-server层,到client层
同进程的:数据从model层,转移到control层,转移到view层
归根结底一句话:互联网分层架构,是一个CPU固定,数据移动的架构。
画外音:更详细的分析,详见《互联网分层架构的本质》。
MapReduce的架构,是不是也遵循这个架构特点呢?
假如MapReduce也使用类似的的分层架构模式:
提前部署服务:
map服务层:接收输入数据,产出“分”的数据,集群部署M=1W个实例
reduce服务层:接受“合”的数据,产出最终数据,集群部署R=1W个实例
当用户提交作业时:
(1) 把数据数据传输给map服务集群;
(2) map服务集群产出结果后,把数据传输给reduce服务集群;
(3) reduce服务集群把结果传输给用户;
存在什么问题?
将有大量的时间浪费在大量数据的网络传输上。
画外音:输入给map,map给reduce,reduce给用户。
会发现,“固定CPU,移动数据”的架构并不适合。
Google MapReduce工程架构是如何思考这一个问题的呢?
问了减少数据量的传输:
(1) 输入数据,被分割为M块后,master会尽量将执行map函数的worker实例,启动在输入数据所在的服务器上;
画外音:不需要网络传输了。
(2) map函数的worker实例输出的的结果,会被分区函数划分成R块,写到worker实例所在的本地磁盘;
画外音:不需要网络传输了。
(3) reduce函数,由于有M个输入数据源(M个map的输出都有一部分数据可能对应到一个reduce的输入数据),所以,master会尽量将执行reduce函数的worker实例,启动在离这些输入数据源尽可能“近”的服务器上;
画外音:目的也是最小化网络传输;
服务器之间的“近”,可以用内网IP地址的相似度衡量。
所以,对于MapReduce系统架构,“固定数据,移动CPU”更为合理。
这是为什么呢?
互联网在线业务的特点是:
总数据量大
吞吐量比较大,同时发起的请求多
每个请求,处理的数据相对比较小
用户对处理时延比较敏感
这类业务,使用“固定CPU,移动数据”的分层架构是合理的。
MapReduce离线业务的特点是:
吞吐量比较小,同时发起的任务比较少
每个任务,处理的数据量非常大
用户对处理时延容忍性大
这类业务,使用“固定数据,移动CPU”的分层架构是合理的。
任何脱离业务的架构设计,都是耍流氓。
思考问题的本质,希望大家有收获。
原文发布时间为:2018-12-14
本文作者: 58沈剑
本文来自云栖社区合作伙伴“ 架构师之路”,了解相关信息可以关注“road5858”微信公众号
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Elasticsearch学习,请先看这一篇!(Elasticsearch教程01)|MVP讲堂
作者:阿里云MVP 铭毅 上节内容:死磕 Elasticsearch 方法论:普通程序员高效精进的 10 大狠招!下节链接:Elasticsearch增、删、改、查操作深入详解(Elasticsearch教程02) 题记:Elasticsearch研究有一段时间了,现特将Elasticsearch相关核心知识、原理从初学者认知、学习的角度,从以下9个方面进行详细梳理。欢迎讨论…… **0. 带着问题上路——ES是如何产生的?(1)思考:大规模数据如何检索?**如:当系统数据量上了10亿、100亿条的时候,我们在做系统架构的时候通常会从以下角度去考虑问题: 1)用什么数据库好?(mysql、sybase、oracle、达梦、神通、mongodb、hbase…) 2)如何解决单点故障;(lvs、F5、A10、Zookeep、MQ) 3)如何
- 下一篇
使用Data Lake Analytics快速分析OSS上的日志文件
背景 Data Lake Analytics (后文简称 DLA)是Serverless化的云上交互式查询分析服务,用户可以通过标准的SQL语句对存储在OSS, OTS, RDS等介质上的数据进行快速地查询分析。 日志文件在大数据分析中的地位举足轻重。对于一个服务来说,其日志文件往往记录了其运行的所有详细信息。无论是故障排除,状态监控,还是预测告警,都离不开对日志文件的查询分析。由于OSS的高性价比,越来越多的用户倾向把大量的日志文件存储在OSS中。DLA可以无需移动OSS上的日志文件,直接对其做查询分析。 本文将介绍如何使用DLA对常见格式的日志文件做查询。 使用DLA查询日志文件 DLA可以分析的日志文件需要满足下面的条件: 日志文件是纯文本的格式,每行可以映射为表中的一条记录; 每行的内容有固定的模式,可以用一个正则表达式去匹配 目前对日志
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8编译安装MySQL8.0.19
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2全家桶,快速入门学习开发网站教程