2.存储优化

在分布式系统中，为了提高数据的可用性与性能，通常会将数据存储3份，这就意味着存储1TB的逻辑数据，实际上会占用3TB的物理空间。

数据压缩

• 阿里的大数据平台提供了archive压缩方法，可以将数据保存为RAID file的形式，数据不再简单地保存为3份，而是使用盘古 RAID file 的默认值（6，3）格式的文件，即 6份数据＋ 3份校验块的方式，这样能够有效地将存储比约1:3提高到1:1.5，大约能够节省一半的物理空间。
• 缺点：如果某个数据块出现了损坏或者某台机器宕机损坏了，恢复数据块的时间将要比原来的方式更长，读的性能会有一定的损失
• 应用场景：一般应用在冷备数据与日志数据的压缩存储上

数据重分布

• 背景：阿里的大数据平台主要采用基于列存储的方式，由于每个表的数据分布不同，插入数据的顺序不一样，会导致压缩效果有很大的差异
• 使用方法：distribute by + sort by
• 总结：数据重分布效果的波动较大，这主要跟数据表中字段的重复值、字段本身的大小、其他字段的具体分布有一定的关系

存储治理项优化

• 未管理表、 空表、最近 62 天未访问表、数据无更新无任务表 、数据无更新有任务表、开发库数据大于100GB且无访问表、长周期表等

生命周期管理

• 生命周期管理的根本目的就是用最少的存储成本来满足最大的业务需求，使数据价值最大化
• 生命周期管理策略：周期性删除：针对无效的历史数据可以定期清理彻底删除：无用表数据或者 ETL 过程产生的临时数据，以及不需要保留的数据，可以进行及时删除永久保留：重要且不可恢复的底层数据和应用数据需要永久保留极限存储：极限存储可以超高压缩重复镜像数据。缺点是对数据质量要求非常高，配置与维护成本比较高。建议一个分区有超过 5G 的镜像数据（如商品维表、用户维表）就使用极限存储。冷数据管理：冷数据管理是永久保留策略的扩展。永久保留的数据需要迁移到冷数据中心进行永久保存，同时将大数据平台中对应的数据删除。一般将重要且不可恢复的、占用存储空间大于 100TB，且访问频次较低的数据进行冷备，例如3年以上的日志数据。增量表merge全量表：对于某些特定的数据，极限存储在使用性与存储成本方面的优势不是很明显，需要改成增量同步与全量merge的方式
• 通用的生命周期管理矩阵：对历史数据的等级划分与对表类型的划分历史数据等级划分：P0：非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如交易、日志、集团 KPI 数据、 IPO 关联表。P1：重要的业务数据和重要的应用数据，具有不可恢复性，如重要的业务产品数据。P2：重要的业务数据和重要的应用数据，具有可恢复性，如交易线 ETL 产生的中间过程数据。P3：不重要的业务数据和不重要的应用数据，具有可恢复性，如某些 SNS 产品报表。表类型划分：事件型流水表（增量表）：数据无重复或者无主键数据，如日志事件型镜像表（增量表）：业务过程性数据，有主键，但是对于同样主键的属性会发生缓慢变化，如交易、订单状态与时间会根据业务发生变更。 维表：包括维度与维度属性数据，如用户表、商品表。merge全量表：包括业务过程性数据或者维表数据。由于数据本身有新增的或者发生状态变更的，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行 Merge 操作，主键对应的属性只会保留最新状态 ，历史状态保留在前一天分区中。例如，用户表、交易表等都可以进行 Merge 操作。merge全量表：包括业务过程性数据或者维表数据。由于ETL临时表：指 ETL 处理过程中产生的临时表数据，一般不建议保留，最多7天。TT临时表：TT拉取的数据最终会流向ODS层，ODS层数据作为原始数据保留下来，从而使得TT上游数据成为临时数据，不建议保留很长时间，生命周期默认设置为93天普通全量表：很多小业务数据或者产品数据， BI一般是直接全量拉取，这种方式效率快，对存储压力也不是很大，而且表保留很长时间，可以根据历史数据等级确定保留策略。生命周期管理矩阵如下：

数据成本计量

• 对数据成本的计量，可以采用最简单的方式，将一个数据表的成本分为存储成本和计算成本

暂时无法在飞书文档外展示此内容

• 上图是一条数据链路，表示A依赖B，B依赖C... 假设表B的成本可能是10元，但是表C和表D的成本可能是100元，那么如果表B的成本仅用自身的存储和计算成本衡量显然是不合理的
• 因此，在计量数据表的成本时，除考虑数据表本身的计算成本、存储成本外，还要考虑对上游数据表的扫描带来的扫描成本