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

《网易-数据中台》学习笔记 2. 数据仓库 3. 数据中台 3.2 方法论、支撑技术和组织架构 3.3 元数据中心 3.4 指标管理 3.5 数据模型 3.6 数据质量 3.7 成本优化 3.8 数据服务 3.9 数据安全 3.10 数据中台的使用 3.11 数据研发 3.12 数据使用和管理 3.13 数据中台实践

1. 大数据发展历程 1.1 数据仓库

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

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

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

1.2 - 数据湖

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

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

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

1.3 大数据平台

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

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

实现：

1.4 数据中台

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

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

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

1.5 Next：大数据 + 人工智能

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

2. 数据仓库 2.1 数据仓库建模

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

2.1.1 E-R 模型

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

E-R 建模步骤：

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

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

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

2.1.2 维度模型

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

建模步骤：

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

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

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

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

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

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

3. 数据中台 3.1 概述 3.1.1 面对的挑战 3.1.2 解决方案 数据重复建设：解决数据复用，相同的数据只加工一次，实现数据共享取数效率低：实现数据资产目录，实现数据地图和可视化查询平台数据质量差：数据问题及时发现和快速恢复，数据链路全流程监控 3.1.3 利与弊

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

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

3.1.3 总结

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

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

：

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

：

数据网关：实现权限、监控、流控、日志等一系列管控能力逻辑模型：屏蔽底层的数据物理实现，实现相同粒度的数据构造一个逻辑模型，简化数据接入复杂度性能与稳定性：数据服务必须是无状态，可横向拓展的

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

3.2.2 支撑技术 数据治理：以元数据为中心，在统一所有数据源的元数据的基础上，提供以下 5 个产品 数据服务数据应用 3.2.3 组织架构

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

3.3 元数据中心 3.3.1 元数据

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

3.3.2 业界元数据中心

多数据源集成型架构设计

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

Atlas 实时数据血缘采集

血缘采集的三种方式：

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

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

3.3.3 网易元数据中心

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

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

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

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

3.3.4 数据地图

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

3.4 指标管理 3.4.1 指标混乱现状 3.4.2 规范化定义指标

=“zoom:75%;” />

3.4.3 指标系统

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

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

3.4.4 指标字典

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

强调几点：

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

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

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

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

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

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

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

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

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

3.5 数据模型 3.5.1 数据模型设计

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

复用度：用模型引用系数作为指标，衡量数据中台模型设计的复用度，引用系数越高说明数仓的复用性越好。模型引用系数是指一个模型被读取，直接产出下游模型的平均数量规范度：一看表的分层信息和所属主题域；二看表命名是否包含分层、主题域、业务过程、内容、分区规则等；三是保证相同含义的字段名必须相同 3.5.2 从烟囱式小数仓到共享数据中台

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

模型开发：注意事项

应用迁移：确保数据一致

3.6 数据质量 3.6.1 数据质量问题的根源 数据开发任务变更：占比 60% 以上物力资源不足基础设施不稳定 3.6.2 提高数据质量

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

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

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

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

规范化管理制度：

3.6.3 衡量数据质量

设计数据质量量化指标：

3.6.4 数据质量中心

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

3.7 成本优化 3.7.1 成本陷阱 3.7.2 精细化成本管理

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

发现问题：全局资产盘点为发现问题做支撑 治理优化 治理效果评估：主要统计和评估高峰期间下线的任务数和数据、任务每日消耗的资源、数据占用存储空间等 3.7.3 成本治理中心

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

3.8 数据服务 3.8.1 数据服务解决的问题 3.8.2 数据服务八大功能 3.8.3 数据服务系统架构设计

逻辑模型：

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

3.9 数据安全 3.9.1 三大问题 3.9.2 五大机制 垃圾回收箱设计：HDFS 本身提供了垃圾回收站的功能，对意外删除的文件可在制定时间内进行恢复，默认是关闭的，可通过 Core-site.xml 添加配置开启。HDFS 只支持通过命令执行 rm 操作进入 trash，对通过 接口删除文件或在 Hive 中执行 drop table 删除表无效。建议将 接口和 Hive 上 HDFS 进行替换，实现和 rm 同样的语义。此外由于 HDFS 垃圾回收器保存的也是三副本配置，所以不宜保存太长时间，建议只保存24小时的数据，其他数据备份到冷备集群精细化权限管理：数据权限是数据中台实现数据复用的前提和必要条件，权限必须在数据中台构建之初就规划好。网易实现权限管理的技术是 + + 。 操作审计机制开发和生产集群物理隔离 3.10 数据中台的使用 3.10.1 数据应用的三个阶段 3.10.2 数据中台赋能 BI 工具 3.10.3 数据运营体系

以零售行业奶茶店为例：

促活：基于数据计算用户喜欢的奶茶种类、门店，定向推送折扣信息 管理： 运营： 3.11 数据研发 3.11.1 流程协作重点问题 一个流程涉及到哪些环节?这些环节涉及到哪些角色参与？承载这个场景的工具产品是什么？这些环节之间是如何衔接的？ 3.11.2 研发流程 研发阶段： 开发阶段： 交付阶段： 运维阶段： 3.12 数据使用和管理 3.12.1 数据分析流程 第三步：探索式分析：通过数据地图获取元数据，判断当前数据是否满足分析需求，若不满足需要向数据开发提出需求第四步：可视化展示：制作报表展示成果第五步：分析过程产品化：代码构建数据产品 3.12.2 资产管理流程

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

资产管理的主要作用：

3.13 数据中台实践 3.13.1 立项数据中台项目

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

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

3.13.2 推进数据中台项目落地