爆料天猫286亿海量图片存款和储蓄与管理架构,商用软件未必消除难点

作者:亚搏app官网    发布时间:2019-11-08 22:33    浏览:139 次

[返回]

第七届开源中国开源世界高峰论坛29日下午的演讲中,阿里集团的高级研究员与副总裁核心系统负责人章文嵩先生给大家带来了“开源+自主开发淘宝软件基础设施构建实践”的主题演讲。

8月27日下午,在IT168系统架构师大会存储与系统架构分论坛上,淘宝网技术委员会主席,淘宝网核心工程师章文嵩向我们详细介绍了淘宝网图片处理与存储系统的架构。章文嵩博士的演讲日程包括了图片 1淘宝的整个系统架构、淘宝图片存储系统架构,淘宝网独立开发的TFS集群文件系统,前端CDN系统以及淘宝网在节能服务器方面的应用和探索。

章文嵩的演讲主要分享了阿里巴巴在底层基础平台建设方面的一些经验。从整体上看分为如下几个议题,首先介绍了淘宝网的一些情况,然后介绍了淘宝网目前在软件基础设施中的部署情况。

图片 2
LVS创始人,淘宝网技术委员会主席,淘宝网核心工程师章文嵩先生

图片 3

  本文侧重介绍淘宝网后台的图片存储系统架构、包括TFS集群文件系统,以及前端处理服务器架构。该系统前端CDN架构,以及淘宝网在节能服务器应用方面的探索,请参考:
  淘宝商城286亿图片访问的CDN架构全解析 
  教你省钱!淘宝总结节能服务器应用场景

阿里集团的高级研究员与副总裁核心系统负责人章文嵩

  解决海量并发小文件的系统噩梦

提到淘宝网,可能很多人都知道他是一个网络购物的代名词,有市场报告显示,去年淘宝网交易额是7800多亿,淘宝网占7层份额,淘宝网上面大概有七八百万卖家创造了直接的就业机会,职业就业机会270多万个,淘宝网的网络流量,目前基本上在13名左右。第一名是谷歌,第二名是FACEBOOK,这个排名会随时变动,比如做大促销的时候,有可能冲到11名,过年网络购物少的时候可能降到18名,目前国内是第3名。支撑网站排名背后的流量一天现在大概700多万个访客,跟踪帐户登陆,有700多万个,去年双12大促一天有1.25亿人访问,那时候CDN访问流量856G,整个淘宝网页一天25亿,淘宝网站上有800多个应用。针对这样的规模搭建基础设施也并不容易,我淘宝网的基础设施每年在不断的发展,可能以百分之七八十速度在增长。

  对于淘宝网这类型访问量极高的电子交易网站来说,对图片系统的要求和日常的照片分享完全不在一个级别。日常照片分享往往集中在几个有限的亲朋好友之间,访问量不会特别高,而淘宝网商铺中的商品照片,尤其是热门商品,图片的访问流量其实是非常大的。而且对于卖家来说,图片远胜于文字描述,因此卖家也格外看重图片的显示质量、上传时间、访问速度等等问题。根据淘宝网的流量分析,整个淘宝网流量中,图片的访问流量会占到90%以上,而主站的网页则占到不到10%。

淘宝的基础设施,最上面是CND系统,在全国布很多点,让用户访问家门口的机器,中间是交易平台,背后是基础设施软件,存储系统,数据库,包括海量数据处理平台和资源调度平台,左侧有淘宝的搜索,淘宝上有十几亿商品,用户进来要搜索,我们要做到实时搜索,比如用户变更了价格,在搜索引擎里几秒钟要反映出来,卖家变更一些信息之后往往自己上去查,如果查不到自己就会投诉;右侧是广告系统,是收入的主要来源,还有数据挖掘平台。在基础软件上,我们分很多层次来做,最底下的是硬件,我们对硬件进行定制,我们对各种储存介质非常了解,我们在低功耗处理器、CPU方面定制专门机器,降低功耗比,或者降低成本。

图片 4
淘宝网电子商城首页截图,淘宝网的后端系统上保存着286亿多个图片文件,淘宝网整体流量中,图片的访问流量要占到90%以上。且这些图片平均大小为17.45KB,小于8K的图片占整体图片数量61%,整体系统容量的11%

我们有一个内核的团队,几万台服务器支撑淘宝网,我们根据应用的特点做优化,过去Apache用的比较多,我们还有数据库团队,这是目前在单机上做的事情。上面是分布式系统,多机环境,有分布式存储,像TFS、分布式表格系统,还有图像搜索团队,图像搜索输入一张照片,我们有CDN分发系统,还有海量数据的计算,包括旺旺平台,现在将近一千万同事在线,虚拟化管理,负载均衡,包括网络的解决方案。现在采用的软件基本都是开源加自主开发的,比如CDN,我们可以说它是世界上最大的面向图像的CDN系统,送照片就送856G流量,上面都是拿开源软件做的,我们做成了一个自主开发的CDN系统,今年会建到2400G,按照淘宝流量的增长,能力到2400G,实际的量可能会在2000G左右。

  与此同时,这些图片的存储与读取还有一些头疼的要求:例如,这些图片要求根据不同的应用位置,生成不同大小规格的缩略图。考虑到多种不同的应用场景以及改版的可能性,一张原图有可能需要生成20多个不同尺寸规格的缩略图。

TFS是自主开发的分布式对象存储系统,目前有6.2P存储空间,实际用了4P多,今年会建设到12P。每G存储成本会逐渐下降,今年到2.5元。Oceanbase,一张表格里大概有120亿条的收藏记录。核心数据库,采用开源的MySQL,机上高速的非易先存储,以及多层级优化。旺旺平台,自主开发。底层的支撑软件,在OpenJDK基础上开发和维护Taoboo JVM,在LVS基础上实现负载均衡解决方案,用开源软件实现了高流量的网络镜像项目,可以说淘宝整个平台是建在开源软件加自主开发的基础上,核心系统没有商用软件,淘宝不是第一天是这个样子的,我们讲一个事例。

  淘宝整体图片存储系统容量1800TB(1.8PB),已经占用空间990TB(约1PB)。保存的图片文件数量达到286亿多个,这些图片文件包括根据原图生成的缩略图。平均图片大小是17.45K;8K以下图片占图片数总量的61%,占存储容量的11%。

淘宝最早是做交易网站的,一块是都是花钱解决问题,最终花钱解决不了问题了,不得不自己走上这条道路,我们可以拿三个事例来说明,图片存储,淘宝上有很多商品,卖家拍了很多商品照片,平均一个商品可能有三四十张以上的图片,一开始花钱解决问题,买的是NAS系统,然后往里面放,到2006年的时候,从最低端升级到最高端设备,因为是笑图片,最高端的存储控制没用完,但是文件个数已经用爆了,数目不够,工程师说一台放不下买两台,两台放不下放四台,我们自己知道这个不是解决办法,因为成本很高,那时候10T存储空间就要几百万,我们自己做了一个面向图片存储的管理系统,在架构上我们做了一些取舍,分布式文件系统由原数据服务器、数据服务器两部分组成,对于互联网图片数据来说,用户并不关心文件名是什么、路径是什么,只是在网页里能把图片展示出来,我们把目录空间抛弃掉了,我们做了取舍,没有目录空间,做了对象存储,你要放进来一个对象,自己还不能起名字,是我们赋予的,这样可以做到非常高速,比如中间有一个图片名字,一般人看不懂,原数据可以变的很简单,直接可以映射到物理机器,原数据很简单,数据量很少,分布式系统里原数据一定是最终瓶颈,做的越简单可扩展性越好。

  这就给淘宝网的系统带来了一个巨大的挑战,众所周知,对于大多数系统来说,最头疼的就是大规模的小文件存储与读取,因为磁头需要频繁的寻道和换道,因此在读取上容易带来较长的延时。在大量高并发访问量的情况下,简直就是系统的噩梦。

上线一用规模可能就大了一个数量级,后续逐渐优化,增加各种功能,现在TFS也开源了,2.0版本,我们还在持续优化,我们内部都有指标。淘宝CDN系统,一开始也是花钱解决问题,最早淘宝CND系统都是买商用负载均衡器,因为是图片,随即访问,后来逐步改造,用开源的软件,包括混合存储,原来建6G要花掉200多万,去年建10G35万就可以做到了,2010年光KPI就节约了1亿多,因为规模大了,稍微优化一下就可以节约1亿多,这里面我们提了很多做法,以后我们会有大型的节点,在调度力度和用户体验上都会做进一步优化。

 

第三是淘宝核心数据库,最后一个被拔掉的,最早拿IBM小型机、思科商用数据库、EMC高端存储,好处是功能比较强大,缺点就是比较贵。2008年开始使用MySQL数据库,2011年组建了自己MySQL开发团队,开发团队只有8人,去年最早把商品库换掉了,十亿多个商品,交易数据库过去2000万IOE解决方案,那时候每秒钟只能做3000笔交易,2011年原定目标是平台要做到5000笔交易就能支撑业务的发展。

  分析自主研发和商用系统的经济效益

后来我们用MySQL加上优化,一台机器做到1万笔交易,当然了不是普通的PC服务器,是9万元的PC服务器,再加上FLASH卡,总共不到12万元,整个淘宝平台的交易能力一秒钟能做到16万笔交易,商用软件已经不能满足大规模系统的需要,开源自主开发有很好的可控性和可扩展性,我们有个规模效应,比如这个图横坐标是规模,规模由小变大的时候,一开始自己研发,投入的起点可能比较高,随着规模增大,斜线不高,如果一开始租或者买,投入的起点已经必定低,随着规模增长,斜率比较高,两条斜线肯定相交于一点,过了这个交差点自己做一定划算,我们在商用软件上碰上问题,商用厂商并不全力支持我们,全世界可能就我们一家是这种用法,逼着规模大的不得不自己做。

  淘宝网成立于2003年,在整个系统的构建和规划上也做过相当多的尝试和探索。

过去我们使用了大量开源软件,也在开源基础上做改进、定制,把工作成果回馈给开源社区,在Linux内核上,目前内核贡献量在全世界排115名。我们也建设了开源的平台,把淘宝大部分数得上名字的基础软件都开源出来了,我们有这样的开源平台,不光软件开源,硬件也做了定制的低功耗服务器,我们做了绿色计算网站,服务器定制只是其中一块,数据中心、机房的基础设施、机柜的定制可能是绿色计算很大一块,建这样的网站,尤其是国内,用中文交流可能更方便,可以在一块推进整个绿色计算的发展。

  下图是淘宝网2007年之前的图片存储系统。淘宝网之前一直采用的商用存储系统,应用NetApp公司的文件存储系统。随着淘宝网的图片文件数量以每年2倍(即原来3倍)的速度增长,淘宝网后端NetApp公司的存储系统也从低端到高端不断迁移,直至2006年,即时是NetApp公司最高端的产品也不能满足淘宝网存储的要求。

小结,淘宝是开源系统的受益者,并积极参与开源生态系统的建设,促进开源生态系统的发展,积累更好的口碑,凝聚人才,迎接未来更大的技术挑战。淘宝公司希望以更开放的方式与世界一起进行技术创新。

图片 5
淘宝网2007年以前的图片存储系统架构图,由于淘宝网图片速度已每年2倍的速度增长,商用系统已经完全不能满足其存储需求,目前淘宝网采用自主研发的TFS集群文件系统来解决海量小图片的读取和访问问题

...

  章文嵩博士在这里总结了几点商用存储系统的局限和不足:

  首先是商用的存储系统没有对小文件存储和读取的环境进行有针对性的优化;其次,文件数量大,网络存储设备无法支撑;另外,整个系统所连接的服务器也越来越多,网络连接数已经到达了网络存储设备的极限。此外,商用存储系统扩容成本高,10T的存储容量需要几百万¥,而且存在单点故障,容灾和安全性无法得到很好的保证。

  谈到在商用系统和自主研发之间的经济效益对比,章文嵩博士列举了以下几点经验:

  1.商用软件很难满足大规模系统的应用需求,无论存储还是CDN还是负载均衡,因为在厂商实验室端,很难实现如此大的数据规模测试。

  2.研发过程中,将开源和自主开发相结合,会有更好的可控性,系统出问题了,完全可以从底层解决问题,系统扩展性也更高。

图片 6
自主研发和采用商用系统的经济效益对比

  3.在一定规模效应基础上,研发的投入都是值得的。上图是一个自主研发和购买商用系统的投入产出比对比,实际上,在上图的交叉点左边,购买商用系统都是更加实际和经济性更好的选择,只有在规模超过交叉点的情况下,自主研发才能收到较好的经济效果,实际上,规模化达到如此程度的公司其实并不多,不过淘宝网已经远远超过了交叉点。

  4.自主研发的系统可在软件和硬件多个层次不断的优化。

 

  TFS 1.0版本的集群文件系统

  从2006年开始,淘宝网决定自己开发一套针对海量小文件存储难题的文件系统,用于解决自身图片存储的难题。到2007年6月,TFS(淘宝文件系统,Taobao File System)正式上线运营。在生产环境中应用的集群规模达到了200台PC Server(146G*6 SAS 15K Raid5),文件数量达到上亿级别;系统部署存储容量: 140 TB;实际使用存储容量: 50 TB;单台支持随机IOPS 200+,流量3MBps。

图片 7
淘宝集群文件系统TFS 1.0第一版的逻辑架构,TFS最大的特点就是将一部分元数据隐藏到图片的保存文件名上,大大简化了元数据,消除了管理节点对整体系统性能的制约,这一理念和目前业界流行的“对象存储”较为类似。

  图为淘宝集群文件系统TFS 1.0第一版的逻辑架构:集群由一对Name Server和多台Data Server构成,Name Server的两台服务器互为双机,就是集群文件系统中管理节点的概念。

  • 每个Data Server运行在一台普通的Linux主机上

  • 以block文件的形式存放数据文件(一般64M一个block)

  • block存多份保证数据安全

  • 利用ext3文件系统存放数据文件

  • 磁盘raid5做数据冗余

  • 文件名内置元数据信息,用户自己保存TFS文件名与实际文件的对照关系–使得元数据量特别小。

  淘宝TFS文件系统在核心设计上最大的取巧的地方就在,传统的集群系统里面元数据只有1份,通常由管理节点来管理,因而很容易成为瓶颈。而对于淘宝网的用户来说,图片文件究竟用什么名字来保存实际上用户并不关心,因此TFS在设计规划上考虑在图片的保存文件名上暗藏了一些元数据信息,例如图片的大小、时间、访问频次等等信息,包括所在的逻辑块号。而在元数据上,实际上保存的信息很少,因此元数据结构非常简单。仅仅只需要一个fileID,能够准确定位文件在什么地方。

  由于大量的文件信息都隐藏在文件名中,整个系统完全抛弃了传统的目录树结构,因为目录树开销最大。拿掉后,整个集群的高可扩展性极大提高。实际上,这一设计理念和目前业界的“对象存储”较为类似,淘宝网TFS文件系统已经更新到1.3版本,在生产系统的性能已经得到验证,且不断得到了完善和优化,淘宝网目前在对象存储领域的研究已经走在前列。

 

  TFS 1.3版本的集群文件系统

  到2009年6月,TFS 1.3版本上线,集群规模大大扩展,部署到淘宝的图片生产系统上,整个系统已经从原有200台PC服务器扩增至440台PC Server(300G*12 SAS 15K RPM) + 30台PC Server (600G*12 SAS 15K RPM)。支持文件数量也扩容至百亿级别;系统部署存储容量:1800TB(1.8PB);当前实际存储容量:995TB;单台Data Server支持随机IOPS 900+,流量15MB+;目前Name Server运行的物理内存是217MB(服务器使用千兆网卡)。

图片 8
TFS 1.3版本逻辑结构图

  图为TFS1.3版本的逻辑结构图,在TFS1.3版本中,淘宝网的软件工作组重点改善了心跳和同步的性能,最新版本的心跳和同步在几秒钟之内就可完成切换,同时进行了一些新的优化:包括元数据存内存上,清理磁盘空间,性能上也做了优化,包括:

  完全扁平化的数据组织结构,抛弃了传统文件系统的目录结构。

  在块设备基础上建立自有的文件系统,减少EXT3等文件系统数据碎片带来的性能损耗

  单进程管理单块磁盘的方式,摒除RAID5机制

  带有HA机制的中央控制节点,在安全稳定和性能复杂度之间取得平衡。

  尽量缩减元数据大小,将元数据全部加载入内存,提升访问速度。

  跨机架和IDC的负载均衡和冗余安全策略。

  完全平滑扩容。

  在后面“图片服务器部署与缓存”一页中详细介绍了淘宝网整个图片处理系统的拓扑图。我们可以看到:TFS在淘宝的部署环境中前端有两层缓冲,到达TFS系统的请求非常离散,所以TFS内部是没有任何数据的内存缓冲的,包括传统文件系统的内存缓冲也不存在。

  TFS主要的性能参数不是IO吞吐量,而是单台PCServer提供随机读写IOPS。由于大家硬件型号不同,当然也是因为一些技术保密的原因,淘宝网很难给出一个参考值来说明性能。但基本上可以达到单块磁盘随机IOPS理论最大值的60%左右,整机的输出随盘数增加而线性增加。

 

  开发中的TFS2.0与开源TFS

  TFS 2.0已经在开发过程中,主要解决的问题是大文件存储的难题。TFS最早开发的时候针对小文件频繁并发读取的难题而开发,设计的块大小是64MB,意味着每个文件小于64MB,这对于一般的图片存储来说完全足够用了,但对于大文件存储还有一些瓶颈。

  TFS 2.0将重点针对大文件跨越块的存储进行优化。此外,还包括SSD、SAS硬盘不同硬盘特性的应用优化。根据淘宝网的资料数据,SSD的存储成本大约是20¥每GB左右,SAS硬盘的存储成本约在 5-6¥每GB,SATA盘的每GB成本不到1¥。随着对应用性能的要求提升,应用SSD是未来的趋势,针对不同硬盘的存取特性进行优化是十分必要的。

  此外,章文嵩宣布,TFS将在9月份完全开源,完全开源则意味着淘宝网将提供所有的源代码,开源版本的TFS将与淘宝网线上应用的系统完全一致。

 

  图片服务器部署与缓存

  下图为淘宝网整体系统的拓扑图结构。整个系统就像一个庞大的服务器一样,有处理单元、缓存单元和存储单元。前面已经详细介绍过了后台的TFS集群文件存储系统,在TFS前端,还部署着200多台图片文件服务器,用Apatch实现,用于生成缩略图的运算。

  这里需要补充一点,根据淘宝网的缩略图生成规则,缩略图都是实时生成的。这样做的好处有两点:一是为了避免后端图片服务器上存储的图片数量过多,大大节约后台存储空间的需求,淘宝网计算,采用实时生成缩略图的模式比提前全部生成好缩略图的模式节约90%的存储空间,也就是说,存储空间只需要后一种模式的10%;二是,缩略图可根据需要实时生成出来,更为灵活。

图片 9
淘宝网图片存储与处理系统全局拓扑,图片服务器前端还有一级和二级缓存服务器,尽量让图片在缓存中命中,最大程度的避免图片热点,实际上后端到达TFS的流量已经非常离散和平均

  图片文件服务器的前端则是一级缓存和二级缓存,前面还有全局负载均衡的设置,解决图片的访问热点问题。图片的访问热点一定存在,重要的是,让图片尽量在缓存中命中。目前淘宝网在各个运营商的中心点设有二级缓存,整体系统中心店设有一级缓存,加上全局负载均衡,传递到后端TFS的流量就已经非常均衡和分散了,对前端的响应性能也大大提高。

  根据淘宝的缓存策略,大部分图片都尽量在缓存中命中,如果缓存中无法命中,则会在本地服务器上查找是否存有原图,并根据原图生成缩略图,如果都没有命中,则会考虑去后台TFS集群文件存储系统上调取,因此,最终反馈到TFS集群文件存储系统上的流量已经被大大优化了。

  淘宝网将图片处理与缓存编写成基于Nginx的模块,淘宝网认为Nginx是目前性能最高的HTTP服务器(用户空间),代码清晰,模块化非常好。淘宝网使用GraphicsMagick进行图片处理,采用了面向小对象的缓存文件系统,前端有LVS+Haproxy将原图和其所有缩略图请求都调度到同一台Image Server。

  文件定位上,内存用hash算法做索引,最多一次读盘。写盘方式则采用Append方式写,并采用了淘汰策略FIFO,主要考虑降低硬盘的写操作,没有必要进一步提高Cache命中率,因为Image Server和TFS在同一个数据中心,读盘效率还是非常高的。

 

  演讲人简介

  章文嵩博士是淘宝网的研究员,主要负责基础核心软件研发、推进网络软硬件方面的性能优化、搭建下一代高可扩展低碳低成本淘宝电子商务基础设施。他也是开放源码及Linux内核的开发者,著名的Linux集群项目--LVS (Linux Virtual Server)的创始人和主要开发人员,LVS集群代码已在Linux 2.4和2.6的官方内核中。在设计和架构大型系统、系统软件开发、Linux操作系统、系统安全和软件开发管理上有着丰富的经验。他一直在自由软件的开发上花费时间,并以此为乐。

搜索