数据中台技术体系

目录

• 前缀
  • 数仓建模体系
  • 数据中台产生背景
  • 数据中台主要解决的问题
  • 数据中台如何解决
  • 什么样的企业适合构建数据中台？
• 技术架构
  • 元数据中心
  • 元数据技术
  • 元数据中心架构设计
• 指标管理
• 模型设计
• 数据质量
  • 如何衡量数据质量
• 成本控制
  • 成本陷阱
  • 如何解决
• 数据服务
  • 解决方案
• IAAS

前缀

常用数据收集和迁移：
flume，canal，sqoop，datax，waterdrop等
常用任务调度：
azkaban，oozie，dophinscheduler，airflow
常用部署运维：
cloudera manager, ambari，SaltStack等
常用监控告警：
Alertmanager+Prometheus，zabbix，openfalcon等
常用安全和权限：
Kerberos，ranger等
数据存储：
HDFS，HBase，Kudu等
数据计算：
MapReduce, Spark, Flink
交互式查询：
Impala, Presto
在线实时分析：
ClickHouse，Kylin，Doris，Druid，Kudu等
资源调度：
YARN，Mesos，Kubernetes

所谓的大数据中台就是封装上述技术，实现平台化的一站式数据集成、计算、存储、数据治理、数据透出使用的一站式平台。

最新的概念： 像数据治理，数据地图，元数据管理，数据资产，数据血缘，数据湖等更新潮的概念。
所谓的大数据中台其实就是使用上述技术，把这些数据做成服务化，WEB方式配置化解决问题。
具体演绎流程如下：
数据库阶段 ---> 传统数仓 ---> 大数据平台 ----> 大数据中台

数仓建模体系

Bill Inmon 提出的建模方法自顶向下（顶指数据的来源，在传统数据仓库中，就是各个业务数据
库），基于业务中各个实体以及实体之间的关系，构建数据仓库。比如之前数仓中讲到的：商品
表，用户表，交易表，两个实体表，一个关系表。 从数据源开始构建，适用于应用场景比较固定的业务，比如金融领域。冗余数据少

Ralph Kimball 建模与 Bill Inmon 正好相反，是一种自底向上的模型设计方法，从数据分析的需求
出发，拆分维度和事实。那么用户、商品就是维度，库存、用户账户余额是事实。适合于变化速度比较快的业务，比如互联网。

数据中台产生背景

1. 传统数仓模型，烟囱式开发，效率低。而且产生各种数据指标不一致问题
2. 数据开发周期太长，一个数据开发需求甚至要一周时间
3. 机器开销太大， 每个月账单成指数级增长。
   数据中台建设好之后，主要解决以下问题： 烟囱式开发 数据孤岛 数据割裂
   数据中台是指通过数据技术对海量数据进行采集、计算、存储和处理，同时统一标准和口径，形成全域级、可复用的数据资产中心和数据存储能力中心，形成大数据资产层，进而为客户提供高效的服务。
   数据中台吸收了传统数据仓库、数据湖、大数据平台的优势，同时又解决了数据共享的难题，通过数据应用，实现数据价值的落地。
   阿里大中台、小前台模式
   
   阿里数据和业务中台双中台结构
   

数据中台主要解决的问题

• 指标口径不一致：主要原因：业务口径不一致、计算逻辑不一致、数据来源不一致。要实现一致，就务必确保对同一个指标，只有一个业务口径，只加工一次，数据来源必须相同。
• 数据重复建设，需求响应时间长：解决数据复用的问题，要确保相同数据只加工一次，实现数据的共享。
• 取数效率低：面对几千甚至上万张表，运营，开发或者分析师想要快速找到想要的数据，以及做到精准理解这些数据意义，都非常的困难。所以需要构建一个全局的企业数据资产目录，实现数据地图的功能，快速找到数据
• 数据质量差：没有数据稽核任务，运营不相信数据。存储数据链路，及时发现数据质量问题，并恢复数据。
• 数据成本线性增长：大企业烟囱式开发，导致一个企业拥有很多小数仓，不同数仓可能开发相同任务，导致资源浪费，而且也做不到淘汰低价值数据任务。所以解决方案的核心：解决数据重复建设，打通数据孤岛。

数据中台如何解决

OneData 就是所有数据只加工一次。
OneService 数据即服务，强调数据中台中的数据应该是通过 API 接口的方式被访问。
API 接口一方面对应用开发屏蔽了底层数据存储，使用统一标准的 API 接口查询数据，提高了数据接入的速度。另一方面，对于数据开发，提高了数据应用的管理效率，建立了表到应用的链路关系。

oneservice 如何实现？

• 屏蔽底层数据来源的不同：不同的数据来源，统一的数据出口

• 实现包括权限，日志，监控等管控能力的数据网关：权限控制，统计分析，流量控制，成本控制等

• 给用户屏蔽底层的物理数据模型，提供数据逻辑模型：动态拼接多张相同粒度的数据结构，简化接入复杂度

• 提供无状态的，高性能和稳定可靠的数据服务

• 由一个团队，负责所有指标的管控，明确每个指标的业务口径，数据来源和计算逻辑，消除指标二义性，确保任何一个指标的意义和计算逻辑，在全公司都只有一个唯一的相同口径。

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

• 对于非技术人员，数据中台提供了可视化的取数平台。你只需要选取指标、通过获取指标系统中每个指标的可分析维度，然后勾选，添加筛选过滤条件，点击查询，就可以获取数据。

• 构建了企业数据地图，你可以很方便地检索有哪些数据，它们在哪些表中，又关联了哪些指标和维度

• 数据只能加工一次，强调数据的复用性

• 成本控制，研发了一个数据成本治理系统，从应用维度、表维度、任务的维度、文件的维度进行全面的治理。比如，某个任务产出的数据指标，在过去 30 天内都没有被访问过，所以这个任务是没有作用没有意义的
  自助取数平台可以参考如下设计：
  

什么样的企业适合构建数据中台？

数据中台的构建需要非常大的投入：一方面数据中台的建设离不开系统支撑，研发系统需要投入大量的人力，而这些系统是否能够匹配中台建设的需求，还需要持续打磨。
建设数据中台需要考虑的因素如下：

1. 企业是否有大量的数据应用场景：所以当你的企业有较多数据应用的场景时（一般有 3 个以上就可以考虑）
2. 经过了快速的信息化建设，企业存在较多的业务数据的孤岛，就是存在多个业务小数仓
3. 当你的团队正在面临效率、质量和成本的苦恼时
4. 当你所在的企业面临经营困难，需要通过数据实现精益运营，提高企业的运营效率的时候
5. 企业规模也是必须要考虑的一个因素，数据中台因为投入大，收益偏长线，所以更适合业务相对稳
   定的大公司，并不适合初创型的小公司。

技术架构

中台要想做成的关键：

• 一把手牵头，全员共识；
• 总体规划，分步实施；
• 找准切入点，解决具体业务问题

元数据中心

元数据划为三类：数据字典、数据血缘和数据特征。
数据字典：描述的是数据的结构信息：表结构信息，主要包括像表名，字段名称、类型和注释，表的数
据产出任务，表和字段的权限等
数据血缘：指一个表是直接通过哪些表加工而来。数据血缘一般会帮我们做影响分析和故障溯源。比如
说有一天，你的老板看到某个指标的数据违反常识，让你去排查这个指标计算是否正确，你首先需要找
到这个指标所在的表，然后顺着这个表的上游表逐个去排查校验数据，才能找到异常数据的根源。
数据特征：主要是指数据的属性信息：存储空间大小，数仓分层，访问热度，主题分类，关联指标等

元数据技术

开源的有 Netflix 的 Metacat、Apache 的 Atlas；
商业化的产品有 Cloudera Navigator。
关于开源的这两款产品，Metacat 擅长管理数据字典，Atlas 擅长管理数据血缘。
Metacat 介绍：https://github.com/Netflix/metacat，最大的优势：多数据源的可扩展架构
只需要定义一个 connector就能接入各种存储，对于元数据没有通过WEB平台维护，而是通过直连数据源的方式，不会存在保存2份元数据

Apache Atlas 介绍：http://atlas.apache.org/
血缘采集，一般可以通过三种方式：

• 通过静态解析 SQL，获得输入表和输出表； 不准确
• 通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表； 比较理想 Atlas 采取的方案
• 通过任务日志解析的方式，获取执行后的 SQL 输入表和输出表。血缘是执行后产生，确保是准确的，但是时效性比较差
  对于 Hive 计算引擎，Atlas 通过 Hook 方式，实时地捕捉任务执行计划，获取输入表和输出表，推送给
  Kafka，由一个 Ingest 模块负责将血缘写入 JanusGraph 图数据库中。然后通过 API 的方式，基于图查
  询引擎，获取血缘关系。对于 Spark，Atlas 提供了 Listener 的实现方式。
  

元数据中心架构设计

功能模块分为 数据血缘、数据字典和数据特征

元数据中心统一对外提供了 API 访问接口，数据传输、数据地图、数据服务等其他的子系统都可以通过
API 接口获取元数据。另外 Ranger 可以基于元数据中心提供的 API 接口，获取标签对应的表，然后根
据标签更新表对应的权限，实现基于标签的权限控制。

元数据设计要点：

• 元数据中心设计上必须注意扩展性，能够支持多个数据源，所以宜采用集成型的设计方式。
• 数据血缘需要支持字段级别的血缘，否则会影响溯源的范围和准确性。
• 数据地图提供了一站式的数据发现服务，解决了检索数据，理解数据的“找数据的需求”。

指标管理

定义不一致，口径不一致，计算逻辑就不一致。所以构建数据中台，需要提供全局一致的指标口径，输
出完备统一的指标字典。
指标管理常见问题：

1. 相同指标名称，口径不一致：比如 "新用户销售额，7日UV"
2. 相同口径，指标名称不一样：比如 "优惠券抵扣金额" 和 "优惠券消费金额"
3. 不同限定词，描述相同事实过程的俩个指标，相同事实部分口径不一致
4. 指标口径描述不清晰：比如 "关单金额"
5. 指标命名难于理解：比如 "转化率" 和 "ROI"
6. 指标数据来源和计算逻辑不清晰
   如何构建指标系统：

• 提供一个易于维护的规范标准化指标管理系统，具备查询，增删等功能。
• 数据中台团队必须要有一个专门负责指标管理的人或者小组（一般不超过 3 个人），最好是数据产品经理来负责，如果你的公司没有这个职位，也可以让分析师承担。
• 提供一个完备的指标创建流程：提交指标需求，需求评审，模型设计和数据开发，验证，上线，应用接入
• 不同的两个指标描述的相同业务过程中的相同事实部分口径不一致，是指标梳理过程中最常见的问题，需要通过拆分原子指标和派生指标的方式解决。

模型设计

就是分层设计好，避免每次计算都从 ODS层开始拖数计算。
构建可复用模型的标准：数据模型可复用，完善且规范
统计明细层完善度：统计 DWD 层表被跨层引用次数即可，次数越多，证明完善度越好
DWS/ADS/DM 层完善度：能满足多少查询需求。

数据质量

根源：

• 业务系统变更，包括表结构变更（加减字段），源系统环境变更（扩容 agent没有采集日志），源数据格式异常（JSON 格式改了）；
• 数据开发 Bug + 数据开发任务变更：忘了修改数据源（测试线上环境混用），写死数据分区，数据格式异常
• 物理资源不足：YARN 上多租户争抢资源导致数据延迟产出
• 基础设施不稳定：NameNode 高可用失效导致数据读写功能异常
  如何提高数据质量？
• 添加稽核校验任务：确保数据的完整性、一致性和准确性
• 建立全链路监控：可以基于血缘关系建立全链路数据质量监控。
• 通过智能预警，确保任务按时产出：延迟产出，异常任务等立即报警
• 通过应用的重要性区分数据等级，加快恢复速度

如何衡量数据质量

一切皆可量化

• 某个时间点以前核心任务的产出完成比，超过规定时间，没有完成产出则稽核校验失效
• 基于稽核规则，计算表级别的质量分数。对于低于质量分数的表，分发到响应责任人进行改进。
• 需要立即介入的报警次数。超过规定次数的需要立即介入
• 数据产品 SLA。数据应用中的所有指标在规定时间内产出。如果没有，则计算不可用时间，不可用时间越短，证明SLA越好

成本控制

支撑好业务，获得业务部门的认可
精简架构，控制成本，为公司省钱

成本陷阱

数据上线容易，下线难，什么没有下线机制。
低价值的数据应用消耗了大量的机器资源。
烟囱式的开发模式导致数据加工重复
数据倾斜导致资源分配利用不均衡
未设置数据生命周期，导致过期数据长期占用磁盘资源。
调度周期设置不合理，未形成闲忙搭配得当。
任务指定资源参数配置不当
数据为压缩存储

如何解决

1. 全局资产盘点 基于数据血缘建立全链路的数据资产视图。
   1.1 一张表的成本 = 每个加工任务的计算资源成本 * m + 上有依赖表的存储资源成本 * n
   1.2 数据价值计算：给使用人数，使用频率，数据应用数，老板等因素加权计算
2. 发现问题
   2.1 持续产生成本，但是已经没有使用的末端数据（“没有使用”一般指 30 天内没有访问）：没有使用，却消耗了资源
   2.2 数据应用价值很低，成本却很高，这些数据应用上游链路上的所有相关数据：低价值产出
   2.3 高峰期高消耗的数据：高成本的数据
3. 治理优化
   3.1 对于第一类问题，应该对表进行下线
   3.2 对于第二类问题，我们需要按照应用粒度评估应用是否还有存在的必要，如果没有，则删除。
   3.3 对于第三类问题，主要是针对高消耗的数据，又具体分为产出数据的任务高消耗和数据存储高消耗，分配到非高峰期运行即可。
4. 治理效果评估
   4.1 最简单粗暴的标准：省了多少钱
   4.2 下线了多少任务和数据；这些任务每日消耗了多少资源；数据占用了多少存储空间。
   4.3 将上述节省资源换算成钱，这就是你为公司省的钱

数据服务

主要解决问题：
1、数据接入效率低
之前需要对接各种存储， 主要是存储特性决定的， 现在是直接对接服务， 服务封装了各种存储。
2、数据服务解决的问题
存储数据复用
服务复用
数据服务具备稳定性，限流等，最终实现共享数据的能力

3、不确定数据应用在哪里
数据服务链接了数据和应用的链路
下线数据的话能很快知道这些数据在那些服务中使用

4、数据部门的字段更变导致数据应用变更
底层表变更修改逻辑模型即可，不必再报错

解决方案

接口规范化定义
数据网关
链路关系的维护
数据交付
提供多样中间存储
逻辑模型
API 接口
API 测试
基于相同主键的物理模型，可以构建逻辑模型，逻辑模型解决了数据复用的难题，提高了接口模型的发布效率；

IAAS

安装 Amabari 和 HDP 的 CentOS7 集群; 主要解决Hadoop system 不好维护的问题。不管是 Hadoop V1 或者 V2
的安装，又或者 Spark/YARN 等的集成，都不是几行简单的命令可以完成的，而是需要手工修改很多的
集群配置，这进一步增加了业务开发者的学习和使用难度。有了 Ambari，这些都不再是难题。