首页>会议文档 >

小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践

page:
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践
小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践

小米科技 林尚泉——小米结构化存储系统及融合云平台的设计与实践

所属会议: 2017 OpenStack Days China会议地点:北京


下载

手机看
活动家APP客户端

扫二维码下载
或点击下载
Android iOS

10761次
浏览次数

文档介绍

林尚泉:我是来自小米的云平台的工程师林尚泉,下面我来给大家介绍一下小米结构化存储系统以及融合云平台的设计和实践。这个是今天的演讲大纲,比较简单。结构化存储是一个分布式NoSQL数据库服务,对标AWS DynamoDB,我们的目标是要把它做成一个弹性可扩展、高可用、低延时、稳定可靠的数据库服务。

演讲实录

林尚泉:我是来自小米的云平台的工程师叫林尚泉,下面我来给大家介绍一下小米结构化存储系统以及云平台的设计和实践。这个是今天的演讲大纲,比较简单。结构化存储是一个分布式NoSQL数据库服务,对标AWS DynamoDB,我们要做成一个弹性可扩展、高可用、低延时、稳定可靠的数据库服务。先介绍一下项目的背景,HBase是小米用的比较多的,但是用着就发现了一些问题,包括一些配置还有客户的验证等等,还有支持java多语言支持的不太好,到后面我们还要支持生态链公司的一些结构化数据的存储,所以我们需要在公网里面提供访问,HBase在公网直接提供访问也不大方便,所以我们就做了这套服务,它是基于HBase的,对外提供一个无状态的公网访问,简化了客户的配置,支持多种主流语言的SDK,也为一个集群多个用户一起用,还有一些多住户的概念包括访问控制和流量控制,并且还在原生的HBase上做了一些功能扩展,因为延伸的HBase是只支持主件上面的索引,没有二级索引,也没有数据类型的概念。我们在上面做了一些功能扩展,包括数据类型、二级索引、还有软删除和数据冷备等等这些功能。现在这个服务不仅支持了小米内部业务,包括小米网等等,还支持了十几家生态链公司的结构化存储的业务。看一下应用规模,我们在全球,在北京天津美国新加坡都有相应的集群,机器规模一百多台,支持的业务数二十几个,数据量一百个TB还有数千亿行,前端时间统计现在是以每两个月翻倍的在增长,现在单集群的QPS大概是几十万级别。

这是结构化存储一个典型的部署,分为储备结构、底层是Oookeeper等系统,主机群使用SDS盘,在HBase上面那层我们封了一层libsds,主要对HBase做了一些功能拓展,在libsds库上,我们是直接对外提供服务的,上面做了一些框架,支持多源SDK,还有流量控制等功能。主集群是直接供用户的线上访问,备集群除了充当主集群之外还会给主集群跑一些业务。下面首先介绍一下libsds库,主要做了一下的功能扩展,一个是规范化的数据模型,还有一些数据类型的支持,还有局部索引以及二级索引,下面分别介绍一下几个功能,规模化的数据模型意思是在libsds内层,这个图就是对应HBase的,还支持了多种数据类型,包括五各种常用的集合类型等等,我们的编码采用了HBase8201和SQLite编码方案,会保证跟原来的数据类型的顺序是一致的,还可以支持逆序。

介绍局部二级索引,这种二级索引是实体组内部的索引,索引数据是跟原数据存在同一张表上的,我们实现了个基于表达式的前缀分割,确认保证同一个实体组件里面的数据是在同一个HBase里面,并且不能被split的,这两个图刚才介绍过,一个是原数据的,我们间了局部索引,除了写原数据还会加一行索引数据,就是下面这个任意的HBase是实体组件到索引件再到组件,可以看到原数据和索引数据的实体组件是一样的,然后根据我们实现的前缀分割就可以保证原数据和索引数据在同一台机器上,然后就可以比较简单的去保证这两个数据的原始性。我们是通过HBaseCoprocessor来实现indexObserver,也就是客户发布了Put为以后我们会拦截这个操作,然后再计算要上出来索引,再把它放到原来的数据里,最后再同一台机器上一起落,就可以保证原数据和索引数据的原始性。

还支持了多种类型的局部二级索引,其中包括EAGER类型,也就是更新纱橱时同时删除失效索引,是适合写少读多的场景,而LAZY索引是读取判断索引有效性,更新时不做额外操作,适合写多读少,还有IMMUTABL五是需要用户保证数据的只读性,就适合以只读数据的一次性写入,读写都不需要做额外的判断,这种比较高效。

还支持了全局二级索引,和局部二级索引不一样的地方是它的索引数据是用一个单独的HBase表达出来,我们采用了谷歌的percolator实现的,是实现了这套算法叫Themis,这个已经开源,这个算法可以保证跨表更新的原始性,Chronos为全局单调递增时间戳,全局二级索引数据对应的HBase是跟局部二级索引不大一样,是以索引排在最前面,再到实体组件和组件,我们对局部二级索引和全局二级索引做了一下性能对比,这个图是对某一张表建立了一个全局二级索引和局部二级索引,然后再写,红色是局部二级索引,蓝色是全局二级索引,可以看到因为全局二级索引会涉及到分布式的,可以看到性能损耗比较大,局部二级索引比它有个四倍左右,而读的话同样局部二级索引好个两倍。

另外我们实现了stream功能,如果开了这个功能,用户对表的修改除了在原来的数据上写,还会封装在那个消息里再写一份,定期扫,再把那个消息打到流失消息队列里,用户就会拿到流失消息队列来消除这些数据,其中包括两种类型,一个是RECORD IMAGE,是这行数据被修改以后最后的视图,用户拿着这种类型的消息就可以做一些最终一致的增量对分,另外是MUTATE LOG,就是每一行的修改日志,这种类型再结合一个定期打快照的功能,就可以把指定某一个表恢复到历史任意一个时间点。

ThriftServer主要对外提供一个无公网的访问,对外评比了HBase,用户只需要拿到一个域名就可以直接访问,简化了验证和配置,支持了多种语言的SDK,多住户包括全程流量控制。我们采用了脸书的方案,对外屏蔽了一些复杂的配置,由于是使用了ThriftServer框架,很方便的可以支持多种语言的SDK.ACL功能,我们是在HBase那里存了一份原数据表,它的格式是某一个表有哪些ACL信息是存在一个表里面,并且每一个节点会做本地缓存,假如有用户发了一个修改,这个ThriftServer不仅要更新要,还要在Zookeeper修改每个节点,因为所有的ThriftServer节点都监听了Zookeeper的节点,就会打一个通知进行更新,通过访问原表更新本地。流量控制,SDS支持用户每一个表进行预设置的读写quota配额,设置读写配额的时候SDS会检查一下集群的能力,集群的能力是根据我们的一些性能测试得到的,做限流的时候是基于token bucket算法进行限流的,集群能力使用到80%的时候会提醒我们进行集群扩容。还实现了软删除的功能,因为要保证数据安全,软删除就是用户发一个商标请求,要删除一张表的时候,SDS后台会先对这个表打一个快照,然后再去删除这个表,这个时候会存一个snapshot五文件,在delete稳健的时候,用户可以通过restoretable为里面把表cloneshapstrt的,而数据冷备我们实现了一个工具,是可以把HBase一些snapshot推的,需要的时候再拉下来。结构化数据存储系统当时介绍了,我们来看一下融合云平台,这个是小米融合云平台的控制台的首页,可以看到它除了刚才介绍的结构化存储之外,还包括的文件存储,团队管理,流失队列和深度学习等等的一些服务,我们的愿景是把它打造成一个闭环的并且是比较闭环的计算集存储于一体的云服务平台,更好的给小米的用户和生态链公司进行服务。

然后用户要访问上面的任何一个服务都要通过团队管理,然后自己去申请一些team等等,这个是我们融合云平台的架构图,中间主要的服务是Zookeeper、HDFS、HBase等等服务,在上面有SDS、FDS、EMQ,还有其他队列等等,外围有一些公用的组件就是部署服务,我们为了方便我们集群的管理还有一些升级部署,我们开发了一套公用的部署系统,所有的部署都是通过云和云的部署系统,还有一套公用的报警系统,并且用户访问的时候都要通过团队验证管理提供一个统一的验证入口。下面来简单介绍一下三模块,融合云通过一个CloudManager进行了团队验证管理模型,用户可以对CloudManager发一些团队请求,生成一些请求,就会把请求存起来,比如用户要访问我们的结构化存储或者文件存储的服务,如果前端过来的请求,前端首先会把这个请求转化到CloudManager这个模块,CloudManager经过验证以后会从MySQL读出团队信息,再放到前端里面再转化。如果通过SDK直接访问service,要通过验证才能访问,具体是service调API,这个Restful API会有一些用户团队信息,service再把这个解密,算一个签名出来,再做对比。融合云的部署系统是使用了我们小米发的Minos2.0,1.0已经开源,2.0实际上是在1.0的基础上增加了一些验证授权的模块,主要包括Tank管理服务器,集群每一个节点都用supervisor监控,提供了工具来给用户做集群的升级等等,这些操作都需要经过CloudManager进行认证,主要是为了保证只有集群的或者对这个集群有相应的权限的用户才可以进行相应的操。

因为提供了一套统一的监控告警系统,小米其实在运维团队也开发了一套open的英文告警系统,为什么自己还要再搞一套?因为那套在公网访问是不太方便,因为我们这一套系统需要跟很多的用户一起用,并且那套是使用RRD来保存,不保存原始数据,我们的很多用户是有这个需求的。更重要的一个原因就是我们需要为用户来监控其他资源其他服务上面的一些指标提供一个统一的入口,例如用户用了结构化存储还有文件存储等等,这些服务上面的资源的指标都可以通过我们统一的监控告警系统来进行统一的监控。

它的主要架构是这样的,用户是可以直接往我们的监控告警系统service发请求,包括两种,一个是推送指标或者查询指标,这种请求在service直接专发到OpenTSDB,再对这些指标进行保存,OpenTSDB支持数据的下沉聚合,另外一种就是对指标监控要定植一些告警规则,如果用户可以把这个告警规则的请求发到service,Thrift service把这个规则存到SDS,告警用户模块是对用户每一个指标都要过一遍,根据用户定制的告警规则看有没有触发告警,因为需要有一些指标的内存状态,所以就需要保证同一个指标必须发到模块的同一个节点上,另外还有一个Collector模块,把我们所有小米融合云里面的纸服务的指标,就是用户关注的指标统一收集然后推送到我们的监控告警系统给用户做统一监控。我今天的分享就到这里,谢谢。

×

打开微信扫一扫,分享到朋友圈