粗看WASP ：Alibaba的海量数据分布式数据库探索
- WBOYオリジナル
- 2016-06-07 15:17:281092ブラウズ
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的实现，自身能力有限，所以不保证以上看法的准确性，如有偏差还请指正。