为何说,MapReduce,颠覆了互联网分层架构的本质?
下图是一个典型的，互联网分层架构：
- 客户端层：典型调用方是浏览器browser或者手机APP
- 站点应用层：实现核心业务逻辑，从下游获取数据，对上游返回html或者json
- 服务层：业务服务，数据服务，基础服务，对上游提供友好的RPC接口
- 数据缓存层：缓存加速访问存储
- 数据固化层：数据库固化数据存储
- view层：展现
- control层：逻辑
- model层：数据
如上图所示：数据处理和呈现，需要CPU计算，而CPU是固定不动的：- db/service/web-server都部署在固定的集群上
- 端上，不管是browser还是APP，也有固定的CPU处理
- 跨进程的：数据从数据库和缓存里，转移到service层，到web-server层，到client层
- 同进程的：数据从model层，转移到control层，转移到view层
假如MapReduce也使用类似的的分层架构模式：
提前部署服务：- map服务层：接收输入数据，产出“分”的数据，集群部署M=1W个实例
- reduce服务层：接受“合”的数据，产出最终数据，集群部署R=1W个实例
为了减少数据量的传输：(1) 输入数据，被分割为M块后，master会尽量将执行map函数的worker实例，启动在输入数据所在的服务器上；画外音：不需要网络传输了。(2) map函数的worker实例输出的的结果，会被分区函数划分成R块，写到worker实例所在的本地磁盘；画外音：不需要网络传输了。
(3) reduce函数，由于有M个输入数据源（M个map的输出都有一部分数据可能对应到一个reduce的输入数据），所以，master会尽量将执行reduce函数的worker实例，启动在离这些输入数据源尽可能“近”的服务器上；画外音：目的也是最小化网络传输；服务器之间的“近”，可以用内网IP地址的相似度衡量。 所以，对于MapReduce系统架构，“固定数据，移动CPU”更为合理。 这是为什么呢？ 互联网在线业务的特点是：
- 总数据量大
- 吞吐量比较大，同时发起的请求多
- 每个请求，处理的数据相对比较小
- 用户对处理时延比较敏感
MapReduce离线业务的特点是：
- 吞吐量比较小，同时发起的任务比较少
- 每个任务，处理的数据量非常大
- 用户对处理时延容忍性大
任何脱离业务的架构设计，都是耍流氓。思考问题的本质，希望大家有收获。
福利来了！！！
免费直播，大数据MapReduce升级版Spark。
事件：京东商城大数据实战
人物：凤凰金融大数据一把手，王端阳老师
时间：7月29日，20:00（没错，今晚8点）
分享提纲是什么？
（1）企业级大数据开发流程分析；
（2）大数据分布式计算的核心思想倾囊相授；
（3）Spark体系架构和任务提交流程分析；
（4）手把手带你使用 Spark 实现企业日志分析
（5）常见的大数据分布式计算引擎对比分析；
有技术资料么（以下所有课程，免费）？
大数据开发&架构，20项核心攻略：《Linux基础命令及使用》《Scala视频》《Hadoop集群搭建》《HDFS 架构设计》《手写简单实现Hadoop》《实现RPC》《实现HDFS》《实现MR》《Hive底层执行引擎剖析》《Hive性能调优实战》《大数据集群资源如何评估》《Kafka消息引擎底层架构剖析》《Kafka源码讲解》《Kafka高性能的消息封装》《Kafka客户端容错体系源》《Kafka服务端高性能架构设计》《Kafka数据管理》《数据中台的建设》《数据中台建设数据治理篇》《ZooKeeper企业实战&原理剖析》
扫码获取直播地址，免费领资料
祝大家在P8之路上前行，阅读原文，福利等你。
评论