数据中台
1. 中台产生
业务发展前期，为了快速实现需求，烟囱式开发导致企业不同业务线不同的应用之间，数据是割裂的（数据孤岛）。两个数据应用的相同指标，展示的结果是不一致的，导致运营对数据信任度下降。另外数据割裂导致了大量的重复计算，浪费了人力和物力成本。
数据中台是指通过数据技术对海量数据进行采集、计算、存储，同时统一标准和口径，形成全域级、可复用的数据资产中心和数据存储能力中心，形成大数据资产层，进而为客户提供高效的服务。
狭义上的数据中台是一套实现数据资产化的工具，广义上的数据中台是一套利用数据帮助企业实现数字化转型的机制和方法。
总之，数据中台的核心理念是让一切业务数据化，一切数据业务化，数据取之业务，用之于业务。
核心是避免数据重复开发，积累数据落地，快速灵活响应需求，通过数据服务化，提高数据的共享能力，赋能数据应用。
数据中台是企业构建的标准的、安全的、统一的、共享的数据组织，通过数据服务化的方式支撑 前端数据应用。数据中台消除了冗余数据，构建了企业级数据资产，提高了数据的共享能力。
2. 问题及中台的解决方案
2.1 问题现象
- 指标口径不一致：业务口径不一致，数据来源不一致，计算逻辑不一致。》》需要统一。
- 数据重复建设：数据重复建设，浪费资源。》》要确保相同数据只加工一次。
- 取数效率低：面对几千上万张表，分析师想要快速找到数据以及理解这些数据意义，十分困难。》》需要构建全局的企业数据资产目录，实现数据地图的功能。
- 数据质量差：没有数据稽核任务，数据可靠性低。》》建立数据质量监控平台，及时报警
- 数据成本线性增长：烟囱式开发导致一个企业有多个小数仓，数据重复建设，也无法下线低价值数据任务》》解决重复建设，打通数据孤岛。
2.2 解决方案
构建一个统一的平台，提供统一的出入口：OneData，OneService
- 由一个团队，负责所有指标的管控，明确每个指标的业务口径，数据来源和计算逻辑，消除指标二义性，确保一个指标的意义和计算逻辑在全公司只有一个唯一的相同口径
- 提供可视化的取数平台，选取指标添加过滤条件即可获取数据
- 成本控制，对低价值的任务进行下线
数据中台投入大，收益偏长线，适合业务相对稳定的大公司。
3. 如何建设数据中台
三板斧：方法论、组织、技术
3.1 方法论
在 2016 年，阿里巴巴就提出了"大中台，小前台"，倡导数据中台建设，核心方法论：OneData 和 OneService
3.1.1 OneData
简而言之：OneData就是所有数据只加工一次。
在整个企业中形成一个公共数据层，消灭跨部门的小数仓，实现数据的复用，所以强调数据只加工一次。
如何实现：
- 数据划分主题进行管理：不同的表放到不同的数据域，表名按照规范命名，做好见名知意
- 数据格式和字段命名规范化：词根标准化，分区规则，存储格式
- 指标一致：提供全局数据字典，不存在二义性
- 数据模型复用：采用分层的设计方式
- 数据完善：数据中台尽可能的覆盖到所有业务过程
OneData体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。差异在于资产是可以沉淀和复用的，成本是消耗的，临时的。
3.1.2 OneService
数据即服务，强调数据中台的数据应该通过API接口的方式被访问
现阶段企业数据应用现状：
- 数据量小的使用 MySQL：Hive数仓，Spark计算引擎的计算结果导出到MySQL
- 数据量大的使用HBase + ElasticSearch：解决海量数据中的低延迟高效查询
- 需要多维分析的可能需要 ClickHouse，Kylin，Greenplum：提供现在分析能力
- 实时性要求高的需要用到 Redis
因此，从不同的系统取数据，应用开发需要定制不同的访问接口。而且如果数据发生异常，还不能查出影响到下游应用的那些应用或者报表。所以当你想下线一张表的时候，就无法实施，造成了上线容易，下线难的囧状。
而 API 接口一方面对应用开发屏蔽了底层数据存储，使用统一标准的 API 接口查询数据，提高了数据接入的速度。另一方面，对于数据开发，提高了数据应用的管理效率，建立了表到应用的链路关系。
如何实现：
- 屏蔽异构数据源：数据服务必须要能够支撑类型丰富的查询引擎，满足不同场景下数据的查询需求，常见的有 MySQL、HBase、Greenplum、Redis、Elasticsearch 等。
- 数据网关：要实现包括权限、监控、流控、日志在内的一系列管控能力，哪个应用的哪个页面访问了哪个模型，要做到实时跟踪
- 逻辑模型代替物理模型： 数据库中有一个视图的概念， 每次在查询的时候，动态地将不同表的查询结果聚合成视图的查询结果
- 性能和稳定性：由于数据服务侵入到用户的访问链路，所以对服务的可用性和性能都有很高的要求，数据服务必须是无状态的，可以做到横向扩展。
3.2 体系
计算和存储基础设施：以hadoop为代表的大数据计算、存储基础设施
工具产品：数据集成、数据开发、数据测试到任务运维的整套工具链产品
数据治理模块：对应的方法论就是OneData，以元数据中心为基础，提供包括但不限于数据地图，数仓设计、数据质量、成本优化、指标管理等产品。
数据服务：对应的方法论就是OneService。数据服务向下提供了应用和表的访问关系，向上支撑了各种数据应用和服务。
数据产品和服务：在数据服务之上，是面向不同场景的数据产品和应用，如自助取数系统，自助分析系统，报表系统等。
3.3 组织
对数据中台的组织定位是：懂业务，能够深入业务，扎根 业务。应包含中数据产品团队、数据平台部门、数据开发团队、应用开发团队
- 数据产品团队：负责数据中台、数据产品的体系规划、产品设计、规范制定、应用效果跟进，指标口径的定义和维护
- 数据平台团队：研发数据平台系统，如指标系统、元数据中心、数据地图等
- 数据开发团队：负责维护数据中台的公共数据层、满足数据产品制定的数据需求
- 应用开发团队：负责开发数据应用产品，比如报表系统、前端看板、经营分析
4. 数据中台实现
4.1 元数据中心
4.1.1 元数据概念
数据字典：数据的结构信息：表结构（表名、字段名、类型、注释）、表权限
数据血缘：任务之前的依赖关系，可以帮助我们做影响分析和故障溯源
数据特征：数据的信息：存储空间大小，数仓分层，访问热度，主题分类，关联指标
4.1.2 元数据技术
业界比较流行的元数据产品技术主要有：
- 开源的有 Netflix 的 Metacat、Apache 的 Atlas；
- 商业化的产品有 Cloudera Navigator。
关于开源的这两款产品，Metacat 擅长管理数据字典，Atlas 擅长管理数据血缘。
Metacat 介绍：https://github.com/Netflix/metacat
最大的优势：多数据源的可扩展架构
从 Metacat 的架构图中，可以看到，Metacat 的设计非常巧妙，它并没有单独再保存一份元数 据，而是采取直连数据源拉的方式，一方面它不存在保存两份元数据产生一致性的问题，另一方面，这 种架构设计很轻量化，每个数据源只要实现一个连接实现类即可。
Apache Atlas 介绍：http://atlas.apache.org/
血缘采集（表血缘，字段血缘），一般可以通过三种方式：
- 通过静态解析 SQL，获得输入表和输出表；
- 通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表；
- 通过任务日志解析的方式，获取执行后的 SQL 输入表和输出表。
第一种方式，面临准确性的问题，因为任务没有执行，这个 SQL 对不对都是一个问题。第三种方式， 血缘虽然是执行后产生的，可以确保是准确的，但是时效性比较差，通常要分析大量的任务日志数据。
所以第二种方式是比较理想的实现方式，而 Atlas 就是这种实现
4.1.3 元数据中心架构设计
按照功能模块分为数据血缘、数据字典和数据特征。
元数据中心统一对外提供了 API 访问接口，数据传输、数据地图、数据服务等其他的子系统都可以通过 API 接口获取元数据。另外 Ranger 可以基于元数据中心提供的 API 接口，获取标签对应的表，然后根 据标签更新表对应的权限，实现基于标签的权限控制。
4.1.4 元数据设计要点
元数据中心是数据中台的基石，它提供了我们做数据治理的必须的数据支撑，数据的指标、模型、质量、成本、安全等的治理，都依赖与元数据的支撑。
- 扩展性：元数据中心设计上必须注意扩展性，能够支持多个数据源，所以宜采用集成型的设计方式。
- 字段级别：数据血缘需要支持字段级别的血缘，否则会影响溯源的范围和准确性。
4.2 指标管理
指标管理、模型设计、数据质量和成本治理构成了OneData数据体系
4.2.1 常见的指标问题
- 相同的指标名业务口径、计算逻辑、数据来源不一致
- 指标数据来源、计算逻辑、业务口径描述不清晰
- 相同的业务口径指标名不同
- 指标口径描述不清晰或指标命名难于理解
4.2.2 如何定义指标
- 面向主题：为了提高指标管理的效率，可以按照业务线、主题域和业务过程三级目录方式管理指标
- 拆分原子指标、派生指标和复合指标：解决不同的两个指标描述的相同业务过程中的相同事实部分口径不一致
- 命名规范：规范统一化，见名知意
- 分等级管理
- 记录关联的应用和可分析的维度
4.2.3 如何构建指标系统
- 提供一个易于维护和管理的指标管理系统，具备增删改查功能。
- 团队必须要专人来承担指标维护，如分析师，产品经理。
- 提供一个完备的指标创建流程：提交指标需求，需求评审（确认指标口径、维度）、模型设计、数据开发、验证、上线、监控
4.3 模型设计
烟囱式数据开发：数据模型无法复用，每次遇到新的需求，都从原始数据重新计算。构建数据中台后，要提交数据的复用率。
4.3.1 如何构建
常见的数仓分层，根据实际情况分层设计
4.3.2 验收标准
构建可复用模型的标准：数据模型可复用，完善且规范
- 统计明细层完善度：统计 DWD /DWS层表被跨层引用次数即可，次数越多，证明完善度越好
- ADS/DM 层完善度：能满足多少查询需求。
4.4 数据质量
4.4.1 数据质量问题
造成数据质量问题通常有以下几种情况：
- 业务系统变更，包括表结构变更，源系统环境变更，源数据格式异常
- 数据开发bug
- 物理资源不足
- 集群环境问题
4.4.2 提高数据质量
早发现，早恢复，建立数据质量监控平台。指标上线后建立监控机制。
- 基于血缘关系建立全链路的时效监控，通过智能预警，确保任务按时产出
- 添加指标稽核校验任务：确保数据完整性、一致性和准确性
- 根据重要性设定优先级，资源倾斜
4.4.3 质量衡量标准
最好的方法就是量化
- 在预定时间前完成的任务比例
- 基于稽核规则，计算表级别的质量分数
- 数据产品SLA(Service-Level Agreement)：可用性、准确性、延迟、系统负载量
4.5 成本控制
4.5.1 成本问题
- 调度周期不合理，未形成闲忙搭配，父队列资源动态分配到子队列
- 烟囱式开发，导致资源浪费
- 未设置数据生命周期，导致过期数据占用磁盘
- 数据上线容易，下线难，没有下线机制
- 低价值的数据消耗了大量机器资源
- 数据未压缩存储
4.5.2 成本管控
第一：全局资产盘点
1.对数据中台所有数据进行一次全面盘点，基于元数据中心提供的血缘关系，建立全链路的数据资产视图
2.计算数据成本：任务消耗的计算资产VCore + 表的存储成本 TB
3.计算数据价值： 使用人数、使用频率、数据服务的应用数、重要性（老板看）第二：治理优化
1.数据上线容易，下线难，没有下线机制 》》 数据服务化，统一对外服务接口，建立数据和应用的血缘关系，方便任务下线
2.低价值的数据消耗了大量机器资源 》》 评估是否可以下线或者放到非高峰期运行第三：治理效果评估
1.节省的计算资源+存储资源换算成多少钱4.6 数据服务化
4.6.1 存在的问题
为了保障数据的查询速度，需要引入中间存储
- 数据量小：MySQL
- 低延时：Redis
- 数据两大：HBase
- 多维分析，数据量大：GreenPlum
不同中间存储提供的 API 接口不一致，导致使用复杂度提高。维护困难。主要存在以下问题
- 中间存储中的数据无法复用
- API接口根据应用高度定制化，也无法复用
- 暴露数据
- 多应用共同访问数据容易发生拥堵
- 数据和应用的链路关系是断的，不确定数据的下游应用在哪里，无法下线
- 数据部门的字段更变导致数据应用变更
4.6.2 解决方案
提供统一的 API 接口，为开发者和应用者屏蔽不同的中间存储和底层数据源，解决了一下问题
- 数据服务暴露的不是数据，而是统一的接口
- 数据服务具备限流功能，使得不同应用共享数据成为可能
- 中间存储中的数据可以复用
- 数据服务维护了数据应用和数据中台表的链路关系，建立全链路血缘
- 数据服务解耦了数据应用和数据，方便修改，数据服务的映射关系即可实现字段变更
具体的实施方案为：
- 接口规范化定义
- 数据网关
- 链路关系的维护
- 数据交付提供多样中间存储
- 逻辑模型
- API 接口
- API 测试
数据服务实现了数据中台模型和数据应用的全链路打通，解决了任务异常影响分析和数据下线不知道影 =响哪些应用的难题；
基于相同主键的物理模型，可以构建逻辑模型，逻辑模型解决了数据复用的难题，提高了接口模型的发布效率；
