为什么国内六位oracle 11gACE中有三位来自阿里巴巴

阿里下一代数据库技术:把数据库装入容器不再是神话
数聚价值,智胜未来。这是一个数据的时代,海量,多维度,高并发的数据与数据业务越来越成为企业的核心关注点。对于高并发的承受能力在一定程度上代表着企业IT技术的综合实力。在这一点上,不得不谈到的一个高并发就是双11,以及阿里集团的“双11”数据库技术总负责人张瑞。
张瑞曾两次担任双十一技术保障总负责人。自2005年加入阿里巴巴以来,一直主导整个阿里数据库技术的不断革新。在今年的第七届数据技术嘉年华上,我们有幸邀请到了张瑞为大家带来精彩主题分享,围绕双11运维的最佳实践,分析未来数据的演进之路。
今天,我们拣选张瑞在5月份的数据库技术大会上的演讲主题,与大家分享。
本文文章与图片均转载自『阿里技术』(ali_tech)
本文链接:http://mp./s/AIZQ5-F5AngdIESNCXngWw
张瑞,阿里集团数据库技术团队负责人,阿里巴巴研究员,Oracle ACE
今年五月份举行的2017中国数据库技术大会上,来自阿里巴巴集团研究员张瑞发表了题为《面向未来的数据库体系架构的思考》的主题演讲。主要介绍了阿里数据库技术团队正在建设阿里下一代数据库技术体系的想法和经验,希望能够把阿里的成果、踩过的坑以及面向未来思考介绍给与会者,为中国数据库技术的发展出一份力。
演讲全文:
我先介绍一下我自己,我2005年加入阿里一直在做数据库方面的工作,今天这个主题是我最近在思考阿里巴巴下一代数据库体系方面的一些想法,在这里分享给大家,希望能够抛砖引玉。大家如果能够在我今天分享后,结合自己面对的实际场景,得到一些体会,有点想法的话,我今天分享的目的就达到了。
今天我会讲以下几方面内容:
在数据库内核上的思考与创新
数据库怎么实现弹性调度
关于智能化的思考
曾经踩过的坑和看到未来的方向
“阿里场景下所面临的数据库问题”
首先说一下,阿里巴巴最早一代使用的数据库技术是Oracle,后面大家也知道一件事情就是去IOE,去IOE过程中我们迈向了使用开源数据库的时代,这个时代今天已经过去,这个过程大概持续了五六年,整个阿里巴巴有一个大家都知道的开源MYSQL分支--AliSQL,我们在上面做了大量的改进,所以我这里列了一下在AliSQL上的一些改进,但今天我实际上并不想讲这个,我想讲一下面向未来的下一代数据库技术、数据库架构会往哪个方向走。
我觉得是这样的,因为今天的阿里巴巴毕竟是一个技术的公司,所以很多时候我们会看比如说Google或者是一些互联网的大的公司,他们在技术上创新点来自于哪里?来自于问题。就是说今天在座的各位和我是一样的,你所面对场景下的问题是什么、你看问题深度如何决定了你今天创造的创新有多大。
所以今天我们重新看一下阿里面临的问题是什么,相信在座的各位一定也有这样的想法,阿里所面临的问题不一定是你们的问题,但我想说今天通过阿里面临的问题,以及我们看到这些问题后所做的事情,期待能够给大家带来参考,希望大家也能够看到自己所面临的问题是什么,你将如何思考。
可以看到其实阿里巴巴的应用和Facebook、Google的还是有很大区别的,我们也找他们做了交流,发现跟他们的业务场景真的不一样,首先我们的主要应用是交易型的,这些应用会有些什么要求,你会看到有这些点(见图片),下面主要讲一下我们的思考。
今天数据的高可用和强一致是非常重要的,数据不一致带来的问题是非常非常巨大的,大家也用淘宝,也是阿里巴巴一些服务的用户,数据不一致带来的问题,每一个用户、甚至我的父母都会关注这些事情。
第二,今天存储成本是非常高的,所有的数据中心已经在用SSD,但数据的存储成本依然是一个大型企业面临的一个非常大的问题,这都是实实在在钱的问题。
另外刚才也提到了,数据都是有生命周期的,那么数据尤其是交易数据是有非常明显的冷和热的状态,大家一定很少看自己一年前在淘宝的购买记录,但是当下的购买记录会去看,那系统就需要经常会去读它、更新它。
还有一个特点是今天阿里的业务还是相对简单的,比如我们要在OLTP性能上做到极致性。还有一个阿里巴巴特有的点就是双十一,双十一本质上是什么,本质上就是制造了一个技术上非常大的热点效应。这对我们提出什么样的需求呢?需求就是一个极致弹性的能力,数据库实际上在这个方向是非常欠缺的,数据库怎么样去做到弹性伸缩是非常难的事情。
最后我想说说DBA,今天在座的很多人可能都是DBA,我想说一下阿里在智能化这个方向上得到的思考是什么样的,我们有海量的数据,我们也有很多经验很丰富的DBA,但这些DBA怎么样去完成下一步的转型、怎么样不成为业务的瓶颈?数据库怎么样做到自诊断、自优化。这是我们看到的问题,最后我也会来分享一下我在这方面的思考。
“阿里在数据库内核方向上的思考与创新”
在数据库内核上的思考
首先我很尊敬做国产数据库的厂商,凡是在内核上改进的人都知道,其实每个功能都是要一行行代码写出来都是非常不容易的,我想表达对国产数据库厂商包括这些技术人的尊敬。
首先来讲一下AliSQL X-Cluster。
X-Cluster是在AliSQL上做的一个三节点集群,这是我们在引入了Paxos一致性协议,保证MySQL变成一个集群,并且这个集群具有数据强一致、面向异地部署,且能够容忍网络高延迟等一系列特性。
今天很多数据库都会和Paxos联系在一起,比如大家都知道的Google的Spanser数据库,但是以前大家没有特别想过数据库和Paxos会有什么关系,其实以前确实没有什么关系的。
但是今天的数据库在几个地方是需要用到Paxos协议的,第一个我们需要用Paxos来选举,尤其在高可用的场景下需要唯一地选举出一个节点作为主节点,这就需要用到Paxos;第二是用Paxos协议来保证数据库在没有共享存储的前提下数据的强一致,就是数据怎么样在多个节点间保证是强一致,且保证高可用。
所以说现在的数据库架构设计上Paxos的应用非常广泛,今天外面很多展商包括Goolge Spanser也都在用Paxos协议和数据库结合在一起来做。所以AliSQL的三节点集群也是一样,就是利用Paxos协议变成一个数据强一致的集群。
下面我大概解释一下Paxos协议在数据库里的作用是什么。
本质上来说Paxos也是现在通用的技术,大家都是搞数据库的,简单来说,Paxos协议用在我们数据库里面,就是一个事务组的提交在一个节点并落地后,必须在多个节点同时落地,也就是说原来写入只需要写入一个节点上,但是现在需要跨网络写到另外一个节点上,这个节点可能是异地的,也可能是全球的另外一个城市,中间需要经过非常漫长的网络时延,这时候需要有一些核心技术。
我们的目标是什么?
首先没有办法抗拒物理时延,过去在数据库上的操作只要提交到本地,但现在数据库全球部署、异地部署,甚至跨网络,这个时延特性是没有办法克服的,但是在这种情况下我们能做到什么?在时延增长情况下尽可能保证吞吐不下降,原来做多少QPS、TPS,这一点是可以保证的,只要工程做的好是可以保证的,但是时延一定会提升。
这也是大家经常在Goolgle Spanser论文里看到的“我的时延很高”的描述,在这种时延很高的情况下,怎么样写一个好的应用来保证可用、高吞吐,这是另外一个话题。大家很长一段时间里已经习惯一个概念,那就是数据库一定是时延很低的,时延高就会导致应用出问题,实际上这个问题要花另外一个篇幅去讲,那就是应用程序必须要去适应这种时延高的数据库系统。当然用了Batching和Pipelining技术,本质上是通用的工程优化,让跨网络多复本同步变的高效,但是时延一定会增加。
实际上大家知道数据库要做三副本或者三节点,本质上就是为了实现数据强一致,而且大家都在这个方向上做努力,比如Oracle前一段时间推出的Group replication,也是三节点技术,X-Cluster和它的区别是,我们一开始的目标就是跨城市,最开始设计的时候就认为这个节点一定要跨非常远的距离来部署的,设计之初提出这个目标造成我们设计上、工程实践上、包括最终的性能上有比较大的差异。
这里我们也做了一些X-Cluster和Oracle的Group replication的对比,同城的环境下我们要比他们好一些;在异地场景下这个差异就更大了,因为我们本来设计的时候就是面向异地的场景。可能大家也知道,阿里一直在讲异地多活的概念,就是IDC之间做异地多活怎么样能够做到,所以最开始我们设计的就是面向异地的场景做的。
这是一个典型的X-Cluster在异地多活的场景下怎么做的架构图,这是一个典型的3城市4份数据5份日志架构,如果要简化且考虑数据存储成本的话,实际上可以做到3份数据5份日志,这样的话就可以保证城市级、机房机、包括单机任何的故障都可以避免,并且是零数据丢失的,在今天我们可以这么做,且能保证数据是零丢失、强一致的。在任何一个点上的数据至少会被写到另一个城市的数据中心的数据库里面,这是我们X-Cluster设计之初的目标,这也是一个典型的异地多活的架构。
关于X-KV的创新
这里还要说一下,我们所有的下一代技术组件都是以X开头的。这个X-KV是基于原来MYSQL的Memcached plugin做的改进,做到非常高的性能,大家可能都了解MySQL的Memcached plugin,可以通过Memcached plugin的接口直接访问InnoDB buffer 里的数据,读的性能可以做到非常高。
这对于大家来说,或者对于所谓的架构师,或者设计的过程中意义在什么地方呢?
1、很多场景下不需要缓存了。因为数据库+缓存结构基本上是所有业务通用的场景,但是缓存的问题在于缓存和数据库里的数据永远是不一致的,需要一个同步或者失效机制来做这个事情。使用X-KV后读的问题基本上就能解决掉。这是因为一份数据只要通过这个接口访问就基本上做到和原来访问缓存差不多的能力,或者说在大部分情况下其实就不需要缓存了。
2、它降低了应用的响应时间。原来用SQL访问的话响应时间会比较高,我们在这上面做了一些改进,本来Memcached plugin插件有一些支持数据的类型限制,包括对一些索引类型支持不太好,所以我们做了改进,这个大家都可以用的,如果用这个方式的话基本上很多缓存系统是不需要的。
如何解决冷热数据分离的问题
我们天然地利用了MySQL的框架,这里就直接拿了MySQL的大图来展示,大家可以看到MySQL本质上来说就是上面有个Client,中间有个Server,底下有个存储层,在存储层里面可以有各种各样的引擎,所以通过不同的引擎可以实现不同的特性。大家今天最常用的就是InnoDB引擎,每个存储引擎的特性本质上是由其结构造成的。比如InnoDB采用B+ Tree的结构,它带来的特性就是相对来说读和写都比较均衡,因为发展了这么多年确实是比较成熟的。
比如我们现在选择RocksDB,这是因为我们和Facebook在RocksDB上有一些合作,就是把它引入到MySQL上面,它本质的结构是LSM Tree,这个结构就带来的好处包括写入比较友好、压缩的特性好等。把它引入进来对我们的改革还不仅仅是引入了一个结构,而是今天我们用这两种引擎解决我们今天数据分离的问题。我们也跟Facebook有过一些交流,RocksDB今天并没有那么稳定、那么好,但是作为InnoDB存储引擎的补充的话,是非常有效的。
尤其在稳定数据库的背景下,用户今天怎么样才能对自己的数据的冷热没有太多的感觉,因为大家可能也知道,你们以前也有一些数据的分离,但是对应用方来说,需要把数据从某个存储倒到某个存储里,然后再删掉;或者动不动DBA去找业务开发方说你的存储空间不够了,占用很多空间,能不能删一些数据或者把这些数据导入到成本更低的存储引擎里。我们经常这么干,这里说的直白一点,我相信大家都这么干过。
但是用这种双引擎结构的话,RocksDB压缩率高的特性,特别是OLTP行存储的场景下,能够给我们带来比较大的收益。所以我们可以把这两个引擎在MySQL特性下面把它结合起来,并且可以利用到比较廉价的架构,尤其是LSM Tree这种架构,他对廉价的存储介质是比较友好的,因为他的写都是顺序写的。这就是我们今天在数据库内核上面的一些思考。
“数据库为什么要实现弹性调度”
第二部分,我想说一下数据库弹性调度这个事,大家都知道阿里双十一,双十一对我们来说最大的挑战就是应用程序可能已经很容易去做弹性调度,包括上云、弹性扩容和缩容,但是数据库确实比较难,我们也在这上面也探索了一段时间,今天会把我们的思考分享给大家。
我之前听好多人说数据库容器化是个伪命题,为什么要做容器化,为什么要把数据库放到容器里呢?第二也有一些新技术,比如刚才的分享嘉宾也提到的,把存储放在远端通过网络访问是可能的。但是我们从正向来思考,先别想数据库弹性调度可能不可能,数据库如果要实现弹性调度,它的前提是什么?
我们先去想数据库要像应用一样非常简单的弹性调度,那么数据库要做到什么?我觉得有两大前提是必须要做的:
1、它必须要放到一个容器里;
2、计算和存储必须分离。
因为如果计算和存储本质上不分离的话,数据库基本上没有办法弹性调度。大家知道计算资源是很容易被移动的,但是存储资源基本上很难在短时间内移动它,所以做弹性是非常非常困难的。所以这是两大基础条件。
在我们的场景下如果你也碰到这种问题的话,那就不是伪命题,我觉得这个东西合不合理,更多时候不是技术有没有正确性,而是在你的场景下是否需要它,所以今天我们就做了两件事情,第一是把它放到容器里面,我们目前物理机,VM和Docker都在支持,有一层会把容器的复杂性屏蔽掉,数据库一定要放到容器里。应用程序放到容器里很多时候是为了部署,但是我们把数据库放容器里就是为了做调度,因为数据库本身没有特别多的发布,不需要像应用一样做频繁发布。做了容器化之后,数据库在一个物理机上可以和其他的容器做混部。
我们做DBA的都有一些传统的观点,比如数据库服务器上肯定不能跑应用,数据库肯定是不能用容器的。不知道在座的各位,每当有人或者你的老板问你这个问题的时候,你是不是从来都是马上回绝他说“数据库肯定不能这么做”,但是今天你也许可以告诉你的老板可以试一试。
存储计算分离,最早做数据库的时候,存储和计算其实就是分离的,用一个Oracle的数据库,用一个SAN网络,底下接一个存储,存储和计算本身就是分离的,中间用SAN网络连起来。然后演进到用Local的盘,用SSD盘,用PC做服务器。,那未来重新要回到存储和计算分离的结构下,今天的网络技术的发展,不说专有网络,就说通用的25G网络,还有RDMA和SPDK等新技术的使用,让我们具备了存储计算分离的能力,让数据库存储计算分离的条件已经具备。
今天在数据库上已经看到大量优化的特性可以减少IO,可以把离散的IO变成顺序的IO,可以对下层的存储做的很友好。从存储成本上来说,共享存储会极大的降低成本,是因为存储碎片会被极大地压缩,因为原来每个机器上都空闲30%、50%的空间,其他的机器是很难利用到的,当你今天把这些碎片变成一个Pool的时候是有很大收益的。
还有数据库未来如果采用存储和计算分离的话,就会打破目前主流的数据库一主一备的架构,这个架构至少有一半的计算资源是被完全浪费的,不管你的备库是否用来做报表或者其他的应用,但是基本是浪费的。如果可以做到共享存储,那这将是一个巨大的收益。这是我们在调度上的思考,明天分会场上也会有一个阿里同学就这个主题给大家做容器和存储资源上的细节介绍,我今天只讲了一个大概。
“DBA未来的工作内容”
最后讲一下DBA的事情,刚才也在说,我这里说从自动化走向智能化,我们内部讲从自助化走向智能化,不知道大家是不是受到一个困扰,业务发展的速度远远大于DBA人数的增长,如果你没有后面的这些我可以不讲了,但是如果你有,你可以听一下我们在这方面的思考,我们也碰到同样的问题,DBA要怎么样的发展,自动化的下一步应该做什么,很多人说DBA是不是会被淘汰掉,至少我们想清楚了这些问题之后,阿里的DBA不纠结这个事情,所以我今天跟大家分享一下这个思考。
参考阅读:云时代的DBA将何去何从
首先我们今天做了一个事情,我们放弃了原来的思路,原来的思路是什么呢?最早的时候我们每个上线的SQL都需要DBA看一下;第二个阶段,我们做了一个系统,在每个SQL上线之前系统都要预估一下它的性能好不好,如果好才上线。所有我们今天觉得最大的变化和思考是什么?所有基于单条语句的优化都是没有特别多意义的,因为只有基于大的数据和计算,才有可能变成一个智能化的东西,否则都是基于规则的。
基于规则的系统是很难有特别长久的生命力,因为有永远写不完的规则。我们也曾经做过这样的尝试,一些SQL进来的时候,系统要对它进行一些判断,最后发现永远写不完的规则。所以后来我们就找到了另外一个方向,我相信今天在座的所有人,你所在的公司不论大小都都有一个监控系统,我们就从这个监控系统出发,怎么样把一个监控系统变成一个智能的优化引擎,我们在这里也不说是大脑,就说是引擎好了。这个引擎会做什么?
首先来说,我们已经放弃掉基于单条SQL的优化,因为没有意义,DBA也没有审阅单条SQL,系统去看单条SQL的意义也不大。今天我们的第一个场景是说大量的数据,大量的数据是什么?我们就从我们的监控系统出发,提出了第一个目标,把每一条运行的SQL采集下来,不是采样,是每一条。在规模比较大的系统来说对存储来说是个巨大的压力,因为这样会产生大量的副产品。
就像Facebook在做监控产品时产生的时序数据库一样,今天我们产生的副产品也是在时序数据库方面带来压力,这个具体的我今天先不展开。我们采集每一条SQL的运行情况,因为我们在内核里做了改进,可以把每条SQL的来源、路径、以及它在数据库里所有的信息全部采集下来。把监控指标压到秒级,所有监控项的指标必须最小达到秒级,这是我们现有的技术能够做到的。
另外,我们把应用端日志和数据库结合在一起。原来做数据库的时候,应用方吼一嗓子说“数据库有没有问题啊”DBA说没有问题。但是从应用那端看,其实看到数据库有很多问题,包括应用报错,包括响应时间,把应用端报错也要和数据库结合在一起,尤其是应用里面报数据库的错误,以及这一整条链路。
响应时间,只有应用端的响应时间才是真正意义上可以衡量一个数据库是不是好的指标,而不是数据库本身怎么样,什么Load低啊,CPU利用率多少。当把这些数据全部采集下来之后,这些大量的时序数据我们叫做副产品,这对我们整个链路产生了一个巨大的压力。我们做整个监控系统平台的同学觉得日子要活不下去了,因为原来的存储系统支撑不了、分析系统支撑不了、原来的平台计算不出来。所以先从这个目标考虑,基于链路做了巨大的改进,包括怎么样实现廉价存储、怎么样实时分析,这是存储和计算的要求。
我们今天这个目标是在阿里内部明确提的,我们希望两到三年内希望大部分把DBA的工作替换掉,我不知道两到三年能不能做到,我希望能做到。其实今天DBA是这样的,DBA的工作本质上分为两类,第一类就是运维,但运维本质上来说是比较好解决的,不管是用云,小公司用云全搞定,大公司基本上都有一些自动化运维的系统。
但是最难解决的就是刚才我说的诊断和优化。我也了解过很多公司,比如说Google、facebook,我说你们为什么没有DBA呢?他们说我们没有DBA,没有像国内这种特别传统的针对诊断和性能优化的DBA,这种职责很少。所以这个东西希望能够做到。
最后我们有了数据、有了计算,我们觉得未来的方向可能就是现在比较火的机器学习,这个主题明天也有一个阿里同学会来分享,机器学习这里我就不多讲了,因为我觉得我们也在入门,所以没有什么值得讲的,但是我们觉得这个设计挺有戏的,你只要积累足够的数据和计算的话这个事情还是挺有戏的。
“我们对数据库未来的发展方向”
最后一页PPT我用大白话讲一下我对整个数据库体系的一些理解。
今天在一个公司里边没有一个存储或者是数据库可以解决所有问题,今天越来越多的趋势看到,数据存储的多样性是必然会存在的,因为行存有行存的优势、列存有列存的优势、做计算有计算的优势、做分析有做分析的优势、做OLTP有OLTP的优势,不要指望,或者很难指望一个系统干所有的事情很,这个话我说了可能不太好,但是确实比较难,但是我们看到的一点是什么?就是每个技术或产品在生产中干一件事情可以干到最好,你就用它做的最好的那件事解你的问题就好了。
这就回到之前的问题,我们也走过一些弯路,数据存储类型越来越多,今天用这个明天用那个,怎么办?我们的运维没法搞定,这个支持很痛苦。
所以今天我们建议建立两个平台:
1、建立一个支撑的平台,这个支撑的平台尽可能把下层存储的复杂性屏蔽掉,对上层提供统一的接口和服务;
2、建立一个服务的平台,明确面向研发的平台,研发人员可以直接通过这个平台来用数据库的服务。
我看到很多公司把运维平台和DBA开发的平台混在一起,但阿里的思路是,支撑平台和服务平台是两个分层的平台,支撑平台在下面,上层服务平台为所有的开发人员服务,开发人员上了这个平台就能看到我用了什么数据库,性能怎么样,在上面可以做什么事情,这样就可以大量节省DBA的人力。
我们内部有句开玩笑的话叫“不节省人力的平台、不节省成本的技术都是耍流氓”,这句话怎么讲?就是说我们的自动化系统,尤其是大公司越建越多,最后的结果就是人没有能力了,我不知道大家有没有这个问题,这就是我最后讲的一点,自动化系统的悖论。每个公司每个人今天你们在做自动化系统的过程中有没有发生一件事情?反正在阿里是发生了,就是人的能力弱化了。
这个自动化系统的悖论是我们无意中看到的,在讲飞机的自动驾驶的时候,因为自动驾驶做的足够好,当出现紧急问题的时候,飞机驾驶员反而没有足够的能力去处理紧急的情况,这就是自动化系统的悖论。
可以对比看一下,我们今天做了很多自动化系统,结果人只会点系统,系统一卡壳就完蛋,很多次生故障都是出现在系统卡壳,卡壳人搞不定,怎么办?这是今天要去想的问题,在这个过程中今天所有带团队的或者今天在这个体系的人都要思考的问题,我们也在直面这个问题,让人的能力和系统的能力能够结合在一起,这是另外一个话题,我今天不能给出答案,但是要特别重视这些问题。
不要相信那些已经过期的神话,数据库存储和计算是可以分离的,数据库也是可以放在容器里的,但你真的要去看一下,原来那些神话或者是那个背后它的问题到底是什么,其实现在可能都已经有解法了,所以在座的各位,当你的老板、CTO或者什么人来问你“能不能做到这样?”我希望你能告诉他“我能!”
我们内部有一句话原来我们的DBA哪里看过一篇文章,说DBA的概念是什么?我印象特别深,有一个开发的同学在底下的回复是说“DBA就是一群永远在说不的人”就是不能这样不能那样,我们今天我觉得未来我们变成一群永远可以说“yes”,说“可以”的人,谢谢!
2017 第七届数据技术嘉年华精彩看点,请猛戳:
【数聚价值 智胜未来】第七届数据技术嘉年华北京盛大开启!
MySQL实战进阶技术分享
有目标的人在奔跑,沒目标的人在流浪,因为不知道要去哪里!
有目标的人在感恩,沒目标的人在报怨,因为觉得全世界都欠他的!
有目标的人睡不着,沒目标的人睡不醒,因为不知道起来去干嘛!
生命只有走出来的精彩,沒有等待出来的辉煌!
授课老师:李全新
时间:9月23日 9:30AM
地点:北京市朝阳区光华路9号光华路SOHO二期B座10-3、10-5
责任编辑:
声明:本文由入驻搜狐号的作者撰写,除搜狐官方账号外,观点仅代表作者本人,不代表搜狐立场。
今日搜狐热点解密阿里巴巴的技术发展路径
[思路网注] 在2009年到2013年整个去IOE的过程中,阿里技术发展策略逐渐从商业软件、开源软件发展到自主技术和云计算构成的综合技术服务能力。便宜的Commodity PC替换掉过去昂贵的硬件设备
2008年的一天,阿里巴巴集团(下称“阿里”)开了一次内部会议。在这次当时看来很平常的会议上,明确了两个议题:一,阿里是一家数据公司;二,阿里要把“计算”变成一种像水和电一样的公共品。当时在中国还没有人谈“大数据”的概念;更没有人想到云计算会和一家互联网公司未来发展如此紧密。1999年阿里成立之初,创始人“十八罗汉”中就不乏技术基因。公开资料显示,创始人之一吴泳铭1996年毕业于浙江工业大学计算机系,后成为支付宝的技术总监。盛一飞有多年用户体验设计经验。周悦虹,java架构师,技术精湛,传言是一名极客。随着淘宝网的成立,2003年阿里开始与IBM合作,解决用户、商品和消费信息分散的问题。当时的阿里已经从十几个人的小公司延展出很多新业务,技术系统也变得庞大复杂。到了2007年,阿里在IT上的投入之大,一度成为IBM、Oracle等国外IT厂商在中国的标杆用户。当年,阿里首席数据库管理员冯春培甚至受到了Oracle公司亚太区高级副总裁Brian Mitchell亲切接待,并被授予甲骨文全球第100个ACE(Oracle ACE是指那些通过撰写书籍、文章或博客,分享Oracle经验的技术专家)。但实际上,这种甜蜜的合作关系并没有持续太久。2008年前后,阿里业务高速发展使已有的IT设备使用到达瓶颈。根据时任支付宝数据库架构师、现丁香园CTO冯大辉的描述:“在阿里的IT架构中,淘宝和支付宝等拥有大量IBM小型机和Oracle数据库,以及EMC、戴尔存储设备。用户激增与用户产生的数据越来越多,每年早上8:00?9:30之间CPU(中央处理器)要保持98%的使用率。”IBM小型机价格从几十万到高达百万级人民币,与Oracle签订的数据库软件费用达数千万,加之一大笔软硬件支付和一大笔维护费,阿里的技术发展进入一个压力很大的时期。紧迫之中,阿里在寻找一名技术高管,要为庞大复杂的业务搭建起全新的技术架构,建立全球顶尖IT团队。在2008年的这次内部会议上,阿里确定了“数据”和“云计算”两个重要的新战略。时任阿里巴巴首席架构师的王坚成为接受这个挑战的不二人选。“去IOE”念头萌生阿里巴巴CTO王坚加入阿里巴巴之前,王坚任微软亚洲研究院常务副院长;再之前,他是浙江大学心理学系教授、系主任。加盟阿里后,王坚马上着手第一个重要工作——筹划集团全年的IT预算。他反复琢磨,发现一个重要问题:即便追加巨额IT投资,阿里购买的软硬件也未必能满足其业务的高速增长。“双十一”大促对IT计算资源要求庞大,很难预测业务爆发点所需要的计算资源峰值。但过了高峰期,IT资源空下来,又会造成浪费。这些实实在在的难题是为阿里提供软硬件服务的厂商从没遇到过的,IBM、Oracle和他们的客户都不能为阿里IT提供任何可供借鉴的经验。其次,整个IT就像是一个黑箱子,一旦出现技术故障后,阿里的技术团队要打电话给厂商等待事故处理,而且高端存储设备的性能数据都是由厂商掌控,阿里自己的技术团队并没有太大的控制权。技术维护变成极其繁琐的工作,支撑业务的效率大大下降。而在地球的另一端,Google和Amazon是和阿里业务相近,并值得学习的两个好榜样——Google是世界上少有的能拥有大规模分布式架构技术的互联网公司,Amazon是第一个将自己云计算技术对外提供服务,实现营收的公司。在一次预算讨论中,阿里巴巴集团负责技术保障的副总裁刘振飞和阿里技术保障部DBA负责人周宝方偶然提到:“阿里应该尝试用PC技术替代小型机技术。”一听这句话,王坚一下子激动起来:“既然已经思考了这个问题,为什么我们不郑重写下来?明确阿里再也不购买小型机。”“去IOE”(在IT设备中去除IBM小机、Oracle数据库及EMC存储)由此得名。在2009年到2013年整个“去IOE”的过程中,阿里技术发展策略逐渐从“商业软件”、“开源软件”发展到自主技术和云计算构成的综合技术服务能力。便宜的Commodity PC替换掉过去昂贵的硬件设备,淘宝、支付宝等重要业务将旧的“IOE”集中式架构转变为分布化架构,这种架构是把IT后台迁移到云计算平台上的基础工作。在“去IOE”过程中,阿里技术团队也完成了一次成熟的转型,这为阿里向外提供云服务打下了基础。王坚来阿里之前,阿里各业务技术后台是独立运营的,他将阿里运维团队、平台技术部、大淘宝运维团队、云计算运维团队等整合到一起,成立了集团统一的IT技术保障部。阿里旗下子业务模式差别巨大,IT工具和价值理念也完全不同,所以统一团队经历了很大的技术挑战和组织挑战。这项工作实际为后期阿里云向外提供服务打下了很好的基础,阿里后期推出的“聚石塔”、 “聚宝盆”业务,与这支在“去IOE”过程中锻炼出的队伍密不可分。除了团队,技术人员也面临着个人转型。王坚曾多次说:“‘去IOE’最难的就在于人。每一次的技术转换,我们都是在革自己的命。如果没有同事们当时敢于尝试的勇气,阿里的技术难题都可能扛不过去。”曾有一位技艺精湛、对业务非常熟悉的淘宝数据库管理员,在“去IOE”过程中,他从Oracle数据库技术,转到MySQL数据库,最后去研发阿里自有技术OceanBase数据库。技术的重新选择让阿里最有价值的一批技术人才,随时要面对熟练的技术突然没有用的情况。曾参与IBM小机下线的技术人员楼方鑫曾说过这样一段话:“去掉一两个系统的IOE不是最难的,也不能代表成功;通过‘去IOE’提升和锻炼团队的能力,协调好运维和开发团队间的工作才是关键。”小机,再见!阿里巴巴最后一台下线的IBM小机淘宝是首先推行“去IOE”战略的业务部门之一。“去IOE”之所以能从淘宝开始,是因为淘宝拥有阿里最大的Oracle数据库,成本和技术压力最大。淘宝技术专家余锋曾说:尽管Oracle数据库性能稳定,但是对于淘宝来讲,Oracle数据库本身已经不能满足业务需求。淘宝的数据库专家从IT前端逐渐过渡到后端,弱化Oracle数据库,把“Oracle数据库+IBM小型机+EMC存储设备”切换到“MySQL数据库+PC Server的模式”。到日,淘宝重中之重的广告系统的Oracle数据库全部下线。日,阿里集团最后一台IBM小机在支付宝下线时也使阿里“去IOE”运动越发受到关注。在“去IOE”的进程中,支付宝首席架构师程立有自己的苦衷。支付宝有阿里最后一台IBM小机,这台小机管理着支付宝用户的所有资金。如果这台小机出现故障,用户将会无法支付,甚至连自己账户里有多少钱都看不到了,后果将不堪设想,因此对这台小机的任何改动都要确保万无一失。去除支付宝IBM小机的第二个难点在于,去除小机的前提是实现技术架构分布化,为支付宝IT迁移到云平台打下基础。但将技术架构从集中变成分布后,很难保证强一致性,比如客户A给客户B转了一笔钱,不能出现A的钱扣了,但B的钱没增加的情况。如何在一个分布的系统中保证交易处理的一致性是一个要攻克的技术难题。“在王坚博士梳理整个阿里技术架构的时候,支付宝曾经是他‘去IOE’最大的一个‘障碍’”程立向《商业价值》记者说道。“我们必须要保证每天处理的大量资金,一分钱都不能错,一笔都不能差。”出于谨慎,程立和团队在去掉支付宝系统中其它所有的IBM小型机后,还保留着这台小机管理最重要的账户资金。”时间回溯到2012的“双十一”大促的凌晨,很多消费者不断点击支付按钮,却常常看到支付宝的排队页面。消费者以为支付宝系统崩溃了,实际上,当时是因为支付宝仅存的这台小机的承载能力有限,在高峰交易期,系统只能对来不及处理的请求进行排队,这种排队带来的延迟产生了巨大的用户体验障碍。“双十一”的痛苦经历,让程立最后下定决心去掉这最后一台小机,最终,支付宝技术团队设计出了基于互联网技术的分布式交易处理方案,通过一次完美的项目执行去除了支付宝、同时也是阿里的最后一台IBM小机。2013年的双十一是程立经历过的最轻松一次“大促”,再也不担心有任何技术节点会制约业务的发展了。在阿里进行“去IOE”同时,另外一项重要的技术研发也在同时上演。日,飞天研发启动。“飞天”是什么?飞天是阿里的大规模分布式系统,几乎等同于整个阿里云的整个技术体系。技术网站博客园对飞天——这种分布式技术有一段生动的描述:当你只有六七条鱼的时候, 一个小型鱼缸就够了;可是过一段时间新生了30多条小鱼,这个小缸显然不够大了。如果买一个大缸,把所有水草啊、布景、加热棒、温度计都从小缸里拿出来,重新布置到大缸。这个工程要花费很多时间,尤其水草,纠结在一起很难分开。分布式系统可以帮你在这个小缸旁边接了一个同样的小缸,两个缸联通。鱼可以自动分散到两个缸。帮你越过复杂的系统扩建过程,省掉了很多时间和设备成本。阿里旧的“IOE”架构,本质上代表着基于传统高端设备、大型数据库等软硬件的集中式架构。陈旧集中的技术无法应对阿里爆炸式业务增长,如果在IT系统中有一点出现问题,整个架构都面临危险。飞天这种分布式系统集中大量的通用服务器在一个系统中,比单个的大型集中式系统运行速度更快。而且,把计算能力分散到众多机器上,单个节点的故障只会影响一台机器,其它机器可以照常工作。2013年3月,阿里技术保障部给公司高层突然发信一封:“云梯1要撞墙了!”云梯1是阿里内部另一个基于Hadoop的分布式集群系统。保障部的员工发现按照现有数据增量和未来业务增长的情况,阿里的存储和计算能力将在3个月内达到瓶颈,数据业务面临停滞,必须将飞天系统快速扩建起来。飞天的快速扩建要克服很多难题,国内有大规模分布式系统经验的人不多,阿里的技术团队里只有少数做过或用过分布式系统,所以整个研发的过程是一个探索学习的过程,只有遇到实际的问题,团队才会对工程上的难题有所领悟。其次,在系统设计的时候,工程师会设定相应的工作场景、硬件环境的完备性。但在实际生产环境下,各种硬件环境、参数配置,往往会打破设计时的假设,因此总是会碰到各种问题。在解决这些问题过程中积累的经验,显然不是教科书上可以学到的理论。这个超大计算机也有自己的软肋,她要比单个服务器的可用性和可靠性要高很多,才能保证服务“永远”不中断,数据“永远”不丢失。经过4个月的不懈努力,飞天资深技术总监唐洪和他的团队将5000台飞天集群部署成功。阿里成为国内首个单集群达到5000台规模的公司,在此之前,全球也只有Google、Facebook等顶级公司可以按照5000台机器来划分集群规模。飞天能做什么?用唐洪的话来说:“它有100PB级别的硬盘,可以存放几百亿的网页;可以给几十万的用户,每人提供几百G的存储;再或者是拥有了一台万核以上的超级计算机,普通计算机一个月需要完成的渲染作业在这个计算机上只需要几分钟就可以完成。”“双十一”云备战飞天资深技术总监唐洪“去IOE”与“飞天5K”技术成功后,阿里集团内部所有的重量级业务都已迁移到云计算平台上。“聚石塔”、 “聚宝盆”、“阿里金融”的大数据研发以及YunOS智能移动操作系统等,都运行在阿里云飞天平台上。淘宝、支付宝等各业务部门的底层技术也架设在飞天平台上。阿里金融基于云计算,几分钟之内就能让贷款发出,每天处理上百TB的交易数据,而且保证了每一笔贷款发放的计算成本相同。淘宝也基于阿里云推出电商云——聚石塔,为“双十一”服务。阿里云推出电商云—聚石塔,为“双十一”服务。2012年“双十一”,通过聚石塔,阿里云支撑了天猫20%的交易额,2013年这一数字上升到75%。2013年“双十一”大战前3个礼拜,天猫技术总监庄卓然接到集团通知:大促结束后,他将要被抽调到无线事业部。对他而言,3年的“双十一”备战完美收官,又将迎接新的挑战。2013年,阿里第5个“双十一”,天猫和淘宝单日成交额达到362亿元(根据招股书数据),网站PV过百亿,76%的商家处理工作在聚石塔云计算平台完成,且无一漏单,无一故障。支付宝成功支付1.88亿笔,最高每2分钟支付79万笔。用庄卓然的话:“疯狂业务数据的背后,是对阿里技术团队一次整体大阅兵。”这场阅兵检验了阿里“去IOE”和云计算的成果。3年备战“双十一”,庄卓然每年都重复着高效的工作时间表。5月底,投入产品和技术准备。筹划新的突破点和创意同时启动,投入到一些较长周期的研发工作。8月底,真正的考验来临,冲刺时间段,他每晚习惯性要到两点多才能睡着。有时候,想一些技术难题觉得有突破时,一睁眼就到天亮。庄卓然自己形容自己的工作状态像“精神分裂”一样,左脑思考的是系统的稳定性建设,右脑不停地找寻当前系统的命门和瓶颈。每一次大促都是对团队技术能力的考验。2011年和2012年的“双十一”前夜,庄卓然和技术团队都非常不踏实,即便该做的技术准备都做了,但面对“双十一”巨大的突发流量,只能尽力保证一个完善的技术机制,抓大放小。“双十一”的最大难点在于峰值流量一压过来,系统要扛得住千万人同时在线和每秒数亿笔交易。淘宝和天猫的技术体系非常庞杂。每一笔交易都涉及到银行、商家、淘宝自身和网络等多个系统的处理能力。交易信息层层传递过程中,某一个技术细节执行不到位,交易就可能失败。比如,当用户量大到一定程度,系统让用户排队,如果这个功能失效,一连串的上下游系统都会受到影响。淘宝的几万台机器,上千个应用系统复杂交错,很难实景模拟所有的用户行为,比如1000万人同时在线,同时下单。2013年,庄卓然对“双十一”技术的确定和把握,一部分来源于技术团队已经能实现在短期内集结一大批虚拟用户去做压力测试;另一部分是淘宝天猫后台和大多数商家后台已经上云。淘宝、天猫上大概近千万家商家,其中大部分的商家都有自己的ERP系统。消费者买一个东西需要点击购买,然后进行支付。这个动作会指向两条IT路径:一是连接支付宝,保证有钱可以完成支付;另一条则是进入卖家的ERP,卖家需要知道自己是否有库存,并减掉相应的货品数量。交易从淘宝或天猫链接到卖家后台系统的过程中,如果卖家IT系统薄弱,数据交换可能会因为网络等原因不通畅导致交易失败。庄卓然详细讲解了这一过程:“聚石塔提供的云推送功能在第一时间将交易订单同步部署进商家的ERP、物流、CRM软件中,并提供动态弹性扩容和安全保护。消费者下单到发货、发票打印,所有信息流转都在云上完成。”云上生态系统阿里云业务总经理陈金培天猫技术总监庄卓然聚石塔只是阿里云应用的一个侧面,阿里长在云上的商业生态体系已经初步形成。王坚曾说过:“阿里云平台在内部的代码就是飞天。一个平台的力量有多大,可以造就的东西就有多大,这是过去阿里云为什么花费这么大力气做飞天的原因。”飞天以Web API的方式,向外提供计算、存储和大规模数据处理等云计算服务,建立起庞大的云计算生态体系。未来的互联网将成为一个果园,各行各业像是一棵棵果树,如何为果树提供良好的养分服务,决定了果园生态的丰富程度。云计算就是牵引传统行业互联网化的引擎。数据将成为云生态里的生产资料,通过强大的计算能力进行实时分析和交互,可以催生出无数新的商业模式。在阿里刚刚递交的招股说明书中写道:月,阿里云计算服务等收入达5.6亿人民币,占总收入的1.4%,同比增长15.7%,并且已经拥有98万用户。阿里云快速地将阿里和不同行业企业联系到一起,比如消费电子、公共卫生、能源管理、媒体、电子商务、电子政务、移动互联网等。阿里云客户中有传统的互联网公司,也有移动互联网公司,比如手游公司;还有一些传统企业,比如杭州九阳股份有限公司,这些传统企业的IT逐渐向云迁徙。例如,2013年,阿里与美的集团的深入合作,是基于天猫商城、大数据和阿里云计算平台的多维度合作,这种借助云和数据的能力,让传统企业能与互联网走向更深的耦合。阿里云还在借助ISV合作伙伴,帮助更多的传统企业上云。2013年,东软将旗下SaCa、UniEAP等软件产品部署在阿里云上;普元推出基于阿里云的EOS-Cloud平台,直接在云上支撑企业软件开发。这些ISV厂商有大量传统企业用户积累,这种深入合作撬动了一批传统企业上云。2014年,5月8日,阿里云宣布香港数据中心正式投入使用,阿里云正与Amazon AWS、、微软Azure展开正面竞争,阿里的云生态体系部署已经蔓延到国外。阿里云业务总经理陈金培认为:“所有的产业竞争都是生态系统的竞争,你要么依存于一个生态,要么自己发展出来一个生态。”马云搭建的基于数据和云的生态,已初步形成。2013年初开始,阿里将其战略调整为“平台、金融、数据”三大业务。云计算是金融、数据的基础。2014年春,马云的内部信件再次明确了阿里的未来战略:走向激活生产力为目的的DT(data technology)数据时代。马云的策略是让数据、云计算成为中国商业的基础设施。(文/张宇婷)【阿里巴巴的技术节奏】2007年以互联网为平台的商务管理软件公司阿里软件成立。2008年王坚加盟阿里成为集团首席架构师阿里巴巴集团研发院成立飞天研发工作开始2009年阿里软件与阿里巴巴集团研发院合并阿里云计算成立,在杭州、北京、硅谷设研发中心和运营机构Oracle产品构建的RAC集群成为国内最大的数据仓库淘宝拥有第一个分布式计算系统Hadoop集群,规模300台2010年阿里云第一个云计算机房启用阿里巴巴数据量大爆炸的一年,RAC集群不能满足业务发展速度,迁移到Hadoop2011年阿里云官网上线,“飞天”开始对外提供云服务阿里巴巴云智能手机操作系统云OS正式发布2012年“冰火鸟”启动建立支持集团数据化运营,自主研发的分布式计算平台对全集团提供服务2013年阿里云计算与万网合并为新的阿里云计算公司“飞天”集群达到5000台,100T数据TearSort算法30分钟完成,比当时的世界纪录快2倍以上2014年阿里云发布移动云平台-聚无线香港数据中心正式启用(文/张宇婷)欢迎关注思路网(微信号:isiilu)【找电商服务,试试看】直接回复你想了解的电商服务关键词,如“电商ERP、代运营”等,即可获取相关服务信息,或直接拨打400-免费咨询思路小二。百度“思路网”也可以快速找到我们哦。
【温馨提示】思路网倡导尊重与保护知识产权。如发现本站文章存在版权问题,烦请提供版权疑问、身份证明、版权证明、联系方式等发邮件至,我们将及时处理。本站文章仅作分享交流用途,作者观点不等同于思路网观点。用户与作者的任何交易与本站无关,请知悉。
热门文章标签
电商服务推荐
电商服务招标
版权所有 思路
保留所有权利
Copyright & EBrun, Inc. All Rights Reserved.
京ICP证070369号 | 京ICP备号 | 京公网安备 87
北京亿商联动国际电子商务股份有限公司
地址:北京市石景山区鲁谷路74号中国瑞达大厦1701 电话:010-
打开微信“扫一扫”打开网页后点击屏幕右上角分享按钮
选择需要的电商服务类别
店铺外包(代运营、设计...)
软件工具(ERP、CRM...)
仓配物流(管理、配送…)
外贸出口(推广、管理…)
其它服务(请在备注说明)}

我要回帖

更多关于 oracle 11g 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信