13518219792
根据您的个性需求进行定制 先人一步 抢占小程序红利时代
下图是一个典型的，互联网分层架构：
“只有客户发展了，才有我们的生存与发展！”这是成都创新互联的服务宗旨！把网站当作互联网产品，产品思维更注重全局思维、需求分析和迭代思维，在网站建设中就是为了建设一个不仅审美在线，而且实用性极高的网站。创新互联对成都网站设计、成都网站建设、网站制作、网站开发、网页设计、网站优化、网络推广、探索永无止境。
同一个层次的内部，例如端上的APP，以及web-server，也都会进行MVC分层：
工程师骨子里，都潜移默化的实施着分层架构设计。
互联网分层架构的本质究竟是什么呢?
如果我们仔细思考会发现，不管是跨进程的分层架构，还是进程内的MVC分层，都是一个“数据移动”，然后“被处理”和“被呈现”的过程。
如上图所示：数据处理和呈现，需要CPU计算，而CPU是固定不动的：
而数据是移动的：
归根结底一句话：互联网分层架构，是一个CPU固定，数据移动的架构。
MapReduce的架构，是不是也遵循这个架构特点呢?
假如MapReduce也使用类似的的分层架构模式：
提前部署服务：
当用户提交作业时：
存在什么问题?
将有大量的时间浪费在大量数据的网络传输上。
画外音：输入给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实例，启动在离这些输入数据源尽可能“近”的服务器上;
所以，对于MapReduce系统架构，“固定数据，移动CPU”更为合理。
这是为什么呢?
互联网在线业务的特点是：
这类业务，使用“固定CPU，移动数据”的分层架构是合理的。
MapReduce离线业务的特点是：
这类业务，使用“固定数据，移动CPU”的分层架构是合理的。
任何脱离业务的架构设计，都是耍流氓。
思考问题的本质，希望大家有收获。
【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】
戳这里，看该作者更多好文
