基于数据生命周期管理的存储成本优化
摘要:本次分享的主题是基于数据生命周期管理的存储成本优化,由王太平分享。今天讲解的内容是大家在日常中使用较为频繁的一个话题。首先要聚焦的是对象存储,这是云上最基础的一个产品。会特别关注并讲解关于成本优化方面的内容,主要是指对象的生命周期管理。主要分为四个部分:
1. 产品技术背景
2. 产品介绍
3. 产品核心功能
4. 存储层级的商业应用情况
01. 产品技术背景
根据 IDC 的预测,到 2025 年,全球的数据量可能会达到惊人的175ZB 。可能很多人对这个数据量没有太多的概念。在十几年前刚开始从事存储行业的时候,大多数的存储设备主要用于存储数据库中的结构化数据,而对于非结构化数据则很少进行存储。随后开始逐渐存储一些非结构化数据。到了移动互联网时代,随着每个人都在使用手机和应用,产生的数据量开始大量膨胀。比如朋友圈动态、浏览的抖音视频等,这些数据量都在快速增长。此外整个物联网以及各种机器产生的数据,比如自动驾驶车辆产生的数据。与十几年前刚进入存储行业时相比,存储价格正在飞速下跌。
当年 1TB 的存储费用在核心数据库领域,如运营商、航空业或金融业中,可能极为昂贵。为了存储 1 TB 或几百 GB 的数据库,这些行业可能需要花费几百万人民币去购买一套高端存储设备。然而,时至今日 OSS 存储标准型的费用已经大幅降低, 1GB 存储一个月的费用仅为 0.12 元人民币。那么,整个 1TB 一个月的费用是多少呢?经过计算 1TB 的存储费用一个月仅需 100 元左右,而且这还是标准存储的费用。如果使用阿里云提供的深度冷归档存储方案, 1GB 一个月的费用更是低至 7.5 分钱。这说明了什么问题呢?那就是,尽管数据在急速且爆炸性地增长,但数据的热度和价值却在急速下降。因此,这个时候就需要有更低成本的存储产品来满足市场需求。
因此,云上的对象存储是一个持续不断通过技术创新和产业发展来降低成本的过程。在这个过程中,由于业务架构的多样性实际上将对象存储分为了多个层级。今天重点将放在如何更好地管理这些不同层级之间的存储上。
02. 产品介绍
关于对象存储这一产品,它是云上存储领域中最基础的产品之一。经过多年的发展,它已经能够满足众多领域对服务的需求。例如,关于访问与加速方面,因为面向整个互联网提供服务,所以需要考虑到全球范围内的访问以及大规模并发的处理。此外,云上存储首先要考虑的就是可靠性、稳定性、可用性以及安全性等方面。同时,数据管理、数据处理,以及数据湖、交互工具等,都是对外提供服务的重要组成部分。但是,在谈到存储的底层时会发现存储有多种类型。
在今天的讲解中,关于存储的稳定性、可靠性、安全性、合规性、智能化以及上云等方面将不会重点展开。而主要会聚焦于成本优化这一领域进行详细讲解。
03. 产品核心功能
关于存储,阿里云的对象存储服务实际上分为五个层级:标准存储、低频访问存储、归档存储、冷归档存储以及深度冷归档存储。这意味着您可以根据业务数据的特性,选择不同的存储层级来存放您的数据。而这五种存储类型各有其特点。
其中,上面的三层是标准存储、低频访问存储和归档存储,是可以实时访问的。这意味着它们处于 Online ,对于您的业务系统来说,您只需考虑成本和访问效率,无需进行额外的处理。然而,对于下面的两层,冷归档存储和深度冷归档存储,它们在访问时则需要执行额外的操作。当然,从上层到下层,存储的费用逐渐降低,但数据访问的费用则相应增加。有了这五层存储类型,接下来需要考虑的是,在实际使用过程中业务会面临哪些情况呢?一般来说业务主要分为两种类型。
第一种情况涉及的是,例如音视频文件在刚上传或刚产生时,其访问热度可能较高。但经过一段时间后,访问热度会急剧下降,甚至可能有一段时间无人访问。然而,由于某些业界事件或其他原因,这些数据的热度可能会突然再次发生变化。在这种情况下数据的热度是随机的。但总体来说,它呈现出一个随时间逐渐冷却的趋势,不过可能会因为各种原因而触发数据从冷转热。为了评估这个数据的热度,我们可以根据它在一段时间内的访问热度来进行判断。其实在以前的传统存储中,就已经有了这种根据数据热度进行分层存储的概念。
第二种情况实际上是最常遇到的,即数据的热度随着时间逐渐降低。这种情况非常普遍,例如个人数据中的手机照片、朋友圈内容,以及家庭视频监控等。同时,大部分的互联网音视频内容也具备这一特征。一旦在短期内被访问后,后续往往就不会再有访问需求了。此时,数据的热度与文件的创建时间密切相关。创建时间越短,数据的热度越高;创建时间越长,数据的热度则越低。很多时候,这些数据甚至可能完全不再有访问需求。
然而,由于各种合规性和法律要求,这些数据需要长期保存。例如,金融领域的票据影像、医疗领域的医疗影像,以及各种检测结果等,都需要长期存档。但这些数据通常只有在法律和合规的场景下才会被再次访问。在这种情况下,对于数据再次读取的时间要求并不高。因此,针对不同场景可以提供三种不同的生命周期管理策略。第一种策略是基于数据的热度来动态调整存储层级。当数据热度上升时会自动将其转为更高层次的存储,以便快速访问;当数据热度下降时,则会自动转为更低层次的存储,以降低成本。这种策略允许数据的冷热状态在存储层级之间灵活变化。
第二种策略则是基于数据的最后一次访问时间来判定其存储层级。
第三种,事实上大部分数据并没有那么复杂的冷热频率变化。它们往往遵循一个简单的规律:创建时间越早的数据越热,创建时间越晚的数据则越冷。
因此在对象存储上提供了一个功能,称之为“生命周期管理”。这一功能主要是用来管理存储在特定桶,例如 8K 容量的桶中的数据,确保在适当的时候将数据存储到合适的层级中,甚至在适当的时候将其删除或清除。这实际上是一个数据从写入开始,经历降低成本、转移到更冷的存储层级,直到最终被删除或清除的完整生命周期管理过程。所以将其称为“生命周期管理”。这个生命周期管理的核心本质是成本控制。而我们所做的这一切,以及所构建的多层次存储结构,主要目的就是为了帮助大家节省成本。然而如果操作不当,反而可能会增加成本,甚至对业务成本产生负面影响。
04. 存储层级的商业应用情况
接下来将详细探讨一下这些存储层级的商业应用情况。首先看一下存储成本。标准存储的价格是每 GB 0.12 元,而低频存储的价格是每 GB 八分,这相当于标准存储的约六七折。归档存储的价格则是标准存储的三三折,即大约为标准存储价格的三分之一。接下来看第二个问题。虽然低频归档、冷归档、深度冷归档等存储方式在存储成本上更为便宜,但它们在数据读取时需要额外收费。根据提供的数据,单次数据取回的费用是每 GB 三分钱。如果你假设所有数据每个月都需要取回一次,那么你就会发现低频存储和标准存储的实际成本其实相差无几。因此,在决定哪些数据应该下沉到更低成本的存储层级时必须要考虑数据取回可能产生的费用。
在考虑取回成本时如何做出判断呢?这主要取决于两部分因素。首先,假设你的数据在转为冷存储后仍有被访问的可能性,你需要考虑的是这些数据在短期内,比如一个月内是会被频繁访问,还是只会有单次访问。这是第一个判断依据。
第二个判断依据是,对于一个 TB 的数据量,你大约有多少百分比的数据会在一个月内被取回访问?如果只有极少量数据,比如 1% 被访问,那么即使这些数据在一个月内被访问一次,影响也相对较小。但是,如果你的数据中有 50% 甚至 70% 都有可能随时被取回,那么将它们存放在更冷的存储层次就不太合适了。
那么再次提及冷归档和深度冷归档。这两种存储方式在访问前需要经历一个解冻过程。这时就需要权衡,将其数据放入这些存储层级后,业务系统是否能接受这样的时间延迟。如果我们是为最终客户服务,将他们的冷数据存放在冷归档层,那么就需要考虑最终客户是否能接受在访问时有一定的等待时间,包括数据从冷归档解冻并转为可访问状态的时间。因此在做出决策时始终要围绕的核心问题依然是成本。
接下来会简要地介绍一下在这些领域我们的一些建议,特别是关于使用生命周期管理的一些建议。这些建议涵盖了大家在日常操作中可能会忽略的一些关键点。大家无需刻意记忆,因为这些信息在官网上都有详尽的说明,我只是想把关键的要点提炼出来并分享给大家。第一个要点是有两种生命周期规则。第一个规则是基于修改时间,这里的修改时间实际上可以理解为创建时间,因为对于大多数互联网文件来说,一旦创建后就不会再进行修改。当然,如果文件被覆盖写,那么修改时间就会以覆盖写的时间为准。在这种情况下,如果假设数据的生命周期有严格的规律,并且需要按照创建时间来长期保存,那么这种规则就非常适用。
那么生命周期管理功能具体有哪些呢?首先,它可以按照前缀进行匹配。这里的前缀在对象存储中是一个特定的名词,它大致可以对应到大家普遍理解的“目录”概念,即 Bucket 下的一个子目录。例如可以设定只针对某个特定的目录应用规则,或者针对整个 Bucket 应用规则。
其次,生命周期管理还可以按照标签进行匹配。什么是标签呢?就是在上传文件时可以为文件添加一个标签,这个标签由 Key 和 Value 组成,相当于给文件打上了一个特定的标记。你可以根据不同的应用场景和数据类型,为文件打上不同的标签,然后根据这些标签来制定不同的生命周期规则。在匹配过程中既可以针对整个Bucket 进行匹配,也可以针对单个目录进行匹配。
此外还有很多场景是需要针对一个大的 Bucket 或目录制定规则,但其中可能包含一个小目录,而我们不希望这个小目录遵循同样的规则。针对这种情况提供了 Note 元素的操作,允许你跳过特定的小目录。
在设置生命周期时有两种主要的方式。第一种是基于过期天数,这意味着可以设定数据在创建后的多少天将其移动到某一存储层级,或者在多少天后将其删除。这是一种非常直观和易于理解的方式。
第二种方式是基于某个特定的时间点。这种方式适用于那些业务具有明显生命周期的情况。例如可能有一个明确的时间点或里程碑,比如某个旧版本的应用结束,新版本的应用开始。在这两个版本之间有一个明确的数据分割。这时就可以使用过去的时间点来设置生命周期规则,确保旧版本的数据在指定的时间点后被移动到合适的存储层级或进行删除。而这个生命周期规则并非实时生效,它实际上是异步执行的。在创建生命周期规则之后,该规则会在 24 小时内被加载。更具体地说,它会在下一个工作日的早上八点钟加载,并开始执行。一般而言,如果你的数据条目不超过 10 亿条,在北京、上海、深圳、杭州等大城市一天之内就可以执行完成。但如果你的数据条目超过 10 亿条,它的处理速度大约是每天处理 10 亿条数据这样的规模。
这是一些最基本的操作,其中有一些最容易忽视的细节。比如,首先要考虑排除小文件。为什么呢?对于低频归档、冷归档和深度冷归档这些产品,它们对于小于 64KB 的文件都是按照 64KB 来计费。因此,如果存在大量 1KB 或 2KB 的小文件,这可能会导致你的存储容量被放大几十倍。在这种情况下,将小文件放到更冷的存储层次可能并不会节省成本。
第二个要点是关于数据转冷存储时的注意事项。无论是低频归档、冷归档还是深度冷归档,它们都有一个最小存储时长的要求。如果你将数据存入后,第二天就删除,那么仍然会按照规定的时长来收费,这显然是不划算的。因此在制定规划时,大家一定要考虑到这个收费模式的时长要求,特别是针对低频归档和归档存储。这里提到的 30 天和 60 天是以数据写入的时间为准。而对于冷归档和深度冷归档,它们要求的数据存储时长为 180 天,这意味着一旦数据被存储到冷归档层或深度冷归档层,就需要存够 180 天。在核算整体生命周期规则时,这个时间线是需要重点考虑的。
此外对于数据的删除操作通常建议大家不要采用手动方式。因为手动批量删除不仅执行起来繁琐,而且效率不高。相比之下,使用生命周期管理来执行删除操作既高效又易用。而它是一个异步操作,整个后台调度过程不会影响前端 IO 效率。
其次对于冷归档和深度冷归档这类存储桶 Bucket ,其访问请求的API 费用通常相对于标准存储要更高。如果你将较小或批量的文件直接导入到这些冷存储桶中,可能会瞬间产生大量的 API 费用。在创建存储桶时,实际上可以设置存储桶的类型。如果你将其设置为冷归档或深度冷归档类型,那么默认写入的数据就会是这两种类型。这种情况下可能会导致你的 API 费用显著增加。因此,如果你希望利用冷存储层来降低成本,那么在创建存储桶时,应避免选择这类冷存储桶类型。你可以先创建一个标准存储桶,然后通过生命周期管理策略将数据转移到冷存储层,而不是直接将数据写入到冷存储层。
第二个要点是关于最后一次访问时间的应用场景,它适用于那些数据冷热周期不明显,或者冷数据需要支持在线访问的情况。这里有几个关键点需要大家注意:首先,基于最后一次访问时间的生命周期规则不支持配置删除操作。其次,该规则的匹配条件目前仅支持存储 Bucket 的前缀和标签。再者关于数据转冷的方式,有两种途径可供选择。一种是将数据从标准存储转到低频存储。在这种情况下,如果低频存储中的数据再次被访问,你可以选择是否将其转回标准存储。另一种途径是将数据转到冷归档或深度冷归档。不过要实现这一功能,你需要通过工单申请,让客服团队为你开通相关服务。这种方式更适合有这类需求的用户。
在一段时间内希望数据保持 Online ,而超过这段时间则可以接受其转为 Offline ,或者有一定的解冻时间,这样的客户需求也是经常遇到的。原本,他们可能将所有数据都存放在标准存储中,因为七天内访问的人很多。例如,一些面向消费者的 To C 视频监控客户端就表示,七天内其客户可能会频繁查找自己的视频,但一旦超过七天,几乎就不会有访问需求了。然而在 30 天内,客户可能偶尔还会有一两次的访问需求。因此在 30 天内,他们希望数据能够保持在线状态。但 30 天之后,如果客户需要访问,则可以通过离线方式来获取数据,这是可行的。
针对这类需求有一些建议要分享给大家是关于其执行速度,其实与之前提到的是一样的。第一个建议是生命周期策略可以设置多条规则。当多条规则之间存在冲突时,系统会以最节省成本的方式去执行。例如,如果 A 生命周期规则要求将文件转到归档存储,而 B 生命周期规则算下来要求将其转到冷归档存储,那么系统会选择将其转到冷归档,而不是归档存储,以确保执行成本最低。第二个建议是使用基于最后一次访问时间的生命周期策略时,需要开启防追踪功能。目前这个功能是不收费的。
而哪些操作会触发最后一次访问时间的更新呢?主要是对该文件及其元数据进行操作时会触发。具体来说包括以下几种情况,第一种是 GET 操作,即获取或下载文件。第二种是 COPY 操作,即将该文件拷贝一份。第三种是修改文件的权限。第四种是覆盖写该文件,这些操作都会更改文件的最后一次访问时间。
之前讨论了如何通过生命周期策略将数据从热转冷。那么,如果数据已经进入了冷存储层又该如何将其转热呢?
首先对于标准存储层,因为数据随时可访问,不涉及任何取回或其他操作。对于低频存储,虽然访问时会产生一定的请求费用,但无需执行额外的取回操作。而对于归档存储,则有两种情况。一种是归档直读,这种方式与低频存储类似,你可以直接读取数据,无需执行额外的操作。然而如果采用解冻的方式,你需要触发一个解冻操作。解冻完成后,会进入一个解冻状态持续时间。在这个持续时间内,你会被收取单次性的费用,费用的多少会根据解冻的时间来决定。但在数据本质上,并不会存储两份。然而,对于冷归档和深度冷归档的数据,一旦进行解冻操作,系统实际上会在标准存储层中为该数据创建一份副本。此时你将产生三项费用:取回费用、临时存储费用以及在此期间的所有请求访问费用。这些请求都会通过 APP 定向到标准存储层进行数据访问。因此大家需要了解解冻操作可能带来的费用构成,包括 API 费用、解冻并取回数据的操作费用,以及解冻完成后数据在标准存储层产生的临时存储费用。由于解冻是一个异步操作,所以需要通过调用相关接口并轮询查询,来获取解冻操作返回的状态信息。其次,解冻操作具有一定的效率限制。具体而言,冷归档的解冻速度大约为每秒 500 个 QPS ,每天可处理大约 100 到 120TB 的数据。而对于深度冷归档,其解冻效率可能会稍低一些,大致为每天 10 到 15TB ,每秒 100 个 QPS 。因此,在进行解冻操作时,大家务必考虑这些效率因素,以便结合自身的业务需求,做出最佳实践的配置。
在提供这一生命周期规则后,许多大型客户都开始采用它,其中一个典型的例子就是网盘电影行业的领军企业。这些企业主要通过结合归档直读技术和生命周期规则,实现了成本的大幅降低。由于直接将数据转为冷存储会导致客户体验大幅下降,许多客户可能因此不再访问,所以他们需要在至少一段时间内能够快速访问这些数据。以往他们需要解冻数据,但这一过程对客户体验影响极大。而现在,通过采用基于热度的生命周期管理,结合访问时间和归档制度的功能组合,他们大幅提升了客户的用户体验。
此外,在互联网音视频领域,这一功能更是不可或缺。如今所有大型互联网客户,包括顶级的 APP 厂商,在阿里云上都已使用了这一功能。因此随着大家未来业务的发展,生命周期管理功能也将帮助大家节省成本,以及优化存储使用。