关于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也许什么都不是.  

所谓设计模式和架构

  大致看了下关于bigtable和mapreduce的东西.
  
  想想,其实是google对于搜索引擎数据结构的一个解决方案吧.
  广泛一点说,是对于面向内容的分类的解决方案的.

  对于搜索引擎来说,主要有两个基础的数据:
  一是原始的抓取对象,表现为网页内容.
  二是对原始材料的分类信息,表现为关键字.

  bigtable对于这样的数据的处理,引入的是column family的概念.以传统的RDBMS理解的话,就是在url 和content列之后,有了一个不定数目的列数.

  仔细想想,换个方式理解,其实更简单.
  对于column family,更喜欢将其理解为tagging.

  因为搜索引擎本身承担着两种功能.
  抓取和分析.
  
  得到content之后,只要对其打上相应的tag便行了.

  如果要以RDBMS实现的话,便是简单地对每个关键字建立个表,然后指向相应的content内容便可以.
  而要依据诸多关键字定位page的话,也就是所谓的map reduce.

  先分类,在处理.
  也就是所谓的先map,然后再reduce.

  这其实就是分类处理的思想.

  而map很大程度上,跟集合有着天然的血缘关系.
  而搜索的目的就是在集合里找到特定的子集.
  于是,map > reduce > map > reduce...

  于是,纯粹从思想的角度考虑,bigtable和mapreduce不过是google对于搜索引擎需求的一个建模描述,或者说是基于内容个tagging技术.
  
  话说回来,有时候,所谓的架构或者模型确实是建立在需求之上的.

  软件产品脱胎于需求.
  而产品的架构,虽然某种程度上说跟需求无关.

  因为有着这么一个说法,就是说好的架构必然具有良好的扩展性.
 
  一种很理想主义的想法就是在设计出一个好的架构之后,无论需求如何变更,都能够适应.
  现在想想,这其实是本末倒置的误区.

  所谓的架构扩展性在于面对需求变更的时候,有良好的适应能力.
  其实质是,对于需求的变更,都能保证其跟原有架构设计的一些假设不会冲突.

  意思就是说,你的架构没有做过多的假设.
  比如对于一个这样的需求,偷菜写个函数.
  于是可能有这么些个实现:
   steal(vegetable)
   or
   steal(stealable)
   or
   operate(someting)
   or
   operate(onething,anotherthing)
   or
   operate( list onething , list anotherthing )
   or
   operate( list paticipate_1 , list paticipate_2 , ... )
   or
   getHandle(steal_vagetable).process()
   
   实际哪个实现取决于你做了多少假设.
   也就是说粒度细分到什么程度.
   
   而此时所谓架构是否有良好的扩展性,就在于,新需求会将粒度缩放到哪个程度.
   一旦细化的粒度小于当前架构的粒度,也就是架构不适应需求了.

   所以,最好的架构其实是没有架构.
   即不做任何假设.
   getHandle(steal_vagetable).process()

   这其实又是一个螺旋式的回归.