一、什么是数据仓库?
其实很多企业做数据仓库的时候,都忽略了数仓与BI、数据库的差异,只去搞底层数据,不去做数据服务和应用,其实就是把数据仓库给狭义化了。
其实数据仓库可以看成是BI的基础版本、数据库的升级版本,我们可以把公司里的数据都想象成一个个文件夹,数据库就是这一个个文件柜,这个文件柜存放着非常多的数据,无论这个数据是什么、或者是如何组织的。
而当我们的文件非常多、种类非常复杂的时候,我们的就想要寻找某个文件夹的时候,如果每个文件柜每个文件柜的去找,实际上是非常耗费成本的,因此我们不妨建立一个档案室,对不同的文件柜进行编号、归类、分组,方便我们快速定位数据源,这个档案室就是数据仓库。
所以这时候我们需要更为庞大的数据仓库,帮助我们去对多个数据源的数据库数据进行抓取,而抓取数据源的过程就可以理解为ETL的工作,这样去理解一个企业的数据架构就会简单很多。
因此数据仓库的本质,其实就是整合多个数据源的历史数据进行细粒度的、多维的分析,帮助高层管理者或者业务分析人员做出商业战略决策或商业报表。
这里面就涉及到了数据仓库的架构,简单来说数据仓库分为四个层次:
- ODS层:存放原始数据,直接加载原始日志、数据,数据保存原貌不做处理。
- DWD层:结构与粒度原始表保持一致,对ODS层数据进行清洗
- DWS层:以DWD为基础,进行轻度汇总
- ADS层:为各种统计报表提供数据
这里要注意数据仓库的架构当中,各个系统的元数据通过ETL同步到操作性数据仓库ODS中,对ODS数据进行面向主题域建模形成DW(数据仓库),DM是针对某一个业务领域建立模型,具体用户(决策层)查看DM生成的报表。
也就是说,我们所看到的数据不是直接从数据底层抽取的,相当于我们访问数据仓库的时候,是让图书管理员帮你找一个文件柜,那么怎么更高效低去找,就是数据仓库建设中很重要的一部分工作——数据建模,包括数据的存储模型、逻辑模型、概念模型等等。
二、数据仓库的建模方式
建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。
(1)数据仓库数据模型架构
数据仓库的数据模型的架构和数据仓库的整体架构是紧密关联在一起的,我们首先来了解一下整个数据仓库的数据模型应该包含的几个部分。从下图我们可以很清楚地看到,整个数据模型的架构分成5 大部分,每个部分其实都有其独特的功能。
从上图我们可以看出,整个数据仓库的数据模型可以分为大概5 大部分:
- 系统记录域:这部分是主要的数据仓库业务数据存储区,数据模型在这里保证了数据的一致性。
- 内部管理域:这部分主要存储数据仓库用于内部管理的元数据,数据模型在这里能够帮助进行统一的元数据的管理。
- 汇总域:这部分数据来自于系统记录域的汇总,数据模型在这里保证了分析域的主题分析的性能,满足了部分的报表查询。
- 分析域:这部分数据模型主要用于各个业务部分的具体的主题业务分析。这部分数据模型可以单独存储在相应的数据集市中。
- 反馈域:可选项,这部分数据模型主要用于相应前端的反馈数据,数据仓库可以视业务的需要设置这一区域。
通过对整个数据仓库模型的数据区域的划分,我们可以了解到,一个好的数据模型,不仅仅是对业务进行抽象划分,而且对实现技术也进行具体的指导,它应该涵盖了从业务到实现技术的各个部分。
(2)数据仓库建模阶段划分
我们前面介绍了数据仓库模型的几个层次,下面我们讲一下,针对这几个层次的不同阶段的数据建模的工作的主要内容:
从上图我们可以清楚地看出,数据仓库的数据建模大致分为四个阶段:
- 业务建模,这部分建模工作,主要包含划分整个单位的业务等等
- 领域概念建模,这部分得建模工作,主要包含抽取关键业务概念,分组,细化分组概念,形成完整的领域概念模型
- 逻辑建模,这部分的建模工作,主要包含业务概念实体化,事件实体化,说明实体化
- 物理建模
从我们上面对数据仓库的数据建模阶段的各个阶段的划分,我们能够了解到整个数据仓库建模的主要工作和工作量,希望能够对我们在实际的项目建设能够有所帮助。
(3)数据仓库建模方法
- 范式建模法
范式建模法其实是我们在构建数据模型常用的一个方法,该方法的主要由Inmon 所提倡,主要解决关系型数据库得数据存储,利用的一种技术层面上的方法。目前,我们在关系型数据库中的建模方法,大部分采用的是三范式建模法。
范式建模法的最大优点就是从关系型数据库的角度出发,结合了业务系统的数据模型,能够比较方便的实现数据仓库的建模。但其缺点也是明显的,由于建模方法限定在关系型数据库之上,在某些时候反而限制了整个数据仓库模型的灵活性,性能等,特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时,需要进行一定的变通才能满足相应的需求。
- 维度建模法
维度建模法,Kimball 最先提出这一概念。其最简单的描述就是,按照事实表,维表来构建数据仓库,数据集市。这种方法的最被人广泛知晓的名字就是星型模式(Star-schema)。
上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。通过这些预处理,能够极大的提升数据仓库的处理能力。特别是针对3NF 的建模方法,星型模式在性能上占据明显的优势
- 实体建模法
上图表述的是一个抽象的含义,如果我们描述一个简单的事实:“小明开车去学校上学”。以这个业务事实为例,我们可以把“小明”,“学校”看成是一个实体,“上学”描述的是一个业务过程,我们在这里可以抽象为一个具体“事件”,而“开车去”则可以看成是事件“上学”的一个说明。
由于实体建模法,能够很轻松的实现业务模型的划分,因此,在业务建模阶段和领域概念建模阶段,实体建模法有着广泛的应用。从笔者的经验来看,再没有现成的行业模型的情况下,我们可以采用实体建模的方法,和客户一起理清整个业务的模型,进行领域概念模型的划分,抽象出具体的业务概念,结合客户的使用特点,完全可以创建出一个符合自己需要的数据仓库模型来。
三、数据仓库的建设流程
1、模板调研:
信息调研是逻辑模型设计、物 理模型设计以及数据映射的基 础,在模型设计阶段贯穿始终决定了数据仓库的质量。
这一步我们主要的工作是找出实际存在的业务问题,领导的KPI问题,现在没有提出未来可能出现的问题,这是数据仓库建立的核心所在。方法就是调研,包括业务人员、领导方不断沟通,不断调研,输出问题清单。
2、主题域模型设计:主题域的界定、每个主题主实体的准入原 则、数据处理规范、核心的分类决定了数 据模型的主体框架,保持主体框架的稳定 性确保了仓库的稳定性。
3、概念模型设计:详细的实体属性的设计,大量数据分析业务规则验证的工作,模型设计的同时完成到逻辑 数据模型的简要数据映射
4、逻辑模型数据设计:提供与生产一致版本的数据结构,准 确完善的数据字典,符合分析需求的 样本数据;并能对样本数据分析中的 问题进行及时准确的回复跟踪
5、物理存储模型设计:协调仓库数据的相关方达成共 识,既包容当前数据满足现有 需求,又具备一定的前瞻性便 于扩展,还必须具备操作性
6、模型优化设计回顾:模型设计是多人协同的团队工作,是一项持续不断地扩展演化完善的 过程,遵循模型设计规范、沿用一致的模型客户化方式是至关重要的。
数据在刚刚开始的时候,还是小体量,就好比创业公司,还不足够引起人们的注意。
但是当数据体量上来了,就好像变成了独角兽。
10个人去银行产生的数据,还能勉强搞定,但是成百上千个呢?甚至更多呢?你会说,银行有oracle这种强大的数据库啊,但是,传统数据库目前来说,只能做到处理、读写、删除一些需求,更多的还是存储数据的用途。
把这些数据聚合在一起分析,数据库做不到。
于是,人们在现有的数据库基础上,对数据进行加工,也就是常说的ETL:抽取、转换、加载。
然后,数据仓库就生成了,里面有各种不同的数据,分成不同的业务包,都是为了数据分析,用于BI和报表上面。
要建设数仓的话,我推荐大家把这本书下载看看,非常经典
数仓这个概念吧,有了很久了,里面存了很多不同类型的数据,就好比是千万张Excel表格,都在这个仓库里,你要的时候可以查询。
数据仓库是解决方案,真正落地的时候,还要依托于工具平台。
工具平台包括两种,一种是存储系统如hdfs,计算系统如hive/mr/spark/flink等,是数据仓库的基础,在此基础上进行数据的建设与使用(主要说的是依赖自建的集群进行数据建设,其它的情况后续再说)。
而本文说的是第二种,数据仓库的辅助系统:数据服务平台。
数据服务平台:数据建设,数据使用的辅助与后盾。
对于外部用户,如分析师,项目团队来说,数据可视化/元数据是重要的,通过这两个系统,可以很容易的知道数据的基本情况以及统计结果,可以进行多种分析。
对于内部用户,如数据团队来说,调度系统/质量监控是必不可少的,调度系统可以让任务准时地完成,质量监控可以保证提前发现数据问题。
下面分别对这四个系统进行说明。
1. 数据可视化/报表/数据查询 —— 数据的服务员。
用到的工具是FineReport和FineBI
数据的意义是知晓历史,查看现状,规划未来,前提是我们能”看到数据”。能被看到,能被理解的数据才有意义。用合适的方法把数据展示出来,让用户轻松理解,是一个比较困难的事情。
不同的数据,需要用不同的方法,比如看数据,用表格;看趋势,用折线图;看分布,用饼图;看流量变化,用漏斗图;看分布,用热力图等等。合适的表现形式,才能让人更好地从数据中获取知识。
举一个真实的例子,在一家公司时,只做数据建设,没有好好地做数据可视化,然后我们给高管做汇报的时候,在命令行敲命令,得到一个黑底白字的表格,尴尬至极。
汇报之后,我们就立刻组建了数据可视化的团队。
分析师,数据PM,是使用数据的用户,而他们往往没有技术能力,无法直接使用数据。同时,在离线/实时两种数据场景中,需要使用比如mysql/hive/kylin/druid/clickhouse/es等等工具,无疑更增加了用户的使用成本,并且工具是发展的,随时可能引入新的工具,难不成需要用户随时学习新工具的用法么?
当然不应该这样,所以需要一个统一的系统,能够展示报表数据、图表分析,能让用户在一个界面轻易地查多个平台甚至跨平台的数据。
常用的工具就是BI系统,比如帆软的FineBI平台。一方面对接经整合过的数仓数据,另一方面在前端展示报表、面向高管的驾驶舱、让数据用户自主分析。
没有好的数据查询系统,就无法服务好需求方。常说的”一站式数据服务平台”用户最直观地看到的,通常就是这类。
2. 元数据 —— 数据的解说员。
元数据,是描述数据的数据,通过元数据可以了解数据的基本情况和使用方法等。
包含数据的基本情况(数据层级,作用,建表语句,字段,存储位置等),数据信息(数据类型,数据规范化逻辑,枚举值列举,数值盒图,数据示例等),数据增长信息(新增条数,存储消耗),数据血统(数据流转路径)等。
理想的场景中,当一个新的主题建设出来,只要给一份元数据,用户就能清晰的知道数据的来源,逻辑,样例,以及使用方法,而不用一一宣讲。
3. 数据质量 —— 忠实的观察员。
及时发现数据波动,协助查找原因。数据波动,有时是由于数据异常导致的(整个数据链路中,原始数据,数据收集,数据计算都可能出错,所以数据出错是无法避免的)。
当然多数时候都是正常的波动,但是还是要尽职的观察,随时发现数据波动,提前找到波动的原因,主动把数据问题抛出来,防止小错积累成大错。
数据计算
- 自动多维分析,找出指标变化波动大的维度与变化情况。
数据转移
- 数据在多个数据源之间流转过程中,有无数据变化。数据条数,数据内容。
报表数据
- 多个报表包含相同维度,从总量/相同维度明细两个方面对比相同的指标。
- 通过多方面的自动检查监控,可以很好地了解数据的健康情况。例行检查,给出数据质量报告,保证做到”好数据,用得放心”。
4. 调度系统 —— 勤劳的操作员。
保证任务的稳定执行。众多计算逻辑,包括hql,Java程序,python程序,spark程序,需要在一定条件下顺序执行,可能是时间驱动:每天3点开始执行;可能是条件驱动:上游任务都执行完再进行当前步骤。
当然实际上往往是两种方法并存。在这个需求背景下,调度系统就产生了。调度系统不仅能做到最基本的版本管理控制,控制任务按条件执行,对于数据系统来说,数据的修改往往伴随着一系列下游的任务执行,那么就需要有级连筛选执行的能力。
另外,对任务的执行情况需要有监控,及早发现包括执行失败,产出延迟等任务异常情况,以便及时应对。
小结
这四个工具是按照用户感知的强弱来排列的,都不是数据建设/使用中”必须”的,没有它们,依然可以做,但是为了让数据更好的使用,它们是相辅相承,不可或缺的重要组成部分。
原创文章,作者:奋斗,如若转载,请注明出处:https://blog.ytso.com/205593.html