Facebook公司已经在其近线存储体系当中彻底弃用RAID与复制机制,转而采用分布式擦除编码以隔离其所谓的“暖性BLOB”。
暖性?BLOB?这都是些什么东西?大家别急,马上为您讲解:
Facebook公司面临的一大特殊问题在于,其拥有三种主要用户数据类型外加与之相关的元数据,而且这三种类型都要求拥有庞大的存储空间作为支撑。Facebook最为主要且访问频率最高的数据集是那些生成时间不长,且在用户时间表中留存时间不足一周的发布信息。这些内容往往会受到该用户“好友”们的大量访问。
Facebook利用其Haystack存储系统处理这些数据,这套方案采用三级复制机制对数据中以保护、确保这部分数据能够始终接受访问且具备快速的响应能力,同时尽可能将访问指向单一磁盘(当元数据计算开始运行之后)。
当这部分数据逐渐陈旧之后,其访问频率通常也会有所降低——也就是前面提到的由热门转向“暖性”,但我们仍然需要为其提供较快的访问速度、从而切实满足调用需求。这就产生了新的问题,数据总量一直处于规模膨胀态势当中。举例来说,截至今年一月份,Facebook所保存的照片总数已经超过4000亿张。
根据时间推移,请求的相对频率也如图示发生衰减。每一条只对应单独一类存储对象,图中取其绝对值以增加易读性。另外圆点部分代表着访问请求频率降低至下一数量级的转折位置。
在对每TB数据IO次数进行计算之后,我们可以看到这种暖性型数据的IO密度要远低于热门数据,这意味着此类数据已经不再需要利用三级复制机制加以保存,但却仍然需要具备可以接受的访问速度,同时拥有必要的保护手段以避免遭受磁盘、主机以及机架故障的影响。
Facebook公司的工程师们已经打造出一款新型存储系统,也就是f4,专门用于保存这些暖性BLOB。工程师们在一篇论文中解释道:“f4是一款新型系统,能够在降低暖性BLOB有效复制因素的同时保持其容错性以及对较低数据吞需求的支持能力。”
Facebook的工程师们指出:
f4采用里德所罗门编码机制并将数据块排布在多台不同机架之上,从而确保单一数据中心内部的磁盘、主机以及机架故障不会对数据可用性造成影响。它还在广域层面利用XOR编码机制以确保数据中心的故障弹性。f4已经在Facebook的生产环境之下运行了超过19个月。f4目前保存的逻辑数据超过65PB,帮助公司节约的存储空间则超过53PB。
BLOB与聚合文件系统元数据共同被汇聚在以100GB为单位的逻辑分卷当中。这类逻辑分卷由数据文件、索引文件以及日志文件共同构成。其中索引文件其实是一套针对内存内存储主机查找结构的快照。当所有分卷都被锁定时,则不允许再创建新的分卷。
这些分卷构成多个cell单元并被保存在数据中心内部,其中每个单元由包含15台主机的14套机架构成、每台主机配备30块4TB磁盘驱动器。每个分卷/字符串/数据块都拥有一个位于其它不同地理位置的对应分卷/字符串/数据块。Facebook公司还会在独立的第三个区域另行保存一套XOR数据内容。这套体系能够保证任意区域出现故障时,用户仍能顺利访问所需数据信息。
那么一般性企业用户是否需要建立这样一套存储体系来打理自己的近线数据呢?基本上用不着,毕竟大部分企业用户根本不需要像Facebook那样面对如此庞大的数据总量,也不可能遇到同等规模的数据增长速度或者信息不变性。
好文章,需要你的鼓励
后来广为人知的“云上奥运”这一说法,正是从这一刻起走上历史舞台。云计算这一概念,也随之被越来越多的人所熟知。乘云科技CEO郝凯对此深有感受,因为在2017年春节过后不久,他的公司开始成为阿里云的合作伙伴,加入了滚滚而来的云计算大潮中。同一年,郝凯带领团队也第一次参加了阿里云的“双11”活动,实现了800万元的销售业绩。
随着各行各业数字化变革的不断深入,人类社会正加速迈向智能化。作为智能世界和数字经济的坚实底座,数据中心也迎来了蓬勃发展。面