高质量数据库建模系列课程<1> PPT & 讲义 - 高质量建模的重大意义

浏览: 5104

说在前面的话:

从2016-01-18开始正式起航,我已经录制了2个小时的课程,课程地址:http://www.hellobi.com/course/54

进度有点慢,但好歹算是在前进,我自己后面也会加快速度。

到今天为止,一共有669人参与了该课程。今天有听众问我有没有课堂笔记。

其实我平时都是这么录课的:

1、先做PPT

2、写脚本

3、对着脚本录制课程

因为和平时讲课感觉完全不同,平时讲课可以顺嘴胡说,说错了其实也无伤大雅,而录制视频稍微错一点或者中间有卡壳的现象就觉得特别别扭,没有办法我只能先把要说的话写下来,这里就满足希望能够了解课堂笔记详情的朋友的要求,把PPT以及对应的脚本贴在这里,以方便大家查看。


从今天开始,我们将一起学习高质量数据建模的系列课程. 本节课是整个系列课程的开篇,为大家概述数据建模的基本过程。第一节课数据建模概述分为两个课时,首先我会介绍数据模型的概念和意义, 然后再介绍高质量数据建模的基本流程。

 

在课程开始之前,我想讲一下我做这套课程的初衷。为什么把这套课程叫做《高质量数据建模》呢?首先简单介绍一下自己的背景,我是一个数据仓库的架构师,在这个领域工作了15年,接触过大大小小的数据库系统不下几百个,遇到过各式各样的设计问题。而国内的数据库设计中,最普遍的问题就是什么呢?就是在数据库设计的过程中,有很多数据建模工程师由于没有一个好的设计方法论来指导,因此没有养成好的设计习惯,造成数据库系统很难可持续的健康发展。设计的数据库表,缺少清晰的定义,缺少规范的命名规则,或者没有遵循数据库的设计准则,在系统上线之初还可以勉强运行,但随着时间的推移,需求不断的变化,以及设计工程师的不断更换,由于缺乏高质量建模的基础,数据库中存在大量的数据冗余,数据库表的变化没有妥善的管理,因此带来了大量的数据不一致的问题。经年累月以后,很多表和字段没人知道是什么含义以及如何使用,或者被胡乱使用。造成系统升级清理优化都异常困难,而数据质量一塌糊涂,无法与其他系统做数据交换、数据整合,最后只能推倒重做,而新设计的库表再继续着同样的问题。

 

那么如果能有一套切实可行的方法来指导数据库建模,这种问题就会大大的减少。因此,我这里总结了这些年来读过的数据库设计的经典书籍并结合实际项目中的真实应用,开发出这套课程,也希望大家能够从中获得帮助。

首先让我们来了解一下数据模型的概念和意义。

这在一课时里面,分为四个部分。

数据时代演化,我们一起来回顾数据库发展的历史。

接下来的DIKW,也就是(数据,信息,知识,智慧)之间的关联关系以及在数据模型中我们需要关注的部分。

第三部分我会简单介绍一下数据模型的概念。

最后一个部分,是建设高质量数据模型的重大意义。

在我们这个时代,数据是无处不在的。诸如票据、表单这类的应用,早在几十年前就有了广泛的应用。我这里贴了两张图,分别是Google和亚马逊云计算的电子账单,在现代企业里,电子账单已经是企业非常常见日常的数据应用。而最早出现的这类数据应用都是企业级的第一线业务操作层面的应用。

后来,经理层级需要用于决策支持的应用变得越来越多,比如用来反应公司运营状况的分析报告,财务报表之类的应用。而这类的数据应用的表现形式就更加的丰富多样,图文并茂的表现形式比从前单一的表格更加直观。

从进入新世纪以来,互联网得到了爆炸式的发展。以电子商务为例,像阿里巴巴、亚马逊这种电商巨头每天会产生亿级别的电子交易数据。当然还有搜索引擎,比如谷歌百度;还有腾讯这类企业,产生的数据也呈几何级数的增长。到这个阶段,核心数据还是以文字、数字这种很单纯的形式存在,我们称之为结构化数据。而在电子商务时代已经开始用到大量图片和一些短视频,尽管这些还不是构成系统的核心数据。


最近10年,互联网进入web2.0时代,如国外的Facebook, Twitter等社交网络应用以及国内的微博,人人,微信等应用使数据规模进一步膨胀。并且渗透到我们生活的每个时刻每个角落。而数据的格式,也更加丰富,相比传统的企业的电子账单以及电子表格这类以文字、数字等为主结构化的数据,Web2.0时代以内容为王,海量的图片,视频等非结构化数据开始成为系统数据核心的一部分。

而非互联网行业,数据的应用也在不断发展和变化。我这里秀的两张图片,第一张是迈克尔乔丹时代的数据,在几乎20多年前NBA,通过人工统计已经能够计算出球员的投篮次数,投篮命中率,平均得分,篮板,助攻等反应球员水平的信息。第二张图,是当今NBA的霸主勒布朗詹姆斯在热火队时的一张投篮统计热点图。从这张图上我们可以看到,勒布朗詹姆斯在球场各个位置的投篮的次数、命中率、效率等情况以非常直观的图形化的方式一览无遗。和迈克尔乔丹时代相比,数据分析更加精细化以及自动化,这张图是通过对比赛录像的视频解析并进一步深度分析制作而成的。也就是说,从非结构化的视频数据,解析提炼成结构化数据,再进行分析的结果。

 

而现在,随着移动互联、物联网的飞速发展,世界范围各个领域,数据的规模、数据的种类、数据的格式都发生着巨大的变化,数据比以往更加无处不在。

那么,问题来了,这些数据都存在哪?

前面我们提到了,数据无处不在,那么它们都放在哪儿呢?可以说绝大多数的数据都保存在数据库中。这里我们看一下数据库的发展和变化。

在上个世纪70年代,图灵奖获得者艾德拉考特奠定了关系型数据库理论基础,然后在80年代,关系型数据库得到了蓬勃的发展,Oracle,DB2,Sybase,MS SQL Server, Informix这些优秀的商用数据库产品陆续诞生。

 

几年以后,关系型数据库又产生另外一个新的阵营,那就是开源数据库。我们注意到MySQL和PostgreSQL这两个最著名的开源数据库都诞生于上世纪90年代中期,这两个数据库从此不断茁壮成长。现在他们和商用数据库的差距也变得越来越小,而MySQL已经成为世界上最流行的数据库,几乎成为互联网企业的标配产品。

而随着关系型数据库的不断发展,越来越多的分析型需求开始产生,而数据仓库的概念和思想在上世纪90年代兴起并不断完善,而传统的关系型数据库开始增加了大量的为了提高大规模查询性能的特性,比如物化视图,集簇索引等等。并且进一步衍生出为了满足这类需求的全新的数据库品类。就是为了数据仓库的需求而生的数据库。

 

这些数据库各有千秋,其中Teradata一直都是数据仓库领域的霸主,以完美的并行计算(也就是MPP)著称,SybaseIQ采用列存的模式存放数据,并且采用专利性索引技术,极大的减少磁盘IO以提高查询性能,其他产品也各有特色,比如SAP HANA是内存式数据库,Netezza是FPGA硬件加速以及并行计算,GreenPlum也是以并行计算的模式提高查询性能。这里需要注意的是,这一类的数据库虽然是面向数据仓库而设计的,但仍然是关系型数据库。

而到了互联网时代的各类应用,对多并发要求极高以及对无限扩展能力的需求,并且对数据一致性要求又不像传统的在线交易系统那么高。而传统的关系型数据库已经没有办法满足这类需求。因此根据不同的需求,又产生了四类应用于不同场景的数据库。这类数据库已经不再是传统的关系型数据库,因此被命名为NOSQL数据库。这里的NOSQL不是“no SQL”的意思,而是Not Only SQL的意思。

分为以Redis为代表的键值数据库,Hbase、Cassandra为代表的列存数据库,MongoDB这一类为存储BSON这类非结构数据的文档式数据库;以及Neo4j这类存储图关系的数据库。这些数据库都诞生于近10年。NOSQL的百家争鸣给特殊的数据需求的提供了更丰富的选择。

 

讲了这么多数据的应用以及数据库的进化,那么问题来了,无论采用哪种数据库,这些数据库都需要合理的摆放到数据库中,那么这些数据是如何摆放在这些数据库里?这就是本套课程的核心,高质量数据建模。



由于我们这个课是讲关系型数据库建模的,那我们来看看在NOSQL数据库迅速发展的背景下,关系型数据库所占的份额是多少呢?会不会我讲这些东西以后越来越用不上了呢?看下面这个图,2016年1月份调查的结果,排名前十的数据库里面有7个是关系型数据库,而这7个库的总分占前十比例呢,在2016年的1月份,为89.6%,2015年的12月份是89.5%,而2015年1月份也就是1年前,是88.2%,也就是说这一年以来关系型数据库所占的比例呢一直都稳定在90%左右,并且不但下降,反倒有一点点上升,因此啊,NOSQL DB实际上来讲和关系型数据库是并列存在的,只是说有一些特殊需求,在关系型数据库里面不方便实现,被挪到NOSQL DB中去了。而关系型数据库仍然占绝对主导的地位,那这课我讲起来也放心了。我也希望未来我能把NOSQL的独特的建模方式也添加到我这个系列课程里面来,当下我们还是聚焦在关系型数据库建模上。

 

另外一个题外话,这个DB排名的Score是怎么来的啊?这个其实也是大数据的应用。

它从Google的搜索结果的大小,搜索的次数,以及在知名的IT社区,像stack overflow,这种网站上抓取的词汇出现的频度,工作相关网站如linkedin,以及社交网络twritter上出现的词汇的次数,综合起来计算的分数。虽然这个不是oracle这类数据库的装机的数量,但也很客观的反应出来了每种数据库的流行程度。

DIKW,在我们介绍数据建模之前,需要重点介绍一下这个经典的金字塔模型。D代表Data数据,I代表Information信息,K代表Knowledge知识,W代表Wisdom智慧。其中我们整天挂在嘴边的数据和信息,他们有什么区别?在这里举例说明一下,

首先什么是数据?我们看到,“1990-12-12”和“汤姆克鲁斯”这两个就是数据,看起来第一个数据像是个日期,第二个数据像是人名。那么他们真正的含义是什么呢?

 

什么是信息?出生日期:1990-12-12,最喜欢的演员:汤姆克鲁斯。那么什么是信息呢?增加了上下文的数据就是信息。也就是我们给数据增加了标题,那么数据就具有了含义。这里我给出的场景是,假设你的女朋友出生日期是1990-12-12,然后她最喜欢的演员是汤姆克鲁斯。

 

什么是知识?比如你去查日历,发现日历上写着2015-12-12是周六,也就是你的女友这个周末过生日,并且你也知道新上的大片《碟中谍5》由汤姆克鲁斯主演。

 

那么什么是智慧呢?就是你根据如上你获得的各种信息知识,做出智慧的决定:本周末为你的女朋友庆生,并且一起去看电影碟中谍5。

今天我们这里重点关注的是数据和信息。我们把用于描述数据的数据叫做元数据。信息就等于元数据+数据。从这张片子我们可以看到,单纯从数据本身,我们是猜不出含义的,而正是给数据增加了上下文描述,也就是元数据,才使数据具有意义。

那么,这和数据建模有什么关系呢?数据模型其实就是为了装载数据,而用元数据搭建起来的框子。这里给出的定义是:数据模型是将数据元素以标准化的模式组织起来,用来模拟现实世界的信息框架蓝图。而数据建模就是建设数据模型的过程。

 

那么数据模型有哪些要求呢?

第一,     要直观的模拟真实世界

第二,     要容易被人理解

第三,     便于计算实现。






作为Data Modeler,我们需要牢记于心的是,数据模型是整个数据应用的基石,可以说牵一发而动全身。底层数据模型的小小改动,会带来下游数据应用的极大变化。举一个例子,假设我们在构建一个企业级数据仓库,而该数据仓库下游接入10个Data Mart。在数据仓库层某公用主数据表发生重大变动,比如增加一个Column作为联合主键,在数据仓库层的改动是分分钟的事。但它引发的连锁反应呢?假设下游10个Data Mart中平均20张报表受到影响,那么这次改动引发的连锁反应为:

1.  10个Data Mart的表结构的变动

2.  10个Data Mart中对应表的ETL程序

3.  50*10张报表对应的程序

 每个Data Mart平均接入50张报表

 

我这里一再提到,高质量数据建模,那么相对的,低质量数据建模有哪些问题呢?Steve Hoberman的《Data Model Scorecard》一书中详细罗列了低质量建模的十宗罪

1.  没有准确的捕获到需求

这个属于数据建模最大的问题。通常由于需求调研不完备,需求理解不充分,项目前期缺乏足够的沟通,以及数据调研准备不足、后期测试不充分等原因引起。在系统真正使用时,发现有些需求功能无法满足,造成表结构的大幅调整。

 举例一个简单的例子,某集团公司有30个分公司和子公司,以一个公司为试点部署一套系统,而其中需要设计一张员工表,该表的设置为Employee 员工编号为主键,而在上线推广时发现问题,就是该集团公司其中有几个分公司的HR系统由于历史原因,员工编号与其他公司不是同一套系统,会造成员工编号存在重复的现象,这样就不得不修改主键,以及后面使用到该表的程序都需要大幅修改。这只是一个简单的例子,类似这种例子比比皆是。

 

2.  数据模型不完整

数据模型不完整分为两种情况,一种是设计时对需求把握不准确,造成数据模型缺少一些相关的表,无法完全覆盖需求,这个其实就是上面的例子1。还有一种情况是元数据不完整,我们这里强调的是这个。比如,对于column的constraints的限制,例如参照完整性的定义,比如是否为空。再比如某个Column的default值,是否有设置。另外就是表的描述,字段含义的描述等信息,是否提供。你很难想象下游系统去理解一个完全没有表定义,字段含义定义的有多痛苦。

 

3.  各层模型与其扮演角色不匹配

数据模型分为概念模型,逻辑模型和物理模型,每一层的模型的使命不同。概念模型是为了确定范围以及奠定基础,逻辑模型是为了厘清数据之间的关系并且勾勒理想状态下的数据结构,物理模型是为了性能,安全以及开发的方便构建的适应真实情况的模型,每一层的目的均不相同,很多data modeler不做概念模型和逻辑模型,直接一步到位到物理模型,或者每层的结构没有遵从该层设计的本意。

 

 4.  数据库结构不合理

这个就好比,你画一个房子的设计图,每个房间都得有门,这一类设计的基本常识。比如,一个表通常都得有主键,主键又一定不能为空,之类。相同的两个字段,在不同表中需要保持一致,如column name, 字段长度等等。

 

5.  抽象化不够,造成模型不灵活;又或过于抽象化,带来程序开发的困难

这个部分很重要,一个数据模型的是否能够承受未来的变化,很大程度上都取决于抽象化的程度。这个有点像动物的分类,门纲目科属种,无论飞禽走兽都可以抽象称为动物,而动物中又分脊索动物门,软体动物门等,在脊索动物门下又可以分为哺乳纲,哺乳纲又分草食目肉食目杂食目。每一类都有向上的抽象,所涵盖范围都更为广泛。数据模型也是一样的道理,至于建到门纲目科属种哪一层,实在取决于当下的需求以及未来可能的扩展。

 

 6.  没有或者不遵循命名规范

这个我们见的很多了,老外的项目这方面就好很多,国内的项目千奇百怪,用汉语拼音命名的都比比皆是,这里我就不举例子了,未来会有单独的大篇幅的课程讲命名规范。

 

7.  缺少数据模型的定义和描述

这个覆盖率可能超过90%,我接触过的很多项目都没有数据模型或者数据模型和真实数据库里面的内容就是俩东西,字段的含义表的含义基本靠猜,如果恰好数据模型又犯了6的错误,更是猜无可猜。

 

8.  数据模型可读性差

嗯,这个有意思,见过直接用DDL管理模型的,也见过用Excel管理的,还见过用Word管理的。没有ER图的,数据字典基本为空的,这种例子比比皆是。

 

9.  元数据与数据不匹配

这个问题也很常见,比如表/字段乱起名字,再比如最开始某表/某字段具备一种含义,而开发过程中发现用这表/字段还能干点别的类似的事,然后为了从前的程序不修改,表名和字段名也不改了,直接应用。比如,原来的表是客户,起名叫CUSTOMER, 里面记录CUSTOMER ID,Name,地址,电话等等,然后发现有的时候,我们的供应商需要的字段差不多,本来应该建个表叫VENDOR,结果为了图省事直接用CUSTOMER表,并且模型里面也不加解释,之类。

 

10. 数据模型与企业标准不一致

这个问题是企业信息管理存在的普遍问题,也是哪怕是很多好的Data Modeler也犯的错误,就是以项目视角出发,按照自己的习惯进行模型设计。而企业,(指甲方),在这方面通常也没有标准化的流程和政策来控制,因此造成整个企业都是各个项目有各个项目的标准,但缺乏企业级的标准,这也是数据质量问题的根源之一。

由于低质量的数据模型的原因,会给企业带来哪些影响呢?

1.  就是大量修改和重做

尤其是我们提到的没有准确捕获到需求的这种错误。

2.  重复建设

这个指的是,由于低质量的数据模型,造成系统很难可持续的发展,当需要添加新功能时,很难在原有系统基础上添加,只能重做。

3.  知识丢失

模型文档不完备,比如前面提到的缺乏定义之类的问题。这些知识都当时封存在Data Modeler的脑子里,有个经典的段子:三个月之内只有我知道,三个月之后只有上帝知道。而数据仓库项目又经常是经年累月的长期的过程,项目里面的人来的来走的走,知识没法传承。

4.  模型难以理解,下游开发困难

假设你弄一套千八百张表的数据库,然后还不给说明书,你让下游的Data Mart的设计者,报表等应用的设计者怎么进行开发?

5.  高成本

上面说的这些,都会带来高成本,包括项目周期的延长,包括人员的培训,包括开发的周期,错误的增加等等。

6.  数据质量低下

同时呢,这也是数据质量低下的主要原因之一,比如你数据仓库这一层模型做的质量低下,你就很难保证下游的Data Mart会正确的使用。也就难保证基于其的报表的数据是正确的。

7.  新业务无法展开

比如你新建一个数据应用,基于主数据的,而主数据的数据质量一塌糊涂,是不是你这个新应用就没法做起来啊。

等等,影响的方面其实非常多,我这边只是随便列几个。


那么建设高质量数据模型的意义何在呢?这张图就非常生动的表述了,一个高质量数据模型对于一个企业的现实意义。

我们可以看到,数据模型是整个系统以及数据的基础。而高质量的数据模型能够带来哪些好处呢?从系统的视角出发,它可以更方便的系统集成以及提供更简化的接口。

 

我这里举一个真实的例子:我曾经接触过一个数据库系统,系统里面有上百个表,最大的表每天要产生大约10W条记录,这样每年就要产生10W * 365 = 三千六百万的数据,而这个系统在设计的时候,在每个表上都没有时间戳。当我要做一个数据仓库,希望能从这个系统里面获取数据的时候,我不得不用全表比对的方式或者非时间戳字段的方式来获取增量数据,这样就给数据抽取工作带来非常多的困难。如果这个系统在设计的时候,考虑到将来某一天,有数据仓库系统或者其他系统要从该系统取数的需求,而增加了时间戳标记,就会给后面的数据应用节约大量的时间和成本。也就更方便的做系统集成,以及采用更简化的接口。

 

从数据的角度来看,高质量的数据建模能够减少数据冗余,提高数据质量,并且能够灵活的容纳新添加的数据.按照三范式建模的数据模型会尽可能的减少数据冗余。 减少数据冗余的好处时,只保存一份数据,减少了数据在不同表里存在多版本的情况也就减少了数据的不一致的风险。而在数据仓库的应用中,对于多系统集成,并且上游系统是逐渐添加入数据仓库的的需求,采用Data Vault模式建模会极大减少多系统数据集成时带来的兼容性风险。这些建模方式在后面的课程里都会有详细的讲解。

 

由系统和数据两个层面的效能的提高,都会从商务层面帮助企业降低成本,减少风险并赢得更多的商业机会。




到这呢,我们的第一节课就算讲完了,虽然讲的都是一些大道理,没有实操的干货,但我也希望大家能有所收获。在这里,我再次强调:

数据模型是所有数据相关应用的基石,牵一发而动全身,你的模型做的越准确,越精确,相关文档描述越详细,你可能会花很多时间,但你会为别人节省几十倍甚至几百倍的时间。

 

而数据仓库的Data Modeler,每次去分析上游系统的数据情况,都得烧香拜佛,希望他们能提供完备的元数据。然后当上游系统存在我前面提到低质量模型问题时,光顾着骂上游系统模型做的垃圾了,但自己也不吸取教育,让下游系统的人的也这么骂你。因此我就想起来杜牧这句话了,“秦人不暇自哀而后人哀之, 后人哀之而不鉴之, 亦使后人复哀后人也”。

 

好,本课就讲到这,我们下节课再见。

推荐 11
本文由 BAO胖子 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

9 个评论

这样看着视频来学习,舒服多来。
非常好,尤其是不规范的需要借鉴
做的相当好,这样学习很舒服 。赞一个,持续关注中
胖子老师功力了得,稍微看了两节课,觉得经验不是一般的丰富~\(≧▽≦)/~
太厉害了,胖子老师,写本书吧。回头再弄个案例课程最好了。
和天善搞一起培训班课程,以项目为驱动的,理论+实践 来一期。
厉害
完全解决了wo看视频边截图的动作,棒棒哒
看了视频 ,又看了文字,印象加深了不少,谢谢老师

要回复文章请先登录注册