分类： 服务器与存储
2008-09-17 15:11:22
存储云的商业模式是出卖存储能力，而计算云的商业模式是出卖计算能力。存储云的基础技术是分布存储，而计算云的基础技术是分布计算——更准确说在是“并行计算“。 并行计算的作用是将大型的计算任务拆分，然后再派发到云中的节点进行分布式的并行计算，最终再将结果收集后统一整理（如排序、合并等）。 如果说云计算云是并行计算的升华的话，那么只在一个层面上有所进步 —— 计算资源虚拟化：计算云中的所有计算资源都被看成一个可分配和回收的计算资源池，用户可根据自己的实际需求购买相应的计算资源。
这种资源虚拟化得益于近日重新兴起的虚拟机技术，采用虚拟机实现资源的虚拟化，既可以避免了硬件异构的特性（无论什么样的硬件机器主要攒在一起，其计算资源都可被量化到计算资源池中，并被动态分配），更可以实现资源的动态调整，因此能极大的节约了云中的计算资源（动态调整就是不需要重新启动系统就可调整资源大小，这是虚拟化技术的最大用处之一）。这种虚拟化和我们在自己机器上安装的虚拟机所采用的虚拟化技术大同小异，其异处就在于我们个人用户的使用模式是将一台物理机器的资源虚拟化成多份，以使得其能同时启动多个操作系统；而云中的虚拟化技术是将多个物理机器的资源虚拟化成一个大的资源池，让用户感觉是一个巨大资源的机器——但是要知道只有任务在能并行计算的前提下，资源池虚拟化才有意义。比如用100个386机器组成的计算云可以处理1T的日志数据，如果日志数据的处理可以被并行进行，那么可让每个386机器都处理1／100T的数据，最后将所有中间结果合并成最后结果。但是如果任务无法平行差分，再大的计算池也没用（云计算应用是有限的，目前最能用的上的是web网站——数据量大，但处理相对简单）。
总而言之：计算云的架构可以看成是：并行计算＋ 资源虚拟化。
对于资源虚拟话的问题，这里不作讨论了，有机会我们专门起个话题进行深入探讨。这里主要说说云中的并行计算方式。并行计算是个老话题了，很多基于MPI的并行计算软件处处可见。MPI采用任务之间消息传递方式进行数据交换，其并行开发基本思路是将任务分割成可以独立完成的部分，再下发到各计算节点分别计算，计算后各节点将各自的结果汇总到主计算点进行最终汇总，各点之间的的交互由消息传递完成。对于并行计算面临的主要问题是： 1 算法是否可以划分成独立部分；2 获取计算数据以及中间结果存储代价很高，因为海量数据的读取会带来沉重的IO压力——如在处理诸如page rank等互联网应用上，很大程度上大量、频繁的读取分布存储的网页数据造成了任务计算速度的瓶颈。
对于第一个算法问题，从计算架构上考虑勉为其难，关键在于分割算法。而对于第二个IO压力问题，最好的解决办法莫过于Hadoop项目项目所用的Map/Reduce方式，其思想很简单，就是将计算程序下发到数据存储节点，就地进行计算，从而避免了在网络上传输数据的压力。这并非一个创新思想，很久之前就有诸多尝试（比如IBM曾经搞国一个叫Aglet的移动代理项目，就是将计算程序下发到各节点计算和收集信息），但对于海量数据处理的今天这种方式无疑最具吸引力，代价最小。
简单说Map是一个把数据分开的过程，Reduce则是把分开的数据合并的过程。如Hadoop的word count例子：用Map把[one,word, one,dream]进行映射就变成了[{one,1}, {word,1}, {one,1}, {dream,1}]，再用Reduce把[{one,1}, {word,1}, {one,1}, {dream,1}]归约变成[{one,2}, {word,1}, {dream,1}]的结果集。 关于Map/Reduce的抽象方法是map/recduce的精髓之一，但本文不多说它了（你可参看函数语言或其他种种资料，这里不在赘述），本文主要想谈谈Map 的数据来源问题。
Map 的数据来源初看也并非什么问题，无非就是读本地数据而已（前面已经说过计算程序作为map的回调算子——借用java的说法——被转移到了数据所在地再执行）。然而具体在海量数据处理的应用场景下就必须考虑和分布存储系统搭配了。 Hadoop的搭配方式最简单，就是和其下的分布文件系统DFS配合: 通过文件系统的原数据来定位文件块的分布节点位置，然后将回调算子下发到其上，已顺序读取的方式从本地文件系统上读取数据。对于日志文件分析等应用，上述做法效率很高，因为日志文件读取可是顺序读取，文件系统的预读特点可充分利用 —— 离线日志分析是利用map/reduce分析的典型应用。
但我们也应看到Map/Recduce 的使用也有明显的局限性：第一是，如果对于较为复杂的输入要求，比如需要对数据集合进行query查询，而非顺序读取文件的输入，则不能直接使用Hadoop的Map/Recduce框架；第二是，其下的分布文件系统为了一致性考虑，不支持多个并发写，而且写后不能修改，这些特性对日志等事后分析效果不错，但对于数据需要实时产生的场景有些勉为其难了。因此考虑是否能将Dynamo，甚至是Bigtable等分布存储系统或者分布类数据库系统在Map/Recduce环境下使用便成了新的需求。不过我感觉Bigtable的存储结构似乎不大容易实现在本地环境内完成进行较为复杂的查询（比如多列的符合查询，不一定能完成，且更不容易在本地完成——应为它无法避免到远程取数据，而如果一旦跨机器进行查询则又带来了过多的网络I/O，违背了Map/Reduce架构进行并行计算的设计初衷。那么Dynamo是否可满足负责query需求呢？ 如果采用上文在查询时提到的方法：给记录定义对应的schema，并存储在存储点上将其存在传统的关系数据库中（可以在需要列上建立索引），那么将“回调算子——这里就是query语句了”下发到其上，则可按照传统方式在本地进行query！这样以来既符合了Map/Reduce的初衷，又能满足复杂输入需求，同时还能不影响数据的实时产生。因此我认为灵活、方便的并行计算架构可以由Dynamo或其变种存储系统（如上文所说的partition方式）＋ Map/Reduce完成。
目前云计算中的各种子系统可谓风起云涌，层出不穷。我这里简单提及几个我了解过的项目，大家有兴趣的话可重点跟踪它们，近一步了解云计算知识。
1 Bigtable /Dynamo 上文已经讲过了。
2 Hbase 是Hadoop的一个子项目，类似于Bigtable , 最适合使用Hbase存储的数据是非常稀疏的数据（非结构化或者半结构化的数据）。Hbase之所以擅长存储这类数据，是因为Hbase和Bigtable一样，是列导向的存储机制 3 Couchdb 是Apache下的一个面向文档存储，由Erlang开发而成，和其他新型存储系统一样它同样是分布存储系统，具有很好的扩展性。但不同在于没有任何统一的schema可言，数据组织是平坦的，无行无列。如果需要查询等操作，则借助于用户自己提供的聚合与过滤算子，以Map/Reduce方式进行对文档信息进行全文检索处理——这个角度上说它也能实现类似数据库的查询，可方式方法完全不同——但它提供了一个view的数据关系逻辑接口，对用户而言，可以想象成传统的表。
4 Simpledb 是amazon公司开发的一个可供查询的分布数据存储系统，它是Dynamo键值存储的补充和丰富，目前用在其云计算服务中。其具体实现方式没有论文公开。
5 Pig 是yahoo捐献给apache的一个很有趣项目，它不是一个系统，而是一个类SQL语言, 具体目标是在MapReduce上构建的一种高级查询语言。目的是把一些运算编译进MapReduce模型的Map和Reduce中,允许用户可以自己的功能. Pig支持的很多代数运算、复杂数据类型（tuple,map)、统计运算（COUNT，SUM，AVG，MIN，MAX）和相关数据库检索运算（FILTER，GROUP BY，ORDER，DISTINCT，UNION，JOIN，FOREACH ... GENERATE）
