大数据：存储和成本管理

• 数据存储和成本管理：

  • 有效的降低存储资源的消耗，节省存储成本，是存储管理孜孜追求的目标；
  • 一般从 4 个方面优化存储：数据压缩、数据重分布、存储治理项优化、生命周期管理；

一、数据压缩

• 实际中的数据存储情况：在其它分布式计算系统中，为了提高数据的可用性和性能，通常会将数据存储 3 份；这就意味着存储 1 TB 的逻辑数据，实际上占用了 3 TB的物理空间；

• MaxCompute 提供了 archive 压缩法：

  • 采用了更高效压缩比的压缩算法，可以将数据保存为 RAID file 的形式，数据不再是简单的 3 份，而是使用盘古 RAID file 的默认值（6, 3）格式的文件，即 “6 份数据 + 3 份校验块” 的方式；将存储比约为 1:3 提升到 1:1.5，大约能够节省一半的物理空间；

  • archive 压缩法存在的风险：

    • 如果数据损坏，恢复数据的时间更长；而且读的性能会有一定损失；
    • 如果某个数据块出现了损坏或者某台机器宕机（dang 机，down 机，死机的意思）损坏了，恢复数据块的时间将要比原来的方式更长；

  • archive 压缩法的使用：

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

        • archive table A partition(ds = '20200101') archive;

      • 输出信息如下表：
        • 
      • 从输出信息可以看到， archive 的前后的逻辑存储（File size）和物理存储（File physical size）的变化情况，在这个过程中有将多个小文件自动合并；

二、数据重分布

• 背景 / 数据压缩过程中的问题：

  • 在 MaxCompute 中主要采用基于列存储的方式，由于每个表的数据分布不同，插入数据的顺序不一样，会导致压缩效果有很大的差异；
    • 数据分布情况主要跟重复值、字段本身的大小、其它字段的具体分布；

• 解决思路：

  • 通过修改表的数据重分布，避免列热点，进而改善压缩效果，节省一定的存储空间；
    • 思考：为什么热点列会影响数据的压缩？（应该跟压缩算法和压缩后的数据的格式有关）

• 数据重分布的方法：

  • 主要通过修改 distribute by 和 sort by 字段的方法进行数据重分布；
  • 

• 哪些数据需要重分布：

  • 数据重分布的效果：主要跟数据表中的重复值、字段本身的大小、其它字段的具体分布有一定的关系；
  • 一般会筛选出重分布效果低于 15% 的表进行优化处理；
    • 重分布效果：数据重分布后节约的空间比例；
    • 重分布后，一些底层大表的效果对比：
      • 

  

三、存储治理项优化

• 阿里内部的大数据优化方法：

  1. 存储治理优化项

     • 在元数据的基础上，诊断、加工成多个存储治理优化项；
     • 目前已有的存储治理优化项：
       • 未管理表、空表、最近 62 天未访问表、数据无更新无任务表、数据无更新有任务表、开发库数据大于 100 GB 且无访问表、长周期表等；

  2. 治理项

     • 通过对优化项的数据诊断，形成治理项；
       • 治理项通过流程的方式进行运转、管理，最终推动各个 ETL 开发人员进行操作，优化存储管理，并及时回收优化的存储效果（也就是回收节省出的内存）；

• 存储治理项优化的闭环：

  • 通过上述的存储治理优化体系，形成现状分析、问题诊断、管理优化、效果反馈的存储治理项优化的闭环；（如下图）
  • 通过这个闭环，可以有效的推进数据存储的优化，降低存储管理的成本；

• 

四、生命周期管理

• 从数据价值及数据时间实用性方面综合考虑，数据的生命周期管理是存储管理的一项重要手段；

• 数据生命周期管理的根本目的：用最少的存储成本满足最大的业务需求，使数据价值最大化；

1、生命周期管理策略

　1/1）周期性删除策略

• 所存储的数据有一定的有效期，从数据创建到过时，可以周期性删除 N 天前的数据；
  • 如，MySQL 业务库同步到 MaxCompute 的全量数据、ETL 过程产生的结构数据，其中某些数据可能已经没有价值，且占用存储成本，那么针对无效的历史数据可以定期清理；

　1/2）彻底删除策略

• 无用表数据、 ETL 过程产生的临时数据、不需要保留的数据，要及时删除，包括删除元数据；

　1/3）永久保留数据

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

　1/4）极限存储策略

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

　1/5）冷数据管理策略

• 冷数据管理策略是永久保留策略的扩展；

• 永久保留的数据需要迁移到冷数据中心进行永久保存，同时将 MaxCompute 中对应的数据删除；

• 冷数据：重要且不可恢复的、占用存储空间大于 100 TB，且访问频次较低的数据；
  • 如，3 年以上的日志数据；

　1/6）增量表、 merge 全量表策略

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

2、通用的生命周期管矩阵

• 阿里的生命周期管理规范：

  • 通过对历史数据的等级划分与对表类型的划分生成相应的生命周期管理矩阵；
    • 生命周期管理矩阵：将具体的规则整体汇集成的一种表格；

　2/1）历史数据等级划分

• 根据历史数据的重要程度，一共划分了 P0、P1、P2、P3 四个等级：
  1. P0：非常重要的主题数据域数据和非常重要的应用数据；具有不可恢复性；
     • 如，交易、日志、集团 KPI 数据、IPO 关联表；
  2. P1：重要的业务数据和重要的应用数据；具有不可恢复性；
     • 如，重要的业务产品数据；
  3. P2：重要的业务数据和重要的应用数据；具有可恢复性；
     • 如，交易线 ETL 产生的中间过程数据；
  4. P3：不重要的业务数据和不重要的应用数据，具有可恢复性；
     • 如，某些 SNS 产品报表；

　2/2）表类型划分

1. 事件型流水表（增量表）
   • 事件型流水表：指数据无重复或者无主键数据；（如，日志）
2. 事件型镜像表（增量表）
   • 事件型镜像表：指业务过程性数据，有主键，但是对于同样主键的属性会发生缓慢变化；
     • 如，交易、订单状态与时间会根据业务发生变更；
3. 维表
   • 维表：包括维度和维度属性数据；
     • 如，用户表、商品表；
4. Merge 全量表
   • Merge 全量表：包括业务过程性数据或者维表数据；
     • 由于数据本身有新增的或者发生状态变更，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行 Merge 操作，主键对应的属性只会保留最新状态，历史状态保留在前一天分区中；
     • 如，用户表、交易表等都可以进行 Merge 操作；
5. ETL 临时表
   • ETL 临时表指 ETL 处理过程中产生的临时数据，一般不建议保留，最多 7 天；
6. TT 临时数据
   • TT 临时数据：TT 拉取的数据和 DbSync 产生的临时数据最终会流转到 ODS 层，ODS 层数据作为原始数据保留下来，从而使得 TT& DBSync 上游数据成为临时数据；
     • 这类数据不建议保留很长时间，生命周期默认设置为 93 天，可以根据实际情况适当减少保留天数；
7. 普通全量表
   • 很多小业务数据或者产品数据，BI 一般是直接全量拉取，这种方式效率快，对存储压力也不是很大，而且表保留很长时间，可以根据历史数据等级确定保留策略；

　2/3）生命周期管理矩阵

• 根据历史数据等级划分和表类型划分，生成相应的生命周期管理矩阵，如下表：

  • 
  • 

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

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

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

五、数据成本计算

• 数据成本计算主要是计算数据表的存储成本、计算成本、扫描成本：

  • 存储成本是为了计算数据表消耗的存储资源；
  • 计算成本是为了计算数据计算过程中的 CPU 消耗；
  • 扫描成本是指对上游数据表的扫描带来的扫描成本；

• 对上游数据表扫描：

  • 例：如下图：
    • 表 D 是业务方的一个数据表，表 D 依赖表 C，但是为了产生表 C，往往上面存在一个较长的数据刷新链路；表 C 的成本可能是 10 元，但是表 A、B 可能会是 100 元；像这样的情况，如果表 C 的成本仅仅用数据表 C 自身的存储和计算成本衡量是不合理、不准确的；（因为确定表 C 的时候，必须扫描表 B 才能确认）
    • 

• 通过在数据成本计算中引入扫描成本的概念：

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

六、数据使用计费

• 数据表的使用计费：

  • 分别依据数据的存储、计算、扫描三部分成本进行收费，称为：计算付费、存储付费、扫描付费；

• 数据资产的成本管理：数据成本计算、数据使用计费；

  • 数据成本计算，可以比较合理的评估出数据加工链路中的成本，从成本的角度反映出在数据加工链路中是否存在加工复杂、链路过长、依赖不合理等问题，间接辅助数据模型优化，提升数据整合效率；
  • 数据使用计费，可以规范下游用户的数据使用方法，提升数据使用效率，从而为业务提升优质的数据服务；