Map/Reduce与中间结果理论

为什么80%的码农都做不了架构师？>>>   

Map/Reduce的真正实质不是高阶函数。它的真正实质是中间结果思想的应用。

当我把一个大型任务给系统时，系统只会把它当成一个任务。系统当然可以考虑把它切分，但这并不会在所有的情况下有效。因为系统并不了解也不能理解真正的应用。它的“智能”是非常有限的。在大部分情况下，系统将花费大量的内存来处理大型任务，并且由于算法设计上的缺陷，系统很可能还未到任务完成就遇到内存不足的情况（如果系统或程序未能做好或对当前的情况未做好充分的考虑---典型的，软件的最高要求内存高于系统实际拥有的内存）。总之，系统不是为超大型任务设计的。即使系统的确这样做了，总仍会具有它本身的局限性。特别是在很多大型任务不能够被通过小循环或尾递归来解决的时候，可能必须从任务本身去寻找解决方案。如把它人为地切分成多个很容易完成的小任务（前面说过，系统当然有时候，如果拥有足够的信息并且算法设计非常优良的时候，也能做到任务切分。但这并不代表所有的情况-----并且，如果我就是这个系统的设计人呢？这个时候，系统的任务切分能力来源很可能就只有我。如果我能做到，那么系统就能做到；如果我不能，那么系统就不能。。。anyway,,这里的意思是，中间结果作为一种思想，不管在哪里发生，它有着它存在的价值）。

其实尾递归就是用的这种思想。另外很多循环算法虽然可能设计者从来没考虑过使用中间结果，但系统也可能偶然地获得其效果。因为循环本来就是可以在其中使用中间结果的一个很好的代码结构。

使用中间结果对大型任务有巨大的好处：

1，中间结果的采用，使得任务被切分成多个对系统来说合理大小的子任务，这样的任务更容易被完成。这样的结果当然也意味着更小的系统风险。而更小的系统风险显然又意味着更高的系统稳定性；

2，中间结果的采用使得任务可以很容易地被部署到不同的地方去运行。因为被切分以后的小任务是独立的任务，而系统就是被设计成运行任务的，所以这样的切分毫无疑问为任务的分布式处理提供了条件；

3，中间结果的采用为任务拥有者提供了更好的了解任务运行状态的机会。因为中间结果的定义等于对任务的一种定义。这种定义的存在为任务的状态提示和控制，失败恢复，任务日志提供了一个非常好的切入点。因为它们是定义非常清楚的任务阶段。也因为这样，它实际上还可以算是一种对程序的语义升华：在提供这样的中间结果以前，中间结果只能存在于人的大脑中，而在系统中却没有任何形式化表示。而中间结果的提供毫无疑问为系统增加了一层形式化表示。这个形式化表示，为更高一层语义的存在提供了支持。因为根据形式化系统理论，语义必须有其形式化存在承载。

 

 

转载于:https://my.oschina.net/digerl/blog/34217