对象存储OSS产品介绍

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,内容安全 1000次 1年
对象存储 OSS,恶意文件检测 1000次 1年
简介: 本次分享由王太平(征越)主讲,围绕阿里云对象存储OSS的产品介绍、成本优化、功能实战及最佳实践展开。内容涵盖OSS的五种存储类型及其应用场景,详细解析了生命周期管理在数据存储成本优化中的重要作用,并提供了具体的配置建议和实际案例。适合希望深入了解OSS及优化存储成本的用户参考。

内容介绍:

一、产品介绍

二、产品选型

三、功能实战

四、最佳实践

 

本次分享的主题是对象存储oss产品介绍(成本优化篇-生命周期管理),由王太平(征越)分享。

image.png

 

1.产品介绍

产品技术背景-数据持续爆发增长

根据IDC的预测,到2025年,全球数据达到175ZB。


在刚开始做存储时,大多数的存储设备只存数据库里的结构化数据,非结构化数据不存储。之后开始存储一些非结构化数据,到了移动互联网时代,每人用手机APP产生的数据(如朋友圈、抖音,数据大量膨胀,其次是物联网机器产生的数据(如自动驾驶各种车辆产生的数据),数据的价格相对于十几年前是飞速下跌的,当年1TB/几百GB存储在核心数据库(如运营商、航空业、金融等)的费用是几百万人民币。时至今日,OSS存储标准型1GB一个月仅需0.12元,1TB就100元/月,如果用阿里云提供的深度冷归档,1GB一个月才0.75。


上述说明虽然数据在急速增长,但数据热度和数据价值却在急速下降,这就需要有更低成本的存储产品。云上的对象存储就是一个根据产业技术发展不断降本的过程。

image.png

在持续降本的过程中,由于不同的业务架构,我们把对象存储分为很多层,今天重点讲解这些层之间怎样更好的管理。


再说回对象存储,它是云上存储最基础的一个产品,经过多年的发展,它有很多领域的服务要求,比如访问与加速、云上的存储、数据管理、数据处理、湖、交互、工具,这些都是对外服务的东西。


对象存储OSS:海量扩展、稳定可靠、安全合规、低成本、智能

image.png

核心竞争力

缩回最底层,这个存储还有很多种类型,重点讲成本优化。

image.png

产品核心功能-5种存储类型覆盖各类冷热数据场景

阿里云的对象存储分为五层:标准、低频、归档、冷归档、深度冷归档。


一个对象存储有5种存储类型,意味着您可以根据您的业务数据选择不同的层级存储产品。这五种类型有一定区别。上面三层标准、低频和归档的可以实时访问,对于业务系统来说,只需考虑成本和访问效率,无需额外处理。但冷归档和深度冷归档在访问时需要有额外操作。从上到下,存储费用越来越便宜,但是对数据访问的费用越来越高。

image.png

在使用过程中,业务主要分为两种:


一是某音视频文件短期内刚上传/刚产生时,它的访问热度较高,过一段时间之后,访问热度急剧下降/无人访问,但有其他事件/其他原因导致数据的热度突然发生变化,这时发现数据的热度是随机的,但总体来说,符合按照时间越来越冷,但会因为各种原因触发数据会转热。我们对数据的热度评估按照一段时间内的访问热度。以前做传统存储就有分层的概念,按数据的热度分层。


二是数据热度随着时间越来越冷,如个人数据(个人手机里的照片、朋友圈、家里的视频监控),大部分互联网的音视频都有这样的特征,在短期内访问后,后续不会再访问,这和文件的创建时间有关,创建时间越短,热度越高,创建时间越长,热度越低。很多时候都没有访问需求了,但由于各种合规合法的要求,需长期保存,比如金融的票据影像、医疗领域的医疗影像、各种检测结果,这都是需要长期保存,只在法律和合规的情况下再次触发,这时,他对再次读取的时间没有那么高的要求。

image.png

针对不同的场景,我们可以提供两种不同的生命周期。


第一,按照热度,热就把它转热,冷了转冷,整个过程是冷热可变的。


第二,判定标准以最后一次什么时访问时间为准。


还有一种,实际上大部分数据是没有那么复杂的冷热频率变化的,创建越早数据更热,创建越晚数据越冷。因此我们在对象存储上提供了一个功能——生命周期管理,即管理存储bucket里的数据,使它在适当的时候存储到适当的层里,甚至在适当的时候删除/清除。这就是数据从写入到降本,降低到更冷的层次,再到删除的从生到死的过程,称为生命周期管理。

image.png

 

2.产品选型

生命周期管理最本质的问题就是成本。这么多层次的产生目的就是节省成本。但有时操作不当节省不了成本,反而影响业务成本。这时来看一下层的商务情况。


单从存储成本来说,标准存储0.12元/GB/月,低频0.08元/GB/月,归档0.033元/GB/月,相当于标准存储1/3的价格。


低频、归档、冷归档便宜了,但读取时要额外收费。数据取回的价格;低频数据取回是0.0325元/GB,假设所有的数据每月取回一次,发现低频和标准价格差不多。所以我们在判定哪个数据往下沉降时,一定要考虑取回成本可能产生的费用。取回的成本可从两部分来判断:


第一,假设数据在转冷之后有访问的可能性,那它在短期内/一个月内会被频繁的访问还是只会有单次的访问?


第二,1TB的数据大概有百分之几的数据会在一个月内被取回访问如果万分之一的数据被访问,那一个月内被访问也无所谓,但如果50% 70%的数据都有可能随时取回,放在更冷的层次就不合适。


冷归档和深度冷归档需要解冻才可访问。这就需考虑是否把它放进去,业务系统是否能容忍这样的时间差。比如最终客户服务中,客户的数据都放到冷归档,最终客户如果能接受在访问的时候等待从冷转热的时间就可以。因此我们在考虑的就是成本的问题。

image.png

 

3.功能实战

功能实战1:基于最后一次修改时间配置生命周期规则

关于生命周期的建议,这些建议就是我们日常过程中可能会忽略的一些东西。


第一,修改时间,意味着创建时间。因为大部分互联网文件在创建完就不修改,如果把文件再覆盖写,就以覆盖写的时间为准。假设这个数据的生命周期有严格的规律,按照创建的时间长期保持。这时生命周期可以按照前缀匹配,前缀是对象存储里的名词,即目录,可以设定只对单个目录做规则。


其次,可以按照标签匹配,不同的应用/数据打不同标签,可以根据标签做。匹配过程中可以匹配整个bucket,也可以匹配单个目录。有很多场景,如果想针对一个大的bucket或大的目录去做,但底下有一个小目录,要跳过小目录,我们还提供个note元素的操作。


生命周期有两种设置方式:

一是过期天数。数据创建了多少天之后把它放到哪一层,多少天后把它删除掉。


二是说某时间以前的数据要把它放到什么时候,业务有明显的生命时间周期的种比较合适,有明确的时间点,有明确的数据分割,就可以用生命周期做。


生命周期规则并不是在实时生效的,它实际上是异步的。创建生命周期规则后,会在24小时内加载,在下一天早上八点加载,开始执行。如果数据条数不超过10亿条,在北、上、深、杭一天就可完成。如果数据条数大于10亿条,大概一天10亿条的处理规模,这是最基本的操作。


这里面有一些我们最容易忽视的东西:


第一,排除小文件,低频、归档、冷归档和深度冷归档对于小于64KB的文件都按照64K计费。如果有1K/2K的文件,可能会带来几十倍的容量放大,放到更冷的层次反而不一定节省成本。


第二,对于转冷,不管是低频、归档,冷归档和深度冷归档都有最小存储时长的要求。假设存储进去第二天就把它删了,还会按照时常收费,这就得不偿失了。


所以大家在做规划时,一定要考虑收费模式,尤其是对于低频和归档来说, 30天和60天是以数据写入的时间为准;对于冷归档和深度冷归档来说, 180天是指数据存储到冷归档层/深度冷归档要存够180天。这时在核算整体生命周期规则时要考虑时间线。


对于数据的删除,我们建议大家不要手动删除,因为手动的批量删除执行起来比较麻烦,生命周期执行既高效又易用,而且还是异步操作,后台调度也不会影响前端的IO效率。


冷归档和深度冷归档的访问请求的API一般相对于标准更贵的,如果文件比较小,批量的导入冷归档和深度冷归档bucket时,会瞬间产生大量API费用。在创建bucket时,可以设置bucket的类型。如果冷归档和深度冷归档默认写进去就是这两种类型,这会导致API费用较高,如果期望使用冷存储层降低成本,那建桶时千万不要建成这种类型的桶,就建成标准桶,通过生命周期把数据转冷,而不是直接写入冷层。

image.png


功能实践2:基于最后一次访问时间配置生命周期规则

最后一次访问时间,适合数据冷热没有明显周期,或冷数据要求可以online访问。

这有几个点需要大家注意:


第一,生命周期规则不支持配置删除。


第二,它的匹配条件当前仅支持bucket前缀和标签。


其次,转冷有两种方式,一是标准到低频,到了低频再次被访问时可以转回来,二是转到归档、冷归档和深度冷归档,需要工单开通,这适合在一段时间内希望它online,在超过一段时间可以接受它offline,或有一定的解冻时间。


对于以上情况有以下几个建议:

第一,生命周期是可以设置多条的,多条之间如果冲突,是以最最节省成本的方式去执行。比如A生命周期规则要求文件转到归纳型,B生命周期算下来要求转到冷归档,那这个数据就会转冷归档,它一定执行最节省成本的方式。

第二,使用最后一次访问时间的生命周期需要开启防追踪功能,这个功能现在是不收费的。


哪些操作会触发最后一次访问时间的更新呢?主要就是要对文件和文件的原数据进行操作,比如get(获取/下载、copy(文件拷贝)、修改文件权限、覆盖文件,都会更改文件的最后一次访问时间。

image.png

如果数据进入冷层如何转热? 对于低频来说,有访问请求的费用,但不需要做取回操作;


对于归档型就有两种,一种是归档直读,和低频类似,没有单独的操作,如果采用解冻的方式,需要触发解冻操作,解冻完后会有解冻状态续时间,持续时间内会单次性按照时间收费,但数据本质上不会存储两份。


但是对于冷归档和深度冷归档,解冻后能在标准层的存储空间里存储一份数据,这时会产生取回费用和临时存储费用,所有该时间段内的请求都会从APP到达标准层存储里进行访问。解冻会产生费用有API费用、解冻取回操作费以及结算完成后数据的临时存储的费用。


因为解冻是异步操作,所以只能调用接口来查询返回图上的一些信息。其次解冻是有一定的效率的,比冷归档大概500 QPS/秒, 100TB-120TB的数据,对于深度冷归档,效率可能会低一些,大概是每天大概10TB-15TB,100 QPS/秒。大家在解冻时一定要考虑效率问题,才能结合业务,做最佳实践配置。

image.png

 

4.最佳实践

最佳实践:视图下载场景数据智能分层

下图是典型的网盘电影客户,主要使用两者结合,通过归档直读和生命周期规则,让成本大幅下降。它不能直接转冷,转冷后客户体验会差,很多客户不愿意再访问,至少在一段时间内可以很快的解决。以前是需要解冻的,对客户体验影响非常差。后来按照热度的生命周期,安装防护时间以及归档直读组合,大幅的提升了客户体验。

image.png

最佳实践:视图下载场景数据智能分层

其次在互联网、音视频这些领域,此功能更是必备功能。现在所有的大型互联网客户在阿里云上都使用了这个功能。随着未来业务的发展,可以通过生命周期管理功能帮助大家节省成本,优化存储的使用。

image.png

以上是本次分享的全部内容。

image.png

 

 

 

 

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
相关文章
|
5月前
|
文字识别 算法 API
视觉智能开放平台产品使用合集之上传素材文件不在同一地域的OSS,怎么上传多张图片
视觉智能开放平台是指提供一系列基于视觉识别技术的API和服务的平台,这些服务通常包括图像识别、人脸识别、物体检测、文字识别、场景理解等。企业或开发者可以通过调用这些API,快速将视觉智能功能集成到自己的应用或服务中,而无需从零开始研发相关算法和技术。以下是一些常见的视觉智能开放平台产品及其应用场景的概览。
56 1
|
6月前
|
监控 Java Serverless
函数计算产品使用问题之对于OSS打包的zip的保存目录,该如何操作
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
7月前
|
运维 Serverless 应用服务中间件
Serverless 应用引擎产品使用合集之关于OSS映射目录的大小限制,如何可以跳过
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
Serverless 应用引擎产品使用合集之关于OSS映射目录的大小限制,如何可以跳过
|
5月前
|
存储 运维 Serverless
函数计算产品使用问题之OSS触发器是否可以只设置文件前缀
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
6月前
|
分布式计算 DataWorks 调度
DataWorks产品使用合集之多个业务流程上传同名资源到同一个OSS(对象存储服务)URL,会产生什么问题
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
6月前
|
消息中间件 分布式计算 DataWorks
DataWorks产品使用合集之如何使用Python和阿里云SDK读取OSS中的文件
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
6月前
|
分布式计算 DataWorks 调度
DataWorks产品使用合集之在使用MaxCompute进行数据集成同步到OSS时,出现表名和OSS文件名不一致且多了后缀,该如何处理
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
6月前
|
DataWorks 安全 定位技术
DataWorks产品使用合集之如何同步OSS中的Parquet数据,并解析里面的数组成多个字段
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
6月前
|
分布式计算 DataWorks 数据处理
DataWorks产品使用合集之要获取OSS文件大小并配置成调度任务,该如何操作
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
5月前
|
存储 Java 关系型数据库
实时计算 Flink版产品使用问题之以jar包方式同步数据是否需要定义存储oss的位置
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。