下图是一个典型的互联网分层架构：客户端层：典型的调用者是浏览器或手机APP站点应用层：实现核心业务逻辑，从下游获取数据，向上游返回html或json服务层：业务服务，数据服务，基础服务，向上游数据缓存层提供友好的RPC接口：缓存加速访问存储数据固化层：数据库固化同级内部的数据存储，如端APP，web-server，还会进行MVC分层：视图层：显示控制层：逻辑模型层：数据工程师潜移默化地进行分层架构设计。互联网分层架构的本质是什么？我们仔细想想就会发现，无论是跨进程的分层架构，还是进程内分层的MVC，都是一个“数据移动”，然后“处理”，“呈现”的过程。如上图：数据处理和呈现需要CPU计算，但CPU是固定的：db/service/web-server都部署在固定集群的上端，无论是浏览器还是APP，都有也是一个固定的CPU处理数据是移动的：跨进程：数据从数据库和缓存传输到服务层，到web-server层，到客户端层在同一进程中：数据从模型层传输到控制层，然后是视图层。换言之：互联网分层架构是CPU固定、数据移动的架构。MapReduce的架构是否也遵循这个架构特点？如果MapReduce也采用类似的分层架构模型：提前部署服务：Map服务层：接收输入数据，输出“分”数据，集群部署M=1WInstancereduce服务层：接受“合”数据，输出最终数据，并在集群中部署R=1W个实例。用户提交作业时：将数据传输到地图服务集群；地图服务集群输出结果后，将数据发送给reduce服务集群；reduce服务集群将结果传递给用户；问题是什么？在大量数据的网络传输上会浪费大量的时间。画外音：输入地图，地图减少，减少给用户。会发现“固定CPU，移动数据”的架构并不合适。GoogleMapReduce工程架构是如何思考这个问题的？为了减少数据传输量：(1)输入数据被分成M块后，master会尝试在输入数据所在的位置启动执行map函数的worker实例。在服务器上；VO：不需要网络传输。(2)map函数的worker实例输出的结果会被partition函数分成R块，写入worker实例所在的本地磁盘；画外音：无需网络传输。(3)reduce函数，由于有M个输入数据源（M个maps的部分输出可能对应一个reduce输入数据），所以master会尝试启动一个距离较远的执行reduce函数的worker实例这些输入数据源放在尽可能“近”的服务器上；画外音：目的也是为了尽量减少网络传输；服务器之间的“接近”可以通过内网IP地址的相似度来衡量。因此，对于MapReduce系统架构，“数据固定，CPU移动”更为合理。为什么是这样？互联网在线服务的特点是：数据总量大，吞吐量比较大，同时发起的请求数量多，处理的数据量比较小。用户对处理延迟很敏感。对于此类服务，采用“固定CPU，移动数据”的分层架构是合理的。MapReduce离线业务的特点是：吞吐量比较小，同时发起的任务数比较少。每个任务处理非常大量的数据。用户对处理延迟有很高的容忍度。对于此类服务，使用“固定数据，移动CPU”。层次结构合理。任何倒闭的建筑设计都是耍流氓。思考问题的本质，希望大家有所收获。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
