大数据之路读书笔记-14存储和成本管理

大数据之路读书笔记-14存储和成本管理

在大数据时代，移动互联、社交网络、数据分析 云服务等应用迅速普及， 对数据中心提出了革命性的需求，存储管理已经成为 IT 核心。对于数据爆炸式的增长，存储管理也将面临着一系列挑战。如何有效地降低存储资源的消耗，节省存储成本，将是存储管理孜孜追求的目标。本章主要从数据压缩、数据重分布、存储治理项优化、生命周期管理等的角度介绍存储管理优化。

---

14.1 数据压缩

在分布式文件系统中，为了提高数据的可用性与性能 ，通常会将数据存储3份，这就意味着存储 1TB 的逻辑数据， 实际上会占用3TB物理空间。目前 MaxCompute 中提供了 archive 压缩方法，它采用了具有更高压缩比的压缩算法，可以将数据保存为 RAID file 的形式，数据不再简单地保存为3份，而是使用盘古 RAID file 的默认值（6 ,3 ）格式的文件，即6份数据＋3份校验块的方式，这样能够有效地将存储比约为1：3 提高到 1: 1.5 ，大约能够省下一半的物理空间。当然，使用archive压缩方式也有一定的风险，如果某个数据块出现了损坏或者某台机器宕机损坏了，恢复数据块的时间将要比原来的方式更长，读的性能会有一定的损失。因此，目前一般将 archive 压缩方法应用在冷备数据与日数据的压缩存储上。例如， 些非常大的淘系日志数据，底层数据超过一定的时间期限后使用的频率非常低，但是又是属于不可恢复的重要数据，对于这部分数据就可以考虑对历史数据的分区进行 archive 压缩，使用 RAID file 来存储，以此来节省存储空间。示例如下：

alter table A partition(ds= ’ 20130101 ’) archive ;

其输出信息如表 14.1所示。

在输出信息中可以看到 archive 前后的逻辑存储（ File size ）和物理存储（ Fi le physical size ）的变化情况，而且在这个过程中会将多个小文件自动合并。

14.2 数据重分布

在MaxCompute 主要采用基于列存储的方式，由于每个表的数据分布不同，插人数据的顺序不 样，会导致压缩效果有很大的差异，因此通过修改表的数据重分布，避免列热点，将会节省一定的存储空间。目前我们主要通过修改 distribute by sort by 字段的方法进行数据重分布，如图 14.1 所示。
数据重分布效果的波动比较大，这主要跟数据表中宇段的重复值、字段本身的大小、其他宇段的具体分布有一定的关系， 一般我们会筛选出重分布效果高于 15% 表进行优化处理。
重分布前后一些底层大表的效果对比如表 14.2 所示。

14.3 存储治理项优化

阿里巴巴数据仓库在资源管理的过程中，经过不断地实践，慢慢摸索出一套适合大数据的存储优化方法，在元数据的基础上，诊断、加工成多个存储治理优化项。目前已有的存储治理优化项有未管理表、 空表最近 62 天未访问表、数据无更新无任务表 、数据无更新有任务表、开发库数据大于 lOOGB 且无访问表、长周期表等。通过对该优化项的数据诊断形成治理项，治理项通过流程的方式进行运转、管理，最终推动各个ETL 发人员进行操作，优化存储管理，并及时回收优化的存储效果。在这个体系下，形成现状分析、 问题诊断、管理优化、效果反馈的存储治理项优化的闭环。通过这个闭环，可以有效地推进数据存储的优化，降低存储管理的成本。
存储治理项优化的主要流程如图 14.2 所示。

14.4 生命周期管理

MaxCompute 作为阿里巴巴集团的大数据计算及服务引擎，存储着阿里系大量且非常重要的数据，从数据价值及数据使用性方面综合考虑，数据的生命周期管理是存储管理的一项重要手段。生命周期管理的根本目的就是用最少的存储成本来满足最大的业务需求，使数据价值最大化。

14.4.1 生命周期管理策略

1 .周期性删除策略
所存储的数据都有一定的有效期，从数据创建开始到过时，可以周期性删除X天前的数据。例如对于 MySQL 业务库同步到 MaxCompute 的全量数据，或者 ETL 过程产生的结果数据，其中某些历史数据可能已经没有价值，且占用存储成本，那么针对无效的历史数据就可以进行定期清理。
2.彻底删除策略
无用表数据或者 ETL 过程产生的临时数据，以及不需要保留的数据，可以进行及时删除，包括删除元数据。
3.永久保留策略
重要且不可恢复的底层数据和应用数据需要永久保留。比如底层交易的增量数据，出于存储成本与数据价值平衡的考虑，需要永久保留，用于历史数据的恢复与核查。
4.极限存储策略
极限存储可以超高压缩重复镜像数据，通过平台化配置手段实现透明访问：缺点是对数据质量要求非常高，配置与维护成本比较高，建议一个分区有超过 5G 的镜像数据（如商品维表、用户维表）就使用极限存储。
5.冷数据管理策略
冷数据管理是永久保留策略的扩展。永久保留的数据需要迁移到冷数据中心进行永久保存，同时将 MaxCompute 中对应的数据删除。一般将重要且不可恢复的、占用存储空间大于 lOOTB ，且访问频次较低的数据进行冷备，例如3年以上的日志数据。
6.增量表merge 表策略
对于某些特定的数据，极限存储在使用性与存储成本方面的优势不是很明显，需要改成增量同步与全量merge 的方式，对于对应的 delta增量表的保留策略，目前默认保留 93 天。例如，交易增量数据，使用订单创建日期或者订单结束日期作为分区，同时将未完结订单放在最大分区中，对于存储，一个订单在表里只保留一份；对于用户使用，通过分区条件就能查询某一段时间的数据。

14.4.2 通用的生命周期管理矩阵

随着业务的发展和不断的数据实践，我们慢慢摸索出一套适合大数据生命周期管理的规范，主要通过对历史数据的等级划分与对表类型的划分生成相应的生命周期管理矩阵。
1.历史数据等级划分
目前我们对历史数据进行了重要等级的划分，主要将历史数据划分为PO、P1、P2、 P3 四个等级，其具体定义如下。
● PO ：非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如交易、日志、集团 KPI 数据、 IPO 关联表。
● Pl ：重要的业务数据和重要的应用数据，具有不可恢复性，如主要的业务产品数据。
● P2 ：重要的业务数据和重要的应用数据，具有可恢复性，如交易ETL 产生的中间过程数据。
● P3 ：不重要的业务数据和不重要的应用数据，具有可恢复性，如某些 SNS 产品报表。
2.表类型划分
( 1) 事件型流水表（增量表）
事件型流水表（增量表）指数据无重复或者无主键数据，如日志。
(2 ）事件型镜像表（增量表）
事件型镜像表（增量表）指业务过程性数据，有主键，但是对于同一样主键的属性会发生缓慢变化，如交易、订单状态与时间会根据业务发
生变更。
(3 ）维表
维表包括维度与维度属性数据，如用户表、商品表。
(4) Merge 全量表
Merge 全量表包括业务过程性数据或者维表数据。由于数据本身有新增的或者发生状态变更，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行 Merge 操作，主键对应的属性只会保留最新状态 ，历史状态保留在前一天分区中。例如，用户表、交易表等都可以进行 Merge 操作。
( 5) ETL 临时表
ETL 临时表是指 ETL 处理过程中产生的临时表数据，一般不建议保留，最多7天。
(6) TT 临时数据
TT 拉取的数据和 DbSync 产生的临时数据最终会流转到ODS 层，ODS 层数据作为原始数据保留下来，从而使得 TT&DbSync 上游数据成为临时数据。这类数据不建议保留很长时间，生命周期默认设置为 93天，可以根据实际情况适当减少保留天数。
(7 ）普通全量表
很多小业务数据或者产品数据， BI一般是直接全量拉取 ，这种方式效率快，对存储压力也不是很大，而且表保留很长时间，可以根据历史数据等级确定保留策略。
通过上述历史数据等级划分与表类型划分，生成相应的生命周期管理矩阵 ，如 14.3 示。


Max Compute 集群中海量数据的存储和大量计算任务每天都会消耗巨额成本，并且随着数据量的不断增长，这个成本还在逐步增加，如何在服务好业务的前提下，更好地管控数据成本，提升资源利用率已成为数据资产管理工作中非常重要的一环。
在阿里巴巴集团内部，大部分数据都会存储在 MaxCompute 集群上，数据以数据表的形式存在，并且数据之间存在比较复杂的关联和上下游依赖关系。可以把数据表之间的依赖 系用树形结构形象化地表示，如图 14 .3 所示。图中的A、B、C代表不同的数据表，带箭头的连线代表数据表之间的依赖和关联关系。比如数据B、C、D都依赖数据表A，数据表E依赖数据表B和C。

MaxCompute 中的任何一个计算任务都会涉及计算和存储资源的消耗，其中计算资源的消耗主要考虑CPU 消耗。为了下面更好地描述数据计量计费的算法和规则，特做如下定义 CPU 消耗的单位定义为 CU,代表CPU的一个核心（ Core ）运行一天的消耗量。存储资源的消耗主要考虑磁盘存储的消耗，这里采用国际通用的存储单位 PB 来衡量。例如：计算资源的单价为1元／CU ，存储资源的单价为1元/ PB 天。

14.5 数据成本计量

对数据成本的计量，可以采用最简单的方式，将一个数据表的成本分为存储成本和计算成本。存储成本是为了计量数据表消耗的存储资源，计算成本是为了计量数据计算过程中的CPU 消耗。但是，对这样的数据成本计量方式会存在较大的质疑和挑战。例如，如图 14.4 示，表D是业务方的一个数据表，表D依赖表C，但是为了产生表C，往往上面存在一个较长的数据刷新链路。表C的成本可能是 10 元，但是表A、表B可能会是 100 元。像这样的情况，如果表C的成本仅仅用 数据表C自身的存储和计算成本衡量显然是不合理、不准确的。

因此，在计量数据表的成本时，除考虑数据表本身的计算成本、存储成本外，还要考虑对上游数据表的扫描带来的扫描成本。我们将数据成本定义为存储成本、计算成本和扫描成本三个部分。

通过在数据成本计量中引人扫描成本的概念，可以避免仅仅将表自身硬件资源的消耗作为数据表的成本，以及对数据表成本进行分析时，孤立地分析单独的一个数据表，能够很好地体现出数据在加工链路中的上下游依赖关系，使得成本的评估尽量准确、公平、合理。

14.6 数据使用计费

在上一节中，已经清楚地将数据成本分为：存储成本、计算成本和扫描成本。那么对于数据表的使用计费，在阿里巴巴集团内部，分别依据这三部分成本进行收费，称为：计算付费、存储付费和扫描付费我们把数据资产的成本管理分为数据成本计量和数据使用计费两个步骤。通过成本计量，可以比较合理地评估出数据加工链路中的成本，从成本的角度反映出在数据加工链路中是否存在加工复杂、链路过长、依赖不合理等问题，间接辅助数据模型优化，提升数据整合效率；通过数据使用计费，可以规范下游用户的数据使用方法，提升数据使用效率，从而为业务提供优质的数据服务。