前言

就这样，大数据领域蓬勃发展了好几年，有很多伙伴执迷于技术，成为了分布式计算与存储的领域专家。也有很多伙伴执迷于数据，成为了行业的数据研发专家。当然还有很多小伙伴，热衷于工具系统开发，成为了数据技术专家。那么我们回过头来考虑，什么是大数据，什么又是数据仓库，什么又是数据技术。大数据其实是个非常笼统的感念，它是由数据仓库演化而来的数据与技术方法论，那么我们先说一下数据仓库的由来：

早在多年以前在Hadoop、Spark、Storm、Kafka等系列分布式计算与存储、消息中间件还没有成熟的时候，数据仓库主要基于Oracle的数仓建设，即便是现在的大数据，仍然使用的是关系理论描述数据之间的关系，只是基于其数据存取的特点在关系数据模型的范式上有了不同的选择而已。但随着时间的推移，传统数据仓库的数据计算与存储，已经无法很好地支持海量数据的计算与存储，这样大数据（分布式）技术才开始火热起来。那么说到这里，我们先说下数据仓库中，OLTP和OLAP系统的区别：

OLTP：数据操作主要是随机读写，主要采用满足3NF的实体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性问题。

OLAP：数据操作主要是批量读写，事务处理中的一致性不是OLAP所关注，其主要关注数据的整合，以及在一次性的大数据查询和处理中的性能。

数据模型

数据仓库建模方法论包含 ER模型 、维度模型、Data Vault模型 及 Anchor模型。

ER模型：采用ER模型建设数据仓库模型的出发点是数据整合，将各个系统中的数据以整个企业角度按照主题进行 相似性组合 和 合并，并进行一致性处理，为数据分析决策服务。建模一般分为：

• 高层模型：一个高度抽象的模型，描述主要的主题以及主题之间的关系
• 中层模型：在高层模型的基础上，细化主题的数据项。
• 物理模型：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可以做一些表的合并、分区设计等。
• 维度模型：选择需要进行分析决策的业务过程->选择粒度->识别维表->选择事实
• Data Vault模型：它强调简历一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合。该模型有以下几部分组成：
  • Hub：是企业的核心业务实体，由实体Key、数据仓库序列代理键、装载时间、数据来源组成。
  • Link：代表Hub之间的关系。这里与ER模型最大的区别是将关系作为一个独立的单元抽象。
  • Satellite:是Hub的详细描述内容，一个Hub可以有多个Satellite。它由Hub的代理键、装载时间、来源类型、详细的Hub描述信息组成。
• Anchor模型：进一步规范化处理，其核心思想是所有的扩展只添加而不是修改，因此将模型规范到6NF，基本编程了K-V结构化模型。

那么总的来说，分为三个阶段：
　　1、将数据以源表结构相同的方式同步到Oracle，数据工程师基于ODS数据进行统计。
　　2、通过一些模型技术改变烟囱式的开发模型，消除一些冗余，提升数据的一致性。（经验）在不太成熟、快速变化的业务面前，构建ER模型的风险非常大，不太适合去构建ER模型。
　　3、选择了以Kimball的维度建模为核心理念的模型方法论，同时对其进行了一定的升级和扩展，构建了公共层模型数据架构体系。

大数据链路

说到这里，有些偏向于技术的同学开始发问，我去，这是啥啊。。我是来看大数据技术的！ 我想说的是，不要着急，我们慢慢来哈。。那么正是因为时代的发展，同时业务种类的增多，数据存储类型的多样化（结构化、半结构化、非结构化）造成了传统数据库无法很会好的支撑，你们要的大数据技术来了！Hadoop！。。等等被你们带偏了。。我们慢慢来。。打开你的视野，先从全局去观察整个大数据体系的运作。大数据大数据，我们先把数据进行分层，那么数据模型的分层总的来说可以分为ODS、DWD、DWS、ADS、DIM：

• ODS层：ODS层属于操作数据层，是直接从业务系统采集过来的最原始的数据，包含了所有业务的变更过程，数据粒度也是最细的。
• DWD层：是在ODS层基础上，根据业务过程建模出来的实时事实明细层，对于访问日志这种数据，会回流到离线系统供下游使用，最大程度地保证实时和离线数据ODS层和DWD层一致。
• DWS层：订阅明细层数据后，会在实时计算任务中计算各个维度的汇总指标。如果维度是各个垂直业务线通用的，则会放在实时通用汇总层，作为通用的数据模型使用。
• ADS层：个性化维度汇总层，对于不是特别通用的统计维度数据会放在这一层中，这里计算只有自身业务才会关注的维度和指标。
• DIM层：实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线系统中供实时应用调用。

那么整个大数据链路，就可以分为采集-->同步-->离线（实时）计算->存储->线上回流。我们来一一详解。
1、采集
　　数据从哪来？要到哪去？我是谁？我为什么坐在这里？因为它来自浏览器和线上业务数据。浏览器的日志采集：浏览器的日志采集的分类包含（1）页面浏览（展现）日志采集（2）页面交互日志采集

对于（1）类也就是目前所有互联网产品的两大基本指标：页面浏览量(PV)和访客数(UV)的统计基础。

对于（2）用户可在浏览器内与页面进行的互动，互动设计都要求采集用户的互动行为数据，以便通过量化获知用户的兴趣点或者体验优化点。

1.1页面浏览日志采集流程：
　用户在浏览器内点击淘宝首页链接。
按照HTTP协议，一个标准的HTTP请求由三部分构成：
　　（2）请求行，分别是请求方法、所氢气资源的URL以及HTTP协议版本号。

（3）请求报头，一般会附加很多内容项（每项内容被称为一个头域，Header），用户如果已登录过，则一般会在请求头中附加一个或多个被称为Cookie的数据项，其中记录上一次访问的信息。
　　（4）请求正文，一般HTTP请求的正文都是空的（body）。
　　（5）服务器接受并解析请求。
与HTTP请求相对应，一个标准的HTTP响应也由三部分构成。
（6）状态行，标识了服务器对此次HTTP请求的处理结果。主要内容是由是三位数字构成的状态码，比如成功响应200和代表所请求的资源在服务器没找到404等。
（7）响应报头，在执行响应时，同样可以加载一些数据项，这些数据项将在浏览器端被读取和使用。
（8）响应正文，浏览器请求的文档、图片、脚本等，其实就是被包装在正文内返回浏览器的。
（9）浏览器接收到服务器的响应内容，并将其按照规范展现给用户，完成整个请求。
　　 综上所述，真正的采集日志的动作，需要在第（9）步，也就是浏览器开始解析文档时才能进行。最直接的采集思路：在HTML文档内的适当位置增加一个日志采集点，当浏览器解析到这个节点时，将自动触发一个特定的HTTP的请求到日志采集服务器。
　　1.2 日志采集服务器整体流程
（1）客户端日志采集，由一小段被植入页面HTML文档内的JavaScript脚本来执行。由业务服务器在响应业务请求时动态执行。
（2）客户端日志发送，会向日志服务器发起一个日志请求，以将采集到的数据发送至日志服务器。
（3）服务器端日志收集，日志服务器的日志收集模块会将日志请求内容写入一个日志缓冲区内，完成此条浏览日志的收集。
（4）服务器日志解析存档，由日志采集脚本记录在日志请求行内的参数，将在这个环节被解析，转存入标准的日志文件中并注入实时消息通道内，供其他后端程序读取和进一步加工处理。
　　1.3 页面交互日志采集
由于业务的发展及每个页面业务的行为、业务特征都不相同，呈现出高度自定义的业务特征，造成采集元数据的困难。需要提供一个统一的日志采集服务，如下，可将自助采集的交互日志发送到日志服务器：
（1）业务方在元数据管理界面一次注册需要采集交互日志的业务、具体业务场景以及场景下的具体交互才几点，在注册完成后，系统将生成与之对应的交互日志采集代码模板。
（2）将交互日志采集代码植入目标页面，并将采集代码与要监督的交互行为做绑定。
（3）当用户在页面上产生指定行为时，采集代码和正常的业务交互响应代码一起被触发和执行。
（4）采集代码在采集动作完成后将对应的日志通过HTTP协议发送到日志服务器。
　　这便是整个web端的实时行为数据采集，当然也有一些来自于线上业务数据库的离线数据同步，通常为业务特征数据。那么下来我们来聊下数据同步。

2、数据同步

数据同步的方式有很多种，从刚才采集端我们发现，存在 日志采集 和 数据库数据同步 两部分。那么总的来说同步的方式分为 直连同步、数据文件同步、数据库日志解析同步
　　直连同步：对于直连同步来说，直接通过API接口直连线上数据库，何种方式的比较容易实现，但是带来的问题便是对线上数据库造成一定的压力，比如直接用sqoop进行数据同步。
　　数据文件同步：每日从业务系统直接导出文件，通过FTP等方式同步到大数据集群环境，然后通过load的方式加载到目标环境中，这种方式在大多数公司普遍使用。
　　数据库日志解析同步：通过解析日志文件获取发生变更的数据，从而满足增量数据同步的需求。
　　这里的数据同步，更多的偏向于离线数据同步。对于实时呢，通常会将数据直接写入消息中间件例如kafka、flume。然后push到对应的服务端进行解析或者由storm等的流式处理框架进行数据的计算等。

3、数据开发（离线与实时）

现在好了~数据已经同步过来了，我们要开始做数据处理（ETL）了！，来自各个业务系统的数据都已经到了分布式文件系统中，我们挨个一个一个的去清洗、制作业务宽表、抽取多业务线通用的数据中间层。做时间长了呢，发现，这不行啊！我天天写MapReduce、天天写Scala，又没几个人会，上手干活儿的成本太大了，还牵扯到代码调优，那么有没有统一的工作平台，直接写Sql就好了啊。于是，数据研发工作台应运而生，这里先说离线。
　　玩过大数据的都知道，写MapReduce的成本很高，而且任何业务都要去通过Map、Reduce这样的模型框架下开发，非常的繁琐而又复杂。Hive应运而生，基于SQL的数据研发。但是我们总不能让数据研发，每次都登录Linux服务器，万一执行错一个命令，代价很高的，你懂的~ 同时，当业务越来越多，任务越来越多，不用的任务之间可能会相互依赖，那么我们就需要一个，数据研发工作台来很好的解决这一的问题。
　　1、统一开发平台，从任务开发、调试、测试、发布、监控、报警到运维管理，形成了整套工具和产品，即提高了开发效率，又保证了数据质量。
　　在任务开发中遇到的各种问题，如用户编写的SQL质量差、性能低、不遵循规范等，总结后形成规则，并通过系统及研发流程保障，事前解决故障隐患，避免事后处理。
　（1）在用户提交job时，校验系统主要有如下三类规则校验：
　　1、 代码规则校验：如表名规范、生命周期设置、表注释等。
　　2、 代码质量类规则：如调度参数使用检查、分母为0提醒、NULL值参与计算影响结果提醒、插入字段顺序错误等。
　　3、 代码性能类规则：如分区裁剪失败、扫描大表提醒、重复计算检测等。
　　在校验系统中，触发强规则后，任务的提交就会被阻断，必须修复代码后才能够再次提交。
　（2） 质量系统DQC
　　主要关注数据质量，通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控。
　　　　1、 数据监控
　　　　强规则会阻断任务的执行、弱规则只会告警不会阻断任务的执行。常见的DQC监控规则有：主键监控、表数据量及波动监控、重要字段的非空监控、重要枚举字段的离散值监控、指标值波动监控、业务规则监控等。
　　　　2、 数据清洗
　　　　其过程在数据进入ODS层之后执行。对于离线任务，每隔固定时间，数据入仓以后，启动清洗任务，调用DQC的清洗规则，将符合清洗规则的数据清洗掉，并保存到DIRTY表归档。如果清洗掉的数据量大于预设的阈值，则阻断任务的执行，否则不会阻断。
　 （3） 数据测试系统
　　　　数据测试的典型测试方法是 功能测试，主要验证目标数据是否符合预期。
1、新增业务需求
2、数据迁移、重构和修改
　2、 任务调度系统
（1）数据开发流程与调度系统的关系
（2）调度系统的核心设计模型
　　　　1、调度引擎：根据任务节点属性以及依赖关系进行实例化，生成各类参数的实例，并生成调度树。
　　　　2、执行引擎：根据调度引擎生成的具体任务实例和配置信息，分配CPU、内存、运行节点等资源，在任务对应的执行环境中运行代码节点。
　（3）任务状态机模型
　　　　针对数据任务节点在整个运行生命周期的状态定义，总共有6种状态，状态之间的转换逻辑：1、未运行 -> 2、等待运行 -> 3、等待资源 -> 4、运行中 -> 5、成功或失败。
　（4）工作流状态机模型
　　　　针对数据任务节点在调度树中生成的工作流运行的不同状态定义，一共有5种状态：1、创建工作流 -> 已创建 -> 运行中 -> 成功或失败 <- 是否重跑
　（5）调度引擎工作原理
　　　　以时间驱动的方式运行，为数据任务节点生成实例，并在调度树种生成具体执行的工作流。
　（6）执行引擎工作原理
（不详细多说）
　（7）执行引擎的用法
用户系统包括上文的工作流服务、数据同步服务，以及调度引擎生成的各类数据处理任务的调度服务。

下来我们说一下实时，实时处理有别于离线处理。我们知道，实时数据是来自于各个业务的日志服务器中，这些数据被实时采集到数据中间件中，供下游实时订阅使用。数据采集一般基于以下原则，按批次对数据进行采集：
　　1、 数据大小限制：当达到限制条件时，把目前采集到的新数据作为一批。
　　2、 时间阈值限制：当时间到达一定条件时，也会把目前采集到的新数据作为一批，避免在数据量少的情况下一直不采集。
　　随后呢，数据被采集到中间件后，需要下游实时订阅数据，并通过（推或拉）的方式到流式计算系统的任务中进行加工处理。
　 基于Storm的实时数据处理应用，出于性能考虑，计算任务往往是多线程的，一般会根据业务主键进行分桶处理，并且大部分计算过程需要的数据都会放在内存中，会大大提高吞吐量。
　
　　1、 去重指标
　　在统计实时任务中，会产生大量的数据存储在内存中，计算逻辑一般都是内存完成的，中间结果数据也会缓存在内存中。那么就需要 布隆过滤器 和 基数估计
　　布隆过滤器：位数组算法的应用，不保存真实的明细数据，值保存明细数据对哈希值的标记位。
　　基数估计：按照数据的分散程度来估算现有数据集的便捷，从而得出大概的去重综合。

2、 数据倾斜
　　在数据量非常大的时候，单个节点的处理能力有限，必然会遇到性能瓶颈。这时就需要对数据进行分桶处理，分桶处理和离线处理的思路一致。
　　去重指标分桶：对去重值进行分桶Hash，相同的值一定会被放在同一个桶中去重，最后再把每个桶里面的值进行加和就得到总值。
　　非去重指标分桶：数据随机分发到每个桶中，最后再把每个桶的值汇总，主要利用的是各个桶的CPU能力。

3、 事务处理

为了做到数据的精准处理，包括如下：

超时时间：由于数据处理是按照批次来进行的，当一批数据处理超时时，会从拓扑的spout端重发数据，另外批次处理的数据量不宜过大，应该增加一个限流的功能，避免数据处理超时。

事务信息：每批数据都会附带一个事务ID的信息，在重发的情况下，让开发者自己根据事务信息去判断数据第一次到达和重发时不同的处理逻辑。

备份机制：开发人员需要保证内存数据可以通过外部存储恢复，因此在计算中用到的中间结果数据需要备份到外部存储中。

数据被实时加工处理（比如聚合、清洗等）后，会写到某个在线服务的存储系统中，供下游调用方便使用。实时任务在运行过程中，会计算很多维度和指标，这些数据需要放在一个存储系统中作为恢复或关联使用。

1、 中间结果：在实时应用处理中，会有一些状态的保存（比如去重指标的明细数据），用于发生故障时，使用数据库中的数据恢复内存现场（HBASE）。

2、 最终结果数据：这些数据是实时更新的，写的频率非常高，可以直接被下游使用。

3、 维表数据：在离线计算系统中，通过同步工具导入到在线存储系统中，供实时任务来关联实时流数据。

最后又牵扯到Hbase的存储及rowkey设计相关：

1、 表名设计

设计规则：汇总层标识+数据域+主维度+时间维度

2、 Rowkey设计

设计规则：MD5+主维度+维度标识+子维度1+时间维度+子维度2

4、数据回流

数据回流的含义，就是讲计算好的数据表回流至线上系统，供线上系统使用，一般回流的数据皆为离线数据，或实时数据的校对后的补充数据。

综上所述，我们玩完了整个数据链路。。再见！ 。。等等。。少了好多东西，数据管理？数据治理？数据质量？要啥自行车？那我们继续先从数据管理开始。

数据管理

1、元数据

传统意义上呢，元数据是指数据的数据。元数据打通了源数据、数据仓库、数据应用，记录了数据从 产生 到 消费 的全过程。

元数据主要记录了数据仓库模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。那么针对元数据，我们又可以分为 技术元数据 和 业务元数据。

那么我们首先来讲技术元数据，其实理解技术元数据你可以理解为是存储数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。包括：分布式计算系统存储元数据、分布式计算系统运行元数据 以及 数据开发平台中 数据同步、计算任务、任务调度等信息，包括数据同步的输入输出表和字段，以及同步任务本身的元数据信息。

业务元数据呢，从业务角度描述数据仓库中的数据，提供了使用者和实际系统之间的语义层。其中包括：维度及属性、业务过程、指标等的规范定义，用于更好地管理和使用数据。数据应用元数据，如数据报表、数据产品的配置等。

那么综合两种元数据，我们可以看出元数据的应用价值，是数据管理、数据内容、数据应用的基础，在数据管理方面为集团数据提供在计算、存储、成本、质量、安全、模型等治理领域上的数据支持。

1.1 统一元数据建设
元数据建设的目标是 打通 数据接入 到 加工，再到 数据消费 整个链路，规范元数据体系与模型，提供统一的元数据服务出口，保障元数据产出的稳定性和质量。包括：
　　（1）元仓底层数据：对元数据做分类，如计算元数据、存储元数据、质量元数据等，减少数据重复建设，保障数据的唯一性。

（2）根据元仓底层数据构建元仓中间层：建设元仓基础宽表，也就是元数据中间层，打通从 数据产生 到 消费 整个链路，不断丰富中间层数据，如MaxCompute元数据、调度元数据、同步元数据、产出访问元数据、服务元数据等。

（3）元数据服务：基于元数据中间层，对外提供标准统一的元数据服务出口，保障元数据产出的质量。

1.2 元数据应用

（1） 血缘图谱：系统化、自动化地对计算与存储平台上的数据进行打标、整理、归档。形象地说，是为元数据“画像”的任务。

实际上，在数据的研发流程、保障登记、数据质量要求、安全等级、运维策略、告警设置上都会有差异，那么可以将标签体系分为四类：

基础标签：针对数据的存储情况、访问情况、安全等级等进行打标。

数仓标签：针对数据是增量还是全量、是否可再生、数据的生命周期来进行标签化处理。

业务标签：根据数据归属的主题域、产品线、业务类型为数据打上不同的标签。

潜在标签：为了说明数据潜在的应用场景，比如社交、媒体、广告、电商、金融等。

（2） 元数据门户：

“前台”产品为数据地图，定位消费市场，实现检索数据、理解数据等的“找数据”的需求。

“后台” 产品为数据管理，定位于一站式数据管理，实现成本管理、安全管理、质量管理等。

同时，针对开发者，主要包括计算费用和健康分管理、存储费用，并提供优化建议和健康分管理。

（3） 应用链路分析：通过应用链路分析，产出表级血缘、字段血缘和表的应用血缘。其中表级血缘主要计算方式为：通过 计算引擎日志进行解析 和 根据任务依赖进行解析。

常见的应用链路分析应用主要有：影响分析、重要性分析、下线分析、链路分析、寻根分析、故障排查等。

（4） 数据建模：

通过元数据驱动的数据仓库模型建设，可以在一定程度上提高数据仓库建模的数据化指导，提升建模效率。

所使用的元数据有：

表的基础元数据 包括：下游情况、查询次数、关联次数、聚合次数、产出时间等。

表的关联关系元数据 包括：关联表、关联类型、关联字段、关联次数等。

表的字段的基础元数据 包括：字段名称、字段注释、查询次数、关联次数、聚合次数、过滤次数等。

其中查询指SQL的SELECT，关联指SQL的JOIN，聚合指SQL的GROUP BY，过滤指SQL的WHERE。

（5） 驱动ETL开发：

通过元数据驱动一键、批量高效数据同步。

2、存储与成本治理

大数据啊大数据，数据量太大了。。然后呢，由于业务形态的变换，很多已有的ETL任务所产出的业务表已经木有了业务价值。但每日跑批任务依旧会占用计算资源，同时增加现有分区的存储资源。那么我们就以成本治理的角度，去干掉它！方法如下：
　　1、 数据压缩
数据压缩主要采取archive压缩方法，对于Hadoop等分布式文件系统来说，通常会将数据存储3份，通过file压缩，可将压缩比从1:3提高到1:1.5（具体要深入研究）。
　　2、数据重分布
主要采取基于列存储的方式，通过修改表的数据重分布，避免列热点，会节省一定的存储空间。一般会采用Distribute by 和 Sort by 的方式。
数据重分布效果的波动比较大，主要跟数据表中字段的重复值、字段本身的大小、其他字段的具体分布有一定的关系，一般要筛选出重分布效果高于15%的表进行优化处理。
　　3、存储治理项优化
在元数据基础上，诊断、加工成多个存储治理优化项。目前已有的存储治理优化项有 未管理表、空表、最近62天未访问表、数据无更新无任务表、数据无更新有任务表、开发库数据大于100GB且无访问表、长周期表等。
　　4、生命周期管理
生命周期你管理的根本目的是 用最少的存储成本 来满足最大的业务需求，使数据价值最大化。
　 　　（1） 生命周期管理策略
　　　　　周期性删除策略：某些历史数据可能已经没有价值，且占用存储成本，那么针对无效的历史数据就可以进行定期清理。
　　　　　彻底删除策略：无用表策略或者ETL过程产生的临时数据，以及不需要保留的数据，可以进行及时删除，包括删除元数据。
　　　　　永久保存策略：重复且不可恢复的底层数据和应用数据需要永久保存。
　　　　　极限存储策略：超高压缩重复镜像数据。
　　　　 冷数据管理策略：一般将重要且不可恢复的、占用存储空间大于100TB，且访问频次较低的数据进行冷备（例如3年以上的日志数据）。
　　　　 增量表merge全量表策略：对于对应的delta增量表的保留策略，目前默认保留93天。
　　　（2） 通用的生命周期管理矩阵
　　　　主要通过对历史数据的等级划分与对表类型的划分生成相应的生命周期管理矩阵。
　　　（3） 历史数据等级划分
　　　　主要将历史数据划分为P0、P1、P2、P3四个等级。
　　　　1、 P0：非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如：交易、日志、集团KPI数据、IPO关联表。

2、 P1：重要的业务数据和重要的应用数据，具有不可恢复性，如重要的业务产品数据。

3、 P2：重要的业务数据和重要的应用数据，具有可恢复性，如交易线ETL产生的中间过程数据。

4、 P3：不重要的业务数据和不重要的应用数据，具有可恢复性，如某些SNS产品报表。

（4） 表类型划分

1、 事件型流水表：数据无重复或者无主键数据，如日志。

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

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

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

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

6、 TT临时数据：TT拉取的数据和DbSync产生的临时数据最终会流转到ODS层，ODS层数据作为原始数据保留下来很长时间，生命周期默认设置为93天，可以根据实际情况适当减少保留天数。

7、 普通全量表：根据历史数据等级确定保留策略。

5、 数据成本计量
　 任何一个计算任务都会涉及计算和存储资源的消耗，其中计算资源的消耗主要考虑CPU消耗，CPU消耗的单位定义为CU，代表一个核心(Core)运行一天的消耗量。
在计量数据表的成本时，除了考虑数据表本身的计算成本、存储成本外，还要考虑对上游数据表的扫描带来的扫描成本。
　　6、 数据使用计费
　 规范下游用户的数据使用方法，提升数据使用效率，从而为业务提供优质的数据服务。
　 3、数据质量

数据质量是每一位数据人的生命线。那么数据质量的评估，可以从完整性、准确性、一致性和及时性来说。

（1） 完整性

完整性是指数据的 记录 和 信息是否完整，是否存在缺失的情况。那么数据缺失主要包括 记录的缺失 和 记录中某个字段信息 的缺失。

（2） 准确性

准确性是指数据中记录的信息和数据是否准确，是否存在异常或者错误的信息。

（3） 一致性

在数据仓库中，有很多业务数据仓库分支，对于同一份数据，必须保证一致性。

（4） 及时性

在确保数据的完整性、准确性和一致性后，接下来就要保障数据能够及时产出，这样才能体现数据的价值。

1、 数据质量方法概述
　　　 针对数据质量的各个方面，都有相关的工具进行保证，以提高效能。
　　　　（1） 消费场景知晓：主要通过 数据资产等级 和 基于元数据的应用链路分析 解决消费场景知晓的问题。那么又引出 数据资产等级定义 和 数据资产等级落地方法
　　　　 数据资产等级定义：按照一般性和未执行，不同性质的重要性依次降低包括：毁灭性质、全局性质、局部性质、一般性质、未知性质。

毁灭性质-A1等级 全局性质-A2等级 局部性质-A3等级 一般性质-A4等级，未知性质-Ax等级，如果一份数据出现在多个应用场景，则遵循就高原则。

数据资产等级落地方法：通过给不同的数据产品或者应用划分数据资产等级，再依托元数据的上下游血缘，就可以将整个消费链路打上某一数据资产的标签，这样就可以将数以亿计的数据进行分类。

（2） 数据生产加工各个环节卡点校验：校验部分主要包括在线系统和离线系统数据生产加工各个环节的卡点校验。

发布上线前的测试包括：Code Review 和 回归测试，对于资产等级较高的任务变更发布，则采取强阻断的形式，完成回归测试以后才允许发布。

（3） 风险点监控：主要是针对在数据日常运行过程中可能出现的 数据质量 和 时效 等问题进行监控。

那么风险点监控又包括 在线数据风险点监控 和 离线数据风险点监控。

在线数据风险点监控：在线业务系统的数据生产过程中需要保证数据质量，主要根据业务规则对数据进行监控。

方法：同时订阅一份相同的数据，在系统中进行逻辑校验，当校验不通过时，以报警的形式披露出来给到规则订阅人，以完成数据的校对。

离线数据风险点监控：主要包括对 数据准确性 和 数据产出及时性 的监控。

数据准确性：由离线开发人员进行配置来确保数据准确性。

数据及时性包括：

1、任务优先级： 调度是个树形结构，在优先级的设置上，首先是确定业务的资产等级，等级高的业务所对应的消费节点自然配置高优先级，一般业务则对应低优先级，确保高等级业务准时产出。

2、任务报警：若发现异常则执行不同等级的预警，根据不同的资产等级执行强保障或弱保障。

强保障又包括：监控范围、监控异常、告警对象、何时告警、告警方式。
　　　 自定义监控：出错告警、完成告警、未完成告警、周期性告警、超时告警。

（4） 质量衡量：主要用于跟进质量问题，确定质量问题原因、责任人、解决情况等。斌惯用语数据质量的复盘，避免类似事件再次发生。

1、数据质量起夜率：每个月的起夜次数将是衡量数据质量建设完善度的一个关键指标。

2、数据质量事件：用来跟进数据质量问题的处理过程、用来归纳分析找到数据出现问题的原因、给出后续预防方案。

3、数据质量故障体系：故障定义、故障等级、故障处理、故障Review。