共计 3546 个字符，预计需要花费 9 分钟才能阅读完成。
简介：存储策略该怎么设计
写这篇存储布局的文章次要是想通知大家该如何给存储做一个布局，在关系数据库的时代存储低廉且珍惜，掰手指头花钱是存储布局的常态。然而到了大数据时代大家又立刻就都变成印美元的美国政府了，感觉存储很多能够随便霍霍，然而又不停的求国会再晋升政府债权下限。反而造成了一种日子过的还不如关系数据库的感觉，至多是看着人家没有咱们这么焦灼和生灵涂炭。怎么就让咱们动则以 PB 计算的大数据产品，日子过的比论 GB 过日子的关系数据库还惨呢？
公共云费用测算
在私有云，MaxCompute 为了吸引新用户去理解和应用产品，实际上做到了 1 元钱学习 MaxCompute 和 DataWorks 的成果，学习应用老本非常低，账户充值 10 块钱都能轻易畅游这两款产品 1 年。所以，咱们要看下真正的用户免费是什么样子的。
l 套餐资源
链接：https://help.aliyun.com/docum…
套餐蕴含计算资源和存储资源，如下表所示。
l 套餐价格
l 存储费用测算
依据上表咱们做一个简略测算。应用 160CU 的规格存储为 150TB 的套餐，超出 100TB 时每天的费用是 0.019 元1000GB100TB=1900 元，每月费用是 57000 元，大于套餐包价格 35000 元。
存储爆炸起因
从下面的例子咱们能够看到，假如在计算资源够用的状况下，存储的减少带来的老本的回升是难以承受的。而且计算是跟业务需要强关联，如果没有新的业务需要，每天解决数据的量不会大幅变动，然而批量零碎每天都会产生新一天的数据。
假如咱们应用 MaxCompute 集成一个大小为 100G 的交易型零碎的数据库，数据加工的时效是 T +1，会有两方面因素导致数据存储的收缩。
- 快照表。快照表是指 MaxCompute 的表的每一个分区的数据都是业务零碎对应的表的一份镜像。依照集成频次 T +1，一个 100G 的业务零碎每天在 MaxCompute 存储一份快照，一年的存储要求是（365*100G）36.5TB。
- 分层架构。依照个别数据仓库的分层架构，至多会分为 3 层，镜像层、中间层、应用层。数据入仓后每回升到一个新的分层，数据都会被复制一份。尤其是到了应用层，不同的利用会多份复制数据进行共性加工。咱们暂且拍一个比拟激进的比例：1:1:1，那么每年对存储的需要就减少到了 36.5*3=100TB。
所以，通过下面的测算咱们失去了一个非常简单的换算（正当然而可能不够准确），如果应用 MaxCompute 集成一个存储规模为 100GB 的业务零碎，采纳 T + 1 频次计算，那么咱们每年须要的存储空间是源零碎的 1000 倍（也是就说 100GB 变成了 100TB）。
存储设计
通过下面局部的剖析，咱们晓得了快照表的存储模式是导致数据被复制了很多份的最大的起因。1 行 1 年内没有更新的记录应用快照存储，会被复制 365 份。那么为什么数据仓库 ETL 过程会大量应用快照表呢？总的来说就是构造简略好用，适宜 ETL 加工。
杜绝快照表是不可能的，那就须要思考如何设计存储。存储优化有两个方向，第一个方向就是压缩，第二个方向是清理。
数据清理
数据清理比较简单，重要的是把不须要的数据及时清理掉。数据清理的办法有：
- 业务下线。曾经不再应用的应用层数据表，是否能够清理下线。
- 主动回收。利用 lifecycle 设定分区的生效工夫，零碎后盾主动回收。
ALTER TABLE table_name SET LIFECYCLEDAYS;
ALTER TABLE table_name partition[partition_spec]ENABLE|DISABLE LIFECYCLE;
- 被动治理。个别用于生产环境管控，不同的档次采取不同的策略，例如存储最近 N 天 + 月末时点快照。被动治理应用自定义脚本的办法定时清理不须要的数据分区。还有被动治理能够对开发环境或者一些我的项目空间设置存储下限，疏导开发人员去设计和治理存储。要求长期表应用完就立刻开释。
- 反复存储。一些数据表只是一个两头后果集，并没有长期存储的必要，能够倡议开发人员应用视图或者长期表代替或者缩小不必要的历史存储周期。
数据清理会删除一部分分区的数据，这也代表着一部分工夫的快照的状态被从历史中革除了。T+ 1 的批量会记录每行数据每天的最初一个状态，然而如果保留策略是月末 + 最近 N 天，那么最初咱们能从历史数据中获取到的数据状态就是每月的最初一个状态。
这种状况下，历史数据清理到什么水平，是须要一个业务领导。还有倡议在数仓分层架构的最上面的档次对历史数据进行保留。
以清理策略为“保留月末 + 最近 10 天”的数据存储需要为例，一年的存储需要从 100TB 裁剪到 100GB(12 个月 + 最近 10 天) 3 层 =6.6TB，变成了原来策略的 1 /15。原来 160CU 规格的存储 150TB，能够让存储为 100GB 业务零碎的数据存储 1.5 年，当初则变成了 20 年。
数据压缩
数据压缩是指利用产品自带的存储压缩个性，或者利用拉链表构造压缩存储。
l 在以后表上进行压缩
- 归档。将存储比从 1:3 进步到 1:1.5，能够节俭一半的物理空间，同时也采纳了更高压缩比的压缩算法。
alter table my_log partition(ds=’20170101′) archive;
如果启用归档策略，对历史数据进行归档。咱们能够看到存储会在原有根底上放大一半。能够让每年 100TB 存储需要，缩小为 50TB。
l 备份到另外一张表
- 分区合并。对于一些数据量十分小的表，历史数据的备份存储能够采纳把一个区间内所有数据合并到一个分区的办法来优化存储（次要还是优化小文件）。
- 拉链表。拉链表是传统数仓得以运行的外围数据存储办法，在 MaxCompute 上依然能够应用这个办法。拉链算法的外围是让每条记录的每个状态变动都保留为 1 行记录，而不是快照表的 N 份，这种办法能大量节约存储资源。
如果启用拉链表策略，数据存储能够认为与源零碎根本持平，只是须要计算分层复制。一年的存储需要从 100TB 裁剪到 100GB 1 天 3 层 =0.3TB，变成了原来策略的 1 /300。原来 160CU 规格的存储 150TB，能够让存储为 100GB 业务零碎的数据存储 1.5 年，当初则变成了 500 年。(这个计算过于理想化，因为 ETL 过程都次要应用快照表来施行，所以，只能对临时不须要应用的历史数据备份)。
备份就相当于表构造与原来不统一了，会发生变化。所以，拜访历史数据须要应用与快照表不一样的办法。
拉链表链接：https://developer.aliyun.com/…
压缩比照
快照表与拉链表
拉链表与快照表比拟起来有更低和更正当的存储个性。
快照表与拉链表构造比照如下：
• 拉链表的每个主键在存储周期的所有时点，一个状态只存储了一行数据。
• 快照表的每个主键在存储周期的所有时点，每个时点都会存储一行数据。
从下面的比拟能够看进去，应用快照表存储数据，每个 MaxCompute 的数据分区都会存储一份数据，而拉链表只存储了一份数据。看起来存储大小比照是 N：1，N 就是快照表的分区个数，而 1 就是 1 个最新快照表的分区大小。
拉链表的压缩比
上面是依据理论数据测算的两种数据表的压缩比，一种是记录增长率低的表，另外一种是记录增长率高的表。比照发现，应用拉链表存储后一月的数据大概都只是 1 天数据的 1 倍左右。
A 表：记录增长率低表【用户信息】
日期：20170501-20170531
天数：31 天
B 表：记录增长率高表【交易日志 / 事件表】
日期：20170501-20170531
天数：31 天
存储归档的压缩比
如果 Project 里的空间比拟缓和，须要进行数据删除或数据压缩，能够思考 MaxCompute 里对表的 Archive 性能，成果是能够将存储空间压缩 50% 左 右。Archive 性能将数据存为 Raid File，数据不再简略的存三份，而是 6 份数据 + 3 份校验块的形式，这样无效的将存储比从 1:3 进步到 1:1.5，能够节俭 一半的物理空间，同时也采纳了更高压缩比的压缩算法。上述的操作也是有代价的，如果某个数据块损坏或某台机器损坏，复原数据块的工夫要比原来的形式更长，读的性能也会有肯定损失。所以当初这种性能能够用在一些冷数据的压缩存储上，例如一些十分大的日志数据，超过肯定工夫期限后应用的频率非常低，然而又须要长期保留，则能够思考用 Raid File 来存储。
理论应用测算成果如下：
总结
通过以上介绍，咱们理解到了罕用的存储计划，理解到了快照表、拉链表和存储压缩和历史数据清理的办法。置信大家心里曾经有了肯定的想法，该怎么去布局和设计咱们的存储策略。
再有存储与计算是有肯定的换算关系，压缩须要计算资源，没有计算资源，存储缩减的办法就只有一条：删除数据。个别批量零碎都是夜间运行，所以，能够把压缩存储的工作安顿在白天执行。
原文链接
本文为阿里云原创内容，未经容许不得转载。
