阿里云智能事业群
数据库产品事业部技术总监,MongoDB中国
用户组杭州
用户会(叶翔)为大家深度剖析了Re
dis和MongoDB云
数据库的技术。
分布式:需要满足企业
快速成长和降低成本的需要,实现弹性扩容,以及从主从模式变为集群模式。
兼容性:兼容性是永恒的话题,即使无法做到100%一致,但需要无限接近。
安全审计:安全在云环境中越来越重要,Re
dis开源版的安全审计能力比较薄弱,阿里云Re
dis对于这一点进行了加强。
数据同步:需要能够
支持混合云部署,使得第三方云厂商、IDC与阿里云实现互通,以及数据迁移和转换,满足客户上云或者下云的灵活决策。
Re
dis原生的Cluster架构采用了Gossip协议实现路由表的同步,但这种架构在社区以及企业中并没有
快速流行起来。虽然其有无中心架构、组件依赖少等优点,但也存在很多问题,如运维困难,路由存在不确定性,需要依赖Smart Client,并且
不支持Multi-Key以及从主从模式迁移到集群模式,进而造成
升级困难。
为了
解决上述问题,阿里云Re
dis数据库没有采用Gossip协议,而是引入了新的两个组件:Proxy和Con
fig Server。阿里云Re
dis采用了配置中心对于路由表信息进行管理,可以通过Con
fig Server进行智能化调度,Proxy则能够兼容非Smart Client,
支持Multi-Key,并能够实现流量管理以及读写分离等。Proxy和Con
fig Server虽然带来了架构的复杂性,但管理大规模复杂架构正是云厂商所擅长的。此外,这两个新组件所造成的额外成本也会被削平。通过这样的云服务架构使得
用户能够将Re
dis从主从架构无缝迁移到集群版本。
随着Re
dis Cluster云服务架构的延伸,出现了
一个新概念——
Redis云数据库企业分布式矩阵。这个矩阵能从纵向和横向进行扩展,纵向能够随着Shard的
添加进行分片,从而实现弹性扩展;横向则能够实现读写分离,并且做了Group分组隔离。全局来看,还
支持Memcache和Re
dis双协议,并且能实现集群、主备之
间的平滑切换。
阿里云Re
dis的Proxy引入了Connection Session的概念,能够对于Connection实现更细粒度的管理,并且通过连接池实现了长连接复用,不仅能够兼容多种协议,并通过C语言高
性能代码也提升了短连接的
性能。阿里云Re
dis的Proxy还具有热
升级能力,能保证在服务不间断的情况下
升级版本。
阿里云Re
dis在整个数据链路上进行了逐层加密处理,
支持了SSL、白名单、权限管理以及关键命令的禁用和审计等,增强了Re
dis的安全审计能力。Re
dis还提供了一些免费的开源工具,如同步工具Re
disShake以及数据校验工具Re
disFullCheck等。
而Re
dis作为内存型的缓存服务也存在很多挑战,比如容量受限,成本较高以及持久化能力弱等。基于以上问题,阿里云提供了混合存储的Re
dis版本,其目的在于为
用户提供持久化、可安全存储的Re
dis服务。其实现依赖于底层的RocksDB,通过不断同步冷热Key,使得内存处于可控范围之内。
MongoDB作为企业级
数据库需要关注四个方面,即安全审计、备份恢复、数据同步以及弹性伸缩。MongoDB的安全审计与Re
dis基本一致,进一步
增加了TDE加密。MongoDB
增加了物理备份,使得备份和恢复效率都有了大幅度提升,并且通过增量备份能力使得数据能够恢复到任意时间点。此外,在备份的基础之上,阿里云MongoDB还提供了备份验证能力。
阿里云MongoDB还提供了诊断分析能力,并提供了MongoShake工具对数据进行同步。阿里云MongoDB基于RocksDB引擎实现了共享存储
解决方案,可以实现存储弹性伸缩,秒级
添加只读节点,并
解决了oplog全局锁问题。当然,这样的方案也面对着几点挑战,如与WiredTiger的兼容性问题;Compaction带来的
性能抖动;以及共享存储延迟稳定性。
基于MongoDB的数据中台技术实现
MongoDB大中国区首席架构师唐建法为大家介绍了基于MongoDB的数据中台技术实现。
如果企业业务需要对接不同的客户数据,而这些数据的结构、类型各不相同,可能需要花费数周甚至数月。很多已有的
解决方案就是实现数据统一平台,将所有数据通过ETL抽取到数据平台上,这种方式的共性是“T+1”的方式批量采集汇总,做成数据集,以交互方式提供下载。但这种方式存在着平台数据滞后、响应速度慢、交互方式粗糙等问题。
数据中台从技术的角度进行定义就是“数据统一平台+数据即服务能力”。数据来源于业务,需要按照“T+0”方式采集,提供及时的数据。数据需要以API的服务化方式交付出去,而非打包。这使得数据中台能够对企业赖以生存的操作型系统提供
支持,相比于分析型业务,操作型业务更加核心,更加能够提高企业竞争力,这也是数据中台火爆的原因。
数据中台的定义就是包含企业实时全域数据的,主要面向操作型业务应用为主的数据服务技术平台。其概念起源自国内,存在众多流派,众说纷纭。咨询公司说数据中台是一种组织架构的转变,方案提供商则说数据中台是像Hadoop一样的技术平台产品,不同的组织有不同的出发点。
中国97%小微企业与数据中台基本不相关。腰部占3%的120万家大中型企业,可能有很多的开发人员但没有数据专家,另外还有少部分头部企业。对于腰部的大中企业而言,系统可能不多,而数据团队基本没有,无法
快速构建完善的数据中台,但是数据孤岛的痛点、数据打通以及
快速开发的需求却是真实存在的。这些企业可以选用技术型架构,具体需要考虑的能力
包括数据汇聚、数据治理以及建模、数据API服务,以及最关键的存储、海量、多模和高
性能。
RDBMS、MPP、Hadoop、No
sql以及New
sql数据技术各有长短板,在构建中台时也可以做一些参考,企业需要根据自身实际情况进行考量。
之前,MongoDB用于大数据离线分析并不是很好的选择,更多地是将其用于业务场景。而数据中台面向的就是业务应用场景,因此MongoDB成为了
一个不错的选择,其具有较强的横向
自动扩展能力,
支持多模多态,并且API友好。此外,基于MongoDB实现建模所需要的工作远少于传统方式,能够降低成本。
此外,MongoDB还具有数据采集、可视化建模、无
代码化API、数据可视化等数据中台构建所必须的能力。
如下图所示的是较为完整的MongoDB数据中台
解决方案参考架构,从下到上依次是采集、存储处理以及数据服务三层。
基于MongoDB构建数据中台具有这样几个核心优势,即无缝横向扩展能力、多类型结构数据模型、逻辑模型即存储模型、异构实时
数据库同步能力、无
代码快速API发布能力以及简单、轻量和
快速。
阿里巴巴资深技术专家朱国云(宗岱)为大家
分享了阿里巴巴图
数据库GDB的设计与实践。
图
数据库是针对于图结构设计的
数据库,而非
图片数据库。什么是图结构呢?这是以社交网络模型为例介绍,该模型中存在人与人、人与论坛、人与帖子、帖子与论坛之
间的关系,人、论坛、帖子就属于图中的点(即Vertex),点之
间的关系就称之为边(即Edge),在点和边上会有一些
属性(即Property)。
如今,一些优秀的社交应用会将多维数据存储到统一的图空间中来,进行存储、
查询和分析,为
用户带来更好的体验。近年来,数据量越来越大的同时,数据维度也逐渐增多,图
数据库就是
在这种背景下诞生的。
图
数据库作为近年来
数据库领域中发展最快的一类,与
关系型数据库存在哪些差别呢?通常情况下,关系型
数据库中需要通过建七八张表才能做到的模型,图
数据库能够更加直观、自然地表现出来。此外,图
数据库做关联
查询的速度更快,还能够提供更多探索发现的能力。
前面提到的是
属性图模型,在图数据领域还有一种RDF模型。两者的主要区别在于RDF的点和边上不可以有
属性。
图
数据库发展速度很快,因此种类也是特别多,主要可以分成四类,即知识图/RDF、分析图、图
数据库、
多模型图
数据库。这些图
数据库系统使用的主流
查询语言大致有三类,即Neo4j主推的最早使用类
SQL查询语言的Cypher、用于RDF上的描述语言SPARQL和目前
支持最广泛的基于
属性图的
查询语言Gremlin。
GDB是一种图
数据库,其主要处理高度连接数据的存储和
查询,其
支持了
属性图模型和开源的TinkerPop Gremlin
查询语言。与其他
数据库不同的是:GDB是云原生
数据库,从一开始就建设在阿里云基础设施之上,因此能够做到弹性、实时和高可靠。
GDB脱胎于Tair Service中的Tai
rgraph 子系统,后来其孵化出来,并放到阿里云上来专注地
解决高度连接数据场景中的问题。基于Tair 10年的技术基础,GDB实现了高度优化的自研引擎,能够实现实时更新和秒级
查询,并且完整地
支持ACID事务,并通过多副本保障高可靠。此外,还做到了服务高可用,能够实现节点故障迅速转移;易运维,提供了开箱即用的能力;可视化,更利于分析数据的内在关系。
在架构层面,GDB为客户提供的是独享专属实例,这意味着资源独立,无须担心抢占问题。HA方面采用了最经典主备架构,并提供只读节点来提升实时
查询能力。GDB
支持了Gremlin开源的TinkerPop SDK,为了实现每秒百万级点边过滤,GDB定制了专属的图友好
数据库引擎,并在
查询优化和并行执行等方面做了大量优化,还
支持了事务和
自动索引。在数据通道部分,GDB还提供了多种数据源的高效导入
支持。
GDB的场景和案例
如今,GDB在社交网络、金融欺诈检测、实时
推荐引擎、知识图谱以及网络/IT运营等场景中得到广泛应用,而且这些场景往往交织在一起。使用GDB能够将之前偏离线的场景做到实时或者准实时。
总结而言,在数据维度越来越多、数据相互关联越来越紧密的今天,GDB提供了一种有效的图存储方式,能够将多维数据很好地连接起来,并通过图
查询、图算法把数据隐藏的价值实时地、智能地挖掘出来。
Re
disson联合创始人顾睿为大家
分享了Re
disson从Java走向云原生的探索之路。
Re
disson是架设在Re
dis基础上的
一个Java驻内存数据网格。Re
disson以Java接口方式而非命令的形式提供给大家,使用非常简单。其优势在于上手容易,只要能够使用Java基本就能够使用Re
disson。此外,Re
disson在设计时规避了多线程的问题,采用了线程安全的设计,同时引入了线程池和连接池的管理,在同步和异步的场景中都能选到适合的方式。
除了使用简单外,Re
disson在
功能上也提供了多种选择,能够
支持31种分布式集合、14种分布式对象、8种分布式锁和分布式同步器以及5种分布式服务。
Re
disson的架构主要分为两大块,包含Re
disson客户端的连接管理、协议解析在内的基本
功能和
包括分布式结构、分布式中间件以及第三方
功能支持在内的高级
功能。
从Re
disson架构角度来看,似乎和Re
dis的理念相冲突。Re
dis设计理念强调简单,而Re
disson设计却比较复杂;Re
dis提供了9种数据结构,界限清晰,而Re
disson提供了约60种,界限比较模糊;Re
dis以命令形式面向
用户,而Re
disson却以Java API形式面向
用户。看似分道扬镳,实则殊途同归,都是为了将复杂隐藏起来,将简单的使用方式提供给
用户。
只
支持Java是Re
disson的优点,也是缺点。Java是Re
disson的
一个牢笼,这对于应用程序开发者而言是优势,而对于程序库开发者而言就是劣势。因此,Re
disson一直在思考如何走出困境,拥抱其他的生态。
2016年,Re
disson首先尝试了使用Vert.x框架,Vert.x的特点是集群运行环境、多语言交互性和基于成熟技术,并且Vert.x对开发者的限制比较少。因此,Re
disson做了相关的实验,实现了Re
disson在其他语言中的运行。但是这种方案学习成本非常大,而实际收益却不高。
2018年,Re
disson注意到ORACLE Labs推出的GraalVM,GraalVM的底层是Java运行层,
包括GraalVM和SubstrateVM,可以让其他语言都能够编译融合并放入JVM中执行,同时保证相互沟通的桥梁。SubstrateVM是最吸引Re
disson的点,它可以理解为用Java编写的嵌入式虚拟机,使得真正的跨平台和跨语言成为可能。
于是,Re
disson开始了“逃跑之路”,实现了re
disson-native。对于Java、Java+Warm UP以及Native三种方式的
性能进行对比,能够看出re
disson-native的
性能具有明显的优势。
因此,这说明借助SubstrateVM逃离Java是非常好的
解决方案,无需考虑JNI等相关问题,大部分操作只需要Java即可完成,学习成本较低,并且无需安装独立的JVM,
生成文件也较小,云原生情况下
性能较高,并且C
调用非常简单。延伸开去,可以将Re
disson带入到原生的二进制状态并进行二次封装,实现遍地开花。
基于企业级HBase的大数据存储与处理
阿里云智能事业群
数据库产品事业部技术总监,Apache HBase PMC沈春辉(天梧)为大家
分享了基于企业级HBase的大数据存储与处理。
进入大数据时代,数据量越来越多,数据种类也越来越丰富。数据量多这一点容易理解,而数据种类丰富则可以从三个维度来看:从静态维度,如今能够用数字化设备越来越多;从动态维度,设备、服务的运行状态越来越多;此外,还有数据再加工又产生了新数据,使得数据变得无穷无尽。面对这么多
数量和种类的数据,如果没有价值就都是废墟。回顾这十年,大家对数据价值层面的认知越来越强烈,数据也越来越多地应用到生活中的各个场景。
随着对数据的应用,系统会面临很多挑战。大数据提出了“4V”,具体对于开发者而言,数据体量非常大意味着系统需要高扩展性;数据种类非常丰富意味着系统需要具有高灵活性,能够很好承载随时随地产生的新数据种类;数据时效性意味着系统具有高实时性,具有数据在线化能力;数据价值则意味着需要能够商业化,系统需要降低数据的存储和计算成本。
十多年前,Google首先遇到大数据问题,因此发表了Big Table论文。而HBase则是基于该论文设计的高可靠、高
性能、可伸缩的开源大数据No
sql系统。HBase放弃了对于关系型
数据库事务的
支持,重点构建扩展
性能力、灵活
性能力、实时响应能力以及对大体量数据存储低成本的能力。
阿里巴巴从2010年开始调研HBase,如今已经走过了近十个年头。随着这十年的逐步探索,阿里巴巴也丰富了HBase的使用场景,如消息,订单,
Feed流,监控,大屏,轨迹,设备状态,AI存储,推荐,
搜索,BI报表等。阿里巴巴自己使用HBase已经达到了非常大的体量和规模,也在产品上有了很多积累和沉淀,形成了如今云HBase+X-Pack的架构。单独依靠HBase
数据库无法
解决业务场景下的复杂问题,因此X-Pack基于云HBase在计算、检索、
多模型上进行了扩展,包含了Spark、Phoenix、Solr以及OpenTSDB等,形成了稳定、易用、低成本的一站式大数据No
sql平台。
云HBase+X-Pack架构实现了低成本的数据存储,将HBase运行在OSS上面,并且让整体接口模型复用HDFS能力。并且同时克服了OSS在面向
文件场景下的问题,将原本面向对象的存储系统当做类似云盘来使用,使得存储成本降低3到7倍。此外,还基于HBase做到了一体化冷热分离,并使得业务无感知。
除了低成本存储之外,阿里云HBase还投入了大量的精力来优化
性能。相比开源版本,阿里云HBase在各个
性能指标上都有较大的提升。
在这背后是不断的优化,如原本将基于HDFS Pipeline日志三副本转变向LLC机制,并将串行改为并行;将原本串行
获取锁的方式变为并行;并且实现了10倍的Java GC优化。
最后一点,HBase属于大数据领域,必须结合很多组件,因此易用性也是大家最为迫切需要的。阿里云HBase实现了HBase和Spark的数据联动以及在线和离线的高效融合。此外,阿里内部也提供了一套易用的数据迁移系统,能够实现平滑在线
搬迁。
无论是从稳定性、易用性还是
性能和成本上来说,阿里云HBase都有很大的提升。未来,阿里云HBase还会通过共享块存储等技术进一步降低成本,也将会推出Serverless能力,并且会通过新硬件来加速计算,降低成本。
斗鱼直播从0到1混合云架构演进
斗鱼技术总监马勇为大家
分享了斗鱼直播的混合云架构演进之路。
斗鱼直播成立于2014年,是以游戏赛事为主的直播平台,平台签约国内Top100主播约50位,覆盖游戏主播Top10中8位,月活达1.5亿,2019年Q1付费
用户约600万。斗鱼主要有三条业务特点:头部主播热点效应,流量水位波动较大,以及在线互动场景较多。目前的技术现状是每天业务
调用量在千亿左右,Re
dis实例集群达2000以上,单个接口QPS达20万以上。
斗鱼直播从2016年开始保持每年25%以上的月活增长,目前面对的技术困境主要有三点:(1)“炸鱼”,头部流量拖死全站房间;(2)
服务器资源利用率低,日常水位大量服务器闲置;(3)Re
dis维护和容灾成本高。
斗鱼混合云架构历程主要分为三个阶段,在探索期做了独立业务上云的尝试;在成长期通过IDC+云的方式实现了横向流量扩容;在成熟期完成横向扩容之后实现对资源的最大化利用。
探索期的主要背景是IDC硬件资源呈现为长期紧缺状态,研发支撑跟不上业务发展,而公有云逐步成熟。因此
在这一阶段,斗鱼尝试性选取了广告业务作为上云试点,并且取得了较大收益,系统的吞吐量直线上升,依赖稳定性显著提升,计算成本也大幅下降。但是这一模式的适用范围较窄,无法直接复制到其他业务场景,而且这一模式只适用于单一数据中心的情况,于是就进入了成长期。
成长期的背景是需要
解决IDC到公有云的数据通道构建问题。针对这一问题,斗鱼和阿里云共同构建了Re
disShake数据同步工具,
支持了Re
dis全量、增量数据同步、
支持云上、云下不同数据中心的同步,还
支持秒级数据监控。通过Re
disFullCheck实现了数据多维度对比,基本能保证数据通路的数据一致性问题。这一阶段的收益在于实现了单一机房到多机房的数据扩展过程。这个阶段存在存在两点有待改进,即资源调度成本比较高和资源缺乏精细化运营。
成熟期的主要优化方向是职责分离和弹性伸缩,优化方案
包括四个方面,即流量分级、数据冷热分离、弹性伸缩和流量调度。其中调度策略
包括了手动调度、定时调度、资源消耗调度和Hook调度。
充分合理评估:云上计算网络与IDC差异较大,需要结合业务实际情况进行测试,避免产生影响。
投入产出比:混合云架构对资源冗余存在一定要求或者带来一定负面影响。
延时问题:企业应通过评估业务的重要性决定是否做混合云,虽然从数据中心到云有专线,但也存在一定延时。
Cassandra&X-Pack Spark云
数据库技术剖析
阿里云智能高级技术专家曹龙(封神)为大家剖析了Cassandra与X-Pack Spark云
数据库技术。
为什么选择Cassandra呢?Cassandra是一种完全没有中心的
数据库,其每个节点都是主节点,如果Kill掉其中任何
一个节点都不会影响集群的QPS以及延时。除了Cassandra使用的P2P-QUORUM机制之外,还有HA机制、Raft以及单内存副本+共享存储等机制,而只有Cassandra能够做到几乎没有感知时间,因此Cassandra的Slogan就是“Always Online”。
Cassandra能够实现平滑扩展,一方面可以
增加节点数据量,甚至扩展多个DC。另一方面在云上还可以
增加内存等。平滑扩展是Cassandra的重要特性,其他
数据库往往难以做到。Cassandra还可以实现全球多DC,架构师可以根据业务自由适配。
对于学习成本而言,Cassandra提供类似于
sql语句的CQL,会
MySQL的DBA或者开发人员基本上一天之内就能学会Cassandra。在安全方面,Cassandra和主流
数据库一样提供了完善的认证以及鉴权体系。在多语言方面,Cassandra采用了非Thrift方式,采用客户端和服务端直连方式,并且
支持主流的语言,并且具有良好的
性能。最后一点,就是运维简单,Cassandra整体只有
一个进程,没有Proxy、HA以ZK等角色节点。
Cassandra具有很多
功能,比较特别的就是其索引
支持物化视图、还
支持SASI全文索引,并且集成了Lucene做更强的全文索引,以及
支持CDC对接流式系统。
Cassandra的
功能和生态比较丰富,其可以和其他组件进行搭配,比如Spark、Kafka、ES、Lucene、RocksDB等。
Cassandra在宽表领域排名全球第一,即使在国内缺乏宣传的情况下排名也是靠前的。Cassandra的发展目前已经经过了十年,其将AWS的DynamoDB和Google的BigTable两者的长处融合在一起形成的。阿里巴巴也在2019年公测并发布了阿里云Cassandra
数据库服务,并且对原生的Cassandra进行了多方面提升,比如实现了
自动化运维、兼容DynamoDB、全链路优化
性能提升100%等。
总结而言,云
数据库Cassandra版是在线可靠的No
sql可调一致性的分布式
数据库服务,
支持类
sql语法CQL,提供强大的分布式索引能力,提供安全、多活容灾、监控、备份恢复等企业级能力,兼容DynamoDB协议。
X-Pack Spark不仅仅
支持Cassandra,还能够
支持HBase、Phoenix、RDS和MongoDB。X-Pack Spark不仅具有强大的连接能力和归档能力,还能够通过ElasticNode降低计算和存储成本。
Cassandra+Spark能够应用于非常广泛的业务场景中,比如
用户画像、
Feed、小对象存储以及推荐平台等。
总结而言,将Spark与Cassandra的优点结合在一起能够满足多种业务场景的需求,能够实现Always Online、扩展性强、好用、
功能和生态丰富以及Spark数据闭环。