3月12日　周日　晴　　地点：老北京铜炉火锅店

这一周忙得焦头烂额，年初诸多项目启动，千头万绪，但是心里很清楚，“数据中台战略项目”是大数据事业部今年最重要也最值得去做的工作。

盘点了集团的数据状况之后，心里已经隐隐有了方向，各自为政的数据文化、分散割裂的业务系统、盘根错节的数据应用，不能仅依靠自身的力量，要借助外力来共同推动。合适的供应商伙伴和统一的技术平台工具，是SL目前最需要的，也是项目成败的关键因素。

今天周末，天气不错，约上姚冰，一起去爬山，然后在我俩都最爱的那家铜炉火锅店，一边喝点小酒，一边讨论接下来技术伙伴和平台选型的相关细节。

“姚冰，基于你的那份集团数据应用评估报告，当务之急是选择一个好伙伴和一套合适的系统，将集团纷繁复杂的数据汇聚、加工、管理并运营起来。”

对于伙伴的选择，姚冰认为首要条件是能提供有技术实力的大数据平台以及丰富的行业实践经验。这当然是无可厚非的，但是我又补充了一点，这也是一大加分项——具备“指导企业建立数据用起来机制”的一套数据中台建设方法论，譬如组织架构的设计、数据资产的管理与运营、数据安全的构建、数据人才的培养等。这对企业来说意义非凡，它能让企业的数据能力沉淀下来，成为最为宝贵的数据资产，进而成为企业创新源动力的核心引擎。

而对于系统的选择，至少需要具备这3个条件：

第一，支持足够丰富的存储形式，不仅仅是结构化的系统数据，还需要支持半结构化的日志和非结构化的视频；

第二，伸缩性足够好，至少能满足集团未来五年的数据增量需求；

第三，有一个良好的生态和足够多的工具支持。

“同时满足这三个条件的，开源的Hadoop是符合需求的，其他的系统也可以调研下，一周后汇报……”

话音刚落，姚冰就乐了：“刘总，不用一周，最近正在查找相关资料，正如您所言，Hadoop这套体系确实比较合适。”

目前国内外的商业公司使用大数据主要有两种方式：

第一种是自成体系的封闭系统，从分布式的存储到计算等一系列技术都自成一体，例如大数据技术的开创者Google；

第二种是和开源的大数据技术生态一起发展，例如Cloudera、开源项目Hadoop的很大一部分代码都是这家公司贡献的。

姚冰更倾向于选择开源生态，因为后续可以有更大的自主掌控权，而且生态周边遇到的问题共性比较多，加上商业公司的支持，未来的可维护性更好，同时生态周边的玩家更多，有大量的工具可以选择。

“不错，那相关的工具选择你有什么看法？”我继续深入。

姚冰娓娓道来：“要做到将数据汇聚在一起，并且满足当前各个分散数据仓库的需求，需要的工具主要分为两大类：一类是数据采集交换类，一类是数据开发类。”

对于数据采集交换类的工具，主要有以下几种场景：

·业务系统的数据库数据同步；

·系统日志数据同步；

·非结构化数据同步；

·互联网公开数据爬取。

第一，数据库数据的同步。有很多工具供选择，例如开源的Sqoop、Oracle的收费软件Imformatica、阿里巴巴内部使用并开源的DataX等。

第二，系统日志的同步。开源的工具有Flume、logstash、fluentd等，商业公司的有阿里的loghub，以及日志易的日志采集汇聚等。

第三，非结构化数据同步。这种场景因为情况复杂多样，市面上没有专门的工具，部分功能是和其他功能集成在一起的，例如阿里云的数据同步工具有同步OSS数据到MaxCompute的功能，大多数企业最开始会使用一些基础技术如Lsyncd传输数据。

第四，互联网数据爬取。这方面的商业化工具其实是最多的，开源的有Nutch，已经非常成熟了。

对于数据开发类工具，技术层面主要分为离线或批量数据处理类、实时或流式数据处理类以及算法和人工智能类三大类技术栈。用于离线批量数据处理的工具和用于实时流式数据处理的工具，有的公司是通过一个产品来支持，有的公司分为两个产品；用于算法和人工智能的工具一般是单独一个产品。

市面上可见的数据开发类工具目前主要分为开源和商业化产品两大类，数据同步和数据开发的工具开始融合，作为一个整体进行输出。开源的数据开发类工具有基于Hadoop的HUE、zeppelin、kettle，商业的有IBM的InfoSphere DataStage，Cloudera的CDH和CDP，国内有阿里的DataWorks，腾讯的TBDS，网易的猛犸，数澜的数栖。另外，有些产品的源代码是开源的，但是商业维护是收费的，如Talend的Data Integration。算法类工具开源的有Jupyter，商业的有阿里云的PAI、腾讯的智能钛、第四范式的Sage AI等。这些工具都能不同程度地兼容Python、Spark MLlib、TensorFlow、MXNet等各类算法库和算法框架。

“那你的结论是？”

“我觉得可以尽量选择一些基于开源生态并且兼容性好的商业化工具，这样既能用上大数据技术，而且不会对公司已有的信息系统形成技术入侵，也不会改变原有的技术栈。”

“那就是说，不会再出现以往上新系统，老系统都需要推倒重来的情况了？”这点尤其重要，这意味着公司可以以一个较低的成本和门槛落地数据中台。

“对，这类工具有完美的底层适配能力，完全可以基于公司已有系统进行搭建，而且未来面对特殊的需求时能够很好地扩展，在紧急情况下也能得到专业的服务。”

姚冰说出了自己的判断，与我心中的想法不谋而合。

数据中台建设、管理、应用的核心是数据，那么数据中台中的数据采用的是什么体系结构？使用的是什么建设方法？本章就来对数据体系建设进行说明。

随着信息化、互联网、物联网、智能化的发展，数据积累越来越多。都知道数据是企业的资产，但杂乱的数据是无法产生业务价值的。本章将介绍数据的分层，以及每一层的建设规范、建设方法、采用的模型，让读者不仅对中台数据体系有一个总体了解，并且可以在实际工作中利用本章介绍的方法建设自己的数据体系。

数据中台是企业数据汇聚地，企业的一切数据都汇聚到数据中台，企业业务所需的数据总能在数据中台找到。但数据中台中的数据并不是简单地堆积，各种系统产生的原始数据堆积在一起导致使用成本非常高，这类数据只能在某些数据技术基础非常好的部门使用，而且会经常出现命名不一、口径不一的问题，从而导致整个企业数据无法真正用起来。数据中台数据体系是在全域原始数据的基础上，进行标准定义及分层建模，数据体系建设最终呈现的结果是一套完整、规范、准确的数据体系，可以方便支撑数据应用。

中台数据体系应具备以下特征：

·覆盖全域数据：数据集中建设，覆盖所有业务过程数据，业务在中台数据体系中总能找到需要的数据。

·结构层次清晰：纵向的数据分层，横向主题域、业务过程划分，让整个层次结构清晰易理解。

·数据准确一致：定义一致性指标，统一命名、统一业务含义、统一计算口径，并有专业团队负责建模，保证数据的准确一致。

·性能提升：统一的规划设计，选用合理的数据模型，清晰地定义并统一规范，并且考虑使用场景，使整体性能更好。

·降低成本：数据体系的建设使得数据能被业务共享，这避免了大量烟囱式的重复建设，节约了计算、存储和人力成本。

·方便易用：易用的总体原则是越往后越能方便地直接使用数据，把一些复杂的处理尽可能前置，必要时做适当的冗余处理。比如在数据的使用中，可以通过维度冗余和事实冗余来提前进行相关处理，以避免使用时才计算，通过公共计算下沉、明细与汇总共存等为业务提供灵活性。统一数据体系的建设让整个企业的业务都有机会使用数据。

为了使数据体系在建设时具备以上特征，需要一个体系化的数据层次架构，这个层次架构定义了数据分层及每一层的模型建设规范。数据体系架构是一套指导规范，实施过程中应严格按照架构执行。下面以某地产公司为例，来分析适合绝大多数企业的数据中台数据体系架构，如图7-1所示。

图7-1　数据中台数据体系架构

图7-1中涉及了以下四个数据分层：

·贴源数据层ODS（Operational Data Store，又称操作数据层）：对各业务系统数据进行采集、汇聚，尽可能保留原始业务流程数据，与业务系统基本保持一致，仅做简单整合、非结构化数据结构化处理或者增加标识数据日期描述信息，不做深度清洗加工。

·统一数仓层DW（Data Warehouse）：又细分为明细数据层DWD（Data Warehouse Detail）和汇总数据层DWS（Data Warehouse Summary），与传统数据仓库功能基本一致，对全历史业务过程数据进行建模存储。对来源于业务系统的数据进行重新组织。业务系统是按照业务流程方便操作的方式来组织数据的，而统一数仓层从业务易理解的视角来重新组织，定义一致的指标、维度，各业务板块、业务域按照统一规范独立建设，从而形成统一规范的标准业务数据体系。

·标签数据层TDM（Tag Data Model）：面向对象建模，对跨业务板块、跨数据域的特定对象数据进行整合，通过ID-Mapping把各个业务板块、各个业务过程中的同一对象的数据打通，形成对象的全域标签体系，方便深度分析、挖掘、应用。

·应用数据层ADS（Application Data Store）：按照业务的需要从统一数仓层、标签数据层抽取数据，并面向业务的特殊需要加工业务特定数据，以满足业务及性能需求，向特定应用组装应用数据。

另外，建设过程中数据的读取也有严格的规范要求。按照规范，贴源数据层直接从业务系统或日志系统中获取数据。贴源数据层的数据只被统一数仓层使用，统一数仓层数据只被标签层和应用层使用。贴源数据层、统一数仓层只保存历史数据以及被标签层、应用层引用，不直接支撑业务，所有业务使用的数据均来源于标签层和应用层。

在实际建设过程中，由于业务使用数据都非常紧急以及统一数仓层建设跟不上业务的需要，所以标签层、应用层也可以直接引用贴源数据层数据，这种不规范操作有可能导致出现数据口径不一致的情况。待统一数仓层建设完毕，要切换回统一数仓层来支撑标签层或者应用层。

由于贴源数据层仅做业务数据的同步与存储，应用数据层面向特定业务组装数据，这两层没有太多的建模规范，故只做简单介绍。下面会重点介绍统一数仓层与标签数据层的建设，尤其是标签数据层，因为它是更能体现大数据能力的一层。

贴源数据层会对企业各业务系统数据进行汇聚整合，保留企业全量业务原始数据，并作为统一数仓层建设的数据源。贴源数据层数据不仅是业务数据库中产生的数据，跟企业相关的所有数据都应该汇聚到贴源数据层，包括业务系统数据、业务运行的日志数据、机器运转产生的日志数据、网络爬虫或者其他方式获取的外部数据。

贴源数据层也称操作数据层，是数据体系架构中最接近数据源的一层，是全企业业务数据的集中存储处，除了对非结构化数据进行结构化处理以及对相同数据进行整合外，并不对业务数据做过多的清洗加工，尽可能保留数据的原始状态。贴源数据层建设的目标就是把企业的全域原始数据都汇聚到数据中台，从而能在数据中台查询到所有的企业数据，为后面的统一数仓层、标签数据层、应用数据层建设做准备。

数据中台的贴源数据层数据获取方式与传统数仓的ETL（Extract-Transform-Load）过程类似，但也有不同。传统数仓的ETL过程是在抽取（Extract）和装载（Load）的过程中进行清洗转换（Transform）操作，装载到数仓的是被清洗转换后的数据。这样的方式如果转换规则复杂，就会导致在ETL过程中消耗大量的计算资源，另外如果转换有错误，由于没有保留原始数据，则会导致在数仓层面无法追溯问题。进入大数据时代，由于存储成本降低和数据量增大，导致ETL过程中的复杂处理非常耗时，因此建议采用ELT（Extract-Load-Transform）方式，即将所有原始数据都抽取到数据中台的贴源数据层，在数据中台内部再利用大数据底层平台的计算能力进行转换操作。这样既可让数据的抽取过程尽可能简单，又保留了所有的原始数据，以便于问题的追溯，还能充分利用大数据的计算能力。图7-2所示为数据中台数据抽取并进行转换的过程。

虽然也把贴源数据层称为ODS层，但是它与ODS系统还是有所区别的。贴源数据层仅做多源数据的汇聚、整合，并不具备传统意义上的ODS系统的功能，ODS系统的数据交换、实时性、报表等功能需要通过数据中台其他功能模块实现。

图7-2　数据中台数据抽取转换过程

按照数据结构类型的不同，贴源数据可以分为三类：

·结构化数据：主要是关系型数据库中的数据，直接从业务系统DB抽取到贴源数据层。

·半结构化数据：一般是纯文本数据，以各种日志数据为主，半结构化数据保留贴源数据的同时也做结构化处理，为后续使用做准备。

·非结构化数据：主要是图片、音频、视频，一般保留在文件系统中，由于这类数据量一般比较庞大，而且没有太多挖掘分析价值，所以贴源数据层不保留原始文件，只保留对原始数据文件的描述，比如地址、名称、类型、分辨率等。

贴源数据层中的数据表与对应的业务系统数据表原则上保持一致，数据结构上几乎不做修改，所以参考业务系统数据表结构来设计贴源数据层表结构即可，结构设计上没有太多的规范要求。考虑到业务系统数据的多样性，贴源数据层数据表的设计要遵循一定的规范。

贴源数据层数据表设计规范如下：

·贴源数据层表的命名采用前缀+业务系统表名的方式。比如，ODS系统简称业务系统表名，这样既可以最大限度保持与业务系统命名一致，又可以有清晰的层次，还可以区分来源。

·贴源数据层表的字段名与业务系统字段名保持一致，在ODS层不做字段命名归一。字段类型也尽可能保持一致，如果数据中台没有与业务系统对应的数据类型则用一个可以兼容的数据类型。比如，业务系统的数据类型是float，数据中台的存储系统没有float类型，则可以用double代替。

·对于一些数据量较大的业务数据表，如果采用增量同步的方式，则要同时建立增量表和全量表，增量表利用后缀标识。比如，ODS系统简称业务系统表名_delta，汇聚到增量表的数据通过数据加工任务合并生成全量表数据。

·对于日志、文件等半结构化数据，不仅要存储原始数据，为了方便后续的使用还要对数据做结构化处理，并存储结构化之后的数据。原始数据可以按行存储在文本类型的大字段中，然后再通过解析任务把数据解析到结构化数据表中。

通过以上建设规范，可保障企业所有业务数据按照一致的存储方式存储到数据中台。

贴源数据层一般采用数据同步工具实现数据的同步落地。具体的实现步骤如下：

1）确定业务系统源表与贴源数据层目标表；

2）配置数据字段映射关系，目标表可能会增加采集日期、分区、原系统标识等必要信息，业务相关内容不做转换；

3）如果是增量同步或者有条件地同步部分数据，则配置数据同步条件；

4）清理目标表对应数据；

5）启动同步任务，往贴源数据层目标表导入数据；

6）验证任务是否可以正确运行，并且采集到准确数据；

7）发布采集任务，加入生产调度，并配置相关限速、容错、质量监控、告警机制。

贴源数据层只对企业各个来源的数据做汇聚、整合，并没有做过多的加工处理，数据基本还是原始结构。且业务系统更多是按照流程组织数据，为保证流程的完整、方便，没有按照业务的本质来组织数据，贴源数据并不方便业务理解，更不适合做分析、挖掘。

统一数仓层站在业务的视角，不考虑业务系统流程，从业务完整性的角度重新组织数据。统一数仓层的目标是建设一套覆盖全域、全历史的企业数据体系，利用这套数据体系可以还原企业任意时刻的业务运转状态。只要能达到这个目标，利用范式建模、维度建模、实体建模中任意一种建模方法都是可以的，这里主要介绍维度建模，因为它更适合大数据时代数据量巨大的特点。

维度建模是实现统一数仓层建设目标的一种推荐建模方式，它用事实表、维度表来组织数据，这种技术已经有近30年的历史，经过大量案例考验，证明这套简单的模型技术满足建模需求。维度建模具备以下特点：

模型简单易理解：仅有维度、事实两种类型数据，站在业务的角度组织数据。

·性能好：维度建模使用的是可预测的标准框架，允许数据库系统和最终用户通过查询工具在数据方面生成强大的假设条件，这些数据主要在表现和性能方面起作用。

·可扩展性好：具有非常好的可扩展性，以便容纳不可预知的新数据源和新的设计决策。可以在不改变模型粒度的情况下，很方便地增加新的分析维度和事实，不需要重载数据，也不需要为了适应新的改变而重新编码。良好的可扩展性意味着以前的所有应用都可以继续运行，并不会产生不同的结果。

·数据冗余：由于在构建事实表星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些预处理过程中，往往会导致大量的数据冗余。

大数据时代，数据是资产，数据应该在业务中发挥更大作用，而易理解、易用、性能好、扩展性好的模型技术能让数据更方便参与业务。随着技术的发展，存储、计算成本的降低，经常会以存储换取性能和易用性。综上考虑，笔者推荐使用维度建模。

统一数仓层建设过程以维度建模为理论基础，构建总线矩阵，划分业务板块，定义数据域、业务过程、维度、原子指标、修饰类型、修饰词、时间周期、派生指标，进而确定维度表、事实表的模型设计。统一数仓层建设过程如图7-3所示。

图7-3　统一数仓层建设过程

另外，准确定义术语非常关键，有时候描述不清楚复杂流程和场景的根本原因是没有厘清其中的一些概念。本节介绍维度建模设计的核心概念，后续的建模工作都是围绕这些概念展开的，了解这些概念有助于理解整个模型技术。

·业务板块：根据业务的属性划分出的相对独立的业务板块，业务板块是一种大的划分，各业务板块中的业务重叠度极低，数据独立建设，比如地产板块、金融板块、医疗板块等。

·模型设计：以建模理论为基础，基于维度建模总线架构，构建一致性的维度和事实，同时设计出一套表命名规范。

·数据域：数据域是统一数仓层的顶层划分，是一个较高层次的数据归类标准，是对企业业务过程进行抽象、提炼、组合的集合，面向业务分析，一个数据域对应一个宏观分析领域，比如采购域、供应链域、HR域等。数据域是抽象、提炼出来的，并且不轻易变动，既能涵盖当前所有业务需求，又能在新业务进入时无影响地将其分配到已有的数据域中，只有当所有分类都不合适时才会扩展新的数据域。数据域是有效归纳、组织业务过程的方式，同时方便定位指标/度量。

·业务过程：业务过程是一种企业的业务活动事件，且是企业经营过程中不可拆分的行为事件，比如下订单、银行转账、账号注册都是业务过程。业务过程产生度量，并且会被转换为最终的事实表中的事实。业务过程一般与事实表一一对应，也有一对多或者多对一的特殊情况，比如累计快照事实表就会把多个业务过程产生的事实在一张表中表达。

·修饰词：修饰词指除统计维度以外的对指标进行限定抽象的业务场景词语，修饰词隶属于一个修饰类型。比如，在日志域的访问终端类型下，有修饰词PC、无线端。修饰类型的出现是为了方便管理、使用修饰词。

·原子指标：原子指标是针对某一业务事件行为的度量，是一种不可拆分的指标，具有明确业务含义，比如支付金额。原子指标有确定的字段名称、数据类型、算法说明、所属数据域和业务过程。原子指标名称一般采用“动作+度量”方式命名，比如支付金额、注册用户数。

·派生指标：派生指标可以理解为对原子指标业务统计范围的圈定，比如最近1天北京买家支付金额（“最近1天”是时间周期，“北京”是修饰词，修饰词“买家”是维度）。派生指标=1个原子指标+多个修饰词+时间修饰词。

·计算方法：指标的数学计算方式，比如汇总、平均、最大、最小等。

·维度表：维度是观察事物的角度，提供某一业务过程事件所涉及的用于过滤及分类事实的描述性属性，用于描述与“谁、什么、哪里、何时、为什么、如何”（5W1H）有关的事件。比如“早上小王在小卖部花费5元钱购买了一个面包”，以购买为业务过程进行分析，可从这段信息中提取三个维度，即时间维度（早上）、地点维度（小卖部）和商品维度（面包）。维度表是统一设计的，在整个数据仓库中共享，所有数据域、业务过程都需要用到维度，都可以在公共维度表中获取相关维度属性。

·事实表：事实是观察事物得到的事实数据，事实涉及来自业务过程事件的度量，基本都是以数量值表示，比如一次购买行为就可以理解为是一个事实，5元就是事实信息。在确定数据域与业务过程后，就可以根据业务过程涉及的维度、度量及粒度，设计相关的事实表。事实表不跨数据域，根据需要，一个事实表可能对应同数据域下一个或者多个业务过程。事实表又分为明细事实表和汇总事实表。明细事实表记录事务层面的事实，保存的是原子数据，数据的粒度通常是每个事务一条记录，明细事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。汇总事实表是把明细事实聚合形成的事实表，包括以具有规律性的、可预见的时间间隔来记录事实的周期快照事实表和以不确定的周期来记录事实的累计快照事实表。

·粒度：粒度是指统一数仓层数据的细化或综合程度，对各事实表行实际代表的内容给出明确的说明，用于确定某一事实表中的行表示什么。确定维度或者事实之前必须声明粒度，因为每个维度和事实都必须与定义的粒度保持一致。原子粒度是最低级别的粒度，是对业务过程最详细的刻画，原子粒度事实必须保留。

·一致性指标定义：指标归属到具体数据域，定义指标的含义、命名、类型、计算方法，确保指标的全局一致性。

数据域是指面向业务或数据进行本质分析，归纳总结出来的数据集合。为保障整个体系的生命力，数据域需要抽象提炼，并且长期维护和更新，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地将其插进已有的数据域中或者扩展新的数据域。具体数据域划分过程如下：

·业务调研：确定项目要涵盖的业务领域和业务线，以及各个业务线可以细分成哪几个业务模块，各业务模块具体的业务流程是怎样的，通过跟业务专家访谈或进行资料文档收集，梳理主要业务流程、业务边界、专业术语等。

·数据调研：调研全部数据目录信息，梳理数据流与业务过程关联关系。

·业务过程提取：根据调研结果抽取出全部业务过程。

·业务过程拆分：将组合型的业务过程拆分成一个个不可分割的行为事件，如下单、支付、收货、退款。

·业务过程分类：按照业务分类规则，将相似特征的业务过程分为一类，且每一个业务过程只能唯一归属于一类。

·业务分类确认：对业务分类结果再次确认，避免分类范围中出现业务特征明显与其他业务过程无关的情况。

·数据域定义：根据业务分类的规律总结出划分业务范围的标准定义。

·数据域命名：为每个数据域起一个专属名称，并附上英文全称和简称。

指标就是在企业业务运转过程中产生的度量事实，一致性指标设计是为了在企业内外部使指标的命名、计算方法、业务理解达到一致，避免不同部门同一个指标的数据对不上或者对同一个指标的数据理解不一致。

一致性指标的定义为，描述原子指标、修饰词、时间周期和派生指标的含义、类型、命名、算法，被用于模型设计，是建模的基础。派生指标的生成过程如图7-5所示。

图7-5　派生指标生成过程示例

一致性指标设计是事实表模型设计的来源，有了一致性的指标定义，在设计事实表模型时引用定义好的一致性指标，可达到指标的一致性与标志性。

维度是维度建模的基础和灵魂，维度表设计得好坏直接决定了维度建模的好坏。维度表包含了事实表所记录的业务过程度量的上下文和环境，它们除了记录5W等信息外，通常还包含了很多描述属性字段。每个维度表都包含单一的主键列。维度设计的核心是确定维度属性，维度属性是查询约束条件（SQL where条件）、分组（SQL group语句）与报表标签生成的基本来源。维度表通常有多列或者说多个属性。维度表通常比较宽，是扁平型非规范表，包含大量细粒度的文本属性。实际应用中，包含几十甚至上百个属性的维度并不少见。维度表应该尽可能包括一些有意义的文字性描述，以方便下游用户使用。维度属性尽可能丰富。维度属性设计中会有一些反规范化设计，把相关维度的属性也合并到主维度属性中，达到易用、少关联的效果。

维度表设计主要包括选择维度、确定主维表、梳理关联维表、定义维度属性等过程。

1）选择维度： 维度作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。维度一般用于查询约束条件、分组、排序的关键属性，维度既可以从报表需求中分析获取，也可以从与业务人员的交谈中发现。

2）确定主维表： 主维表一般直接从业务系统同步而来，是分析事实时所需环境描述的最基础、最频繁的维度属性集合。比如用户维表从业务系统的用户基本信息表中产出。

3）梳理关联维表： 数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。如商品与类目、SPU、卖家、店铺等维度存在关联关系。

4）定义维度属性： 从主维表或关联维表中选择维度属性或生成新的维度属性，过程中尽量生成更丰富、更通用的维度属性，并维护和描述维度属性的层次及关联关系。如商品维表，商品属于类目，类目属于行业。

事实表是统一数仓层建设的主要产出物，统一数仓层绝大部分表都是事实表。一般来说事实表由两部分组成：一部分是由主键和外键组成的键值部分，另一部分是用来描述业务过程的事实度量。事实表的键值部分确定了事实表的粒度，事实表通过粒度和事实度量来描述业务过程。事实表的外键总是对应某个维度表的主键，实际建设和试用过程中，为了提升事实表的易用性和性能，不仅会存储维度主键，还会把关键的维度属性存储在实施表中。这样事实表就包含表达粒度的键值部分、事实度量及退化的维度属性。一切数据应用和分析都是围绕事实表来展开的，稳定的数据模型能大幅提高数据复用性。

在Kimball的维度建模理论中主要定义了事务事实表、周期快照事实表、累积快照事实表三种类型的事实表。

·事务事实表：事务事实表描述业务过程事务层面的事实，每条记录代表一个事务事件，保留事务事件活动的原始内容。事务事实表中的数据在事务事件发生后记录，一般记录后数据就不再进行更改，其更新方式为增量更新。事务事实表相对其他事实表保存的数据粒度更细，可以通过事务事实表对事务行为进行详细分析。

·周期快照事实表：周期快照事实表以具有规律性、可预见的时间间隔产生快照来记录事实，每行代表某个时间周期的一条记录，记录的事实是时间周期内的聚集事实值或状态度量。周期快照事实表的内容一般在所表达的时间周期结束后才会产生，一般记录后数据就不再更改，其更新方式为增量更新。周期快照事实表一般是建立在事务事实表之上的聚集，维度比事务事实表少，粒度比事务事实表粗，但是由于对事实进行了多种形式的加工从而产生了新的事实，故一般事实会比事务事实表多。

·累计快照事实表：累积快照事实表覆盖一个事务从开始到结束之间所有的关键事件，覆盖事务的整个生命周期，通常具有多个日期字段来记录关键事件时间点。周期快速事实表涉及的多个事件中任意一个的产生都要做记录，由于周期快照事实表涉及的多个事件的首次加载和后续更新时间是不确定的，因此在首次加载后允许对记录进行更新，一般采用全量刷新的方式更新。

累计快照事实表一般用于追踪某个业务的全生命周期及状态转换，比如交易业务，涉及下单、支付、发货、确认收货，这些相关事件在不同的事务事实表中，通过事务事实表很难看到不同事件之间的转化及状态变化，通过累计快照事实表可把相关事件串起来放在一条记录中，这样就很容易解决了。

不管哪种类型的事实表，设计方法都类似，事实表设计可以遵循以下步骤：

企业业务是由一个个业务过程组成的，事实表就是为了记录这些业务过程产生的事实，以便还原任意时刻的业务运转状态。所以设计事实表，第一步就是确定实施所要表达的是哪一个或者几个业务过程。笔者理解业务过程是企业活动事件，比如注册、登录、下单、投诉等都是业务过程，最基本的是每一个业务过程对应一张事实表，这样最容易理解。但是实际开发过程中，业务过程和事实表会存在多对多的关系。

不管事实表对应一个还是多个业务过程，粒度必须是确定的，每个事实表都有且只能有唯一的粒度，粒度是事实表的每一行所表示的业务含义，是事实的细节级别。在实际设计过程中，粒度与主键等价，粒度更偏向业务，而主键是站在技术角度说的。虽然粒度在最终的事实表中很难被体现，但是定义粒度是必不可少的步骤，这样可避免整个事实表的业务含义模糊。

定义粒度之后，事实表每一行的业务含义就确定了。那么业务人员会站在哪些角度来描述事实度量？这就要确定维度了，常见的维度有时间、区域、客户、产品、员工等。维度依附于粒度，是粒度的环境描述。

事实就是事实表度量的内容，也就是业务过程产生的事实度量的计算结果，比如注册量、登录次数、交易金额、退款量等。事实表的所有事实度量都与事实表所表达的业务过程相关，所有事实必须满足第二步所定义的粒度。

事实表的设计要综合考虑数据来源和使用需求，在满足业务事实记录的同时也要满足使用的便利性和性能要求。大数据时代，事实表记录数动辄亿级，甚至数十亿、数百亿，维表也有可能达到亿级甚至更多。利用标准维度模型会经常出现维表与事实表关联的情况，这种对亿级表的关联计算，在性能上是灾难性的。为了满足业务需求，降低资源消耗，建议适当冗余维度属性数据到事实表，直接利用事实表就可以完成绝大部分业务的使用需求，这样下游使用时可减少大表关联，提升效率。所以大数据时代，适当进行维度冗余是可取的。

注意：维度属性冗余与模型的稳定性是有矛盾的，因为维度的属性是有可能改变的，如果属性已经冗余到事实表中，那么维度属性就与事实一起被记录到事实表中。如果后续维度属性值改变，由于事实表已经生成，事实表的内容基本不会再做改变，这样就会出现已记录的维度属性与真实的维度属性不一致，导致数据错误的情况。属性的冗余是一种优化建议，冗余带来的收益与弊端要综合考虑。

经过以上数据域的划分、指标的定义、维表设计、事实表设计，就完成了整个统一数仓层的设计工作。接下来要在数据开发平台结合数据平台工具，进行统一数仓层的物理层面的建设。模型结构与内容已经确定，仅仅需要代码和运维层面的实施。

落地实施的具体步骤如下：

1）按照命名规范创建表，包括维表和事实表；

2）开发生成维表和事实表的数据的逻辑代码；

3）进行代码逻辑测试，验证数据加工逻辑的正确性；

4）代码发布，加入生产调度，并配置相应的质量监控和报警机制；

5）持续任务运维监控。

统一数仓层是按照数仓的维度规范建模，对业务数据进行了重新组织标准化。但是同一个对象的各种信息分散在不同的数据域并且有不同的数据粒度。比如客户数据，基本信息在客户域按照客户粒度组织，交易信息在交易域按照订单粒度组织，社交信息在社交域按照关系对粒度组织，这导致很难了解一个客户的全面信息，要通过各种关联计算才能满足业务的需要，数据使用成本较高。而获取、分析客户的全面数据，是多个业务的共同需求，这可以通过建设标签数据层来满足。大数据的典型应用基本都是通过建立标签体系来支撑的，大数据的核心价值和魅力通过标签数据的多样应用得到充分体现。

标签数据层是面向对象建模，把一个对象各种标识打通归一，把跨业务板块、数据域的对象数据在同一个粒度基础上组织起来打到对象上。标签数据层建设，一方面让数据变得可阅读、易理解，方便业务使用；另一方面通过标签类目体系将标签组织排布，以一种适用性更好的组织方式来匹配未来变化的业务场景需求。

标签归属到一个对象，标签按照产生和计算方式不同可分为属性标签、统计标签、算法标签。对象本身的性质就是属性标签。对象在业务过程事件中产生原子指标，原子指标与修饰词、计算方法可以组装出统计标签。对象在多个业务过程的规律特征通过一定的计算方法可以计算出算法标签。另外对象在特定的业务过程会与其他对象关联，关联对象的属性也可以作为标签打在主对象上。对象的属性标签、统计标签、算法标签与对象标签类目、对象标识组装起来就生成对象标签表。对于对象标签表来说一切都是标签，并没有严格的维度与事实的区分，笔者称对象标签表为标签融合表。

图7-6所示为标签融合表的建设过程，其中涉及很多名词，业务过程、原子指标、修饰类型、修饰词、计算方法等在统一数仓层已经做了介绍，这里主要介绍新出现的对象、对象标识、标签、标签类目、属性标签、统计标签、算法标签、标签融合表等名词。

图7-6　标签融合表建设过程

·对象：是客观世界中研究目标的抽象，可以是现实存在的，也可以是虚拟的，是具备独立特征的个体，比如自然人、产品、账户等。

·对象标识：对象的标识符用以标识一个对象，一般是各种ID，比如手机号、身份证、登录账号。

·标签：利用原始数据，通过一定的加工逻辑产出，能够为业务所直接使用的可阅读、易理解、有业务价值的数据。

·标签类目：是标签的分类组织方式，是标签信息的一种结构化描述，目的是管理、查找标签，一般采用多级类目。

·属性标签：属性是对实体基本性质的刻画，属性的变化非常缓慢，有些甚至永远固定，属性是一类实体区别于另一类实体的差异所在。属性标签是根据人类对实体的长期认知得出的，比如性别、年龄、体重。

·统计标签：统计标签是特定场景下，维度和度量的组合。构建出实体所在场景的维度、度量矩阵，就可以根据经验和实际业务需要组装统计标签，比如日均登录次数、最近30天交易额。

·算法标签：算法标签是不可以直接获取的，需要通过复杂逻辑分析推理得出，是通过分析对象在多个场景下发生多个事件的规律性得出的相关结论，比如信用指数、购买能力、品牌偏好。

·标签融合表：以对象为核心把属性标签、统计标签、算法标签组装起来得到的表，是标签数据层落地的产出物。标签融合表设计要考虑标签的类目结构进行合理组织。

进行标签建设，首先要清楚对哪类对象建设标签，也就是确定对象。对象是客观世界中研究目标的抽象，有实体的对象，也有虚拟的对象。在企业经营过程中可以抽象出非常多的对象，这些对象在不同业务场景下交叉产生联系，是企业的重要资产，需要全面刻画了解。

经过对多个行业、多个标签体系建设经验的总结，可把对象分为“人”“物”“关系”三大类。其中“人”包括自然人、自然人群体、法人、法人群体等，例如消费者、消费者协会、电商企业、电商企业联合会，这类是可以主动发起行为的主体。“物”包括物品、物体、物品集合等，例如商品、仓库等，是行为中的被施与对象。关系指的是人、物、人和物、人和人、物和物在某时某刻发生的某种行为、关联、关系，包括行为关系、归属关系、思维关系等各种强弱关系，例如购物、运货、聊天、监管等。因此可以采用这种对象识别方法，将现实世界中的一切事物、关系通过这种方式一一对应到相应的对象分类中。

三种对象是不一样的，“人”往往具有主动性和智慧，能主动参与社会活动，主动发挥推动作用，往往是关系的发出者。“物”往往是被动的，包括原料、设备、建筑物、简单操作的工具或功能集合等，是关系的接收者。当常规意义上的设备具有了充分的人工智能，变成了机器人，那么它就属于“人”这一类对象。“人”和“物”是实体类的对象，即看得到、摸得着的对象，而“关系”属于一种虚拟对象，是对两两实物实体间的联系的定义。因为关系很重要，企业大多数情况下反而是在对关系进行定义、反复发生、记录、分析、优化，因此需要“关系”这种对象存在，对关系进行属性描述和研究。关系按照产生的动因不同，又分为事实关系和归属关系，事实关系会产生可量化的事实度量，归属关系只是一种归属属性。

明确了对象的定义和分类，就可以根据业务的需要确定要对哪些对象建立标签体系。企业的对象非常多，不会对所有对象都建立标签体系，一般都是选择典型的对象建立标签体系，比如客户、员工、产品、设备等。一种对象标签体系的建设并不会影响另一种对象标签体系的建设，可以根据资源和业务紧急度，合理安排标签体系建设的前后关系。

在确认对象后，由于存在同一个对象在多个不同业务中的标识ID不同的情况，因此需要将同一个具体对象的不同ID标识打通，以便所有业务数据都能在该对象上打通，完成对该对象的全面数据的刻画。比如一个自然人，他本身由身份证进行唯一识别，但是他看病时用的是医保账号进行挂号缴费；缴纳水电煤费用时，又有不同的水表账号、电表账号、天然气账号；购买了手机又有手机的设备账号；上网购物会有电商账号，上网聊天会有聊天应用账号……通过不同账号，又记录了各自账号下的大量行为记录，如果需要对一个对象进行全面的数据收集、完整刻画、辨别真伪，就需要将多方数据进行融合打通。要完成对象的ID打通，一般会给每个对象设置一个超级ID，比如SUPER-ID作为唯一识别该对象的标识码，业务系统中不同的对象标识ID都通过一定的算法规则与这个SUPER-ID打通，进而完成对象所有业务标识ID的打通。

ID打通，首先必须有ID-ID之间的两两映射打通关系，通过ID-ID之间两两映射关系表，将多种ID之间的关联打通。比如手机号、身份证号码可以打通，手机号、邮箱账号可以打通，这样通过手机号就可以把身份证号码和邮箱账号也打通了。完全孤立的ID是无法进行打通的。通过ID-ID间的两两映射，打通整个ID关系，看似简单，实则计算复杂，计算量非常大。想象一下，假如某种对象有数亿个个体，每个个体又有数十种不同的ID标识，任意两种ID之间都可能有打通关系，想要完成这类对象的所有个体ID打通需要数亿亿次的计算，一般的机器甚至大数据集群都无法完成。大数据领域中的ID-Mapping技术就是用机器学习算法来取代野蛮计算，解决对象数据打通的问题。基于输入的ID关系对，利用机器学习算法做稳定性和收敛性计算，输出关系稳定的ID关系对，并生成一个SUPER-ID作为唯一识别该对象的标识码。

另外要说明的是，通过算法打通对象的不同ID标识，两两ID之间的打通关系有一定的误差，通过置信度来描述这个误差，置信度越高则误差越小，反之则越大。不同业务根据业务自身的需要，选择不同的置信度，比如要做财务统计，就要100%置信度才行，但是如果是做营销推广，可能80%的置信度就可以了。

一般来说，ID打通是标签体系建设的前提，没有ID打通就无法收集到一个对象的全面信息，也就无法对这个对象进行全面标签化刻画。

企业业务需要使用的标签项一般都会非常之多，当标签项超过50个时，业务人员要使用或查找标签就开始变得麻烦，管理标签也会变得困难。因此笔者借鉴了图书管理学中的经典方法：海量图书需要有专门的图书分类体系对书本进行编号并按照编号分柜排放，阅读者在查阅图书时只需要按编号索引即可快速找到自己所需图书，图书管理员也可以方便、有效地理清所有图书状况。笔者也通过建立对象标签类目体系来对对象的标签进行分类管理。

构建标签类目体系首先需要确定根目录。根目录就是上文提到的对象，因此有三大类根目录：人、物、关系。根目录就像树根一样直接确定这是一棵什么树。如果根目录是人，即这个标签类目体系就是人的标签类目体系，每个根目录都有一个识别列来唯一识别具体对象。人这种大类下包括自然人和企业法人两种亚根，同时自然人群体或企业法人群体也可以认为属于人的对象范畴内，也是亚根。自然人实例可以有消费者（人）、员工（人）、加盟商（人）等，因此可以形成消费者（人）的标签类目体系、员工（人）的标签类目体系、加盟商（人）的标签类目体系。同样法人也可以细分为实体公司（人）、营销公司（人）、运输公司（人）等。自然人群体可以细分为消费者协会（人）、卖家联盟（人）、直播圈（人）等。法人群体可以细分为电商协会（人）、国际品牌公司联盟（人）等。从最大的“人”根目录、到“自然人/法人/自然人群体/法人群体”亚根，再到实例“用户/员工/加盟商”，都属于根目录的范畴。

根据类似的方式，也可以将物细分为“物品”“物体”“物品集合”“物体集合”等亚类，各亚类下也可以细分根；关系也可以细分“关系记录”“关系集合”。电商行业中的物品可以细分为“商品”或“服务”等，进而构建商品标签类目体系、服务标签类目体系。各亚根示例在图7-7所示虚框中的下半部分，上半部分为标签示例。

图7-7　标签对象示例

对根目录展开，可以构建多级类目结构：针对“人”“物”“关系”的标签集都可以分别构建出多级的标签类目体系。

标签类目体系是对业务所需标签采用类目体系的方法进行设计、归属、分类。类目体系本身是对某一类目标物进行分类、架构组织，分类通常使用一级类目、二级类目、三级类目等作为分类名，将item分入合适的类目中，每个具体的item都是叶节点。某大型互联网集团构建的商品类目体系，是对海量商品进行行业类目梳理的经典成功案例，其对所售商品先进行一级分类，分为美妆、女装、母婴、数码、鞋包等；美妆一级分类下有基础护理、彩妆、美发、美体等二级分类；基础护理二级分类下又细分为卸妆、洁面、化妆水、乳液面霜等三级分类，卸妆三级分类下再下挂具体的卸妆油、卸妆液等具体商家商品。

根目录下可以设置类目结构，类目结构可以用树状结构来比拟，根上长出的第一级分支，称为一级类目；从第一级分支中长出的第二级分支，称为二级类目；从第二级分支中长出的第三级分支，称为三级类目。一般类目结构设为三级分层结构即可。没有下一级分类的类目叫叶类目，挂在叶类目上的具体叶子就是标签。没有上一级类目的叫一级类目，有下一级类目的类目则该级类目是下一级类目的父类目，有上一级类目的类目则该级类目是上一级类目的子类目，如图7-8所示。

类目体系的层级构建尽量以用户最容易理解的分类方式展开，因为类目体系存在的核心意义即为帮用户快速查找、管理数据/标签。

数据类目体系建议按照数据采集、存储、管理等系统原有的业务体系进行划分，因为对于数据开发者或数据库管理员来说，按照数据产生、存储等技术方式组织的数据查找方式是最容易理解的，这样划分可以让他们在合适的类目下快速找到所需数据。

图7-8　类目树状结构

标签类目体系则建议按照数据理解、使用、价值等数据应用的角度进行划分，因为标签类目体系的作用是供业务方、产品经理等数据使用者理解、查找、探索业务上所需指标，这是体现数据价值的地方，而这样的划分方式对业务方、产品经理等非技术人员是非常友好的。

没有完全严格、统一的类目体系结构来满足所有客户业务场景的需求，不变的原则是需要按照客户真实业务需求来构建类目结构。

图7-9所示为某银行构建的客户标签类目体系，其中客户是根目录，会由custom_id来进行唯一识别，根目录下有“基本特征”“资产特征”“行为特征”“偏好特征”“价值特征”“风险特征”

“营销特征”等一级类目。“基本特征”一级类目下又分“ID信息”“人口统计”“地址信息”“职业信息”等二级类目。“地址信息”二级类目下再细分为“账单地址”“家庭地址”“工作地址”“手机地址”等三级类目。“账单地址”三级类目下挂有“账单详细地址”“账单地址邮编”“账单地址所在省”等标签。

图7-9　某银行客户标签类目体系示例

将以上各项内容，即人的标签类目体系、物的标签类目体系、关系的标签类目体系汇总后，可以得到一家企业的标签类目体系结构图。以一家服务企业的标签类目体系为例，汇总后包含加盟商（人）的标签类目体系、员工（人）的标签类目体系、消费者（人）的标签类目体系、门店（物）的标签类目体系、仓库（物）的标签类目体系、商品（物）的标签类目体系、交易记录（关系）的标签类目体系、库存记录（关系）的标签类目体系、要货记录（关系）的标签类目体系、销量趋势（关系）的标签类目体系、库存预警（关系）的标签类目体系、订货辅助（关系）的标签类目体系。人/物标签类目体系中的标签除了人/物基本固有属性信息外，也包括各种关系中转化而来的标签。关系的标签类目体系中，包括从业务流程中抽象出的关系，也包括从新建的数据应用或数据业务中抽象出的关系，如图7-10所示。

图7-10　某服装企业标签对象

通常说的标签体系，一般是指一类对象的标签类目+标签。对象标签体系设计的核心是标签类目设计，标签类目设计完成，整个标签体系的框架就有了，接下来要做的就是往每个叶类目下填充有业务价值并且可以加工出来的标签，进而完成整个标签体系的设计。标签类目体系也与标签实现的物理存储相关，这一点会在7.4.6节介绍。

通过标签类目设计，已经有了某类对象的标签体系框架，只是还没有具体的标签内容。标签设计就是设计合适的标签并将其挂载到标签类目。前面介绍标签按照产生和计算方式的不同可以分为属性标签、统计标签、算法标签，每一类标签深挖下去，都可以有无数个。这里探讨什么样的标签才是需要的、有什么原则以及注意事项。

标签本质上是一种对客观世界中实体对象的度量或描述，是经过缜密的逻辑分析和处理后的产物，用以引导发挥数据应用价值。数据必须转化成能帮助业务提升的标签才具有价值，否则就是数据负累。因此大数据业内一直尝试探索的最核心环节就是数据的商业变现，或者叫数据到商机价值之间的桥梁通道建设。

标签即业务需求的数据呈现，商业价值核心承载在标签上，再配以相应的工程化能力，将标签快速、稳定、便捷地输送到业务以供使用，即完成了数据服务过程。

将数据提炼转化为标签的过程就叫标签化，也就是标签设计过程。一个好的标签设计，等于已经完成了好的数据服务50%的工作，标签设计考验的是理解、抽象、提炼、提升业务场景的数据能力。标签设计要充分考虑两大前提条件，如图7-11所示。

图7-11　标签设计的两大前提

1）标签必须是业务上需要的，能体现业务价值，帮助业务人员做出业务判断或者能创造性的地唤醒新业务场景的数据项，在业务中往往会称其为属性、特征、指标、参数等。

2）必须要探查清楚根据业务需求提炼、整理出的标签是否具有数据可行性，是否有原始数据可以用于加工成标签，不能天马行空，没有落地点。

在分析业务需求，设计出初始业务所需标签的基础上，要进行数据可行性分析，剔除没有数据支撑的标签，这是一个筛减调整的过程。数据可行性的判断需要了解数据源有哪些，了解数据普查信息及数据字典信息，充分利用数据设计丰富的标签以保障标签的落地可行性。

了解了标签设计的两个前提条件，就可以着手设计满足条件的标签了。标签的设计是业务需求与经验结合的结晶，是一个漫长的持续迭代的过程，没有一个具体的步骤可以快速构建。提到标签，有一些容易混淆的概念，比如标签类目和标签、标签与标签值。标签设计的内容不仅包括标签名，还要有归属标签类目、计算逻辑、取值范围、安全等级等。另外标签设计也有一些必须关注的事项。厘清标签设计容易混淆的一些概念、设计所包含的内容及注意事项，有助于设计出更规范化、体系化、可扩展的标签体系。

标签根目录指的是标签的对象，往往是一种较为模糊、宽泛、简单的名词或动词，例如购房者、旅游酒店、报修。按照之前提到的大数据思维，世上的一切事物都可以归类为人、物、场景三类对象，因此一个用来指向某个对象的词（名词指向人、物，动词指向场景）都不应该是标签，往往是根目录。在物理层面可以和某张大宽表中的主键对应，这张大宽表是对该主键对象的详细刻画和数据记录。

对对象的拆分及对象的角度、层面或过程，一般是类目，例如基本信息、地理位置、社交关系、功能效用、从属关系、准备、过程、结果等，也往往由名词构成。在物理层面可以和某张具体表对应，多张这样的具体表按照共同的主键关联在一起就可以形成该主键对象的大宽表。

对对象具体属性、特征、信息、内容的字段级刻画，是标签，例如购房者姓名、购房者电话、旅游酒店地址、报修工单号、报修时间，往往由前后两个名词构成，前一次名词作为定语修饰后一个名词。在物理层面可以和某张具体表中的字段对应，因此最近1天报修工单量、最近3天报修工单量、最近7天报修工单量，这些时间维度不同、统计方式和统计对象相同的标签，属于3个标签，因为它的底层由3个字段一一对应。

对对象属性、特征、信息、内容的具体取值，是标签值，例如张三、李四是购房者名称这个标签的标签值，男、女是性别这个标签的标签值，往往由形容词、名词、数字组成。在物理层面可以和某张具体表中的字段值字典对应，标签值有些是可枚举的离散值，有些是不可枚举的连续值。要特别注意的是，往常习惯给别人打标签、贴标签的动作，其实不是在设计标签，而是在设计标签值。例如对某个人的定义“女、20～30岁、白领、活泼开朗”，分别是性别、年龄段、职业、性格标签的具体标签值。

在标签设计实际过程中，经常会碰到的问题是，同一个标签是否能够多挂，即一个标签是否会属于多个叶子类目。在标签体系方法论中，没有严格规定允许还是不允许多挂，方法论的最核心思维是必须结合企业自身需要来设计组织标签类目体系。因此一家企业如果按照自身需要用严格不冗余的做法来组织安排标签分类的话，就不能多挂。如果企业没有严格要求，为了最大限度帮助业务同事用数据的方式理解事物，或在所需场景中找到所需数据，或根据现有数据激发新场景思考设计，则在必要时可以多挂，但这并不意味着所有可以多挂的标签都要多挂，因为那样会引起冗余问题。一般情况下，如果是个别标签具备多种类目归属，是可以多挂的；但是如果是一整片大批量标签都有多重属性，建议单独成立一个类目。总而言之，视企业具体情况而定，做好平衡即可。

标签的标签，即元标签的设计内容主要包括标签类目、标签名、标签加工类型、标签逻辑、值字典、取值类型、示例、更新周期、安全等级、表名、字段名、负责人、完成时间等。其中“标签类目、标签名、标签加工类型、标签逻辑、值字典、取值类型、示例、更新周期、安全等级”偏向业务方向，主要登记与业务所需相关的指标；“表名、字段名、负责人、完成时间”偏向技术方向，主要登记的技术开发实施过程相关的指标。标签设计文档的截图如7-12所示。

1）某具体对象某标签的标签值，只允许有一条记录，即对应在数据表里，是一个字段取值。例如人的某个标签的标签值，在用户表里就一个值一条记录，不存在多条记录，人有“性别”这个标签，每个人的“性别”取值就一个，要么男，要么女，要么未知，不存在男、女两条取值记录。

性别标签容易理解，再举一个复杂一些的例子——“同住时长”标签。该标签可能是人的标签，也有可能是同住关系的标签。如果“同住时长”是人的标签，那么标签取值类型应该是K-V型，记录的是历次同住人同住时长，标签值如“张三：2年；李四：1年”。不允许出现两条标签取值的记录，如“2年”和“1年”，因为标签和标签之间是相互独立的，不存在一个标签必须依赖另一个标签才能使用的情况，因此不能说“同住时长”必须和“同住人”标签联合起来用。从这里也可以看出标签处理和SQL处理的区别。当然如果“同住时长”是同住关系的标签，那么每一次的同住关系记录，就会有一个“同住时长”的标签，这时候同住时长可以是数值型的标签。

图7-12　标签设计文档截图

2）对于人–物–关系各对象标签间的转化，大家可能会认为身份证号、证件号是“用户”的标签，但实际上身份证号、证件号是“物”的标签，要变成“用户”标签，需要转化成“拥有的身份证号”这个标签。同时，由于一个人可能拥有多个证件（身份证、护照、军官证、驾驶证等），因此“拥有的各证件号”就需要是K-V型，通过key来识别证件类型，其标签值应为“身份证：330110**0001；护照：110*001”，而不能直接存证件号码，否则通过“拥有的证件号”取到的号码数值没法区分是什么证件的号码。当然还有一种处理方式是拆成多个标签，如“拥有的护照号”“拥有的军官证号”“拥有的驾驶证号”。

从以上实例中可以发现，不管是物的标签还是关系的标签，都可以按需转化成人的标签，同理也可以实现其他对象类型间的标签转化。

经过以上原则方法，可以设计出符合企业业务需要的标签体系。由于企业的业务在不断变化，数据在不断变化，业务对标签的诉求以及标签的加工方式也在不断变化。所以标签体系建设不是一蹴而就的，而应是一个动态调整的过程。不断更新迭代标签体系，才能更好地支撑业务，更能体现数据价值。

对象的标签体系是对象有价值数据的全域标签，跨业务板块、跨主题，包括属性标签、统计标签、算法标签，比如性别、到达次数、消费额、品牌偏好都是标签。特定对象的标签体系是面向对象组织数据，对于标签表来说并没有维度和事实的区分，所以标签表又称为标签融合表。那么在大数据平台中标签融合表该如何设计呢？

一般标签融合表有两种组织方式：

1）纵表：类似K-V表，每行表示对象的一个标签，通常的表结构如下：

2）横表：就是普通的二维表，每行表示一个对象，包含对象的多个标签，表结构如下：

通过以上表结构，对纵表和横表做个对比：

1）模型稳定性：纵表模型比较稳定，要增加新的标签时增加记录即可而无须修改模型结构；横表模型不稳定，只要增加或者修改标签元数据，都会涉及模型的修改。

2）易用性：横表就是普通的二维表，比较容易理解，另外现在市面上大部分数据处理技术都是面向二维表的，横表易用性较高。纵表类似K-V表，只适合做单值的查询，对于复杂计算都不方便，易用性较差。

3）性能：纵表每增加一个标签，就要所有对象都增加一条记录，假如有1亿个对象，每个对象有1000个标签，那么用纵表将是有1000亿条记录的标签表，这个数据量对于任何一个平台来说处理都是非常难的。而横表增加标签仅增加列，不管有多少标签，行数都是跟对象数相同的，性能相对较好。

大数据时代，用户或者设备动辄数以亿计，性能是不得不考虑的因素，而且方便易用的数据服务是数据中台建设的主要目标，模型的不稳定可以通过平台技术来屏蔽。推荐使用横表的方式设计标签融合表，以满足性能和易用性的要求。

横表作为标签融合表落地的设计方式，标签数据该如何组装呢？是用一张表还是多张表？由于标签众多，一般不会用一张标签融合表来存储所有标签，而是通过多张融合表来存储标签。融合表与标签类目对应，尽可能把相同类目的信息挂载在同一张表中，图7-13所示为标签类目与融合表的对应关系。另外要考虑标签数量的均衡性，不要有些表有数百个标签，有些表只有几个标签。标签融合表中的标签数量尽量均衡，如果某个类目下标签太多，考虑在下一级类目建表。在考虑了标签类目、标签数的均衡性的基础上，再结合标签本身，就完成了标签融合表的设计。

图7-13　标签类目与融合表对应关系

注：如果一张融合表中大部分标签的产出时间较早，某个标签产出时间特别晚，也要考虑要不要把产出晚的标签移出该表或者做特殊处理。

经过对象的确定、对象ID打通、标签类目设计、标签设计、标签融合表设计，就完成了标签数据层一个对象的模型设计工作。标签融合表的实现就是利用数据中台的数据开发能力开发代码，加工设计好的标签融合表数据。标签融合表开发实施与统一数仓层类似，在数据中台的开发平台进行代码和运维的实施。

落地实施的具体步骤如下：

1）按照设计和命名规范创建标签表。

2）开发生成标签数据的逻辑代码。

3）进行代码逻辑测试，验证数据加工逻辑是否正确。

4）代码发布，加入生产调度，并配置相应的质量监控和报警机制。

5）持续进行任务运维监控。

统一数仓层和标签数据层数据相对稳定，然而最终用户的需求和使用方式是千变万化的，统一数仓层和标签数据层无法灵活适应各类用户的使用需求。另外最终用户使用数据也需要灵活性和高性能，而这与规范是矛盾的，因为按规范进行建设就会把数据按照各种域、业务过程、维度、粒度等拆分，使用的时候需要各种连接，这样就无法满足对灵活、高性能的要求。为了解决规范稳定与灵活、高性能之间的矛盾，要增加应用数据层。

应用数据层是按照业务使用的需要，组织已经加工好的数据以及一些面向业务的特定个性化指标加工，以满足最终业务应用的场景。应用数据层一般也是采用维度建模的方法，但是为了满足业务的个性需求以及性能的要求，会有一些反规范化的操作，所以应用数据层并没有非常规范的建设标准。

应用数据层类似于传统的数据集市，但是比数据集市更轻量化、更灵活，用于解决特定的业务问题。应用数据层整体而言是构建在统一数仓层与标签数据层之上的简单数据组装层，不像数据集市那样要为某个特定的业务独立构建，应用数据层的构建和完善是从企业级多个类似业务场景来考虑的，同时它又具备数据集市灵活响应业务需求的特点。

应用数据层是在统一数仓层、标签数据层都已经建设好的基础上，面向特定业务需求而准备的个性数据组装层，除了特殊的业务个性标签需要单独加工外，其他尽可能复用统一数仓层和标签数据层的建设成果。

应用数据层的建设是强业务驱动的，业务部门需要参与到应用数据层的建设中来。推荐的工作方式是，业务部门的业务专家把业务需求告知数据部门的数据工程师，然后在建模过程中深入沟通，这样最终形成的应用数据层的表设计才能既满足业务需求又符合整体的规范。因此应用数据层的特点就是考虑使用场景，其有以下几种结构：

1）应用场景是多维的即席分析，一般为了减少连接、提升性能，会采用大宽表的形式组织。

2）如果是特定指标的查询，可以采用K-V表形式组织，涉及此类表的时候需要深入了解具体的查询场景，例如是否有模糊查询，以便于选择最适合的数据结构。

3）有些场景下一次要查询多种信息，也可能会用复杂数据结构组织。

应用数据层建设步骤如下：

1）调研业务应用对数据内容、使用方式、性能的要求，需要明确业务应用需要哪些数据，数据是怎么交互的，对于请求的响应速度和吞吐量等有什么期望。这个时候需要参与沟通的可能不仅仅是业务部门的业务专家，业务系统的研发人员也需要参与讨论。

2）盘点现有统一数仓层、标签数据层数据是否满足业务数据需求，如果满足则直接跳到第3步；如果有个性化指标需求，统一数仓层、标签数据层数据无法满足，则进行个性化数据加工。

3）组装应用层数据。组装考虑性能和使用方式，比如应用层是多维的自由聚合分析，那就把统一数仓层、标签数据层以及个性化加工的指标组装成大宽表；如果是特定指标的查询，可以考虑组装成K-V结构数据。

随着数据技术的发展，数据应用场景已经不限于做BI分析出报表，而是在更广的业务领域发挥价值，比如根据客户兴趣做推荐、根据客户的历史行为做搜索优化，也有可能快速获取客户信息服务业务。这些不同的使用场景，对数据的组织方式和底层的存储计算技术的要求是不同的，应用层的模型设计要考虑业务需要和技术环境。

应用数据层加工的结果数据集，要根据不同的使用场景，同步到不同的存储介质，以达到业务对不同吞吐量和响应时间的需要，如图7-14所示。

图7-14　一套数据多套存储计算环境

比如交叉分析和特定指标查询，所有数据都是数据工程师、算法工程师在数据平台中加工而成的，一般采用分布式离线加工，加工的结果存放在分布式文件中。但是交叉分析和指标查询都需要毫秒级的快速响应，大数据存储层计算环境无法满足这样的低延迟要求，这就需要把加工好的数据同步到可以满足的环境介质中。这里交叉分析一般同步到具备高吞吐、低延迟的即席分析环境，比如Greenplum、Impala；指标查询一般同步到K-V数据库，比如HBase。这样就达到一套数据多套存储，以满足业务对于性能的要求。

本章用简短的篇幅，结合笔者自身的体会介绍了数据中台最核心的数据内容体系结构和相应的建设方法。本章只是概要介绍，关于模型建设的详细步骤方法，请参考Ralph Kimball和Margy Ross的《数据仓库工具集》或阿里巴巴的《大数据之路》等书。

7月16日　周一　晴　地点：集团大会议室

今天天气很闷热，窗外的知了在声声地叫着夏天。

时间过得真快，好在数据中台项目正在按计划全速推进中：

4月，经过多轮招标，集团选择了业内小有名气的数据中台服务商作为项目合作伙伴。

5月，率先从商业地产切入，开始部署数据中台基础平台产品。

6月，技术平台部署完成，接下来进入最重要的数据资产建设阶段。

今天，由大数据事业部牵头，还特意召开了一个项目阶段验收会，一方面对于数据平台部署上线进行项目验收；另一方面，也是最重要，让部门另一位数据专家赵伟向现场十多位业务相关负责人汇报下一阶段数据资产建设工作的思考和规划，希望能在内部达成进一步的思想共识。

赵伟，国内某知名大学的信息管理专业高材生，刚来集团半年，曾经在顶尖企业做过数据分析师、咨询总监等工作，现在负责新成立的大数据事业部的数据管理团队。

和姚冰不同，赵伟永远都是冷静而理性的，泰山压顶而不形于色，这也是我非常欣赏他的地方。

“要打破组织墙和数据岛，不仅仅是上一个技术平台，最重要的是要基于平台，建设集团的数据体系，形成一个统一的规范，而保障规范可执行落地的方法，还需要有相关的组织、流程和工具支持。

“数据中台强调数据的持续可用，为了保障这一点，需要构建一个统一的数据体系，包括数据仓库各层的建设，尤其关注统一数仓层的建设。同时数据中台方案还强调数据模型的建设和标签体系建设，这两个方面其实也是保证数据持续可用的重要环节。因此在数据体系的建设过程中，资源轻重缓急的安排，是有一定的步骤和方法的。”

赵伟还举了个例子：“以集团的商业地产业务为例，其关键数据需求之一是对到访某个商场的客户进行画像分析和洞察，如果以这个业务需求作为数据资产建设的业务价值的出发点，则需要通过以下几个步骤来展开资产建设工作。”

（按照他的介绍）第一步，需要设计一套满足此需求的客户标签，如图7-15所示。

图7-15　客户标签体系

第二步，调研商业地产中客户数据的来源，一类是交易数据，一般包含的字段如图7-16所示；一类是评价类数据，如图7-17所示。

同时，如果能将集团内部各业务线的数据拉通，那将会获得更丰富的客户画像，譬如商业与住宅地产的用户数据打通，那将可以从不同的角度得到用户更丰富的信息，这对后续的个性化推荐和智能服务是很有帮助的。

图7-16　交易数据字段示例

“住宅版块的用户数据是绝对不能随便开放的！”住宅地产的掌门人林总打断了赵伟的分享。

数据共享问题是项目落地过程中打破组织墙必然会面临的问题，因此在会上一定要把原则性态度表达出来。

于是我立刻接过他们的话说：“数据是咱们业务部门的生命线，这点我很理解，不过数据要融通汇聚才能获得更大的价值，而数据共享是必要前提。”

“试想一下，如果你曾在SL特色小镇度过假，当你再走进SL售楼处时，置业顾问马上会识别出是文旅的客户，并为你提供个性化的购房推荐；如果你租过SL的长租公寓，踏进SL商场时，服务人员会微笑地告诉你，作为优质客户，今天你消费将获得额外的优惠……在SL进驻的40多个国内城市，不远的将来，会给客户提供这样的平台和场景。希望所有在SL业务场景里消费的客户，消费得更舒心、更满意，而这一切，都需要建立在多业态数据打通、整合，并匹配利用的基础之上……”

图7-17　评价数据示例

“今年集团已经启动了全面数据化转型和大数据战略，全集团数据的融通汇聚是大趋势，类似数据共享的问题，数据中台战略小组会专门组织会议与各部门商讨，打消各部门各业务线的顾虑，希望大家能多多理解和支持……”

会议室又恢复了平静，赵伟的汇报继续。

经过前期的数据采集，下一步就是数据资产的构建了，PPT上出现了一张图，如图7-18所示。

图7-18　SL集团商业地产数据体系架构

“经过数据采集，形成了商业地产板块的数据体系；然后，通过调研客户的到访，交易、停车等业务过程并进行分析，将数据仓库统一数仓层划分为客户数据域、交易数据域、商场数据域和商品数据域，这部分数据会随着业务需求的增加而日渐丰富，到后期就可以达到高度复用的理想状况。”

在统一数仓层之上的，是由其加工而来的数据标签层和数据应用层，譬如加工成对客户特征进行完整描述的数据结构，最终这些数据能直接输出给具体的应用，如客户画像、客群洞察……

赵伟的汇报逻辑清晰，案例翔实，很有说服力。现场十多位业务部门负责人对数据中台的项目很认可。很欣喜，遇到了赵伟这位如此得力的干将。

随着大数据时代的到来，人们已经认识到数据是一种无形的宝贵资产。谷歌、Facebook、阿里巴巴、腾讯等企业的市值能够高达数千亿美元，除了其独特的商业模式和市场地位，市场还格外看重其拥有的海量用户数据里所蕴含的巨大价值。对于数据的拥有者和管理者来说，通过对数据的合理管理和有效应用，能盘活并充分释放数据的巨大价值。但如果他们不能对数据进行有效管理，数据就用不起来，或者即便用起来也用不好，在这种情况下，堆积如山的无序数据给企业带来的是高昂的成本，数据就成为一项棘手的“负债”。从这个角度来说，是否具备数据资产管理能力已经成为衡量一家企业能否成功的重要因素。

本章将首先从数据资产的定义和特征出发，循序渐进地介绍数据资产的管理现状和挑战、数据资产管理的目标、数据资产管理与数据中台的关系、数据治理的概念以及数据治理与数据资产管理的关系，其中重点讲解数据资产管理的11个职能，最后阐述如何进行数据资产管理效果的评估，以及数据资产管理的7个成功要素。

在讲数据资产管理之前，首先需要厘清数据资产和数据资产管理的概念，区分数据和数据资产的区别。

中国信通院联合多家企业于2019年6月发布了《数据资产管理实践白皮书4.0》 ^[1] ，其中将“数据资产”定义为：“由企业拥有或控制的，能够为企业带来未来经济利益的，以物理或者电子的方式记录的数据资源，如文件资料、电子数据等。”

从这个定义可以看出，数据资产的3个特征为：

1）“企业拥有或控制”。 这个特征指明数据是有其主体的，同时也说明数据资源既可能来源于企业内部的信息系统或者日常经营活动的沉淀，也可能是企业通过外部的交换、购买等手段获取的。

2）“能带来未来经济利益”。 这个特征清楚表明，在企业中，并非所有的数据都构成数据资产，数据资产是能够为企业产生价值的数据资源。

3）“数据资源”。 这个特征表明数据资产的存在形态，是以物理或者电子方式记录下来的数据。

《数据资产管理实践白皮书4.0》中对“数据资产管理”的定义为：“规划、控制和提供数据及信息资产的一组业务职能，包括开发、执行和监督有关数据的计划、政策、方案、项目、流程、方法和程序，从而控制、保护、交付和提高数据资产的价值。”

从这个定义可以看出，数据资产管理是通过一系列手段，以控制、保护、交付和提高数据资产的价值为目的。

笔者们认同《数据资产管理实践白皮书4.0》中对数据资产和数据资产管理的这两个定义，因此本书沿用这两个定义。

[1] http://www.caict.ac.cn/kxyj/qwfb/bps/201906/P020190604471240563279.pdf

在过去，国内大部分领先企业都陆续建设了ERP系统、人力资源系统、供应链管理系统、物流系统、电子商务系统、集成门户、协同办公、决策支持系统等各类信息化系统，这些系统在支撑企业经营活动的同时，也带来了数据量的高速膨胀。随着数据积累逐渐增多，大部分企业在数据管理方面也遇到了诸多挑战。

·缺乏统一的数据视图：数据资源分布在企业的多个业务系统中，分布在线上和线下，甚至分布在企业的外部。由于缺乏统一的数据视图，数据的管理人员和使用人员无法准确快速地找到自己需要的数据。数据管理人员也无法从宏观层面掌握自己拥有哪些数据资产，拥有多少数据资产，这些数据资产分布在哪里，以及变化情况怎样等。

·数据基础薄弱：大部分企业的数据基础还很薄弱，存在数据标准混乱、数据质量参差不齐、各业务系统之间数据孤岛化严重、没有进行数据资产的萃取等现象，阻碍了数据的有效应用。

·数据应用不足：受限于数据基础薄弱和应用能力不足，多数企业的数据应用刚刚起步，主要在精准营销、舆情感知和风险控制等有限场景中进行了一些探索，数据应用的深度不够，应用空间亟待开拓。

·数据价值难估：企业难以对数据对业务的贡献进行评估，从而难以像运营有形资产一样运营数据。产生这个问题的原因有两个：一是没有建立起合理的数据价值评估模型；二是数据价值与企业的商业模式密不可分，在不同应用场景下，同一项数据资产的价值可能截然不同。

·缺乏安全的数据环境：数据的价值越来越得到全社会的广泛认可，但随之而来的是针对数据的犯罪活动日渐猖獗，数据泄露、个人隐私受到侵害等现象层出不穷。很多数据犯罪是由安全管理制度不完善、缺乏相应的数据安全管控措施导致的。

·数据管理浮于表面：没有建立一套数据驱动的组织管理制度和流程，没有建设先进的数据管理平台工具，导致数据管理工作很难落地。

这些问题已经严重影响到数据价值的发挥，导致企业的数据越积越多，逐渐成为企业的负担，大数据管理部门也成为企业的成本中心，而不是创新中心和利润部门。

数据资产管理是数据中台面向企业提供数据能力的一个窗口，数据资产中心将企业的数据资产统一管理起来，实现数据资产的可见、可懂、可用和可运营。

·可见：通过对数据资产的全面盘点，形成数据资产地图。针对数据生产者、管理者、使用者等不同的角色，用数据资产目录的方式共享数据资产，用户可以快速、精确地查找到自己关心的数据资产。

·可懂：通过元数据管理，完善对数据资产的描述。同时在数据资产的建设过程中，注重数据资产业务含义的提炼，将数据加工和组织成人人可懂的、无歧义的数据资产。具体来说，在数据中台之上，需要将数据资产进行标签化。标签是面向业务视角的数据组织方式。

·可用：通过统一数据标准、提升数据质量和数据安全性等措施，增强数据的可信度，让数据科学家和数据分析人员没有后顾之忧，放心使用数据资产，降低因为数据不可用、不可信而带来的沟通成本和管理成本。

·可运营：数据资产运营的最终目的是让数据价值越滚越大，因此数据资产运营要始终围绕资产价值来开展。通过建立一套符合数据驱动的组织管理制度流程和价值评估体系，改进数据资产建设过程，提升数据资产管理的水平，提升数据资产的价值。

数据资产管理在数据中台架构中处于中间位置，介于数据开发和数据应用之间，处于承上启下的重要地位（如图8-1所示）。数据资产管理对上支持以价值挖掘和业务赋能为导向的数据应用开发，对下依托大数据平台实现数据全生命周期的管理，并对企业数据资产的价值、质量进行评估，促进企业数据资产不断自我完善，持续向业务输出动力。

图8-1　数据资产管理的位置

数据资产体系是通过数据开发得到的宝贵成果。通过良好的数据资产管理，一方面可以保证数据资产的质量，提升数据资产的可信度；另一方面，组织良好的数据资产，既能为各类角色的用户提供数据资产的直观视图，方便用户查看和使用，又能源源不断地输出数据资产服务能力，持续赋能业务场景。

数据治理这个概念最早是在20世纪90年代提出的，率先大规模开展数据治理工作的是强监管要求下的银行业。虽然这个概念提出的时间并不长，但其实隐含数据治理内涵的社会活动，从很早就已经开始进行，秦灭六国，始皇帝统一度量衡，“车同轨，书同文”可以被认为是最早的数据标准化工作。

自从21世纪进入大数据时代以来，随着数据量的爆发，如何用好这些海量数据，是人们面临的一个巨大挑战，相应地，数据治理也被放在了一个前所未有的重要位置上。数据治理之所以如此重要，是因为如果数据没有得到良好的治理，就没有办法相信手中的数据是可靠的，没有办法很好地使用数据，发挥不出数据本身的巨大价值。只有建立了适合企业的数据治理体系，从多个维度保证数据的质量，才能够真正有效地挖掘组织的数据价值，提升竞争力，将数据作为组织决策的依据以及创新的源泉。

从根本上说，数据治理的目标是保障数据资产的质量，促进数据资产的价值创造。这个根本目标可以分解成以下6项：

·提升数据质量，帮助做出基于数据的更高效、更准确的决策；

·构建统一的、可执行的数据标准；

·良好地响应数据生产者、消费者、数据处理技术人员等数据利益相关者的需求，如保护好客户（数据生产者）的数据隐私和数据安全；

·培训组织内所有的管理层和员工，让大家采用共同的解决数据问题的办法；

·实现可重复的数据管理流程，并确保流程透明；

·实现数据的可持续运营、数据资产的增值。

可以使用8.5.3节阐述的DCMM数据管理能力成熟度评估模型，对数据治理的目标达成程度进行科学评估，找出差距，制订持续可行的推进方案，逐步达成目标。

数据治理的原则可以总结为以下6条。

·标准化原则：数据标准化是实现高价值数据、支撑以数据为基础的相关业务的先决条件。组织必须制定可参考、可落地的标准。当发生争议的时候，有权威的标准可供仲裁参考。

·透明原则：除了一些需要保密的安全措施之外，数据治理相关的文件、数据问题的发现等，都应该是公开透明的，相关人员应该清楚正在发生的事情，以及事情发生后应如何按照原则处理。

·数据的认责与问责：数据治理必须解决无人问责的问题，比如将很多岗位列为负责人，最终却没有人真正负责。数据的认责是数据治理的先决条件，数据的问责和考核制度是确保数据治理工作真正落地的制度保障。

·平衡原则：在大数据时代，时时刻刻都在涌现海量数据。在进行数据治理工作的过程中，必须在代价和收益之间取得平衡。往往没有必要追求百分之百的数据质量，而对于历史遗留数据，数据标准也不可能对其进行完全约束。很多时候，对于企业来说，数据可商用是平衡原则的重要参考。

·变更原则：随着市场和业务的不断发展，数据标准、元数据、数据质量等要求并不是一成不变的，既要控制数据的变更流程，也要主动适应这些变化，推动标准更新。

·持续改进原则：业务在不断变化，数据在持续产生，数据治理非朝夕之功，需要持续推动，不断改进，形成长效机制。

数据治理的理论在业界并没有一个统一的标准，不同的组织根据自身的理论研究和实践经验，提出了各有侧重的理论体系。国际上比较有名、接受度较高的理论体系的提出者有：DAMA（Data Management Association，国际数据管理协会）、CMMI（Capability Maturity Model Integration，软件能力成熟度模型集成）研究所、DGI（The Data Governance Institute，国际数据治理研究所）、IBM（International Business Machines Corporation，国际商用机器公司）数据治理委员会和Gartner（高德纳）公司。其中，以DAMA提出的数据治理理论体系最被广泛接受。

DAMA从数据治理生命周期角度对数据资产的管理行使权力和控制的活动（规划、监控和执行）进行了重点研究。定义了数据治理、数据架构管理、数据开发、数据操作管理、数据安全管理、参考数据和主数据管理、数据仓库和商务智能管理、文档和内容管理、元数据管理、数据质量管理这10个领域，以及目标和原则、活动、主要交付物、角色和职责、技术、实践和方法、组织和文化这7个环境因素，为数据管理提供了完整的结构体系。截至本书写作时，DAMA理论体系已经更新到第2版，国内相关的翻译工作也正在进行。

CMMI研究所推出的DMM（Data Management Maturity，数据管理成熟度模型），帮助企业组织改善他们整个业务领域的数据管理实践。DMM模型由五大核心过程域和一套支撑流程组成，五大核心过程域包括：数据管理战略、数据治理、平台和架构、数据运营、数据质量。DMM可为公司组织提供一套最佳实践标准，制订让数据管理战略与单个商业目标相一致的路线图。

在我国，由工业和信息化部下属的电子工业标准化研究院牵头，联合多家高校和著名企业提出的DCMM（Data Management Capability Maturity Assessment Model，数据管理能力成熟度评估模型），正在被越来越多的企业和政府机构所接受，作为指导数据治理工作的重要理论依据。DCMM充分结合大数据特点和国内数据治理现状，形成数据战略、数据治理、数据架构、数据标准、数据质量、数据安全、数据应用、数据生命周期8个核心领域 及28个过程域，重点关注数据的管理过程和方法。相较于国外的DAMA等理论体系，DCMM体系的特点是更加符合中国的数据治理现状，如在体系中增加了数据战略、数据标准等核心领域。

DCMM在数据管理的8个核心领域中，将数据管理的成熟度划分成5个等级。

·初始级：数据管理主要在项目级体现，没有统一的管理流程，主要是被动式管理。

·受管理级：组织已经意识到数据是资产，根据管理策略的要求制定了管理流程，指定了相关人员进行初步管理。

·稳健级：数据已被当作实现组织绩效目标的重要资产，在组织层面制定了系列的标准化管理流程，促进数据管理的规范化。

·量化管理级：数据被认为是获取竞争优势的重要资源，数据管理的效率可以量化分析和监控。

·优化级：数据被认为是组织生存和发展的基础，相关管理流程能实时优化，能在行业内进行最佳实践分享。

DCMM可以帮助组织发现自身数据管理存在的问题，以及与标杆行业最佳实践的差距，识别自身优势和劣势，帮助组织提出数据管理能力提升路线图。DCMM可以为组织带来的收益如下：

·规范数据管理方面的职能域划分；

·提出数据管理参考内容、流程和工具集；

·获得数据管理现状、识别差距并提出未来发展方向；

·建立数据管理相关能力域的最佳实践；

·持续提升数据管理能力。

本书写作过程中所参考的主要是DCMM理论体系 ^[1] ，同时也参考了DAMA体系 ^[2] 的部分内容。

在传统的关系型数据库时代，开展数据治理更多的是为了解决数据质量问题，提升数据决策水平。而在大数据时代，除了保证数据质量之外，对数据治理也提出了更高的要求，数据必须更好地适应不确定性的需求，即插即用，服务不断变化的业务创新，发挥数据更大的价值。在这种要求下，可以通过数据资产管理，在传统的数据治理能力之外，提供数据资产视图能力、数据检索能力、数据共享能力、数据价值运营能力等，实现数据的可见、可懂、可用、可运营，并不断增值。数据管理部门也有机会从一个纯粹的成本中心逐渐转变成企业的创新中心和高利润部门。

高质量的大数据作为AI的原料，不断地训练出表现越来越出色的AI模型。而反过来，AI也可以反哺大数据的处理能力，帮助人类大幅度提升大数据处理效率。目前很多企业和大数据服务提供商都在探索用机器学习的方式帮助组织增强数据治理能力。通过应用机器学习技术，来识别哪些数据可能有问题，哪些数据是用户的隐私数据。一旦数据特征被确认，就会自动给它们打上标签，从而使用这种自动化的机制来完成一部分数据治理工作。比如当碰到某类有特殊标记的数据时，就会有相应的流程启动。而解决这类问题的传统机制往往需要人工操作，费时费力，在大数据时代，这样的人力成本投入已经不再现实，机器学习可以将这一整串流程完全自动化，且准确率达到较高的水平。

在数据安全管理方面，人工智能的介入将帮助组织发现更多可疑的数据窃取、数据泄露的潜在风险，识别潜在的系统攻击，帮助组织建立健全的数据安全管理措施，填补技术上的漏洞。

随着云计算、边缘计算的兴起，未来的数据治理必须满足分布式的要求，因为数据治理总是随数据存储的位置而进行。而实现这些，需要数据治理围绕元数据展开，无论数据分散在何处，都可以在数据保留在原地的情况下，通过元数据把它们关联在一起，因此元数据将成为未来数据治理的基础和核心。

[1] http://c.gb688.cn/bzgk/gb/showGb?type=online&hcno=B282A7BD34CAA6E2D742E0CAB7587DBC

[2] 《 DAMA数据管理知识体系指南》，清华大学出版社，2012。

数据治理（Data Governance，DG）是指对数据资产管理行使权力和控制的活动集合（规划、监督和执行）。传统的数据治理内容通常包含数据标准管理、元数据管理、数据质量管理、数据安全管理、数据生命周期管理等内容。

而8.1节中沿用的中国信通院对数据资产管理的定义是：“规划、控制和提供数据及信息资产的一组业务职能，包括开发、执行和监督有关数据的计划、政策、方案、项目、流程、方法和程序，从而控制、保护、交付和提高数据资产的价值。”

从上面两段描述中可以看出，数据治理和数据资产管理的定义有异曲同工之处，它们围绕的对象都是数据资产。 而中国信通院在《数据资产管理实践白皮书4.0》中阐述的数据资产管理的八大职能中，数据标准管理、元数据管理、数据质量管理和数据安全管理等同时也属于传统数据治理的必要工作内容。数据资产管理在传统数据治理的基础上，加入了数据价值管理、数据共享管理 等内容。

从8.5.4节中可以看出，数据治理的目标正从“以质量管理为主”过渡到“质量管理与服务并重”。基于上面的论述，笔者们认为，数据资产管理就是传统的数据治理的升级版，可以认为是数据治理2.0。 数据资产管理与数据治理之间的关系可以用图8-2来表示。

图8-2　数据治理与数据资产管理的关系

在本书中，不再另用一章来阐述数据治理，而是将数据治理的内容包含在本章数据资产管理的内容中。本章余下部分，在阐述数据标准管理、数据质量管理等数据资产管理职能的时候，从用词中读者便可以看出，它们也是数据治理中的重要部分。

《数据资产管理实践白皮书4.0》中规定，数据资产管理的管理职能包括数据标准管理、数据模型管理、元数据管理、主数据管理、数据质量管理、数据安全管理、数据价值管理和数据共享管理共8个方面。在本书中，结合数据中台建设的特点，加入数据资产门户、生命周期管理、标签管理3个新的管理职能，一共形成11大数据资产管理职能域。本书对这些职能的阐述参考了《数据资产管理实践白皮书4.0》中的部分阐述，但并没有完全照搬，而是结合数据中台本身的特点，加上笔者们的实践，在某些职能域中做了较大幅度的修改和扩充，使之更符合开展数据资产管理工作中的实际情况。下面分别对这11大职能域进行详细阐述。

根据全国信息技术标准化技术委员会大数据标准工作组制定的大数据标准体系，大数据的标准体系框架共由7个类别的标准组成，分别为基础标准、数据标准、技术标准、平台和工具标准、管理标准、安全和隐私标准及行业应用标准。本节主要阐述其中的数据标准。

数据标准这个词，国内从21世纪初开始提出，最早是在银行业的数据治理中开始使用的。数据标准工作一直是数据治理中重要的基础性内容，但是对于数据标准，不同的人却有不同的看法：有人认为，数据标准极其重要，只要制定好了数据标准，所有数据相关的工作依标进行，数据治理大部分目标就水到渠成了；也有人认为，数据标准几乎没什么用，做了大量的梳理，建设了一整套全面的标准，最后还是束之高阁，被人遗忘，几乎没有发挥作用。

其实这两种看法都是片面的。实际上，数据标准工作是一项复杂且涉及面广的系统性、长期性的工作。它虽然不能快速发挥作用，迅速解决掉数据治理中的大部分问题，但也不是完全没有作用，最后只剩下一堆文档——如果数据标准工作的结果真是如此，那只能说明这项工作没有做好，没有落到实处。

首先要厘清数据标准的定义。对于何为数据标准，各相关组织并没有达成共识。结合各家对数据标准的阐述，从数据治理的角度出发，尝试着给数据标准下一个定义：数据标准是对数据的表达、格式及定义的一致约定，包含数据业务属性、技术属性和管理属性的统一定义；数据标准的目的是使组织内外部使用和交换的数据是一致的、准确的。

举例来说，对于一个企业来说，营销、财务、总经理办公室等不同的部门可能都会产出“利润率”这个指标，所以需要统一“利润率”这个指标标准，如果确实有多个不同口径的“利润率”需要同时存在，则必须用不同的限定词把它们区分开，如销售利润率、成本利润率、产值利润率、资本金利润率、人均利润率等。对于每一种指标，都必须明确阐述其唯一的业务含义，明确其计算公式、数据来源、限定范围（如时间范围、业务范围），并确保这种指标标准是可供业务部门和技术部门参考，有专人维护的。

数据标准来源非常丰富，有外部的监管要求、行业的通用标准、专家的实践经验，同时也必须考虑到企业内部数据的实际情况。通过资料收集、调研访谈、分析评估等工作流程，梳理其中的业务指标、数据项、代码等，最终形成并制定适用于组织的数据标准，并对标准进行发布和公示。数据标准的制定流程如图8-3所示。

图8-3　数据标准的制定流程

需要注意的是，由于组织内业务的复杂性，将收集到的所有参考标准都纳入数据标准管理中进行管理是没有必要的，数据治理的指导者必须清楚哪些标准才适用于当前组织内业务和数据的实际情况。

按照DCMM的分类，数据标准可分为以下几类：

·业务术语标准

·参考数据和主数据标准

·数据元标准

·指标数据标准

业务术语是被批准、管理的业务概念定义的描述，需要通过流程来定义组织如何创建、审批、修改和发布统一的业务术语，进而推动数据的共享和在组织内部的应用，如银行的业务术语贷款展期、收息、兑付等。

参考数据是用于将其他数据进行分类或目录整编的数据，可以简单理解为是数据字典，是数据可能的取值范围，比如我国的省份，它总是在一个固定的可选范围之内，又如性别的分类和取值范围、货币币种的分类和取值范围。主数据是组织中需要跨系统、跨部门共享的核心业务实体数据。主数据因为其重要价值，被喻为企业的黄金数据记录，如多个系统共享的客户、商品等核心业务实体数据。

数据元是用一组属性描述其定义、标识、表示和允许值的数据单元，是描述数据的最基本单元。数据元由3部分组成：对象类、特性、表示值域和数据类型的组合。数据元是一个相对抽象的概念，感兴趣的读者可以寻找相关的资料深入学习，如参考DCMM里数据元的相关内容。

指标数据是组织在经营分析过程中衡量某一个目标或事物的数据，一般由指标名称、指标解释、时间限定、其他条件限定、指标数值等组成，如企业的人均利润率、季度离职率等。

首先要明晰数据标准和数据标准化在概念上的区别。数据标准是一经制定发布后相对稳定的静态文件，而数据标准化是一项带有系统性、复杂性、困难性、长期性特征的动态管理工作，是对标准的某种程度上的落地。在数据标准管理中，通常数据标准相对好制定，而数据标准落地就困难多了。

国内的数据标准化工作已经发展了很多年，各个行业和组织都在建设自己的数据标准，但是很少听到哪个组织大张旗鼓地宣传自己的数据标准工作有多么出色，换句话说，做数据标准取得显著效果的案例并不多。为什么会出现这种情况？主要有两个原因。

应对以上这些难题，最经济、最理想的模式当然是：首先建标准，再建应用系统、大数据平台、数据仓库、数据应用等。正因为其太过理想化，所以这种模式几乎是见不到的。因为一般的组织不大可能有这样的认识，很多时候大家都是先建设再治理。先把信息系统、数据中心建好，后面发现标准有问题、质量不高，再来建数据标准，但实际上这时候已经是在做一些亡羊补牢的事情，客户的投入肯定有一部分是被浪费掉的。但这往往不可避免。

要解决数据标准化的难题，需要从以下几个方面入手：

数据模型是指对现实世界数据特征的抽象，用于描述一组数据的概念和定义。数据模型从抽象层次上描述了数据的静态特征、动态行为和约束条件。企业在数据模型管理中遇到的问题包括：

·生产库里面存在大量没有注释的字段和表，意思含糊不清，同名不同义、同义不同名、冗余字段、枚举值不一致等现象是普遍存在的，这些问题都会直接影响到用户对数据的识别。

·模型变更前没有任何合理性判断。

·模型修改过程中缺乏监管，有很多模型的变更虽然通过了评审，但是变更的过程是否按照原来的标准变更是不得而知的。

·很多企业的数据模型是一个黑盒子，有的甚至根本就没有数据模型。

数据模型管理主要是为了解决架构设计和数据开发的不一致，而对数据开发中的表名、字段名等规范性进行约束。数据模型管理一般与数据标准相结合，通过模型管理维护各级模型的映射关系，通过关联数据标准来保证最终数据开发的规范性。理想的数据模型应该具有非冗余、稳定、一致和易用等特征。

《数据资产管理实践白皮书4.0》中对数据模型管理内容方面的论述和介绍如下：

数据模型按不同的应用层次分成概念数据模型、逻辑数据模型、物理数据模型3种。

概念模型是一种面向用户、面向客观世界的模型，主要用来描述世界的概念化结构，与具体的数据库管理系统无关。

逻辑模型是一种以概念模型的框架为基础，根据业务条线、业务事项、业务流程、业务场景的需要，设计的面向业务实现的数据模型。逻辑模型可用于指导在不同的数据库管理系统中实现。逻辑数据模型包括网状数据模型、层次数据模型等。

物理模型是一种面向计算机物理表示的模型，描述了数据在存储介质上的组织结构。物理模型的设计应基于逻辑模型的成果，以保证实现业务需求。它不但与具体的数据库管理系统有关，而且还与操作系统和硬件有关，同时考虑系统性能的相关要求。

数据模型管理是指在信息系统设计时，参考业务模型，使用标准化用语、单词等数据要素来设计企业数据模型，并在信息系统建设和运行维护的过程中，严格按照数据模型管理制度，审核和管理新建数据模型，数据模型的标准化管理和统一管控，有利于指导企业数据整合，提高信息系统数据质量。数据模型管理包括对数据模型的设计、数据模型和数据标准词典的同步、数据模型审核发布、数据模型差异对比、版本管理等。数据模型管理的关键活动包括：

·定义和分析企业数据需求；

·定义标准化的业务用语、单词、域、编码等；

·设计标准化数据模型，遵循数据设计规范；

·制定数据模型管理办法和实施流程要求；

·建设数据模型管理工具，统一管控企业数据模型。

数据模型是数据资产管理的基础，一个完整、可扩展、稳定的数据模型对于数据资产管理的成功起着重要的作用。通过数据模型管理可以清楚地表达企业内部各种业务主体之间的数据相关性，使不同部门的业务人员、应用开发人员和系统管理人员获得关于企业内部业务数据的统一完整视图。

元数据（Metadata）是一个相当抽象、不易理解的概念，所以重点先要把元数据是什么搞懂。本节共提出3个概念。

（1）元数据是描述数据的数据

这是元数据的标准定义，但这么说有些抽象，技术人员能听懂，倘若读者缺乏相应的技术背景，可能当场就懵了。产生这个问题的根源其实是一个知识的“诅咒”：知道某件事情，但向不了解的人描述时却很难讲清楚。

要破解这个“诅咒”，不妨借用一个比喻来描述元数据：元数据是数据的户口簿。想想一个人的户口簿是什么，是这个人的信息登记册：上面有他的姓名、年龄、性别、身份证号码、住址、原籍、何时从何地迁入等，除了这些基本的描述信息之外，还有他和家人的血缘关系，比如父子、兄妹等。所有这些信息加起来，就构成了对这个人的全面描述，而这些信息都可以称为这个人的元数据。

同样，如果要描述清楚一个现实中的数据，以某张表格为例，则需要知道表名、表别名、表的所有者、主键、索引、表中有哪些字段、这张表与其他表之间的关系等。所有的这些信息加起来，就是这张表的元数据。

（2）元数据管理是数据治理的核心和基础

为什么说元数据管理是数据治理的核心和基础？它的地位为何如此特殊？

想象一下，一位将军要去打仗，他要掌握的必不可少的信息是什么？对，是战场的地图。很难想象手里没有军事地图的将军能打胜仗。而元数据就相当于所有数据的一张地图。

通过这张关于数据的地图，可以知道：

·有哪些种类的数据；

·有哪些信息系统、哪些数据库、哪些表、哪些字段；

·数据全量是多少，每日增量是多少；

·数据分布在哪里；

·数据之间有什么流向关系；

……

如果没有掌握这张地图，做数据治理就犹如盲人摸象。现在流行的数据资产管理、知识图谱等，其实也是建立在元数据之上的。所以说，元数据是一个组织内的数据地图，是数据治理的核心和基础。

（3）有没有描述元数据的数据

有。描述元数据的数据叫元模型（Metamodel）。元模型、元数据和数据三者之间的关系如图8-4所示。

图8-4　数据–元数据–元模型关系图

对于元模型的概念本书不做深入讨论，感兴趣的读者可以寻找相关的学习材料深入研究。

在大数据平台中，元数据贯穿大数据平台数据流动的全过程，主要包括数据源元数据、数据加工处理过程元数据、指标层元数据、标签层元数据、服务层元数据、应用层元数据等。

业内通常把元数据分为以下类型。

·技术元数据：库表结构、字段约束、数据模型、ETL程序、SQL程序等。

·业务元数据：业务指标、业务代码、业务术语等。

·管理元数据：数据所有者、数据质量定责、数据安全等级等。

元数据采集是指获取到分布在不同系统中的元数据，对元数据进行组织，然后将元数据写入数据库中的过程。

要获取到元数据，需要采取多种方式，在采集方式上，使用包括数据库直连、接口、日志文件等技术手段，对结构化数据的数据字典、非结构化数据的元数据信息、业务指标、代码、数据加工过程等元数据信息进行自动化和手动采集。

元数据采集完成后，会被组织成方便查看和分析的数据结构，通常被存储在关系型数据库中。

元数据的管理包含元数据的增删改查、变更管理、对比分析、统计分析等。

·元数据的增删改查。通过对不同的角色赋予相应的权限，实现元数据在组织范围内的信息共享。值得注意的是，对元数据的修改、删除、新增等操作，必须经过元数据管理员的审核流程。

·元数据变更管理。对元数据的变更历史进行查询，对变更前后的版本进行比对等。

·元数据对比分析。对相似的元数据进行比对。比如，对近似的两张表进行对比，发现它们之间的细微差异。

·元数据统计分析。用于统计各类元数据的数量，如各类数据的种类、数量、数据量等，方便用户掌握元数据的汇总信息。

那么有了元数据以后，能做什么呢？

（1）元数据浏览和检索

通过提供直观的可视化界面，让用户可以按不同类型对元数据进行浏览和检索。通过合理的权限分配，元数据浏览和检索可以大大提升信息在组织内的共享。

（2）数据血缘和影响性分析

数据血缘和影响性分析主要解决“数据之间有什么关系”的问题。因其重要价值，有的厂商会从元数据管理中将其单独提取出来，作为一个独立的重要功能。但是考虑到数据血缘和影响性分析其实是来自于元数据信息，所以还是放在元数据管理中来描述。

血缘分析指的是获取到数据的血缘关系，以历史事实的方式记录数据的来源、处理过程等。

以某张表的血缘关系为例，其血缘分析展示如图8-5所示。

数据血缘分析对于用户具有重要的价值，比如当在数据分析中发现问题数据的时候，可以依赖血缘关系，追根溯源，快速定位到问题数据的来源和加工流程，减少分析的时间和难度。

数据血缘分析的典型应用场景：某业务人员发现“本月客户增长情况”报表数据存在明显不合理的情况，于是向数据部门提出异议，技术人员通过元数据血缘分析发现，“本月客户增长情况”报表受到上游DWD（Data Warehouse Detail，明细数据层）6张不同的数据表的影响。通过这种方式，技术人员可以快速定位到问题的源头，低成本地解决问题。

除了血缘分析之外，还有影响性分析，它能分析出数据的下游流向。当系统进行升级改造的时候，如果修改了数据结构、ETL程序等元数据信息，依赖数据的影响性分析，可以快速定位出元数据修改会影响到哪些下游系统，从而减少系统升级改造带来的风险。从上面的描述可以知道：数据影响性分析和血缘分析正好相反，血缘分析指向数据的上游来源，而影响性分析指向数据的下游。

图8-5　数据血缘分析

影响性分析的典型应用场景：因业务系统改造升级，某个部门在DATAWAVE_FINANCE这张表中将字段TRADEID的长度由8字节修改为64字节，需要分析本次升级对后续相关系统的影响。对元数据DATAWAVE_FINANCE进行影响性分析，发现对下游ADS（Application Data Store，应用数据层）相关的3个指标都有影响，定位到影响之后，数据部门及时通知下游相关系统的管理人员，修改了下游的相应程序和表结构，避免了问题的发生。由此可见，数据的影响性分析有利于快速锁定元数据变更带来的影响，将可能发生的问题提前消灭在萌芽之中。

（3）数据冷热度分析

冷热度分析主要是对数据表的被使用情况进行统计，如表与ETL程序、表与分析应用、表与其他表的关系情况等，从访问频次和业务需求角度出发，进行数据冷热度分析，用图表展现表的重要性指数。

数据的冷热度分析对于用户有着巨大的价值，其典型应用场景有：如果观察到某些数据资源处于长期闲置，没有被任何用户查看，也没有任何应用去调用它的状态，用户就可以参考数据的冷热度报告，结合人工分析，对冷热度不同的数据做分层存储，以便更好地利用HDFS资源，或者评估是否对失去价值的这部分数据做下线处理，以节省数据存储空间。

主数据（Master Data）是指用来描述企业核心业务实体的数据，是企业核心业务对象、交易业务的执行主体，是在整个价值链上被重复、共享应用于多个业务流程的、跨越各个业务部门和系统的、高价值的基础数据，是各业务应用和各系统之间进行数据交互的基础。从业务角度，主数据是相对“固定”的，变化缓慢。主数据是企业信息系统的神经中枢，是业务运行和决策分析的基础。常见的主数据如供应商、客户、企业组织机构和员工、产品、渠道、科目、交易方式等。

由于IT系统建设的历史局限性，主数据分布在不同的应用系统，而不同的应用系统之间主数据的定义、属性、编码存在众多的不一致，极大影响了系统和数据之间的融合与集成。因此需要进行主数据管理建设，统一规范企业级主数据。

主数据管理（Master Data Management，MDM）是一系列规则、应用和技术，用以协调和管理与企业的核心业务实体相关的系统记录数据。主数据管理的主要内容包括如下几项。

·主数据相关标准及规范设计：主数据的标准和规范是主数据建设的核心工作，需要企业抽调专业人员集中精力进行梳理和汇总，建立一套完整的标准体系和代码库，对企业经营活动中所涉及的各类主数据制定统一数据标准和规范，如数据模型标准、数据编码标准、主数据接口标准等。

·主数据建模：对主数据进行数据模型设计，建立主数据架构的物理模型，包括数据属性的定义、数据结构设计、数据管理定义等方面，通过数据发布来创建数据存储实体。

·主数据梳理与集成：根据主数据标准规范，依托于数据集成平台以及主数据质量模块，辅助业务部门将现有的主数据内容重新进行数据编码、数据转换、数据清洗等，形成企业标准的主数据库。

·主数据质量管理：对主数据系统中的数据质量进行统一闭环管理，覆盖数据质量的定义、监控、问题分析、整改和评估，推动质量问题的解决。围绕数据质量管理，建立考核机制，提升数据资产的业务价值；在数据清洗过程中，进行数据质量的管理，并生成数据质量报告，提供数据质量管理服务。

·建立灵活的主数据共享服务：主数据的特殊性决定了主数据与业务系统需要频繁的数据共享，主数据管理系统需提供灵活的服务接口，保证能够快速实现数据集成且最大程度减少集成成本。

·建立主数据维护流程：协助梳理企业内主数据管理相关流程，明确流程流转方向，以及各环节表单及责任人，并在主数据系统中进行流程配置，逐步实现梳理成果的自动化落地，在主数据系统中实现跨业务部门的流程贯通。

主数据管理通过对主数据值进行控制，使得企业可以跨系统使用一致的和共享的主数据，提供来自权威数据源的协调一致的高质量主数据，降低成本和复杂度，从而支撑跨部门、跨系统数据融合应用。

数据质量管理主要用来解决“数据质量现状如何，谁来改进，如何提高，怎样考核”的问题。在关系型数据库时代，做数据治理最主要的目的是提升数据质量，让报表、分析、应用更加准确。时至今日，虽然数据治理的范围扩大了，开始注重数据的服务和共享，注重数据价值的运营，但是提升数据的质量依然是数据治理最重要的目标之一。

为什么数据质量问题如此重要？因为一方面，要想让数据要能发挥其价值，关键在于其质量要高，高质量的数据是一切数据应用的基础。如果一个组织根据劣质的数据去分析业务、指导决策、进行创新，那还不如没有数据，因为通过错误的数据分析出的结果往往会带来“精确的误导”，对于任何组织来说，这种“精确的误导”都无异于一场灾难。

另一方面，对于数据最主要的使用者数据科学家和数据分析员来说，如果不能信任手上的数据，每天还要花费大量时间来辨别，将造成资源的严重浪费。可见数据质量问题已经严重影响到组织业务的正常运营。通过科学的数据质量管理，持续提升数据质量，已经成为组织刻不容缓的优先任务了。

做数据质量管理，首先要搞清楚数据质量问题产生的原因。原因有很多方面，比如技术、管理、流程等。造成质量问题的原因通常很复杂，比如企业的信息系统一般是由外部的供应商承建的，在建设过程中，这些系统使用当时条件下不同的标准生产和使用数据，甚至没有标准，只有当时的IT人员自己的“标准”。这就导致系统间存在大量的重复数据、脏数据、不同口径的数据。

这些数据质量问题产生的原因，从本质上来说，还是管理不善，技术和流程只是其表象。所以，要解决数据质量问题，也就不能只从技术角度来考虑，奢望通过购买某个工具就能解决，还是要从业务、管理、技术等多方面入手。

从多个角度思考问题，整合资源，解决数据质量问题，重要的是建立一套科学可行的数据质量评估标准和管理流程。

当谈到数据质量管理的时候，必须有一个数据质量评估的标准，有了这个标准，才能知道如何评估数据的质量，才能将数据质量量化，并知道改进的方向，以及如何评估改进后的效果。

目前业内认可的数据质量标准有如下几类。

1）准确性： 描述数据是否与其对应客观实体的特征一致。

举例：用户的住址是否准确；某个字段规定应该是英文字符，在其位置上是否存在乱码。

2）完整性： 描述数据是否存在缺失记录或缺失字段。

举例：某个字段不能为null或空字符。

3）一致性： 描述同一实体同一属性的值在不同的系统中是否一致。

举例：男女是否在不同的库表中都使用同一种表述。例如在A系统中，男性表述为1，女性表述为0；在B系统中，男性表述为M，女性表述为F。

4）有效性： 描述数据是否满足用户定义的条件或在一定的取值范围内。

举例：年龄的值域在0~200之间。另一个枚举的有效性例子是银行的币种代码。

5）唯一性： 描述数据是否存在重复记录。

举例：身份证号码不能重复，学号不能重复。

6）及时性： 描述数据的产生和供应是否及时。

举例：生产数据必须在凌晨2：00入库到ODS（Operational Data Store，操作数据层）。

7）稳定性： 描述数据的波动是否稳定，是否在其有效范围内。

举例：产品质量抽样统计的合格率，不会有超过20%的波动范围。

8）连续性： 描述数据的编号是否连续。

举例：有关部门处理环保违法案件，案件的编号必须是连续的。

9）合理性： 描述两个字段之间逻辑关系是否合理。

举例：企业注销时间必须晚于注册时间，自然人的死亡时间必须晚于出生时间。

以上数据质量标准只是一些通用的规则，还可以根据客户数据的实际情况和业务要求对其进行扩展，如进行交叉表数据质量校验等。

要提升数据质量，需要以问题数据为切入点，注重问题的分析、解决、跟踪、持续优化、知识积累，形成数据质量持续提升的闭环。数据质量的管理流程如图8-6所示。

图8-6　数据质量管理流程

首先需要梳理和分析数据质量问题，摸清数据质量的现状。在这个过程中，需要用到数据质量评估标准和评估工具，对业务数据进行全部或抽样扫描，找出不符合质量要求的数据，形成数据质量报告，提供给用户参考。

然后针对不同的质量问题选择合适的解决办法，制订详细的解决方案。如在落地到数据中心的过程中进行数据清洗，在数据录入的源头进行质量把控，对数据建模过程进行是否符合质量标准的审核，等等。

接着是问题的认责，追踪方案执行的效果，监督检查，持续优化。在这一步，要把每一个问题都落实到具体的责任人，并且形成一套最终的考核机制，督促相关的责任人持续不断地关注与提升数据质量。

最后形成数据质量问题解决方案的知识库，以供后来者参考。数据质量问题往往不是偶然出现的，许多问题都有其共性，比如由于在数据录入环节，对输入框中输入的内容没有严格限定格式，会批量造成同样的数据质量问题，把这些质量问题的解决过程沉淀下来，形成知识库，有助于提升后续数据质量问题的处理效率。

不断迭代上述步骤，形成数据质量管理的闭环。

从以上流程中可以看出，要管理好数据质量，仅有工具支撑是远远不够的，必须要组织架构、制度流程参与进来，才能形成一套完整有效的管理流程。

企业也好，政府也好，从来不是生活在真空之中，而是被社会紧紧地包裹着。解决任何棘手的问题，都必须考虑到各种社会因素的影响，做适当的取舍。

《数据资产管理实践白皮书4.0》中对数据安全管理的主要观点和思想如下：

数据安全管理是指对数据设定安全等级，按照相应国家/组织相关法案及监督要求，通过评估数据安全风险、制定数据安全管理制度规范、进行数据安全分级分类，完善数据安全管理相关技术规范，保证数据被合法合规、安全地采集、传输、存储和使用。企业通过数据安全管理，规划、开发和执行安全政策与措施，以保障企业和个人的数据安全。

由于无论是对于政府还是企业、个人，数据安全管理都十分重要，为此笔者们在第11章专门阐述了这个主题。

《数据资产管理实践白皮书4.0》中对数据价值管理的主要观点和思想如下：

数据价值管理是对数据内在价值的度量，可以从数据成本和数据应用价值两方面来开展。

本书遵循数据中台的建设方法论，在第10章中，从质量、成本、应用价值等多个维度阐述了如何评估数据资产的价值，涵盖了《数据资产管理实践白皮书4.0》中数据价值管理的内容，请读者移步至第10章阅读相关的内容。

《数据资产管理实践白皮书4.0》中对数据共享管理的主要观点和思想如下：

数据共享管理主要是指开展数据共享和交换，实现数据内外部价值的一系列活动。数据共享管理包括数据内部共享（企业内部跨组织、部门的数据交换）、外部流通（企业之间的数据交换）、对外开放。

数据共享的前提正是数据资产本身蕴含的巨大价值。这种价值不仅体现在组织的内部，对于某些外部客户来说，同样是有价值的。但有价值的数据资产未必由自己拥有或控制，这时候就可以通过数据的共享，使数据资产的提供者和数据资产的消费者同时受益。某些时候，数据资产的提供者同时又是数据资产的消费者，在这种场景下，双方可以交换对方所需的数据资产。这种数据的共享和交换可以直接为企业带来经济利益，同时也是数据资产保值、增值的重要手段。

在数据共享活动中，为了安全和监管的需要，必须对数据输出的状态有相应的分析和监控。数据输出监控有服务链路分析、影响度分析、异常监控警告等。数据API服务管控措施包括API接口鉴权认证、流量控制、访问次数控制等。

数据资产管理过程中，生命周期的管理也是非常重要的部分，每一类数据都有其价值周期，要设置一个合理的数据生命周期需要考虑各方面的因素。在数据中台的实践过程中，首先会将数据分成两类：不可恢复的数据与可恢复的数据。一般涉及原始数据的，都会被定义为不可恢复数据，即清除后没办法找回来；而一些中间过程或者结果数据，只要原始数据在并且相关的加工逻辑在，都可以被重新加工恢复。因此在生命周期的管理策略上，也需要区别对待。

（1）不可恢复数据

一般建议策略为永久保存，在实际实施过程中可以根据企业各方面因素来综合考虑。数据当前没价值不代表未来没有价值，只是当前的技术、认知和场景没有办法使用其中的价值。当然也需要从企业成本考虑，如果什么数据都存，成本部分又无法承受，那反而会将数据变成一种负债，拖累企业发展。在实施过程中，可以考虑冷数据用低价存储的方式，未来需要使用时再进行恢复，虽然可能会有一些效率上的浪费，但和实际的资金成本平衡后也是常常会选择的方式。

（2）可恢复的数据

这类数据只需要有原始数据和加工模型在，就可以通过平台的调度策略进行恢复，因此这类数据的生命周期一般会根据实际使用情况来灵活调整。平台侧可以根据数据使用情况，推荐具体的生命周期保留时长，用户也可以自主选择设置，让生命周期的设置符合实际企业需要。

生命周期管理提供生命周期的设置和自动清理功能，还提供了生命周期建议的功能，即结合数据的热度、存储量变化情况给用户建议的生命周期，帮助用户合理配置。

在数据中台中，标签是一类重要的数据资产。把标签定义为对象的一种描述方法，成为更容易被理解、被识别的一种分类及描述的组织形式。业界常见的标签一般分成两类：一类是数据的分类方式，如根据数据的来源、更新频率、归属部门等进行标识和分类；还有一类是对数据的内容进行重新描述甚至是重新组织的方式，如根据行为特点组织的还贷能力、某个属性从业务视角的重新定义等。

经常和标签一起被提到的有指标、画像及字段等概念，在笔者看来：

·指标是为达到某一个具体业务目标而定义的描述约定，是一种衡量目标的方法，主要是针对某个场景而提炼的一些关键评判维度。

·画像是指某个对象从各个标签的维度的具体内容描述。如某个群体中80%的人还贷能力高，10%还贷能力中，10%还贷能力弱，其中还贷能力是标签，高、中、低则是针对这个群体在还贷能力方面的画像。

·字段是一种物理存储的形态，指标、标签更多是在逻辑层面作为具体的存储方法。二维表中具体的描述方法，如“还贷能力”这个标签，其信息在表中用一个字段来存储，而该字段的取值是其具体画像的内容。

在标签管理中，通常采用标签类目体系的方式来进行分类组织。标签类目体系是标签信息的一种结构化描述，目的是方便业务人员管理、查找所需的指标，因此标签类目体系的构建是需要按照客户真实业务需求来考虑的。

标签管理与资产中心子模块其他部分的一个不同点是它主要针对业务人员，标签管理让业务人员可以看懂数据，把数据低成本地用起来。

标签管理一般包含标签体系的管理、标签与数据映射关系、标签的应用管理。以数澜科技的数栖产品为例，标签管理包含标签池、标签场景、标签应用，标签池对标签体系及标签与数据映射关系进行管理，标签场景针对每个用户不用的应用场景提供支持，标签应用支持用户在标签管理模块基于标签做一些数据探索工作。

数据资产地图为用户提供多层次、多视角的数据资产图形化呈现形式。数据资产地图让用户用最直观的方式，掌握数据资产的概况，如数据总量、每日数据增量、数据资产质量的整体状况、数据资产的分类情况、数据资产的分布情况、数据资产的冷热度排名、各个业务域及系统之间的数据流动关系等。

数据资产目录通过对数据资产良好地组织，为用户带来直观的体验，可以使用户花较少的时间查找到自己关心的数据资产。

数据资产目录的组织方式灵活多样，常见的有按业务域组织、按数据来源组织、按数据类型组织。

根据用户角色的不同，数据资产目录有多种展现视角，概括来讲，有3类用户角色：数据资产开发者、数据资产管理者和数据资产使用者。

·数据资产开发者关注当前开发的数据资产是否有重复，是否有准确的定义，通过数据资产目录，数据资产开发者可以将自己负责开发的数据资产发布到合适的资产目录下。

·数据资产管理者必须掌握数据资产的全局情况，包括拥有哪些数据资产、数据资产分布在哪里、数据资产的质量情况、数据资产的使用情况等。数据资产管理者通过对数据资产的合理授权，控制数据资产的使用。

·数据资产使用者关心数据是什么、数据在哪里、如何获取到数据。通过数据资产目录和获取到的合理授权，数据资产使用者能快速定位到自己需要的数据资产，掌握数据资产的存在形式是什么（结构化还是半结构化），如何获取到自己想要的数据，评估现有的数据资产能否满足所建应用的需要。

数据资产检索服务为用户提供了一键式的资产检索服务，通过对关键字的匹配，数据资产门户检索出相关的数据资产集，用户可以根据需要找到相关的数据资产，可以查看数据资产的名称、创建者、业务语义、加工过程等详情，帮助自己理解和使用数据。

在评估数据资产管理效果的过程中，要考虑到不同行业客户的特点，考虑到客户对数据资产管理的不同要求，采用科学的评估模型，帮助客户认识到当前数据资产管理的水平如何，应该如何改进。

必须认识到，不同行业的业务特点不同，对于数据资产管理的诉求也有所差异。在评估数据资产管理效果时，也必须考虑到不同行业的侧重点。下面以金融、政府部门、电信行业为例，分别说明它们在开展数据资产管理工作时的侧重点。

金融机构监管力度大，对数据标准和数据质量的要求很高，适合自上而下开展大数据资产管理。通过建立权威的数据资产管理委员会，指导数据资产管理工作。参考国际及国家发布的相关标准，制定数据标准管理办法。并从数据质量问题发生的源头开始，将数据质量管理嵌入到系统开发过程，从根本上保证数据质量符合国家的监管要求。所以，金融行业相对更重视数据标准和数据质量的实施效果。

政府部门涉及很多民生相关的数据，例如在智慧城市的建设中，以提升管理和服务水平，方便市民作为出发点。因此，通过打通不同政府部门之间的数据墙、业务墙，在海量数据中快速找到所需数据就显得至关重要。政府部门的数据资产管理必须进行不同部门间的数据交换与共享，在安全可控的前提下适当开放数据接口，拓展民生应用。政府部门相对更重视数据的安全可控、数据交换的及时性和共享开放性。

电信行业数据量特别大，而且增长迅速，数据具备较高的商业价值。在遵守法律、保证安全与隐私的前提下将数据资产化，通过资产管理平台进行数据共享，可以大大拓展与集成商的合作空间，挖掘出数据巨大的商业潜质。电信行业更重视数据资产是否被良好地组织和管理起来，以及是否实现了开放共享。

除了这3个行业之外，在制造业、房地产、安防、军工等行业中，数据资产管理也被提到越来越重要的位置。在帮助客户开展数据资产管理工作的时候，一定要先搞懂客户的核心诉求和行业的特点，才能做到有的放矢，以始为终，取得良好的效果。

客户的业务和数据情况千差万别，对于数据资产管理的诉求也是不一样的。在评估数据资产管理的效果时，不能忽视任何一个客户的独特诉求。

以笔者们经历过的一个电信行业客户为例，在一期数据资产管理项目基本解决了数据标准、数据质量问题的基础上，二期项目客户的主要诉求是建立起数据资产健康度评价模型。于是从处理效率、数据质量、数据价值、数据冗余、数据空间、数据标准、价值密度这7个方面建立数据资产健康评估维度，以了解数据资产健康状况，发现数据中存在的故障线索和健康隐患，并制订相应的解决方案。从而帮助企业有计划地深入开展数据资产管理工作。

而另一家制造企业客户的主要问题是统计分析的数据不准。通过建设数据问题的血缘追溯功能，实现数据质量问题自动化诊断，数据质量问题查证效率提高了70%，查证准确率提升了45%，大大降低了数据质量问题反复沟通成本，提高了工作效率。在此基础上，对发现的数据质量问题进行分析、归类、下发和效果考核，通过一套数据质量管理流程，逐步提升数据质量。

还有一类典型的客户诉求，因为客户内部的数据标准不统一，导致不同部门计算出来的指标千差万别，无法指导业务决策，这时候就需要首先统一企业内部的数据标准，包括指标标准、代码标准、数据开发标准等，统一数据的口径。在此基础上再进行其他方面的数据资产管理工作。

在评估数据资产管理效果的时候，首先要考虑到客户的核心诉求，而不是抱着一套评估模型不变，否则容易导致做了很多工作，但是客户并不满意的结果。

在8.5.3节数据治理的理论体系中，谈到了DCMM数据管理能力成熟度评估模型，这套模型可以帮助企业获得目前数据管理现状、识别差距和提出未来发展方向，同时也能帮助客户评估数据资产管理的效果如何，下一步该如何改进。

DCMM在八大领域，将数据管理的成熟度划分成5个等级：初始级、受管理级、稳健级、量化管理级、优化级（见图8-7）。

图8-7　数据管理的成熟度划分

以八大领域中的数据质量域为例，它包含4个过程域：数据质量需求、数据质量检查、数据质量分析和数据质量提升。再以数据质量检查域为例，其建设目标为：

·全面监控组织数据质量情况。

·建立数据质量问题管理机制。

建设内容为：

·制订数据质量检查计划。

·数据质量情况剖析。

·数据质量校验。

·数据质量问题管理。

数据质量检查域的成熟度等级如下。

·初始级：开展偶然的数据质量检查活动，基于出现的数据问题进行问题查找。

·受管理级：定义了数据质量检查方面的管理制度和流程，明确了数据质量剖析的主要内容和方式，在某些业务领域按计划进行数据质量剖析和校验。

·稳健级：明确了组织级的数据质量检查制度和流程，定义了相关人员在其中的职责，定义了相关的执行计划，统一开展数据质量检查，并根据结果进行考核。

·量化管理级：定义并应用量化指标，对数据质量检查和问题处理过程进行有效分析，可以及时对相关制度和流程进行优化。

·优化级：在业界分享组织数据质量检查的实践经验，成为行业标杆。

以笔者们的经验，大多数企业都处于初始级或受管理级，少部分企业达到了稳健级或量化管理级，极少企业能达到优化级。在数据资产管理工作开展的初期，先对当前的能力成熟度做一个由第三方牵头的客观评估，如评估的结果是企业的成熟度为初始级。经过一段时间，如半年的建设周期后，再做一次评估，看能否达到下一个甚至再下一个成熟度等级。评估工作最好请企业外部有能力、有公信力的机构来执行，避免企业既做运动员也做裁判的情况发生。

除了运用好数据管理能力成熟度评估模型之外，在数据资产管理过程中，取得客户和领导的肯定和支持，让相关干系人能够看到实实在在的成果，也是效果评估中必不可少的一部分。这部分工作考验数据资产管理人员的总结整理能力和沟通能力。如可以客观地评价数据质量的提升曲线，评估用户因为数据质量的提升而减少的线下沟通时间，定期向关键干系人汇报项目进度和成果，在组织内部推广数据资产管理相关的知识和成果等。

大部分组织的数据现状都是先污染、后治理，所以，数据资产管理是一个需要经常“翻旧账”的工作。而随着数据源源不断地产生，由于业务变化的需要，数据资产管理又是一项需要长期进行的系统工程。数据资产管理牵涉到的业务部门众多，利益复杂，系统庞杂，通常需要面对各种数据源情况，具有相当大的难度。要保障数据资产管理工作顺利推行，取得成效，需要建立一个强有力的组织，制定清晰可行的数据战略，培养重视数据的企业文化，制定合理的制度和工作流程，建立统一的标准与规范，使用成熟的软件系统，进行科学的现场实施。

（1）强有力的组织架构

强有力的组织架构是数据资产管理取得成功的有力保证。在开展数据资产管理工作之前，对于组织及其责任分工做出规划是非常必要的。数据资产管理涉及的范围很广，牵涉到不同的业务部门和信息部门，是一件全局大事。如何成立和成立什么样的组织，应该依据企业本身的发展战略和目标来确定，但通常来说，这个组织架构需要高层领导牵头，涵盖业务部门和信息部门。结合企业自身的管理架构，本着专人专事的原则，完整的数据资产管理组织架构中通常需要有如下角色：领导决策层、业务部门主管角色、IT部门主管角色、执行项目经理、执行团队等。在具体的执行岗位上，需要有专人从事专门的工作，如设立数据质量管理人员、数据标准管理人员、元数据管理人员、数据安全管理人员等专门的岗位。

提倡由懂业务、懂数据、懂技术的专职人员来承担数据资产管理的核心工作，在专职人员无法到位的情况下，也可暂时由各部门抽调兼职人员来组成一个临时组织，但要想让工作顺利推进下去，必须对组织的相关人员进行充分授权。

（2）清晰的数据战略

数据战略是指导数据资产管理的最高原则。数据资产管理是否与企业发展战略相吻合也是衡量数据资产管理体系是否成熟、是否成功的重要标准。企业高层和数据资产管理的牵头部门要在企业发展战略框架下，建立数据资产管理的战略文化，包括企业高层领导对数据资产管理的重视程度、所能提供的资源、重大问题的协调能力、未来的目标和发展规划等一系列措施。

（3）重视数据的企业文化

大数据时代的到来带来了很多跨越式发展的机遇，但如果没有大数据意识、大数据思维，没有形成大数据文化，那么就很难抓住这种机遇，实现跨越式发展。所以，要把“大数据”这个科技符号变成“大数据文化”，即政府的文化、社会的文化、企业的文化和大众的文化。以企业为例，企业的管理者应该重视数据的战略价值，逐步引导并培养一种“数据即资产”的价值观，倡导“基于数据做决策，基于数据做创新”的企业行为规范。当全员认识到有价值的数据是一种宝贵的资产后，它就可以发挥业务价值，进而流通、交易、合作，最终变现，并将深刻影响企业的业务模式，甚至重构其文化和组织。

（4）合理的制度与流程

制度与流程是数据资产管理过程中落地认责制度的有效保障。应该由数据管理人员和协调人员共同制定数据资产管理制度流程。常见的制度包括但不限于：

·数据需求管理办法

·数据模型管理办法

·数据标准管理办法

·元数据管理办法

·数据质量管理办法

·数据共享管理办法

·数据安全管理办法

·数据生命周期管理办法

（5）标准与规范

制定数据标准是开展数据资产管理的前提和基础。通常情况下，企业进行数据资产管理都是从梳理和建立数据标准开始的。举例来说，做数据质量检查时参考的规则通常来自于数据标准，做数据清洗时参考的清洗规则通常也来自于数据标准。

制定标准，不应一味地追求全面和严苛，而是要参考企业当前数据的实际情况，合理地制定可落地的标准。同时，标准并不是一成不变的，会因为企业的管理要求和业务的变化而变化。标准和规范都要及时更新，以跟上变化形势。

（6）成熟的软件平台

数据资产管理工作要取得成功，离不开成熟的软件平台支撑，如数据质量管理系统、元数据管理系统、数据标准管理系统、数据安全管控平台、数据资产中心等。它们是数据资产管理工作能够顺利开展的技术和工具保障，能够大大降低数据资产管理工作的门槛，提升工作效率，减少人工投入的工作量，更有利于标准化的实施，有利于持续开展数据资产管理工作。建议选用国内外有实力的数据资产管理厂商的成熟软件平台，保障数据资产管理工作的顺利开展。

（7）科学的项目实施

数据资产管理并不是一次性的项目工作，而是需要长期持续不断地改进。这一点是它与一般项目的不同之处。

在开展数据资产管理项目工作的时候，不仅要考虑到项目管理的范围边界、实施周期、人力成本、质量交付等重要因素，同时也要充分考虑到项目的长期性，在建立起数据战略、组织架构、制度流程、标准规范、软件平台的基础上，仔细考虑如何合理配置资源，让数据资产管理工作不间断地进行。

通常来说，面对复杂多变的信息系统现状和数据现状，数据资产管理工作不宜立即全面铺开，而是需要整体规划，分步实施，突出重点，逐步推广。可以从业务最关心的数据、最重要的数据入手，取得一定的成果后，再推广到更大的范围中。

数据资产管理在数据中台中的角色类似于一个大管家，掌控着数据中台中最有价值的那部分资产。而数据资产的管理能力决定了一个企业能否完成数字化转型。

7月28日　周三　晴　地点：CIO办公室

上次的会议开得很成功，集团资产建设工作也在有条不紊地进行着，但是随即又有另一个问题：数据资产建设过程中产生的数据资产，怎样才能有效地管理起来？包括对数据资产价值的盘点，对数据质量的评估，对数据应用情况的统计，等等。这可是咱们这家企业所有的数据家底啊。

下午和赵伟就这个问题进行了讨论。赵伟认为，数据资产管理最核心的是要做两件事：

一是建设数据资产门户（见图8-8）。通过对数据资产的梳理、盘点、组织，为数据资产开发者、数据资产管理者、数据资产使用者提供多层次、多视角的数据资产视图。帮助管理者掌控企业所拥有的数据资产全局状况，比如企业有哪些数据资产、分布在哪里、总量有多少、增量情况怎么样、哪些是高价值资产，等等。帮助使用者快速准确地定位并准确理解自己关心的数据资产。通过数据资产目录，数据资产开发者可以了解企业组织数据资产的方式，并将自己负责开发的数据资产发布到合适的资产目录下，等等。

图8-8　资产门户一览

二是数据资产的治理。比如通过数据标准管理，确保企业内的数据定义是唯一的，取数口径是一致的；通过数据质量管理提升数据资产的质量，通过数据安全管理确保数据是安全可控的，等等。

“数据资产管理会涉及很多部门和系统，是个系统工程，需要领导支持，最好是建立专门的职能部门来负责，通过建立相关的制度和流程来保障工作顺利开展，同时还要选用合适的工具，持续开展下去，才会收到良好的效果。”赵伟一贯都是有了整套的解决方案，再抛出问题，这已经成了我们之间的默契。可以看出，对于数据资产管理他已是成竹在胸。

“那对于数据资产管理工具的选择，你的建议是？”

“刘总，我对这个问题已经进行了考察，刚才展示给你看的那张图，就是想采购的那款工具可以提供的……”

下午效率很高，和赵伟就选择哪一款数据资产管理工具达成了共识。资产门户和资产治理将是下一阶段重点跟进的内容。

水是生命的源泉，是人们赖以生存和发展的重要物质资源。在日常生活中，可以通过不同的方式使用水，这也给我们的生活带来巨大便利。在数据世界中，数据资产就好比日常生活中生命所需的水资源，无处不在且不可或缺。但是如果没有相应的水加工厂、运输管道，人们只能到水库打水喝，这明显会极大影响人们正常的生活和工作。因此，将数据资产封装成数据服务，以接口方式提供给上层应用，才能极大释放、提升数据资产的价值。

数据服务体系就是把数据变为一种服务能力，通过数据服务让数据参与到业务之中，激活整个数据中台，这也是数据中台的价值所在。

数据资产只有形成数据服务被业务所使用，才能体现其价值。以往传统做法是根据某个应用产品的需要，独立构建非常多的数据接口与应用产品对接，这会形成数据接口的“孤岛”，造成大量接口的重复建设，且修改、运维、监控的成本都很大，需要抽象成可管理、可复用、可监控的统一标准下的数据服务体系。而通过数据服务便捷地对接业务系统或应用系统，才能将数据资产灵活使用起来，最终给企业带来各种适配业务场景的数据解决方案，从而提升效率。数据服务作为数据中台实现资产服务化的核心能力，是连接前台业务和数据的桥梁，通过服务接口的方式对数据进行封装和开放，快速、灵活地满足上层应用的需求。数据中台能够以提供数据服务的方式直接驱动业务，不需要人的介入，让业务更快地产生价值。

由图9-1所示的数据中台架构可以看到，数据服务是数据中台能力的出口，是支持数据应用的重要支撑。在数据中台落地支撑业务时，数据分析师或算法工程师可以通过数据服务配置中台数据资产的访问API，这样数据应用产品可以方便地使用中台的数据能力，支撑业务决策和智能创新。

图9-1　数据中台总体架构图

按照数据与计算逻辑封装方式的不同，数据服务可分为以下三类：

·基础数据服务：它面向的对象是物理表数据，主要面向的场景包括数据查询、多维分析等，通过自定义SQL的方式实现数据中台全域物理表数据的指标获取和分析。

·标签画像服务：它面向的对象是标签数据，主要面向的场景包括标签圈人、画像分析等，通过界面配置方式实现数据中台全域标签数据跨计算、存储的统一查询分析计算，加快数据应用的开发速度。

·算法模型服务：它面向的对象是算法模型，主要面向的场景包括智能营销、个性化推荐和金融风控等，主要通过界面配置方式将算法模型一键部署为在线API，支撑智能应用和业务。

数据服务作为补全数据应用的最后一公里，它的核心价值有以下4点。

（1）确保数据在业务层的全域流通

数据服务可以对数据中台的全量数据进行封装透出，让中台的数据支撑数据业务，加速数据业务化的流程；数据业务产生的反馈数据可以回流到数据中台中，不断优化现有的数据服务，让数据在业务中持续流动起来。

（2）降低数据接口的重复建设

前端不同的数据应用对数据的需求有些是类似的，例如客户画像和客户精准营销都对客户的特征标签有需求，通过统一的数据服务创建的包含客户特征数据的接口，可以通过授权分别提供给画像和营销两个应用。与以前的烟囱式开发相比，这样做的好处是可以避免数据接口的重复建设。通过一次创建、多次授权的方式交付给前端。

（3）保障数据获取的及时性和稳定高效

通过统一的数据服务，对于不同业务部门给数据中台提的数据需求，中台管理方可以进行统一规划和分配，从整体上保证资源和需求的协调。同时，通过数据服务中的数据，中台可以及时得到业务上的完整反馈信息，并基于真实数据及时调整：若需要及时的数据，则给予实时性的保障；若需要稳定的数据，则给予可用性的保障。

（4）使能数据能力扩展

通过统一数据中台，不断扩展数据源、优化数据资产建设、扩展数据服务封装方式，将数据能力进行持续扩展，不断给数据业务和数据应用提供更多数据价值。

数据服务类型是对数据使用场景的抽象提炼，可以根据不同的数据使用场景，抽象出查询服务、分析服务、检索服务、圈人服务、推荐服务、风控服务等多种数据服务类型。这些最小化的数据服务可以按需组合在一起，构成一个复杂的数据服务体系，并通过交互界面的封装，形成一个数据应用产品。

由于篇幅有限，本节仅介绍4种较为常见的数据服务，如图9-2所示。

图9-2　4种常见的数据服务类型

查询服务通过一个标识（key）查询其所对应的内容，可以附加一些条件过滤选项来满足检索要求。如常见的根据账号查询其相关的档案信息、根据商品查询其销售信息等，都属于查询服务的应用场景。

如图9-3所示，查询服务具备3个特征，下面来一一介绍。

（1）支持配置查询标识

查询服务一般会有一个查询标识，会根据该标识去定位具体内容，底层数据组织一般会对该标识建立索引，以加快查询速度。

图9-3　查询服务的3个特征

（2）支持配置过滤项

过滤项配置是指用户在进行标识查询时，配置一些过滤条件，以满足个性化的数据查询需求。该场景在应用层随处可见，比如查询一个人的账单流水数据，一般会配置一个时间区间，查询该时间区间的账单流水数据。

（3）支持查询结果配置

查询服务支持查询结果配置。常见的配置包括数据排序规则以及分页规则。数据排序就是对查询的结果数据做排序处理，包括升序、降序、自定义排序和组合排序。分页规则通常只需要设置每页要展示多少条数据即可。

查询服务的构建包含4个过程，如图9-4所示。

（1）数据接入

可以通过数据库、文件或API等形式把数据连接进来，也可以通过数据平台对接数据资产库数据，实现资产服务化的过程。

图9-4　查询服务的4个构建过程

（2）数据查询

可以通过传参或图形化界面进行查询配置。一般会配置查询标识和过滤条件。

（3）结果规则配置

对于查询好的数据，可以设置排序规则和分页规则。排序规则规定按哪个字段进行排序，排序方式包括升序、降序和自定义。用户可以设置多个排序规则，按排序规则的前后顺序生效。用户可以设置结果数据的分页规则。

（4）能力开放

所有配置完成后，查询组件最终会生成一个服务API，供上层应用调用。该服务API中包含按查询规则生成的结果数据。

分析服务通过各种数据统计分析的方法，对数据做任意维度的数据分析挖掘，让数据分析人员快速了解数据集的特点，以支持数据化运营、分析决策等场景。常见的如BI工具、数据化运营中的路径分析、漏斗模型等，大部分是基于这种能力来构建的。

分析服务通常具备4大特征，如图9-5所示。

图9-5　分析服务的4大特征

（1）支持多源数据接入

企业的数据经过清洗加工转化成数据资产后，最终通过服务作用于业务系统。基于企业异构存储的现状，要求分析服务能够支持与Hive、Elasticsearch、Greenplum、MySQL、Oracle、本地文件等多种数据源进行连接。此外，它应该还支持公有云和私有云等形式的数据接入，从而帮助企业实现业务数据的无缝对接。

（2）高性能即席查询

随着企业数据爆发式增长，每天产生的数据量由之前的千级别、万级别，转变成现在的百万级别、千万级别，甚至亿级别。这就导致传统的数据分析工具遇到分析能力的瓶颈，也就是对大数据量的分析越来越乏力。因此，这就要求分析服务内置高速计算引擎，以对数据进行高性能的即席计算，实现亿级数据毫秒级（至多秒级）分析和计算，减少用户等待时间。

（3）多维数据分析

在数据驱动决策深入人心的今天，越来越多的企业开始意识到数据的价值，从而对数据分析也提出了更高的挑战和要求。分析服务除了支持常规的数据分析、上卷下钻、切片切块之外，还应该支持多维的数据分析以及深层次的数据挖掘，发现数据背后的关联关系。

（4）灵活对接业务系统

最终的分析结果会以接口的形式输出给业务系统，供业务系统调用。为了适配企业多样的业务系统，服务接口允许用户自定义构建。分析服务应提供包括接口URL、后端服务类型、接口请求模式等在内的多个配置项，以最大程度地满足业务需求。

如图9-6所示，分析服务的构建包含3个过程。

（1）数据接入

“巧妇难为无米之炊”，如果没有原始的数据接入，也就没办法向上层应用提供服务。而且，接入的数据必须具备分析的价值，否则，即使通过分析服务分析之后，也不会给企业带来价值信息。了解了这两点之后，可以把业务所需的数据通过各种数据库、API或文件等形式与分析组件进行对接。

图9-6　分析服务的3个构建过程

（2）在线建模

在线建模本质上就是构建SQL语句的过程，把用户要分析的条件变为SQL语句来将数据查询出来。在这个过程中，业界通常会提供两种方式：一种是SQL代码编辑器，另一种是图形化界面。

SQL代码编辑器方式就是让用户通过代码编辑器直接编写SQL代码，查询要分析的数据。通过SQL代码编辑器，用户可以实现较复杂的数据分析。但对于业务人员来说，SQL代码编辑器非常不友好，由于不了解SQL，他们不能正常分析数据。

图形化界面则是专门为了方便业务人员使用而设计的。业务人员通过简单的“拖曳”完成数据分析操作，再由分析组件把用户的操作转化成系统能理解的SQL语句，从而实现数据的分析和查询。这种方式对于业务人员来说非常方便，简单易上手，但是通过这种方式不能实现复杂的数据分析。

（3）能力开放

完成建模后，分析组件会自动生成一个API对外透出，当然用户也可以对API进行自定义调整。对于生成的API，需要控制其使用权限，并不是所有的应用都可以调用它，只有经过审核的应用才能调用，这样可以避免数据资产泄露。

推荐服务即所谓的千人千面，对不同的人对物的行为进行数据挖掘，构建每个人与物之间的关系程度，来推荐人、物以满足用户的兴趣偏好，以提升用户对业务的黏性。大家听过最多的啤酒与尿布的案例就是其中一种，只不过它是从物与物的关联性来找到相关的人群，以提高用户的消费力。每个人打开手机淘宝看到的内容都不一样，这就是一种基于人的兴趣偏好的推荐服务能力。

推荐服务具备以下3大特征（见图9-7）。

（1）支持不同行业的推荐

推荐服务是具备行业属性的，不同行业背后的推荐逻辑是有区别的。比如电商领域和内容资讯领域，同样都是浏览行为，但是在推荐模型进行计算的过程中，两者所占的比重完全不一样。所以在电商、内容资讯、视频直播、音乐媒体、社交等不同领域中，推荐服务都应该具备和该领域适配的推荐能力。

图9-7　推荐服务的3大特征

（2）支持不同场景的推荐

即使在同一个行业中，对于推荐的使用也会存在不同的场景。还是以内容资讯类为例，在用户冷启动场景下，应该为其推荐哪些资讯？在用户已经有浏览行为的场景下，又应该为其推荐哪些资讯？在资讯冷启动场景下，应该为其推荐哪些用户群体？在资讯已经被浏览之后，又应该为其推荐哪些用户群体？不难发现，在不同的场景下，同行业下的推荐逻辑也是完全不同的，所以推荐服务应该覆盖这些不同的推荐场景。

（3）支持推荐效果优化

推荐服务的终极目标是成为用户的贴心管家。不需要用户的任何思考，推荐服务就能向用户推荐他想要查看的物品或资讯。这就要求推荐服务能够自我迭代，自我更新。从导入的原始数据开始，经过推荐组件生成推荐数据，再根据用户的浏览数据不断修正推荐模型，从而使推荐效果不断优化。

推荐服务的构建包含5个过程，如图9-8所示。

图9-8　推荐服务的5个构建过程

（1）选择行业和场景模板

一般需要先选择推荐服务的应用行业，是电商类推荐还是新闻资讯类推荐，是视频直播类推荐还是社交类推荐，等等。此外，还要选择推荐服务的应用场景，是用户冷启动推荐还是用户热启动推荐，是商品冷启动推荐还是商品热启动推荐。不同行业、不同场景背后的推荐模型不同。

（2）原始数据接入

选择好要使用的推荐模型之后，就需要把相关的数据接入进来。通常要接入三类数据：一类是用户相关的数据，一类是物品相关的数据，最后一类是关系类数据（用户和物品发生关系的数据）。

以新闻资讯类为例，用户数据包括用户的基本信息、行为习惯、兴趣偏好、性格特征等内容；物品数据包括新闻资讯的基本信息、从属关系、功能特性、价值属性等内容；关系类数据是指浏览、分享、点赞、评论等内容。

（3）参数配置

数据导入后，通过服务参数设置可以便捷地配置推荐模型的模型结构、样本指向、目标设定、输入输出格式等参数，推荐模型即会在设定的参数下开始自动化训练运行，直至模型稳定下来后，产出推荐结果或稳定的推荐模型。

（4）能力开放

通过模型训练后最终会生成一个可供调用的推荐API，该API支持传入ID参数，实时或离线计算后，将适配该行业或场景下的推荐数据输出返回到相应的上层应用系统中。

（5）数据回流

上层应用使用推荐服务提供的推荐数据后，产生的效果数据还要回流到推荐模型中，也就是要把新一轮的用户数据、物品数据和关系数据导入推荐组件，设置一定的同步周期，通过数据不断修正推荐模型，从而大大提高推荐的准确性。

各行各业都会涉及广告营销场景，而如何找到对的人推送广告就成了大数据场景要解决的问题。圈人服务应运而生，通过提供人群圈选服务，帮助服务使用者从全量用户数据中基于标签组合筛选出符合指定特征的人群，并以API的形式对接上层的营销系统，从而实现营销广告的精准触达，最终达到老客户召回、休眠客户激活等运营目的。

圈人服务具备3大特征，如图9-9所示。

图9-9　圈人服务的3大特征

（1）支持人群圈选

圈人服务的核心在于人群圈选，通过SQL代码或标签取值组合等多种方式，实现人群查找，帮用户找到对的人群。

（2）支持人群计量

营销部门或广告公司使用圈人服务圈选出目标人群后，往往还要考虑人群量是否符合预期，因为预算有限，不可能无限量或者不计成本地对人群进行营销。因此在通过条件圈选后，系统需要能快速计算出符合条件的人群量，如果数量多于预期，则建议继续追加条件圈选更精准的人群；如果数量少于预期，则建议放宽筛选条件，或者继续圈选其他合适人群。

（3）支持多渠道对接

人群圈选并计量测算，确认是业务方所需目标人群后，需要能够将人群名单导出到相应的下游系统。最简单的名单导出方式是先下载文件，再由业务人员导入相应的业务系统中。当人群名单量达到千万甚至上亿级，或人群圈选需要自动化对接时，需要将人群名单直接对接到短信系统、微信投放接口、营销活动系统等。

圈人服务的构建包含3个过程，如图9-10所示。

图9-10　圈人服务的3个构建过程

（1）数据接入

圈人服务的第一步是接入人群数据，用户可以通过文件、数据库、API等多种方式导入数据。

（2）人群圈选

圈人服务的本质其实是数据查询分析的过程，根据用户输入的条件，返回符合相应条件的人群数据。针对不同的使用场景，通常会提供多种圈人方式，以满足不同类型客户的需求。面向开发人员，可以提供SQL代码编辑器进行圈选。开发人员直接在代码编辑器中编写要查询的SQL语句，实现人群圈选。面向业务人员，可以提供图形化界面进行圈选。业务人员通常对代码了解不多，所以直接通过界面拖曳标签，勾选计算逻辑的方式，能大大降低他们的学习成本。

（3）能力开放

和所有其他服务一样，圈人服务最终也会以API的形式向上层应用透出。圈人服务通常会提供两方面的信息：一是圈选出的人群包名单，二是圈选的人群特征。下游的分发系统，例如短信系统、营销活动系统、广告系统等，会根据圈人服务提供的API，向这个人群发送符合该人群特征的文案内容或创意广告，从而实现精准触达，提升点击率和转化率。

根据上文所介绍的4类数据服务，可以对接多种数据应用。本节简单阐述3种常见的数据应用（见图9-11），帮助大家更好地理解它们和数据服务的关联关系。

图9-11　3种常见的数据应用

数据可视化大屏是一门将科学和艺术相结合的技术，将数据以可视化的方式直观呈现，在诸多领域都有广泛应用。越来越多的政府部门、企业青睐于通过这种强视觉形式来展现重要的数据，它是当前计算机科学的一个重要研究方向。近年来，我国的大数据产业呈现出高速增长的趋势，其中大数据产业8大趋势之一的数据可视化也迎来黄金发展期。查询服务作为最常见的一种数据服务，也是可视化大屏数据来源的重要支撑部分。用户创建查询服务接口，然后在可视化大屏里面配置相关API，就可以支撑可视化大屏的展现。

数据可视化大屏旨在把一些统计性、结论性、预测性数据通过可视化框架（WebGL、D3、three.js或Mapbox等）渲染出来直观地呈现给读者。可视化大屏的使用者是决策人员，它基于数据多维度分析，为管理决策提供数据支撑。

可视化大屏的使用场景主要有两类：

·公关：一些会议展览、业绩汇报等场景，面向媒体公众展示管理成绩、营收效益的可视化，以宣扬团队实力为目的，载体多为展厅里的大屏，交互方式以轮播为主，通过小屏控制大屏的交互场景也较多。

·监控：一些风险预警、实时作战指挥中心等场景，对管辖区域内的数据进行监测和分析，以指导制定政策为目的，载体为可视化大屏、液晶显示器、电脑灯，可直接用鼠标进行交互操作。

数据可视化起源于图形学，到了19世纪下半叶，系统构建可视化方法的条件日渐成熟，使其进入了黄金时期。法国人Charles Joseph Minard率先将可视化应用于工程和统计，其最著名的工作是1869年将1812—1813年拿破仑东征莫斯科大败而归的事件做成流图（见图9-12），这幅图如实呈现了军队的位置和行军方向，军队汇聚、分散和重聚的地点和时间，军队减员的过程，撤退时严寒气候造成人员伤亡等信息。

由近代护理事业的创始人南丁格尔创作的堆叠饼图（见图9-13），如实反映了1854年克里米亚战争4千多名英国士兵的死亡主因并不是直接战死，而是没有得到及时救治以及恶劣环境的影响。

近年来随着计算机图形学的发展，尤其是人工智能的发展，加上科学可视化（如医院人体的CT检查、心电图等）以及人机交互界面等领域的相互促进和发展，数据可视化的发展迎来黄金发展期。数据可视化是当前计算机科学的一个重要研究方向，它利用计算机对抽象信息进行直观表示，有利于快速检索信息和增强认知能力。

图9-12　拿破仑东征事件流图

图9-13　南丁格尔玫瑰

数据可视化的基本流程是数据调研、数据开发、数据服务、可视化呈现，如图9-14所示。

图9-14　数据可视化的基本流程

（1）数据调研

需求分析是大数据可视化项目开展的前提，要了解项目背景与目的、业务目标、业务范围、业务需求和功能需求等内容，明确企业对可视化的期望和需求；要了解企业当前数据状况，质量达不达标，满足主题域的原始数据全不全，缺失的数据是要购买还是通过公开网站获取等。

（2）数据开发

数据开发是利用开发工具加工原始数据，产生可视化大屏业务所需的数据。通常会基于数据开发IDE进行，包括离线开发、实时开发和算法开发。

（3）数据服务

基于加工好的数据，利用数据服务套件，对数据进行封装，生成在线的API。

（4）可视化呈现

在数据可视化套件中，配置数据服务API数据源，产生可视化大屏。

分析服务接口往往对接报表分析类的分析型数据应用。这类数据应用重在通过图形化方式呈现各类关注指标，并通过下钻、对比、关联分析等功能实现对数据自由灵活的查看、比对、研究，是管理者和分析师做企业经营分析或行业研究分析时的常用工具。

什么是报表分析？流水账记录后，每天或者每隔一定时间由账房先生对收入及支出进行加和，得到盈亏数据，这就是最早、最基础的报表分析。时至今日，本质不变，报表分析其实就是以各类报表为基础进行的更深一步的分析计算，以期得到能够描述报表中数据特征的数据，来指导下一步的工作，其分析的结果可以通过文字、数值、图形等多种形式输出。

报表分析按照所能提供的能力分类，其发展大致可以划分为三个阶段，其阶段的演变基本与报表的演变历程一致。

这个时候人们对于分析维度几乎没有什么认知，分析主要集中在观察后的主观认知和简单的加减计算，应用于粗放的管理模式。笔者们把这时的报表分析能力叫作记录能力，这种情况一直持续到计算机的出现。

当计算机出现后，报表逐渐开始往格式的多样化和数据的动态化方向发展。各类数据库软件拥有了实时动态变化的数据，实现了报表数据的动态化，但一般只能提供最简单的表格形式来显示数据。以Excel为代表的编辑类软件，则实现了报表格式的多样性，使用这类软件能做出复杂的报表，但需要提前准备好数据，不能动态加载数据。这两种形式的报表将报表分析推到了初步分析的层面，能够通过多样化的图表形式得到侧重点不同的结论，例如饼图的占比分析、折线图的趋势分析、雷达图的多序列数据综合价值分析；也能凭借数据的动态化特性及时得到结论，提高响应速度。但这一阶段报表分析的能力主要集中在统计层面，且无法同时满足对数据动态化及图表多样性的需求，笔者们将这一阶段的报表分析能力叫作统计能力。

随着大数据时代的到来，以及BI（Business Intelligence，商业智能）模式的出现，人们对报表分析的需求变得越来越复杂。庞大的数据量、多样的数据类型、更专业的分析需求等催生了专业的报表软件，这时候的报表和报表分析已经逐渐淡化了边界。BI类软件就是这个时代最具有代表性的产物，它具备专门的报表结构来动态加载数据，也有多样化的图表形式来分析数据并展示结论，并且通过不断深入分析、挖掘数据的内在、潜在价值，将数据转化为知识，以帮助企业做出相对准确的经营决策，这时的报表分析才真正迎来分析能力的时代。如何将数据背后隐藏的价值通过报表分析最大化地发挥出来，直接决定着企业运营的效率及未来的竞争力，这也是BI时代报表分析技术的研究方向。

按照对数据特征探索的深度不同，目前的报表分析从功能层面大致可以划分为统计报表、数据分析、数据挖掘3种类型。

统计报表主要集中在描述性统计的层面，通过提供灵活的、可自定义的、能便捷生成的各类表格和图表，例如柱状图、条形图、折线图、饼图、直方图、箱线图、散点图、瀑布图、雷达图等，让用户能够自主地将所想变为所得。它的价值主要表现为两个方面：一方面，最基础的，它将数据库中存在的数据转变为业务人员可以读懂和获取的信息；另一方面，它对数据做了描述性统计层面的处理，能够将数据的一部分外在特征呈现给用户，例如频数、比例、趋势、离散程度等。

数据分析和数据挖掘则主要针对的是从数据中发现新的特征，属于探索性数据分析和验证性数据分析的维度。数据分析层面常用的方法有假设检验、显著性检验、相关分析、距离分析、回归分析、聚类分析、因子分析、主成分分析、关联分析等。而数据挖掘最常用的方法则主要有分类、估计、预测、相关性分组或关联规则、聚类、复杂数据类型挖掘等，其中常用的算法模型有k-means、ANN、神经网络模型、遗传免疫算法、决策树等。它们能够从杂乱无章、看起来毫无关联的数据中发现潜在的特征关系，或者通过分析对已有假设进行证实或证伪。

报表分析产品从交互界面端获得用户对数据进行统计分析、数据分析、数据挖掘等类型的数据操作指令后，产生一条输入信息并传递到分析服务，分析服务根据数据操作指令，调用后端的数据计算引擎，快速完成数据计算后，将计算结果通过输出接口传递回报表分析产品端，可视化呈现给用户。

智能应用是数据应用的核心组成部分，是从数据洞察到业务创新的重要支撑。在数据服务应用体系中，常见的智能应用包括个性化推荐应用、精准营销应用等。9.2节的推荐服务、圈人服务都是智能应用的数据服务组成部分。

智能应用结合数据建模和人工智能等多种技术，从数据中提炼、发掘、获取有揭示性和可操作性的信息，从而为人们在基于数据进行决策或执行任务时提供有效的智能支持。

目前在智能应用方面发展得比较成熟的行业有金融、公共安全、教育、零售、医疗健康、工业制造、手机及互联网娱乐、广告营销、家庭家具、交通出行等。典型场景应用有个性化推荐、精准营销、大数据风控、人脸识别等。典型智能应用如图9-15所示。

图9-15　典型智能应用总览

每个智能应用场景的内容和功能都不一样，本节以个性化推荐应用和精准营销应用为例重点说明。

（1）个性化推荐应用

个性化推荐在日常的网络应用中无处不在，比如网上购物、新闻App、社交网络、音视频软件等，有人的地方就有推荐。根据个人喜好物品的特性，或者相同喜好人群的习惯等信息进行个性化的内容推荐，就是我们所说的个性化推荐。

根据数据源的不同，个性化推荐可以细分为三类：

·基于人口统计学的推荐：主要根据系统用户的基本信息来发现用户的相关程度。

·基于内容的推荐：主要根据物品或内容的元数据，发现物品或内容的相关性。

·协同过滤推荐：主要根据用户对物品或信息的偏好，发现物品或内容本身的相关性，或者发现用户的相关性。

个性化推荐往往在用户特征数据与目标物特征数据之间建立关联匹配算法，通过算法模型计算得出针对每个具体个体的推荐结果。个性化推荐的前提条件是积累了大量用户对目标物的行为记录，例如浏览、搜索、查询、下单、交流等，在此基础上，增加时间衰减、广泛热度、同类型、突变因子等因素的权重考量，通过推荐模型的训练运算，离线或实时计算得出推荐结果。

业务系统从交互界面端获得访问用户的ID信息，及用户准实时的行为表现信息，即时产生一条输入信息并传递到推荐服务，由推荐服务根据收到的ID数据及准实时行为数据，调用后端的数据计算引擎，实时完成推荐算法计算或查询离线推荐结果，然后将计算或查询结果通过输出接口传递回业务系统的目标物展示界面，通过前端目标物列表呈现给用户个性化推荐的目标物结果。

（2）精准营销应用

精准营销是指将营销信息或营销产品通过精确的定向技术推送给目标受众的营销手段。这个定义强调了两个概念。第一个是推送的内容既可以是营销的文案或者广告等消息，也可以是要营销的产品本身。这个理念主要针对现在厂商类型和产品的多样性，例如奶粉厂商要投放的是广告，而媒体资讯平台要推送的就是产品本身。第二个是推送的效果必须是双向的，推送的内容只被目标用户看到，且用户需要的正是你的营销内容。而在这种理念下，对精准营销技术手段的要求就非常高。

根据营销的渠道形式，精准营销可以分为广告系统中的精准营销与营销活动系统中的精准营销。广告领域是最早运用精准营销的领域，因为广告领域中每天面对的是几十亿乃至几百亿条的流量信息，常规做法是广告公司、品牌公司直接买断优质广告位或优质客户流量，但是这种方式有较大的资源浪费，因为部分流量可能对广告内容并不感兴趣。因此广告流量联盟希望能将流量资源的利用最大化，开始尝试构建DMP系统：每一个广告商根据自身产品特征及目标客户画像，制订精准营销计划，在DMP系统中圈选的人群会自动对接到DSP系统中进行实时竞价精准投放。各公司的营销部门也逐渐开始使用精准营销系统为不同的营销活动制定目标客群，圈选出的客群名单需要对接到具体的活动载体系统中去，例如短信、微信、App等。

精准营销系统一般需要先建立产品和用户的标签体系，形成产品画像及用户画像，通过标签圈选功能，筛选出满足标签值组合条件的人群，对接营销投放系统，并对营销效果数据进行对比分析。通过对营销人群、营销内容、营销环境、营销载体等多维组合制订不同的营销计划，淘汰效果较差的营销计划，一步步筛选出效果最好的营销计划，分析挖掘出产品与受众之间的最佳匹配关系。

营销系统从营销端获得访问用户的ID信息，即时传入圈人服务，由圈人服务根据收到的ID数据，调用后端的计算引擎完成分组查询后，将适配的营销内容通过输出接口传递回营销系统进行相应的营销展示。