数据中台及数据仓库设计

数据中台建设深度好文

1：数据中台介绍

1.1：概述

数据是从业务系统产生的，而业务系统也需要数据分析的结果，那么是否可以把业务系统的数据存储和计算能力抽离，由单独的数据处理平台提供存储和计算能力？这样不仅可以简化业务系统的复杂性，还可以让各个系统采用更合适的技术，专注做本身擅长的事。这个专用的数据处理平台即数据中台。
数据中台通过将企业的数据变成数据资产，并提供数据能力组件和运行机制，形成聚合数据接入、集成、清洗加工、建模处理、挖掘分析，并以共享服务的方式将数据提供给业务端使用，从而与业务产生联动，而后结合业务系统的数据生产能力，最终构建数据生产>消费>再生的闭环，通过这样持续使用数据、产生智能、反哺业务从而实现数据变现的系统和机制。

数据中台的本质就是“数据仓库+数据服务中间件”，面对的是底层的数据库和上层的不同系统。

1.2：架构

主题：即高层次的互不折叠的数据分类，用于管理其下一级的业务对象，企业中一般是某类可用于分析的对象
数据标准：基于公司或者一具体的业务线制定的需要公司共同遵守的属性层数据含义和业务规则，描述了公司对某个数据的共同理解，这些理解确定后就应该作为标准在企业内被共同遵守。
数据仓库-ODS层：存储源数据的简单落地，比如kafak/sparkstring/日志埋点/sqoop
数据仓库-DWI层：又称为数据整合层，DWI层是对多个源系统数据的整合，清洗，基于数据建模三范式建模（个人理解属于从数据治理得来的数据）。
数据仓库-DWR层：数据报告层，基于数据维度，和DWI层数据粒度基本保持一致。该层包括事实表，维度表（对应有维度），其都是属于某一主题的概念。
数据仓库-DM层：数据集市层，面向VUE/BI等展示层
数据质量：指定的对数据好坏评判的标准，比如手机号的校验，邮箱校验，字段长度，类型，非空，正则表达式等的判断
维度：从不同角度看待分析数据，比如从不同地域，不同年龄等都属不同的维度。一般在sql中的group by 中进行分析。
指标：基于数据建模中的事实表和维度表提取的一部分属性和度量，和多维模型中的最细数据粒度一致。
数据加工：包括对数据的指标加工，标签加工，宽表加工，数据探索等
数据标签：标签是一种数据特征。比如用户的年龄、性别、地区等。这些特征在数据中具有一定的通用性和价值。数据标签存储一般在数据库中是单独一列。数据标签介于数据仓库和数据集市中间。数据标签简介

2：数据中台建设

数据中台的建设总体可使用以下几个步骤，有问题的地方欢迎指正。

2.1：业务和数据资产调研

数据化的基础是信息化或者信息化所产生的数据。这些数据本就有数据化的含义，同时这些数据又会进入数据化框架体系，继续通过计算产出更多的数据和更大的价值。所以，对企业数据资源的盘点是数据化建设的前提和基础。一份完整、准确的数据资源是后续数据化建设的有力保障。

2.2：数据架构设计

数据中台的数据架构设计是基于需求调研阶段的业务需求、数据情况，完成数据中台概要设计工作。数据架构设计主要包含 OneModel 、OneID 和 OneService 。

2.2.1：技术选型

数据存储：HDFS，HBase，hive等

数据计算：MapReduce, Spark, Flink

交互式查询：Impala, Presto,phoenix（提供sql查询hive和hbase）

在线实时分析：ClickHouse，Kylin，ES，Druid，Kudu等

资源调度：YARN，Mesos，Kubernetes

任务调度：crontab，Azakaban，AirFlow等

关系型数据库：MySQL、Oracle

非关系型数据库

键值数据库：Redis
列式数据库：Hbase
文档数据库：MongoDB
图形数据库：Neo4J

…

现阶段企业数据应用现状：

数据量小的使用 MySQL：Hive数仓，Spark计算引擎的计算结果导出到 MySQL

数据量大的使用 HBase + ElasticSearch：解决海量数据中的低延迟高效查询

需要多维分析的可能需要 ClickHouse，Kylin，Greenplum：提供现在分析能力

实时性要求高的需要用到 Redis：提供高性能单点查询能力

2.2.2：数据仓库建设

数据仓库OLAP适合联机分析处理。
ods层：ods是数据经简单处理后直接存储的原始数据
dwi层：一般从源数据层提取一部分属性组成新的表。属性可能来自多个表或者一个表或者再加入一些自己的标识的属性如创建时间，创建人等信息组成的新表。但是其实时表和历史表都属于dwi层。
dwr层：dwr层是基于dwi层从一些维度或者度量提出的表。比如从时间度量上，dwi层的表可分为分钟表，小时表，天表等粒度，都属于是dwr层
dws层：一般是根据dwi层进行特定业务的汇总统计信息，比如日产量，月产量等信息

比较全的数据仓库介绍

1：主题设计

数据划分主题进行管理：表的命名，字段的命名等规范统一，做到见名知义

• 数仓分层-业务主题域(比如不同领域部门)-业务过程-基础信息-分区规则
  指标一致，不存在二义性：提供全局数据字典确保意义一致。

• 数据模型复用：推荐采用分层的设计方式，通常包括：ODS 原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS应用数据层 / DM数据集市层，DIM 公共维度层。

• 数据完善：数据中台尽可能的覆盖到所有业务过程，用户和系统的一切行为都被记录下来永久保存OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。资产和成本的

• 数据分层：数据模型以维度建模理论为基础，建设数据中台的公共数据层。一般将数据模型划分为操作数据层（Operational Data Store，ODS）、通用数据模型层（Common Data Model，CDM）和应用数据层（Application Data Service，ADS）。

2：数仓建模

一般情况，在进行设计时一般会分开成三个步骤：概念模型阶段 > 逻辑模型阶段 > 物理模型阶段，每个步骤负责各自部分，层层递进，最终一步步完成完整设计。

各用一句话总结来说就是

概念模型
找出你需要设计的系统、业务层面的核心实体以及实体间的关系。

逻辑模型
进一步整理完善系统实体、实体间的关系，以及确定实体的属性。

物理模型
确定之前模型中的实体、关系、属性如何映射到具体实现，物理数据模型的目标是指定如何用具体的数据库模式来实现逻辑数据模型，以及真正的保存数据。

概念模型：此阶段主要是明确主体拥有的属性，和各个主体间的关系，一般使用ER模型进行划分。

逻辑建模：就是对业务对事实进行实体化，明确其属性的过程。主要有星形模型和雪花模型和星座模型等设计过程。
数据库逻辑建模包括三范式建模和维度建模。
1：三范式建模

• n1：字段不可再拆分，具有原子性；
• n2：有主键，非主键字段必须依赖主键；
• n3：非主键字段不能相互依赖，和主键直接相关。

2：维度建模

• 星形模型：一个事实表，多个维度表和事实表关联
• 雪花模型：一个事实表，维度表和其他维度表存在管理，存在二级维度表
• 星座模型：多个事实表间存在共享维度表

各个实体间的关系都有哪些约束
每个实体都有哪些业务属性以及属性的业务类型
星型模式是一种多维的数据关系,它由一个事实表(Fact Table)和一组维表(Dimens ion Table)
组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键

物理模型：主要是生成建表的脚本、数据库进行一些优化和数仓的维护工作

物理模型阶段需要做的事情比较多

确定业务属性如何转换成数据库形式：类型，字段集，表
确定实体和实体间的关系如何转换成数据库的表，主键，外键
确定数据库表字段的其他数据库特性：默认值，是否非空，触发器
确定数据库表中除业务需要之外需要冗余的字段以及是否需要其他数据库表

最后生成DDL语句进行建表。

3：数据设计

3.1：数据采集

根据实时和离线数据一般使用各个业务系统、flume、sqoop、logstash、日志埋点等进行数据采集，此阶段获取的数据就是ODS原始数据

3.2：数据加工

数据加工包括建立数据标准、数据加工、数据标签管理、数据建模、数据ETL等流程最终到数据仓库。

制定数据标准：对数据来源，含义，类型，取值范围等进行确定
数仓建模：在数采设计阶段已完成。
数据ETL加工：ETL确定是用flink还是spark等进行开发工作清洗数据
数据建模：对数据的不同维度等数据进行提取和汇总等过程，通常包括：ODS 原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS应用数据层 / DM数据集市层，DIM 公共维度层。
数据治理：对数据质量的管理体系

2.2.3：数据应用层/数据集市

数据建模加工完后各个数据供前端使用。
​ 在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。该层主要面向BI报表，更多面向营销推荐，用户画像，AI决策分析，风险评估等。