软文发布网站,企业营销图片,8469网站,设计公司logo的网站简介#xff1a; 作者#xff1a; 沄浩、士远
一 、背景
据IDC发布的《数据时代2025》报告显示#xff0c;全球每年产生的数据将从2018年的33ZB增长到2025年的175ZB#xff0c;平均每天约产生491EB数据。随着数据量的不断增长#xff0c;数据存储成本成为企业IT预算的重…简介 作者 沄浩、士远
一 、背景
据IDC发布的《数据时代2025》报告显示全球每年产生的数据将从2018年的33ZB增长到2025年的175ZB平均每天约产生491EB数据。随着数据量的不断增长数据存储成本成为企业IT预算的重要组成部分。例如1PB数据存储一年全部放在高性能存储介质和全部放在低成本存储介质两者成本差距在一个量级以上。由于关键业务需高性能访问因此不能简单的把所有数据存放在低速设备企业需根据数据的访问频度使用不同种类的存储介质获得最小化成本和最大化效率。因此把数据存储在不同层级并能够自动在层级间迁移数据的分层存储技术成为企业海量数据存储的首选。本文介绍数据仓库产品作为企业中数据存储和管理的基础设施在通过分层存储技术来降低企业存储成本时的关键问题和核心技术。
1. 什么是分层存储
分层存储顾名思义就是把数据分为高频访问的热数据和低频访问的冷数据并分别存储在热数据层和冷数据层达到性能与成本的平衡。热数据层采用高性能存储介质单位成本高为控制预算一般容量较小只存储关键业务数据例如ERPCRM数据或者最新的订单数据等。冷数据层则存储非关键业务数据例如审计日志运行日志等或历史沉淀数据例如一个月前的订单数据。此部分数据体量大访问频度低性能要求不高因此采用单位成本低容量大的存储介质来降低成本。同时随着时间流逝部分热数据访问频度会降低一般称为数据降温此时存储系统能够自动迁移该部分数据到冷数据层来降低成本。 2. 数据仓库分层存储面临的挑战
数据仓库产品在实现分层存储能力时面临的几个核心挑战如下
选择合适的存储介质。存储介质既要满足性能、成本需求还要满足可靠性、可用性、容量可扩展、运维简单等需求。业务上的冷热数据如何在分层存储中定义即如何描述哪部分是热数据哪部分是冷数据。冷热数据如何迁移随着时间流逝业务上的热数据降温为冷数据后数据仓库如何感知温度的变化并执行数据迁移来降低存储成本。如何加速冷数据的访问冷数据仍然会被访问比如因法规政策要求用户需对三个月前数据进行修订或者需要对过去一年的数据进行统计分析来进行历史回顾和趋势分析。由于冷数据体量大查询涉及的数据多存储介质性能低如果不进行优化对冷数据的元信息内容访问可能出现瓶颈影响业务使用。二 、数据仓库分层存储关键技术解析
本章将以阿里云数据仓库AnalyticDB MySQL版下文简称ADB为原型介绍如何在数据仓库产品中实现分层存储并解决其核心挑战。ADB的整体架构分为三层
第一层是接入层由多个前端节点构成主要负责接入用户查询进行SQL解析、优化、调度。第二层是计算引擎层由多个计算节点组成负责执行用户查询。第三层是存储引擎层由多个存储节点组成用户数据按Shard切片存储每个Shard有多个副本保证高可靠和高可用。1. 冷热数据存储介质的选择
对于业务上的热数据需采用高性能存储介质满足其快速查询需求。SSD相对HDD来说成本较高但其具有高IOPS和高带宽的特性因此ADB把热数据层建立在SSD上并使用数据多副本机制出现存储节点异常时通过切换服务节点来保证高可靠和高可用。业务上的冷数据一般是历史沉淀的业务数据或日志数据这些数据体量大访问频度低因此容量大、成本低是存储介质的主要选择因素。对于冷数据层ADB选择建立在阿里云OSS上。阿里云对象存储服务OSS作为阿里云提供的海量、低成本、高持久性的云存储服务其数据设计持久性不低于99.9999999999%服务可用性不低于99.995%。OSS提供的这些特性满足了冷数据层对成本和可靠性的需求同时相对于自己维护HDD磁盘OSS自身具有容量无限扩展能力满足海量数据存储需求。并且OSS可以远程访问因此存储节点的副本间可以共享数据来进一步降低成本。 2. 冷热数据定义问题
业务自身对冷热数据的定义比较明确。比如企业中一些需要高频访问的CRM、ERP数据均为热数据。而对于审计日志或数天前的订单数据其访问频度低则可定义为冷数据。核心问题是业务上的这些数据如何在分层存储中描述其冷热属性并保证存储位置的准确性。例如企业促销活动大量用户正在线上进行业务交互此时如果分层存储错误的把客户信息、商品信息等关键数据迁移到冷区则会引起相关查询性能受损最终出现客户登录受阻客户点击失败等业务异常导致企业受损。ADB解决这个问题的方法是在用户建表时指定存储策略storage_policy来精确关联业务上的冷热数据和分层存储中的冷热存储下面是示例。 全热表
所有数据存储在SSD并且不会降温适用于全表数据被频繁访问且对访问性能有较高要求的场景比如CRM、ERP数据。
Create table t1(id int,dt datetime
) distribute by hash(id)
storage_policy HOT;
全冷表
所有数据存储在OSS适用于体量大访问频度低需要减少存储成本的场景比如审计日志数据。
Create table t2(id int,dt datetime
) distribute by hash(id)
storage_policy COLD;
冷热混合表 适用于数据冷热有明显时间窗口的场景。例如最近7天的游戏日志数据广告点击数据等需高频访问作为热数据存储而7天前的数据可降温为冷数据低成本存储。 注冷热混合表需配合表的分区使用。除storage_policy外还需指定hot_partition_count属性。hot_partition_count指按分区值倒序取最大N个分区为热分区其余为冷分区。下例中表按天分区hot_partition_count 7表示分区值最大的7个分区也就是最近7天的数据为热数据。 Create table t3(id int,dt datetime
) distribute by hash(id)
partition by value(date_format(dt, %Y%m%d))
lifecycle 365
storage_policy MIXED hot_partition_count 7;
修改冷热策略 随业务的变化表的访问特性可能发生变化企业可以随时修改表的存储策略来适应新的存储需求。 1由热表修改为冷表
Alter table t1 storage_policy COLD;
2修改热分区的个数修改为最近14天的数据为热数据
Alter table t3 storage_policy MIXED hot_partition_count 14;
3. 冷热数据自动迁移问题
随时间流逝热数据的访问频度降低降温为冷数据。比如一些日志数据在数天后就很少再访问分层存储需把这部分数据由热数据层迁移到冷数据层来降低成本。这里的核心问题是如何知道哪部分数据的温度降低了需要迁移下面通过一个冷热混合表来说明ADB解决该问题的方法。如下是一张日志表最近三天数据为热数据满足高性能在线查询需求三天前数据为冷数据低成本存储并满足低频访问需求。
Create table Event_log (event_id bigint,dt datetime,event varchar
) distribute by hash(event_id)
partition by value(date_format(dt, %Y%m%d)) lifecycle 365
storage_policy MIXED hot_partition_count 3;
在本例中表首先按天分区。 partition by value(date_format(dt, %Y%m%d)) lifecycle 365并定义冷热策略为混合模式最新3天的数据是热数据。
storage_policy MIXED hot_partition_count 3在ADB中冷热数据以分区为最小粒度即一个分区要么在热区要么在冷区然后通过热分区窗口来判定某个分区是否为热分区表属性中的hot_partition_count定义了热分区窗口的大小。在本例中假定当前日期是3月4日则3月2日、3日、4日这三天的数据处于热分区窗口中因此是热分区。当写入3月5日的数据后则3月3日、4日、5日这三天数据组成了新的热分区窗口3月2日数据降温为冷数据后台会自动执行热冷迁移把3月2日的数据由热区迁移到冷区。通过热分区窗口客户根据业务场景可以明确定义冷热边界一旦数据降温则自动迁移。 4. 冷数据访问性能问题
冷数据存储在OSS上OSS是远程存储系统并通过网络访问延迟较高。例如判断文件是否存在获取文件长度等元信息操作单次交互的访问延迟在毫秒级别。同时OSS带宽有限一个账号下整体只有GB级别带宽提供的整体QPS也只有数十万超过后OSS就会限流。数据仓库内部存储着大量文件如果不对OSS访问做优化则会出现查询异常。例如查询可能涉及数百万个文件仅仅获取这些文件的元信息就会达到OSS的QPS上限最终导致查询超时等异常因此需对OSS的访问进行优化来保证业务的可用性并提高查询性能。如下对元信息访问优化和数据访问优化分别介绍。 元信息访问优化
ADB作为数据仓库底层存储了大量的数据文件和索引文件。ADB优化元信息访问的方法是对文件进行归档即把一个分区内的所有文件打包在一个归档文件中并提供一层类POSIX的文件访问接口通过这个接口去读取文件内容。 归档文件的Meta里内存储了每个子文件的偏移和长度等元信息。读取时先加载归档文件的Meta只需要一次交互即可拿到所有子文件元信息交互次数降低数百倍。为进一步加速ADB在存储节点的内存和SSD上分别开辟了一小块空间缓存归档文件的Meta加载过即无需再访问OSS获取元信息。同时归档后只需一个输入流便可读取所有子文件数据内容避免为每个子文件单独开启输入流的开销。 数据访问优化
查询中无论是扫描索引还是读取数据块都需要读取OSS上文件的内容而OSS无论访问性能还是访问带宽都有限。为加速文件内容的读取ADB存储节点会自动利用SSD上的一块空间做数据Cache且Cache的上层提供了类POSIX的文件访问接口数据扫描算子Table Scanner可以像访问普通文件一样访问Cache中的内容。 查询中对OSS的所有访问索引、数据等都可借助SSD Cache加速只有当数据不在Cache中时才会访问OSS。针对这块CacheADB还做了如下优化
多粒度的Cache Block加载元信息时使用较小的Block加载数据时使用较大的Block以此提高Cache空间利用率。元数据预热自动加载数据和索引的元数据到Cache中并锁定以实现元数据高效访问。基于冷热访问队列的类LRU算法实现无锁化高性能换入换出。自动IO合并相邻数据的访问合并为一个请求减少与OSS的交互次数。三、总结
随着企业数据量的不断增长存储成本成为企业预算中的重要组成部分数据仓库作为企业存储和管理数据的基础设施通过分层存储技术很好的解决了企业中存储成本与性能的平衡问题。对于分层存储技术中的关键挑战本文以云原生数据仓库AnalyticDB MySQL为原型介绍了其如何通过冷热策略定义热分区窗口文件归档SSD Cache来解决冷热数据定义冷热数据迁移冷数据访问优化等关键问题。 关于我们
AnalyticDB MySQL是阿里巴巴自主研发经过超大规模以及核心业务验证的PB级实时OLAP数据仓库。AnalyticDB MySQL存储团队致力于实现全球领先的云原生数据仓库存储服务提供云原生、实时化、高性能、低成本、安全可靠的企业级数仓存储能力通过持续不断的自研存储技术积累和突破帮助数以万计的用户享受云原生实时化分析能力实现数据价值在线化。
原文链接
本文为阿里云原创内容未经允许不得转载。
