图/文 杨骥
导读
时光如白驹过隙，坐在时代的列车里，我们一路向前；近三十年来，无数事物在车窗前掠影而过，一度流行，又一度黯淡。磁带，就是一个时代的符号。彼时，磁带因其低廉、可靠及易用等特性，一度成为音乐最主流的载体，将流行音乐传遍大街小巷。后来，随着 CD 和 MP3走进大众视野，磁带逐步退出历史舞台。如今，磁带作为音乐载体早被时代淘汰.....但磁带作为存储载体，近几十年却从未过时：在冷数据场景，磁带存储凭借其极低的成本和极长的寿命，在企业存储市场始终占有一席之地。今天的故事就此展开，来聊聊腾讯的深度归档存储与磁带的那些事。欢迎阅读~
1.1 童年的回忆——家用磁带渐行渐远
提起磁带，80和90后可能感触颇深。在20世纪末至21世纪初的那些时光里，磁带绝对是那个时代的符号: 不管是在街上插着裤兜边走边听随身听的翩翩少年，亦或是街边一家接一家的外放音乐似乎永不停歇的小店，无一不在诉说着磁带的故事。
我与磁带结缘于2003年，那一年我读初一。依稀记得当时电视上天天洗脑般的播放各种学英语的广告——“学英语，Follow Me”、“XX 高复读机，学英语更容易”，潜移默化之下，似乎全天下的家长都认为复读机真的可以学英语。于是，复读机便成了中学生的必需之物，流行音乐的种子也同时在学校里生根发芽。那一年，我不仅拥有了人生中第一台复读机（也是唯一一台），也花掉了积攒已久的零花钱，拥有了人生中第一盘磁带——周杰伦的《叶惠美》。
不过后来，更厉害的东西出来了——MP3播放器。MP3播放器个头不大，但可以装的音乐更多，听完一波还可以再换一波，简直是听歌神器，再配合全球最大的盗版音乐下载基地: 某度音乐，MP3播放器迅速取代磁带成为了学生听歌设备的中流砥柱，从磁带手中接过了"繁荣华语音乐"的大旗。而也就是那时起，家用磁带便离我们渐行渐远。
1.2 云时代的契机——企业级磁带蓬勃发展
虽然民用级磁带已逐步退出历史舞台，但企业级磁带技术却在近几十年一直处于高速发展态势，其最主要是解决冷数据问题。根据 Horison 调研报告，预计到2025年，全球每年会新增163ZB 的数据，其中60%都是冷数据，即2025年每年会有100ZB 的新增冷数据。
冷数据有什么特点？日常写（如日志、音视频等），低频读，数据要可靠，成本还要低，寿命还要长，最好存放数据的介质不读时还不费电…… 这些看似苛刻但实际的需求，是冷数据的特点，却也命中了磁带的硬件特性。因此，磁带在各个大型公司中始终承担着数据备份的作用，并且在关键时刻一定能够把数据恢复出来。谷歌在2011年曾经出过一次事故，在一次 gmail 服务软件更新中出了个 bug，导致线上4万个 gmail 的账户数据被删除，尽管他们的邮件数据存储在了多个数据中心的多个副本里，但是数据依然有所丢失。最后，谷歌是从他们的磁带备份中把丢失的用户账户数据给恢复回来了。
但是，对于中小型企业来说，引入磁带有一定的技术门槛，前期的投入可能得不偿失。互联网公司发现了这个商机，他们在公司内部把磁带技术钻研透彻后，逐步把磁带存储技术搬到了云上。
2019年，亚马逊在云上推出了基于磁带的极冷数据存储产品：Glacier Deep Archive，也就是 S3的深度归档服务。Glacier Deep Archive 可以让中小企业0投入，直接以极低的成本使用云上的磁带存储。而除了互联网公司外，传统企业的备份需求也非常大，国内外的科研机构、广电、银行、证券、保险等行业，每年都会采购大量的磁带存储构建私有云，用于冷数据的存储。
1.3 磁带硬件概览
企业中使用的磁带存储设备，我们称作磁带库（"库"字既可以理解成 Library，也可以理解成仓库）。
磁带库常见两种形态:
▶︎ 独立机柜: 单个磁带库占地面积较小，通常配置的槽位数为400~900左右的量级（一个槽位可以插一盘磁带），对应物理存储空间约5~10PB 左右；
▶︎ 联排机柜: 单个磁带库占地面积较大，通常为多个机柜组合而成，槽位数配置也可以达到几千甚至上万，对应的磁带存储空间可以达到百 PB 级别。
互联网公司通常使用独立机柜较多，一个原因是硬件部署时对 IDC 的机位的侵入性更小，机位易改造；另一个更关键的原因是当发生整机故障时，故障影响范围更小。
磁带库内部，主要部件有四个：
▶︎ 磁带: 实际的存储介质；
▶︎ 驱动器: 也叫磁带机，负责磁带介质的读写。这里需要注意，驱动器对磁带的读和写是互斥的；
▶︎ 机械臂: 负责磁带介质的移动，从槽位中取出磁带放至驱动器，或者从驱动器中取出磁带放至槽位；
▶︎ 槽位: 实际存放磁带介质的地方，通常是一个类似抽屉形状的存储空间。
补充一点，磁带库是纯机械构造，因此故障要比 X86服务器要很多，这也是磁带库使用时，应该重点考虑的事。
让大家更直观的了解磁带库的“长相”，如下。
1.4 磁带介质
- LTO vs 3592
磁带的介质有两种，一种是 LTO，一种是3592，驱动器类型也与之对应：
▶︎ LTO 为标准组织定义的磁带类型，3592为 IBM 独有的磁带类型，需配合 IBM 专有驱动器才能访问，且仅能从 IBM 购买 (不可否认，IBM 对于 LTO 的技术推进也贡献很大）；
▶︎ 目前的主流使用的磁带为 LTO-8（12TB）和 3592 JE（20TB），下一代 LTO-9（18TB）于2021正式发布（原定2020年）；
▶︎ 3592类型，旧磁带可格式化成新一代（容量/性能不同于新一代），可循环利用，LTO 无此功能；
▶︎ 磁带生产厂商主要有 FujiFilm 和 Sony，这两家厂商市场占有率总和接近100%，各家磁带库厂商的磁带生产主要交由 FujiFilm 和 Sony 进行生产，包括 LTO 和359。
与 HDD 不同，磁带介质不管是 LTO 还是3592，都不是标准的块设备，都不能直接使用。
LTO 和3592整体的路线图如上。LTO-8和3592JE 的理论顺序读写速度分别为360MB/s 和400MB/s，不过由于种种机械特性的限制，生产环境很难持续的把理论速度跑满。
目前 LTO9 已经发布，海外已经有一些公司逐步开始使用，国内对待 LTO9 的态度仍然偏保守。
HDD 与磁带的技术栈本质上有些类似，均为磁技术（加磁和读磁），通过对存储介质施加磁性，达到数据存储的目的，只是二者目前的密度不同。左图是来自 insic.org 的关于磁密度的 HDD 与磁带的对比，到目前为止，HDD 的磁密度已经接近极限了，而磁带的磁密度上限还非常大。
目前业界真正投产的最大容量的 HDD，主要集中在20~24TB，但 CMR 短期内很难看到再有容量上的突破。HDD 的密度难以突破的原因之一，是磁头操作磁道时，会相邻磁道产生干扰，从而影响周边数据，这个问题也叫做邻道干扰（ATI），密度越高问题越明显。所以要想 HDD 的存储密度提升，ATI 是绕不开的问题。目前应对的手段主要有2个，分别是 HAMR（热辅助技术）和 MAMR（微波辅助技术）。使用 HARM 和 MAMR 理论性可以使得 HDD 达到40~50TB 这样一个容量量级，也是目前 HDD 容量的天花板。
而磁带在密度上的现状则完全不同。如果把提升密度比喻成打怪升级的账号，那么现在磁带的密度连新手村都没有出。用同样12T 的容量来比对下，12T 的硬盘容量大概是923GB/in²，而12T的LTO8磁带，它的密度现在只8.5Gb/in²。也就是在 LTO8基础上，能够至少再提升一百倍的容量空间。目前富士联合 IBM 已经在实验室中成功研制出了580T 容量的磁带 demo。不过短时间内，磁带的容量增速不会太激进，一个原因是有好东西要挤牙膏一样缓慢推进才能创造持续的商业价值，另外一个原因是配套硬件也需要时间去适配（比如网卡带宽、驱动器能力等）。
总的来说，目前磁带相比于 HDD，在容量上有着无尽的想象力。
如上是详细的 HDD 与 Tape 的对比说明，这里就几个关键点补充说明：
▶︎ 成本: 磁带的成本优势，不仅仅在于相比于 HDD，同容量的介质采购价格更低，同时磁带的寿命通常要远长于 HDD，以及在非读写时磁带完全不费电，磁带整体 TCO 相比于 HDD 机型可以显著下降；
▶︎ 性能: 磁带的吞吐性能尚可，大批大文件数据连续写时，可以跑到接近理论吞吐，但磁带在读数据时，性能会退化非常严重，主要体现在寻址时间过长。当业务想要从磁带中读出数据时，磁带库需要经历“机械臂找磁带并插入驱动器”和“驱动器倒带直到数据所在 LBA”，前者耗时最长几十秒，而后者耗时可能长达2~3分钟。因此，磁带库的应用，最重要的就是如何把读性能尽可能提高；
▶︎ 可靠性: 磁带的可靠性远高于 HDD；
▶︎ 非标设备: 磁带是一个块设备，但是不是标准块设备，访问磁带时需要依赖外部驱动和软件。
1.5 磁带柜
- 机柜介绍
磁带柜分为独立和联排。独立机柜更灵活一些，IDC 改造也更容易一些，同时隔离能力更强。比如当电源坏了或是机械臂卡住类似这种非常极端的故障，独立机柜只影响一部分数据；而连排机柜，如果发生极端情况，会有更大面积数据受到影响，因此互联网厂商/云厂商，多会选择独立机柜进行部署。
市场上磁带柜厂商主要有：第一 IBM，第二 Quantum，第三是 BDT，但是 BDT 主要是做 OEM 和 ODM。除了市场老大和老二，BDT 每年给海外互联网公司的出货量也非常大。
- 磁带库配套驱动/软件
磁带是一个非标的块设备，需要外部程序配合使用。而社区中公开的技术，即为 LTFS。
LTFS 可以把单盘磁带模拟成一个文件系统，给用户屏蔽了“通过 iSCSI 协议向机械臂/驱动器发送原始指令”等细节，同时 LTFS 兼容 Linux、Windows 等多个平台。凭借开放、易用的特性，LTFS 对磁带技术有一定程度的推泼助澜的作用。不过 LTFS 在企业场景还是稍显乏力：缺乏大规模磁带管理能力、性能较弱。
为了应对企业场景，磁带库厂商通常会搭配企业级的 LTFS 进行捆绑售卖，企业级 LTFS 相比于社区 LTFS 而言，增加如下优势：
▶︎ 具备大规模磁带管理能力，并且以统一的视野面向使用者；
▶︎ 可以实现批量取回优化：同一盘磁带中的多个文件优化读取顺序，跨磁带的多个文件按磁带进行合并；
▶︎ 提供多种访问协议：私有协议远程文件系统/NFS/CIFS/对象接口等(不过各家基本都是先实现了文件系统协议，其他协议基于文件系统协议进行二次封装，因此效率底下)；
▶︎ 提供副本管理：可以设置多副本 (不支持 EC，并且需要消耗大量的机器资源，性价比比较低)。
那么，企业版 LTFS 长什么样呢? 我们看下图：
▶︎ 磁带库 &X86 服务器：通常每一台磁带库都对应一台或多台 X86服务器，这个 X86服务器上运行有厂商提供的驱动/软件，X86服务器与磁带库通过 FC 网络直连；
▶︎ 数据缓存：X86 服务器上一般有 SSD 来做磁带库的缓存盘。数据写入时，需要先写入缓存盘，再沉降到磁带中；数据回热也是类似的，回热成功后数据回到了缓存盘里。实际上我们跟磁带库打交道时，数据流都是跟缓存盘打交道，而控制流（刷磁带/读磁带）则可以通过 API 进行。
这里大家可能会有疑问，为什么不管是社区还是厂商，提供的最基础协议都是文件系统呢？主要还是因为用起来方便，尤其是小企业，使用时把文件系统挂载到本地服务器，直接跟文件系统交互即可，用着省事。这部分群体不太关心效率。但事实上，文件系统协议对互联网公司来说，还是太重了，尤其还是 Posix 语义的文件系统。
如果从互联网公司的需求来看，就做几个最简单的 BatchPut，BatchGet，BatchDelete RPC 接口就足矣，完全无需文件系统语义，因为文件系统语义大部分功能都是多余的。即使真的有场景需要提供文件系统语义，也应该通过SDK进行文件系统的操作（类似 HDFS-Client），而非通过 VFS/FUSE 进行操作，效率着实有点低。基于上述原因，亚马逊等海外的磁带使用量较大的大厂，实际上投入了非常多的人力，彻底干掉了厂商提供的所有软件，直接在纯硬件上开发适合云场景的软件系统。
1.6 磁带硬件特点总结
▶︎ 成本特性：成本低、功耗低、寿命长、容量增速空间有想象力。
▶︎ 运维特性：需要机房改造，相比于 X86服务器，运维更复杂。
▶︎ IO 特性：
- 只能顺序读写：通常情况下磁带只能顺序读写，不能直接原地修改；
- 吞吐高：单盘磁带可达到300~360MB/s 吞吐，不同驱动器可并发；
- 延迟高：磁带寻址（尤其是读磁带时）时间最多可达3分钟；
- 大文件更优：每写一个文件都要停顿记录元数据，文件太小导致磁带吞吐不连续；
- 回热代价大：沉降时几乎不用寻址，磁带尾部 Append 即可，而回热需要花费更多时间寻址；
- 批量作业更优：磁带库软件内部可以进行优化，让磁带转动的距离更短；
- 缓存盘交互：不能直接访问磁带，需要与缓存盘交互；
- 数据回收缓慢：数据不能直接从磁带删除，只能后续通过倒带的方式来消除空洞。
02
磁带技术硬件介绍: 企业磁带技术详解
2.1 对象存储 COS
接下来就是磁带存储的业务应用，即 COS 深度归档存储，COS 的全称是 Cloud Object Storage，它是腾讯的一个大型分布式存储系统平台，更具体地说是一个对象存储的平台。COS 凭借开放商用的标准能力，目前服务了上万家内外客户。
COS 有哪些存储类型？
COS 有5个存储类型，从冷到热分别叫标准存储、低频存储、归档存储和深度归档存储，以及智能分层（本文暂时不讲）。我们可以看到数据越热数据存储越贵，数据越冷数据存储越便宜。但是数据越冷，它的数据访问越贵，深度归档存储和归档存储从定义上来都算冷数据的范畴，并且面向的用户场景其实也有一些重叠，但基本上都是做归档用。
归档存储与深度归档存储区别在哪儿？
当有一些归档数据用户取回时，需要分钟级或者小时级，那么就可以掏3倍的价钱购买归档存储而不是买深度归档存储。但如果用户数据量非常大，比较在意成本，并且能够接受天级别的回热延迟，那么就非常适合做深度归档。比如很多企业为了合规性，把一些日志、视频进行归档，当审计或者需要时进行取回。举个例子，比如部分企业运营的原始资料（比如直播录屏），这些数据如果不是遇到重大案件回溯，基本上不会再调出来使用，但是这些数据出于合规性，又得永久保存，这种场景就可以放到深度归档里，且成本非常低。
2.2 深度归档存储介绍
以下，我们分别引用腾讯云和亚马逊的深度归档介绍：
深度归档存储（Deep Archive）是对象存储（Cloud Object Storage，COS）提供的可让海量数据长期归档的存储服务。深度归档存储提供了磁带存储级别的存储单价，为用户数据长期存储提供了低成本方案。用户无需在本地维护复杂的磁带库配置，无需关注底层存储介质的演进，通过对象存储 COS 提供的 API、SDK、生态工具和控制台等丰富的人机交互手段，即可实现便捷、低成本地管理数据。
深度归档存储适用于数据访问频率极低，但需要长期保留的场景。在日志冷备场景中，企业需要按照当地法律法规要求，将每天产生的日志数据进行冷备存储，以便追溯和分析。在视图数据和自动驾驶等业务中，企业沉淀了大量的图片、视频等媒体文件，在数据被使用过后仍然需要长期归档保存。通过深度归档存储，企业可以将这些数据存储在云上，仅在需要的时候恢复，降低存储成本和运维管理难度。
亚马逊：
S3 Glacier Deep Archive 是 Amazon S3 成本最低的存储类，支持每年可能访问一两次的数据的长期保留和数字预留。它是为客户设计的 – 特别是那些监管严格的行业，如金融服务、医疗保健和公共部门 – 为了满足监管合规要求，将数据集保留 7—10 年或更长时间。S3 Glacier Deep Archive 还可用于备份和灾难恢复使用案例，是成本效益高、易于管理的磁带系统替代，无论磁带系统是本地库还是非本地服务都是如此。S3 Glacier Deep Archive 是 Amazon S3 Glacier 的补充，后者适合存档，其中会定期检索数据并且每隔几分钟可能需要一些数据。
通过官方介绍，大家可以 Get 到几个信息：
▶︎ 价格很便宜；
▶︎ 回热很低频；
▶︎ 云来帮你管理磁带。
为了让大家更深刻的理解深度归档的产品设计（是如何向磁带存储特性倾斜的），我们以腾讯云的产品报价和时效性为例，进行分析：
概括来讲: 让用户多写少读少删、存大块数据，如果真的要读，也尽量鼓励用户批量读！
2.3 极冷数据存储引擎：Berg
2.3.1 Berg 基本介绍
为什么叫 Berg？
Berg 是 COS 团队设计并研发的面向磁带的极冷数据存储引擎。Berg 也是 COS 的一部分，意为冰山 （通常大家多想起 IceBerg 作为冰山示意，但在地质学词典里，Berg 本身就有冰山的意思，比如 Sugar Berg：多孔冰山）。
Berg 是国内首款支持纠删码的规模化商用的磁带存储引擎，也是腾讯从零开始完全自主设计和研发的全新存储系统。
Berg 与 COS 的关系？
本身 Berg 也是 COS 的一部分，如下图，COS 内部其实有很多子系统，Berg 并不能单独拿出来提供深度深度归档存储的服务。
2.3.2 Berg 面临的问题
想要设计出一个靠谱的磁带存储引擎，就要首先搞清楚，用户的需求是什么，硬件的特性是什么，这中间的 diff 就是引擎需要解决的问题。
用户的需求是上图左边，数据大小要支持 1Byte~50TB 的范围（因为对象存储本身支持的对象最大就到50TB），用户既可以直接上传，也可以把已经存在的低频归档的数据通过沉降的方式深度归档；用户需要时，可以把数据取回：按照云上的协议，当数据取回之后，数据需要在对象存储的标准存储准备好。当然，取回之后标准存储的那部分存储空间和读取也是额外收费的。最后，数据安全是底线，数据一定不能丢。
那么这些用户需求对于磁带库来说有什么问题呢？首先小文件性能会差，太大的又装不下，因为一盘磁带就12T，这也限制了磁带不能存储超过 12T 的数据。另外，磁带库本身写入读写流程非常繁琐，回热效率非常低（寻址时间可能高达3分钟），故障率也很高。而对于数据安全，则需要业务软件提供额外的副本机制了（前边讲过，磁带库软件自带的副本机制对资源浪费非常严重）。
为了打平这些问题，Berg 就需要在设计上有所注意。
2.3.3 Berg 的整体架构
Berg 是一个在离线混合系统，在线响应用户的沉降回热信令，离线处理数据。
Berg 有三个模块：
▶︎ Captain：最外层的调度层叫做 Captain，意味冰山上的指挥官，最主要的职责为信令的接收与再分配，起到一个调度的作用；Captain 依赖一个外部存储来持久化信令，当 Captain 崩溃时，信令不会丢失；
▶︎ IceWorker：真正执行任务的模块，它的职责主要是接受 Captain 分发的任务并执行。IceWorker 也是直接跟磁带库打交道的模块；
▶︎ IceCenter：资源总管，寓意是冰上的大本营。IceCenter 保存了所有磁带库的资源信息，间接对 IceWorker 进行指导。比如 IceWorker 如果要沉降数据，则需要向 IceCenter 进行空间申请，申请后才能向磁带库写数据。
总的执行流程如上图：YottaAccess 把读写信令发给 Captain，Captain 收到信令后持久化，然后分配任务给 IceWorker 去做，IceWorker 既跟磁带库交互，又跟 COS 的数据引擎 YottaStore 进行交互。
接下来在拆解上图，按照沉降、回热、修复、删除等等逻辑详细讲解整个的控制流、数据流是怎么样运行起来的。
2.4 数据沉降流程
对于 Berg 而言，数据沉降流程的起点是：Captain 接收到 ArchiveTask 信令之后，对收到的 Task 进行聚类和持久化；流程的终点是：完成数据沉降后通知 YottaAccess 任务执行成功。
整个流程如上图，不再赘述，这里阐述2个关键问题。
- 关键设计1: 用户数据沉降时聚类
为什么要聚类？ 最主要的原因还是，想要这些数据回热的时候更快。前边讲过，磁带存储的寻址时间非常长，我们不希望回热发生的时候，用户的数据分散在磁带库/磁带的各个地方，因此 Captain 会尽最大努力按照用户的数据特征，进行一个聚类动作，让具备相同特征的数据尽可能让 IceWorker 一起拿走，然后连续的写到磁带上，实现一个局部连续性。这样某个用户回热时，用户的数据大概率也是具备局部连续性的，可以显著提高回热性能。另外，当用户删除的时候，也可以让空洞更少一些。
怎么聚类? 依然是两种思路，要想实现最精准的思路是：存到一个结构化存储里，或者就是存到大数据平台里，当 Captain 分发任务的时候，通过计算得到一个最优解。但是这个思路的实现代价太大了，有点用原子弹打蚊子的意思。本身 Berg 并不要这么高精度的聚类模型，无需过度设计。所以最后 Berg 就选择了一个轻量级的方式：实时聚类，Captain 收到信令时，立刻进行聚类计算，不同聚类模型对应不同文件，如文件过大则按策略进行切割。这样 Captain 给 IceWorker 分发任务的时候，按照聚类后的模型文件，一批一批递交给 IceWorker 去执行即可。
- 关键设计2：沉降时硬件故障处理
▶︎ 可恢复性故障：通过任务调度系统后续重试失败的部分；
▶︎ 不可恢复性故障：Black 磁带库（组）的写请求，让后续的写请求流向健康的磁带库（组）。
这里引申一个问题，为什么遇到局部故障时，不暂时放弃某列去判定成功，后续再通过修复的方式补齐数据呢？主要原因在于，磁带库进行修复时需要进行读数据，读数据操作太重了，这个问题在后边介绍到修复逻辑时，会面临同样的问题。
- 关键设计3：任意 CodingSchema EC 支持
IceWorker 在进行 Block 数据切片时，通过抽象的 EcController 进行独立控制，可以支持任意 CodingSchema 的 EC 切片，灵活配置。
2.5 数据回热流程
回热流程的读写路径其实跟沉降非常类似，主要的策略点也在 Captain，对于用户发来的回热任务，并不是越快执行越好。Captain 如果是收到一个请求就立即执行一个请，硬件整体的吞吐是上不去的（由于回热数据的离散性，大量时间浪费在了磁带寻址上）。而磁带库的驱动器是稀缺资源，数据读写又是互斥的，磁带库处理读请求时，写请求就会暂停。因此，怎么样让磁带库更多的时间是在读数据，而不是在倒带，是 Berg 要解决的一个关键问题。
- 关键设计1：用户回热请求静置与聚合
▶︎ 静置：根据任务紧急程度，数据需要有小时级的静置期，积累足够多的用户回热任务，并对回热任务进行聚合，使得磁带中 LBA 相近的数据尽可能一起回热；
▶︎ 聚合：数据沉降时，会生成与数据位置相关的信息 Hint，Hint 值越接近表示数据在磁带中的 LBA 地址越接近，或者表示两盘不同磁盘间隔的距离越近。静置期内，Captain 按照 Hint 值进行聚合，保障分发给 IceWorker 的任务都是尽可能在磁带中较为靠近的，而 IceWorker 再执行这一批任务时，磁带库平均寻址时间更短，从这个角度提高了整体回热性能（吞吐）。
- 关键设计2：自适应降级读
▶︎ 故障规避：以 KxNy 的 CodingSchema 为例，如返回错误的列数<=(N-K)，则 IceWorker 可以根据 EC 反算出原始数据，本次回热请求可以执行成功；
▶︎ 长尾规避：如 N 列全部成功，则 IceWorker 在收到前 K 列请求时，即可开始进行读缓存和上传数据的操作，无需等待全部列取回成功，本次回热请求可以更快时间完成执行。
2.6 数据删除流程
数据删除流程相对简单，但也相对头疼的。这里 Berg 有两个关键设计来缓解删除带来的影响。
- 关键设计1：三级删除设计
▶︎ 第一级删除：Captain 聚合删除。Captain 的删除是以 Block 为粒度进行删除的。当 Captain 收到用户 Object 级别的删除指令时，如果是小 Object，不会立刻让 IceWorker 执行，会把这个删除请求持久化起来，直到该小 Object 对应的 Block 全部收到删除执行时，Captain 会向 IceWorker 分发一个 Block 级别的删除任务。如果某个 Block 中的 Object 一直不被删除怎么办？这会导致该 Block 内其他空间永远无法执行删除，这里需要借助 Re-Compaction 的方式来对 Block 进行坍缩&再聚合的操作来消除空洞；
▶︎ 第二级删除：IceWorker 向磁带库发起删除。IceWorker 向磁带库发起删除后，磁带库会从文件系统中删掉这个 Block 对应的文件，但是实际上磁带上并没有真正删除该数据，需要进到第三级删除才算真的删除；
▶︎ 第三级删除：磁带库回收磁带空间。这是一个非常费性能的操作，需要2个驱动器配合，一个驱动器会把待回收空间的磁带整个读一遍，同时另一个驱动器在另一盘空磁带上把这些数据再写一遍，数据复制成功后，把前一盘磁带进行格式化，达到回收空间的目的。物理删除有两个弊端，一个是驱动器资源消耗较大（占用时间较长），另一个是寿命有损 (一盘磁带格式化300次左右会寿终正寝）。因此，第三级删除也是一个较为谨慎的运维操作。
- 关键设计2：IceWorker 两阶段删除
本身 IceWorker 向磁带库提交删除时（第二级删除），又有一个两阶段删除：
▶︎ 第一阶段: 对所有需要删除的列进行标删，直到全部成功为止，否则调度系统会定期重试；
▶︎ 第二阶段: 向磁带库发起删除数据请求。
两阶段删除的目的在于：一个 Block 在被删除时，需要 N 列全部删除成功，而由于网络抖动、硬件故障等情况，可能造成部分列删除失败。这时对于磁带库中残留的若干列，无法直接确认该 Block 是产生了数据丢失还是删除部分成功。而对于两阶段删除，残留的部分列可以看到特殊标记，我们就可以直接断定它是没删干净的垃圾数据，就可以放心的进行人工清理垃圾数据的措施了。
2.7 数据修复流程
数据修复流程主要是修复效率的问题。
对于磁带库而言，读数据性能开销是非常大的，并且驱动器读写是互斥的，这意味着驱动器读数据时无法再执行沉降任务；同时，对于 EC 而言，想要修复某一列数据，需要读大量其他的列的数据。这里以 KxNy 的 EC 为例；比如一盘12T 的磁带故障，则至少要读出剩下 K 盘磁带的数据（总数据量 K*12T），才能修复回这12T 的数据。
但是由于磁带故障率远低于 HDD，且当磁带故障时，大概率这一批磁带库已经写满了，只有回热请求，因此磁带数据修复对于业务的实际影响并不大。
2.8 数据安全性保障
传输链路：全链路 CRC 数据校验。
存储链路：存储数据 CRC 读时校验。
▶︎ 写数据时，CRC 信息写入磁带；
▶︎ 读数据时，复算数据 CRC，并且与 Meta 中的 CRC 值对比，保障可第一时间发现问题。
离线数据校验：
▶︎ 业务低峰时定时发起数据校验，再次验证 CRC 信息。
磁带库元数据多级备份：
▶︎ 本地磁带元数据 Snapshot 备份；
▶︎ 远程文件系统定时 Snapshot 备份。
ObjectMeta 封存：
▶︎ 磁带中不仅存储 BergMeta，同时额外存储一份 COS 的 Meta 信息，极端情况下，可以只根据磁带中内容，可还原用户的 Object 信息。
03
写在最后的话
磁带库虽然能够显著降低存储成本，但是并不是所有的业务场景都适合搬到磁带上，本身磁带库的使用是有一定的业务和技术门槛的。从业务上而言，使用磁带库的场景必须是真正的冷数据的场景，用户数据具有保存时间长、低频读、低频删的特征，高频读写删会造成磁带介质寿命损害，只有真正的冷数据才能够做到“因地制宜”降成本；与此同时，由于磁带库通常单柜密度较高，当业务本身总数据量不大时，也不适宜使用磁带库。从技术上而言，使用磁带库具备一定的门槛，磁带库硬件不仅对于机房的温湿度环境要求较高，也需要机房具备一定电路网路改造能力，同时，在磁带库的使用上，设计和研发配套业务软件也需要一定的人力投入。对于一般用户而言，极冷数据存储的需求选择腾讯云 COS 深度归档服务显然性价比更高一些。
而磁带库在腾讯的大规模落地，也并不是一件易事，是 COS 团队、星星海、供应链、运管、商务、IDC、硬件运营、网平、OS、安平等多个兄弟团队之间相互协作的结果。
未来，随着全球冷数据的持续爆炸，以及磁带介质数据密度提升的巨大潜力，磁带库的前景依然充满想象力。我们期待着，数据存储成本持续降低的明天。
