一、数据仓库工具箱

1、主要内容

结合业务场景，阐述
1、维度建模以及事实表的基本及相关概念。
2、根据业务主题的总线矩阵图，梳理业务流程、指标以及对应的维度。
3、关于事实表的阐述。
4、企业层面的BI应用的框架以及组件，和实现所需的内容。

2、进阶内容

1、如何建立缓慢变化维表。
2、如何处理桥接表。
3、总结常用主题应用的维度建模知识。
4、kimball DW/BI设计以及实现方式。
5、总结在数仓建设中需要避免的常见错误。

3、重点内容介绍

3.1 维度模型设计的4个步骤

1、选择业务过程
2、声明粒度
3、确定维度
4、确定事实
通过以上4个步骤，就可以画出总线矩阵图。
纵列标记过程、粒度以及事实。横排标记维度。
举个订单管理过程的总线矩阵行图的例子。

	日期	客户	产品	代理销售	交易	仓库	运货商
报价	×	×	×	×	×
下订单	×	×	×	×	×
运输至客户	×	×	×	×	×	×	×
开具货运发票	×	×	×	×	×	×	×
接收付款	×	×		×
客户退货	×	×	×	×	×	×	×

3.2 关于事实表的内容以及比较

3.2.1 关于事实表的具体内容介绍包括：

可加事实、半可加事实、不可加事实。
可加事实，就是指标正常求和之后，就是符合事实的总数。
半可加事实，就是表达事实当前状态的一个值。如温度、当前存款数量、当前库存水平等。
不可加事实，就是分母不同的百分比等。

3.2.2 关于记录事实的表：

事务事实表、周期快照事实表、累计快照事实表、无事务的事实表。
事务事实表又可以被分为单事务事实表和多事务事实表。多事务事实表一般是多个事情，维度一致。
周期快照事实表，就是每个一段时间或者一个时间，记录一次当前事务的状态。
累计快照事实表，就是一行数据记录一个事务的各个关键事务节点的时间以及对应的指标。一般记录流水线事件以及表中会存在多个时间点。
无事实的事实表，不记录指标。会记录某个状态所有可能发生的事件。然后事件发生了记为1，不发生记为0，于是就将不发生的事实记录了下来。

3.3 关于维表的设计

3.3.1 维度与事实表的键

3.3.2 一致性维度

3.3.3 缓慢变化维度

3.3.4 维度的属性层次

3.3.5 客户维度

1）静止维度：地址、姓名、日期、客户层次、客户行为
2）维度内容变化：通过类型2的缓慢变化维度来处理
3）复杂的客户行为以及客户关系：通过桥接表来处理。
4）用户点击相关维度：网页、事件、会话、推荐维度。

3.3.5 需要避免的常见错误

3.4 kimball DW/BI 设计以及实现

1、企业层面的BI应用的框架以及组件，和实现所需的内容。
2、RDBMS与hadoop的不同。

二、阿里大数据之路

1、内容摘要

主要讲了阿里的数据采集、数据整理、数据应用以及数据价值管理的全链路及平台的搭建与使用过程。

2、数据技术篇

2.1 数据采集

主要是日志采集，分为浏览器页面采集以及APP客户端数据采集。
APP又分为两种，纯APP内容以及有H5页面嵌入的APP。
H5基于浏览器页面的方式进行采集。纯APP基于SDK方式进行采集。
两种采集方式会互相跳转。
后续附上数据处理全链路图。

2.2 数据同步

采集好的数据，分为离线和实时，数据流转处理器包括flume,kafka,clickhouse，同步到mysql等库。
然后mysql库的数据通过同步系统流转到其他库。

2.3 数据开发

2.3.1 离线数据开发

离线数主要基于平台开发。平台具有数据同步、脚本研发、测试、运维、数据管理、调度等多种功能。
此处注意maxcompute体系架构。

2.3.2 实时技术

实时技术注意书中提到的流式技术框架图。数据采集kafka,流式数据计算flink，数据存储、数据服务以及流式数据模型（事实表、维表的关联）以及高峰时段的测试。

2.4 数据服务

为了使得采集以及开发到的数据更高效地被整理和使用，建立了统一的数据服务层，OneService。这个平台需要关注它的组件的使用方式和场景。就是用户不需要关注数据是怎么采集到的，只需要关注可以获取的表字段以及字段含义。因为它对用户展示的是一张逻辑表。保证业务可以高效地应用数据。

2.5 数据挖掘

提高数据地纯度，挖掘数据内部信息。阿里创建数据挖掘算法平台以及挖掘数据中台。优点是通过简易的操作将常见的算法应用于自己的业务中，并且管理好特征集和结果集，沉淀代表性场景的方法论以及实操模板。

3、数据模型篇

3.1阿里数据整合及管理体系

选择以Kimball的维度建模为核心理念的模型方法论，构建阿里的公共层模型数据构架体系。
主要解决数据存储和计算的共享问题。指导方法是’OneData’,包括一致性的指标定义体系、模型设计方法体系以及配套工具。
大数据建设的核心方法论是：从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理、可追溯、可规避重复建设。
注意图9.1体系架构图

3.1.1 OneData规范定义

包括名词术语解释，指标体系组成基本原则，通过平台对命名进行限制，避免命名重复或者歧义，保证指标的一致性。
操作细节以及其他规则说明。

3.1.2 模型设计

遵循维度建模理论，将表数据模型分为3层，操作数据层，公共维度模型层以及应用数据层。其中公共数据层包括明细数据层以及汇总数据层。
注意：模型层次图
操作数据层数据增量或者全量同步，数据清洗。
在公共维度模型层，采用明细宽表，将维度退化至事实表中，减少数据扫描，且公共指标统一加工，建立逻辑汇总宽表，降低数据计算口径不统一的风险。
应用数据：个性化指标、复杂指标、大宽表集市，行转列等。
注意：模型架构图

3.1.3 基本原则

高内聚低耦合，核心模型支持常用的核心业务，扩展模型含有个性化字段。公共逻辑下沉以及单一，成本与性能的平衡。数据可回滚，多次运行结果不变。数据一致性。命名清晰以及可理解。

3.1.4 OneData实施过程

注意图9.11实施工作流
数据调研，业务和需求调研。
架构设计：数据域划分、构建总线矩阵。
规范定义
模型设计
总结

3.2 维度设计

3.2.1 维度设计基础

维度是事件发生的环境，维度的作用一般是查询约束、分类汇总以及排序。
维度使用主键约束其唯一性，代理键和自然键。自然键具有业务含义，比如Id。保证维度的唯一性。
主维表以及相关维表的关联关系。
关于维度属性的几点提示：
（1）尽可能生成丰富的维度属性
（2）尽可能多地给出包括一些富有意义的文字性描述。
（3）区分数值型属性和事实。
（4）尽量沉淀出通用的维度属性。
维度的层次结构
上卷和下钻。
在实际使用时，用维表的空间来换取简明性和查询性能。
具有部分相同的维度的属性可以进行交叉探查。

3.2.2 维度高级主题

3.2.2.1维度整合

命名规范统一。
字段类型统一。
公共代码及代码值统一。
业务含义相同的表的统一，垂直整合和水平整合，增加行和增加列的整合方式。

3.2.2.2水平拆分

拆分依据，维度不同分类的属性差异情况，如公共属性以及特殊子属性。
根据业务的关联程度进行拆分。

3.2.2.3 垂直拆分

根据来源表的产出时间，使用频率进行拆分。

3.2.2.4 历史归档

建议解析数据库binlog日志，采用数据库变更日志的方式，获取数据的方式是通过增量merge全量的方式获取最新的全量数据。使用增量日志删除标志，作为前台数据归档的标志。

3.2.3 维度变化

3.2.3.1 缓慢变化维

（1）重写维度值，不保留历史数据，商品不换自然键。
（2）插入新的维度行，保留历史数据，商品换新的自然键。
（3）添加维度列，旧类目，新类目。商品不换自然键。

3.2.3.2 快照维表的优化——极限存储

将快照维表改为历史拉链存储的底表。然后将底表做成全量存储，不影响下游用户的使用。

3.2.4 特殊维度

3.2.4.1 递归层次

（1）类目扁平化，类目回填。对于非平衡层次的结构，可以通过预留级别的方式来解决，但扩展性较差。
（2）桥接表，容易产生多对多的问题，不建议使用。

3.2.4.2 行为维度

行为维度可以分为，另一个维度的过去行为、快照事实表行为、分组事实行为维度、复杂逻辑事实行为维度。
处理方式：冗余至现有维表、单独加工维表。
原则：避免维度过快增长、避免耦合度过高。

3.2.4.3 多值维度

（1）降低事实表粒度
（2）采用多字段、多关联2-3次维表
（3）采用桥接表。桥接表同一个key，对应多个id。

3.2.4.4 多值属性

（1）k-v存储
（2）多值属性，多次关联维度表。
（3）维度主键发生变化，数据记录多。

3.2.4.5 杂项维度

以订单Id为主键，生成杂项维度或者直接退化至事实表中。

3.3 事实表的设计

3.3.1事实表基础

3.3.1.1事实表特性

事实表的基础，事实表获取业务过程的度量来表达业务过程，包含了引用维度和与业务相关的度量。事实表中一条记录所表达的业务细节程度被称为粒度。
事实一般分为可加的，半可加的（在某些维度可加）和不可加三种类型。
维度属性也可以存储到事实表中，这种存储到事实表中的维度列被称为退化维度。
事实表有三种类型，事务事实表，周期快照事实表，累计快照事实表。

3.3.1.2 事实表设计原则

原则1：尽可能包含所有与业务过程相关的事实。
原则2：只选择与业务过程相关的事实
原则3：分解不可加性事实为可加的组件
原则4：在选择维度和事实之前必须先声明粒度
原则5：在同一个事实表中不能有多种不同粒度的事实
原则6：事实的单位要保持一致
原则7：对事实的null要处理，建议用0填充
原则8：使用退化维度提高事实表的易用性。

3.3.1.3事实表设计方法

第一步：选择业务过程及确定事实表类型
第二步：声明粒度
第三步：确定维度
第四步：确定事实
第五步：冗余维度（退化维度），方便上卷

3.3.2 事务事实表

3.3.2.1 事务事实表的种类

事实表设计方法如3.3.1.3所示。单事务事实表和多事务事实表的比较。
父子事实可以将父订单的总额计入事务表，同时通过分摊父订单的金额将所有业务过程的度量全部代入淘宝交易的事务事实表中。将父子事实同时冗余到事务表中。

3.3.2.2 事实的设计准则

事实完整性、事实一致性、事实可加性。

3.3.3 周期快照事实表

快照事实表在确定的间隔内对实体的度量进行抽样，这样就可以很容易地研究实体的度量值，而不需要聚集长期的事务历史。可以通过事务事实表进行汇总

3.3.3.1 特性

用快照采样状态。（我写的历年制理赔表就是周期快照表）
快照粒度，采用周期以及在什么维度下将被采样。
密度与稀疏性，即使状态不发生变更，也会被记录一行数据。因此周期性快照表是稠密的。
半可加性，可以计算周期内平均值，以及在除了时间之外的维度具有可加性。

3.3.3.2 注意事项

事务与快照成对设计。
附加事实，一般会附加上一个采样周期的状态度量。
周期与日期度量，历史至今，自然年至今等度量，分别做表。

3.3.4 累积快照事实表

累积快照事实表用于研究事物之间间隔的需求。设计方法如3.3.1.3所示。

3.3.4.1 特点

数据不断更新，多业务日期。

3.3.4.2 特殊处理

1、非线性过程
（1）业务过程统一
（2）针对业务关键里程碑构建全面的流程。
（3）循环流程的处理。
2、多源过程
主要考虑事实表的粒度问题。
3、业务过程取舍
选取关键的里程碑。

3.3.4.3 物理实现

1、全量表形式，存储了大量不会更新的历史数据。
2、全量表变化形式，根据业务生命周期，全量存储近200天数据，200天之前的数据归档。
3、以实体业务的结束时间分区。每天存放当天结束的数据，设计一个时间非常大的分区，存放截至当前未结束的数据。

3.3.5 三种事实表的比较

P227
为什么大部分表都有Update_time，按道理来说事务事实表和周期快照表都不应该有Update_time了。

3.3.6 无事实的事实表

不包含事实或度量的事实表称为‘无事实的事实表’
1、记录事件的发生，发生了记为1。
2、条件、范围或者资格类的、记录维度多对多之间的关系。

3.3.7 聚集型事实表

3.3.7.1 聚集的基本原则

一致性、避免单一表设计、聚集粒度关心要查询的维度。

3.3.7.2 聚集的基本步骤

1、确定聚集维度
2、确定一致性上钻。
3、确定聚集事实。

3.3.7.3 阿里公共汇总层

1、基本原则
数据共用性、不跨数据域、区分统计周期。
3、交易汇总表设计
聚集的粒度越细，记录的条数越多，就会越接近原始明细粒度的模型。

3.3.7.4 聚集补充说明

1、聚集是不跨越事实的
如果要跨越事实，先融合事实表，然后再生成聚集表。
2、聚集带来的问题
增加ETL维护的难度。一些维度的变化，会需要重新聚集数据。

4、数据管理篇

4.1 元数据

4.1.1元数据概述

4.1.1.1元数据的定义

元数据打通了源数据、数据仓库、数据应用，记录了数据从产生至消费的全过程。
元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。
元数据包括技术元数据以及业务元数据。
技术元数据包括；表的建表信息，作业运行信息，数据同步、计算任务、任务调度等信息、以及数据质量和运维相关的元数据。
业务元数据包括，OneData元数据，如维度及属性、业务过程、指标等的规范化定义，用于更好地管理和使用数据。
数据应用元数据，如数据报表、数据产品等地配置和运行元数据。就是数据报表用了哪些表以及报表运行时长，查看报表地Pv，uv。

4.1.1.2 统一元数据体系建设

统一元数据建设体系思路如图12.1所示。

4.1.2 元数据应用

4.1.2.1 Data Profile

核心思路是为纷繁复杂的数据建立一个脉络清晰的血缘图谱。为元数据‘画像’的任务。图12.2

4.1.2.2 元数据门户

前台实现找数据的需求，后台实现管理数据的需求。不需要人工维护。

4.1.2.3 应用链路分析

主要通过统一的应用日志打点SDK来解决问题，可以做到配置化，应用无痕化。

4.1.2.4 数据建模

通过下游所使用的元数据来指导并参考数据建模。

4.1.2.5 驱动ETL开发

数据同步效率提升。图12.3

4.2 计算管理

目标：减低计算资源的消耗，提高任务执行的性能，提升任务产出的时间。

4.2.1 系统优化

4.2.1.1 HBO

任务执行历史+集群状态信息+优化规则

4.2.1.2 CBO

根据收集的信息选择来计算每种执行方式的代价，进而选择最优的执行方式。

4.2.2 任务优化

4.2.2.1 Map倾斜

Key作为分区，存放对应的Value，可能会出现部分key存储的Value过多。
读入文件分布不均匀，某个键对应的值很多，大表的数据打散。

4.2.2.2 Join倾斜

（1）MapJOIN
某路输入较小处理，加上特殊字符之后，小表放在主表。
（2）join因为空值长尾
将空值处理成随机数
（3）Join因为热点值长尾
热点值与非热点值分开处理，然后再Union　all

4.2.2.3Reduce倾斜

重视count distinct的问题

4.3 存储和成本管理

目标：有效降低存储资源消耗、节约存储成本。
数据存储治理流程图 14.2
表14.3生命周期管理矩阵
数据使用计费公平合理｡计算､存储､扫描付费｡

4.4 数据质量

目标:保证数据仓库的数据质量
注重,完整性､准确性､一致性和及时性｡
图15.2 数据质量建设方法

5､数据应用

目的:让数据最大化的产生价值
介绍示例:数据产品平台
对外数据产品
图16.1生意参谋产品理念图
图16.2 功能架构
技术能力:看我情,看行情､看敌情｡
基于各个业务打通数据｡
对内数据产品
功能:数据获取､数据分析､数据应用的数据产品平台｡
图16.3 阿里数据平台整体构架图
不仅可以做报表还可以做专题分析,赋能业务数据化运营｡

数据库仓工具箱及阿里大数据之路--阅读总结相关推荐

数据仓库进阶《阿里大数据之路》第二篇数据模型篇 (完整版)
第8章大数据领域建模综述此文章为学习笔记,有兴趣的小伙伴可以根据以下指引获取更多,学习内容链接如下: 视频:[一起啃书]阿里大数据之路数据仓库建模基础理论研读(已完结)_哔哩哔哩_bilibili ...
数据仓库理论进阶 - 01 《阿里大数据之路》第二篇数据模型篇
第8章大数据领域建模综述此文章为学习笔记,有兴趣的小伙伴可以根据以下指引获取更多,学习内容链接如下: 视频:[一起啃书]阿里大数据之路数据仓库建模基础理论研读(已完结)_哔哩哔哩_bilibili ...
阿里大数据之路总述
大数据之路一.总述 1. 数据采集 2. 数据计算 3. 数据服务 4. 数据应用一.总述数据有序.有结构地分类和存储,从而产生价值. 实时:数据量大,要实时.准确离线:采集.存储.计 ...
阿里大数据之路：数据管理篇大总结
来源:大数据技术与架构全文共 13000个字,建议阅读 20 分钟第1章元数据 1.1 元数据概述 1.1.1 元数据定义元数据打通了源数据.数据仓库.数据应用,记录了数据从产生到消费的全过程 ...
阿里大数据之路：数据模型篇大总结(收藏)
第1章大数据领域建模综 1.1 为什么需要数据建模有结构地分类组织和存储是我们面临的一个挑战. 数据模型强调从业务.数据存取和使用角度合理存储数据. 数据模型方法,以便在性能.成本.效率之间取得最 ...
万字总结阿里大数据之路-数据技术篇（建议收藏）
目录一.日志采集 1.1 浏览器的页面日志采集 1.2 无线客户端的日志采集 1.3 日志采集的挑战案例二.数据同步 2.1 数据同步基础 2.2 数据同步策略 2.2.1 批量数据同步 2.2. ...
阿里大数据之路问道（一）
数据同步数据同步技术更通用的含义是不同系统间的数据流转,有多种不同的应用场景.主数据库与备份数据库之间的备份,主系统与子系统之间的数据更新,同类型不同集群数据库之间的数据同步.还有不同地域.不同数据 ...
《阿里大数据之路》研读笔记（1）
首先先看到OLAP和OLTP的区别: OLTP(Online transaction processing):在线/联机事务处理.典型的OLTP类操作都比较简单,主要是对数据库中的数据进行增删改查,操 ...
阿里大数据技术如何进化？资深技术专家带你回顾
阿里妹导读:很多童鞋在后台留言,希望看到大数据相关的文章.因此,今天带来一篇阿里资深专家观滔在2017年云栖大会的精彩分享,为大家展示阿里大数据计算服务的进化演进.以及MaxCompute解读. 一. ...

数据库仓工具箱及阿里大数据之路--阅读总结