《数据中台让数据用起来》读书笔记
2020-07-03 11:51:07 7 举报AI智能生成
登录查看完整内容
系统讲解数据中台建设、管理与运作的著作。由业界领先的数澜科技官方出品，大部分作者来自原阿里巴巴数据中台团队，结合百家头部企业数据中台经验，总结一套可落地的数据中台方案
作者其他创作
大纲/内容
数据中台
架构
目标
让数据持续流动和使用起来
把数据转变为资产
数据汇聚
理解
首要目标是打破数据孤岛
是数据接入的入口，目的是把分散在各处的数据进行采集和存储，得到一堆未处理或简单处理的原始数据
类型（时效性角度）
离线批量汇聚
实时采集
常见的具体方式
数据库同步
如同步服务端计算使用的数据时
埋点
如需要前端的交互数据时
网络爬虫
如需要抓取网络信息时
消息队列
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天北京买家支付总金额
计算方法
数学计算方式
汇总、平均、最值等
维度表
维度是观察事物的角度
提供某一业务过程中涉及到的用于过滤和分类事实的描述性属性
维度表是统一设计的，在使用时可以在公共维度表中获取相关维度属性
事实表
事实表不跨越数据域
明细事实表
汇总事实表
明细事实聚合形成
以有规律性、可预见的时间间隔来记录事实周期快照
或以不确定的周期记录事实的累计快照
粒度
用于确定事实表中的一行具体代表什么
每个维度和事实都必须和定义的粒度保持一致
原子粒度的事实必须保留
一致性指标定义
指标归属到具体数据域
确保全局一致性
数据域划分
阶段一：数据调研
业务调研
摸清业务涵盖的领域和业务线
业务线细分的业务模块、业务模块具体流程
业务流程、业务边界、专业数据
数据调研
调研全部数据目录信息
梳理数据流和业务过程的关联关系
阶段二：业务分类
业务过程提取
抽取全部业务过程
业务过程分类
将特征相似的业务过程分为一类
每个业务只能归属一个类别
业务过程拆分
将业务过程拆解为一个个不可分割的行为事件
如下单、支付、收货、退款
阶段三：数据域定义
根据业务分类规律，总结出数据域定义
数据域专属命名，附上英文全称和简称
阶段四：总线矩阵构建
定义二维矩阵，记录数据域下的业务过程与维度信息
指标设计
核心是一致性
描述原子指标、修饰词、时间周期和派生指标的含义、类型、命名、算法等，是建模的基础
派生指标的生成
维度表设计
是维度建模的基础，直接决定了模型的好坏
设计的核心是确定维度属性，用于设置查询约束条件、分组、标签生成等
内容
每个维度表有单一的主键列
维度表包含了事实表所记录的业务过程的上下文和环境，除了5W还包含很多属性描述字段
通常有多个属性，比较宽，是扁平型非规范表
有大量细粒度文本属性
应尽量包括一些有意义的文字描述，方便下游使用
维度尽量丰富，减少后续使用关联
设计方法
选择维度
在企业级数仓中保证维度的唯一性
通常在业务报表、业务人员需求中寻找需要的维度
确定主维表
通常直接从业务系统同步过来
是分析时最基础、最频繁的维度属性集合
梳理关联维表
寻找统一业务或不同业务系统中表间的关联性，选择其生成关联维度
定义维度属性
尽量生成更丰富、通用的维度属性
维护和描述纬度属性与层次关联关系
事实表设计
数仓的主要产物
主键+外键+事实度量
kimball维度建模理论
事务事实表
描述业务事实，一条记录一个事件
增量更新，记录后不再修改
粒度较细，支持详细地分析
周期快照事实表
以规律性、可预见的时间间隔内的聚集事实值或状态度量，产生快照
周期结束后才会产生一行新的记录，不再更改，增量更新
粒度较粗，维度较少
是事实加工之后产生的新事实，一般事实会比事务事实表多
累计快照事实表
覆盖一个事务的整个生命周期的所有关键事件
通常有多个日期字段来记录关键事件时间点
通常使用全量刷新的方式更新数据
常用于追踪某个业务的生命周期及其状态转换
事实表的设计步骤
确定业务过程
确定事实要表达的是什么业务过程
如注册、登录、下单等，每个事实都对应一个事实表
定义粒度
一个事实表的粒度是唯一的，是事实的细节级别
粒度与主键同样重要，粒度是从业务角度出发的，主键是从技术角度出发的
确定维度
业务人员会从哪些角度来描述一个业务
确定事实
是业务过程产生的事实度量的计算结果
需满足粒度定义
冗余维度属性
超大量级的表，进行关联，是灾难级的计算量，适当冗余使其可以完成绝大部分业务需求，减少关联
冗余带来计算便利的同时，也可能降低模型的稳定性，当冗余的属性发生变化时，真实维度和当时记录的就会不一致
模型落地
按照命名规范创建维表和事实表
开发生成表的数据的逻辑代码
代码逻辑测试
代码发布，质量监控与报警
运维
标签数据层建设
概述
面向对象建模，将跨业务、数据域的对象数据在同一个力度基础上组织起来关联到对象上
标签类别
属性标签
对象自身属性
统计标签
业务中的原子指标+修饰词+计算，生成统计标签
算法标签
对象在多个业务过程的中的表现，通过某种算法计算出的规律性特征
对象标签表
无论维度还是事实，一切都是标签
标签表的设计过程
一些概念
对象
对象标识
各种id等
标签
利用原始数据加工产生、易于业务理解和使用的数据
标签类目
标签的分类方式
用于管理和查找标签
通常采用多级类目
确定对象
描述现实世界的三大类对象：人、物、关系
人
具有主动性，常是关系的发出者
物
被动，常事关系的接受者
具有智慧的“物”如人工智能，也会归到“人”一类
关系
一种虚拟对象，是实体对象之间的联系
事实关系
产生可量化的事实度量
归属关系
只是一种归属属性
对象ID打通
解决同一个体在不同业务中标识ID不同的情况
通常采用设置超级ID的方式来打通
ID打通的前提是必须有ID与其他ID之间的两两映射关系，否则完全孤立的ID无法进行打通
对于个体数量庞大、业务种类多的情况，打通ID计算量极大，通常使用ID-Mapping技术，用算法替代野蛮计算
算法打通的对象具有一定误差，使用时要考虑置信度
标签类目设计
图书管理学方法，建立多级目录体系
根目录
人、物、关系
分类原则
尽量按照对数据的理解、使用、价值等业务角度去理解，对非技术人员更友好
标签体系的核心就是标签类目的设计，类目设计完成后填入标签即可
标签设计
前提条件
必须是对业务有价值的
必须是具有数据可行性的（有数可算）
概念区分
标签根目录
是标签所属于的对象，常是模糊、宽泛的名词或动词，如会员、酒店、报修
物理层面对应于某张大宽表中的主键
对对象的拆分、对象的角度、层面或过程，如社交关系、从属关系等
物理层面对应某张表，多张这样的表按主键关联就组成主键对象的大宽表
对象具体某个属性、信息
物理层面对应表中某个字段
标签值
对象具体某个属性、信息的具体取值，如男女、白领
物理层面对应具体某个字段值字典
多挂问题
一个标签归类在多个类目下，称为多挂
多挂会导致冗余问题，有时也可以便于业务理解，视情况选择是否要多挂
多挂通常是个别现象，大量有多属性的标签最好新建一个类目
标签设计内容
偏技术
表名、字段名、负责人、完成时间等
偏业务
标签类目、标签名、标签加工类型、标签逻辑、值字典、取值类型、示例、更新周期、安全等级，等
注意事项
标签是一个独立的字段，不存在互相依赖才能生效的“组合标签”，每个具体对象某标签的标签值，只能有一个
人、物、关系这三种对象的标签，有些可以互相转化，如“身份证号”是身份证（物）的标签，“拥有的身份证号”才是人的标签
标签融合表设计
标签融合表中，维度=标签
通常有纵表和横标两种组织方式
纵表模型稳定（无需增加列），但不容易理解，且性能差（新增一个维度/标签时，要新增大量的记录/行）
横标模型不稳定（经常增加列）但可以用技术手段克服，二维模型容易理解，性能好，增加新维度时无需增加行数
标签数量巨大，通常使用多张表来存储，表与标签类目对应，尽量把同类目信息挂载在同一张表中
考虑多个表之间的均衡性，避免某些表中标签太多，某些太少，对于标签太多的，往下一级类目去建表，对于太少的，考虑是否往上一级
应用数据层建设
数仓层和标签层不够灵活，无法满足各种不同的需求
应用层类似数据集市，更轻量化、灵活，专注于解决特定的业务问题
数据集市会为某个特定的业务独立构建
应用数据表设计
尽可能复用数仓层和标签层，面向特定需求徐准个性数据组装
强业务驱动，需要业务专家、业务开发、数据工程师共同设计
数据层的三种使用场景结构
多维的即席分析
减少连接，使用大宽表组织
特定指标查询
使用k-v组织
考虑具体查询场景，是否支持模糊查询等，确定合适的数据结构
一次查询多种信息
其他复杂数据结构
应用数据表实现
明确业务使用数据的要求
使用方式
性能（响应速度、吞吐量、时效等）
若数仓层和标签层有现成的数据，直接用，否则进行个性化加工
组装
场景化支撑
交叉分析和指标查询
毫秒级响应、高吞吐
离线分布式计算无法满足，需要同步一份数据到满足的环境介质中
略
数据资产管理
数据资产
企业拥有或控制的
必须能带来未来经济效益
存在形式是物理或电子方式记录下来的数据
资产管理在中台中的位置
数据开发 → 数据资产管理 → 数据应用
面临的挑战
数据资源散落在多个业务系统中，缺乏宏观的统一视图，难以管理，难以产生统一价值
数据基础薄弱：标准混乱，质量参差不齐、孤岛化严重
应用不足，研究深度不足
数据价值难以估计
数据到底起到了哪些价值？
两个原因
没有合理的数据价值评估模型
企业的商业模式是否能很好的利用数据
缺乏安全的数据环境
数据管理浮于表面
没有一套数据驱动的组织管理制度和流程
没有先进的数据管理平台工具
四个目标
可见
数据资产目录的方式观想数据
用户可以快速、精准的查找自己关心的数据资产
可懂
组织一套人人可懂的、无歧义的对数据的描述
对数据资产进行标签化
可用
提升数据质量，让使用数据的用户放心使用，减少数据不可用、不可信带来的沟通成本
可运营
建立一套符合数据驱动的组织管理制度流程和价值评估体系
数据治理
没有得到良好治理的数据，不是可靠的，无法很好地使用，无法发挥价值
治理的六个目标
高质量的数据
统一、可执行的数据标准
良好的响应需求，保护数据安全
组织内统一采用共同的解决数据问题的办法
建立可重复的数据管理流程，确保流程透明
数据的可持续运营、数据资产增值
治理的原则
标准化、可参考、可落地
方案公开、责任明确
相关文件、问题的发现，应公开透明，相关人员应及时清楚正在发生的事情、事后的处理原则
平衡
在考虑数据的“可商用性”情况下，在数据治理成本和收益之间取得平衡
没必要追求百分之百的数据准确度
跟随业务发展持续变更成长
理论体系
DMM、DAMA、DCMM等
DCMM体系更符合中国数据治理现状
数据管理成熟度的五个等级
数据治理发展的三个趋势
人工智能大幅提升数据治理效率
以元数据为核心的分布式数据治理
数据资产管理与数据治理的关系
数据资产管理在数据治理的基础上加入了数据价值管理和数据共享管理等
数据服务体系
补全数据应用的最后一公里'
定义与定位
数据服务的主要分类
基础数据服务
面向物理表
面向数据查询、多维分析等场景
自定义SQL实现对物理表数据的获取和分析
标签画像服务
面向标签数据
标签圈人、画像分析等
通过界面配置方式实现数据使用
算法模型服务
面向算法模型
智能营销、个性化推荐等
通过界面配置方式将算法模型部署为在线APi
核心价值
数据的全域流通和成长
减少数据接口重复建设
保障数据获取的及时性和稳定高效
使数据能力持续扩展
4种常见的数据服务
查询
典型特征
支持配置查询标识
要看哪些字段
支持配置过滤项
如何筛选
支持查询结果配置
排序、分页等
构建过程
数据接入
数据查询
通过传参或图形化界面配置查询
结果规则配置
能力开放
查询组件生成一个服务API，供上层调用
分析
支持多数据源接入
高性能即席查询
多维度数据分析
灵活对接业务系统
接口形式输出
允许用户自定义接口构建
提供包括接口URL、后端服务类型、接口请求模式等
在线建模
本质是构建SQL，把用户分析条件转化为SQL
提供SQL代码编辑器或者图形化界面
能力开发
API对外开放
推荐
支持跨行业分析推荐
对不同行业的计算模型不同
支持跨场景分析推荐
能够覆盖用户的使用场景
支持推荐效果优化
推荐模型可以不断自我优化
选择行业和场景模板
不同行业和场景对应的推荐模型不同
现弄清楚想推荐什么，达到什么目的
原始数据接入
用户数据
物品数据
内容、信息、商品等
关系数据
参数配置
便捷测配置推荐模型的模型结构、样本指向、目标设定、输入输出格式等
模型在设定好的参数下自动化训练运行，直至模型稳定下来，产出腿甲那结果或稳定的模型
API
事实计算或离线计算，将推荐数据输出返回到上层应用系统中
数据回流
产生的推荐数据效果回流到推荐模型，用于修正模型
圈人服务
支持人群圈选，是你用SQL代码或标签等方式查找人群
支持人群计量
算一下符合条件的人群有多少
太多了就缩进，太少了就放宽条件
支持多渠道对接
人群的名单可以实现自动化对接（到其他系统）
文件、数据库、API等多种方式导入数据
人群圈选
提供SQL编辑器或图形化界面实现人群的圈选
API输出
提供人群名单
提供人群特征
3种常见的数据应用
数据大屏
把统计性数据通过可视化框架（web GL、D3等）渲染出来呈现给用户
公关大屏展示
数据监控，可简单交互
建设
数据服务，封装加工成API
API配置在可视化套件中，生成可视化大屏
数据报表
使用分析服务接口，重在图形化展示各种指标
主要是决策者和分析人员使用
三种分析的内容
统计报表
提供灵活、可自定义的表格和图表的功能
数据分析
假设检验、显著性检验、相关分析、距离分析、回归分析、聚类分析、因子分析、主成分分析、关联分析等
数据挖掘
分类、估计、预测、相关性分组或关联规则、聚类、复杂数据类型挖掘等
智能应用
不同的场景内容与功能不同
个性化推荐
根据数据源分为三类
基于人口统计学的推荐
通过用户的基本信息发现用户的相关度
基于内容的推荐
根据物品或内容的元数据，发现物品或内容的相关性
协同过滤的推荐
根据用户对物品或内容的偏好，发现物品或内容自建的相关性，或发现用户的相关性
个性化推荐的原理
前提是累计了大量用户对目标物的行为记录（浏览、搜索、查询等）
在基础数据上增加时间衰减、广泛热度、突变因子等因素的权重
通过推荐模型训练运算，得到推荐结果
过程
业务系统从交互界面得到用户的信息（基础信息+实时行为表现）， 传递到推荐服务
推荐服务根据收到的数据调用算法，试试计算推荐结果，通过输出接口传给业务系统
精准营销应用
将营销信息或产品精准的推送给目标受众的营销方式
按推荐内容分为两类
营销文案或广告等信息
产品本身（如新闻）
推送效果必须是双向的
推送的内容只被目标用户看到
用户需要的正是推送的内容本身
按渠道形式分类
广告系统中的精准营销
传统方式买断优质流量，造成浪费（再优质的粗糙流量里也有部分低质流量）
DMP系统
广告商根据产品特征及目标客户画像制定精准营销计划
DMP系统中圈选人群自动对接到DSP系统进行实时竞价投放
营销活动系统中的精准营销
设施基础是建立产品与用户标签体系，形成产品画像和用户画像
根据人群、内容、环境、载体等多维度制定营销计划
数据服务背后的产品技术
多样数据服务
标签服务化
面向业务人员（无需技术基础）
用户可以方便快速的选取标签
自定义SQL服务化
面向有一定SQL能力的人员
在需要对接数据源时，使用SQL取得需要的数据
算法模型服务化
面向业务技术人员
通过步数算法模型，输出模型服务
注册API服务化
支持企业将已有的API注册到数据服务统一管理和输出
形成企业的统一服务出口、统一托管API，形成服务中心
生命周期管理
管理API的新建、维护、上下线、授权、监控等，降低日常维护成本
五个阶段
服务的创建部署
首先明确服务的应用场景、解决的问题，来确定要使用的服务组件（技术选型）
选型后考虑服务部署的环境
本地机房
云服务器
远程Docker仓库环境
服务的授权
除了创建者，其他用户均需授权才能访问
服务的运行监控
自动化的运维监控机制保障服务状态正常
服务的更新升级
服务的到期停服下架
服务安全控制
稳定性
扩容、容错等
鉴权
对API和授权应用进行鉴权，识别请求者身份
常用的鉴权机制：AK鉴权、Acess Token、JWT
黑白名单
控制服务调用权限
申请审批
经过授权或申请审批通过的API才能被应用使用
多版本管理
审计与计量计费
数据中台运营机制
运营的目标
数据安全和质量是中台可持续运营的基础
降本生效是打造中台影响力的关键
运营的4个价值切入点
统一战略
管理层对数据中台的建设有清晰的认知，坚定的决心
全体员工明白数据中台的重要性
自上而下，必须由最上层牵头来做，共同负责
搭建组织
人员
常规的数据分析师、数据产品
数据运营专家
数据架构师
组织
数据委员会
指定数据建设战略方向，授权职能部门落地执行
虚拟数据团队
各部门数据团队核心人员，数据数据建模理论，发开经验丰富
执行团队
统一开发标准规范，全面测试
打造氛围
数据大屏就是一种常见的用于打造氛围的工具，所有员工都能轻松看到，逐渐形成数据影响力
实践创新
让各业务部门形成争用数据资源的态势
一些方式
奖励重视数据的部门
让各业务部门和数据部门进行共创，发现业务和数据的结合点
数据资产运营的4个目标
可阅读
存在数据库中的数据无法让业务人员轻易理解，长此以往会使他们丧失对数据的兴趣
通过技术人员去取数，时效性差，或偏离业务人员的本意
当业务变复杂时，技术资源不足以应付各种灵活的需求
易理解
仅靠一个表、字段名和简单注释，业务人员无法得知字段生产加工逻辑、血缘、有效性等，无法判断是否是业务可用的
没有良好组织信息的数据，不足以成为数据资产，需要面向业务进行标签化才能成为资产
以年龄（age）标签为例
描述
注册身份证信息获得的年龄信息
计算逻辑
身份证7~10位抽取出生年份，进行年龄计算
取值类型
数值型
值字典
来源表字段信息
用户覆盖量
历史调用量、调用方
价值分、质量分
好使用
传统方式
业务人员告诉开发人员使用的字段，开发人员编写数据服务接口，对接业务或数据应用系统，供业务人员使用数据
将数据使用方法进行抽象，供业务部门理解后直接配置使用
解决了业务人员难以准确描述需求的问题
缩短了从0开始编程的过程
可以通过修改配置参数的方式快速变更，降低试错成本
有价值
数据资产运营要围绕资产的价值进行
记录数据资产使用的情况
调用情况
如通过调用量反映资产的重要程度
使用数据带来的效果
AB测
使用了数据资产的部门和没有使用的部门的业绩差别
业务部门访谈
评估资产的价值
通过量化分析，数据服务带来的业务增长，这部分增长即是数据服务带来的收益
数据资产运营的完整链路
看
提供一个资产门户或资产管理场所，给数据消费方提供数据资产的基本信息，方便其选择和使用
选
传统方式：用文档方式记录和提报选用的数据资产
进阶方式：生成数据申请信息流确认所所需数据信息
高端操作：用户通过资产管理系统将所需资产加入购物车或收藏夹，放入意向资产库，方便业务人员反复查看研究
用
通过生成服务接口或数据应用产品来使用
治
面向业务层的标签治理
新表现设计、标签上下架管理、标签类目管理、标签血缘分析、圆标签标准、标签质量评估、标签使用安全
面向存储层的数据治理
数据表/字段的生命周期管理、血缘分析、元数据标准、数据质量评估、数据安全方案
评
评估角度
质量、成本、故障、使用等
调用次数与频率
业务人员的反馈评价
意义
让数据消费者更加全面理解数据资产的质量、应用价值和风险，形成有效闭环
数据资产运营的5个动作
组织登记
掌握现有数据
大规模企业设计跨部门、跨业务、跨系统、跨项目的情况，数据库、表权限要求不同，数据收集工作很困难
收集完成后盘点哪些资产是可用的
收集业务需求
优先根据主流的、核心的业务需求，将数据资产对象登记上架
要理解一线业务人员描述的内容、掌握业务生产经营活动的详细流程，才能做到准确的录入资产、生产标签
由于十分了解生产经营流程，要比业务人员更有数据前瞻性，想到将来有哪些也会用到，提前登记
信息登记上架
数据资产是一种商品，只有被用起来才有价值
数据资产管理工具要支持资产的上架、使用审批、使用、评价等功能，提供给业务人员看、选、用、评的能力，持续治理
当某资产长时间使用量为零或相关业务撤销时，通知正在使用、曾经使用或关注该数据资产的业务人员，即将下架，停止对该资产的计算、存储、读取的支持
宣传推广
业务人员对数据的处理能力大概率是弱的，对数据的价值是认知不足的，数据资产运营人员需要融入一些营销手段才能让数据被更好更多的利用起来
可以安排业务人员定期出报告，观察在使用数据标签后对业务是否有帮助
或监控标签的调用情况、使用频率，观察业务是否对标签产生依赖，也能体现标签的价值
服务保障
搭建出一个可看、可控、可追溯、可预警的服务保障平台
确保调用数据服务的上层应用都是经过审核授权的，避免数据资产泄露
保障服务调用的性能
如响应时间、QPS、处理数据体量等会决定计算引擎的选型
配合负载优化、分流控制等机制来避免调用激增、恶意攻击
通过流量控制进行流量倾斜，向头部倾斜更多的流量，优先保障头部的稳定
完整的监控体系，发现异常及时发送警告
治理优化
运营人员记录使用过程中的问题，人工修正或下发治理任务，不断迭代
部分资产治理工作可以由运营人员自己完成
元标签信息不够完备、有错误、不标准
某些资产具体取值存在错误，需要人工审核
新增或修改资产类目结构
定期关注使用中的资产的价值情况和占用的资源成本，及时清理长期不用、过失、性价比低的资产，沉淀出有价值的资产进行优化
价值评估
根据资产使用情况判定
判断维度
使用准确率
关注度
调用量
可用率
故障率
持续优化度
持续实用度
成本与性价比
。。。
制作数据资产价值看板或BI报表给管理层阅览
数据资产质量评估
源头数据质量
安全性
元数据是否合法取得、是否有用户许可等
准确性
数据的生产方式：第一现场取得(如ip）、间接获取（如调用其他服务获取的数据）、边缘推算（设备侧进行的加工计算）
生产周期、生产时段、生产数据量、数据格式、数据取值等的稳定性
从第一现场产生到传输录入的时间间隔
时效性会间接影响标签准确度，如行为类数据对推荐算法的影响
全面性
是否支持各个层面数据打通、进行痊愈计算
（标签）加工过程质量
准确率
建模和测试过程中得到的准确率，是类似实验性质的初始准确率，供参考用
标签每天加工产出的时间是否准时
标签生产耗费的时间，越短时效性越强
覆盖量
具有某标签的标签值的对象个体数量
如性别信息，只有56%的用户登记了
完善度
标签的元数据是否完善，是否能说清楚标签的情况，让其可选可用
规范性
标签元数据是否规范
离散度
标签取值的分布情况，离散程度因场景而异
一般场景下离散度越大越好，说明人群在该标签属性下均匀分布与不同特征值
使用价值质量
通过业务场景实际使用验证出的标签准确率
受众热度
被多少业务部门、业务场景、业务人员申请使用
反映标签的适用性和泛化能力
被调用的成功次数/调用总次数
故障时长在总服务时长中的占比
关注热度
标签在标签市集被搜索、浏览、收藏、咨询、讨论等方面的热度
是否处于持续迭代优化的过程
平均持续调用情况
成本性价比
加工标签投入的数据源生产、传输、计算、存储成本，为业务带来的价值
0 条评论
回复 删除
下一页
