摘要

本文主要探讨了数据存储与成本管理的多种策略。介绍了数据压缩技术，如MaxCompute的archive压缩方法，通过RAID file形式存储数据，可有效节省空间，但恢复时间较长，适用于冷备与日志数据。还详细阐述了数据生命周期管理策略，包括周期性删除、彻底删除、永久保留、极限存储、冷数据管理以及增量表merge全量表策略，并提出了通用的生命周期管理矩阵，以及数据成本量和数据使用费的概念，旨在优化数据存储治理，降低成本。

1. 数据压缩

在分布式文件系统中，为了提高数据的可用性与性能，通常会将数据存储3份，这就意味着存储1TB的逻辑数据，实际上会占用3TB的物理空间。目前MaxCompute中提供了archive压缩方法，它采用了具有更高压缩比的压缩算法，可以将数据保存为RAID file的形式，数据不再简单地保存为3份，而是使用盘古RAID file的默认值（6,3)格式的文件，即6份数据+3份校验块的方式，这样能够有效地将存储比约为1：3提高到1：l.5,大约能够省下一半的物理空间。当然，使用archive压缩方式也有一定的风险，如果某个数据块出现了损坏或者某台机器宕机损坏了，恢复数据块的时间将要比原来的方式更长，读的性能会有一定的损失。因此，目前一般将archive压缩方法应用在冷备数据与日志数据的压缩存储上。

例如，一些非常大的淘系日志数据，底层数据超过一定的时间期限后使用的频率非常低，但是又是属于不可恢复的重要数据，对于这部分数据就可以考虑对历史数据的分区进行archive压缩，使用RAID file来存储，以此来节省存储空间。示例如下：

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

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

2. 数据重分布

在MaxCompute中主要采用基于列存储的方式，由于每个表的数据分布不同，插入数据的顺序不一样，会导致压缩效果有很大的差异，因此通过修改表的数据重分布，避免列热点，将会节省一定的存储空间。目前我们主要通过修改distribute by和sort by字段的方法进行数据重分布，如图14.1所示。

重分布前后一些底层大表的效果对比如表14.2所示。

3. 存储治理项优化

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

存储治理项优化的主要流程如图14.2所示。

4. 数据生命周期管理

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

4.1. 生命周期管理策略

4.1.1. 周期性删除策略

所存储的数据都有一定的有效期，从数据创建开始到过时，可以周期性删除X天前的数据。例如对于MySQL业务库同步到MaxCompute的全量数据，或者ETL过程产生的结果数据，其中某些历史数据可能已经没有价值，且占用存储成本，那么针对无效的历史数据就可以进行定期清理。

4.1.2. 彻底删除策略

无用表数据或者ETL过程产生的临时数据，以及不需要保留的数据，可以进行及时删除，包括删除元数据。

4.1.3. 永久保留策略

重要且不可恢复的底层数据和应用数据需要永久保留。比如底层交易的增量数据，出于存储成本与数据价值平衡的考虑，需要永久保留，用于历史数据的恢复与核查。

4.1.4. 极限存储策略

极限存储可以超高压缩重复镜像数据，通过平台化配置手段实现透明访问；缺点是对数据质量要求非常高，配置与维护成本比较高，建议一个分区有超过5GB的镜像数据（如商品维表、用户维表）就使用极限存储。

4.1.5. 冷数据管理策略

冷数据管理是永久保留策略的扩展。永久保留的数据需要迁移到冷数据中心进行永久保存，同时将MaxCompute中对应的数据删除。一般将重要且不可恢复的、占用存储空间大于100TB,且访问频次较低的数据进行冷备，例如3年以上的日志数据。

4.1.6. 增量表merge全量表策略

对于某些特定的数据，极限存储在使用性与存储成本方面的优势不是很明显，需要改成增量同步与全量merge的方式，对于对应的delta增量表的保留策略，目前默认保留93天。例如，交易增量数据，使用订单创建日期或者订单结束日期作为分区，同时将未完结订单放在最大分区中，对于存储，一个订单在表里只保留一份；对于用户使用，通过分区条件就能查询某一段时间的数据。

4.2. 通用的生命周期管理矩阵

随着业务的发展和不断的数据实践，我们慢慢摸索出一套适合大数据生命周期管理的规范，主要通过对历史数据的等级划分与对表类型的划分生成相应的生命周期管理矩阵。

4.2.1. 历史数据等级划分

目前我们对历史数据进行了重要等级的划分，主要将历史数据划分为P0、P1、P2、P3四个等级，其具体定义如下。

1. P0:非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如交易、日志、集团KPI数据、IPO关联表。
2. P1:重要的业务数据和重要的应用数据，具有不可恢复性，如重要的业务产品数据。
3. P2:重要的业务数据和重要的应用数据，具有可恢复性，如交易线ETL产生的中间过程数据。
4. P3:不重要的业务数据和不重要的应用数据，具有可恢复性，如某些SNS产品报表。

4.2.2. 表类型划分

1. 事件型流水表（增量表）

事件型流水表（增量表）指数据无重复或者无主键数据，如日志。

1. 事件型镜像表（增量表)

事件型镜像表（增量表)指业务过程性数据，有主键，但是对于同样主键的属性会发生缓慢变化，如交易、订单状态与时间会根据业务发生变更。

1. 维表

维表包括维度与维度属性数据，如用户表、商品表。

1. Merge全量表

Merge全量表包括业务过程性数据或者维表数据。由于数据本身有新增的或者发生状态变更，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行Merge操作，主键对应的属性只会保留最新状态，历史状态保留在前一天分区中。例如，用户表、交易表等都可以进行Merge操作。

1. ETL临时表

ETL临时表是指ETL处理过程中产生的临时表数据，一般不建议保留，最多7天。

1. TT临时数据

TT拉取的数据和DbSync产生的临时数据最终会流转到ODS层，ODS层数据作为原始数据保留下来，从而使得TT&DbSync上游数据成为临时数据。这类数据不建议保留很长时间，生命周期默认设置为93天，可以根据实际情况适当减少保留天数。

1. 普通全量表

很多小业务数据或者产品数据，BI一般是直接全量拉取，这种方式效率快，对存储压力也不是很大，而且表保留很长时间，可以根据历史数据等级确定保留策略。

通过上述历史数据等级划分与表类型划分，生成相应的生命周期管理矩阵，如表14.3所示。

MaxCompute集群中海量数据的存储和大量计算任务每天都会消耗巨额成本，并且随着数据量的不断增长，这个成本还在逐步增加。如何在服务好业务的前提下，更好地管控数据成本，提升资源利用率，已成为数据资产管理工作中非常重要的一环。

在阿里巴巴集团内部，大部分数据都会存储在MaxCompute集群上，数据以数据表的形式存在，并且数据表之间存在比较复杂的关联和上下游依赖关系。可以把数据表之间的依赖关系用树形结构形象化地表示，如图14.3所示。图中的A、B、C等代表不同的数据表，带箭头的连线代表数据表之间的依赖和关联关系。比如数据表B、C、D都依赖数据表A,数据表E依赖数据表B和C。

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

4.3. 数据成本量

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

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

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

4.4. 数据使用费

在上一节中，已经清楚地将数据成本分为：存储成本、计算成本和扫描成本。那么对于数据表的使用计费，在阿里巴巴集团内部，分别依据这三部分成本进行收费，称为：计算付费、存储付费和扫描付费。

我们把数据资产的成本管理分为数据成本计量和数据使用计费两个步骤。通过成本计量，可以比较合理地评估出数据加工链路中的成本，从成本的角度反映出在数据加工链路中是否存在加工复杂、链路过长依赖不合理等问题，间接辅助数据模型优化，提升数据整合效率；通过数据使用计费，可以规范下游用户的数据使用方法，提升数据使用效率，从而为业务提供优质的数据服务。

博文参考

《阿里巴巴大数据实战》