数据中台概念（一）

1.数据仓库

• 启蒙时代

  • BI诞生于上世纪90年代，数据转化为知识，帮助企业经营分析决策。

    • 零售行业的门店管理，如果使单个门店利润最大化

      • 分析每个商品的销售数据和库存信息

      • 为每个商品制定合理的销售采购计划，滞销降价，畅销预测，提前采购

    • 大数据量的范围查询

  • 数仓之父=》比尔 恩门=》数仓是在企业管理决策中面向主题、集成、与时间相关，不可修改的数据集合

    • 订单表和会员表

    • 按照主题域的方式组织数据

    • 自顶向下

      • TP建模方式

      • 买家表、商品表、买家商品交易表

    • 优缺点

      • 成本高，适用于固定业务，比如金融领域，冗余数据少

  • 金博尔=》自底向上（顶是数据源）

    • 用户、商品维度

    • 库存、用户账户余额的事实表

    • 优缺点

      • 适用于变化比较快的业务，比如互联网业务

    • 多样化的数据格式=》数据湖

• 数据工厂时代：大数据平台兴起

  • 数据集成=》数据开发=》数据测试=》数据发布=》任务运维

    • 好工具，提高效率

    • 面向数据研发场景的，覆盖数据研发的完整链路的数据工作台

  • 大量数据指标

    • 各个报表和数据产品

    • 随着数据需求快速增长，报表指标、数据模型越来越多，找不到数据

• 数据价值时代：数据中台崛起

  • 2016年，阿里巴巴提出数据中台的口号

    • 数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用

2.数据湖

3.数据平台

什么企业适合建中台？

• 面临的问题

  • 线上流量枯竭

  • 业绩增长乏力

  • 企业成本高筑

  • 利润飞速下滑的风险

• 提高企业运营效率的同时，暴露很多尖锐的问题

  • 指标口径不一致

    • 两个数据产品一个包含税，一个不包含税，都是销售额

  • 数据重复建设，需求相应长

    • 交付时间拉长

  • 取数效率低

    • 面对数十万报表

  • 数据治理差

    • 数据因为BUG导致计算结果错误，最终导致错误的商业决策

  • 数据成本线性增长

    • 4000CORE=>4000CORE

• 为什么数据中台可以解决这些问题？

  • 指标口径不一致的问题

    • 业务口径不一致

      • 关单 日期理解不一致？

    • 计算逻辑不一致

      • 关单 日期理解不一致？

    • 数据源不一致

      • 离线数据、实时数据统计不一致

  • 烟囱开发模式=》各自做了数据清洗？是否可以清洗一次=》节省资源=》确保数据只加工一次，实现数据的共享

  • 取数效率低

    • 构建一个全局的企业数据资产目录，实现数据地图的功能，快速找到数据

    • 提供可视化查询平台，通过勾选一些参数

  • 数据质量差

    • 加工链路一般非常长，等到使用人投诉，才发现问题=》及时发现然后恢复数据问题

数据中台核心是啥？

数据中台是企业构建的标准的、安全的、统一的、共享的数据组织，通过数据服务化的方式支持前端数据应用

如何解决这些问题？

• 一个团队统一负责指标口径的管控

• 指标体系化管理，提高指标管理的效率

• 确保所有的数据产品、报表都引用指标系统的口径定义（运营移到某个指标上，就会有相应的定义）

如果实现所有的数据只加工一次？

• 数仓设计中心，在设计模型设计阶段，强制相同的聚合粒度的模型，度量不能重复

• 数据地图，方便数据开发能够快速理解表的含义

服务化的方式，提高了数据应用接入和管理的效率

• 数仓的数据是通过API的方式提供给数据应用，不关心底层的查询引擎访问的差异

非技术人员提供可视化取数平台

全链路的数据质量稽核监控，对一个指标的产出上游链路中设计的每个表，都实现了数据一致性，完整性、正确性的监控

成本问题

• 数据成本治理系统

  • 应用维表、表维度、任务的维度、问津的维度进行全面的治理

    • 应用维度

      • 30天没有访问，价值极低

      • 结合报表的上游表以及上游表的产出任务，计算这张表的成本，有了价值和成本，就能计算ROI，根据ROI就可以实现将低价值的报表下线的功能=》节省20%的成本

什么企业适合数据中台？

离不开系统志诚，研发系统需要投入大量的人力；面对大量的数据需求，要花费额外的人力去做数据模型的重构

选择数据中台考虑的因素：

• 企业是否大量的数据应用场景

  • 快速地孵化数据应用

    • 企业有较多数据应用功能的场景

• 整合各个业务系统的关联，进行关联分析

  • 仓储、供应链、市场运营都是独立的数据仓库，数据分析往往跨了多个系统

• 团队面临效率、质量和成本的苦恼，不知如何提效

• 投入大，收益偏长线，所有适合稳定的大公司，不适合初创型的小公司

数据中台建设三板斧：方法论、组织和技术

建数据中台比作是盖房子，那么设计图纸就是数据中台建设的方法论；工具是数 据中台的支撑技术；施工队伍就是数据中台的组织架构。

数据中台建设方法论

• onedata

  • 所有数据只加工一次

  • 如何实现只加工一次？

    • 分主题域管理

      • 电商业务

        • 商品、交易、流量、用户、售后、配送、供应链

    • 命名规范定义

      • dwd_wms_inbound_item_info_di

    • 指标一致

    • 数据模型复用

      • 采用分层设计

      • 数据中台的数据尽可能覆盖所有

    • 数据完善

• oneservice

  • 数据即服务，数据中台的数据应该是通过API接口的方式被访问

  • 如何实现数据服务化

    • 屏蔽异构数据源

      • 数据服务必须能够支持类型丰富的查询引擎，满足不同场景的数据查询

        • mysql、hbase、gp、redis、es

    • 数据网关

      • 包含权限、监控、流控、日志在内的一系列管控能力

    • 逻辑模型

      • 从用户的视角触发，屏蔽底层的模型设计的实现，面向用户提供逻辑模型

    • 性能和稳定性

      • 数据服务侵入到用户的访问链路，所以对服务的可用性和性能都有很高的要求，数据服务必须是无状态的，可以做到横向扩展

  • 数据中台组织定位

    • 懂业务、能够深入业务、扎根业务

    • 具体组织架构

      • 数据产品团队

        • 负责数据中台、数据产品的体系规划、产品设计、规范制定、应用效果跟进

      • 数据平台团队

        • 负责研发数据中台构建的产品，例如指标系统、元数据中心、数据地图

      • 数据开发团队

        • 负责维护数据中台的公共数据层，满足数据产品制定的数据需求

      • 应用开发团队

        • 负责开发数据应用产品，比如报表系统、电商中供应链系统、高层看板、经营分析

  • 中台组织的绩效目标一定是要与业务落地价值绑定的

数据中台实现篇

元数据中心的关键目标和技术实现方案

• 元数据包含哪些

  • 分类

    • 数据字典

    • 数据血缘

    • 数据特征

  • 产品（借鉴已有的产品）

    • 开源

      • Metacat

        • 直接数据源拉取

          • 不存在一致性的问题

          • 架构很轻量化

      • apache atlas

        • 实时采集数据血缘的架构设计

          • 通过静态解析sql，获得输入表和输出表

          • 实时抓取正在执行的sql，解析执行计划，获取输入、输出表

          • 任务日志解析的方式，获取执行后的sql输入表和输出表

    • 商业化

      • cloudera navigator

    • 网易元数据中心设计

      • 多业务线、多租户

        • 电商

        • 音乐

      • 多数据源支持

        • 有结构化的元数据

        • 半结构化的元数据

      • 数据血缘

        • 元数据中心需要支持数据血缘的实时采集和高性能查询，必须支持字段级别的血缘

        • 支持生命周期

      • 与大数据平台集成

        • 元数据中心需要与Ranger集成，实现基于tag的权限管理方式

        • ranger可以基于这个标签，对拥有某一个标签的一组表按照相同的权限授权

          • 对于会员、交易、毛利、成本可以设定表的敏感等级，然后根据敏感等级，设定不同的人有权限查看

      • 数据标签

        • 元数据中心必须要支持对表和表中的字段打标签，通过丰富的不同类型的标签，可以完善数据中台数据的特征

  • 指标管理

    • 每日给CEO提供的每日新用户销售额数据不一致

      • 市场部门与会员中心关于新用户口径不同

        • 市场部门

          • 首次下单并完成支付的用户

        • 会员中心

          • 当日新注册用户

    • 指标混乱现状

      • 网易电商数据中台团队对电商业务核心指标进行全面的梳理和怕你单

        • 原先800个指标最终梳理成427个指标

      • 指标问题

        • 同名不同径，通径不同命

        • 口径不清晰，口径有错误

        • 命名难理解，计算不易懂

        • 来源不清晰，同部不同经

    • 如何规范化定义指标

      • 面向主题域管理

        • 为了提高指标管理的效率，需要按照业务线、主题域和业务过程三级目录方式管理指标

          • 业务线

            • 电商、游戏、音乐、传媒、教育

          • 主题域

            • 划分标准与数仓保持一致

          • 业务过程

            • 加入购物车、下单、支付

      • 拆分原子指标和派生指标

        • 统计周期、统计粒度、业务限定、原子指标，组成派生指标

      • 命名规范

        • 易懂

        • 统一

        • 对于原子指标

          • 适合用“动作+度量”

        • 对于派生指标

          • 遵循“时间周期+统计粒度+修饰词+原子指标”

      • 关联的应用和可分析维度

        • 指标被哪些应用使用，方便去对应的数据产品或报表上查看指标的数值

        • 有指标的可分析维度，方便分析师从不同的维度分析指标的变化趋势

      • 分等级管理

        • 一级指标

          • 数据中台直接产出，核心指标（提供给公司高层看的）、原子指标以及跨部门的派生指标

        • 二级指标

          • 基于中台提供的原子指标，业务部门创建的派生指标

      • 不同等级的指标意味着管理方式不同

        • 一级指标

          • 确保指标按时、保证质量产出，指标创建由中台负责

        • 二级指标

          • 允许业务自己创建，中台不承诺指标的产出时间和质量

      • 指标系统

        • Excel不是指标管控的原因

          • 难于共享

          • 缺少权限控制

          • 无法动态更新

          • 指标无法跟数仓的模型动态联动

        • 基于指标系统构建全局的指标字典

          • 可以通过指标字典，快速了解指标的业务含义和计算过程，不会对指标口径产生歧义

          • 一个负责指标管理的人或者小组，最少是数据产品经理来负责

          • 分为两个场景

            • 面对一个新的指标需求，如何基于指标系统完成指标的开发流程

            • 面对已存在的，混乱的指标现状，如何进行全局梳理

          • 全局梳理工作步骤

            • 成立以数据产品或者分析者为核心的1-3人工作小组，负责指标的全局梳理

            • 制定指标梳理计划，明确指标目标，覆盖多少个业务线

            • 对于每一个业务线，需要对还在使用的数据报表、数据产品进行盘点，顺便把没用的报表和数据产品下线

            • 对于每一个报表和数据产品中涉及的指标，按照一下的格式来收集

              • 指标展示名称

                • 购买用户数

              • 指标标识

                • buyer_num

              • 业务口径

                • 支付成功的购买用户数量，按统计周期去重

              • 数据来源

                • dwd_trd_bd_item_di

              • 分析维度

                • 商品、类目、流量来源、品牌

              • 数据应用

                • 报表链接

              • 计算逻辑

                • SQL/或者伪代码

            • 对于收集的指标，明确业务口径，对于相同口径的，应该去除重复，关联的应用应该合并，可以适当过滤一部分

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

            • 区分指标类型，对于派生指标，要明确指标的统计粒度、修饰词、时间周期以及关联的原子指标

            • 按照指标系统对指标的规范定义，把整理好的指标录入指标系统

    • 什么才是一个好的数据模型设计

      • 按照分层统计表的数量

        • ODS:DWD:DWS:ADS=》1072:545:187:433

        • ODS=>ADS 物理深加工？

      • 理想的数仓模型设计应该具备的因素

        • 数据模型可复用，完善且规范=》数据比较丰富完善、数据复用性强、规范性强

          • 完善度

            • DWD

              • 跨层引用率

            • DWS/ADS/DM

              • 汇总数据查询比例

            • 考核标准

              • DWD层完善度

                • 跨层引用率，ods跨层使用，占所有ods层表的比例

                • 越低越好，规范中是不允许跨层使用的

              • DWS/ADS/DM 层完善度

                • 汇总数据能直接满足多少查询需求

                • 汇总数据查询比例：DWS/ADS/DM 层的查询占所有查询的比例

                • 越高越好

          • 复用度

            • DWD/DWS

              • 模型引用系数

                • 较差的模型设计

                  • 自上而下是一条线

                • 较好的模型设计

                  • 发散型结构

                • 一个模型被读取，直接产出下游模型的平均数量

                  • 一个DWD层表被5张DWS层表引用，这张DWD层表的引用系数就是5

                  • 一般低于2比较差，3以上相对较好

          • 规范度

            • 有多少表没有主题域、业务过程没有归属

            • 模型命名不规范

            • 字段命名不规范

      • 如何从烟囱式的小数仓到共享的数据中台

        • 接管ods层，控制数据源

          • ods层表的数据必须和数据源的表结构、表记录数一致，高度无损，对于ODS层表的命名采用ODS_业务系统数据库名_业__业务系统数据库表名方式

        • 划分主题域，构建总线矩阵

          • 划分主题域，建构总线矩阵

            • 主题域+业务过程+可分析维度

        • 构建一致性维度

          • 公共维度属性与特有维度属性拆成两个维表

          • 大表拆小表分区策略

            • DD

            • DI

            • WD

            • WI

            • MI

            • MD

            • ND

        • 事实表整合

          • 统计粒度必须保持一致，不同统计粒度的数据不能出现在同一个事实表中

          • 输入表是ODS=》是否可以使用现有的DWD

            • 迁移到现有的DWD

            • 新建DWD

              • 迁移任务

        • 模型开发

          • 所有任务都必须严格配置任务依赖

          • 任务中创建临时表，任务结束前应该删除

          • 任务名称跟表名一致

          • 生命周期管理，ODS层和DWD层，一般尽可能保留所有历史数据，对于DWS/ADS/DM需要设置生命周期，7-30天不等

          • DWD层表宜采用压缩的方式存储，可用lzo压缩

        • 应用迁移

          • 最后一步就是应用的迁移，注意数据的比对，确保数据一致性

        • 数仓建模工具

          • EasyDesign

            • 按照主题域、业务过程、分层的方式管理所有的模型

数据质量问题如何解决

数据质量问题的根源

• 根源问题复盘

  • 业务员系统变更

    • 源系统数据库表结构变更

      • 增加字段

    • 源系统环境变更

      • 大促多了5台服务器

    • 源系统日志数据格式异常

      • 166.111.4.null出现

  • 数据开发BUG

    • 数据开发任务变更

      • 引用的测试库没有修改为线上库

      • 代码中使用的固定分区，没有切换为环境

      • 数据格式处理错误，代码忽略了异常，导致数据错误

      • 任务配置异常

  • 物理资源不足

    • 多租户，hadoop生态的大数据任务一般运行在yarn管理的多个队列上，每个队列都是分配了一定大小的计算资源

      • 数据量暴涨

      • 写了很差的sql

  • 基础设施不稳定

    • Hadoop2.7 NameNode的BUG，造成HDFS整个服务都停止读写=》临时补丁修复

• 如何提高数据质量

  • 早发现，早恢复

  • 添加稽核校验任务

    • 对产出表按照业务规则，设计一些校验逻辑

      • 数据的完整性、一致性和准确性

      • 弱规则

        • 触发不同流程

      • 强规则

        • 终止加工链路，立即发出电话报警

      • 完整性规则

        • 主要目的是确保数据记录是完整的

          • 表数据量绝对值监控和波动率的监控（比如表波动超过20%，就认为是异常）

          • 字段级别的监控（字段为0或null）

      • 一致性规则

        • 主要解决相关数据在不同模型中一致性的问题

          • 购买数量是1W、商品访问uv10W、商品购买率20%

      • 准确性规则

        • 解决数据记录准确性问题

          • 是不是IP正确的格式

  • 建立全链路监控

    • 源数据=》大数据加工=》指标=》应用

  • 通过智能预警，确保任务按时产出

    • 对下游指标产出时间进行实时预测，一旦发现指标无法按时产出，则立即报警，数据开发可以终止一些优先级低的任务，确保核心任务

  • 通过应用的重要性区分数据等级，加速恢复速度

    • 稽查校验会消耗大量的资源，只有核心任务才需要

  • 规划范管理制度

    • 规则完备性如何保障

      • 制定一些通用的指导规则

      • 数据架构师牵头，按照主题域、业务过程，对每个表进行规则的评审

  • 如何衡量数据质量

    • 数据治理=》效果可量化

  • 数据质量中心平台

    • 质量大屏

    • 质量评估

    • 监控列表

    • 监控执行历史

速度质量之外=》省

精细化的成本管理

CU=1vpcu+4G memory，年度曲线，研究规律

八种陷阱

• 数据上线容易下线难

  • 近30日无访问的表

    • 表存储及总占比

• 低价值的数据应用消耗了大量的资源

  • 数据报表的加工=》运营实习生用=》每日消耗6000=》投入和产出极不匹配

• 烟囱式的开发模式

  • 数据重复加工，一张500T的表，高峰消耗300Core，一年消耗40W

• 数据倾斜

  • 不同用户下单不同，但是group by 分配的资源一致，计算不均匀

• 数据未设置生命周期

  • 一般原始数据和明细数据，会保留完整的历史数据，而汇总层和集市层会考虑成本，按照生命周期来管理

• 调度周期不合理

  • 任务都集中在同一时段

• 任务参数配置

  • Spark各个参数配置不合理

• 数据未压缩

  • 数据未压缩，造成成本急剧消耗

如何做？

• 全局盘点

  • 基于元数据中心提供的数据血缘，建立全链路的数据资产视图

  • 计算数据资产视图末端的成本和价值

    • 数据成本如何计算？

      • a,b,c 三个子任务 A-F 6张表

      • 成本=》3个任务加工消耗的计算资源成本+6张表消耗的存储资源成本

      • 如果被多个下游应用复用，则可分摊给多个应用

    • 价值如何计算？

      • 末端数据价值

        • 应用层表

          • 报表展示类应用

            • 适用范围

            • 产品粘性

          • 面向特定场景的数据应用

            • 目标人群覆盖

            • 直接业务价值产出

        • 轻度汇总层或者集市层

          • 使用范围

          • 使用频率

• 发现问题

  • 第一类

    • 没有使用，但一直消耗成本

      • 陷阱1

  • 第二类

    • 低价值产出，高成本的数据应用

      • 陷阱2

  • 第三类

    • 高成本的数据

      • 陷阱4-8

• 治理优化

  • 对于第一类问题

    • 表进行下线

      • 线上数据删除=》制定下线策略=》停止产出任务调度=》数据进入冷备集群=》线上。。。。

  • 对于对二类问题

    • 按照粒度评估应用是否有存在的必要，对于报表，可以按照30天内没有访问的应用自动下线策略

  • 对于第三类问题

    • 任务高消耗=》是否数据倾斜=》压缩格式=》生命周期存储

• 效果评估

  • 省了多少钱

    • 下线了多少任务和数据

    • 这些任务每日消耗了多少资源

    • 数据占用了多少存储空间

成本治理中心

• EasyCost

数据服务

• 数据服务解决了什么问题？

  • 不知道数据被哪些应用访问

  • 数据接入方式多样，接入效率低

  • 数据和接口没办法共享

  • 底层数据变更，影响数据应用

• 数据服务应该具备的八大功能

  • 接口规范化定义

    • 取快递约定的收货码

  • 数据网关

    • 对每个货架前的队伍进行限流

  • 链路关系的维护

    • 驿站会记录谁取走了什么快递

  • 数据交付

    • 驿站提供送货上门

  • 提供多样中间存储

    • 不同类型的货架

  • 逻辑模型

    • 一个工作人员，可以取多个货架的快递

  • API接口集市

    • 不同货架的不同队伍的导览

  • API测试

    • 驿站工作人员上岗前的测试

• 数据服务的系统架构设计

  • 云原生

    • 每个服务至少两个副本，实现高可用，根据访问量的大小动态扩缩容

    • k8s service

      • 多个副本的Pod

        • API+envoy

  • 逻辑模型

    • 包括了逻辑模型和物理模型的映射关系

  • 自动导出

• 数据中台安全保障

  • 数据备份/恢复

    • HDFS快照+DistCp+EC实现

  • 操作审计

    • 用户访问数据=》权限认证=》获取用户访问记录=》Ranger支持审计的功能=》用户的访问记录会由部署在各个插件推送到Audit Server上，然后存储到Solr，Ranger提供了API接口查询表的访问记录

  • 精细化权限管理

    • OpenLDAP + Kerberos + Ranger

  • 删除数据垃圾箱设计

    • HDFS Client进行修改，删除的文件进入trash

  • 生产、测试集群隔离

    • 正式环境数据=》脱敏=》开发环境

中台使用

• 数据报表

  • 初级阶段

• 数据产品

  • 发展阶段

    • 业务需要持续监控业务过程，发现问题、诊断分析、给出决策建议、最后一键执行

• 自助取数

  • 普惠大数据

数据中台如何赋能BI工具

• 统一报表指标业务口径

  • 口径定义修改

• 掌握任务影响了哪些数据报表

  • 数据血缘一目了然

• 治理低价值的数据报表

  • 降低成本

• 全维度钻取

  • BI工具根据元数据中心提供所有的指标可分析维度

打造零售行业精益数据运营体系

• 目标量化=》持续监控=》诊断分析=》决策建议=》执行=》目标。。。。

自助取数

• 效率提升10倍以上