数据中台是什么？

数据中台是一套可持续“让企业的数据用起来”的机制，通过有形的产品和实施方法论，构建一套持续不断把数据变成资产并服务于业务的机制，数据来自于业务，并反哺业务，不断循环迭代，实现数据数据可见、可用、可运营，通过数据中台把数据变成一种服务能力，其目标是提供普惠的数据服务。本质就是数据仓库+数据服务中间件。

数据中台一般会具备4个能力：数据采集整合、数据提纯加工、数据服务可视化、数据价值变现。

数据采集整合：创建企业数据中台第一步，打破企业内部各个业务系统的数据隔阂，形成统一的数据中心，为后续数据价值的挖掘提供基础。主要通过数据采集和数据交换实现。
数据提纯加工：主要是对数据统一标准、补充属性，然后根据维度汇总成数据表、最后汇总出所需要的报表，满足企业对数据的需求。
数据服务可视化：对数据进行计算逻辑的封装，生成API服务，上层数据应用可以对接数据服务API，让数据快速应用到业务场景中。数据服务API对接的3种常见数据应用包括数据大屏、数据报表、智能应用。
数据价值变现：通过打通企业数据，提供以前单个部门或者单个业务部门无法提供的数据服务能力，为赋能前端应用、数据价值变现提供基础。

关于数据中台有以下几个功能特点：

1）数据中台具备数据汇聚整合、数据提纯加工、数据服务可视化、数据价值变现核心能力。
2）数据中台的核心就是实现公共计算逻辑下沉，实现数据复用，提供给接口使用。
3）数据中台不是某一个单一的产品或者某个技术。本质上讲数据中台就是从数据中发现价值，赋能业务数据管理机制。

数据中台的核心理念就在于数据取之于业务，用之于业务，它相对于数据平台注重的是对业务的积累和沉淀，构建了从数据生产到消费，消费后产生的数据再回流到生产流程的闭环过程。

数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用

数据中台出现的背景

为什么要构建数据中台呢？

1、烟囱式的开发模式

一个企业体量不大时，对于业务需求我们可以直接由底向上直接开发，由原始表深度加工产出一张表对外提供服务，针对不同的业务需求我们都这样实现，这就形成烟囱式开发，随着企业体量变大，业务变多，这种烟囱式开发会导致我们的数据无法复用，做很多重复的开发，这时我们可以构建一套数据分析平台，这里涉及数据采集、数仓构建、数据分析、数据可视化展示等，由于我们构建了统一数仓平台，几乎解决烟囱式开发问题。

但是当企业体量继续变大时，企业内部业务线增多，部门增多，由于一些公司内部组织架构的原因，可能会出现不同部门都会搞一套大数据平台，而这些部门之间有一些极其相似的业务，例如：淘宝业务线、聚划算业务线、天猫业务线都涉及交易信息统计、用户信息统计、用户活跃、流失、留存统计。每个大数据平台都会针对以上业务做相同业务的数据分析，各个部门使用了企业资源运行了大量相同的业务逻辑，设置各个业务部门之间需要进行数据交换关联时还需各个业务线领导牵头完成数据统一交换使用，那么站在全企业的角度来看各个业务部门之间这些相似的业务开发就是一个个的烟囱式开发，做不到相同业务合并处理，业务数据共用和复用。

对于烟囱式开发从企业角度来说相当于付出两倍的人力去研发同一件事情，从资源角度来说使用两倍的资源来加工相同数据，实际上烟囱开发效率是高的，但是烟囱多了，从全局角度看，效率是低的。

2、数据管理能力缺失

随着企业业务线增多，企业业务量和业务指标增多，在数据分析时对应任务和数据表也非常多，如果我们缺少了对这些任务和数据的管控能力，不清楚一个任务挂掉影响哪些数据表结果，不清楚每张数据表被哪些用户使用，当一张表数据量庞大到一定程度需要下线时不清楚这张表是否还在被使用？被哪些人在用？表中数据多久之前的数据可以被删除？由于对数据管理能力缺失导致一系列不可预估的问题。

3、缺少全链路数据治理监控

面对成千上百的数据表，在进行业务开发时，可能遇到很多相似的字段，例如：全量新增用户、新增用户两个相似字段由于区分不了两个字段代表意义，我们不清楚在业务中应该使用那个字段进行数据统计。

在某个数据处理流程中可能涉及到几十张表处理流程，当任意一张表出现问题都会导致下一个张表处理出现问题，当某张表出现问题时，需要逐层向上排查定位哪张数据表出现问题，这个过程会花费很长时间，尤其是这张表是上游链路中比较靠上的一张表时，需要对涉及到的所有流程需要任务重跑，故障恢复有需要花费很长时间，甚至有时候需要半天或者一天的时间，如果其他部门基于你的数据结果进行工作，不仅影响自己部门的产出还会影响到其他部门正常工作，例如数据运营部门。

对于数据使用方来说，数据质量非常重要，在数据分析时常常由于业务逻辑处理不严谨、数据清洗问题导致数据质量问题，如果很多业务有数据质量问题，对于数据质量问题定位也需要很多时间，往往数据开发人员被数据质量问题拖慢数据开发进度。

此外，数据安全也非常重要，对于数据建设中成千上百张表我们需要知道哪些表被哪些人访问了，哪些人有权限访问敏感数据表，访问哪些数据，对数据安全管理的忽视往往会给企业带来很大的风险。

4、成本粗放式管理

在做一些数据开发业务时，往往我们想的是快速的进行数据价值挖掘，而忽略了数据成本，结果导致有可能产出很多临时表和使用少量次的报表，这些使用少量次的表可能还会每天都在加工处理，但是有可能下游根本没有人在使用，导致线上资源出现大量浪费。

5、数据使用不灵活

当业务复杂时，报表展示的各类业务指标非常多，面对成百上千的表和指标，不能进行快速精准的业务数据定位，不能进行关键指标快速可视化展示。

以上几点原因总结下来主要有三个方面：

第一就是流程规范的缺失，我们没有一个很完善的流程、标准、规范来进行数据的研发，数据的管理，导致在使用数据的时候，出现了混乱失控的状态。
第二就是缺少平台工具支撑，当我们有了流程、标准和规范后，如何保证这些流程和规范高效的执行，这就需要一些平台工具进行支撑
第三就是组织架构分散，企业中构建了很多独立的小数仓平台根本原因是按照组织架构来分的，比如我们几个人是一个部门，我们就构建一个自己的数仓体系，他们是另外一个部门，他们就构建自己的一个数仓体系，这样一个庞大的企业中就会有 N 多个小数仓，当我们需要打通数据进行关联分析时，发现我们无能为力。

解决以上三个方面问题关键就是需要一套机制，通过这套机制整合企业数据，规范、快速的形成数据服务能力，为企业经营决策、精细化运营提供支撑，这套机制就是数据中台。

构建数据中台价值

1、提升数据应用能力

数据中台将海量数据转化为高质量的数据资产，为企业提供更深层的客户洞察，从而为客户提供更个性化和智能化的产品和服务。

2、打破数据应用屏障

在传统数据建设中，数据无法被业务使用，其中一个重要的原因是业务人员不够懂数据，导致数据应用到业务变得困难，数据分析人员不管业务，只是按部就班产出报表结果，以上情况导致数据分析结果不能很好地反哺到业务中，构建数据中台之后，数据分析人员将数据变成业务人员可阅读、易理解的内容，业务人员看到内容后很快可以将数据结合到业务中。

3、打破数据孤岛，盘活全量数据

数据中台构建将分散割裂的海量数据做到集成，打破数据孤岛的现状，同时降低使用数据服务的门槛，实现数据“越用越多”的价值闭环。

4、支持跨主题域访问数据

企业早期建设的应用数据层 ADS(传统数据仓库分为 ODS/DW/ADS)更多是为了某个主题域所服务，例如：营销域、人力资源域、风控域。而企业在数据应用到业务的时候往往需要打破各个主题，会从业务对象主体出发来考虑数据应用，如人（会员、供应商、渠道、员工）和物（商品、仓库、合同），从全域角度设计完整的面向对象的数据标签体系。

5、数据快速复用

传统的架构中，将分析后的数据应用到业务中，通常做法就是通过数据同步能力，把结果同步到业务系统中，由业务系统自行处理，这会带来数据管理问题，整个数据血缘链路是割裂的。数据中台可以很好的提供数据服务，业务系统只需要从数据服务中获取数据即可。

数据中台建设方法论

数据中台建设之数据标准

背景

在数据管理的模块域中，数据标准重要性非常之大，属于事前的整理。无规矩不成方圆，任何事物都需要有一套标准，基于这套标准去执行，才会清晰。没有数据标准通常会遇到的问题：

1.数据命名规范混乱，导致理解不一致，沟通成本高，数据同名不同义导致错误
2.没有清晰的元数据信息，导致数据共享、使用难、难以管理、数据来源不明

业务：通过对实体数据的标准化定义，可以解决数据不一致、不完整、不准确等问题，。通过对数据的标准化定义让数据在企业内有一个全局的定义，大大减少了各部门、各系统间的沟通成本。

技术：统一、标准的数据及数据结构是企业信息共享的基础；标准的数据模型和标准数据元为新建系统提供支撑，提示应用开发的实施效率；很大程度上数据质量管理都是依赖于数据标准，在数据标准之上才能定义数据质量。

管理：通过数据的标准化定义，明确数据的责任主体，为数据安全、数据质量提供保障；

数据标准的使用场景

建立统一的数据视图：建立通用的元模型规范，支持用户自定义扩展，对多源异构数据表进行信息抽象提取，形成统一的元数据层。所有的数据开发完成后发布到数据标准维护的统一的数据目录，通过不同维度的数据目录进行多维筛选，满足各类用户的检索需要，达到资产的可管、可用、可查的目标。
建立统一的数据认知：通过对多源异构数据的标准化描述，就算数据在不同系统的称呼千奇百怪，但是至少流入大数据的场景后就会统一描述，使管理方、开发方、使用方统一认知。
建立质量审核体系：在数据标准统一的前提下，我们就可以基于标准的元数据信息，进行质量的监控和审核，提升数据质量，更大化的体现数据价值
面向未来的数据治理：工具的终极目的都是为了降本提效。效率的提升要依靠流程规范，流程主够规范，在某种程度上就可实现流程自动化流转，所以数据治理如果要成为流程自动化、阶段智能化的阶段，那么就需要数据标准的支持。

数据标准的定义和分类

数据标准就是通过制定一套由管理制度、管控流程、技术工具共同组成的体系，来对数据定义、分类、格式、编码等标准化管理。通俗地讲，对企业来说，数据标准就是对数据类型、长度、归属部门等定义一套统一的规范，以保障不同业务系统之间可以做到对同样的数据理解统一和使用统一。数据标准不是形成各种文档，而是形成规范文档后要落地。数据标准是保障数据内外部使用和交换一致性和准确性的规范性约束。数据标准管理是用来规范数据标准制定和实施的活动。数据标准是进行数据标准化输出的主要依据，构建一套完整的数据标准体系是开展数据标准管理工作的基础，有利于底层互通、提升可用性 “数据标准”并非是一个专有名词，而是一系列“规范性约束”的抽象。

数据标准的定义要遵循六大原则：数据标准分类：一般数据标准分类：

基础数据标准
指标类数据标准 数据标准命名规范 数据标准设计流程 数据标准体系建设流程
1.制定目标和界定范围

首先，第一步是组织需要制定数据标准目标，需要达到什么水平，数据标准管理要达到到什么程度，战略方向目的要明确。接着我们需要界定数据标准的范围，根据企业自身的管理和业务发展需求制定数据标准，比如业务场景需求，管理需求，产品功能需求等，制定客户标准，产品标准等。

2.数据标准调研

第二步，组织需要对整个组织的数据标准管理情况进行调研和汇总。通过调研企业数据标准现状，弄清哪些系统的数据标准问题比较严重，哪些字段不符合标准，为后续的数据标准落地提供支撑和指导。数据标准管理调研，通常有3个步骤;

第一步，用调研表的方式，去调研企业内部组织标准，名称规范情况，业务系统表等情况
第二步，分析收集的资料问题，与国标，行标，企业内部需求标准进行对比
第三步，制定数据标准落标策略，比如哪些标准非强制，哪些是强制的，对哪些字段，表名称需要进一步统一。

3.明确组织和流程

把数据标准目标与企业内部情况了解后，第三步，企业需要明确组织和管理流程制度，这样才能使数据标准项目推进落实。

（1）数据标准管理角色制定
数据标准管理组织：是数据标准治理项目的重要推手，不可或缺，很多企业的数据治理项目失败，就是没有相应的组织推动，最后不了了之。
数据标准管理角色：通常有数据治理管控委员会，数据标准管理岗，数据标准管理专员，IT项目组这4个。
数据治理管控委员会：是组织领导层承担的，主要目的是领导各个部门的工作，负责组织协调和推进，落实监督的作用。
数据标准管理岗：是由IT部门负责人担任，需要总体协调和管理数据标准工作，负责数据标准项目的工作开展。
数据标准管理专员：是由各个业务部门业务员担任，主要作用是对数据标准的执行，根据实际情况，提出优化新的变更需求。
IT项目组：是由企业内部的IT项目人员造成，主要负责数据标准落地执行，也是需求提出方。
企业可根据自己实际情况，灵活调整组织架构，制定出适合自身的数据标准管理部门。
（2）管理流程制度制定
确定了数据治理相关组织人员后，接下来企业需要结合自身实际业务和管理场景，制定相应的管理流程制度。
常见管理流程有：
①标准变更流程。如果数据标准发生变化，相应的变更申请，审批，通过的流程制度是什么。
②标准落地执行。标准制定后，是如何随着业务，技术，管理流程落实到具体的场景需求上。
③数据标准管理制度。平时数据标准是如何管理，什么时候检核，什么时候定期分析管理效果，如何提出完善修改建议等。

4.数据标准编制与发布

治理目标，企业内部调研，组织架构和流程制度搭建好后，第四步，就是企业需要根据实际情况，制定自己的数据标准，并且发布使用到具体的管理，业务场景中。

数据标准编制，通常有4个步骤：

（1）制作数据标准管理文档
第一步，收集国标，行标要求，并且结合企业自身管理和业务要求，形成自己独特的数据标准管理文档。
（2）制定初版数据标准
企业业务和管理需求与IT数据管理岗协调沟通，制定出初版的数据标准管理文档。
（3）数据标准审核
数据管理专员，逐条与数据标准管理部门讨论，是否符合数据标准，是否能落标，是否符合业务发展等，从多个角度对标审核，最终得到定版标准。
（4）定版数据标准发布
标准制定好后，我们需要向数据治理委员会汇报定版标准，内部发布，收集反馈，以及后续对数据标准进行维护和更新。

5.数据标准宣贯

数据标准定版后，企业需要向内部组织一场数据标准的宣贯会。宣贯会主要有3个目的：

①阐述数据标准的意义和价值，提升企业内部人员对数据标准管理的重视程度
②数据标准管理方法的宣贯，研读管理方法，为后续数据标准提供制度依据
③数据标准的落标培训，提高使用人员的熟练度，让数据标准可以更好更快实行，发挥价值

6.数据标准平台落地运营

宣贯会结束后，最后一步就是数据标准在数据标准平台进行落地，主要分为4个步骤：

（1）数据标准录入
第一步，企业需要把已经制定好的数据标准，直接录入到相应的数据标准平台系统。
（2）数据标准评估
系统用新的数据标准，应用于之前陈旧的数据中，测试数据效果是否明显。通过管理，技术，业务的维度查看效果，进行适当修改后，满足大部分要求后，投入使用到实际场景中。
（3）数据标准效果跟踪
企业需要定期评估，持续跟踪数据标准管理的落地情况，它是否提高了企业运营管理效率，为业务辅助做提升。
（4）最后就是数据标准管理的日常运营提升。
数据使用人员通过不断深入接触到新的场景和需求，数据标准需要新增，修改，删减，变更等，不断完善，达到更加适应企业管理经营的目的。

数据标准落地方案关键性分析

数据中台建设之元数据管理

元数据

元数据分类

在数据中台领域中，一般将元数据划为三类：数据字典、数据血缘和数据特征。

数据字典：诸如表名、注释信息、表的产出任务、表字段信息、含义和字段类型等，描述数据的结构信息（如图）；
数据血缘关系：描述表的继承关系，由哪些表经过哪些计算任务得到的。数据血缘一般会帮我们做影响分析和故障溯源。比如有一天，你的老板看到某个指标的数据违反常识，让你去排查这个指标计算是否正确，你首先需要找到这个指标所在的表，然后顺着这个表的上游表逐个去排查校验数据，才能找到异常数据的根源。
数据特征：数据的属性，比如存储空间大小、访问热度、主题域、分层、表关联指标等（如图）。在实际的业务场景中，元数据的种类非常多，因此，为了管理这些元数据，此时必须要构建一个元数据中心

元数据中心

数据血缘

数据血缘要素

数据血缘关系一般由数据节点、数据流转路径、数据流转规则构成，它们在血缘关系中以直接或间接可见的方式标志血缘信息。

1）数据节点

数据节点是有独立数据功能业务的载体，体现了数据的业务属性与存储位置。从广义上来说，数据库、数据表、数据字段都是数据节点；在实际运用中，一般使用元数据信息作为区分数据节点的依据，每个数据节点都有唯一的身份标识。同时，每个节点在血缘图中都占有一定的比重，比重越高的节点，对整个数据网络的影响越大。数据节点分为以下三类：

数据流出节点：用于提供最基础的数据，一般是底层源数据中间节点：是数据血缘关系中类型最多的节点，既承接流入的数据，又向流入节点提供数据数据流入节点：是整个数据血缘的终端节点，承接中间节点流入的数据后，不再往下流转。数据流入节点的数据一般即业务系统的输出，用作可视化报表或者仪表板展示；在少数情况下，会对其他业务系统进行数据反哺

2）数据流转路径

数据流转路径通过表现数据流动方向、数据更新量级、数据更新频率三个维度的信息，标明了数据的流入流出信息：

数据流动方向：通过箭头的方式表明数据流动方向数据更新量级：数据更新的量级越大，说明数据的重要性越高数据更新频率：数据更新的频率越高，说明数据的变化越频繁，重要性越高

3）数据流转规则

数据流转规则体现了数据流转在过程中发生的变化以及如何成为其他实体的构成部分，每一条数据流转路径都可以包含一个或者多个流转规则，用户通过查看流转路径，可查看该段流转路径的规则，规则可以是直接映射关系，也可以是复杂的规则，例如：

数据映射：不对数据做任何变动，直接抽取
数据清洗：由于各个节点对数据质量的要求不同，数据需要基于一定的数据标准流入实体，通过数据清洗的方式表现数据流转过程中的筛选标准。例如要求数据不能为空值、符合特定格式等
数据转换：数据流转过程中，流出实体的数据需要进行特殊处理才能接入到数据需求方
数据预警：针对数据检测规则，一旦触发预警阈值，就以特定方式进行报警，并对整条数据流转路径上的节点自动进行关联检测

血缘的应用场景

在讨论技术细节之前，需要先讲清楚血缘的应用场景与业务价值，进一步明确数据血缘需要解决的问题。不同的应用场景，对于血缘数据的消费方式，血缘的覆盖范围，血缘的质量诉求，都会有所差别。

血缘采集，一般可以通过三种方式：

第一，通过静态解析 SQL，获得输入表和输出表；
第二，通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表；
第三，通过任务日志解析的方式，获取执行后的 SQL 输入表和输出表。

第一种方式，面临准确性的问题，因为任务没有执行，这个SQL对不对都是一个问题；第三种方式，血缘虽然是执行后产生的，可以确保是准确的，但是时效性比较差，通常要分析大量的任务日志数据。因此，第二种方式，相对是比较理想的实现方式。

开源的几种数据血缘工具选型建议？

# Atlas
Atlas的优点：
大厂开源，深度集成Hadoop生态中的Hive，支持表级、字段级血缘
与HDP原生集成，支持对接Ranger实现行列级数据权限管控，安装便捷省心
强大的元数据元模型，支持元数据定制及扩展
源代码不复杂，国内有大量平台基于Atlas定制修改为商用产品
Atlas的不足：
其优势也是劣势，母开源公司已被并购，历史悠久，不再是一种优势，反而是一种负担
Hadoop体系已经走向衰退，如何只是完美支持Hive和Hadoop体系，已经无法满足现在快速发展的技术要求
其设计界面复杂，体验老旧、数据目录及数据检索都不够便捷
使用体验复杂及产品功能更聚焦于解决技术人员的问题，而非数据的最终用户，比如业务人员
生态渐渐失去新鲜感、新的类似平台不断发展
选型建议：
1）如果您只有Hadoop生态，可以试试。
2）如果您的数据资产是面向数据团队的技术人员，可以试试。
# Datahub
Datahub的优点：
名门开源，与Kafka同家庭。社区活跃，发展势头迅猛，版本更新迭代迅速。
定位清晰且宏远，Slogan可以看出团队的雄心壮志及后期投入，且不断迭代更新的版本也应证了这一点。
底层架构灵活先进，未扩展集成而生，支持推送和拉去模式，详见：https://datahubproject.io/docs/architecture/architecture/
UI界面简单易用，技术人员及业务人员友好
接口丰富，功能全面
Datahub的不足：
前端界面不支持国际化，界面的构建和使用逻辑不够中国化
版更更新迭代快，使用后升级是个难题
较多功能在建设中，例如Hive列级血缘
部分功能性能还需要优化，例如SQL Profile
中文资料不多，中文交流社群也不多
选型建议： 
1）如果有至少半个前端开发人员+后台开发人员； 
2）如果需要用户体验较好的数据资产管理平台； 
3）如果有需要扩展支持各种平台、系统的元数据。请把Datahub列为最高选择。 尽管列举了一些不足，但是开源产品中Datahub目前是相对最好的选择。笔者也在生产中使用，有问题的可以随时沟通交流。

对于Hive计算引擎，Atlas通过Hook方式，实时地捕捉任务执行计划，获取输入表和输出表，推送给Kafka。由一个Inges模块负责将血缘写入JanusGraph 图数据库中，然后通过 API 的方式，基于图查询引擎，获取血缘关系；对于Spark，Atlas提供了Listener的实现方式。此外，Sqoop、Flink也有对应的实现方式。

在对比完以上两款产品后，接下来，我们搭建元数据中心。

在搭建之前，需要明确元数据中心实现的五个关键目标：

第一，多业务线、多租户支持。电商、短视频、内容推送等都是不同的业务线，同一个业务线内，也分为算法、数仓、风控等多个租户，因此，元数据中心必须支持多业务线、多租户。
第二，多数据源的支持。元数据中心必须要能够支持不同类型的数据源，同时还要支持相同数据源的多个集群。为了规范化管理，还需要考虑将半结构化的KV 也纳入元数据中心的管理（比如Kafka、Redis、HBase等）。这些系统本身并没有表结构元数据，因此，需要能够在元数据中心里定义Kafka中每个Topic的每条记录JSON中的格式，每个字段代表什么含义。
第三，支持字段级数据血缘查询。元数据中心需要支持数据血缘的实时采集和高性能的查询，与此同时，查询必须支持字段级别的血缘。字段血缘在做溯源的时候非常有效。因为大数据加工链路的下游是集市层，为了方便使用者使用，一般都是一些很宽的表，俗称“大宽表”。这个表的上游可能是有几十个表产生的，如果不通过字段血缘限定溯源范围，就会导致搜索范围变得很大，无法快速地精准定位到有问题的表。此外，数据血缘还必须要支持生命周期管理，已经下线的任务，如果没有继续被调度，过期的血缘关系应该予以清理。
第四，与大数据平台集成。元数据中心需要与Ranger集成，实现基于tag的权限管理方式。在元数据中心中可以为表定义一组标签，Range可以基于这个标签，对拥有某一个标签的一组表按照相同的权限授权。这种方式大幅提升了权限管理的效率。例如，对于会员、交易、毛利、成本，可以设定表的敏感等级，然后根据敏感等级，设定不同的人有权限查看或编辑。此外，元数据中心作为基础元数据服务，包括自助取数分析系统，数据传输系统，数据服务，都应该基于元数据中心提供的统一接口获取元数据。
第五，支持对表和表中的字段打标签。通过丰富的不同类型的标签，可以完善数据中台数据的特征，比如指标可以作为一种类型的标签打在表上，主题域、分层信息都可以作为不同类型的标签关联到表。

基于以上五个目标，搭建的元数据中心如下：这个图按照功能模块分为数据血缘、数据字典和数据特征。

数据血缘由采集端、消息中间件、消费端以及血缘清理模块组成。基于Hive Hook，Spark Listener，Flink Hook可以获取任务执行时输入表和输出表，推送给统一的消息中间件（Kafka），然后消费端负责将血缘关系沉淀到图数据库中。

图数据库选择Neo4j，主要考虑是性能快、部署轻量化、依赖模块少，当然，开源的Neo4j没有高可用方案，并且不支持水平扩展。但是，因为单个业务活跃的表规模基本也就在几万的规模，所以单机也够用，高可用可以通过双写的方式实现。

此外，血缘还有一个清理的模块，主要负责定时清理过期的血缘，一般可以把血缘的生命周期设置为7天。

数据字典部分，参考Metacat实现，由一个统一的 Connector Mananger负责管理到各个数据源的连接。对于Hive、MySQL元数据中心并不会保存系统元数据，而是直接连数据源实时获取；对于Kafka、HBase、Redis等KV，在元数据中心里内置了一个元数据管理模块，可以在这个模块中定义Value的schema信息。

数据特征主要是标签的管理以及数据的访问热度信息。元数据中心内置了不同类型的标签，同时允许用户自定义扩展标签类型。指标、分层信息、主题域信息都是以标签的形式存储在元数据中心的系统库里。同时，元数据中心允许用户基于标签类型和标签搜索表和字段。此外，元数据中心统一对外提供了API访问接口，数据传输、数据地图、数据服务等其他的子系统都可以通过API接口获取元数据。最后，Range可以基于元数据中心提供的API接口，获取标签对应的表，然后根据标签更新表对应的权限，实现基于标签的权限控制。

血缘衡量指标

实际推广血缘时，最常被用户问到的问题就是，血缘质量怎么样，他们的场景能不能用。面对这种灵魂拷问，每个用户都单独评估一遍的开销过大，所以我们花了很多精力讨论探索出了最常用的三个技术指标，以佐证血缘质量。用户可以根据这些指标，判断自己的场景是否适用。

01 - 准确率

定义：假设一个任务实际的输入和产出与血缘中该任务的上游和下游相符，既不缺失也不多余，则认为这个任务的血缘是准确的，血缘准确的任务占全量任务的比例即为血缘准确率。准确率是用户最关注的指标，像数据开发的影响分析场景，血缘的缺失有可能会造成重要任务没有被通知，造成线上事故。

不同类型的任务，血缘解析的逻辑不同，计算准确率的逻辑也有区别：

SQL 类任务：比如 HiveSQL 和 FlinkSQL 任务，血缘来源于 SQL 的解析，当 SQL 解析服务给出的质量保证是，成功解析的 SQL 任务，产生的血缘关系就一定是准确的，那么这类任务的血缘准确率，就可以转化成 SQL 解析的成功率。
数据集成（DTS）类任务：比如 MySQL->Hive 这类通道任务，血缘来源于对用户登记上下游映射关系的配置，这类血缘的准确率，可以转化成对于任务配置解析的成功率。
脚本类任务：比如 shell，python 任务等，这些血缘来源于用户登记的任务产出，这类血缘的准确率，可以转化成登记产出中正确的比例。注意一个问题，上面所讲的准确率计算，转化的时候都有一个前提假设，是程序按照我们假定的方式运行，实际情况并不一定总是这样。其实这件事情没必要特别纠结，血缘就像我们在运行的其他程序一样，都可能因程序 bug，环境配置，边界输入等，产生不符合预期的结果。

作为准确率的补充，我们在实践中通过三种途径，尽早发现有问题的血缘：

人工校验：通过构造测试用例来验证其他系统一样，血缘的准确性问题也可以通过构造用例来验证。实际操作时，我们会从线上运行的任务中采样出一部分，人工校验解析结果是否正确，有必要的时候，会 mock 掉输出，持续运行校验。
埋点数据验证：字节中的部分存储会产生访问埋点数据，通过清洗这些埋点数据，可以分析出部分场景的血缘链路，以此来校验程序中血缘产出的正确性。比如，HDFS 的埋点数据可以用来校验很多 Hive 相关链路的血缘产出。
用户反馈：全量血缘集合的准确性验证是个浩瀚的过程，但是具体到某个用户的某个业务场景，问题就简化多了。实际操作中，我们会与一些业务方深入的合作，一起校验血缘准确性，并修复问题。

02 - 覆盖率

定义：当至少有一条血缘链路与资产相关时，称为资产被血缘覆盖到了。被血缘覆盖到的资产占关注资产的比例即为血缘覆盖率。

血缘覆盖率是比较粗粒度的指标。作为准确率的补充，用户通过覆盖率可以知道当前已经支持的资产类型和任务类型，以及每种覆盖的范围。

在内部，我们定义覆盖率指标的目的有两个，一是圈定出我们比较关注的资产集合，二是寻找系统中缺失的整块的任务类型。

以 Hive 表为例，字节生产环境的 Hive 表已经达到了几十万级别，其中有很大一部分，是不会被长期使用与关注的。计算血缘覆盖率时，我们会根据规则圈选出其中的部分，比如，过去 7 天有数据写入的，作为分母，在这之上，看血缘覆盖率是多少。

当血缘覆盖率低时，通常说明我们漏掉了某种任务类型或者圈选的资产范围不合理。举个例子，在初期时，我们发现 MQ 的血缘覆盖率只有个位数，分析后发现，我们漏掉了以另外一种格式定义的流式数据集成任务。

03 - 时效性

定义：从任务发生修改，到最终反应到血缘存储系统的端到端延时。

对于一些用户场景来说，血缘的时效性并没有特别重要，属于加分项，但是有一些场景是强依赖。不同任务类型的时效性会有差异。

数据开发领域的影响分析场景，是对血缘实时性要求很高的场景之一。用户在圈定修改的影响范围时，如果只能拉取到昨天为止的状态，是会产生严重业务事故的。

提升时效性的瓶颈，通常不在血缘服务方，而是任务管理系统是否可以近实时的将任务相关的修改，以通知形式发送出来。

数据地图

数据地图是对整个数据中台内的数据进行统一查询、管理的“地图”，数据地图主要面向数据开发者，汇聚用户所有数据信息，通过元数据信息收集、数据血缘探查、数据权限申请授权等手段，帮助数据中心专有云完成数据信息的收集和管理，解决"有哪些数据可用"、"到哪里可以找到数据"的难题，并且提升数据资源的利用率。

数据地图最核心的功能有两个：元数据信息的展示、血缘关系。

数据地图提供了多维度的检索功能，使用者可以按照表名、列名、注释、主题域、分层、指标进行检索，结果按照匹配相关度进行排序。考虑到数据中台中有一些表是数仓维护的表，有一些表数仓已经不再维护，因此在结果排序时，我们增加了数仓维护的表优先展示的规则。数据地图还提供了按照主题域、业务过程导览功能，可以帮助使用者快速了解当前有哪些表可以使用。

数据中台建设之数据模型

建模流程

数据模型层次设计

数据分层架构主要包含三个层次。

1. 贴源层：ODS（Operational Data Store）操作型数据存储层
面向业务的原始溯源性，贴原从业务系统引入并组织数据。
2. 中间层：CDM（Common Data Model）公共数据模型层
面向业务通用性，易用性、复用性，组织公共通用明细数据与汇总数据。包括三种
类型数据：
• DWD（Data Warehouse Detail）：明细类数据事实表
• DWS（Data Warehouse Summary）：汇总类数据事实表
• DIM：维度表
3. 应用层：ADS（Application Data Service）应用数据服务层
面向业务应用视角组织数据，一般是面向产品、业务场景进行公共数据组合与个性
化计算。

下图右边以淘宝为例，列举淘宝三个核心 Project（tbads、tbcdm、tbods） 数据模型建设关键步骤：

1：需求调研：

需求调研分为自底向上和自顶向下两种，自底向上是从现有的业务系统入手，从业务上分析数据域、业务过程，了解数据需求。自顶向下是和实际报表使用人员了解需求，依据报表 SQL 反向推导所需的数据源及指标信息。

1) 业务调研
业务调研的流程分三个步骤：
• 输入调研模板。
• 针对产品和运营进行调研。
• 归纳产出：业务过程&数据域。

下图举例说明业务调研的流程：

2) 需求分析
需求分析的三个步骤：
• 输入调研模板，研究报表&数据体系。
• 与分析师&运营讨论收集信息。
• 归纳产出：指标体系

3) 数据调研
数据调研需要做好数据探查工作，需要了解数据库类型，数据来源，全量数据情况及数据每年增长情况，更新机制；还需要了解数据是否结构化，是否清洗，是接口调用还是直接访问库，有哪些类型的数据，数据结构之怎样的。
• 数据开发，模型建设之前，先了解数据结构，数据内容，数据特性，对数据有一个整体把控
• 探查一下本次需求能不能实现，怎么实现，有没有隐藏bug，数据质量如何

2:数据域的划分

数据分域分为三个步骤：收集、提炼、归纳。

收集：业务数据需求、存量数据梳理

核心目的：对现有数据和业务诉求需要的数据进行 merge，保障数据仓库的完整性，形成数据全集。
核心对象：分析师、业务运营人员、数仓开发者。
核心输出：粒度、维度、数据指标、使用场景等信息。

提炼：业务过程、业务梳理

业务过程：指企业的业务活动行为，如点击、浏览、下单等，业务过程是一个不可拆分的行为事件。

核心目的：对收集的数据全集，进行业务关键词（包括业务过程、业务元素）提炼，根据经验罗列分类。
核心对象：数据模型架构师。
核心输出：业务过程、业务元素列表。

归纳：数据域

数据域：面向业务，根据业务过程进行分类，组合抽象而成的数据集合。数据域不能轻易变动，在划分数据域时，既能覆盖当前所有的业务场景数据，又能在新业务进入时被融入，或对整体架构无影响下的扩展新数据域。

核心目的：对业务过程、业务元素的列表进行抽象，尽量避免边界模糊不清，归纳出数据域名称。
核心对象：数据模型架构师。
核心输出：数据域大图，包括核心业务过程与元素的包含关系。

下图用实例来介绍数据分域过程中如何进行收集、提炼和归纳：

3：总线矩阵

是一种在全局视角理解数据结构的一种工具，可以让相关人员对整个数仓结构能够有清晰了解，很容易就能看出来数据域与业务过程、维度的关系；以及业务过程与维度的关系。

由业务过程和维度的关联关系构成的表格，就称之为总线矩阵，可以很清晰的看出： • 业务过程与维度的关系：方便我们在开发时对照需要冗余的维度属性。 • 数据域与业务过程/维度的关系：方便开发时就做好数据资产的归类，便于后续复用。

4：明确统计指标
5：规范定义

业务分类
分层划域规范
业务过程
存储策略
表命名规范
表生命周期
指标时间周期
一致性维度
词根规范
码值管理

一致性维度

# 维度及维度属性
在总线矩阵下，维度必须归属某一个数据域，维度属性的来源一种是源系统，一种是挖掘计算，如最近一次支付时间。
# 特殊维度
杂项维度：将事实表中的状态、分类等字段定义为维度，比如交易订单、物流单中的状态等均可称杂项维度。
行为维度：基于历史事实构建，如会员最近一次支付时间就是一个行为维度，可作为其父维度会员维度的维度属性，不建议单独创建维度。
# 维度整合和拆分
• 维度整合
同一业务板块下同维度不同属性信息可整合，如会员维度基本属性、星级等信息。
不同业务板块同维度信息可整合，如天猫淘宝基本会员信息。
• 维度拆分
同一维度不同分类的属性，差异较大或业务关联度不大的信息，如不同业务板块的商品维度可拆分成不同维度表。
每个商品会有主属性（形状、颜色、价格，等）和扩展属性，比如有些产品的一个扩展属性是带电的，那么在物流业务上就会有相应的限制，因此需要
根据其业务属性拆分到不同维度表。从产出时效、易用性考虑垂直拆分出主商品维表和商品维度扩展表。
比如“跨境十日达”商品，会根据其业务属性划分维度属性，并放入维度扩展表。
# 命名规则
命名规则尽可能使用英文简写。
若英文简写过长，可考虑拼音首字母简写，如：商品 itm，商家 slr，买家 byr。

一致性度量

基本原则

度量必须归属某一个业务过程。
度量类型：一般是数值，所以在定义数据类型时候一般为数字类型，同时需要和维度属性做区别。
度量分类：按照事实的是否可加性分为：可加性度量、半可加性度量、不可加度量

命名规则

尽可能使用英文简写。
当英文简写很长可以考虑汉语拼音首字母的简写，但一般要保持整个数仓一致性，所以尽可能选择一种命名缩写规则，如：数量 cnt、金额 amt。

指标规范（...省略）

6: 模型设计 层级设计规范

dwd层（明细事实表）设计原则：
通常，一个明细粒度事实表仅和一个维度关联。
尽可能包含所有与业务过程相关的事实 。
只选择与业务过程相关的事实。
分解不可加性事实为可加的组件。
在选择维度和事实之前必须先声明粒度。
在同一个事实表中不能有多种不同粒度的事实。
事实的单位要保持一致。
谨慎处理Null值，建议用0填充。
使用退化维度提高事实表的易用性。
dim层在设计公共维度表时需要考虑：
1：维表中数据的稳定性。
例如，A公司电商会员通常不会出现消亡，但会员数据可能在任何时候更新，此时要考虑创建单个分区存储全量数据。如果存在不会更新的记录，您可能需要分别创建历史表与日常表。日常表用于存放当前有效的记录，保持表的数据量不会膨胀；历史表根据消亡时间插入对应分区，使用单个分区存放分区对应时间的消亡记录。
2：维表是否需要垂直拆分。
如果一个维表存在大量属性不被使用，或由于承载过多属性字段导致查询变慢，则需要考虑对字段进行拆分，创建多个维表。
3：维表是否需要水平拆分。
如果记录之间有明显的界限，可以考虑拆成多个表或设计成多级分区。
4：核心维表的产出时间。通常有严格的要求。
5：维度属性尽可能的齐全
dws层（公共汇总事实表）设计原则：
1：数据公用性 
比如，汇总的聚集表能否与他人公用？基于某个维度的聚集是否是数据分析或者报表中经常使用的？如果满足这些情况，我们就有必要把明细数据沉淀到汇总表中。
2：不跨数据域
数据域是在较高层次上对数据进行分类聚集的抽象，如交易统一划到交易域下，商品的新增、修改放到商品域下。
3：区分统计周期
表命名上要能说明数据的统计周期，如_1d 表示最近1天，_td 截止到当天，_nd 表示最近N天。
4：避免多个层级的数据
应该避免将不同层级的数据放在一起，比如，如果存在7天和30天的事实，我们可以选择用两列存放7天和30天的事实，但是需要在列名和字段注释上说明清楚。同时我们也可以使用两张表分别存储不同统计周期的数据加以区分。
5：聚集是不跨越事实的
聚集是针对原始星型模型进行的汇总，为了获取和查询原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此聚集是不跨事实的。横向钻取(交叉探查)是针对多个事实基于一致性维度进行的分析，很多时候采用融合事实表，预先存放横向钻取的结果，从而提高查询性能。因此融合事实表是一种导出模式而不是聚集。
DM（ADS）层规范：
集市划分的原则有以下两点：
• 原则一：以业务场景或者服务对象作为划分原则，对相似数据业务场景内聚抽象进行分类。
• 原则二：集市划分需要统一标准，尽量符合 MECE 原则。
公共层的核心原则设计：
• 原则一：公共层开放共建，事后审计治理
应用开发整理需求，把需要下沉的公共维度提给公共层研发，公共开发需求评估。
• 原则二：以应用需求驱动，设计开发共建
以需求为驱动，拆分出核心模型和非核心。模型，核心模型公共研发负责，非核心模型由业务开发进行，共同开发以提高效率。
• 原则三：公共层研发统一运维保障
非核心模型上线并完成相关测试（准确性、确定性、治理）后转交给公共层研发，由公共层统一运维。

数据模型管理

数据模型管理，主要是为解决架构设计和数据开发的不一致性，是为了约束平台使用者的表名、字段名的规范性，架构师从工具层合理的进行模型分层和统一开发规范，包括2部分，一个是规则配置，另一个是对表名、字段名的定期校验。

规则配置：可以配置表名必须由哪几个元素组成，比如表名=数据仓库所属层级+表所属主题+数据更新周期+增量/全量，按照这个规则，表名就会是dws_sale_channel_day_full，这样的话，这张表是做什么的就一目了然了。
定期校验：可以对表名、字段名做定期校验，告诉你哪些表、哪些字段是不符合要求的，这样的话，平台长期运营下去，依然会处于比较健康的状态。 数据模型生命周期 数据模型衡量标准

数据中台建设之数据质量

整体框架 在实际生产中，数据计算任务没有告警，但不代表数据就是正确的，比如源数据异常、代码逻辑修改等原因都会造成结果数据错误。数据质量就是保障数据正确性的工具，主要包括这么几部分：一是支持准确性校验规则，二是支持双表校验，三是输出校验报告。

数据质量的八个维度指标

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

关键流程：

质量监管平台建设实践应用及价值体现，离不开管理流程、技术实现和组织人员的紧密结合，主要包含如下8大流程步骤：

质量需求：发现数据问题；信息提报、收集需求；检核规则的需求等。
提炼规则：梳理规则指标、确定有效指标、检核指标准确度和衡量标准。
规则库构建：检核对象配置、调度配置、规则配置、检核范围确认、检核标准确定等。
执行检核：调度配置、调度执行、检核代码。
问题检核：检核问题展示、分类、质量分析、质量严重等级分类等。
分析报告：数据质量报告、质量问题趋势分析，影响度分析，解决方案达成共识。
落实处理：方案落实执行、跟踪管理、解决方案Review及标准化提炼。
知识库体系形成：知识经验总结、标准方案沉淀、知识库体系建设。

一个标准的数据质量管理平台 常见数据质量监控规则 数据质量建设保障方案

设立负责人：

首先需要设立一个负责人，主要职责是问题确立、制定规范、推进执行、落地解决等。其他人负责配合其完成相关工作。

建立完整的保障机制：按照事前，事中，事后三个方面来设立规范。每个方面都要有相应的保障机制，和处理办法。

1：事前预防控制：

事前，通过圈定数据质量范围，制定研发各个环节的质量规范，把95%可能的数据质量问题把控在事前。

1）测试验证
测试验证方法如下：
    总量核对，核对上下两步的数据总条数，没有过滤条件的话应该是一致的。
    多维度统计，复杂的多维度指标拆分成单维度SQL统计，对每个指标分别进行核查。
    多表关联统计，拆分成中间表进行核对每一步骤的指标。
    明细到指标统计，比如随机找一台车的明细和最后统计的指标进行核对。
    新老统计对比，比如有些指标是迁移或者之前业务手工制作，可以开发后的新指标同老指标进行对比。
测试需要有专门的数据测试人员进行测试，输出测试用例和测试报告。
2）上线审核
需要对上线的SQL代码进行审核，主要从以下几个方面：
    对查询表的where后面的条件、join关联字段、group by分组字段等重点检查逻辑，和需求理解结合审核。
    数据集命名、数据集字段命名、任务名称进行审核，是否按照数据仓库建设规范中的业务域、维度、原子指标、修饰类型、修饰词、时间周期、派生指标等标准进行命名。
    代码注释审核，每一步处理需要有注释该步骤的作用，每个指标也要有注释，where条件等也要添加注释。
    重要任务是否开启短信告警，任务启动时间等审核。
    任务上线的位置是否符合上线标准，比如上线的数据层级与业务层级等。
    上线审核需要审核人员按照以上步骤进行审核，对不合理的地方进行指正，审核人员和开发人员共同保障代码质量。
3）流程规范
    需求上线时候需要在知识库中完成所开发需求逻辑说明
    复杂需求（比如项目指标），需要团队至少两人以上评审需求后开发。
    提交上线申请的同事需要备注上需求逻辑说明。
    审核上线人员为“轮值”，审核上线人员需要review开发人员的代码，需要和开发人员共同承担代码质量

2、事中监控数据质量

事中，针对数据进行数据质量监控，及实地发现质量风险点。

强化源头数据质量：可以通过自动化校验或人工干预审核的方式进行管理，采用流程驱动的方式
控制过程数据质量：唯一性或及时性等等方面控制，入库是否及时，是否满足主外键要求，枚举字段是否正确等
数据预警机制：数据质量边界模糊的数据采用数据质量预警机制，就是对数据相似性和关联性指标的进行控制的一种方法，针对待管理的数据元素配置数据相似性算法或者数据关联性算法在数据新增变更，处理应用环节调用预先配置的数据质量的算法进行相似度和关联性分析，给出数据分析的结果来保障事中的质量控制
针对不同的表配置不同的DQC规则。DQC规则分为表级，字段级和自定义三种。并有强弱规则之分，
如果是强规则，就立即终止任务加工链路，后续的任务不会执行，并且立即发出电话报警，直到故障被认领；如果是弱规则，任务会继续执行。但是存在风险，这些风险会通过邮件或者短信的方式，通知到数据开发，由人来进一步判断风险严重程度。
在实际操作中，我们需要针表的重要性来针对性的建立规则。因为DQC也会占用一定的资源消耗，如果无脑堆规则会导致整体产出滞后。

3、事后改善机制：

事后，对已经发生的数据质量问题，详细的分析影响以及原因，制定完善流程或策略，避免质量点再次发生。 数据质量体系建设评估标准 除了上面提到的数据质量综合评估的八个标准外，还需要如下具体的指标，例如：

故障次数。数据开发或应用过程中，系统出现问题的次数。除记录故障次数外，还需记录发生故障的时间、任务、负责人等相关信息。

产出完成率。例如，每日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秒。

数据质量体系架构方向建议

1）加强组织建设

企业需要建立一种文化，以让更多的人认识到数据质量的重要性，这离不开组织机制的保障。建立数据质量管理的组织体系，明确角色职责并为每个角色配置适当技能的人员，以及加强对相关人员的培训和培养，这是保证数据质量的有效方式。组织角色设置企业在实施数据质量管理时，应考虑在数据治理整体的组织框架下设置相关的数据质量管理角色，并确定他们在数据质量管理中的职责分工。常见的组织角色及其职责如下。
数据治理委员会：为数据质量定下基调，制定有关数据基础架构和流程的决策。数据治理委员会定期开会以新的数据质量目标，推动测量并分析各个业务部门内数据质量的状态。
数据分析师：负责数据问题的根因分析，以便为数据质量解决方案的制定提供决策依据
数据管理员：负责将数据作为公司资产进行管理，保障数据质量，例如定期数据清理、删除重复数据或解决其他数据问题。

2）加强人员培训

数据不准确的主要原因是人为因素，加强对相关人员的培训，提升人员的数据质量意识，能够有效减少数据质量问题的发生。数据质量管理培训是一个双赢的过程。对于员工来说，通过培训，自己不仅能够认识到数据质量对业务和管理的重要性，还能学习到数据管理理论、技术、工具等知识和技能，确保上游业务人员知道他们的数据对下游业务和应用程序的影响，让自己在工作中尽可能不犯错、少犯错，提高自己的业务处理效率和质量。对于企业来说，通过培训，可以使数据标准得到宣贯，提升员工的数据思维和对数据的认识水平，建立起企业的数据文化，以支撑企业数据治理的长治久安。有关数据治理培训机制的相关策略在第6章中已经详细描述过，此处不再赘述。此外，企业应鼓励员工参加专业资格认证的培训，这样能够让相关人员更加系统性地学习数据治理知识体系，提升数据管理的专业能力。

3）落实数据标准

数据标准的有效执行和落地是数据质量管理的必要条件。数据标准包括数据模型标准、主数据和参考数据标准、指标数据标准等。

4）ETL流程规范保障

数据提取规范：明确数据提取的来源和方法，包括数据源的选择、访问权限和安全性要求。定义清楚数据提取的时间频率和数据范围，确保提取的数据完整和准确。
数据清洗规范：明确数据清洗的目标和规则。定义数据清洗的步骤和流程，包括数据格式化、去重、填充缺失值、纠正错误等操作。确保数据清洗过程符合业务需求和数据质量标准。
数据转换规范：明确数据转换的目的和规则。定义数据转换的操作和算法，包括数据格式转换、数据标准化、数据聚合等。确保数据转换过程符合业务逻辑和数据质量要求。
数据加载规范：明确数据加载的目标和规则。定义数据加载的目标数据库或数据仓库的结构和模型，确保数据按照正确的结构进行加载。同时，制定数据加载的验证和校验规则，确保加载的数据准确性和完整性。
异常处理规范：制定异常数据处理的规范流程。定义异常数据的识别和处理方法，包括错误数据的记录、通知和修复流程。确保异常数据得到及时处理，避免其对后续数据分析和决策造成负面影响。

5）源端系统变更检测

源端的问题最好能在源端解决掉，比如数据准确性、一致性、稳定性等等。
我们需要事先跟源端系统负责人沟通确认清楚数据使用规则，确保数据抽取和计算环节的数据准确性。
在线业务系统复杂多变，每次变更都会产生数据的变化。为保证数据质量，就需要考虑如何能将源端业务系统的变更，更高效地通知给数据仓库维护人员。
首先，我们可以从人员管理入手，制定流程规范，要求前端业务变更发版上线前必须通知下游下游数仓运维人员。
其次，我们可以使用工具自动捕捉每一次业务的变化。如果数仓直接使用的是业务系统的表可以检测表结构的变化、业务关键字段的空值率、数据量同环比的波动等等。如果数仓接入的是业务系统日志，可以在入库前做格式校验和数据量同环比波动分析。

6）模型设计评审

模型设计师、架构师、需求人员、业务人员、运维人员参与，对数仓模型进行评审，优秀的数据模型除了满足业务需求外，还需要在性能、成本、效率、质量等方面有不错的助力。良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。

7）代码提交核查

即在 SQL 提交前进行相关规则校验。有工具最好，如果没有可以人工代码 review。规则分类如下：
代码规范类规则。例如，表命名规范、生命周期设置及表注释等。
代码质量类规则。例如，分母为0提醒、NULL 值参与计算影响结果提醒及插入字段顺序错误等。
代码性能类规则。例如，分区裁剪失效、扫描大表提醒及重复计算检测等。

8）任务发布变更审查

为保障线上数据的准确性，每次变更都需要经过测试再发布到线上生产环境，上线后最好第一时间对相关应用和底层数据做检查。
在进行更新操作前，需要通知下游变更原因、变更逻辑、变更时间等信息。下游对此次变更没有异议后，再按照约定时间执行发布变更，这样可以将变更对下游的影响降到最低。

9）数据质量监控：

ETL 运行过程每一步的执行情况都应该记录日志，如果有报错需要根据资产等级定义选择立即触发报警以及是否停止任务。
DQC Data Quality Center/Check 数据质量中心， DQC 通过配置质量检查规则，可以实现完整性、准确性、可访问性监控，从而间接实现了时效性监控。但是，一致性只能通过统一的模型设计和口径定义来保障。
通过配置 DQC 的数据质量校验规则，可以实现在数据处理过程中进行自动的数据质量监控。DQC 可以监控数据质量并报警，但它不对数据产出进行处理，需要报警接收人判断如何处理。
DQC 数据监控规则有强规则和弱规则：
强规则：一旦触发报警就会阻断任务的执行（将任务置为失败状态，使下游任务不会被触发执行）。
弱规则：只报警但不阻断任务的执行。

数据中台建设之指标管理

指标的定义

指标是指将业务单元细分后量化的度量值，它使得业务目标可描述、可度量、可拆解，它是业务和数据的结合，是统计的基础，也是量化效果的重要依据，一般通过对某个字段的某种计算得到（比如求和、均值等）。

指标 = 业务维度描述 + 技术维度描述

指标具体到计算实施，主要有以下几部分组成

指标加工逻辑，比如count ,sum, avg
维度比如按部门、地域进行指标统计，对应sql中的group by
业务限定/修饰词比如以不同的支付渠道来算对应的指标，微信支付的订单退款率，支付宝支付的订单退款率。对应sql中的where

指标痛点

基于但不限于上述场景，可概括为如下六类痛点：

①指标名称冲突：指标名称相同，计算逻辑、统计口径、数据源等不一样，这种情况非常让人费解；
②命名难以理解：好的指标命名是可以推断出其包含的业务过程的，但工作中总会碰到一些指标，很难判断这个指标是描述什么业务的；
③计算口径不统一：有些指标的计算口径不同的人会有不同的理解方式，导致使用者对这一指标理解产生歧义；
④计算逻辑不清晰：之前工作中经常会碰到这类问题，当指标出现问题时需要去查代码才能找到指标使用了哪些表中的数据。而有些计算逻辑比较复杂的指标很难用语言描述清楚，即使能够描述清楚也会需要大段文字。指标开发人员很清楚其中的计算逻辑，使用者用起来是一头雾水；
⑤指标重复：由于没有统一的指标管理体系，导致很多指标重复开发，不同指标名称背后很可能是相同的计算逻辑和统计口径；
⑥指标使用问题：由于指标命名不规范、指标描述不清晰等问题，使用者不知道如何使用、分析这一指标。

指标分类

原子指标：原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额。原子指标描述的其实是一种指标的类型，比如订单支付金额，支付订单数，下单订单数，PV，UV 等等。但是仅仅一个原子指标是不能直接取数的。
派生指标：对原子指标业务统计范围的确定。由一个原子指标＋修饰词（业务限定）＋时间周期+聚合粒度组成。

派生指标可以分为两类：事务型指标、存量型指标。按照其特性不同，有些必须新建原子指标，有些可以在其他类型原子指标的基础上增加修饰词形成衍生指标。

事务型指标：是指对业务过程进行衡量的指标，如近N天支付金额。这类指标需维护原子指标及修饰词，在此基础上创建衍生指标。
存量型指标：是指对实体对象某些状态的统计，对应的时间周期一般为”历史截止当前某个时间“。这类指标需维护原子指标及修饰词，在此基础上创建衍生指标。

衍生指标：是在一个或多个派生指标的基础上，通过各种逻辑运算复合而成的。例如比率、比例等类型的指标。衍生指标也会对应实际的统计需求。衍生指标=派生指标+运算规则

指标解析

拿统计报表的指标解析步骤来举例，通常指标解析的步骤分为5步：

理解业务。首先通过报表标题、表头、表尾，以及各数据项的关系和公式来了解统计报表是要做什么的。
剔除无效指标。报表不是所有指标都是有效指标，与业务没有强关联的指标可以视为无效指标，例如“操作”、“序号”等。
分析指标的维度、筛选条件、公式。
确定报表的数据期。数据期也就是查看统计报表的时间粒度，我们需要确认：确定数据期字段、确定数据期类型。
与业务方或技术方确认，保证指标的权威性。记录存档，以备指标定义时使用。

指标规范

指标来源规范

为了保持数据一致性，同一业务含义指标的源头尽量保持同一张表，比如所有相关评论指标应该能追溯到同一个数据表。

同一业务指标需要涉及多个源数据时，比如日志和服务端的数据。建议尽量加以区分，比如命名上区分。

命名规范指标规范定义：一个指标只有一个英文字段、一个中文字段、一个算法定义，避免不同部门口中的指标逻辑不同一问题。
统计口径

在开发指标过程中，做到需求描述、计算口径、指标口径保持一致性，同时做到指标可追溯可管理。可依托于工具来完成指标的管理。

以下是一些常见的指标口径规范：

定义度量标准：定义每个指标的计算方法和公式，以保证所有人对指标的解释和计算方式达成一致。例如，销售额=销售数量*销售单价。
确定数据源：明确每个指标的数据来源，并对数据的准确性进行验证和验证过程进行说明。例如，销售数量来自订单表，销售单价来自价格表。
设定计算周期：确定每个指标计算的时间点和时间范围，以保证指标的时效性和可比性。例如，月度销售额需要在每月末算出。
选择计算精度：根据业务需求和数据特点，确定指标计算的精度和取舍原则。例如，保留两位小数或者四舍五入取整。
标准化指标名称：使用简洁明了、具有意义的指标名称，并与业务术语相一致，以便于理解和识别。
编写指标说明：编写指标说明文档，详细阐述每个指标的含义、计算方法、数据来源、计算周期等信息，以方便用户查询和理解。

统一词根、修饰词、公共字段管理，保证原子指标和衍生指标的一致性
统一指标管理，保证需求描述、计算口径、指标业务口径数据来源的一致性。
统一维度管理，保证了维度定义、维度值的一致性。
统一模型层次、维表、事实表的关联，保证模型设计的一致性
统一数据域、业务过程管理，保证数仓体系的一致性

指标字典

指标字典是业务数据标准化的基础，目的是对指标进行统一管理，方便共享达成对业务指标的共识，并统一修改和维护。指标字典可以更新在excel或者指标管理平台。如果有足够多的的资源，那么开发指标管理模块可以放在数据管理系统再配合血缘关系，就方便追踪数据流转了。很多公司喜欢用Excel管理指标，觉得Excel上手容易，编辑比较方便。但是，Excel并不是一个适合指标管理的工具，有这样几个原因：难于共享、缺少权限控制；无法动态更新；指标无法跟数仓的模型动态关联。因此，我们需要搭建一个面向指标的管理平台。指标字典是基于元数据中心构建的一个指标管理工具，它从元数据中心自动同步数仓的主题域和业务过程，按照规范化定义创建指标。新创建的指标同时会以特定类型的标签，下沉到元数据中心对应的表和字段上，这样在数据地图上就可以搜索到表关联的指标。

指标字典模板

指标分级

指标体系分级用到的技能会更高阶一点，更适合 BI 或者分析师，帮助公司搭建一套完整的数据指标体系，从而及时发现业绩的升高或降低、以及产生的原因。

数据本身是分层的，我们在思考指标的时候，也应该有一个层级的概念，而不是现阶段关心什么，我们就放什么，指标分级可以帮助我们更高效的去定位问题，去验证我们的方法论，无需每次都要思考要去看哪些指标。

三级指标体系我们可以针对不同的指标，分不同的层级。不一定要拆得太细，否则层级会过深不易执行，基本上3个层级就能够指导我们一线的业务人员去做一些动作。

(1)一级指标(Tier 1 Metrics)：公司战略层面指标
一级指标必须是全公司都认可的、衡量业绩的核心指标。可以直接指引公司的战略目标，衡量公司的业务达成情况，本质上需要管理层和下级员工的双向理解、认同，目要易干沟通传达。
选择一级指标时，数量控制在 5至8个最为合适。需要从公司和用户两个角度出发，与商业结果和公司战略目标紧密结合。比如 GMV(GMV=用户数*转化率*客单价)、订单数量、周/日活跃用户数量等。
(2)二级指标(Tier 2 Metrics)：业务策略层面指标
二级指标是针对一级指标的路径分析拆解，是流程中的指标。当一级指标发生变化的时候，我们通过查看二级指标，结合一定的历史经验，能够快速定位问题的原因所在。
比如，我们的一级指标是 GMV 和订单数量上升，而能够影响到 GMV 和订单数量上升的，就是我们的核心二级指标。比如说货品的单价上升、活跃用户数量增多、或者某站内渠道大规模推广。
(3)三级指标(Tier 3 Metrics)：业务执行层面指标
三级指标是针对二级指标的路径分析拆解，通常以子流程或个体的方式定义。通过三级指标，可以高效定位二级指标波动的原因，这一步也会基于历史经验和拆解。
三级指标能够直接指引一线运营的决策。一线的产品、运营、市场等同学，在看到三级指标的结果后，往往就能够有直接的改变行为产生。

以一级指标 GMV 提升为例，我们拆解后发现是转化率提升，那么转化率就是二级指标。接着分平台去拆解转化率的时候，我们发现是 iOS 的客户端转化率有所提升。那为什么安卓没有提升，是不是 iOS 最近有一些迭代？是不是它的一个转化路径比其他端好？这些思考就能直接指导业务人员展开行动。

指标管理体系建设

参看链接：https://blog.csdn.net/a958014226/article/details/127085821

1、通用原则

用户第一：指标体系核心是围绕反映实际业务情况的目的去的，因此，指标不是越多越好，更不需要“虚荣指标”。
典型性原则：尽量选择比较典型、比较具备代表性的指标，这些指标能够反映业务的真实情况，其中最重要的指标叫做“北极星指标”。
系统性原则：指标体系是需要强调系统性的，常见的就是找到核心原子指标，然后延伸，最终形成类似二叉树一样的树状结构指标体系，让每个指标有根可循。
动态性原则：数据指标体系是随着业务发展变化、随着数据分析需求变化的，因此需要不断地去做指标体系的维护与迭代更新。

2、通用方法

第一步：确定北极星指标及伴随指标

北极星指标代表了当前业务的战略方向，往大了讲就是整个产品团队的目标，往小了讲就是产品运营团队中单个成员的业务目标，其确定方法主要有以下两种。

1.通常 KPI/OKR 即代表北极星指标
当 KPI/OKR 与自身业务一致，则拆解 KPI/OKR， 选择其中的某个子指标作为北极星指标。例如，某信息流产品以 DAU 作为 KPI，而小A负责的是信息流中短视频的 DAU。因为短视频的 DAU 是整个信息流产品 DAU 的组成部分，所以可将短视频的 DAU 作为小A的北极星指标。
当 KPI/OKR 与自身业务不一致，则拆解自己的业务指标，找到其中可以与 KPI/OKR 一致对应的指标作为自己的北极星指标。例如，某电商产品以有效注册用户量作为 KPI，而小A负责的是电商产品的 DAU。因为小A自己的业务指标 DAU 与整个产品的 KPI 并不一致，故拆解自己的 DAU 为新增用户量、留存用户量和回流用户量。其中新增用户量是产品 KPI 的组成部分，故选择新增用户量作为小A的北极星指标。
2.结合产品生命周期确定
产品的生命周期分为探索期、成长期、成熟期、衰退期和退出期，每个周期可供借鉴和使用的北极星指标如下：
    探索期：留存类指标，包括留存率、留存用户量、探索期内每用户平均使用次数。
    成长期：注册类指标，包括每日新增用户量、有效注册用户量等。
    成熟期：活跃、留存或收入类指标，包括 DAU、MAU、次日留存、次月留存或 ARPU 等。
    衰退期：注册类、活跃类或收入类指标，包括有效注册用户量、DAU、MAU 或 ARPU 等。
    退出期：活跃类指标，包括 DAU、MAU 等。
确定伴随指标的方法主要依据指标间的联系紧密程度：
    如果注册类指标为北极星指标，那么活跃类指标就是伴随指标；
    如果活跃类指标为北极星指标，那么留存类指标就是伴随指标；
    如果留存为北极星指标，那么活跃类和收入类指标就是伴随指标。

第二步：确定指标的业务口径和关联维度

明确业务口径是为了清晰定义指标的定义，同时也是为接下来的指标拆解提供依据；关联维度是明确可以考察指标的不同角度，为接下来的多维分析奠定基础。

1.为指标明确业务口径-----清晰定义指标的定义，为接下来的指标拆解提供依据
    数值型指标，需要注意其口径的限定条件，例如某段时间、某个区域、达成某个条件，以及是否去重。例如，DAU 就是在当天的 00：00~23：59 之间启动过 App 的去重设备量。
    比率型指标，需要注意其口径中的分子和分母的范围必须一致，即分子有且只能是分母的一部分，分子不能包含超出分母范围的数据。
2.为指标关联维度--明确可以考察指标的不同角度，为接下来的多维分析奠定基础。
例如，信息流产品的核心指标是人均 vv 或者 ctr，一般可以给它关联内容类型的维度，其中包括图文、图片、短视频、长视频和动图等分类。B 站和头条系产品都有这些内容类型，每种内容类型的运营策略不尽相同，也都由不同的团队负责；也可以关联分类或垂类的维度（分类，是指内容本身的属性，又因为每个分类都是一个相对垂直的领域，故也叫垂直分类，简称垂类），例如娱乐、社会、汽车、教育等，大部分信息流产品的分类/垂类维度都是一个树状体系，分为一级分类、二级分类和三级分类。

第三步：梳理业务，指标拆解和细化

数值型指标拆解：要求维度内遵循 MECE 原则，无遗漏无重复，维度间尽可能完备，且每个维度内的子指标求和等于上层指标。
比率型指标拆：天然就有两个部分组成：分子和分母，所以可以按照其口径立刻进行拆解。如果子指标出现数值型指标，就按照关联维度继续拆解。
# 几种拆解方式
（1）业务目标拆解法
这种方法是将业务目标拆解为多个子目标，再将子目标转化为相应的指标。例如，一家电商平台的业务目标可能是提高销售额，那么子目标就可以是提高转化率、提高客单价等。这些子目标可以进一步转化为相应的指标，例如转化率可以转化为下单率、支付率等。
（2）用户行为拆解法
这种方法是将用户行为按照漏斗模型拆解为多个步骤，再将每个步骤转化为相应的指标。例如，一家社交媒体平台的用户行为可能包括浏览、点赞、评论、分享等。这些行为可以按照漏斗模型分为多个步骤，例如浏览、点赞、评论、分享等。每个步骤可以进一步转化为相应的指标，例如浏览可以转化为浏览量、页面停留时间等。
（3）数据属性拆解法
这种方法是将数据属性按照维度拆解为多个指标。例如，一家电商平台的数据属性包括商品、用户、订单等。这些数据属性可以按照不同的维度拆解为多个指标，例如商品可以拆解为销售量、库存量、SKU数等。
在拆解出各个指标后，需要对指标进行筛选和加权，以确保指标的有效性和权重的合理性。

第四步：全面检查复核所有指标的口径和维度，并确定更新周期

每个指标的口径是否正确
是否存在重复指标
上下级指标是否存在明确、直接的关系
指标关联的维度是否尽可能完备
指标是否确定了更新周期

最后，定期进行 review，移除废弃指标、更新指标口径、添加新的指标，真正地把指标体系作为重要的数据产品来不断维护和迭代。

指标管理平台

基于上述指标管理方法，可以抽象出一个合格的指标管理系统应当具备哪些功能：

系统应当能按照指标管理体系进行多维度分类
能够清晰的描述指标名称（中英文）、业务口径、计算逻辑等；
能够较为便利的管理指标，进行添加、删除、修改等操作。
指标能够关联应用系统
指标应该和能数仓中的数据模型动态关联，即指标能够关联到表和字段上，以便使用者能够深入了解指标的计算过程，开发者能够较为便捷的定位数据源
系统应该和元数据管理系统关联，否则指标无法关联表和字段
应当能够同步数仓的主题域和业务过程，并按照命名规范创建指标
提供指标检索功能

数据中台之数据服务

One Service即数据即服务，强调数据中台中的数据应该是通过API 接口的方式被访问。

有以下四点作用：
    屏蔽异构数据源
    把控数据网关
    提供面向用户的逻辑模型
    保证性能和稳定性

OneService体系方法论至少包括：主题式数据服务、统一但多样化的数据服务、跨源数据服务3个方面。

(1)主题式数据服务。举一个例子，假设用户想要看的是“会员”这个主题下的数裾.，至于“会员”主题背后有1000张物理表还是2000张物理表，他都不关心。而主题式数据服务要做的是，从方便用户的视角出发，从逻辑层面屛蔽这1000张甚至是2000张物理表，以逻辑模型的方式构建而非物理表方式。
(2)统一但多样化的数据服务。例如，双十一当天上百亿次的调用服务是统一的，但获取形式可以是多样化的，可以通过API提供自主的SQL查洵数据服务，也可以通过API提供在线直接调用数椐服务。
(3)跨源数据服务。不管数裾服务的源头在哪里，从数据服务的角度出发，都不应该将这些复杂的情况暴露给用户，而是尽可能地屏蔽多种异构数据源。

oneService包含内容：统一查询API接口，集群性能监控，全链路监控，调度平台，网关服务，鉴权，安全认证，高可用建设，容器化...

中台核心目的就是对外提供便捷、准确、高效的数据服务，前期包括数据集成与数据资产管理均为统一的数据服务提供保障。对外服务的主体包括但不限于数仓数据、指标信息、元数据信息。服务方式包括但不限于：数据接口、SDK开发包、搜索展示平台、数据地图、数据门户等。统一服务出口的意义主要有以下几点：

（1）保障“数出一孔”，提升数据的一致性
通过服务获取数据的方式类似于“阅后即焚”，大部分情况下数据并不会在使用方的系统中落地，因此减少了数据“搬家”，而一旦数据的使用方并不拥有数据，就减少了向下游二次传递所造成的数据不一致问题。
（2）数据消费者不用关注技术细节，可以满足不同类型的数据服务需求
对于数据消费者而言，不用再关心“我要的数据在哪里”，例如用户不需要知道这些数据来自哪个系统、哪个数据库、哪个物理表，只需要清楚自身的数据需求，就能找到对应的数据服务，进而获取数据。
（3）提升数据敏捷响应能力
通过可复用的数据服务出口，为后续应用开发减少了工作量。不需要按使用者重复构建集成通道，而是通过“订阅”该数据服务快速获取数据。
（4）满足用户灵活多样的消费诉求
数据服务的提供者并不需要关心用户怎么“消费”数据，避免了供应方持续开发却满足不了消费方灵活多变的数据使用诉求的问题。
（5）兼顾数据安全
所有数据服务的使用都可管理，数据供应方能够准确、及时地了解“谁”使用了自己的数据，并且可以在数据服务建设中落实各种安全措施，确保数据使用的合规。

提供方式

数据接口：通过HTTP接口对外提供数据服务。
可视化图表：将数据通过可视化图表进行展现。
数据地图：在元数据基础上，通过多层次图形化的数据资产管理工具，将企业内各类数据进行展示，帮助业务人员、管理人员、开发人员更好更快地查找、理解、使用和管理数据。
数据门户：通过配置导航菜单，自由组合报表、⼤屏、数据填报、外部链接等资源，形成⼀个可通过自定义地址统一访问的资源。数据门户可⽅便用户对多个关联⻚⾯进⾏集中查看。
消息队列：将数据发送至消息中间件中，由下游进行统一消费。

数据服务的核心功能 第一，接口规范化定义。对各个数据应用屏蔽了不同的中间存储，提供的是统一的API。

第二，数据网关部署。作为网关服务，数据服务必须要具备认证、授权、限流、监控四大功能，这是数据和接口复用的前提。

认证。为了解决接口安全的问题，数据服务首先会为每个注册的应用分配一对accesskey和secretkey，应用每次调用API接口，都必须携带。
授权。对于每个已发布的 API，API 负责人可以对应用进行授权，只有权限的应用才可以调用该接口。
限流。API 接口的负责人可以对应用进行限流（例如限制每秒QPS不超过 200），如果超过设定的阈值，就会触发熔断，限制接口的访问频率。需要注意的是，对于接口复用来说，限流功能非常必要，否则会造成不同应用之间的相互影响。
监控。例如，接口的 90% 的请求响应时间、接口调用次数、失败次数等相关的监控。同时，对于长时间没有调用的API ，应该予以下线。

第三，数据全链路打通。服务很难避免出现问题或者故障，一旦出现问题，及早发现及早介入是非常重要的，因此，数据服务必须负责维护数据模型到数据应用的链路关系，构建服务平台的全链路监控，包括：

数据同步：对数据资产同步至高速存储的过程进行监控，包括数据质量检测（过滤脏数据）、同步超时或者失败检测等；
服务稳定性：构建一个独立的哨兵服务，来监测每个API的运行指标（如延迟、可用性等），客观的评估健康度；
业务正确性：数据服务需要确保用户访问的数据内容和数据资产表内容是一致的，因此，哨兵服务会从数据一致性层面去探查，确保每个API的数据一致性。

第四，确立推和拉的数据交付方式。

Push（推）

数据供应端主动推送数据到数据消费端，典型的代表有事件订阅和数据库同步。例如，当物料主数据变化的时候，将最新的数据推送给所有的数据消费者系统。

这样的形式是从供应方的视角来处理的，因此不论数据消费者是否需要这些数据，也不论消费者对于这些数据的使用场景是怎样的，对于数据供应方，都是无差别推送过去，尽管消费者使用频率很低。

其优势是实时性很强，只要数据在源头发生了变化，都会第一时间推送给数据消费方。但是劣势也很明显，主要体现在：
    无差别的推送，数据产生了很多资源浪费；
    往往数据消费方需要二次加工这些推送来的数据，才能使用；
    消费者是否使用，如何使用，不好管理，无法跟踪。

Pull（拉）

数据消费方根据自己的需要，从数据供应端拉数据回来，这样的典型服务类型包括：Data API，文件下载和Terminal & APP。 Pull是典型的精益形式，按需使用数据，用什么获取什么，什么时候用什么时候获取，用哪部分数据获取那部分数据。

从数据消费者的视角来看（如图），只有当数据应用方能够直接使用这个数据消息的时候，应用开发团队才不需要二次开发这个数据，否则应用开发团队需要在本地的存储中再次存储一遍这个数据，并且构建后端AP，进一步加工这个数据。这样带来了前端应用利用数据的复杂性，也带来了一致性的问题。由此，在数据处理和加工方与数据应用方之间加入一层——数据服务层（如图），可以提高灵活性和复用性，这样让数据应用放可以直接使用数据服务而不再做任何加工处理，也能够保证不同数据应用使用同一个数据服务，提高数据的一致性。

什么情况下选择用推（push）的方式：
基于网络安全考虑，外部网络无法直接访问数据源系统的网络，但是数据源系统的网络则可以访问外部网络情况下只能用推；
数据源方生产数据的频率比较随机。比如，数据源方不定期的生成数据且数据量也不固定，为了让后台处理系统第一时间能够完整处理每次产生的数据，需要用推的方式；
基于数据源访问权限考虑，虽然数据源与外部系统网络互通，但是由于数据的访问权限控制，外部系统无法直接读取数据源，这种情况也只能用推的方式；
数据源方众多（比如各种数据采集终端设备），且都是以比较随机的频率提供数据，后台处理系统不太方便通过统一的数据拉取程序来获取数据源，这种情况下也最好用推的方式。
什么情况下选择用拉（push）的方式：
后台处理系统有权限访问数据情况下，数据源方以一个比较固定的频率或者固定的时间节点产生数据；
业务要求必须以固定频率（比如每10分钟）或者固定时间点（比如每天的8:00、12:00、20:00）更新数据；
如果根据实际业务需求发现，两种方式都可以的话，优先选择拉的方式，以此可以达到简化后台处理的复杂度，提高系统稳定性。
综上，两种数据接入的方式分都有着各自的特点，不存在孰优孰劣，具体如何选择完全取决于业务场景需要，以上是我对数据源接入方式的一点理解，希望对你有所帮助。

第五，利用中间存储，加速数据查询。数据中台中数据以Hive表的形式存在，基于Hive或者是Spark计算引擎，并不能满足数据产品低延迟，高并发的访问要求，因此，一般做法是将数据从 Hive 表导出到一个中间存储，由中间存储提供实时查询的能力。

第六，基于逻辑模型发布API，实现数据的复用。逻辑模型是解决数据复用的一个策略，在相同的物理模型之上，应用可以根据自己的需求，构建出不同的逻辑模型。我们可以在数据服务中定义逻辑模型，然后基于逻辑模型发布API。逻辑模型实际是多个物理表，从用户的视角，一个接口可以访问多张不同的物理表。逻辑模型类似数据库中的视图，相比于物理模型，逻辑模型只定义了表和字段的映射关系，数据是在查询时动态计算的，因此，不占用大量的物理存储空间。

第七，构建API集市，实现接口复用。为了实现接口的复用，我们需要构建API 集市，应用开发者可以直接在API集市发现已有的数据接口，直接申请该接口的 API权限，即可访问该数据，不需要重复开发。数据服务通过元数据中心，可以获得接口访问的表关联了哪些指标。使用者可以基于指标的组合，筛选接口，这样就可以根据想要的数据，查找可以提供这些数据的接口，形成闭环。

此外，需要关注的是，在当前最新的应用中，API已超越了技术范畴，从对技术的要求转变为商业战略和商业模式的需求，许多企业开始启动API战略，构建API生命周期管理。由于本篇不是重点介绍API内容，因此先抛出这样的观察。

数据服务的关键技术

为了使数据中台具备快速响应前端业务需求的能力，主流的数据中台均采用了云原生技术来构建数据服务层，实现数据服务的快速开发、有序落地。在数据中台领域，应用云原生的核心优势在于每个服务至少有两个副本，实现了服务的高可用。同时，根据访问量大小，服务的副本数量可以动态调整，可以实现对客户端透明的弹性伸缩。服务之间基于容器实现了资源隔离，避免了服务之间的相互影响。这些特性非常适用于提供高并发、低延迟，在线数据查询的数据服务。

以下是具体技术应用场景。

第一，配置即开发。平台用户分为两类角色：数据服务生产方、数据服务调用方。数据服务生产方只需要配置，实现“配置即开发”。配置内容包括：

数据源
数据加速到何处
接口形态，访问方式
测试环境，访问隔离的测试数据当配置完毕后，数据服务平台便会根据配置清单，完成接口的自动化生产和部署。生产和部署完毕后，调用方在平台申请服务权限调用。通过自动化生产，达到配置即开发的目的，从而极大的提升效率。

第二，多模式服务形态。 数据服务有多种服务形态，包括：

KV API：简单点查，可以支撑百万QPS、毫秒延迟。这类API是通过模板自动化创建，支持单查、批量查询等接口，返回的结果是 Protobuf (PB) 结构体，从而将结果自动做了ORM，对于主调方更加友好。典型场景包括：根据IP查询GEO位置信息、根据用户ID查询用户标签画像信息等。
SQL API：复杂灵活查询，底层基于OLAP/OLTP 存储引擎。通过Fluent API接口，用户可自由组合搭配一种或若干种嵌套查询条件，可查询若干简单字段或者聚合字段，可分页或者全量取回数据。典型场景包括：用户圈选（组合若干用户标签筛选出一批用户）。
Union API：融合API，可自由组合多个原子API，组合方式包括串行和并行方式。调用方不再需要调用多个原子API，而是调用融合API，通过服务端代理访问多个子查询，可以极大降低访问延迟。

第三，高效数据加速。企业的数据资产，通常是存在于低速的存储引擎中，无法支撑线上业务高访问流量。因此需要以系统化的方式进行数据加速。目前有两种加速方式：

全量数据加速。从多个数据源摄入原始数据（如Kafka，MySQL、线上访问日志等），进行加工建模后，得到数据资产。数据资产经由独立的数据同步服务，同步至其他更高速的存储引擎，如redis、hbase、druid等。数据同步支持一次性或者周期性（小时、天、周等）将数据从Hive同步至其他存储中，数据同步本身是基于分布式的调度系统，内核是基于datax 进行数据同步。大数据服务化平台单日同步的数据量达到1200亿条，数据size达到20TB。
多级缓存（部分数据加速）。大数据服务化平台会使用Redis、Hbase、Druid、Clickhouse等方式存储所有数据，但是部分存储如Hbase速度可能较慢，针对热点数据需要使用额外的热点缓存来Cache数据。热点缓存是多级缓存，针对每个API接口，用户可自由搭配组合多级缓存、灵活设置缓存策略。此外，针对数据较大的API，还可配置数据压缩，通过多种压缩方式（如 ZSTD, SNAPPY, GZIP 等），可将数据量显著减少（部分API 甚至能减少90%的数据存储量）。 第四，资源隔离。资源隔离是可用性保障的常见手段之一，通过隔离将意外故障等情况的影响面降低。不管是微服务，还是存储，需要按照业务+优先级（高、中、低）粒度隔离部署，独立保障，业务之间互不影响、业务内不同级别也互不影响。同一业务线内可能有多个不同数据服务，通过混合部署，提高资源使用率。 总结：

数据服务架构的关键，主要有以下三点：

支持丰富的数据源：包括大宽表、文本文件、机器学习模型（模型也是一种数据资产），来构建完善的数据服务。
支持多样取数方式：除了支持同步快速取数之外，还支持异步查询取数、推送结果、定时任务等多样化方式，以满足业务多种场景需求。
建设统一的API网关：集成权限管控、限流降级、流量管理等于一体，不仅平台创建的服务可以注册进API网关，用户自己开发的API也可注册进API网关，从而享受已有的基础网关能力，为业务提供数据服务能力。

数据中台之数据安全

安全管控策略 安全从哪些方面建设

数据获取安全：能够支持数据获取需要经过申请与审批流程，保障数据获取安全；
数据脱敏：能够支持数据脱敏规则、脱敏算法及脱敏任务的管理及应用，一般情况下，脱敏方式有动态脱敏和静态脱敏两种；
统一认证：定义数据安全策略，定义用户组设立和密码标准等；
租户隔离：管理用户，密码，用户组和权限；
角色授权：划分信息等级，使用密级分类模式，对企业数据和信息产品进行分类；
日志审计：审计数据安全，监控用户身份认证和访问行为，支持经常性分析；
异常监控：指对账号异常行为的监控，如同一账号异地登录、同时多 IP 登录、多次重复登录等；
数据分类分级：能够支持对数据资产安全进行敏感分级管理，并支持根据各级别生成对应的数据安全策略。

安全实现手段

1.统一安全认证和权限管理

由于hadoop本身没什么安全机制，Hadoop集群安全，首先就会想到业界通用的解决方案： Kerberos。Kerberos是一种网络认证协议，其设计目标是通过密钥系统为客户机/服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，不需要基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意读取、修改和插入数据。
Kerberos通常会与LDAP配合使用。在大数据平台通常服务器多、租户也较多，需要进行Linux层面及应用层面的统一，这也就是构建Kerberos+LDAP这一组合的缘由。LDAP是一个轻量级的产品，作为一个统一认证的解决方案，其主要优点在于能够快速响应用户的查找需求。
除了统一认证，在数据的传输过程中，可以通过选择适合的SSL（Secure Socket Layer）证书，对传输中的一些敏感数据进行加密。 SSL证书可加密隐私数据，使黑客无法截取到用户敏感信息的明文数据，因此部署SSL证书是网络安全的基础防护措施之一。一份SSL证书包括一个公共密钥和一个私用密钥。公共密钥用于加密信息，私用密钥用于解译加密的信息。当用户端的浏览器指向一个安全域时，SSL同步确认服务器和客户端，并创建一种加密方式和一个唯一的会话密钥。它们可以启动一个保证消息的隐私性和完整性的安全会话。
在数据的操作和应用过程中，可以通过权限管理，控制不同的角色能操作的数据权限。设计良好的大数据平台权限管理，能从两个维度控制角色权限：第一个维度是控制粒度，如控制到字段级权限，第二个维度控制动作，如控制该角色是否能进行select、alter、delete等操作。

2.资源隔离

在资源隔离层面，可以通过建立不同的租户，对不同权限的数据资源进行隔离。多租户技术是一种软件架构技术，可实现在多用户环境下共用相同的系统或程序组件，并且可确保各用户间数据的隔离性。多租户在数据存储上存在三种主要的方案，按照隔离程度从高到低，分别是：

独立数据库
共享数据库，隔离数据架构
共享数据库，共享数据架构

3.数据加密

数据加密是用某种特殊的算法改变原有的信息数据使其不可读或无意义，使未授权用户获得加密后的信息，因不知解密的方法仍无法了解信息的内容。

先进行数据资产安全分类分级，然后对不同类型和安全等级的数据指定不同的加密要求和加密强度。尤其是大数据资产中非结构化数据涉及文档、图像和声音等多种类型，其加密等级和加密实现技术不尽相同，因此，需要针对不同的数据类型提供快速加解密技术。

根据数据是否流动的特点，数据加密分为存储加密和传输加密。

4.数据脱敏

为了防止用户隐私信息、商业机密信息和企业内部数据泄露，在数据的传输、共享、展现等环节，往往需要对数据中台中的某些敏感数据进行脱敏操作。

大数据脱敏主要包括以下两大功能：

1.敏感数据识别
通过设置敏感数据的发现机制，计算机自动识别敏感数据，并在发现敏感数据后自动为该敏感数据打上相应的标签。
建立敏感数据规则：建立敏感信息样本库，定义企业的敏感信息的具体特征。比如：身份证号码、手机号码、生日、信用卡号码等。
敏感数据检测：脱敏系统支持对大数据平台存储的结构化和半结构化数据库、表进行敏感数据扫描探测，并对每个数据表进行抽样数据匹配，基于敏感信息库来检测存储在大数据平台的敏感数据，如客户信息、交易数据等。脱敏系统将数据库中包含敏感信息的表和字段标记出来以实现各类高级数据安全功能。例如：利用敏感数据标记实现以下自定义规则：只向外传输姓名，不是信息泄露事件；姓名、账号和电话等信息同时向外泄露，则认定为信息泄露事件。
2.敏感数据脱敏
提供敏感数据的动态脱敏功能，保障敏感数据访问安全。同时基于大数据安全分析技术，发现访问敏感数据的异常行为，并在可能的情况下进行追踪。最常见的脱敏方式包括如下几种形式：
    数据替换：以虚构数据代替数据的真实值。
    截断、加密、隐藏或使之无效：以“无效”或“*****”等代替数据的真实值。
    随机化：以随机数据代替数据的真实值。
    偏移：通过随机移位改变数字型的数据。

5.数据共享安全

数据对外共享一般包括两种方式：接口和文件。

接口方式包括接口数据（JSON/XML）、流式数据（Kafka）等多种数据访问方式。通过API操作权限管理、API流量管控、API认证管理等手段实现接口管控。
文件方式主要指通过FTP、SFTP、邮件等对外共享数据，数据类型包括TXT、CSV、Word、PPT、Excel、HTML等，通过数字暗水印进行安全防护。数字暗水印通过对共享的文件嵌入暗水印作为标记一起传输，保障数据在发生泄露时，能够提取水印信息并追踪至责任人，达到事后安全保护的目的，解决了数据泄露后无法追踪、难以定责、难以避免再发生的问题。

6.数据的容灾备份

服务器的硬件故障、软件故障、网络发生问题等，都可能导致数据丢失、错误或损坏。另外，人为的操作失误、自然灾害、战争等不可预料的因素，也可能导致发生不可挽回的数据丢失，给用户带来巨大损失。

为了应对这些情况，用户必须考虑数据的容灾备份，确保在任何情况下都不会影响到重要业务活动的持续开展。用户可以根据恢复目标将业务的关键等级划分为核心业务系统、一般性重要业务系统和一般业务系统三个级别，并根据不同级别分别有针对性地制订容灾备份方案。

7.日志审计

日志审计系统是用于全面收集企业IT系统中常见的安全设备、网络设备、数据库、服务器、应用系统、主机等设备所产生的日志（包括运行、告警、操作、消息、状态等）并进行存储、监控、审计、分析、报警、响应和报告的系统。

数据中台之数据应用

数据中台能力评估

如何衡量数据中台带来的价值？

数据中台可以从技术侧和业务册两个角度来分析价值：

技术侧：
1、统一底层架构，统一落地规范，统一演进路径，减少技术冗余，便于快速落地项目和扩展。
2、统筹规划资源，减少浪费，提升效率。
3、功能标准化工具化，降低研发成本。
业务侧：
1、标准化的规范数据产出，降低数据的学习成本。
2、聚合数据，便于挖机数据联系，促进新的数据业务产出。
3、统一管控，降低数据安全风险。
综合评定要从价值产出、使用效率、分析研发运维效率、计算效率、安全性几个方面来综合衡量。
1、价值产出：数据产出的业务价值，数据的单独应用和聚合应用。
2、使用效率：平台的被使用程度、包括平台工具、相关加工的数据。以及数据使用对业务的效率提升。
3、分析研发运维效率：研发成本、运维成本、分析成本的降低和效率的提升。
4、计算效率：综合计算成本，提升数据产出时效，高效、准确、及时的产出数据
5、安全：数据安全达标的等级，规避安全风险。