大家好，我是讯享网，很高兴认识大家。



 <p>本文转自&#xff1a;大数据启示录</p> 

讯享网

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

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

讯享网

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

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

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

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

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

• 1、烟囱式的开发模式

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

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

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

• 2、数据管理能力缺失

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

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

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

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

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

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

• 4、成本粗放式管理

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

• 5、数据使用不灵活

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

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

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

构建数据中台价值

• 1、提升数据应用能力

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

• 2、打破数据应用屏障

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

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

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

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

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

• 5、数据快速复用

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

背景

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

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

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

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

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

数据标准的使用场景

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

数据标准的定义和分类

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

数据标准的定义要遵循六大原则：

数据标准分类：

一般数据标准分类：

• 基础数据标准
• 指标类数据标准

  数据标准命名规范

  数据标准设计流程

  数据标准体系建设流程

• 1.制定目标和界定范围

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

• 2.数据标准调研

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

讯享网

• 3.明确组织和流程

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

• 4.数据标准编制与发布

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

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

讯享网

• 5.数据标准宣贯

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

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

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

讯享网

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

元数据分类

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

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

  在实际的业务场景中，元数据的种类非常多，因此，为了管理这些元数据，此时必须要构建一个元数据中心

元数据中心

数据血缘要素

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

1）数据节点

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

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

2）数据流转路径

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

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

3）数据流转规则

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

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

血缘的应用场景

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

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

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

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

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

对于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 - 时效性

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

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

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

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

数据地图

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

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

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

建模流程

数据模型层次设计

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

讯享网

下图右边以淘宝为例，列举淘宝三个核心 Project（tbads、tbcdm、tbods）

数据模型建设关键步骤：

• 1：需求调研：

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

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

讯享网

• 2:数据域的划分

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

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

讯享网

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

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

1. 归纳：数据域

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

讯享网

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

• 3：总线矩阵

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

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

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

1. 一致性维度

讯享网

1. 一致性度量

基本原则

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

命名规则

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

1. 指标规范（...省略）

• 6: 模型设计

  层级设计规范

数据模型管理

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

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

  数据模型生命周期

  数据模型衡量标准

整体框架

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

数据质量的八个维度指标

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

建设方法

• 关键流程：

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

讯享网

一个标准的数据质量管理平台

常见数据质量监控规则

讯享网

数据质量建设保障方案

• 设立负责人：

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

• 建立完整的保障机制：

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

1：事前预防控制：

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

2、事中监控数据质量

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

讯享网

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）加强人员培训

讯享网

• 3）落实数据标准

• 4）ETL流程规范保障

讯享网

• 5）源端系统变更检测

6）模型设计评审

讯享网

• 7）代码提交核查

• 8）任务发布变更审查

讯享网

• 9）数据质量监控：

指标的定义

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

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

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

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

指标痛点

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

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

指标分类

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

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

讯享网

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

指标解析

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

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

指标规范

• 指标来源规范

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

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

• 命名规范

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

• 统计口径

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

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

讯享网

指标字典

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

指标字典模板

指标分级

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

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

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

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

指标管理体系建设

讯享网

• 1、通用原则

• 2、通用方法

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

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

讯享网

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

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

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

讯享网

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

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

指标管理平台

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

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

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

讯享网

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

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

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

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

提供方式

讯享网

数据服务的核心功能

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

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

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

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

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

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

Push（推）

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

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

Pull（拉）

数据消费方根据自己的需要，从数据供应端拉数据回来，这样的典型服务类型包括：Data API，文件下载和Terminal & APP。

Pull是典型的精益形式，按需使用数据，用什么获取什么，什么时候用什么时候获取，用哪部分数据获取那部分数据。

从数据消费者的视角来看（如图），只有当数据应用方能够直接使用这个数据消息的时候，应用开发团队才不需要二次开发这个数据，否则应用开发团队需要在本地的存储中再次存储一遍这个数据，并且构建后端AP，进一步加工这个数据。这样带来了前端应用利用数据的复杂性，也带来了一致性的问题。

由此，在数据处理和加工方与数据应用方之间加入一层——数据服务层（如图），可以提高灵活性和复用性，这样让数据应用放可以直接使用数据服务而不再做任何加工处理，也能够保证不同数据应用使用同一个数据服务，提高数据的一致性。

讯享网

第五，利用中间存储，加速数据查询。数据中台中数据以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.统一安全认证和权限管理

• 2.资源隔离

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

讯享网

• 3.数据加密

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

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

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

• 4.数据脱敏

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

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

• 5.数据共享安全

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

讯享网

• 6.数据的容灾备份

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

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

• 7.日志审计

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

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

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