关于Hadoop

  在hadoop里写了点东西,大概也印证了有怎样的环境才有怎样的解决方案.

  确实,在hadoop里,不像在一台机器上,能比较容易的mutex操作.
  毕竟,你要mutex 的东西都不知道物理上在什么地方,甚至还存在不存在.
  所有,这个是思维要转变的地方.

  在分布式情况下,有时候create比read/write来得更浅显易懂.
  毕竟,除了delete操作,其他操作都不会影响create的行为.
  而且,当delete操作也依赖于create的某些标志性行为的时候,一切都简化到create操作上了.

  比如,要进行任何操作,先create一个标志,表明holding了这个resource.
  
  当然,这中间也还是会有些问题的.
  比如,在hadoop里,这依赖于namenode操作的正确性.
  
  某种程度上说,这种解决方法其实是利用了namenode的单点性.
  由于所有对hdfs的操作都需要汇总反馈到namenode上 ,所以,用namenode去拦截调度也是很容易想到的思路.
  毕竟,所谓的一致性,是由namenode保证的.

  但是,如果是纯粹的对等网络呢?
  比如,没有namenode的?

  其实最后还是会归结到这种有中间节点的模型上.

  比如hadoop准备改造的mapreduce模型.
  实际上就是去掉的jobtracker的这个单独的job调度节点,把它分散到开来.

  也就是实际上来所,是在tasktracker上vote一个节点作为某一个job的jobtracker罢了.

  这其实有时典型的分层思维.
  跟ip地址的掩码模式差不多.
  加一层即可虚拟出许多隔离的东西出来.

  resource manager就是这个新加的一层.

  所以,从这个程度上来说,也许并没有纯粹的对等模型.
  多少还是有一些中心节点的.
  只不过这种中心节点的特殊性不强罢了.

  就像人的选举一样.
  本质都是差不多的.
  只是由于某些原因变得有些特殊罢了.

  所以,平等这个东西,首先是建立在公平之上.
  没有公平,也就没有平等.

  话说回来,hadoop或者说map reduce这个东西,也许又是Google重新修饰了一番的东西.
  就像Bigtable的概念一样,重新包装了下,以不太直观的形式描述一个很简单的模型/思路.

  mapreduce其实就是把计算分摊到各台机器上罢了.
  即使不用hadoop,写个脚本自己分块数据自己计算汇总也是可以的.
  只不过hadoop本身解决了分块的问题.

  而所谓的map/reduce过程,则多少有些无谓?
  毕竟,redcue本身其实也是一种map过程.
  至少从hadoop的实现上来说,是这样.

  而且,hadoop本身似乎也是这么认为的.
  这个从job的combine设置以及,不显式设置reduce数目的时候,job的行为可以看出.
  
  本质上说,hadoop的reduce过程只是map的特例.
  所不同的是output出来的数量分块比较少.

  当然,从编程接口上来说,reduce跟map的区别在于,reduce是key的一个汇总.
  但其实这是map output的sort使然.
  reduce也不过是根据output结果去取罢了.

  所以,其实mapreuce本质上就是一个数据格式的转换问题.
  只不过被放到到了分布式的情况下.
  多了调度和同步的问题.

  除开这些,mapreduce也许什么都不是.