基于MaxCompute/Dataworks实现数据仓库管理与全链路数据体系

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

　　早在多年之前在Hadoop、Spark、Storm、Kafka等系列分布式计算与存储、消息中间件尚未成熟的时候，数据仓库主要基于Oracle的数仓建设，即使是如今比较流行的大数据产品，如阿里巴巴MaxCompute，仍然使用的是关系理论描述数据之间的关系，只是基于其数据存取的特色在关系数据模型的范式上有了不一样的选择而已。但随着时间的推移，传统数据仓库的数据计算与存储，已经没法很好地支持海量数据的计算与存储，这样大数据（分布式）技术才开始火热起来。那么说到这里，咱们先说下数据仓库中，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结构化模型。

　　那么总的来讲，分为三个阶段：

　　一、将数据以源表结构相同的方式同步到Oracle，数据工程师基于ODS数据进行统计。

　　二、经过一些模型技术改变烟囱式的开发模型，消除一些冗余，提高数据的一致性。（经验）在不太成熟、快速变化的业务面前，构建ER模型的风险很是大，不太适合去构建ER模型。

　　三、选择了以Kimball的维度建模为核心理念的模型方法论，同时对其进行了必定的升级和扩展，构建了公共层模型数据架构体系。

 

大数据链路

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

　　ODS层：ODS层属于操做数据层，是直接从业务系统采集过来的最原始的数据，包含了全部业务的变动过程，数据粒度也是最细的。

 　  DWD层：是在ODS层基础上，根据业务过程建模出来的实时事实明细层，对于访问日志这种数据，会回流到离线系统供下游使用，最大程度地保证明时和离线数据ODS层和DWD层一致。

 　  DWS层：订阅明细层数据后，会在实时计算任务中计算各个维度的汇总指标。若是维度是各个垂直业务线通用的，则会放在实时通用汇总层，做为通用的数据模型使用。

 　  ADS层：个性化维度汇总层，对于不是特别通用的统计维度数据会放在这一层中，这里计算只有自身业务才会关注的维度和指标。

 　  DIM层：实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线系统中供实时应用调用。

　　那么整个大数据链路，就能够分为采集-->同步-->离线（实时）计算->存储->线上回流。咱们来一一详解。

     一、采集

　　数据从哪来？要到哪去？我是谁？我为何坐在这里？由于它来自浏览器和线上业务数据。浏览器的日志采集：浏览器的日志采集的分类包含（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端的实时行为数据采集，固然也有一些来自于线上业务数据库的离线数据同步，一般为业务特征数据。那么下来咱们来聊下数据同步。

 

     二、数据同步

　　数据同步的方式有不少种，从刚才采集端咱们发现，存在 日志采集 和 数据库数据同步 两部分。那么总的来讲同步的方式分为 直连同步、数据文件同步、数据库日志解析同步

　　直连同步：对于直连同步来讲，直接经过API接口直连线上数据库，何种方式的比较容易实现，可是带来的问题即是对线上数据库形成必定的压力，好比直接用datax、sqoop进行数据同步。

　　数据文件同步：每日从业务系统直接导出文件，经过FTP等方式同步到大数据集群环境，而后经过load的方式加载到目标环境中，这种方式在大多数公司广泛使用。

　　数据库日志解析同步：经过解析日志文件获取发生变动的数据，从而知足增量数据同步的需求。

　　这里的数据同步，更多的偏向于离线数据同步。对于实时呢，一般会将数据直接写入消息中间件例如kafka、flume。而后push到对应的服务端进行解析或者由storm、flink等的流式处理框架进行数据的计算等。

　

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

　　如今好了~数据已经同步过来了，咱们要开始作数据处理（ETL）了！，来自各个业务系统的数据都已经到了分布式文件系统中，咱们挨个一个一个的去清洗、制做业务宽表、抽取多业务线通用的数据中间层。作时间长了呢，发现，这不行啊！我每天写MapReduce、每天写Scala，又没几我的会，上手干活儿的成本太大了，还牵扯到代码调优，那么有没有统一的工做平台，直接写Sql就行了啊。因而，数据研发工做台应运而生，这里先说离线。

　　玩过大数据的都知道，写MapReduce的成本很高，并且任何业务都要去经过Map、Reduce这样的模型框架下开发，很是的繁琐而又复杂。Hive应运而生，基于SQL的数据研发。可是咱们总不能让数据研发，每次都登陆Linux服务器，万一执行错一个命令，代价很高的，你懂的~ 同时，当业务愈来愈多，任务愈来愈多，不用的任务之间可能会相互依赖，那么咱们就须要一个，数据研发工做台来很好的解决这一的问题。

　　一、统一开发平台，从任务开发、调试、测试、发布、监控、报警到运维管理，造成了整套工具和产品，即提升了开发效率，又保证了数据质量。

　　在任务开发中遇到的各类问题，如用户编写的SQL质量差、性能低、不遵循规范等，总结后造成规则，并经过系统及研发流程保障，事前解决故障隐患，避免过后处理。

　（1）在用户提交job时，校验系统主要有以下三类规则校验：

　　一、 代码规则校验：如表名规范、生命周期设置、表注释等。

　　二、 代码质量类规则：如调度参数使用检查、分母为0提醒、NULL值参与计算影响结果提醒、插入字段顺序错误等。

　　三、 代码性能类规则：如分区裁剪失败、扫描大表提醒、重复计算检测等。

　　在校验系统中，触发强规则后，任务的提交就会被阻断，必须修复代码后才可以再次提交。

 　（2）     质量系统DQC

　　主要关注数据质量，经过配置数据质量校验规则，自动在数据处理任务过程当中进行数据质量方面的监控。

　　　　一、 数据监控

　　　　强规则会阻断任务的执行、弱规则只会告警不会阻断任务的执行。常见的DQC监控规则有：主键监控、表数据量及波动监控、重要字段的非空监控、重要枚举字段的离散值监控、指标值波动监控、业务规则监控等。

　　　　二、 数据清洗

　　　　其过程在数据进入ODS层以后执行。对于离线任务，每隔固定时间，数据入仓之后，启动清洗任务，调用DQC的清洗规则，将符合清洗规则的数据清洗掉，并保存到DIRTY表归档。若是清洗掉的数据量大于预设的阈值，则阻断任务的执行，不然不会阻断。

　 （3）     数据测试系统

　　　　数据测试的典型测试方法是 功能测试，主要验证目标数据是否符合预期。

              一、新增业务需求

              二、数据迁移、重构和修改

　二、 任务调度系统

    （1）数据开发流程与调度系统的关系

    （2）调度系统的核心设计模型

　　　　一、调度引擎：根据任务节点属性以及依赖关系进行实例化，生成各种参数的实例，并生成调度树。

　　　　二、执行引擎：根据调度引擎生成的具体任务实例和配置信息，分配CPU、内存、运行节点等资源，在任务对应的执行环境中运行代码节点。

　（3）任务状态机模型

　　　　针对数据任务节点在整个运行生命周期的状态定义，总共有6种状态，状态之间的转换逻辑：一、未运行 -> 二、等待运行 -> 三、等待资源 -> 四、运行中 -> 五、成功或失败。

　（4）工做流状态机模型

　　　　针对数据任务节点在调度树中生成的工做流运行的不一样状态定义，一共有5种状态：一、建立工做流 -> 已建立 -> 运行中 -> 成功或失败 <- 是否重跑

　（5）调度引擎工做原理

　　　　以时间驱动的方式运行，为数据任务节点生成实例，并在调度树种生成具体执行的工做流。

　（6）执行引擎工做原理

         （不详细多说）

　（7）执行引擎的用法

             用户系统包括上文的工做流服务、数据同步服务，以及调度引擎生成的各种数据处理任务的调度服务。

 

　　下来咱们说一下实时，实时处理有别于离线处理。咱们知道，实时数据是来自于各个业务的日志服务器中，这些数据被实时采集到数据中间件中，供下游实时订阅使用。数据采集通常基于如下原则，按批次对数据进行采集：

　　一、 数据大小限制：当达到限制条件时，把目前采集到的新数据做为一批。

　　二、 时间阈值限制：当时间到达必定条件时，也会把目前采集到的新数据做为一批，避免在数据量少的状况下一直不采集。

　　随后呢，数据被采集到中间件后，须要下游实时订阅数据，并经过（推或拉）的方式到流式计算系统的任务中进行加工处理。

 　  基于Storm的实时数据处理应用，出于性能考虑，计算任务每每是多线程的，通常会根据业务主键进行分桶处理，而且大部分计算过程须要的数据都会放在内存中，会大大提升吞吐量。

 　  

　　一、 去重指标

　　在统计实时任务中，会产生大量的数据存储在内存中，计算逻辑通常都是内存完成的，中间结果数据也会缓存在内存中。那么就须要 布隆过滤器 和 基数估计

　　布隆过滤器：位数组算法的应用，不保存真实的明细数据，值保存明细数据对哈希值的标记位。

　　基数估计：按照数据的分散程度来估算现有数据集的便捷，从而得出大概的去重综合。

 

　　二、 数据倾斜

　　在数据量很是大的时候，单个节点的处理能力有限，必然会遇到性能瓶颈。这时就须要对数据进行分桶处理，分桶处理和离线处理的思路一致。

　　去重指标分桶：对去重值进行分桶Hash，相同的值必定会被放在同一个桶中去重，最后再把每一个桶里面的值进行加和就获得总值。

　　非去重指标分桶：数据随机分发到每一个桶中，最后再把每一个桶的值汇总，主要利用的是各个桶的CPU能力。

 

　　三、 事务处理

　　为了作到数据的精准处理，包括以下：

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

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

　　备份机制：开发人员须要保证内存数据能够经过外部存储恢复，所以在计算中用到的中间结果数据须要备份到外部存储中。

 

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

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

　　二、 最终结果数据：这些数据是实时更新的，写的频率很是高，能够直接被下游使用。

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

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

　　一、 表名设计

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

　　二、 Rowkey设计      

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

 

 　  四、数据回流

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

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

 

数据管理

 　一、元数据

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

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

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

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

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

　　 1.1 统一元数据建设

         元数据建设的目标是 打通 数据接入 到 加工，再到 数据消费 整个链路，规范元数据体系与模型，提供统一的元数据服务出口，保障元数据产出的稳定性和质量。包括：

　　（1）元仓底层数据：对元数据作分类，如计算元数据、存储元数据、质量元数据等，减小数据重复建设，保障数据的惟一性。

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

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

 

　　 1.2 元数据应用

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

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

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

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

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

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

　　（2）     元数据门户：

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

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

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

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

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

　　（4）     数据建模：

　　　　　　经过元数据驱动的数据仓库模型建设，能够在必定程度上提升数据仓库建模的数据化指导，提高建模效率。

　　　　　　所使用的元数据有：

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

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

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

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

　　（5）     驱动ETL开发：

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

　　

 　二、存储与成本治理

 　　　　大数据啊大数据，数据量太大了。。而后呢，因为业务形态的变换，不少已有的ETL任务所产出的业务表已经木有了业务价值。但每日跑批任务依旧会占用计算资源，同时增长现有分区的存储资源。那么咱们就以成本治理的角度，去干掉它！方法以下：

　　一、 数据压缩

        数据压缩主要采起archive压缩方法，对于Hadoop等分布式文件系统来讲，一般会将数据存储3份，经过file压缩，可将压缩比从1:3提升到1:1.5（具体要深刻研究）。

　　二、数据重分布

        主要采起基于列存储的方式，经过修改表的数据重分布，避免列热点，会节省必定的存储空间。通常会采用Distribute by 和 Sort by 的方式。

        数据重分布效果的波动比较大，主要跟数据表中字段的重复值、字段自己的大小、其余字段的具体分布有必定的关系，通常要筛选出重分布效果高于15%的表进行优化处理。

　　三、存储治理项优化

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

　　四、生命周期管理

       生命周期你管理的根本目的是 用最少的存储成本 来知足最大的业务需求，使数据价值最大化。

　 　　（1）     生命周期管理策略

　　　　　周期性删除策略：某些历史数据可能已经没有价值，且占用存储成本，那么针对无效的历史数据就能够进行按期清理。

　　　　　完全删除策略：无用表策略或者ETL过程产生的临时数据，以及不须要保留的数据，能够进行及时删除，包括删除元数据。

　　　　　永久保存策略：重复且不可恢复的底层数据和应用数据须要永久保存。

　　　　　极限存储策略：超高压缩重复镜像数据。

　　　　   冷数据管理策略：通常将重要且不可恢复的、占用存储空间大于100TB，且访问频次较低的数据进行冷备（例如3年以上的日志数据）。

　　　　  增量表merge全量表策略：对于对应的delta增量表的保留策略，目前默认保留93天。

　　　（2）     通用的生命周期管理矩阵

　　　　主要经过对历史数据的等级划分与对表类型的划分生成相应的生命周期管理矩阵。

　　　（3）     历史数据等级划分

　　　　主要将历史数据划分为P0、P一、P二、P3四个等级。

　　　　一、 P0：很是重要的主题域数据和很是重要的应用数据，具备不可恢复性，如：交易、日志、集团KPI数据、IPO关联表。

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

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

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

　　　（4）     表类型划分

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

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

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

　　　　四、 Merge全量表：包括业务过程性数据或者维表数据。因为数据自己有新增的或者发生状态变动，对于一样主键的数据可能会保留多份，所以能够对这些数据根据主键进行Merge操做，主键对应属性只会保留最新状态，历史状态保留在前一天的分区中。

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

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

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

　　 五、 数据成本计量

         　  任何一个计算任务都会涉及计算和存储资源的消耗，其中计算资源的消耗主要考虑CPU消耗，CPU消耗的单位定义为CU，表明一个核心(Core)运行一天的消耗量。

              在计量数据表的成本时，除了考虑数据表自己的计算成本、存储成本外，还要考虑对上游数据表的扫描带来的扫描成本。

　　六、 数据使用计费

        　  规范下游用户的数据使用方法，提高数据使用效率，从而为业务提供优质的数据服务。

 

　   三、数据质量

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

　　　　（1）     完整性

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

　　　　（2）     准确性

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

　　　　（3）     一致性

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

　　　　（4）     及时性

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

　　　　一、 数据质量方法概述

       　　　   针对数据质量的各个方面，都有相关的工具进行保证，以提升效能。

　　　　（1）     消费场景知晓：主要经过 数据资产等级 和 基于元数据的应用链路分析 解决消费场景知晓的问题。那么又引出 数据资产等级定义 和 数据资产等级落地方法

　　　　              数据资产等级定义：按照通常性和未执行，不一样性质的重要性依次下降包括：毁灭性质、全局性质、局部性质、通常性质、未知性质。

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

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

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

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

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

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

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

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

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

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

　　　　数据及时性包括：

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

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

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

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

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

　　　　　　二、数据质量事件：用来跟进数据质量问题的处理过程、用来概括分析找到数据出现问题的缘由、给出后续预防方案。

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