Big toy for boy!

前些日子拖着病躯参加了一个北京的Hadoop User Group聚会，可以用“不虚此行来”形容。见到两位大大：负责Facebook总部backend工作的Shao Zheng和Yahoo北京研发中心首席架构师Zheng Hao。他们分别对各自在hadoop上面的工作做了介绍，让我们了解到Facebook, Yahoo使用hadoop的情况。

Hadoop是一个apache基金的项目，表面上来看是实现一个开源的GoogleFS BigTable，实际现在已经发展得有自己的特色并且希望能解决更多的应用问题。

Hadoop目前多用于后端数据统计分析等工作。此类工作的特点是数据量大，计算量大；数据写入后不变化；读取数据时多用顺序读取，很少使用随机读取；需要快速计算得到所需要的结果。

目前硬件环境的瓶颈主要在于磁盘I/O，所以利用分布式计算来进行并行计算，提高计算效率。为此，数据存储下来是不移动的，每台机器负责自己拥有的部分数据计算，这样在这上面就要实现MapReduce。

何为MapReduce? 如果你熟悉Linux下的指令的话，也许你曾经为了统计已经用过下面的命令：

“cat 日志文件.log | grep 检索条件 | sort |uniq -c > 输出”

这就是MapReduce的本质，只是将上面的步骤分拆到不同的机器同时运算而已。

Hadoop有几个子项目，分别处理不同的细节问题。Shao Zheng负责的是Hive，它是Facebook提交并维护的一个基于Hadoop的简易查询语句转换器。实际上可以理解为SQL on top of Hadoop。Zheng Hao介绍的Pig是Yahoo编写的查询语言，也是用于Hadoop中的数据查询。两个子项目都是为了将用户的查询需求变成MapReduce然后再进入Hadoop进行实际的运算。只是前者将通用的SQL来进行转换，后者使用自己定义的一套查询语法来查询。各有千秋。

我非常喜欢老外的思路，Hadoop项目组认为，效率不是问题，先要将思路走通。假设整体架构是可行的，如果那个地方有效率问题，采用不同的技术、硬件或者算法可以改善，那么整体系统都会得以提升。所以我也认同不要有事儿没事儿就批判Hadoop效率不行。起码这个项目一直在进步，有很多人参与进来贡献自己的力量，比起一个深思熟虑解决好效率问题几个苦力完成的私有解决方案要强大得多，三个臭皮匠还能顶一个诸葛亮呢。莫要忽视开源社区的力量，现在Hadoop的问题大家都能看到，每个人都在想办法解决，因此它会越来越好的。

Hadoop不是万能，我建议大家刚接触这个项目的话就将它应用于统计分析或类似的应用，如果你对Hadoop不是很熟悉的话，暂时不要尝试想Hadoop还能做什么这个问题，因为我认为在整体架构和社区任务计划不了解的情况下，很难做出这样的判断。很容易得出Hadoop不好，Hadoop不好用的结论。这些事情还是交给Hadoop解决方案专家或者顾问来做比较好。

废话了这么多，算是我自己的发泄，贴张聚会的照片，看看我在那个位置？

最近在做一些调研工作，查看了BigTable以及Hadoop的一些资料，并且结合自身需要开发的项目，得出了一些领悟，可能并不是对的，但是自认为还是有一定道理，先在此记录下来，稍后逐条论证。在此我仅假设我们构造的是普通的Web应用，类似论坛系统这样的东西，其实很多系统都可以往这个方向靠，可以认为他们是类似的。那么这样的系统我们未来主要考虑如何能承载更多的用户访问，如何能做到可扩展和稳定以及分布式、异步数据同步等细节。ok，在这个前置条件下，我觉得：

改变原有的数据操作思路，数据根据特性来划分，放弃关系型数据库。数据可以分成下面的类型

1、 一次创建，后续只读，更新会写入新的版本，旧版本删除（key,data,timestamp）
帖子、附件或贴图、用户信息、用户访问日志数据

2、 创建后数据会频繁被更改，写操作针对单条记录做事务性操作（锁机制）
主题信息（回帖数，最后回帖时间等）、论坛版块信息（主题数等）

3、 需要保证唯一的数据单元（锁机制，分布式后的唯一性）
主题编号，帖子编号等

 第一类数据使用基本的数据同步机制，根据时间戳进行增量同步就可以保证数据一致。被同步节点只是会存在数据延迟，中间丢失数据可以使用脚本检查完整性。

 第二类数据原则性统一存储不做分布处理，为了提高每个节点的响应，可以使用树形结构部署，中心节点负责核心数据写操作，镜像数据同步至节点并设定只读。

也可以将数据写操作分布在不同接点，但只记录对数据的操作范围（加xx，减xx），数据基础通过中心接点定期汇总下放各个节点，节点收到更新数据基础后更新，用户便可以查询到相对实时的数据了。

其实可以将此类数据更加细分，一般数据没有这么高的准确要求，例如总帖子数据、帖子访问数等，此类数据通过第二种方法分别在每个节点读写，中心只是负责汇总数据将系统总数据下放至各个节点。目前只有类似积分这样可以添加或消费，并且有并发可能的、需要处理事务的数据，才需要严格的处理，此类数据很少，足可以将其集中管理，在中心节点出现问题时，停止消费操作（扣减操作），对于增加的操作可以在每个节点记录日志，待中心节点恢复后再做异步处理。

 第三类数据分显性和隐形数据，显性是指要给用户查看的，并且用户参与指定的（例如用户账号名），此类数据只确定一次后期只有读操作，因此绝对集中存放，集中申请。隐形的数据类似帖子编号等，此类只是要保证系统内唯一，但是是什么值对于用户来讲无所谓，因此此类数据可以根据每个节点的名字空间来区分，名字空间内使用程序自我保持不重复性。

也许上述内容是我特定工作环境下的问题，如果正巧你也在思考这些问题，欢迎与我联系讨论！