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

时间:2024-01-29 12:58:38

今天淘宝日照老师来公司做技术交流,交流的主题是《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。