《网易-数据中台》学习笔记

1. 大数据发展历程

1.1 数据仓库

背景：20 世纪 90 年代企业开始集成数据围绕主题做**决策分析**

数据仓库定义：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合

实现：数据按照主题划分为主题域，主题域作为数据仓库的目录

1.2 Hadoop - 数据湖

背景：21 世纪互联网时代互联网产品产生**海量数据和异构数据**，数据仓库无法应对

数据湖定义：数据湖是一个以原始格式存储数据的存储库或系统

Hadoop 相比传统数据仓库的优势：

• 分布式、易于拓展、成本低
• 弱化数据格式

1.3 大数据平台

背景：数据需求开发**流程复杂**

大数据平台定义：大数据平台是面向数据研发场景的，覆盖数据研发的完整链路的数据工作台

实现：

• HDFS、Kudu、HBase 实现数据存储
• Yarn、Kubernetes 实现 资源调度
• Hive、Spark、Impala、Flink 实现数据处理

1.4 数据中台

背景：2016 年前后大规模数据的需求开发导致**数据冗余和指标冲突**

OneData 定义：统一定义、标准建模、规范研发、工具保障

数据中台与数据仓库、数据湖和大数据平台的关系：

• 数据中台借鉴了传统数据仓库面向主题域的数据组织模式，基于维度建模的理论，构建统一的数据公共层
• 数据中台构建于数据湖之上，具有数据湖异构数据统一计算、存储的能力，同时让数据湖中杂乱的数据通过规范化的方式管理起来
• 数据中台依赖大数据平台，大数据平台完成了数据研发的全流程覆盖，数据中台增加了数据治理和数据服务化的内容

1.5 Next：大数据 + 人工智能

猜想：人工智能利用大数据辅助决策分析和价值挖掘

2. 数据仓库

2.1 数据仓库建模

数据仓库建模方法论可分为：E-R模型、维度模型、Data Vault模型、Anchor模型。

2.1.1 E-R 模型

E-R 实体关系模型：自顶向下，将事物抽象为实体、关系来描述事物和事物之间的关联，是面向主题的抽象，具有良好的稳定性和一致性，但是难以处理当前复杂多变的业务需求，只用于 ODS 和 DWD 层。

E-R 建模步骤：

1. 高层模型：一个高度抽象的模型，描述主题与主题之间的关系，用于描述企业的业务总体概况

2. 中层模型：在高层模型的基础上，细化主题的数据项

3. 底层模型（物理模型）：在中层模型的基础上，考虑物理存储，同时基于性能和平台的特点进行物理属性的设计，也可能做一些表的合并、分区的设计

2.1.2 维度模型

维度模型：自底向上，重点解决如何快速完成需求的问题，能够解决复杂多变的业务需求，存在数据冗余的问题。

建模步骤：

1. 选择需要决策分析的业务过程：业务过程可以是单个业务事件、某个事件的状态，也可以是一系列相关的业务流程

2. 选择粒度：在需求分析中，我们要预判分析需要的细分程度，从而决定选择的粒度。粒度是维度的一个组合。

3. 选择维表：选择粒度后，就需要基于粒度设计维表，包括维度属性，用于分析时进行分组和筛选

4. 选择事实：确定分析需求衡量的指标

事实表根据粒度的角色不同可分为 事务事实表、周期快照事实表 和 累计快照事实表

• 事务事实表：用于保存事务数据，任何事件都可以被理解为一种事务
• 周期快照事实表：快照表以预定的时间间隔采样状态度量
• 累计快照事实表：用于记录具有时间跨度的整个业务处理过程的信息

补充：维度建模技术实践——深入事实表

3. 数据中台

3.1 概述

3.1.1 面对的挑战

• 指标口径不一致：业务口径不一致、计算逻辑不一致、数据来源不一致
• 数据重复建设：烟囱式开发方式（孤岛系统）导致重复逻辑代码的开发
• 取数效率低：找不到数据和取不到数据
• 数据质量差：数据加工链路长，数据问题很难发现
• 数据成本线性增长：数据成本线性随需求增长而线性增长，本质上是数据重复建设的问题

3.1.2 解决方案

• 指标口径不一致：业务口径相同、只加工一次、数据来源必须相同
  • 业务口径相同：一个团队统一负责指标口径的管控，建设指标系统提高管理效率，所有的数据产品、报表引用指标系统的口径定义
  • 只加工一次：即将相同粒度的度量或指标的构建全局一致的公共维表，需要数仓设计中心和数据地图。数仓设计中心用于在模型设计阶段强制聚合相同粒度度量、指标的模型，数据地图方便开发快速理解一张表的含义
  • 数据来源相同：对不同数据来源的数据根据指标和维度进行整合，数仓的数据通过 API 接口的方式提供给数据应用
• 数据重复建设：解决数据复用，相同的数据只加工一次，实现数据共享
• 取数效率低：实现数据资产目录，实现数据地图和可视化查询平台
• 数据质量差：数据问题及时发现和快速恢复，数据链路全流程监控

3.1.3 利与弊

利：实现高效率、高质量、低成本建设数据产品，核心是降低成本

弊：数据中台本身不产生收益，价值体现依托数据产品，而构建数据中台需要大量投入

3.1.3 总结

数据只加工一次是建设数据中台的核心，本质是实现公共计算逻辑的下沉和复用

3.2 方法论、支撑技术和组织架构

3.2.1 方法论：OneData 和 OneService

OneData：

• 主题域管理：将数量众多的表划分到不同的主题域，要保证主题域劲量稳定，能覆盖绝大多数表

• 命名规范定义：表名最好包含表的主题域、业务过程，分层和分区信息，同时命名过程中必须采用统一的缩写，例如仓储域下的一张入库明细表

  dwd_wms_inbound_item_info_di
  明细层_仓储域_入库_基础信息_每日增量
  分层_主题域_业务过程_内容_分区规则
  

• 指标一致：构建全局的指标字典

• 数据模型复用：采用分层设计实现模型的复用，数据中台的数据必须尽可能覆盖所有业务过程

• 数据完善

OneData 体系的目的是构建统一的数据规范标准，让数据成为一种资产（可沉淀、可复用），而不是一种成本（消耗的，不可复用的）

OneService：

• 屏蔽异构数据源：数据服务必须支撑类型丰富的查询引擎，满足不同场景下的查询需求
  • MySQL：数据量小
  • HBase：数据量大（超过 500 万行）
  • Greenplum：多维分析
  • Redis：实时性要求高
• 数据网关：实现权限、监控、流控、日志等一系列管控能力
• 逻辑模型：屏蔽底层的数据物理实现，实现相同粒度的数据构造一个逻辑模型，简化数据接入复杂度
• 性能与稳定性：数据服务必须是无状态，可横向拓展的

OneService 体系的目的是提高数据的共享能力，让数据使用方便、安全

3.2.2 支撑技术

• 大数据基础设施：Hadoop 提供大数据运行所必须的计算、存储资源
• 大数据平台：
  • HDFS：分布式文件系统
  • Yarn/Kubernates：资源调度系统
  • Hive、Spark、Fink：分布式计算引擎
• 数据治理：以元数据为中心，在统一所有数据源的元数据的基础上，提供以下 5 个产品
  • 数据地图：数据发现
  • 指标管理
  • 数仓设计：模型
  • 数据质量
  • 成本优化
• 数据服务
• 数据应用

3.2.3 组织架构

• 数据产品部：负责数据中台、数据产品的体系规划、产品设计、规范制定、应用效果跟进，指标口径的定义和维护
• 数据平台部：负责研发支撑数据中台构建的产品，如指标系统、元数据中心、数据地图等
• 数据开发团队：负责维护数据中台的公共数据层，满足数据产品制定的数据需求
• 应用开发团队：负责开发数据应用产品，如报表系统、经营分析

数据中台必须是独立于业务线的部门，但又必须深入业务、懂业务，组织绩效必须与业务绑定

3.3 元数据中心

3.3.1 元数据

元数据：数据的基本信息，便于理解业务口径、计算逻辑和数据来源

• 数据字典：描述数据的结构信息 ，比如表名、表注释、表产出任务、表字段、字段注释、字段类型等
• 数据血缘：描述一个表是直接通过哪些表加工而来，用于做影响分析和故障溯源
• 数据特征：数据的属性信息，比如存储空间、访问热度、主题域、分层、关联指标等

3.3.2 业界元数据中心

Metacat 多数据源集成型架构设计

特点：（1）没有单独保存元数据，采用数据源直拉方式，保证元数据一致性（2）轻量化架构设计，每个数据源只需一个连接类，便与拓展

Apache Atlas 实时数据血缘采集

血缘采集的三种方式：

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

第一种方式存在准确性问题，任务未执行，SQL 不一定对。第三种方式可以保证准确性，但是时效性较差。

对于 Hive 计算引擎，Atlas 通过 Hook 方式，实时捕捉任务执行计划，获取输入表和输出表，推送给 Kafka，由一个 Ingest 模块负责将血缘写入 JanusGraph 图数据库中。然后通过 API 的方式，基于图查询引擎，获取血缘关系。

3.3.3 网易元数据中心

网易元数据中心五大目标：

• 多业务线、多租户
• 多数据源：支持不同类型的数据源（MySQL、Hive、Kudu等），还要支持相同数据源的多个集群和半结构话的 KV（Kafka、Redis、HBase等）。这些系统没有表结构元数据，需要能够在元数据中心定义 Kafka 中每个 Topic 中每条记录 JSON 中的格式。
• 数据血缘：实时采集和高性能查询，字段级别的血缘
• 集成大数据平台：与 Ranger 集成，实现基于 tag 的权限管理方式。在元数据中心可以为表定义一组标签，Ranger 可以基于这个标签，对拥有标签的一组表授权。
• 数据标签：支持对表和表字段打标签，通过标签完善数据特征

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

数据字典：由一个统一的 Connector Manager 负责管理到各个数据源的连接，通过直接连数据源实时获取元数据。对于 Kafka、HBase、Redis 等 KV，在元数据管理模块中定义 Value 的 schema 信息

数据特征：主要是标签的管理和数据访问热度信息，指标、分组、主题域等信息以标签的形式存储，允许用户基于标签类型和标签搜索表和字段

3.3.4 数据地图

数据地图是基于元数据中心构建的一站式企业数据资产目录，可以看做是元数据中心的界面。数据地图提供了一站式的数据发现服务，解决了检索数据，理解数据的需求。

3.4 指标管理

3.4.1 指标混乱现状

• 相同指标名称，口径不同
• 相同口径，指标名称不同
• 不同限定词，描述相同事实过程的两个指标，相同事实部分口径不一致
• 指标口径描述不清
• 指标口径描述错误
• 指标命名难以理解
• 指标数据来源和计算逻辑不清晰

3.4.2 规范化定义指标

<img src=“https://img-blog.csdnimg.cn/img_convert/a7429d03c6b1a372e4f4e03473331d74.png” alt=“img”
=“zoom:75%;” />

• 面向主题域管理：按照业务线、主题域、业务过程三级目录方式管理指标

• 拆分原子指标和派生指标：原子是按规则无法继续拆分的指标，派生指标 = 统计周期 + 统计粒度 + 业务限定 + 原子指标

  统计周期 + 统计粒度 + 业务限定 + 原子指标 = 派生指标
  近 30 天    商品     黑卡会员   购买用户数
  

• 命名必须遵循 “统一、易懂” 原则：原子指标适用 “动作 + 度量” 的命名方式，标识命名采用英文缩写或汉语拼音缩写；派生指标适用 “统计周期 + 统计粒度 + 业务限定 + 原子指标” 的命名方式，标识命名要用 " 业务限定_原子指标_ 统计周期"

• 关联的应用和可分析维度：在全局的指标字典中，应该有关联的应用和可分析维度，便于去对应的应用查看指标数值和从不同纬度分析指标变化趋势

• 分级管理：数据中台产出公共核心指标，业务部门产出专属指标，众多指标需要分级管理。

  • 一级指标：数据中台直接产出，核心指标、原生指标和跨部门派生指标
  • 二级指标：基于中台提供的原生指标，业务部门创建的派生指标

3.4.3 指标系统

使用 Excel 管理指标存在的问题：

• 难以共享
• 无权限控制
• 无法动态更新
• 无法与数仓模型进行动态关联

指标系统是基于元数据中心的指标管理工具，它从元数据中心自动同步数仓的主题域和业务过程，按照规范化定义创建指标。新创建的指标会下沉到数据中心对于的表和字段上，这样可以在数据地图上搜索表关联的指标。

3.4.4 指标字典

指标治理的最终目的是基于指标系统构建全局业务口径统一的指标字典

强调几点：

• 指标需求评审：需求方、数据开发、应用开发都参与，主要确定指标是否已存在，是原子指标还是派生指标
• 该流程适用一级指标，二级指标可不需要评审

对于已经存在的产品或应用的指标进行如下梳理：

1. 成立专门的工作小组负责指标的全局梳理

2. 制定梳理计划，明确梳理目标覆盖的业务线，和业务方制定时间计划

3. 对每条业务线使用的数据报表和数据产品进行盘点

4. 对每个报表和数据产品涉及的指标按指定格式进行收集

5. 对收集的指标明确业务口径，去除口径相同的，关联的应用进行合并

6. 根据指标业务口径，明确指标所属的主题域、业务过程

7. 区分指标类型，对派生指标，要明确指标的统计周期、统计粒度、业务限定和关联的原子指标

8. 根据指标系统对指标的规范化定义，将整理好的指标录入系统

3.5 数据模型

3.5.1 数据模型设计

一个好的数据模型设计应该是 “数据模型可复用，完善且规范”

• 完善度：
  • DWD 完善度：衡量 DWD 层是否完善，主要看 ODS 层多少表被 DWT/DWA 层引用，跨层引用率越高，DWD 完善度越低。跨层引用率表示 ODS 层直接被 DWT/DWA 层引用的表占所有 ODS 层表（活跃表）的比例
  • DWT/DWA 完善度：衡量 DWT/DWA 层是否完善，主要看 DWT/DWA 层查询次数占数仓查询次数的比例，DWT/DWA 层查询次数占比越高，完善度越高
• 复用度：用模型引用系数作为指标，衡量数据中台模型设计的复用度，引用系数越高说明数仓的复用性越好。模型引用系数是指一个模型被读取，直接产出下游模型的平均数量
• 规范度：一看表的分层信息和所属主题域；二看表命名是否包含分层、主题域、业务过程、内容、分区规则等；三是保证相同含义的字段名必须相同

3.5.2 从烟囱式小数仓到共享数据中台

• 接管 ODS 层，控制源头：ODS 层表的数据必须和数据源的表接口、表记录一致，对 ODS 层表的命名采用 ODS_业务系统数据库名_业务系统数据库表名

  ods_warehouse_stock
  分层_数据库名_表名
  

• 划分主题域，构建总线矩阵：主题域是业务过程的抽象集合，主题域划分尽可能覆盖所有业务需求，保持相对稳定性，还具有扩展性（新建主题域不影响原主题域的表），总线矩阵用于分析主题域下每个业务过程的可分析维度

  

• 构建一致性维度：全局一致性的维表用于关联表分析，比如分析地区配送延迟导致投诉情况。维度统一最大的难点在于维度属性（维度是商品，商品类别、品牌、尺寸等是维度属性），维表的规范命名采用 “DIM_主题域_内容_分区规则” 的方式

  • 公共维度属性和特有维度属性拆分为两个维表

  • 产出时间相差较大的维度属性拆分为单独的维表

  • 出于维表稳定性，可以按更新频率、访问频率等进行拆分

• 事实表整合：事实表整合遵循的基本原则是统计粒度必须相同，不同统计粒度的数据不能出现在同一个事实表中。此外对 ODS 层被 DWT/DWA 直接引用的情况，应该补齐 DWD 层，DWD/DWT/DWA 采用 “层次_主题_[子主题]_内容_分区规则”

• 模型开发：注意事项

  • 所有任务必须严格配置任务依赖，防止前面任务无产出而后面任务执行导致异常
  • 任务中创建的临时表，任务结束前必须删除
  • 任务名和表名保持一致
  • 生命周期管理，ODS 和 DWD 尽量保存所有历史数据，DWT/DWA 需要设置生命周期，保存 7~30 天
  • DWD 层表适合压缩存储，可用 lzo 压缩

• 应用迁移：确保数据一致

3.6 数据质量

3.6.1 数据质量问题的根源

• 业务源系统变更：
  • 源系统数据库表结构变更
  • 源系统环境变更
  • 源系统数据格式异常
• 数据开发任务变更：占比 60% 以上
• 物力资源不足
• 基础设施不稳定

3.6.2 提高数据质量

提高数据质量最重要的是 “早发现、早恢复”

• 添加稽核校验任务：在数据处理任务中，根据业务规则设计一些校验逻辑，确保数据的完整性、一致性和准确性。在数据任务运行结束后，对产出数据进行校验，判断是否符合规则预期，若不符合就按照设定的强弱规则触发不同的处理流程，强规则直接终止任务链路并报警，弱规则继续执行但会提示

  • 完整性规则：表数据量绝对值和波动率监控，主键唯一性监控和字段监控等
  • 一致性规则：
  • 准确性规则：数据格式是否异常

• 建立全链路监控：基于数据血缘关系建立全链路数据质量监控

• 通过智能预警，确保任务按时产出：基于任务运行时间和数据血缘，对下游数据产出进行实时预测，对于不能及时产出的任务进行预警

• 通过应用的重要性区分数据等级，加快恢复速度：稽核校验会消耗大量资源，只有核心任务才需要

• 规范化管理制度：

3.6.3 衡量数据质量

设计数据质量量化指标：

• 故障次数
• 基于稽核规则，计算表级别质量分数
• 需要立即介入的报警次数
• 数据产品 SLA

3.6.4 数据质量中心

数据质量中心的核心功能是稽核校验任务和全链路监控

3.7 成本优化

3.7.1 成本陷阱

• 数据上线容易下线难：无法确定表被哪些应用引用，导致不敢下线不活跃表，造成资源浪费
• 低价值应用消耗大量资源：数据部门往往更关注新的数据产品带来的价值，而忽略已有产品是否还存在价值，导致低价值应用消耗资源
• 烟囱式开发：数据重复处理导致资源浪费
• 数据倾斜：分布式并行计算框架执行时间由运行最长的任务决定，分片数据量相差太大导致资源浪费
• 数据未设置生命周期：除了 ODS 层和 DWD 层保存完整历史数据外，其他分层的数据有哦生命周期
• 调度周期不合理：服务器资源不是弹性的，尽量均匀设置任务执行时间，减少高峰和低谷的差距
• 任务参数配置
• 数据未压缩

3.7.2 精细化成本管理

成本管理按照全局资产盘点、发现问题、治理优化和效果评估四步进行

• 全局资产盘点：
  • 第一步：对数据中台中所有的数据进行全面盘点，基于元数据中心提供的数据血缘建立全链路的数据资产视图
  • 第二步：计算全链路数据资产视图中末端数据的成本和价值，价值由产品售价、使用频率和使用范围决定
• 发现问题：全局资产盘点为发现问题做支撑
  • 持续产生成本，但无使用的末端数据（30天内未访问）
  • 价值低成本高
  • 高峰高消费
• 治理优化
  • 针对上线容易下线难和低价值高成本：梳理数据血缘关系，采用末端数据下线的策略，然后评估数据资产，重复上述过程直到不能再优化
  • 针对高峰高消耗：错开任务执行时间
• 治理效果评估：主要统计和评估高峰期间下线的任务数和数据、任务每日消耗的资源、数据占用存储空间等

3.7.3 成本治理中心

系统提供了数据诊断的功能，可以按照访问时间、访问频率、关联应用等设置下线策略，支持一键灰度下线，大幅提高了管理的效率

3.8 数据服务

3.8.1 数据服务解决的问题

• 数据接入方式多，接入效率低：由于数据使用场景不同，导致接入方式不同，增大了开发和运维的难度，而数据服务屏蔽了不同的中间存储，采用统一的接口访问数据
• 数据和接口无法复用：烟囱式开发方式中，接口属于应用，而应用一般是高度定制化，导致不同应用之间接口不能复用，而数据服务使数据中台暴露的不再是数据而是接口，接口不在属于应用而是统一的数据服务上。
• 不知道数据被哪些应用访问：数据血缘建立了数据与数据之间的链路关系，但是数据到应用的链路关系是断开的，导运维难度加大，而数据服务建立了应用与数据之间的链路关系
• 数据部门字段变更导致应用变更：数据模型发生变更，导致应用也必须变更非常不合理，而有了数据服务可以将数据模型和应用进行解耦，当数据模型发生变更时修改数据服务接口参数和数据字段的映射关系即可

3.8.2 数据服务八大功能

• 接口规范化定义： 屏蔽不同的中间存储，提供统一的API
• 数据网关：认证、权限、限流（接口复用）和监控
• 全链路打通：维护数据模型到数据应用的链路关系
• 推与拉的数据交付：
• 利用中间存储加快查询：
• 逻辑模型实现复用：
• 构建 API 集市，实现接口复用:

3.8.3 数据服务系统架构设计

• 云原生：

  • 高可用：每个服务至少两个副本，副本数量根据访问量动态调整
  • 弹性伸缩：
  • 资源隔离：

• 逻辑模型：

• 数据自动导出：数据服务选择的是数据中台的一张表，然后将数据导出到中间存储中，对外提供 API

3.9 数据安全

3.9.1 三大问题

• 如何解决数据误删除操作问题
• 如何解决 敏感数据泄露问题
• 如何解决开发和生产物理环境隔离问题

3.9.2 五大机制

• 数据备份与恢复：数据中台的数据都保存在 HDFS 中，即使是及时数据也会归档到 HDFS 中，核心就是 HDFS 的备份问题，网易数据中台 HDFS 备份策略是 HDFS 快照 + DistCp + EC。
  • 文件备份：将集群分为线上集群和冷备集群，数据加工任务访问的是线上的集群，存储采用 HDFS 默认的三个副本，冷集群采用 EC 存储。线上集群创建快照，通过 HDFS 自带的 DistCp 将快照拷贝到冷备集群，实现数据同步。 线上集群每天备份前先创建快照，然后对比前一个快照拷贝增量数据，最后删除前一个快照。此外拷贝占用大量 IO 资源，建议在任务运行低谷期进行。
  • 任务备份：保存任务代码、任务的依赖关系、任务的调度配置和任务告警、稽核等信息
  • 表备份：备份表的创建语句
• 垃圾回收箱设计：HDFS 本身提供了垃圾回收站的功能，对意外删除的文件可在制定时间内进行恢复，默认是关闭的，可通过 Core-site.xml 添加配置开启。HDFS 只支持通过命令执行 rm 操作进入 trash，对通过 Delete 接口删除文件或在 Hive 中执行 drop table 删除表无效。建议将 Delete 接口和 Hive 上 HDFS Client 进行替换，实现和 rm 同样的语义。此外由于 HDFS 垃圾回收器保存的也是三副本配置，所以不宜保存太长时间，建议只保存24小时的数据，其他数据备份到冷备集群
• 精细化权限管理：数据权限是数据中台实现数据复用的前提和必要条件，权限必须在数据中台构建之初就规划好。网易实现权限管理的技术是 OpenLDAP + Kerberos + Ranger。
  • OpenLDAP：是一个轻量化的目录服务，数据以树形结构进行存储，能够提供高性能的查询服务，非常适合用户管理场景。在 OpenLDAP 中，我们可以创建用户 User 和组 Group，每个用户会有唯一的 uid，当用户加入到某个项目时，会在该项目对应的 Group 下增加一个 Memberuid。
  • Kerberos：是一种非常安全有效的认证机制，用户通过 Principal 访问 Kerberos，Hadoop 可以通过配置 hadoop.security.auth_to_local 将 Principal 映射为系统中的 OpenLDAP 用户，用户注册时平台为每个用户生成 Principal 一起相对应的 Keytab 文件
  • Ranger：提供细粒度的权限控制（Hive 列级别），基于策略的访问控制机制，支持丰富的组件以及和 Kerberos 的良好集成。注意要根据资产等级制定不同的授权策略。
• 操作审计机制
• 开发和生产集群物理隔离

3.10 数据中台的使用

3.10.1 数据应用的三个阶段

• 初级阶段：数据报表，实现数据的可视化呈现
• 发展阶段：数据产品，紧紧围绕业务做数据加工和处理
• 高级阶段：自助取数，助力业务发掘与业务实现

3.10.2 数据中台赋能 BI 工具

• 统一报表指标业务口径：指标系统
• 掌握任务影响了哪些数据报表：元数据中心
• 治理低价值的数据报表：成本治理中心
• 全维度钻取：分析师以往只能根据经验判断指标有哪些可分析维度，而 BI 工具可根据元数据中心提供的所有指标可分析维度，自动根据指标在各个维度下的取值，找到指标波动的原因

3.10.3 数据运营体系

以零售行业奶茶店为例：

• 销售
  • 拉新
    • 基于数据评估 广告渠道转化效果
    • 基于数据计算人群画像，推正确的商品给正确的人
    • 指标：新消用户数、新消 APRU、新消单客成本
  • 促活：基于数据计算用户喜欢的奶茶种类、门店，定向推送折扣信息
• 管理：
  • 供应链：基于数据精准预测销量，自动生成采购计划
  • 滞销商品监控：基于数据、分析原因、及时干预
• 运营：
  • 量化目标
  • 持续监控
  • 诊断分析
  • 决策建议
  • 一键执行

3.11 数据研发

3.11.1 流程协作重点问题

1. 一个流程涉及到哪些环节?
2. 这些环节涉及到哪些角色参与？
3. 承载这个场景的工具产品是什么？
4. 这些环节之间是如何衔接的？

3.11.2 研发流程

• 需求阶段：
  • 工具：指标系统
  • 涉及角色：数据产品、数据开发、应用开发、分析师
  • 产出：指标业务口径、数据来源、计算逻辑
  • 核心：指标的规范化定义
• 研发阶段：
  • 设计阶段：
    • 工具：模型设计中心
    • 涉及角色：数据架构师、数据开发
    • 产出：模型
    • 核心：基于主题域、分层的维度建模
  • 开发阶段：
    • 工具：数据集成、离线数据开发/实时数据开发、数据测试、数据质量中心
    • 涉及角色：数据开发
    • 产出：任务
    • 核心：先设计、后开发
• 交付阶段：
  • 工具：数据服务
  • 涉及角色：应用开发、数据开发
  • 产出：API 接口
  • 核心：数据抽取到中间存储，发布 API 接口
• 运维阶段：
  • 工具：任务运维中心
  • 涉及角色：数据开发
  • 产出：任务稳定运行
  • 核心：早发现、早恢复

3.12 数据使用和管理

3.12.1 数据分析流程

• 第一步：发现业务问题
• 第二步：理解数据
  • 要分析的业务流程
  • 涉及的关键指标
  • 关键指标的口径
  • 可分析的维度
• 第三步：探索式分析：通过数据地图获取元数据，判断当前数据是否满足分析需求，若不满足需要向数据开发提出需求
• 第四步：可视化展示：制作报表展示成果
• 第五步：分析过程产品化：代码构建数据产品

3.12.2 资产管理流程

在数据中台中，数据资产的精细化管理主要包括成本治理和资产管理两个部分，分别产生成本治理中心和数据管理中心。

资产管理的主要作用：

• 制定规则：数据或报表下线的规则，数据资产等级的规则等
• 系统衔接：数据等级与数据权限的审批流程，数据备份策略等流程打通

3.13 数据中台实践

3.13.1 立项数据中台项目

立项是建数据中台最关键的一步，核心是挖掘业务的痛点，跟业务达成一致的建设目标。如果能达成一个一致的、可量化的目标，数据中台项目就成功了一半。

数据中台项目立项最关注的两个问题：

• 当前数据使用过程中存在哪些痛点
• 当前业务部门最关注的业绩目标

3.13.2 推进数据中台项目落地

• 第一步，调整团队组织架构，明确各个团队的职责
• 第二步，数据整合：梳理指标、整合模型
• 第三步，研发工具产品：
• 第四步，数据产品构建：