数据中心是成本中心，要在有限资源内，最大化的完成精细化运营的决策支撑任务，所以会尽可能地完成业务方的合理需求； 与此同时，也会受到整体技术产研的“资源帽”的要求，要不断的节省成本。

成本分为人员成本和集群成本，人员成本可估算为60-80万（人民币一年）； 集群成本可按一个<core+Memory>对来描述，和公司采买机器的偏好有关（memory: core 越高说明是内存计算型的任务更高）一般这个比例是在4:1 到2:1之间。

成本花在什么地方了？
在建设数据中台的过程中，数据仓库的建设、日常数据挖掘与分析、数据产品开发，都是由数据团队的人+机器完成的。 在开心过程中，要小心一些成本陷阱。

提防成本陷阱

能够监测到每个报表的使用情况

  • 制定数据下线规则

其实，以我的过往经验来看，数据团队产生的数据报表有一多半是30天内无人查看的，三成以上是近90天无人查看的。

这个原因也很好理解，核心报表（与业务方的日报、周报、月报有关）是业务方每天关注的，但更多的生产报表有它的历史任务，过了那段业务高峰，业务方就会转移到新注意力；

随着时间的积累，就导致这些历史报表的地位变得很难受。

  • 衡量一张表的投入产出比

    还是那句话，对于成本优化来说，如果不能给出量化的策略，就难以优化。
    在数据仓库任务中，每张表的加工成本可以根据集群使用情况用金额评定；

    但难点是一张表的收益如何量化呢？

    • 烟囱式开发

即数据重复加工，团队里每个人各自开发了若干个数据烟囱，没有复用，造成资源的巨大浪费。

  • 数据倾斜

数据开发优化，应在开发流程上加以优化，避免不合理任务的上线。

  • 数据存储

对数据管理来说，应对每张表设置存储策略，引入定期删除机制，降低存储。

同时还应对远期表引入冷热表分离和压缩机制，进一步降低存储成本。

  • 调度周期

（图片来自 极客时间-《数据中台实战课》）

在我之前接触的团队，数据调度也是类似的，从凌晨开始，持续到上午的6点或8点，完成当天ETL任务， 在白天则基本上服务于一些ad-hoc即席查询，集群的使用率不到四分之一。

因为一般情况，业务方会默认的以为每天上班后看到的数据就是当天准确的，所以很难再和业务同事商量下午2点再看数据，这不现实。

精细化成本管理

—— 核心工作在于数据资产门录的建设。

早期数据仓库是开发开发，上线上线，修bug维护等一系列工作下来，在这个阶段是没有成本意识的，更不会量化一张数仓表到底投入了多少总成本。


（图片来自 极客时间-《数据中台实战课》）

一张数仓报表的财务分析示例，
依赖成本：在这个图中 表A 依赖上游的六个表、三个开发任务 = 开发任务各自的执行成本 ，存储成本是6个报表的存储成本。
开发成本：自身生产任务的执行成本，按CU占用时间评估执行成本； 存储成本，按该表存储占用一年来估算一年的成本；

数据价值如何体现？

再有价值的数据，如果只有开发人员关注，而无业务人员问津，也是不对的。

末端数据应用分类：

  • 应用层表（对接展示类或者特定业务场景应用），使用范围（谁在使用）+使用频率（使用强度）；
  • 轻度汇总或集市层（用于探索分析），使用范围（谁在使用）+使用频率（使用强度）；

一开始，并不一定需要对每个报表，每个数仓中间层表都准确维护。
但数据资产盘点工作应至少把数据的使用分为三类：

  • 第一类：持续占用成本资源，无人过问。
  • 第二类，ROI不匹配的数据报表，高投入低产出
  • 第三类，高成本数据，以一个参考线往上

前两类对应的是下线报表策略。

数据下线策略

这里要注意的是，下线策略并不是突然间将报表从任务调度停止，删除历史数据，这样的一刀切太过危险。
应使用温和的下线策略：

    1. 在数据地图上标识这个表的状态为下线观察期（7-30天），如果有用户反应还会使用，则根据使用情况进行调整 （放弃下线，或者引导用户使用其他表）；
    1. 观察期过后，更新状态为已下线——停止生产，新数据不再写入；
    1. 如果集群分为主集群和备用集群，则将数据移到冷备集群，一般来说冷备集群不负责数据密集型计算，主要以备份和数据存储为主。
    1. 再经历过一段时间，还无人反馈，则数据删除，更新数据字典状态。

数据存储策略

数据存储周期设置

  • 永久级
  • 非永久级，
    • 短期， 只保留最近7天分区
    • 中期， 保留最近30天分区
    • 长期，保留最近180天， 一年分区

衡量数据成本治理的方式

开发维度同样的任务，是否可以节省更多的机器资源。