共计 4909 个字符，预计需要花费 13 分钟才能阅读完成。
简介： 作者：沄浩、士远
一、背景
据 IDC 公布的《数据时代 2025》报告显示，寰球每年产生的数据将从 2018 年的 33ZB 增长到 2025 年的 175ZB，均匀每天约产生 491EB 数据。随着数据量的一直增长，数据存储老本成为企业 IT 估算的重要组成部分。例如 1PB 数据存储一年，全副放在高性能存储介质和全副放在低成本存储介质两者老本差距在一个量级以上。因为要害业务需高性能拜访，因而不能简略的把所有数据寄存在低速设施，企业需依据数据的拜访频度，应用不同品种的存储介质取得最小化老本和最大化效率。因而，把数据存储在不同层级，并可能主动在层级间迁徙数据的分层存储技术成为企业海量数据存储的首选。本文介绍数据仓库产品作为企业中数据存储和治理的基础设施，在通过分层存储技术来升高企业存储老本时的关键问题和核心技术。
1. 什么是分层存储
分层存储顾名思义，就是把数据分为高频拜访的热数据和低频拜访的冷数据，并别离存储在热数据层和冷数据层，达到性能与老本的均衡。热数据层采纳高性能存储介质，单位成本高，为管制估算个别容量较小，只存储要害业务数据，例如 ERP，CRM 数据，或者最新的订单数据等。冷数据层则存储非关键业务数据，例如审计日志，运行日志等，或历史积淀数据，例如一个月前的订单数据。此局部数据体量大，拜访频度低，性能要求不高，因而采纳单位成本低，容量大的存储介质来降低成本。同时，随着工夫流逝，局部热数据拜访频度会升高（个别称为数据降温），此时存储系统可能主动迁徙该局部数据到冷数据层来降低成本。
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。针对这块 Cache，ADB 还做了如下优化：
多粒度的 Cache Block，加载元信息时应用较小的 Block，加载数据时应用较大的 Block，以此进步 Cache 空间利用率。
元数据预热，主动加载数据和索引的元数据到 Cache 中并锁定，以实现元数据高效拜访。
基于冷热拜访队列的类 LRU 算法，实现无锁化高性能换入换出。
主动 IO 合并，相邻数据的拜访合并为一个申请，缩小与 OSS 的交互次数。
三、总结
随着企业数据量的一直增长，存储老本成为企业估算中的重要组成部分，数据仓库作为企业存储和治理数据的基础设施，通过分层存储技术很好的解决了企业中存储老本与性能的均衡问题。对于分层存储技术中的要害挑战，本文以云原生数据仓库 AnalyticDB MySQL 为原型，介绍了其如何通过冷热策略定义，热分区窗口，文件归档，SSD Cache 来解决冷热数据定义，冷热数据迁徙，冷数据拜访优化等关键问题。
对于咱们
AnalyticDB MySQL 是阿里巴巴自主研发，通过超大规模以及外围业务验证的 PB 级实时 OLAP 数据仓库。AnalyticDB MySQL 存储团队致力于实现寰球当先的云原生数据仓库存储服务，提供云原生、实时化、高性能、低成本、安全可靠的企业级数仓存储能力，通过继续一直的自研存储技术积攒和冲破，帮忙数以万计的用户享受云原生实时化剖析能力，实现数据价值在线化。
原文链接
本文为阿里云原创内容，未经容许不得转载。
