讲座笔记——《Ocean base结构化数据海量存储》

今天淘宝日照老师来公司做技术交流，交流的主题是《Ocean base结构化数据海量存储》（详见PPT）。这是Hadoop in china 2011上的一个topic，就讲座中的一些点做些笔记。

 

报告共分如下四部分：Ocean base介绍，Ocean base架构，Ocean base应用以及后续的发展计划。

Ocean base的数据模型和关系型数据库的数据模型很像，并非schema-free的，这和现在主流的nosql数据库大相径庭。数据模型分为主键和普通列，数据类型现在主要有四种（整形、字符串、日期时间，高精度浮点数）。

支持的基本操作有：

1.随机读取；2.范围查询；3.写操作（单行、多行、保证分区内事务）；4.filter,like,groupby,orderby,limit,offset，etc。

随机读取和范围查询都是针对主键的，针对其他列的查询没有提到，肯定是没有进行特殊的优化，因而即使支持想必也是不推荐的。

特点和适用场景如下图所示：

重点面向结构化数据，也是由taobao自身的业务场景决定；而且，伴随着互联网的进一步发展，结构化数据的量会越来越大，价值会越来越高；

随机读取请求最多一次磁盘IO，剩余的操作由内存操作(最多扩展为SSD操作)完成；

taobao的数据特点决定其数据需要强同步；

架构自身实现分库分表；

其特色功能是大表join支持，后续会进一步介绍；

适用场景只供参考，可能需要深入分析业务才能最终确定；

 

在线存储特点：

这部分是ocean base的设计切入点，也是其最初立项需要满足的主要应用场景；其设计中的考虑是把数据天然的分成两部分：基准数据，是累计数据，数量大，可以离线处理；增量数据，最新的实时数据，数据量相对较小；

在ocean base中，基准数据是放在chunk server中存储的，是在整个架构的第三层（接下来会看到架构图），增量数据是放在update server中的，是在架构的第二层（离用户更近，可以理解为另一种形式的cache）;

增量数据和基准数据定期merge（merge的原则由应用确定，时间 or 存储量，现在的常见应用一般是天级merge）.

 

ocean base架构

实际的架构相当于划分为三层，第一层是RootServer（主备，单点，相当于GFS中的master），第二层是UpdateServer（主备，同样是单点，这一层在GFS的架构中不存在，也是ocean base最重要的特点），第三层Chunk Server（多副本，相当于GFS中的chunk server，但这里存储的是基准数据，也就是历史数据，和GFS的chunk server不一样），MergerServer和ChunkServer在同一层，用来完成数据合并（merge操作是由ChunkServer发起的，从UpdateServer pull的数据）；

 

设计要点：

RootServer以tablet为粒度进行负载均衡，系统本身会对tablet粒度进行切分；本身是无状态的；

UpdateServer是系统中另一个单点，据介绍，taobao实际应用中，UpdateServer运行良好，并未成为瓶颈；优化点在于Group Commit，批量写操作，除了主备外，单机增加RAID，进一步保障可用性；

内存Copy-on-write B+ tree，实现零锁（需要进一步研究下）；内存+SSD转储

 

为了避免UpdateServer成为单点，对包括网络在内的模块进行了有针对性的优化，并采用了比较高端的设备（只有1台）；

 

针对多机房的支持，现在共有三个机房，杭州的两个机房使用光纤相连，有主机房、备机房的概念，运维团队有专门的工具用于主备机房切换，同时，系统有工具做流量配比；

系统的写入操作，需要主UPS，同机房备UPS，备机房主UPS均写入成功才返回，从而保证强一致性；

在做系统升级时，会停掉一个机房，流量完全切换到另一个机房，对客户程序透明；

RS主备使用VIP（virtual IP）保证可用性；

 

典型应用示例

PS：在听此讲座前，了解ocean base，说其典型应用是收藏夹应用，第一感觉是个很简单的应用场景，是否杀鸡用牛刀，今天听过讲座后，才知道看似简单的应用，在taobao这样一个平台之上，背后面临的复杂性，可以说，ocean base就是为了解决收藏夹背后的问题--大表join而定制开发的。

2010年数据

此前遇到的技术挑战是，每次收藏夹展示操作，都需要两张大表（收藏表+商品表）进行一次join查询，而每次join查询都可能涉及到上万次的磁盘随机读，简单的分表存储，在性能上是无法满足要求（单次查询响应时间<50ms）的。而将两张表冗余存储，由于商品有商品热度信息（如被收藏次数），又可能造成某个用户的收藏操作就造成数万次的更新。

现在用ocean base解决了这个问题，解决的办法是，在基准数据中对数据做冗余，收藏表同时存储商品数据，但在增量数据中还是分表存储。单次查询操作，首先在chunk server中做一次顺序读操作，然后在update server中做一次内存中的join，再把两次的结果进行合并，从而最终返回给用户。而定期将增量数据和基准数据做merge操作时，将收藏表+商品表进行了合并，生成冗余表存储。这样就避免了磁盘上的join操作，从而保证了性能。

针对大表join操作，需要提前设计好单表以及冗余表的schema以及对应关系，不支持join关系更改。

 

ocean base并非万能（双11的例子）：

针对PPT中给出的热门收藏的例子，需要业务方在计算结果做缓存，更好的利用ocean base。

 

ocean base后续发展方向：

ocean base，未来将着重解决可用性。

 

收获颇多。文章最后，感谢淘宝日照老师的报告，以及淘宝的open source。