上一篇中，我们介绍了元数据中心的搭建以及它一项应用——指标字典与指标体系。接下来，我们依次介绍元数据中心的其他模块：数据模型、数据质量和成本管控。

数据模型设计

在数据中台的场景中，如果我们把指标比喻成一棵树上的果实，那么数据模型（Data Model，也称为数据集）就是这棵大树的主干。想让果实结得好，就必须让树干变得粗壮。

在这里，我们先区分业务系统中的数据模型和数仓中的数据模型的不同（如下表）。

数据中台的数据模型来源于整合后数仓的数据模型。关于数仓数据模型设计的方法论（概念模型设计、逻辑模型设计、物理模型设计）你可以在任何一本数仓建模中找到，在这里不进行讲述。此部分，我们需要重点关注的是如何诊断当前数仓中数据模型的问题、定位主要原因，以及如何搭建数据中台可复用的数据模型。

在真实的场景中，分析师会结合业务做一些数据分析，通过输出报表的方式服务于业务部门的运营与决策。

在数据中台构建之前，分析师经常发现自己没有可以复用的数据集，不得不使用原始数据依次进行数据的清洗、加工、计算指标。由于业务部门的分析师大多是非技术出身，写的SQL可能比较差，多层嵌套对后台的计算和调度资源消耗非常大，造成队列阻塞，影响其他数仓任务，导致开发不满。开发可能会取消分析师的原始数据读取权限，如果想取数，需要单独和开发沟通，那么这会严重影响分析师的工作效率，分析师会抱怨开发提供的数据不完善、速度慢，一个需求经常要等一周甚至半个月，由此，分析师与开发的矛盾愈演愈烈。

以上的场景矛盾的根源在于数据模型无法复用。数据开发是烟囱式的，每次遇到新的需求，都从原始数据重新计算，非常耗时且浪费资源。

一个“好”的数据模型

许多公司已普遍存在大量的数据模型，在设计之初，我们首先要对当前的数据模型进行诊断。

下面的两张表是基于元数据中心提供的血缘信息，分别统计大数据平台上正在运行任务和即席查询。

即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。

回忆背景篇中关于数仓的分层设计，我们知道当前主流数仓分成以下4个层级：

• ODS：操作数据层（Operational Data Store）。在结构上其与源系统的增量或者全量数据基本保持一致。它相当于一个数据准备区，同时又承担着基础数据的记录以及历史变化。原始数据经过缓冲层（STG）的加载，会进入数仓的业务数据层，这一层采用范式建模，基本保持与数据源完全一致的结构，对于变化的数据，使用数据拉链加工与存储。
• CDM：公共数据层（包括公共明细层 DWD，Data Warehouse Detail；公共汇总层 DWS，Data Warehouse Summary）。它的主要作用是完成数据加工与整合、建立一致性的维度、构建可复用的面向分析和统计的明细事实表以及汇总公共粒度的指标。公共数据层是数据仓库的核心层，是整个数仓中使用率最高的，这一层主要采用的维度建模思路进行设计，类型包括事务事实、周期快照、累积快照。同时为了方便下游对数据的使用，一般会设计一系列的宽表模型，将不同业务过程中的事实进行统一整合。
• ADS：应用数据层（Application Data Service）偏向应用的数据加工，也称数据集市层，这一层的设计可以相对灵活，贴近应用即可，总体设计思想仍然可以按维度建模思想为主。

回到上面的统计数据。

• 表1 中有2547张未识别分层的表，占总表6049的 40%，它们基本没办法复用。在已识别分层的读表任务中，ODS : DWD : DWS : ADS的读取任务分别是1072 : 545 : 187 : 433，直接读取ODS层任务占这四层任务总和的47.9%，这说明有大量任务都是基于原始数据加工，中间模型复用性很差。
• 在已识别的分层的查询中，表2 ODS : DWD : DWS : ADS的命中查询分别是892 : 1008 : 152 : 305，有37.8%的查询直接命中ODS层原始数据，说明 DWD、DWS、ADS 层数据建设缺失严重。尤其是ADS和DWS，查询越底层的表，就会导致查询扫描的数据量会越大，查询时间会越长，查询的资源消耗也越大，使用数据的人满意度会降低。
• 进一步对ODS层被读取的704张表进行分解，发现有382张表的下游产出是DWS，ADS，尤其是ADS达到了323张表，占ODS 层表的比例45.8%，说明有大量ODS层表被进行物理深加工。

通过上面的分析，我们似乎已经找到了理想数据模型设计具备的要素：可复用、够完善、守规范。

那么，如何具体地度量这三个要素呢？

复用度

数据中台数据模型设计的核心是实现模型的复用与共享。通过元数据中心的数据血缘图，可以看到，一个比较差的模型设计，自下而上是一条线。而一个理想的数据模型设计，它应该是交织的发散型结构。

复用度可用模型引用系数衡量：引用系数越高，数据模型的复用性越好。

模型引用系数=被读取模型直接产出下游模型的数量

• 比如一张DWD层表被5张 DWS 层表引用，这张DWD层表的引用系数就是 5，如果把所有DWD层表（有下游表的）引用系数取平均值，则为DWD层表平均模型引用系数；从经验上看，一般低于2比较差，3以上相对比较好。

一种提升数据模型复用度且提升响应速度的策略，是在数据源和数据使用之间增加缓存层。缓存层中存放复用度较高的数据模型，以及这些数据模型所携带的数据。分析师或业务人员根据需求查询数据时，如果是常用的数据模型，便不必再进行从源数据中取数、清洗、拼接等重复动作，从缓存中直接导入数据模型即可，大大提升复用数据模型的前端响应速度。

完善度

衡量DWD层是否完善，需要确认ODS层有多少表被 DWS/ADS/DM 层引用。如果DWD以上的层引用的越多，就说明更多的任务是基于原始数据进行深度聚合计算的，明细数据没有积累，无法被复用，数据清洗、标准化、集成存在重复开发。因此，可以用跨层引用率指标衡量DWD的完善度。

跨层引用率=ODS层直接被DWS,ADS,DM层引用的表数量/所有活跃的ODS层表。

跨层引用率越低越好，因为在数据中台模型设计规范中，不允许出现跨层引用，ODS 层数据只能被DWD引用。

针对DWS/ADS/DM层完善度，主要看汇总数据能直接满足多少查询需求（也就是用汇总层数据的查询比例衡量）。如果汇总数据无法满足需求，使用数据的人就必须使用明细数据，甚至是原始数据。

汇总数据查询比例=DWS/ADS/DM层的有效查询/所有有效查询。

汇总数据查询比例越高，说明上层的数据建设越完善，对于使用数据的人来说，查询速度变快、性能提升。

规范度

规范度其实没有特别明确的量化指标，主要根据数据表命名或归属主题域是否正确等情景，进行定性判断。例如，在表1中，有超过40%的表都没有分层信息，在数据模型设计中，这显然是不规范的。除了确定表有没有分层，还要看它有没有归属到正确的主题域（例如交易域）。如果没有归属主题域，就很难找到这张表，也无法复用。

其次，我们需要看表的命名。一个规范的表命名应该包括主题域、分层、表是全量快照，还是增量等信息。除此之外，如果在表A中用户ID的命名是UserID，在表B中用户ID命名是ID，就会对使用者造成困扰，这到底是不是一个表。因此，我们要求相同的字段在不同的模型中，它的命名必须是一致的。

我们进行一个简短的总结：

要想得到一个“好”的数据模型，首先，我们可以统计未规范表的数量（可仿照表1），诊断数据模型现状。然后，制订一些针对性的改进计划，例如把这些不规范命名的表消灭掉，把主题域覆盖的表比例提高到90%以上。在进行一段时间的模型重构和优化后，再拿着这些指标去评估是否有所改善。

很多数据开发在向上级汇报工作时，喜欢用重构了多少模型说明工作成果，很多老板会想，这些重构到底对数据建设有多少帮助？有没有一些量化的指标可以衡量？因此，我们需要着重考虑是否真的改善了？以及如何证明真的改善了，而不是强调优化了多少模型。

假设当前我们已经对数仓中的数据模型做好评估和改进了，那么，我们需要怎么做才能让它变成一个数据中台呢？

从小数仓到数据中台

建设数据中台本质就是构建企业的公共数据层，把原先分散的、烟囱式的、杂乱的小数仓，合并成一个可共享、可复用的数据中台。以下是几点策略：

首先，接管ODS层，控制数据源头。ODS是业务数据进入数据中台的第一站，是所有数据加工的源头，控制住源头，才能从根本上防止一个重复的数据体系的出现。因此，数据中台团队必须全面接管ODS层数据，可以从业务系统的源数据库权限入手，确保数据从业务系统产生后进入数据仓库时，只能在数据中台保持一份。

此外，把控ODS层表的数据必须和数据源的表结构、表记录数一致，高度无损，对于ODS层表可采用 ODS_业务系统数据库名_业务系统数据库表名 的方式命名。

然后，划分主题域和拆分业务维度，构建总线矩阵。主题域是业务过程的抽象集合。例如，库存的仓储管理过程有入库、存放、出库、配送、签收等，这些都是业务过程，抽象出来的主题域就是仓储域。每个企业有多个业务过程，划分要尽量涵盖所有业务需求，保持相对稳定性，还具备一定的扩展性（新加入一个主题域，不影响已经划分的主题域的表）。

待主题域划分好后，就要开始构建总线矩阵，需要明确每个主题域下的业务过程有哪些可拆分的维度（如图）。

接下来，构建一致性维度。例如，售后团队的投诉工单数量有针对地区的维度，而配送团队的配送延迟也有针对地区的维度。当拆分因为配送延迟导致的投诉增加，但是两个地区的维度包含内容不一致，最终会导致一些地区没办法分析。因此，我们需要构建全局一致性的维表，确保维表只存一份。维度统一的最大的难点在于维度属性（如果维度是商品，那么商品类别、商品品牌、商品尺寸等商品的属性，称为维度属性）的整合。

那么，是不是所有维度属性都要整合到一个大的维表中？具体情况需要具体分析：

• 公共维度属性与特有维度属性拆成两个维表。例如，在电商自营平台中，通常也会有一些第三方的商家入驻，但是数量很少。大部分商品其实都没有店铺的属性。面对这种情况，就不建议将店铺和商品的其他维度属性，比如商品类别、品牌设计成一个维表。
• 产出时间相差较大的维度属性拆分成单独的维表。比如有些维度属性产出时间在凌晨2点，有些维度属性产出时间在早晨6点，那凌晨2点和早晨6点就可以拆成两个维表，确保核心维表尽早产出。

除此以外，更新频繁的和变化缓慢，访问频繁的和访问较少等不同情景，都可需要将维表拆分。

对于维表的规范化命名，建议用 DIM_主题域_描述_分表规则 方式。其中，分表规则：例如，一个表存储几千亿行的记录实在是太大了，所以需要把一个表切割成很多小的分区，每天或者每周，随着任务被调度，会生成一个分区。常见的分表策略如下：

紧接着，事实表整合。事实表整合的核心是统计粒度必须保持一致，不同统计粒度的数据不能出现在同一个事实表中。

例如，在数据中台构建前，供应链部门、仓储部门和市场部门都有一些重复的事实表，一方面，我们需要将这些重复的内容进行去除，另一方面，按照交易域和仓储域等主题域的方式整合。

• 对于仓储部门和供应链部门都存在的库存明细表，由于仓储部门的统计粒度是商品加库存，而供应链部门的只有商品，原则上两个表是不能合并，而是应该独立存在。

• 而对于市场部门和供应链部门的两张下单明细表，因为统计粒度都是订单级别，都归属于交易域下的下单业务过程，因此，可以合并为一张事实表。

除此之外，还应该考虑将不全的数据补齐。对于ODS层直接被引用产出 DWS/ADS/DM层的任务，通过血缘，找到任务清单，逐个进行拆解。没有ODS 对应的 DWD 的，应该生成DWD表，对于已经存在的，应该迁移任务，使用 DWD 层表。DWD/DWS/ADS/DM的命名规则适合采用 层次_主题_子主题_内容描述_分表规则 的命名方式。

接下来，模型开发。模型设计完成后，进入模型开发阶段，此阶段应该注意：

• 所有任务都必须严格配置任务依赖，如果没有配置任务依赖，会导致前一个任务没有正常产出数据的情况下，后一个任务被调度起来，导致数据空跑，浪费资源，同时增加排查故障的复杂度。
• 任务中创建的临时表，在任务结束前应该删除，如果不删除，会发现有大量的临时表存在，占用空间；
• 任务名称与跟表名一致，方便查找和关联；
• 对数据实现生命周期的管理。对于ODS和DWD，一般尽可能保留所有历史数据，对于DWS/ADS/DM需要设置生命周期，可以保留7-30天不等。

最后，应用迁移。这个过程的核心是要注意数据的比对，确保数据的完全一致，然后进行应用迁移，删除旧的数据表。

综上，我们可以初步实现小数仓数据模型的整合，从而搭建数据中台的数据模型。

总之，建设数据中台不是一蹴而就的，它的建设往往是滚雪球的方式，随着一个个应用的迁移，中台的数据也越来越多，发挥的价值越来越大。

从数据模型的设计层面，我们逐步将分散、杂乱、烟囱式的小数仓整合成了可复用、可共享的数据中台。那么，只要交付数据足够快，用户就会满意吗？答案肯定不是的，速度快只是其中一个方面，而另一方面是保证数据质量，这也是评估数据中台建设最重要的维度之一。

数据质量诊断

首先，我们需要对当前数据或报表做数据质量诊断。

数据的质量可以从八个维度衡量，分别是：准确性（Accuracy）、精确性（Precision）、真实性（Rightness）、完整性（Completeness）、全面性（comprehensiveness）、及时性(Timeliness)、即时性（Immediacy）和关联性（Relevance）。

通过以上标准，可以设计数据质量矩阵针对性打分，从而初步诊断数据质量。

接下来，我们需要明确出现数据质量问题和主要原因。

数据质量的问题与主要原因

在数据中台的实际场景中，常常会遇到一下问题：

• 数据部门晚于业务方发现数据异常，被投诉后才发现问题。
• 出现问题后，数据部门无法快速定位到数据异常的根源，排查用了很长的时间。
• 故障出现在数据加工链路的上游顶端，出现问题没有第一时间报警处理，导致问题修复时，所有下游链路上的任务都要运行，修复时间成本非常高。
• 这些常见的问题最终导致了数据质量较差，业务方对数据信任度大打折扣。

导以上异常事件的原因其实非常复杂，散落到各个领域和流程中（如图）。

在这里，我们重点关注常见且重要的原因，如下：

• 业务源系统变更
• 数据开发BUG
• 物理资源不足

业务源系统变更

数据中台的数据一般最初来源于业务系统，而源系统变更一般会引发3类异常情况：

• 源系统数据库表结构变更。例如，业务系统新版本发布上线，对数据库进行了表结构变更，增加了一个字段，同时对部分字段的类型、默认值等进行了调整。这种表结构变更没有通知到数据团队，导致数据同步任务或者数据清洗任务异常，进而影响了下游数据产出。
• 源系统环境变更。典型的是前端用户行为埋点日志量暴增，系统管理员紧急对服务器进行扩容，上线了5台新的服务器，但是没有配置这5台服务器的日志同步任务，结果导致数据侧少了这5台服务器数据，最终影响了数据计算结果的准确性。
• 源系统日志数据格式异常。这种情况通常出现在前后端埋点日志中。业务系统发布上线引入埋点BUG，导致IP格式出现了不符合约定的格式，最终也会导致计算结果错误。

数据开发BUG

这种情况在数据质量事件中占到了60%以上，而它大多数是由于数据开发的疏忽造成的，以下是具体的场景：

• 任务发布上线，代码中引用的测试库没有修改为线上库，结果污染了线上数据；
• 任务发布上线，代码中使用了固定分区，导致数据异常；
• 数据格式处理错误，代码忽略了异常，导致数据错误；
• 任务配置异常，通常表现为任务没有配置依赖，前一个任务没有运行完，后一个任务就开始运行，输入数据不完整，导致下游数据产出错误。

物理资源不足

这种情况发生的原因也是比较复杂，常见场景可能是：

• 业务暴增（比如双11、618）导致数据量增加，平时1小时后能跑完的数据可能得2小时，需要消耗更多的资源。
• 新上线的调度任务，写的SQL极其低效，从而占据大量的资源。

因为在多租户下，Hadoop 生态的大数据任务（MR，Hive，Spark）一般运行在 yarn管理的多个队列上（调度器为CapacityScheduluer），每个队列都是分配了一定大小的计算资源（CPU、内存），因此在有限的资源下就会出现抢资源的情况。

待明确问题的主要原因后，我们需要提出具体的优化策略。在此之前，需要明确一个原则：早发现、早恢复。

• 早发现：能够先于数据使用方发现数据的问题，尽可能在出现问题的源头发现问题。
• 早恢复：要缩短故障恢复的时间，降低故障对数据产出的影响。

那么，如何做到这两个早呢？ 以下是几点策略：

添加稽核校验任务

稽核校验任务本质上就是，通过预先设置好的一些规则来验证当前调度任务执行结果表的质量，如果触发规则就自动发送预警给到相关的开发人员。

在数据加工任务中，对产出表按照业务规则，设计一些校验逻辑，确保数据的完整性、一致性和准确性，这是提升数据质量最行之有效的方法。通常在数据产出任务运行结束后，启动稽核校验任务对数据结果进行扫描计算，判断是否符合规则预期，如果不符合，就根据提前设定的强弱规则，触发不同的处理流程：

• 如果是强规则，就立即终止任务加工链路，后续的任务不会执行，并且立即发出电话报警，直到故障被认领；
• 如果是弱规则，任务会继续执行。但是存在风险，这些风险会通过邮件或者短信的方式，通知到数据开发，由人来进一步判断风险严重程度。

强规则还是弱规则的设定，取决于业务对上述异常的容忍度。例如，涉及到交易、支付跟钱相关的，一般都会设置为强规则，对于一些偏行为分析的，一般都是弱规则。

具体的稽核规则如下：

• 完整性规则。主要目的是确保数据记录是完整的、不丢失。常见的稽核规则有表数据量的绝对值监控和波动率的监控（例如，表数据量波动超过 20%，就认为是异常）。还有主键唯一性的监控，它是判断数据是否有重复记录的监控规则。除了表级别的监控，还有字段级别的监控（比如字段为0、为NULL的记录）。
• 一致性规则。主要解决相关数据在不同数据模型中一致性的问题。例如，商品购买率是通过商品购买用户数除以商品访问UV计算而来的。如果在不同的模型中，商品购买用户数是1W、商品访问UV为10W，商品购买率20%。那么，这三个指标就存在不一致。
• 准确性规则。主要解决数据记录正确性的问题。常见的稽核规则有，一个商品只能归属在一个类目，数据格式是不是正确的IP格式，订单的下单日期是还没有发生的日期等。

建立全链路监控

分层设计的数据模型会导致数据加工的链路变长，加工链路的依赖关系变得复杂。当下游表上的某个指标出现问题，排查定位问题的时间都会比较长。因此，需要基于数据血缘关系，建立全链路数据质量监控。

建立智能预警功能

通过分析过去任务运行的时间以及任务需要输出的时间节点，基于当前物理资源的情况，自动判断当前调度任务是否可以在规定的时间节点前完成计算，一旦发现指标无法按时产出，则立即报警，数据开发可以终止一些低优先级的任务，确保核心任务按时产出。

规范化管理制度

提升数据质量，这不仅仅是一个技术问题，也涉及管理。如果涉及业务层面，需要由数据架构师或数据产品经理牵头，按照主题域、业务过程，对每个表的规则进行评审，决定这些规则是否能够完全覆盖数据质量异常场景，确保规则的完备性。

当按照以上方法确立数据质量体系后，我们需要一些具体的量化指标来评估体系有效性。

数据质量评估指标

除了之前提到的数据质量综合评估的八个标准外，还需要如下具体的指标，例如：

• 故障次数。数据开发或应用过程中，系统出现问题的次数。除记录故障次数外，还需记录发生故障的时间、任务、负责人等相关信息。
• 产出完成率。例如，每日16点前数据中台任务产出完成率。如果任务异常，任务延迟，强稽核规则失败，都会导致任务无法在规定时间前产出。
• 表质量分数。根据表上稽核规则，为每个表进行质量打分，对于分数低的表，表负责人要承担改进责任。
• 数据产品SLA。SLA（Service-Level Agreement）服务等级协议，指的是系统服务提供者对客户的一个服务承诺。这是衡量一个大型分布式系统是否健康的常见方法。常见的4个SLA指标：

可用性（Availability），指的是系统服务能正常运行所占的时间百分比。对于许多系统而言，四个9的可用性——99.99% Availability，即可以被认为是高可用性。其中99.9% Availability 指的是一天当中系统服务可能会有大约86秒的服务间断期。间断原因也许是系统维护或升级。
准确性（Accuracy），指的是所设计的系统服务中，是否允许某些数据是不准确的或丢失的。如果允许这样的情况发生，用户可以接受的概率（百分比）是多少？很多时候，系统架构以错误率（Error Rate）来定义——用导致系统产生内部错误（Internal Error）的有效请求数，除以这期间的有效请求总数。例如，我们在一分钟内发送100个有效请求到系统中，其中有5个请求导致系统返回内部错误，那我们可以说这一分钟系统的错误率是5/100=5%。
系统容量（Capacity）。在数据处理中，系统容量通常指的是系统能够支持的预期负载量量，一般会以每秒的请求数为单位来表示。例如，某个系统的架构可以处理的QPS（Queries Per Second）是多少又或者RPS（Requests Per Second）是多少？这里的QPS或者是RPS就是指系统每秒可以响应多少请求数。
延迟（Latency），指的是系统在收到用户的请求到响应这个请求之间的时间间隔。例如，系统的SLA会有p95或者是p99这样的延迟声明。这里的p指的是percentile（百分位）。如果说一个系统的p95延迟是1秒的话，那就表示在100个请求里面有95个请求的响应时间会少于1秒，而剩下的5个请求响应时间会大于1秒。

在建设数据中台的过程中，我们通常会关注新业务的接入、数据产品的上线、历史数据梳理整合、数据价值挖掘，但我们往往忽视其较为隐性的目标——成本控制。无论是建设还是维护数据中台，需要大笔资金投入，成本不断增长，总是超过资金预算。如何确保目标达成且有效控制成本？这成为数据中台管理者的难题。

数据中台的成本管控

首先，我们需要明确成本增长的主要原因：

第一，数据（报表）上线容易下线难。这是某数据中台报表使用情况统计。

根据统计数据，有个重要的发现：有一半的表在30天内都没有访问，而这些表占用了26%的存储空间。如果我们把这些表的产出任务单独拿出来，在高峰期预估消耗5000Core CPU的计算资源，换算成服务器需要125台（按照一台服务器可分配40Core CPU计算），折合成本一年接近500万。由此，我们突然醒悟，竟然有这么多没有用的数据？！

对于这些无法及时清理或下线的报表，数据开发并不知道一个表有哪些任务在引用，有哪些人在查询。因此，开发不敢也不能直接停止这个表的数据加工。此时，需要数据产品经理或运维人员进行梳理和统计，提供报表使用情况的说明，针对“无人问津”的报表，进行下线处理。

第二，烟囱式开发。通过之前的介绍，我们知道烟囱式的开发不仅会带来研发效率低的问题，而且由于数据重复加工，存在大量的资源浪费。假设我们有一张500T的表，加工这张表，计算任务需要高峰期消耗300Core，折合7台服务器（按照一台服务器可分配 CPU 40Core计算），再加上存储盘的成本 (按照0.7元/TB天计算)，一年需要消耗40万。而这张表每复用一次，就可以节省40W的成本。因此，通过之前的模型复用策略，还可以实现省钱的目的。

第三，调度周期不合理。从图中我们可以看到，大数据任务的资源消耗有很明显的高峰期和低谷期：一般晚上0点到第二天的上午9点（夜晚时段）是高峰期，上午9点到晚上0点（白天时段）是低谷期。

任务有明显的高峰低谷，但是服务器资源不是弹性的，所以服务器在低谷期比较空闲，在高峰期比较繁忙，整个集群的资源配置取决于高峰期的任务消耗。因此，把一些不必要在高峰期内运行任务迁移到低谷期运行，可以节省资源的消耗。

第四，数据未压缩。Hadoop架构中的HDFS为了实现高可用，默认数据存储3副本，所以大数据的物理存储量消耗较大，尤其是对于一些原始数据层和明细数据层的大表，动辄500多T，折合物理存储需要1.5P（三副本，所以实际物理存储5003），大约需要16台物理服务器（一台服务器可分配存储按照128T计算）。如果不启用压缩，存储资源成本会很高。此外，在Hive或者Spark计算过程中，中间结果也需要压缩，可以降低网络传输量，从而提高Shuffer (基于Hive或者Spark计算，数据在不同节点之间的传输过程) 性能。

针对以上常见原因，我们建立精细化的成本管控体系。

精细化成本管控

遵循全局盘点、发现问题、定位原因、治理优化和效果评估五个步骤。

全局盘点

对数据中台所有数据的全面盘点，是精细化成本管控的第一步。

通过梳理全链路数据资产视图，我们可以看到，下游末端关联到了数据应用（财务分析），而上游的起点是进入数据中台的原始数据，数据之间通过任务进行连接。接下来，我们需要计算全链路数据资产视图中的末端数据（加工链路最下游的表）的成本和价值。需要注意的是，评估通常从末端开始，因为中间数据，在计算价值的时候，需要考虑下游表被使用的情况，相对难计算归类，因此选择从末端数据开始。

数据成本核算

报表上游链路中涉及：

• 【3个任务】a，b，c
• 【6张表】A，B，C，D，E，F

那么，这张报表的成本计算如下：

表成本=3个任务加工消耗的计算资源成本+6张表消耗的存储资源的成本

需要注意的是，如果一个表被多个下游应用复用，那么这个表的存储以及计算成本，需要分摊给多个应用。

数据价值核算

数据价值评估分为两个情景：

如果末端数据是一张应用层的表，它对接的是一张数据报表，那么衡量这个数据的价值，主要是看报表的使用范围和使用频率。在计算使用范围时，通常使用周粒度，同时考虑不同管理层级的权重。

• 管理级别越高，做出的商业决策影响就越大，诸如老板等管理人员，应赋予更高的权重。
• 使用频率一般使用单个用户每周查看报表的次数来衡量，例如PV，UV等指标，指标数值越高，证明报表使用频次高，报表价值越大。

如果末端数据对接的不是一个数据报表，而是面向特定场景的数据应用。衡量此类报表的价值，主要考虑目标人群的覆盖率和直接业务价值产出。

此外，末端数据还可能是一张集市层的表，它主要提供给分析师用于探索式查询。这类表的价值主要看它被哪些分析师使用，使用频率如何。同样，在使用范围评估时，要对分析师按照级别加权。

发现问题与定位原因

通过以上全局盘点，我们可以定位以下两大类问题：

• 持续生产，但已经没有价值的末端数据或应用（“价值”可以根据实际业务定义，例如30天内没有访问），以及这些数据上游链路上的所有相关数据开发任务；
• 高峰期高消耗的数据。

针对问题，尤其是复杂的问题，我们需要分析问题背后的原因，也可以从上面四个原因中直接归类。

治理优化

对于第一类问题，需要评估报表是否下线，以及制定报表下线的策略。报表下线要谨慎对待，一方面，评估报表的重要性——访问量只是其中一个维度，另一方面报表访问少是诸多原因共同作用，例如，报表路径较长，业务人员找不到；部门人数本身就少，访问量与部门人数有关等。如果确定下线，需要对报表上游的所有加工表下线，如果该表还被其他的应用引用，考虑是否能脱钩，如果不能脱钩，还不能下线。

对于第二类问题，需要优化高消耗数据计算资源。造成高消耗的具体场景可分为产出数据的任务高消耗和数据存储高消耗。对于产出任务高消耗，首先要考虑是不是数据倾斜。例如，通过MR或者Spark日志中，Shuffer的数据量进行判断。如果有某一个Task数据量非常大，其他的很少，就可以判定出现了数据倾斜。

综上，我们经过一些策略的调整和优化，此时如何评估治理的效果呢？

效果评估

核心五个字：省了多少钱。

不过，如果直接用减少服务器的数量来衡量，其实并不能真实地反应治理效果，因为未考虑业务增长等其他情况。因此，我们需要具体围绕优化任务数量背后的数据和资源成本考虑：

下线了多少任务和数据？这些任务每日消耗了多少资源？数据占用了多少存储空间？拿这些资源来计算成本。例如，任务A运行时长3个小时，在运行过程中，共消耗5384503 cpu*s，37007892 GB *s, 假设我们1个CU（1 cpu，4g memeory）一年是1300元成本，折合每天为3.5元（计算公式为1300/365）。

综上，我们完整地讨论了元数据中心的两个数据产品应用：指标字典搭建、数据模型整合，以及两项核心评估体系：数据质量评估、中台成本管控。

下一篇，我们继续讨论数据中台其他模块的架构策略。