数仓学习基础
定义:数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合，用于支持管理人员的决策。
一、数仓的基础概念
1. 数仓的四大特征
1.数据仓库的数据是面向主题的
2. 数据仓库的数据是集成的
3. 数据仓库的数据是非易失的
4. 数据仓库的数据是随时间不断变化的
2. 数仓的历史
2.1 传统数仓
特点：
a) 基于RDBMS
b) 数据量较小
c) 所有的数据存储在RDBMS中，计算引擎就是相应的DB Server (数据库服务器，如：mysql→mariadb, oracle, DB2, sql server等等)
d) 随着数据量的急剧增加，基于传统的RDBMS也会搭建分布式集群，如：mycat。但是，有临界值，管理的rdbms的台数有限制，不能
无限制地扩充。
2.2 大数据数仓
特点：
a) 基于HDFS，通过Hive进行分析
b) 数据量庞大（数据量没有极限值，随着数据量的膨胀可以任意地扩充节点）
c) 使用Hive数仓的工具框架对hdfs上存储的海量的数据进行分析，计算，底层会将hql语句转换成MapReduce,MapReduce运行在Hadoop分布式集群中的。
d)心得：新框架的诞生是为了解决现实的需求，是为了解决时下的一些痛点。
3. 大数据数仓的其他的理论
3.1 软件项目开发的流程：
①立项
②需求分析
③设计
a)概要设计
b)详细设计
④编码
⑤测试：
a)单元测试
b)集成测试
⑥上线
a)试运行
b)正式交付（若是外包项目，客户给软件公司结清尾款）
心得：后续的阶段基于紧挨着的前一个阶段，不能跨越。在每个阶段都有成果物（如：需求分析说明书）。
3.2 数仓项目开发的流程：
①业务建模 ~ 类似于：需求分析
②领域建模 ~ 类似于：设计部分的概要设计
③逻辑建模 ~ 类似于：设计部分的详细设计（db名，表名，表中的字段，字段的类型，表之间的关联关系）
④物理建模 ~ 类似于：编码阶段，如何具体实施
心得：后续的建模阶段基于前一个建模阶段，不能跨越。
3.3 建模阶段具体的划分：
逻辑建模：
RDBMS(业务db，存储业务数据)，经常使用到的建模工具是PD (Power designer)
物理建模：
书写建库，建表语句。
如： RDBMS（如：mysql）, 业务db， 数据(从数据部门拿取脱敏之后的数据，一般选用模拟的数据)。
数仓项目实施时，具体的阶段划分（都是hive数仓部分的）：
①ODS层 （original data store, 原始数据存储层）
a)通过flume采集到hfds相应目录下的日志文件
b)通过sqoop导入到hdfs的一些业务db中的数据
c)创建ODS层的db, 以及db下相应的表（与rdbms源库中的表名类似，表字段一般同名，类型修改成hive表中的类型）
②DWD层 （data warehouse detail, 数仓细节层）
a) 建库，建表，表中的数据来自于ods层相应表中的数据
b) 表一般是经过轻度汇总之后的结果 （将一天中用户访问的所有日志信息聚合起来）
③DWS层（data warehouse service，数仓服务层）
a) 建库，建表，表中的数据来自于dwd层相应表中的数据
b) 表一般是经过粗粒度汇总之后的结果 （将最近一个月中用户访问的所有日志信息聚合起来）
④DM层 （data market，数据集市层）
a) 建库，建表，表中的数据来自于dwd,dws层相应表中的数据 。
b) 表是关于特定主题最终统计后的结果，表中的每个字段就是统计指标。
3.4 OLTP, OLAP解释
OLTP(online transaction process): 在线事务处理，主要适用于传统的RDBMS。 对时效性要求挺高的场合。如：网站连接的后台的DB，一般是RDBMS。
OLAP(online anylysis process): 连接分析处理， 主要适用于对hdfs上存储的海量的数据进行分析处理，一般指大数据数仓领域。适用于对时效性要求不高的场合。但是，将实时数仓除外。
3.5 逻辑建模的模型有哪些
①星型模型。
有一张事实表，周围环绕着一系列的维度表组合而成的表结构。
②雪花模型。
有一张事实表，周围环绕着一系列的维度表，维度表中复杂的字段通过其他的维度表进行详述，将这样组合而成的表结构。
③星座（星系）模型。
有多张事实表，每张事实表周围环绕着一系列的维度表，维度表又可以拥有子维度表，将这样组合而成的表结构。
注意：
a, 事实表(fact table)：用于记录事实上产生的数据，如：下单时，向后台的订单表中插入一条记录。那么，此时订单表就是一张事实表，用于记录某个用户下单这一动作。
tb_user:
id name graduation_id address_id age xxx
--------------------------------------------------------------------
1 杰克逊 1 2 20 xxx
b,维度表（dimention table）：用来对事实表中的一些字段进行扩展说明的，一般，在事实表中针对于语义丰富的字段，一个字段在事实表中是一个外键，指向的是相应
维度表中的主键。
tb_graduation维度表：
graduation_id graduation_name
——————————————
1 小学
2 中学
3 高中
4 专科
5 本科
tb_address籍贯维度表：
address_id country province city county zipCode
______________________________________________________________________________
1 中国 北京市 北京市 昌平区 100027
2 中国 广东省 深圳市 宝安区 300027
c, 在真实的数仓项目中，星型模型和雪花模型使用得较多，星座模型使用得较少。
→ 星型模型的适用场景：
优势：
业务简单
效率高
缺点：
数据有冗余 （多余的，重复的，累赘的数据。）
→ 雪花模型的适用场景：
优势：
关系清晰
数据冗余少，甚至没有任何冗余
缺点：
业务比较复杂
效率较低
→ 星座模型的适用场景：
优势：
关系复杂的场合
数据量特别庞大
缺点：
可读性差，关系太复杂，查询的效率较低
数仓与数据库的区别
| 差异项 | 数据库 | 数据仓库 |
|---|---|---|
| 特征 | 操作处理 | 信息处理 |
| 面向 | 事务 | 分析 |
| 用户 | DBA、开发 | 经理、主管、分析人员 |
| 功能 | 日常操作 | 长期信息需求、决策支持 |
| DB设计 | 基于ER模型，面向应用 | 星形/雪花模型，面向主题 |
| 数据 | 当前的、最新的 | 历史的、跨时间维护 |
| 汇总 | 原始的、高度详细 | 汇总的、统一的 |
| 视图 | 详细、一般关系 | 汇总的、多维的 |
| 工作单元 | 短的、简单事务 | 复杂查询 |
| 访问 | 读/写 | 大多为读 |
| 关注 | 数据进入 | 信息输出 |
| 操作 | 主键索引操作 | 大量的磁盘扫描 |
| 用户数 | 数百到数亿 | 数百 |
| DB规模 | GB到TB | >=TB （PB） |
| 优先 | 高性能、高可用性 | 高灵活性 |
| 度量 | 事务吞吐量 | 查询吞吐量、响应时间 |
3.6 数据抽取,数据清洗,数据预加载
关于ETL:
①ETL是BI项目最重要的一个环节，通常情况下ETL会花掉整个项目的1/3的时间，ETL设计的好坏直接关接到BI项目的成败。
②ETL也是一个长期的过程，只有不断的发现问题并解决问题，才能使ETL运行效率更高，为项目后期开发提供准确的数据。
③ETL的设计分三部分：数据抽取、数据的清洗转换、数据的加载。在设计ETL的时候也是从这三部分出发。
a)数据的抽取是从各个不同的数据源抽取到ODS中(这个过程也可以做一些数据的清洗和转换)，在抽取的过程中需要挑选不同的抽取方法，尽可能的提高ETL的运行效率。
b)ETL三个部分中，花费时间最长的是T(清洗、转换)的部分，一般情况下这部分工作量是整个ETL的2/3。
c)数据的加载一般在数据清洗完了之后直接写入DW中去。
④ETL的实现有多种方法，常用的有三种：
a) 第一种是借助ETL工具如Oracle的OWB、SQL server 2000的DTS、SQL Server2005的SSIS服务、informatic等实现。etl可视化的工具有很多，如：kettle,canal等等
b) 第二种是SQL方式实现
c) 第三种是ETL工具和SQL相结合。
前两种方法各有优缺点， 借助工具可以快速的建立起ETL工程，屏蔽复杂的编码任务，提高速度，降低难度，但是欠缺灵活性。
SQL的方法优点是灵活，提高ETL运行效率，但是编码 复杂，对技术要求比较高。
第三种是综合了前面二种的优点，极大的提高ETL的开发速度和效率。
3.7 缓慢变化维数据处理
缓慢变化维：
①维度表里面的数据并非是始终不变的，总会随着时间发生变化。
②维度建模的数据仓库中，有一个概念叫Slowly Changing Dimensions，中文一般翻译成“缓慢变化维”，经常被简写为SCD。
③缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。
这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。
缓慢变化维的几种常见解决方法（注意：hive表也可以更新，也支持事务）
第一种方法，直接在原来维度的基础上进行更新,不会产生新的记录：
1） 更新前：
emp_rid(代理键) emp_id(自然键) emp_name position
101212 12345 Jack Developer
更新后：
emp_rid(代理键) emp_id(自然键) emp_name position
101212 12345 Jack Manager
第二种方法，不修改原有的数据，重新产生一条新的记录,这样就可以追溯所有的历史记录：
1） 更新前：
emp_rid(代理键) emp_id(自然键) emp_name position start_date end_date
101212 12345 Jack Developer 2010-2-5 2012-6-12
更新后：
emp_rid(代理键) emp_id(自然键) emp_name position start_date end_date
201245 12345 Jack Manager 2012-6-12
第三种方法，直接在原来维度的基础上进行更新,不会产生新的记录但是只会记录上一次的历史记录：
1） 更新前：
emp_rid(代理键) emp_id(自然键) emp_name position old_position
101212 12345 Jack Developer null
更新后：
emp_rid(代理键) emp_id(自然键) emp_name position old_position
101212 12345 Jack Manager Developer
3.8 处理缺失数据方式
缺失值的处理是很常规的操作，可以按照以下步骤进行：
①确定缺失值范围：对每个字段都计算其缺失值比例，然后按照缺失比例和字段重要性，分别制定策略。
②去除不需要的字段：这一步很简单，直接删掉即可，但强烈建议清洗每做一步都备份一下，或者在小规模数据上试验成功再处理全量数据，
不然删错了会追悔莫及(多说一句，写SQL的时候delete一定要配where!)。
③填充缺失内容：某些缺失值可以进行填充，方法有以下三种：
以业务知识或经验推测填充缺失值
以同一指标的计算结果(均值、中位数、众数等)填充缺失值
以不同指标的计算结果填充缺失值
前两种方法比较好理解。关于第三种方法，举个最简单的例子：年龄字段缺失，但是有身份证号，可以通过截取身份证号来获取年龄
④重新取数：如果某些指标非常重要又缺失率高，那就需要和取数人员或业务人员了解，是否有其他渠道可以取到相关数据。
3.9 星型模型和雪花模型
①星型模型：以一个事实表为中心，周围围绕多个维度表。
a)星型模是一种多维的数据关系，它由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。
b)强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。这也是我们在使用hive时，经常会看到一些大宽表的原因，
大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，
相对来说对OLAP的分析比较方便。
②当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。
a)雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，
这些被分解的表都连接到主维度表而不是事实表。
b)雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要join的表比较多所以其性能并不一定比星型模型高。
③星型模型和雪花模型的优劣对比：
属性 星型模型 雪花模型
————————————————————————
数据总量 多 少
可读性 容易 差
表个数 少 多
查询速度 快 慢
冗余度 高 低
对事实表的情况 增加宽度 字段比较少，冗余低
扩展性 差 好
④应用场景
a)星型模型的设计方式主要带来的好处是能够提升查询效率，因为生成的事实表已经经过预处理，主要的数据都在事实表里面，所以只要扫描实时表就能够进行大量的查询，
而不必进行大量的join，其次维表数据一般比较少，在join可直接放入内存进行join以提升效率，除此之外，星型模型的事实表可读性比较好，不用关联多个表就能获取大
部分核心信息，设计维护相对比较简答。
b)雪花模型的设计方式是比较符合数据库范式的理念，设计方式比较正规，数据冗余少，但在查询的时候可能需要join多张表从而导致查询效率下降，此外规范化操作在后
期维护比较复杂。
⑤总结
通过上面的对比，我们可以发现数据仓库大多数时候是比较适合使用星型模型构建底层数据Hive表，通过大量的冗余来提升查询效率，星型模型对OLAP的分析引擎支持比较友好，
这一点在Kylin中比较能体现。而雪花模型在关系型数据库中如MySQL，Oracle中非常常见，尤其像电商的数据库表。在数据仓库中雪花模型的应用场景比较少，但也不是没有，
所以在具体设计的时候，可以考虑是不是能结合两者的优点参与设计，以此达到设计的最优化目的。
3.10 数据集市
①是按照主题域组织的数据集合，用于支持部门级的决策。(数据集市层中表的每一个字段就是一个指标)
②数据集市的类型有两种：独立数据集市和从属数据集市。
a)独立数据集市集中于部门所关心的单一主题域，数据以部门为基础部署，不考虑企业级别的信息共享。
b)从属数据集市，数据来源于数据仓库，数据仓库里的数据经过整合、重构、汇总后传递给数据集市。
c)我们一般用聚合数据放入到数据集市中。
d)我们的入门案例，日统计数据和月统计数据和年统计数据放入dm层，因此我们的数据仓库的数据从源数据层（source）、
贴元层（ods、rds）、数仓层（dw~>dwd →data warehouse detail , dws →data warehouse service）、数据集市层（dm）、mysql报表展示。
3.11 数据粒度
①数据粒度，是指数据仓库中数据的细化和综合程度。
②根据数据粒度细化标准：细化程度越高，粒度越小；细化程度越低，粒度越大。
③分析了数据仓库中的粒度模型，在此基础上提出了一种估计数据仓库大小的方法。
④为了提高银行数据仓库的性能,合理地确定数据仓库中数据单元的详细程度和级别,给出了一种银行数据仓库中数据粒度划分的方法。
⑤分析了数据仓库中的粒度模型,介绍了数据粒度划分的策略,在此基础上提出了一种估计数据仓库大小的方法,进而在明确数据粒度划分原则的基础上,
提出了一种银行环境中数据粒度的划分。该划分方法有效的解决了银行数据仓库开发者面临的一个最重要的设计问题,使其设计和实现中的其余方面得以非常顺畅地进行。
⑥总结：
a）可以将数据看成是有粘性的沙粒,粒度小的沙粒比较细,粒度大的沙粒是由粒度小的沙粒粘起来的,即粒度高的数据是由粒度低的数据综合起来的.
b) 在数据仓库环境中,粒度是一个重要的设计问题,他影响到数据仓库的数据量和系统能回答的查询类型,粒度越小,细节程度越高,能回答查询就越多,但是存储的东西也就越多
3.12 数仓中的维度表
①维度表示你要对数据进行分析时所用的一个量。
②比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析. 这样的按某个标准分析就构成一个维度。
前面的示例就可以有两个维度：类型和区域。另外每个维度还可以有子维度（称为属性），例如类别可以有子类型，产品名等属性。下面是两个常见的维度表结构：
产品维度表：Prod_id, Product_Name, Category, Color, Size, Price
时间维度表：TimeKey, Season, Year, Month, Date
注意：
要搞清楚这些专业术语：维度表, 事实表, 数据分析, BI。
3.13 数仓中的事实表
事实表是数据聚合后依据某个维度生成的结果表。它的结构示例如下：
销售事实表：Prod_id(引用产品维度表), TimeKey(引用时间维度表), SalesAmount(销售总量，以货币计), Unit(销售量)
上面的这些表就是存在于数据仓库中的。从这里可以看出它有几个特点：
1. 维度表的冗余很大，主要是因为维度一般不大(相对于事实表来说的)，而维度表的冗余可以使事实表节省很多空间。
2. 事实表一般都很大，如果以普通方式查询的话，得到结果一般发的时间都不是我们可以接受的。所以它一般要进行一些特殊处理。
如SQL Server 2005就会对事实表进行如预生成处理等。
3. 维度表的主键一般都取整型值的标志列类型，这样也是为了节省事实表的存储空间
2616
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
