《数据中台:让数据用起来》思维导图模板

架构

目标

让数据持续流动和使用起来

把数据转变为资产

数据汇聚

理解

首要目标是打破数据孤岛

是数据接入的入口，目的是把分散在各处的数据进行采集和存储，得到一堆未处理或简单处理的原始数据

类型（时效性角度）

离线批量汇聚

实时采集

常见的具体方式

数据库同步

如同步服务端计算使用的数据时

埋点

如需要前端的交互数据时

网络爬虫

如需要抓取网络信息时

消息队列

1. 方法与工具

线上行为采集

线上行为的载体（数据生产终端）

传统互联网

PC系统

PC网页

移动互联网

H5

小程序

APP

智能可穿戴设备

...

技术方案

客户端SDK埋点

全埋点

记录设备上用户的所有操作

适用范围

终端设计标准化，有统一接口

优点

不用频繁升级，一次验证发布后就可获取终端全量行为数据

对于新需求，可以直接从历史数据进行加工

缺点

存储和传输成本高

定制化程度低

可视化埋点

阉割版的全埋点，通过服务端配置，有选择的记录部分范围数据

适用场景

存储和带宽成本敏感

优点

成本更低

缺点

有些需要的数据可能过去没有采集

代码埋点

根据需求来定制收集内容

适用场景

终端设计非标准化

事件行为需要代码控制

优点

灵活性强，可针对复杂场景单独设计方案

存储和带宽的优化空间大

缺点

需要终端模块升级迭代才能实现新需求，升级周期长

成本高，容错低，维护难度大

服务端SDK埋点

适用场景

通常与客户端埋点结合，补足用户数据

常见方式

http服务器

access_log

定制SDK

主要用户捕获服务端中无法通过常规访问获取的数据，如耗时、包大小等

优点

降低客户端开发复杂度

降低了安全风险（因为节省了客户端上报数据到服务端的过程）

缺点

一些用户行为并不向服务端发出请求，这种场景的数据无法采集到

线下行为采集

通过通过硬件实现

常见方式

WiFi信号采集

通过wifi采集周边移动设备信息

常涉及隐私问题和系统维护，设备会做防采集处理

目前已经不怎么使用这种方式

原理：当移动设备在探测SSID时，通过信号探测协议，与其建立网络连接，在协议中获取设备信息

信令数据采集

图像视频采集

智能摄像头

传感器探测

...

互联网数据采集

爬虫

内部数据汇聚

数据的组织形式

结构化数据

定义

规则、完成、严格遵循数据格式规范

可用二维逻辑表现

常见形式

数据库表、Excel表等二维表

半结构化数据

定义

规则、完成、严格遵循数据格式规范

无法用二维逻辑表现

常见形式

JSON、XML

非结构化数据

定义

不规则、不完整

无法用二维逻辑表现，需要复杂的处理才能提取信息

常见形式

文档、图片、音频、视频等

时效性

离线

适用场景

大批量数据的周期性迁移

时效性要求不高

方式

分布式批量数据同步，通过连接读取数据

全量/增量

统一处理后写入目标存储

实时

适用场景

时效性要求高

方式

增量日志、通知消息等

数据建设过程

两种模式

ETL

Extract-Transform-Load，抽取-转换-存储

ELT

Extract-Load-Transform，抽取-存储-转换

在大数据场景下更适合使用ELT，抽取后直接存储，然后再清洗

大数据场景下的选择

ELT更合适

ETL模式在传输过程中进行复杂清洗，会因数据量大和清洗复杂降低传输效率

ELT将更多的数据保存下来，以便将来可能发掘出新的价值，ETL则丢失了这种可能性

常见的汇聚工具

Canal

Sqoop

Data X

2.数据交换产品

目标

屏蔽底层工具的复杂性，以可视化的配置方式提供给企业用户

满足异构存储、易购数据类型的交换

不同时效要求下的数据互通

数据源管理

什么是数据源

已经存储了业务数据的地方

具体应用场景也是数据源，数据中台可以为其提供存储

分不同的场景有不同的侧重点

实时可读性

大批量多维度分析能力

....

离线数据交换

时效要求低、吞吐量大的场景

原理：将不同数据源的数据交换，抽象为写入人插件和读取插件

读取插件

采集数据源的数据，发送给数据交换核心模块

写入插件

从交换核心取数据，写入到目的端

数据交换核心模块

作为通道，连接读取和写入插件

处理缓冲、流控、并发、数据转换等核心技术问题

技术亮点

前置稽核

数据同步开始前校验数据质量，决定是否运行同步

数据转换

将非标准数据转化为标准格式

跨集群数据同步

全量同步

表全量同步

读取表中全量数据并写入

库全量同步

把库中所有表进行同步

要求源端和目的端表名称、结构相同，目标表不存在时自动创建

增量同步

新增策略

在目的端创建新分区或追加写数据

覆盖/更新策略

同步时选择唯一键，对比新老数据，结合增量策略决定是覆盖还是更新

实时数据交换

把数据库、日志、爬虫等数据实时介入kafka、hive、oracle等存储，便于后续实时计算

核心服务

数据订阅服务

数据的订阅和读取、任务实力的启停控制等

数据消费服务

任务状态控制、数据解析、数据过滤、数据转换、数据写入等

通过任务配置，将数据写入到目的端

3.数据存储的选择

数据规模

关系到对未来的发展预期

选择成本可控且易扩展的存储方式

数据生产方式

一些数据生产时不进行存储，需要有一个能满足数据实时落地的存储

若目标存储不具备较好的实时落地性能，可以在中间加一个写性能较好的存储作为缓存

数据应用方式

数据使用场景决定了数据存储的选型

离线分析适合非人机交互的场景

搜索需要能快速检查并支持关键字和权重处理

...

在线与离线

在线

用户随时可读，满足计算平台对数据访问的速度要求

离线

对在线存储的备份，防范数据灾难

离线数据不经常被调用

读写时是顺序进行的，修改已写入的数据时，要全部改写

速度慢、效率低

OLTP与PLAP

存储技术

分布式系统

多个自主的处理单元，通过网络协作完成任务，分而治之策略

分布式文件系统

提供底层存储能力支持

HDFS

高容错系统

适用于批量处理、高吞吐量的数据访问

分布式键值系统

存储关系简单的半结构化数据

存储和管理的是对象，而非数据块

No SQL 数据库

关系型数据库无法满足web2.0

无法满足海量数据管理需求

无法满足高并发需求

扩展性和可用性功能太低

No SQL优势

支持超大规模存储

灵活的数据模型支持web2.0应用，横向扩展能力强

常见

键值数据库

列族数据库

文档数据库

图形数据库

云数据库

部署在云中，以服务方式提供数据库功能

数据开发

简介

是一整套数据加工以及加工过程管控的工具

提供离线、实时、算法开发工具，以及任务的管理、代码发布、运维、监控、告警等一系列集成工具

通过数据汇聚得到的是待处理的原始数据，数据开发将其变成可供业务使用的有价值的产品

三个产品部分

离线开发

离线数据加工、发布、运维、数据分析、数据探索、在线查询、即席分析等

实时开发

数据实时接入和实时处理、简化流数据的加工处理过程

算法开发

提供简单易用的可视化拖曳方式和notebook方式

1.数据计算能力的4中类型

批计算

场景

批量数据的高延时处理

常见应用

离线数仓的加工

大规模数据清洗和挖掘

工具

map reduce

分而治之策略

设计原因导致处理性能慢

hive

spark

将数据抽象成RDD、Data Frame，一种分布式的内存抽象

在大型集群上执行基于内存的计算，减少迭代计算的开销

相对map reduce的优势

数据处理技术

有向无环图DAG执行计划

多个stage串联或并行

无须将stage中间结果输出到HDFS

数据格式和内存布局

RDD支持粗粒度写操作

RDD支持精确到每条记录的读操作

以上特型使RDD可以作为分布式索引

执行策略

map reduce 在shuffle前话费大量时间排序

spark支持基于hash的分布式聚合、调度采用DAG，每一轮输出结果都缓存在内存中

特点

吞吐量大、延时高、人机交互少

流计算

场景

对数据加工处理和应用有较强的时效性要求

流式ETL

集成数据通道和SQL加工，对流式数据实时清洗、归并、结构化等

补充和优化离线数仓

流式报表

实时采集加工流式数据、展现指标

监控预警

在线系统

常见应用

监控警告场景，有异常时可以及时介入

双11可视化数据大屏

工具

Flink

Spark Streaming

Storm

在线查询

对处理大规模数据；同时提供快速计算能力，如条件过滤、筛选等；支持高并发、低延迟

常见场景

画像服务

根据对象标签进行具体查询服务

使用redis提供低延迟、高并发

HBase供大规模查询

搜索

搜索引擎能力

模糊匹配、意图识别、快速检索等

圈人

用户分群

对时效性要求高的，如营销等

采集缓存型存储

redis、tair等

时效要求一般的

HBase、My SQL等

需要条件过滤、检索的

ES等

即席分析

主要用于分析型场景和经验统计，是面向大规模数据集快速进行多维交叉分析

企业80%的需求是在线查询和即席分析

工具

kylin、impala、click house、hawk

常见的实现方式

ROLAP

关系数据库核心，关系型结构进行多维数据表示和存储，结合星型模型和雪花模型

MOLAP

多维数据为核心，形成“立方块”结构

常见场景

交互式数据分析

群体对比分析

AB测试等

对比图

2.离线开发

封装数据加工、分析、在线查询、即席分析等能力，也包括任务调度、发布、运维、监控等

作业调度

作业依赖形成有向无环图

依赖调度

父作业完成后当前作业才开始运行

时间调度

到达指定时间才开始调度作业

依赖+时间调度

同时满足两个条件才开始作业

基线控制

提高数据加工效率、减少执行时间、预测任务时间、监控与警告

异构存储

离线开发中心根据不同的数据库开发出针对性的组件

用户新建各种类型的作业，执行时根据作业类型调用对应的插件来执行

代码校验

校验代码是为了尽量在执行前就找到问题，避免在执行中或结束后才发现问题，浪费资源，造成异常

语法校验

不同类型、不同版本你的SQL语法不同

规则校验

根据规则库提供的规则校验SQL，规则可以动态添加和扩展维护

多环境级联

单一环境

还有一个生产环境

经典环境

开发环境放脱敏数据，测试开发用

正式环境走流程

复杂环境

有外部人员时，提供给他们脱敏环境，内部检查过后走流程

依赖推荐

企业复杂度增加，依赖越来越复杂，难以找到合适的上游依赖

中台提供依赖推荐，帮助用户找到需要的上游作业，也保证不形成环路

原理

血缘图

环路检测

数据权限

不同的部分（引擎、组件等）有自己独立的权限管理系统，造成运维人员压力巨大

插件化思维实现不同系统之间的权限统一管理

3.实时开发

数据的业务价值随时间的流失会迅速降低

实时计算的三个特点

实时且无界的数据流

持续且高效的计算

事件触发计算

数据流即触发源，一有新数据进入，立刻计算

流式且实时的数据集成

计算结果持续的直接写入目的存储/报表展示

元数据管理

数据体系

考虑数据的一致性和可复用性

按照贴源数据、统一数仓、标签数据、应用数据的标准统一建设

贴源数据层建设

尽量保持数据的原始状态，同时经过简单的处理为后续工作提供准备

目标是把全域数据汇聚到数据中台

ETL与ELT的选择

大数据时代在抽取过程中进行清洗会消耗大量资源

存储成本降低，没有必要过度处理数据，反而会导致原始数据丢失

可以先装载保存，再进行处理

贴源数据三种类别

结构化数据，直接从业务系统数据库抽取

半结构化，通常是文本数据，日志等，抽取到贴源数据的同时做结构化处理，为后续使用做准备

非结构化数据，多媒体，一般保留在文件系统中，数据量庞大、价值密度低，通常不保留这些文件，而是这些文件的描述

贴源数据表设计

原则

尽量保持和业务系统一致，结构几乎不需要修改

设计规范

表名

前缀+系统业务表名

如：ODS_业务/系统名称_业务系统表名

字段名

与业务系统保持一致，ODS层不做字段命名归一

字段类型和业务系统尽可能保持一致

若数据中台没有与业务系统对应的数据类型则用一个可兼容的数据类型

增量同步

对于数据量大的业务数据，需要采用增量同步时，要同时建立增量表和全量表

增量表利用后缀进行标识

增量数据通过数据加工任务合并生成全量表

半结构化数据

存储原始数据

同时存储结构化处理后的数据

实现

统一数仓层建设

贴源数据是业务系统数据，这些数据是系统方便流程操作产生的，更贴近系统而非业务，不利用业务理解和数据分析

相关概念（以维度建模为基础）

特点

模型简单，只有维度、事实两种类型数据

性能好

可预测的标准框架

可以生成强大的假设条件

可扩展性好

可在不改变数据粒度的情况下新增维度，无需重新装载数据，不影响曾经的应用

数据冗余

新增维度时，需要进行预处理，通常会造成大量的数据冗余

如新增一个维度时，老数据因为当时没有采集这个维度的数据，需要定义一个值填进去

建设过程

业务板块

各个业务域

模型设计

基于维度建模构建一致性的维度和事实

设计一套表命名规范

数据域

数仓的顶层划分，根据业务进行抽象

一个数据域对应一个宏观业务领域的分析

不轻易变动，能涵盖其业务域内所有需求

新业务加入时可以无影响的分配到已有的数据域，当所有分类都不合适的时候才新建业务域

业务过程

企业经营活动中一种不可拆分的行为事件

下订单、转账、账号注册等

修饰词

除了统计维度外对指标进行限定抽象的业务场景词语

如日志中有修饰词 PC端、APP端

修饰词是为了方便理解和管理

原子指标

不可拆分，是对某一业务事件行为的度量，有明确的业务含义

有明确的字段名、数据类型、算法说明、数据域和业务过程

一般采用“动作+度量”的方式命名，如支付金额、注册用户数

派生指标

对原子指标业务统计范围的圈定

派生指标=一个原子指标+多个修饰词+时间修饰词

如：最近1天北京买家支付总金额

计算方法

数学计算方式

汇总、平均、最值等

维度表

维度是观察事物的角度

提供某一业务过程中涉及到的用于过滤和分类事实的描述性属性

维度表是统一设计的，在使用时可以在公共维度表中获取相关维度属性

事实表

是业务过程的度量,通常以数量值表示

如一次会员开通行为,16块钱月卡费就是事实

事实表不跨越数据域

明细事实表

保存原子数据,通常每个事物记录一条

增量更新,数据插入就不再更改

汇总事实表

明细事实聚合形成

以有规律性、可预见的时间间隔来记录事实周期快照

或以不确定的周期记录事实的累计快照

粒度

用于确定事实表中的一行具体代表什么

每个维度和事实都必须和定义的粒度保持一致

原子粒度的事实必须保留

一致性指标定义

指标归属到具体数据域

确保全局一致性

数据域划分

阶段一：数据调研

业务调研

摸清业务涵盖的领域和业务线

业务线细分的业务模块、业务模块具体流程

业务流程、业务边界、专业数据

数据调研

调研全部数据目录信息

梳理数据流和业务过程的关联关系

阶段二：业务分类

业务过程提取

抽取全部业务过程

业务过程分类

将特征相似的业务过程分为一类

每个业务只能归属一个类别

业务过程拆分

将业务过程拆解为一个个不可分割的行为事件

如下单、支付、收货、退款

阶段三：数据域定义

根据业务分类规律，总结出数据域定义

数据域专属命名，附上英文全称和简称

阶段四：总线矩阵构建

定义二维矩阵，记录数据域下的业务过程与维度信息

指标设计

核心是一致性

描述原子指标、修饰词、时间周期和派生指标的含义、类型、命名、算法等，是建模的基础

派生指标的生成

维度表设计

是维度建模的基础，直接决定了模型的好坏

设计的核心是确定维度属性，用于设置查询约束条件、分组、标签生成等

内容

每个维度表有单一的主键列

维度表包含了事实表所记录的业务过程的上下文和环境，除了5W还包含很多属性描述字段

特点

通常有多个属性，比较宽，是扁平型非规范表

有大量细粒度文本属性

应尽量包括一些有意义的文字描述，方便下游使用

维度尽量丰富，减少后续使用关联

设计方法

选择维度

在企业级数仓中保证维度的唯一性

通常在业务报表、业务人员需求中寻找需要的维度

确定主维表

通常直接从业务系统同步过来

是分析时最基础、最频繁的维度属性集合

梳理关联维表

寻找统一业务或不同业务系统中表间的关联性，选择其生成关联维度

定义维度属性

尽量生成更丰富、通用的维度属性

维护和描述纬度属性与层次关联关系

事实表设计

数仓的主要产物

主键+外键+事实度量

kimball维度建模理论

事务事实表

描述业务事实，一条记录一个事件

增量更新，记录后不再修改

粒度较细，支持详细地分析

周期快照事实表

以规律性、可预见的时间间隔内的聚集事实值或状态度量，产生快照

周期结束后才会产生一行新的记录，不再更改，增量更新

粒度较粗，维度较少

是事实加工之后产生的新事实，一般事实会比事务事实表多

累计快照事实表

覆盖一个事务的整个生命周期的所有关键事件

通常有多个日期字段来记录关键事件时间点

通常使用全量刷新的方式更新数据

常用于追踪某个业务的生命周期及其状态转换

事实表的设计步骤

确定业务过程

确定事实要表达的是什么业务过程

如注册、登录、下单等，每个事实都对应一个事实表

定义粒度

一个事实表的粒度是唯一的，是事实的细节级别

粒度与主键同样重要，粒度是从业务角度出发的，主键是从技术角度出发的

确定维度

业务人员会从哪些角度来描述一个业务

确定事实

是业务过程产生的事实度量的计算结果

需满足粒度定义

冗余维度属性

超大量级的表，进行关联，是灾难级的计算量，适当冗余使其可以完成绝大部分业务需求，减少关联

冗余带来计算便利的同时，也可能降低模型的稳定性，当冗余的属性发生变化时，真实维度和当时记录的就会不一致

模型落地

按照命名规范创建维表和事实表

开发生成表的数据的逻辑代码

代码逻辑测试

代码发布，质量监控与报警

运维

标签数据层建设

概述

面向对象建模，将跨业务、数据域的对象数据在同一个力度基础上组织起来关联到对象上

标签类别

属性标签

对象自身属性

统计标签

业务中的原子指标+修饰词+计算，生成统计标签

算法标签

对象在多个业务过程的中的表现，通过某种算法计算出的规律性特征

对象标签表

无论维度还是事实，一切都是标签

标签表的设计过程

一些概念

对象

对象标识

各种id等

标签

利用原始数据加工产生、易于业务理解和使用的数据

标签类目

标签的分类方式

用于管理和查找标签

通常采用多级类目

确定对象

描述现实世界的三大类对象：人、物、关系

人

具有主动性，常是关系的发出者

物

被动，常事关系的接受者

具有智慧的“物”如人工智能，也会归到“人”一类

关系

一种虚拟对象，是实体对象之间的联系

事实关系

产生可量化的事实度量

归属关系

只是一种归属属性

对象ID打通

解决同一个体在不同业务中标识ID不同的情况

通常采用设置超级ID的方式来打通

ID打通的前提是必须有ID与其他ID之间的两两映射关系，否则完全孤立的ID无法进行打通

对于个体数量庞大、业务种类多的情况，打通ID计算量极大，通常使用ID-Mapping技术，用算法替代野蛮计算

算法打通的对象具有一定误差，使用时要考虑置信度

标签类目设计

图书管理学方法，建立多级目录体系

根目录

人、物、关系

分类原则

尽量按照对数据的理解、使用、价值等业务角度去理解，对非技术人员更友好

标签体系的核心就是标签类目的设计，类目设计完成后填入标签即可

标签设计

前提条件

必须是对业务有价值的

必须是具有数据可行性的（有数可算）

概念区分

标签根目录

是标签所属于的对象，常是模糊、宽泛的名词或动词，如会员、酒店、报修

物理层面对应于某张大宽表中的主键

标签类目

对对象的拆分、对象的角度、层面或过程，如社交关系、从属关系等

物理层面对应某张表，多张这样的表按主键关联就组成主键对象的大宽表

标签

对象具体某个属性、信息

物理层面对应表中某个字段

标签值

对象具体某个属性、信息的具体取值，如男女、白领

物理层面对应具体某个字段值字典

多挂问题

一个标签归类在多个类目下，称为多挂

多挂会导致冗余问题，有时也可以便于业务理解，视情况选择是否要多挂

多挂通常是个别现象，大量有多属性的标签最好新建一个类目

标签设计内容

偏技术

表名、字段名、负责人、完成时间等

偏业务

标签类目、标签名、标签加工类型、标签逻辑、值字典、取值类型、示例、更新周期、安全等级，等

注意事项

标签是一个独立的字段，不存在互相依赖才能生效的“组合标签”，每个具体对象某标签的标签值，只能有一个

人、物、关系这三种对象的标签，有些可以互相转化，如“身份证号”是身份证（物）的标签，“拥有的身份证号”才是人的标签

标签融合表设计

标签融合表中，维度=标签

通常有纵表和横标两种组织方式

纵表模型稳定（无需增加列），但不容易理解，且性能差（新增一个维度/标签时，要新增大量的记录/行）

横标模型不稳定（经常增加列）但可以用技术手段克服，二维模型容易理解，性能好，增加新维度时无需增加行数

标签数量巨大，通常使用多张表来存储，表与标签类目对应，尽量把同类目信息挂载在同一张表中

考虑多个表之间的均衡性，避免某些表中标签太多，某些太少，对于标签太多的，往下一级类目去建表，对于太少的，考虑是否往上一级

应用数据层建设

数仓层和标签层不够灵活，无法满足各种不同的需求

应用层类似数据集市，更轻量化、灵活，专注于解决特定的业务问题

数据集市会为某个特定的业务独立构建

应用数据表设计

尽可能复用数仓层和标签层，面向特定需求徐准个性数据组装

强业务驱动，需要业务专家、业务开发、数据工程师共同设计

数据层的三种使用场景结构

多维的即席分析

减少连接，使用大宽表组织

特定指标查询

使用k-v组织

考虑具体查询场景，是否支持模糊查询等，确定合适的数据结构

一次查询多种信息

其他复杂数据结构

应用数据表实现

明确业务使用数据的要求

使用方式

性能（响应速度、吞吐量、时效等）

若数仓层和标签层有现成的数据，直接用，否则进行个性化加工

组装

场景化支撑

交叉分析和指标查询

毫秒级响应、高吞吐

离线分布式计算无法满足，需要同步一份数据到满足的环境介质中

略

数据资产管理

定义

数据资产

企业拥有或控制的

必须能带来未来经济效益

存在形式是物理或电子方式记录下来的数据

资产管理在中台中的位置

数据开发 → 数据资产管理 → 数据应用

面临的挑战

数据资源散落在多个业务系统中，缺乏宏观的统一视图，难以管理，难以产生统一价值

数据基础薄弱：标准混乱，质量参差不齐、孤岛化严重

应用不足，研究深度不足

数据价值难以估计

数据到底起到了哪些价值？

两个原因

没有合理的数据价值评估模型

企业的商业模式是否能很好的利用数据

没有合理的数据价值评估模型

企业的商业模式是否能很好的利用数据

数据到底起到了哪些价值？

缺乏安全的数据环境

数据管理浮于表面

没有一套数据驱动的组织管理制度和流程

没有先进的数据管理平台工具

四个目标

可见

数据资产目录的方式观想数据

用户可以快速、精准的查找自己关心的数据资产

可懂

组织一套人人可懂的、无歧义的对数据的描述

对数据资产进行标签化

可用

提升数据质量，让使用数据的用户放心使用，减少数据不可用、不可信带来的沟通成本

可运营

建立一套符合数据驱动的组织管理制度流程和价值评估体系

数据治理

没有得到良好治理的数据，不是可靠的，无法很好地使用，无法发挥价值

治理的六个目标

高质量的数据

统一、可执行的数据标准

良好的响应需求，保护数据安全

组织内统一采用共同的解决数据问题的办法

建立可重复的数据管理流程，确保流程透明

数据的可持续运营、数据资产增值

治理的原则

标准化、可参考、可落地

方案公开、责任明确

相关文件、问题的发现，应公开透明，相关人员应及时清楚正在发生的事情、事后的处理原则

平衡

在考虑数据的“可商用性”情况下，在数据治理成本和收益之间取得平衡

没必要追求百分之百的数据准确度

跟随业务发展持续变更成长

理论体系

DMM、DAMA、DCMM等

DCMM体系更符合中国数据治理现状

数据管理成熟度的五个等级

无统一流程,被动式管理

企业认识到数据是资产,战略性制定了管理流程,指定人员进行管理

数据成为帮助组织实现绩效的重要资产,制定了系列标准化流程

认为数据是获取竞争优势的重要资源,数据管理的效率可以量化和分析

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

数据治理发展的三个趋势

曾经的数据治理更多是为了保证数据质量,如今要求更多的提供服务,挖掘数据的价值

人工智能大幅提升数据治理效率

以元数据为核心的分布式数据治理

数据资产管理与数据治理的关系

数据资产管理在数据治理的基础上加入了数据价值管理和数据共享管理等

数据服务体系

中台的核心价值所在,中台无法提供太多服务，而应该提供快速生成和管理服务的能力

补全数据应用的最后一公里'

定义与定位

数据服务是对计算逻辑的封装,生成API服务

数据服务的主要分类

基础数据服务

面向物理表

面向数据查询、多维分析等场景

自定义SQL实现对物理表数据的获取和分析

标签画像服务

面向标签数据

标签圈人、画像分析等

通过界面配置方式实现数据使用

算法模型服务

面向算法模型

智能营销、个性化推荐等

通过界面配置方式将算法模型部署为在线APi

核心价值

数据的全域流通和成长

减少数据接口重复建设

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

使数据能力持续扩展

4种常见的数据服务

查询

典型特征

支持配置查询标识

要看哪些字段

支持配置过滤项

如何筛选

支持查询结果配置

排序、分页等

构建过程

数据接入

数据查询

通过传参或图形化界面配置查询

结果规则配置

排序、分页等

能力开放

查询组件生成一个服务API，供上层调用

分析

典型特征

支持多数据源接入

高性能即席查询

多维度数据分析

灵活对接业务系统

接口形式输出

允许用户自定义接口构建

提供包括接口URL、后端服务类型、接口请求模式等

构建过程

数据接入

在线建模

本质是构建SQL，把用户分析条件转化为SQL

提供SQL代码编辑器或者图形化界面

能力开发

API对外开放