email：colorant at 163.com blog：http://blog.csdn.net/colorant/ == 是什么 == wasp 是阿里集团开发的基于 hbase 的一个数据库方案，其根本出发点是仿效 google 的 megastore ，“在hbase系统上不牺牲线性拓展能力的同时又能提供跨行事务、索引、sql的功
email：colorant at 163.com
blog：http://blog.csdn.net/colorant/
==是什么 ==
wasp是阿里集团开发的基于hbase的一个数据库方案，其根本出发点是仿效google的megastore，“在hbase系统上不牺牲线性拓展能力的同时又能提供跨行事务、索引、sql的功能”
==架构原理 ==
其设计原理可以参考megastore的相关论文，wasp自己的相关设计使用文档可以在下面两个地方找到
https://github.com/alibaba/wasp/wiki/chinese
http://wenku.baidu.com/view/c85f50d984254b35eefd345c.html
megastore框架的核心思想是将数据分割成不同的entitygroup，entitygroup的数据备份是跨datacenter存放的，在entitygroup内部提供完整的acid支持，保证数据写操作在所有数据中心的同步备份。
从具体实现上来看，wasp并没有实现megastore在跨data center方面的相关设计思想，仅仅只是采用了entity groups这样的方案来划分和管理数据。
megastore在很多设计上都是围绕超大规模的数据的并发这样一个核心思想，比如entity groups的跨地域备份，读数据时非主从式的平等节点由paxos动态选主的思想等等，都是为了保证读操作时的去中心化，以提高性能，而wasp的架构方案更像hbase自身的方案，存在fmaster节点和fserver节点，通过zookeeper确定当前fmaster，每个fserver管理若干entity groups，基本还是固定的主从中心式的。在entity group的使用上，wasp则基本保留了megastore的原始设计，通过redolog / mvcc / 跨entity两阶段提交等方式解决并发读写的一致性问题
==具体实现 ==
wasp使用alibaba自己的druid项目实现sql语法的解析，采用netty和protobuf构建服务器内部通讯协议框架。
wasp的数据主要映射为hbase上的4类表，全局的 _fmeta_ 表记录所有wasp表的meta信息，每个wasp表数据对应的entity表，相同entitygroup key管辖下所有表对应的redolog表，以及索引表。
目前wasp对sql的语法支持还很简陋，以query为例，仅支持equal condition和索引上的compare类range condition。对int等数据结构的支持，在比较操作中也存在bug，其它稍微复杂一点的sql语法，如udf，limit, having, group by, join, order by 等等操作目前都是没有的，当然这可能也取决于wasp的具体应用场合，或许只需要最简单的equal和特定字段上的range condition类的查询。
此外从sql plan实现的角度来看，似乎目前只是简单的转换为get/put/delete等hbase操作，以hbase的角度来看是纯粹的客户端应用程序，没有使用任何hbase rs端的能力，如filter,coprocessor等等加以优化，因此如果要实现aggregation类的功能，在性能上大概会受到比较大的影响。
==总结 ==
总体看来，wasp并不能提供一个海量数据跨数据中心的解决方案，其规模受单个hbase cluster所限，因此一定程度上来说和megastore所解决的目标问题还是有很大差距的，wasp更多的是在hbase之上提供一个增强的方案，提供简单的sql接口，和跨行事务的支持。如果光从sqlon hbase的角度上看，与saleforce的phoenix有很大的差距。但在跨行事务支持方面还是优于phoenix的（phoenix的在事务方面的支持几乎完全取决于hbase自身的能力），代码功能等目前看来还不成熟，还要看将来的发展情况。当然，从代码框架，设计模式等方面上看，作者的编程功力还是很不错的，要学习。
我只是快速的了解了一下wasp的实现，自身能力有限，所以不保证以上看法的准确性，如有偏差还请指正。