云存储技术博客：光头老蒋

分布式文件系统在电子交易网站中会有广泛的用途，例如淘宝网，现在的交易额已经超过了600亿/每天，这是一个什么概念，香港一天的消费品市场也就600亿，也就是说一个淘宝已经超过香港了，而要达到这么大的交易量，交易的商业是上百亿件的，这样对商品图片的访问量就会很大。日常照片分享往往集中在几个有限的亲朋好友之间，访问量不会特别高，而淘宝网商铺中的商品照片，尤其是热门商品，图片的访问流量其实是非常大的。而且对于卖家来说，图片远胜于文字描述，因此卖家也格外看重图片的显示质量、上传时间、访问速度等等问题。根据淘宝网的流量分析，整个淘宝网流量中，图片的访问流量会占到90%以上，而主站的网页则占到不到10%。

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

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

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

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

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

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

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

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

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

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

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

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

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

 

1. 架构分析

 

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。

淘宝集群文件系统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(服务器使用千兆网卡)。

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是未来的趋势，针对不同硬盘的存取特性进行优化是十分必要的。

苹果从来就是自成一个体系，哪怕做云也一样，现在在机场经常见到iphone，ipad，imac一个都不能少的人。而把这3个东西的数据统一一下对苹果来说也是轻而易举的事情，今天老蒋要讨论的是其中一个新的生意想法，把盗版音乐变正版的生意。iTunes Match可以洗白你的盗版音乐库，iCloud可自动同步一切到云端。Google 和 Amazon 的云端音乐服务都要求用户自己上载音乐，这将是一个耗时的麻烦活，而苹果的云端映射则方便多了。云端映射的上限是 25，000 首歌曲。试想一下上载需要的时间，我们不是都拥有 Google 速度的。

盗版是否可以变正版？

与之前的传言不同，iTunes Match 的歌曲不要求一定是从 iTunes 下载，也可以是 CD 中提取的歌曲，网络下载的歌曲，甚至那些通过不那么合法的手段获得的歌曲。如果 iTunes Store 里发现了一个对应歌曲，这个歌曲将自动填到 iCloud 里，格式是 256 Kbps，DRM-free 的 iTunes Plus ，就是说，即使你音乐库中是 128 Kbps 的 mp3，也可以获得 iTunes Plus 版。盗版可以变正版，而且可以获得质量提升。

 

iCloud是Apple向云端进发的武器，它可以自动备份iOS设备的一切，还可以同步iOS设备、Mac和PC的图片、音乐和文档。乔帮主想利用iCloud淡化计算机领域的文件概念，你不必考虑将某个文件复制到另外一个设备里继续编辑或使用──iCloud云端会自动帮你完成这项工作。

具体到音乐人和音乐软件，我们可以期待未来的音乐软件都可自动将工程文件上传到云端，一来可以进行备份，二来可以自动同步到其它的电脑或iOS设备里继续编辑，你甚至可以将一个Windows版的音乐软件制作的工程同步到Mac里继续编辑（只要它同时有Windows和Mac版即可）。

尽管iCloud只给每个人分配5GB的空间，但它是完全免费的！目前还不知道是否可以付费购买更多空间，但我想这个是完全可以有的。

我前面有提到音乐也可以自动传到云端，就是说iTunes里买的音乐可以同步到多台iOS设备、Mac和PC电脑里来欣赏，这也是免费的，一次购买，多处收听。不过更给力的应该是iTunes Match功能！

iTunes Match可自动扫描你电脑里的MP3和AAC音乐，与iTunes云端音乐库里的1800万首音乐进行匹配，如果发现一样的音乐，自动就算作是你购买的音乐，然后瞬间同步到多台iOS设备、Mac和PC电脑里来欣赏。这个服务的目的是在几乎一瞬间的时间，自动识别出你自己将CD转换成MP3的音乐，把它们也同步到所有设备里，而不用你亲自用传统的文件同步的形式给复制到每台设备里收听。且将你自己转换的低质MP3自动匹配为高质量256kbps AAC进行同步。

尽管这个iTunes Match服务每年要支付24.99美元享受，但它却可以洗白你的盗版音乐！

每年24.99美元，洗白硬盘里数GB的盗版MP3，变成高质量的正版的音乐。这是各位盗版党（包括我）的福音！就我个人来讲，会把一些下载了感觉很经典的音乐买来CD珍藏，但我也确实下载了很多MP3而没有买CD，借此机会，花24.99美元洗白一下，也算弥补一下罪过。如果你有10000首盗版音乐，那老蒋要恭喜你了，你只需话0.002499元/一首歌曲的价格，把所有音乐变成正版，尽管你连24.99美元都不想给，依然可以使用你的音乐问题。

有人说iTunes Match会摧毁整个音乐界，我并不这么认为。作为一个拥有盗版音乐的人，已经几乎可以肯定他不会去购买CD或者将已经下载的盗版删掉去花钱到iTunes里买正版的音乐，唱片公司和版权所有人已经无法从他已有的盗版音乐上抠出一分钱，那么就谈不上有利益上的损失。付费的iTunes Match只是方便他在多个设备之间自动同步音乐而已，这个业务每年都需要支付24.99美元就已经保证了不会被滥用。不管是一直买正版还是一直买盗版的人，这笔钱都是额外的费用。如果将盗版应用洗白成正版，那开发者会有损失（因为盗版无法像正版那样可以免费升级），音乐又不像iOS应用有免费升级这么一说（做个remix就又卖一分钱，跟应用开发者比起来很孙子哈？）。

简而言之，iTunes Match会对大部分一直下盗版音乐的人没任何吸引力，不会改变任何事情。对部分一直下盗版而苦于在多台设备同步的人来说，会让他们额外每年吐出24.99美元，而他们几乎不买或很少买正版，音乐界也不会因为iTunes Match导致少卖出多少唱片。唯一的担心可能就是那些一直坚持买正版音乐的人，看到盗版党用iTunes Match洗白音乐感到很不爽。但其实他们都可以忍受盗版党一直免费收听音乐而自己一直坚持付费买音乐了，也不可能对iTunes Match洗白音乐感到不爽吧？因为他们知道那样的洗白并不是真的白了，只是理论上的白了，他们依然没有支付足够多的钱给版权所有者和音乐制作者，正版购买者深知这一点才坚持购买音乐的，所以iTunes Match不会让他们感到不爽。

大家都怎么看icloud呢？

比较好的一篇3PAR的文章，转一下，3par的人今天过来，感觉东西设计上还是有特色，虚拟化上，架构设计适合高端用户，另

Chunklet等存储方式的变化都是他的特点。

 

3PAR 在 1999 年成立，几个创始人主要出自 Sun ，前身叫作 3PARdata ， 2008 年上市。要知道在存储技术领域竞争还是比较激烈的，EMC / HDS 等控制着高端存储的主要市场，3PAR 能突破技术壁垒并最后成功上市，没两把刷子那是绝对做不到的。

InSpire 硬件结构

3PAR 背板采用全网状的连接结构，每个控制器节点之间高速直连。因为是全网状的，所以基本上一个链路坏掉只影响直连的两个节点的通信，对其它节点无影响。每个控制器节点内置一块硬盘，用于操作系统安装。控制器节点最多可以扩展到 8 个，是 3PAR 存储最核心的组件。

相比之下，HDS 架构采用全光线交换方式（Universal Star Network），而 EMC 是采用直连矩阵方式(新一代产品采用虚拟矩阵架构--Virtual Matrix ，其实已经放弃了直连矩阵架构了)。这些连接方式的孰优孰劣历来是厂商攻击竞争对手的着眼点，能否最大限度发挥性能是用户最需要关心的。

3PAR 针对 I/O 指令和数据移动使用不同的计算芯片。I/O 指令(元数据/控制Cache)用 Intel 的芯片，而 数据移动/Cache 则使用专门设计的 ASIC 芯片来完成。

因为有专门的硬件 ASIC 芯片用于 RAID 5 XOR 校验，3PAR 号称有了其第三代 ASIC 芯片，实现的 RAID 5 是业界最快的，甚至 SATA 盘也能有不错的性能表现。(从 Oracle 公司测试的数据来看，和 RAID 10 速度的确相差无几。)

InForm 操作系统软件与虚拟化

3PAR 的操作系统叫 InForm，最初就是面向层次化的设计。与其他存储不同的是，3PAR 所有磁盘被分成 256MB 统一大小的小盘(Chunklet)，可以根据需要用多个 Chunklet 组成 RAIDlet(逻辑磁盘)。因为这个独特的设计方式，3PAR 是可以很容易做到不同容量的磁盘混用，同一个 RAID 组里都可以有不同大小、不同转速的磁盘混用，这是其他存储做不到的。而且，所有的磁盘都可以利用，因为Hotspare Chunklet 以更小的单位分散在不同的磁盘上，也不再需要单独留热备盘。空间利用率可以更充分一些。　

多说一句，有这个冗余机制，3PAR 更换磁盘也是与众不同：直接抽磁盘盒子(一个盒子可是四块磁盘啊)，我当初看到 3PAR 技术人员这么操作真是着实吓了一跳。

因为固定大小的 Chunklet 的存在，可以将 I/O 更为均匀的分散到多个磁盘上。

对于熟悉Oracle 的朋友来说，会发现这和 ASM 的思想非常接近。因而也可以和 Oracle 数据库进行无缝集成：

因为软件做得非常具有易用性，日常管理与维护远远没有其他高端存储那么复杂，新增磁盘这种事情，都是一行命令之后底层自动处理。其实在 Thin Provisioning 方面 3PAR 也是很值得一说的，比一些厂商的伪 Thin Provisioning 具体多了。限于篇幅，不赘述。

3PAR 在美国有很多金融证券行业的客户，也有 Web 2.0 行业的客户--MySpace 。在保证 I/O 响应在 10ms 以内的前提下，3PAR 的 IOPS 能力非常优异(这才是卖点，不难理解其客户多集中在证券、金融领域)。虽然有些厂商号称能得到更高的 IOPS ，但那是在 I/O 响应时间很差的情况下的数据。要说明的是，现在随着一些存储厂商在高端服务器上也支持 SSD ，未来几年如何还要再看。

前两年 3PAR 推行所谓 Utility Storage(功用存储) 理念，现在貌似改成敏捷存储了。说实话，我觉得敏捷存储真的挺适合的，3PAR 命令行批量创建 LUN 真的很让人感觉舒服。当然，也在宣传云存储和绿色存储的理念，那是题外话了。

3PAR 原来只做中高端市场，只有 T 这一个系列，现在也开始关注中低端市场了，推出了 F 系列的产品。软硬件体系基本没变，倒是没仔细看过。

Isilon在集群NAS行业异军突起，在包括中央台等多个电台上收获很多案子，现在又在HPC上建立了不少案例，笔者通过对设备实测及白皮书上的内容分析Isilon的缺陷。

Isilon built and delivered the revolutionary OneFS operating system, which combines three layers of traditional storage architectures – the file system, volume manager and RAID – into one unified software layer. This creates a single intelligent, fully symmetrical file system, achieving up to 20GBps of total throughput, which spans all nodes within a cluster.

Isilon革命性的onefs文件系统，包含了存储的3层结构：文件系统，卷系统，和raid系统，让这3层用一个软件层来实现。建立一个智能的对称的无中心点的文件系统。带宽可以到20GBps，而所有节点都可以放到一个集群里面来。

File striping in the cluster takes place across multiple storage nodes versus the traditional method of striping across individual disks within a volume/RAID array.

Isilon在存储节点上做条带华，而不是在传统的在磁盘上做条带华。

OneFS provides each node with knowledge of the entire file system layout and stripes files across nodes within a single cluster. Accessing any independent node gives a user access to all content in one unified namespace, meaning that there are no volumes or shares, no inflexible volume size limits, no downtime for reconfiguration or expansion of storage and no multiple network drives to manage. This fully distributed approach enables the breakthrough technology required to meet the performance, scalability, availability and manageability demands of the next generation data center.

OneFS 会让每一个存储节点知道整个系统的文件分布条带等文件的索引信息（原文为knowledge），访问一个独立的存储节点就等于是访问了一个全局的namespace server，这种全局的信息保证让整个系统没有容量的限制，没有单点的故障，在带宽，扩展性上，可管理性上做的最好。

（让每一个节点，都能有整个系统的信息，意味着每次数据的更新和增加都必须抄送给所有的节点，以保证在每次数据读取时是最新的数据， 那也就是说，如果集群的数量太大时，假设100，每次数据的读写是1，那么整个系统的写操作就是100+1=101次，大量的数据读写浪费在内部的消息通知上，从Isilon本身的技术文章上没有看到类似 gassip协议或者vector clock nwr之类的算法，所有Isilon最大的问题是不能在超大容量下保持很好的性能。

为什么要用Cassandra

• MySQL使用太多随机I / O的
• 基于文件的解决方案需要有太多的锁

面对海量数据优势

• 扩展性，无边界
• 在线负载平衡，集群技术
• 灵活的架构
• 以KEY为导向的查询
• CAP理论

 

记得有个大家记歌词的节目，很火爆，通过旋律快速找到歌曲，旋律搜索有多少用处呢？我们常常会遭遇到这样的尴尬：在大街小巷邂逅一段熟悉的旋律，无奈又听不清歌词。遗憾也许这辈子就这样失之交臂了。

不必懊恼，Shazam 是一款能够识别音乐讯号的应用。相信不少朋友对它并不陌生。它在 iPhone 和 Andriod 手机里出现的频率很高，诺基亚的某些手机甚至预装了这样一款软件。

它的基本原理就是通过采集十几秒的声音样本，通过网络将音乐信号发回 Shazam公司，经过数据分析，很快便将该乐曲的相关信息发回手机。你对此一定不满足，幸运的是我们找到了开发者的一份材料。

我们都知道，一段音乐信号可以通过频谱图表示。横轴表示时间，纵轴为频率，另一个轴表示强度，即一个三维的频谱。那么，一条水平线代表一段连续的音频，垂直线代表一个瞬间的白噪声。如下图，图中的每一个点都代表特定时间点的频率强度，即为选定的"锚点"。图中的红色标记代表该时间点声音强度的峰值。

由开发者的材料看，他们大约是每秒提取 3 个锚点。然后，他们会把收集到的信息建成一个哈希表（Hash table），其键值就是频率。当 Shazam 收到一段音频，以下图为例，它会以第一个键值，即 823.44 Hz 搜索匹配项。

哈希表可能如图所示：

他们不只是标注频谱的一个点，而是一个点对，每个峰值加了第二次锚点，即一个散列的两个点的频率，这样就能减少搜索时因噪声干扰而可能产生的误差。

接下来就是检索的过程了，如果一段音频多次匹配，就会自动坚持这些频率所对应的时间是否与哈希表一致。当两个音频近似时，这些锚点连成一条连线，如果能检测出这条线，就说明音频匹配。

据悉，类似的技术最早由一家名为 Melodis 的公司推出，它推出的一款应用—— Midomi ，与 Shazam 相似。当然，也不乏基于电脑的应用，比如前不久测试的百度哼唱，是首次在国内推出的哼唱搜索引擎。不过由于技术问题，推出时间可能要到2011年下半年了。 Midomi和shazam的搜索在美国用的人不多，倒是中国市场贡献了1/4的点击量，人多力量大啊。

说到语音的搜索，shazam号称收录的音乐曲目为7万，而midomi则有超过10万首歌，天文数字，传统的数据库搜索是无法完成的。只有使用使用云计算云存储的方式解决。

举例：使用类似BIGTABLE的半结构化数据库记录每首哥的旋律：

 

搜索方式采用数状结构：根服务器，从根音823.44赫兹开始，到第二个记录音的音频小于800则进入server A进行搜索，如此类推，进入到第三或者第四层时，搜索匹配的数据在几千个，大大缩短了收索时间，也将海量收索的负载平均分配下去。

期盼在视频搜索上也能有如此的突破，将来的世界通过声音，动作就能进行控制。

国内云平台的研究，大部分集中在并行计算及分布式文件系统上，对整个云平台的资源策略研究比较少，在此老蒋总结一下现在云平台中调度计算及存储资源的8种弹性策略。抛砖引玉希望大家能深入探讨如何保障云的弹性问题。平台通过负载均衡和资源均衡的分配策略，根据服务请求与当前资源利用情况进行合理分配，满足最佳匹配资源供给。在云平台中，没有中心控制的概念，各集群间都是独立的。因此，当本地集群资源不够，系统可以通过作业的跨域迁移，保证作业的正常运行。当网络发生故障、或某些集群宕机时，通过跨平台性以及容错系统保障集群系...

      云架构 是满足按需分配的服务而设计的软件架构。 云架构上构建服务流程是这样，基本的计算及基础设施只是在有需要时（例如处理一个用户请求）才分配出去，分配必要的资源上的需求（如计算服务器或存储），执行特定的工作，然后放弃不必要的资源。 老蒋认为这个过程中提供整个计算及存储等基础设施管理，分配，回收等工作的就称为云管理平台。云...