数仓学习2

在spark 任务时，必须注意cache的中间的的复用job，后续unpersist掉

 1、数据仓库建模理论

1.在数据仓库领域有两个派系：Bill Inmon建模方法论和Ralph Kimball建模方法论

•Bill Inmon被称为“数据仓库之父”

•Ralph Kimball被称为“商业智能之父

•两种观点诞生以来，围绕“哪一种架构最佳”的争论一直存在，但一直无法造成统一的结论

•供用户不一样的场合、针对不一样的应用场景选择某方法或者采用混合二者的方法

 

2.Kimball对数据仓库的理论与维度设计和建模有关。维度建模将客观世界分为：
–度量： 主要由业务过程和支持业务的源系统产生的数据，常以数值形式（订单金额、库存数量）存在，称为事实
–上下文：围绕着事实的大量文本形式存在的上下文，这些上下文一般被直观地分割成多个独立的逻辑块，维度建模称之为维 。维描述了度量的5个W（When、Where、What、Who和Why）信息，好比：什么时间下单、何种方式下单、买的是什么、客户是谁。

3.维度建模的Kimball数据仓库一般以星形架构来呈现
•因为星形紧贴业务过程，很是直观和符合业务人员的视角，所以被普遍和大量使用

 

4,.Kimball对数据仓库建模理论的第二大贡献是基于维度的“总线体系架构”。
•总线体系架构和一致性维度一起保证了多个主题的事实表和维度表可以最终集成在一起，提供一致和惟一的口径给业务人员。
•Kimball维度建模的主题主要以星形架构为主，主题与主题之间则用一致性维度和企业总线体系架构保证数据仓库的一致性

 5.离线数据仓库一般基于维度建模理论来构建，可是除此以外，离线数据仓库一般还会从逻辑上进行分层，这也是业界最佳实践。分层主要基于如下考虑：
–隔离性：
•数据是精心准备、规范、干净，方便理解和使用
•上游业务系统的变更给下游使用的用户最小化影响
–性能和可维护性：
•数据加工和处理都在数据团队，相同的业务逻辑不用重复执行，减小存储和计算的开销
•分层能够将处理逻辑解耦，方便定位问题和修复
–规范性：对于公司和团队，须要有统一的口径

6.数据仓库分层

ODS层：数据仓库源头系统的数据表一般会原封不动地存储一份，这称为ODS（OperationDataStore）层，存储着历史增量和全量数据。

•DW层（DWD和DWS层）：数据仓库明细层DWD和数据仓库汇总层DWS是数据平台的主要内容。
它们是经过ODS层通过ETL清洗、转换、加载生成的，基于维度建模理论来构建，经过一致性维度和数据总线来保证各个子主题的维度一致性。
•应用层（ADS）：应用层主要是各个业务方或者部门基于DWD和DWS创建的数据集市（DM），数据集市是相对于数据仓库来讲的。

一般应用层的数据是来源于DW层，原则上是不能访问ODS层的。对比于DW层，应用层只包含部门或业务方本身关心的明细层和汇总层的数据。

 

数据仓库 O u t L i n e 大数据平台简介

维度建模技术

数据仓库构建

数据仓库 大 数 据 平 台 - 简 介 一般说的大数据平台主要包括三部分：

•数据相关的工具、产品和技术： –批量数据采集传输sqoop，spark –离线数据处理Hadoop，Hive，Spark –实时流处理Storm，Spark Streaming，Flink

•数据资产： –公司业务自己产生和沉淀的数据 –公司运做产生的数据（如财务、行政） –第三方数据：外界购买、交换或者爬虫而来的数据

•数据管理：有了工具和数据，须要进行管理才能让数据价值最大和风险最小 –相关数据管理技术和概念：数据仓库、数据建模、数据质量、数据规范、数据安全和元数据管理

 

数据仓库

离 线 平 台 数据化运营

管理人员和业务人员 当前和过去一个季度或者 一个月的销售趋势如何？ 哪些商品热销？ 哪些商品销售很差？ 哪些客户购买能力比较强？ 指标 数据 获取能统计对应指标的数据

数据仓库 离 线 平 台

•离线平台 Ø对分析需求最擅长，也是最成熟的，使用最普遍的。 Ø开源的解决方案和商业性的解决方案不少 Ø是构建公司和企业数据平台的根本和基础 Ø也是目前数据平台的主战场

数据仓库 离 线 数 据 平 台 架 构

数据仓库 H i v e 体 系 架 构

•在大数据出现以前，离线数据平台就是数据仓库，数据部门也就是数据仓库部门

•hadoop出现以前，数据仓库的主要技术是商业化数据，好比微软的SQL Server、甲骨文 Oracle、IBM的DB2等 •随着数据量的爆炸性增加，Hadoop的MapReduce，Spark，Hive等大数据技术被应用到 数据仓库中。

•离线数据平台另一关键技术是数据的建模：维度表 事实表 •离线数据内容建设会对精心加工后的数据进行分层： Ø ODS原始数据层 Ø DWD明细数据层 Ø DWS汇总层 Ø ADS集市数据层

数据仓库 数 据 仓 库 技 术 - O L T P & O L A P

•OLTP：(online transaction Processing)：

•OLTP数据库，如商业性的Oracle、MS SQL Server和开源的MySQL等关系数据库 •主要用于事务处理：增删改查

•OLTP核心需求：单条记录的高效快速处理，索引技术、分库分表

•OLAP：

•OLAP数据库，专门的分析型数据库，是为了知足分析人员的统计分析需求而发展起来的

•OLAP一般只须要处理数据查询请求，数据都是批量导入的，所以经过列存储、列压缩和 位图索引等技术能够大大加快响应请求速度

数据仓库 O L T P & O L A P 对 比

•需求上不一样：

•OLTP侧重单条数据的处理效率

•OLAP侧重数据分析，须要访问大量的数据，单条数据分析没有意义 •资源和性能上：

•分析上须要频繁的统计和查询，统计须要全表扫描，会大量占用数据库的资源，严重影响线上的OLTP的性能，因此须要单独为分析创建OLAP的分析型的数据库。

•OLTP的分布式为了解决海量单条数据请求压力，将全部用户请求均匀分布到每一个节点上

•OLAP的分布式为了将用户单次对大数据集的请求任务分配到各个节点上独立计算而后再进行汇总返回（map reduce原理）

数据仓库 O L T P & O L A P 对 比 OLTP和OLAP数据库简单对比 对比项 OLTP OLAP 用户 操做人员、一线管理人员 分析决策人员、高级管理人员 功能 平常操做 分析决策 读写 一般读写数条记录 一次读取大量记录 用户数 面向外部的用户数上亿均可能、面向 内部系统用户数一般有限 一般面向内部，几十个抑或上千个， 取决于公司规模大小 DB大小 一般不存储历史数据，MB、GB 包含历史数据，GB、TB、PB级别 响应时间 毫秒级 秒、分钟甚至小时 DB设计 面向应用 面向主题 事务支持 必须支持 不必，不支持 数据 ——八 当前应用的，最新的数据 历史的、汇集的、多维、集成、统一的数据 —— 数据仓库 分 析 型 数 据 库 •专门分析型数据库出现标志着数据仓库由 学术（概念阶段） 工业阶段 •商业性的MPP（分布式的分析型数据库）和类MPP架构应运而生： –Orcale Exadata、天睿公司的Teradata、IBM收购的Netezza、EMC公司的Greenplum、惠普的HP Vertica等 –经过一站式解决方案和产品“一体机”运营： 数据仓库软件+配套硬件设施（服务器、存储设备、高速 网络交换设备），实现开箱即用。 •OLAP用户单次请求大量数据的统计分析，OLTP全部用户单条数据请求： –OLAP须要列式存储：列存储的类型是固定的，能够很容易采用高压缩比的算法进行压缩和解压缩，磁 盘I/O会大大减小，列存储只须要读取对应的列，不需用读取整个表的全部字段进行处理 –OLTP行式存储：把全部字段都存储在一起

数据仓库 H a d o o p 数 据 仓 库 •Hadoop内在技术决定：容易扩展、成本低廉，这两点是决定流行的 关键，若是大公司使用MPP，会有想当大的开销。 •基于Hadoop的数据仓库的解决方案（Hive）面临最大的挑战是数据 查询的延迟

数据仓库 数 据 仓 库 建 模 技 术 •三种搭建数据仓库的方式： –传统OLTP数据库中搭建 –商业性数据仓库产品中搭建（MPP架构的Teradata） –基于Hadoop来搭建 •无论哪一种方式都会面临如下问题： –怎么组织数据仓库中的数据？ –怎么组织才能使得数据使用最为方便和便捷？ –怎么组织才能使得数据仓库具备良好的可扩展性和可维护性？

数据仓库 两 种 数 据 仓 库 的 架 构 •在数据仓库领域有两个派系：Bill Inmon建模方法论和Ralph Kimball建 模方法论 •Bill Inmon被称为“数据仓库之父” •Ralph Kimball被称为“商业智能之父” •两种观点诞生以来，围绕“哪一种架构最佳”的争论一直存在，但一直无 法造成统一的结论 •供用户不一样的场合、针对不一样的应用场景选择某方法或者采用混合二者 的方法

数据仓库 R a l p h a  K i m b a l l 建 模 方 法 论 •Kimball对数据仓库的理论与维度设计和建模有关。维度建 模将客观世界分为： –度量： 主要由业务过程和支持业务的源系统产生的数据，常以数值形式（订 单金额、库存数量）存在，称为事实 –上下文：围绕着事实的大量文本形式存在的上下文，这些上下文一般被直观 地分割成多个独立的逻辑块，维度建模称之为维 。维描述了度量的5个W（When、Where、What、Who和Why）信息，好比：什么时间下单、何种方式下单、买的是什么、客户是谁。

数据仓库 星 形 架 构 •维度建模的Kimball数据仓库 一般以星形架构来呈现 •因为星形紧贴业务过程，非 常直观和符合业务人员的视 角，所以被普遍和大量使用

数据仓库 基 于 维 度 的 “ 总 线 体 系 架 构 ” •Kimball对数据仓库建模理论的第二大贡献是基于维度的“总线体系架构”。 •总线体系架构和一致性维度一起保证了多个主题的事实表和维度表可以最终集成在一起，提供一致 和惟一的口径给业务人员。 •Kimball维度建模的主题主要以星形架构为主，主题与主题之间则用一致性维度和企业总线体系架 构保证数据仓库的一致性。

数据仓库 仓 库 体 系 架 构

数据仓库 B i l l  I n m o n 建 模 方 法 论 •Bill Inmon是第一个提出来OLAP和数据仓库概念的人，因此被称之为“数据仓库之父” •他认为：数据仓库是“在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改 的数据集合” •数据仓库更像是一种过程，对分布在企业内部各处的业务数据的整合、加工和分析的过程， 而不是一种能够够买的产品。称之为“企业信息化工厂”

数据仓库 企 业 级 数 据 仓 库 体 系 架 构

数据仓库 企 业 数 据 仓 库 •Inmon的企业信息化工程包括源头系统、准备区、ETL、企业数据仓库、数据集市等，而企业数据仓库是企 业化信息工厂的枢纽。 •数据集市，所谓“集市”，就是部门级的数据仓库，Inmon主张从企业数据仓库中提取所须要的数据，从 而保证数据的一致性。 •不一样点： –不一样于Kimball，Inmon认为企业数据仓库应为原子数据的集成仓库，应该用第三范式和ER理论而非维度建模的事实 表和维度表来建模。 –Inmon认为先有企业数据仓库才可能开始创建部门级的数据集市。 •Inmon也认为应该用Kimball的维度建模理论来构建数据集市。

数据仓库 数 据 仓 库 建 模 实 践 •Inmon的方法是一种由上而下（top-down）的数据仓库建模方法，主张首先要对企业数据仓库进行整体 规划，并将不一样的OLTP数据集中到面向对象主题、集成的、不易失的和时间变化的企业数据仓库中。数据集市应该是数据仓库的子集，每一个数据集市都是为独立部门专门设计的。 •Kimball方法相反，是一种自下向上的（down-top）。Kimball认为数据仓库是一系列数据集市的集合， 企业能够经过一致性的维度表和“企业总线架构”来递增式集成各个数据集市，从而构建整个企业的数据仓库。 •对比： –Inmon的方法部署和开发周期较长，可是容易维护并且高度集成。因为互联网业务变化快，系统一直变，数据一直 变，致使可能永远设计不出一个企业数据仓库，因此能够先创建数据集市，然后根据业务进展再沉淀出企业数据仓库。 –Kimball的方法能够迅速响应业务需求，快速构建一个数据仓库，成效要求快，投资回报快，可是后期集成和维护较 为麻烦。

数据仓库 数 据 仓 库 逻 辑 架 构 设 计 •离线数据仓库一般基于维度建模理论来构建，可是除此以外，离线数据仓库一般 还会从逻辑上进行分层，这也是业界最佳实践。分层主要基于如下考虑： –隔离性： •数据是精心准备、规范、干净，方便理解和使用 •上游业务系统的变更给下游使用的用户最小化影响 –性能和可维护性： •数据加工和处理都在数据团队，相同的业务逻辑不用重复执行，减小存储和计算的开销 •分层能够将处理逻辑解耦，方便定位问题和修复 –规范性：对于公司和团队，须要有统一的口径

数据仓库 数 据 仓 库 分 层 •ODS层：数据仓库源头系统的数据表一般会原封不动地存储一份，这称为ODS（Operation Data Store）层，存储着历史增量和全量数据。 •DW层（DWD和DWS层）：数据仓库明细层DWD和数据仓库汇总层DWS是数据平台的主要内 容。它们是经过ODS层通过ETL清洗、转换、加载生成的，基于维度建模理论来构建，经过一致性维度和数据总线来保证各个子主题的维度一致性。 •应用层（ADS）：应用层主要是各个业务方或者部门基于DWD和DWS创建的数据集市（DM） ，数据集市是相对于数据仓库来讲的。一般应用层的数据是来源于DW层，原则上是不能访问ODS层的。对比于DW层，应用层只包含部门或业务方本身关心的明细层和汇总层的数据。

数据仓库 数 据 分 层 架 构 图

数据仓库 实 时 数 据 平 台 架 构 •离线数据平台产出数据的周期一般是天，也就是说，今天看到的是昨天的数据，对于大部分的分 析和“看”数据场景来讲，这种T+1的离线数据能够知足业务分析需求 •实时数据： –业务场景须要立刻看到业务效果，尤为是在业务促销活动（双十一大促、618大促）等 –算法需求：实时数据训练的算法效果和离线数据训练的算法效果有着天壤之别，由于时效性比较好，带来 的算法效果会更好

数据仓库 实 时 平 台 架 构

数据仓库 实 时 数 据 平 台 •实时数据平台首先要保证数据来源的实时性。数据来源主要分为两类： •数据库：注意业内最佳实践并非直接访问数据库抽取数据，而是会直接采集数据变动日志 •日志文件 •数据采集工具（Flume）采集binlog事件，产生速度和频率一般取决于源头系统。和下游的实 时数据处理工具（Storm、Spark、Flink等流计算框架和平台）处理数据的速度一般是不匹配的。 •实时数据处理一般还会从某个历史时间点重启以及多个实时任务都要使用同一源头数据的需求， 所以一般还会引入消息中间件（消息队列好比kafka）来做为缓冲，从而达到实时数据采集和处理适配

数据仓库 实 时 数 据 存 储 •实时数据存储根据下游数据使用的不一样方式一般放在不一样的数据存储内。 •对于数据在线服务（即数据使用方传入某业务ID，而后获取到全部此ID的相关字段），一般放在HBase内 •对于实时数据大屏，一般放在某关系数据库（如Mysql）内，有时为了提升性能并减轻对底层数据库的压力，还 会使用缓存数据库（Redis）等

数据仓库 数 据 管 理 •对于一个公司和组织来讲，仅有数据的技术是不够的，还必须对数据进行管理。

•数据管理的范畴很广，可是具体主要包含如下几个： ‒数据探查

数据仓库 数 据 探 查 •数据探查就是对数据自己和关联关系等进行分析，包括但不限于： –须要的数据是否有 –都有哪些字段 –字段含义是否规范明确 –字段的分析和质量如何 •数据探查经常使用的分析技术包括： –主外键 –字段类型 –字段长度 –null值占比  好比- ，‘’，“”其余非约定的值都算是空值 –枚举值分布 –最小值 –最大值 –平均值

数据仓库 数 据 探 查 •数据探查分为战略性和战术性的。 •战如略何性：是指使用数据以前首先对数据进行轻量级的数据分析，肯定其是否可用、数据稳定性 ，以决定是否能够归入数据平台使用。这是构建数据平台的首要任务，不合格的数据源头 必须尽快剔除。 •战术性：是指用技术手段对数据进行详尽的分析，发现尽量多的数据质量问题并反馈给业务 人员或者通知源头系统进行改进。 •数质据探查是构建数据平台的基础，好的数据探查工做直接为后续的数据建模、数据集成和数据 量等工做提供了指导，也能让数据平台团队对数据作到心中有数。

数据仓库 数 据 集 成 •数据仓库的数据集成也叫ETL（抽取：extract、转换：transform、加载：load ）是数据平台构建的核心，也是数据平台构建过程最耗时的过程。

•ETL泛指讲数据从数据源抽取、通过清洗、转换、关联等转换，并最终按照预先 设计的数据模型将数据加载到数据仓库的过程。

•ETL处理的结果是为数据使用者提供一个汇总、规范、包含全部相关订单信息的 宽表。（就是select *就能拿到全部想要的数据）

•ETL过程技术上须要解耦任务，这样会产生大量的执行job，这些须要经过专门 的调度和管理，关键是设置checkpoint保证出错时重跑成本低。 •ETL开源工具：Kettle、Talend，Hive，spark

 

数据仓库 数 据 质 量

•数据质量问题始终是每一个数据相关人员的核心诉求，尤为是数据分析师、数据开 发工程师、业务分析接口人

•这些人常常面临的问题：“这个数据准确么？”

•或者被质疑： –“这个数据有问题” –“这个数据确定是错误的”

数据仓库 数 据 质 量

•数据的准与不许须要从如下4个方面进行衡量： –完整性：是指数据信息是否存在缺失情况，不完整的数据质量会大大下降 •数据记录缺失

•数据记录中字段值缺失 –一致性：指数据是否遵循了统一的规范，是否保持统一的格式 •数据记录的规范：IP地址一定是有4个0~255的数据加上“.”组成

•数据是否合乎逻辑：互联年龄主要集中在12-60，不多是负数，也不可能大于1000 –准确性：指数据记录的信息是否存在异常或错误，是否符合业务的预期

•与一致性的区别：准确性不仅是规则上的不一致，更多的是业务规则的冲突，好比：业务规定某字段值只有（1,0 ），可是出现了3或者其余字符串 –及时性：指数据的产生时间是否及时、准时，符合预期。

数据仓库 数 据 质 量

•数据从生产到消费有不少环节，每一个环节均可能出现数据质量问题，可是对于直接使用数据 的人来讲，数据开发团队被视为数据质量问题的第一责任人，数据开发团队有义务和责任来解决数据质量问题，推进解决问题。

•数据质量问题须要借助系统和工具才能落地，主要监控： –数据行数波动 –主键重复 –字段空值比，空值率 –枚举值检查、枚举值占比 –字段最小值、最大值、均值、数值合计 •经过这些指标+业务规则监测来衡量是否有数质量问题，若是发现系统报警，须要第一时间 解决和修复。

数据仓库 数 据 屏 蔽

•数据仓库存储了企业全部的数据，其中有些数据是很是敏感的，好比用户的信用卡信息、身 份证、手机号等，这些信息若是泄露会给企业和公司带来灾难性的后果。但若是直接删除，会对开发测试和分析统计带来影响。

•数据屏蔽就是对数据进行脱敏，进行不可逆的处理，既能知足开发测试和统计分析使用

•主要方法：

–替换：用预先准备的测试数据来替换真实的敏感数据

–洗牌（shuffle）：和替换一直，只是替换的数据集是其自己

–删除/加扰：删除会破坏数据完整性，能够经过“*”来替代，150****6789

–加密：经过加密算法，将原始数据变为无心义字符，只有应用“密钥”才能查看原始数据

数据仓库 O u t L i n e 大数据平台简介 维度建模技术 数据仓库构建

数据仓库 维 度 建 模 过 程 •维度建模过程顺序分为四个过程：

1. 选取业务过程：针对项目业务活动，不如百度主要业务活动是搜索，维度模型是同部门捆绑在一起的，因此没法避 免数据不一致的状况，（好比业务编码、含义），须要从全局考虑。

2. 定义粒度：对事实表实际表明的内容和含义给出明确的说明，粒度传递了事实表度量值相联系的细节所达到的程度 的信息。（好比：订单信息orders表，更细粒度的priors表每一个订单具体的商品信息）粒度定义须要最大程度选择业务过程当中最为原子性的粒度，这样能让后续处理更加灵活

3. 肯定维度：维度是对度量的上下文和环境的描述。（好比用户的注册的基本信息，商品的基本属性信息）

4. 肯定事实：经过业务过程可能要分析什么来肯定。好比促销活动，须要度量的是销售量和销售金额

数据仓库 维 度 表 设 计

•维度表示维度建模的灵魂，在维度表设计中碰到的问题直接关系到维度建模的好坏。

•主要问题：

–维度变化：维度是缓慢变化的过程 –维度层次：某个维度表中的属性之间存在的从属关系 –维度一致性：两个维度若是有关系，要么相同，要么是子集。不一致包括表内容和属性上的不一致。 –维度整合和拆分：同一个维度来自多个业务系统，须要整合和拆分。

–维度其余

数据仓库 维 度 变 化

•维度表的数据一般来自与业务系统，商品是会发生变化的，好比商品的所属类目、商品价格、商品描述 等。这些变化多是以前错误的修正，或者实际商品更新。这个变化称为“缓慢变化维”

•肯定源数据变化在维度表中如何表示很是重要，根据变化内容的不一样，下游分析可能要求用不一样的办法 来处理。 –商品的描述信息变化：也许业务人员不太敏感，能够直接覆盖 –商品所属类目变化：涉及到这个商品的销售活动是哪一个类目的 •是所有归到新类目，仍是所有归到旧类目？ •变化前归到就类目，仍是变化后归到新类目？

数据仓库 维 度 变 化

•缓慢变化维的几种处理办法：

–从新维度值：当一个维度值属性发生变化时，重写维度值方法直接用新值覆盖旧值。在 不须要保留维度属性历史变化的状况。

–插入新的维度行：不维护维度属性变化，经过插入新的行来保存和记录变化的状况。保 存了变化先后的历史数据，可是没有变化的数据会有冗余现象。

–插入新的维度列：下游分析须要用到变化前和变化后的属性值，有能用变化后的属性值 来分析变化前的全部事实，这时能够采用插入新的维度列。这样会致使表结构须要发生变化，或者提早预留。

数据仓库 维 度 层 次

•维度层次指的是某个维度表中属性之间存在的从属关系问题。

好比商品的类目多是有层次的（一级类 目、二级类目、三级类目等），那么维度建模如何处理这些层次结构的呢？

•有两种处理办法：

–将全部维度层次结构去所有扁平化，冗余存储到一个表中，星形架构 –新建类目维度表，并在维度表中维护父子关系，雪花架构

•在维度建表中一般采用星形架构，虽然牺牲了部分的存储，可是给用户使用带来了便捷，也减低了学习 使用的成本。

•维度层级结构一般和钻取练习在一起，所谓钻取就是对信息的持续深刻挖掘。

•钻取的实质是增长或者减小维度分为两种：

–向下钻取：从汇总数据深刻到细节数据。好比年度销售总额增加20%，增长时间维度，分析季度增加率

–向上钻取：从细节数据归纳到汇总数据。

数据仓库 维 度 一 致 性

•维度设计理论中，数据仓库是在对多个主题、多个业务过程的屡次迭代过程当中逐步创建的，逻辑上划分 迭代过程为数据集市

–数据集市一般由一张和多张紧密关联的事实表以及多个维度表组成，一般是部门或者面向某个特定的主题。

–数据仓库则是企业级的、面向主题的、集成的数据集合

•若是分步创建数据集市的过程当中维度表不一致，那么数据集市就会变成孤立的集市，不能从逻辑上组合 成一个集成的数据仓库，而一致性就是为了解决这个问题。

•维度一致性：两个维度若是有关系，要么彻底一样，要么数据逻辑上是另一个的子集。 –内容不一致：某种交易上缺失了部分商品，那么对这些缺失商品的交易分析没法完成。 –维度不一致：好比日期格式、类目和日组合成一个数据信息、 •能够采用共享同一个维度表或者让其中一个维度表示另一个维度表的子集的方式保证一致性。

数据仓库 维 度 整 合 & 拆 分 •有时候出现同一个维度表来自于多个前台业务系统的问题，此时会带来维度整合和拆分问题。好比：移 动端交易系统和PC端交易系统的系统架构和底层数据库、表结构等的不一样。

•同一个维度的整个须要考虑如下问题： –命名规范：要确保一致和统一 –字段类型：统一整合为一个字段类型 –字段编码和含义：编码及含义要整个为一致的。

•对于业务系统的不一样一般有两种处理办法： –创建一个基础的维度表，此基础维度表包含这些不一样业务的共有属性，同时简历各自业务的单独维度表以包含其独 特的业务属性。 –拆分，即不合并，即各个业务差别独特性的业务各自创建彻底独立的两个维度表，各自管理各自维度表和属性。 （好比1.能够将pc与app端的建同一张表，pc端特有信息字段app端没有，app端特有的pc端没有  2.或者将公共的部分建一个表，特有的信息各自建一个表 ，进行关联便可）

•实际操做中，对于业务差别大的业务，耦合在一起并不能带来很大的便利和好处，所以一般倾向于拆分（ 即不合并），各自管理各自的维度表。对于业务类似度比较大的业务，则能够采用第一种办法。

数据仓库 深 入 事 实 表

•事实表示维度建模的核心和基本表。事实表存储了业务过程的各类度量和事实，而这些度量和事实正是 下游数据使用人员关心和分析的对象。

•事实表的三种主要的类型： –事务事实表：记录业务过程原子粒度的事件，每一个事务一条记录。 –快照事实表：业务的状态（当前状态、历史状态），好比商品的库存，挤压促销。

–累计快照事实表：适用于具备工做流或者流水线形式的业务的分析。好比：漏斗分析（浏览、点击、转化）

数据仓库 事务事实表（用户购买了那些商品，点击了多少次等行为量是多，商品销售额等）

•事务事实表记录业务过程的事件，并且是原子粒度的事件。

•数据在事务发生后产生，数据的粒度一般是每一个事务一条记录。

•一旦事务被提交，事实表数据被插入。 •经过事务事实表存储单词业务事件/行为的细节，以及存储与事件相关的维度细节， 用户能够单独聚合分析业务事件和行为。

数据仓库 事务事实表

•结合超市零售业务以及维度建模的四个环节来讲明事务事实表：

1. 选择业务过程 •理解POS系统记录的顾客购买状况，何时、什么商品、哪一个收银台、销售了哪些商品等

2. 定义粒度 •用户购买行为体如今一张小票，事务事实选择最原子粒度的事件，因此小票的子项目（商品）是超市零 售事务事实表的粒度

3. 肯定维度 •粒度肯定后，销售日期、销售商品、销售收银台、收银员、销售门店等维度就容易被肯定下来了。细节 （促销行为）

4. 肯定事实

•肯定哪些事实和度量应该在事实表中出现。本例：商品销售数量、销售价格、销售金额等 数据仓库 快照事实表

•在实际业务中，除了关心单次的业务事件和行为外，不少时候还关心业务的状态（ 当前状态、历史状态），好比在商品中对应的是库存状况。

•快照事实表，又叫周期快照事实表，指间隔一定的周期对业务的状态进行一次拍照 并记录下来的事实表。最多见的例子：销售库存，帐户余额等 •对比事务事实表发生才会记录，周期快照则必须捕获当前每一个实体的状态。好比： 某个商品当天没有售卖，事务事实表不会有记录，但周期快照须要对其库存进行定时记录。

•周期快照事实表的周期须要和业务方共同肯定，最多见的周期（day、Week、 Month）

数据仓库 快照事实表

•以超市的库存业务啦介绍周期快照事实表的设计过程：

1. 选择业务过程 •业务目的为了更好理解超市库存状况，业务过程就是商品库存状况。何时、什么商品、哪一个仓库的库存 量

2. 定义粒度 •主要指定库存的周期。周期为day的记录计算：100家连锁店*10000个商品=100w行记录/day

3. 肯定维度 •周期（天、周、月等）、商品、仓库

4. 肯定事实 •库存量、增量度量（库存价值、库存成本、周期销售量、去化天数【基于周期内销售预计须要库存天数】）

数据仓库 累计快照事实表

•累计快照事实表很是适用于具备工做流或者流水线形式业务的分析，这些业务通 常涉及多个时间点或者有主要的里程碑事件，是从全流程角度对业务状态的拍照

•以车险举例：

–主要事件：客户报案、保险公司立案、客户提交理赔材料、理赔审批经过和付款。 –目标：分析各个理赔的状态、步骤间的耗时

1. 选择业务过程：更好的理解保险公司的车险理赔业务，业务过程是车险理赔

2. 定义粒度：某个客户的保险理赔申请做为一个记录

3. 肯定维度：快照周期、理赔申请人、受理人、审核人、网点等 4. 肯定事实：索赔金额、审批金额、打款金额、处理时长

 

数据仓库 业 务 需 求

•以零售业务为例，涉及到全国连锁业务形态、收银台购物流程、商品供应链、商品库存管理等。这么大规模 的零售，运营设计到什么？ –整个公司的总体销售趋势如何？ –是否应该对某些滞销商品进行促销？ –客户是否流失？ –某些畅销商品是否应该及时补货？ –如何选择自营商品从而利润最大化？

•数据仓库平台是以上问题实现数据化运营的前提和基础。基于数据仓库平台生成的各类销售报表和库存报表是 公司管理层和各个城市运营人员决策的主要依据。

数据仓库 数 据 仓 库 架 构 设 计

•数据仓库在实际设计中，一般出于可维护性、性能成本以及使用便捷性考虑，会对数据仓库中的表进行分层

•ODS层：源头数据原封不一样存储一份，是后面DW层（仓库层）的源数据，ODS层存储的是历史增量或者全 量数据

•DW层：

–ODS层通过ETL生成，这一层的数据一定是清洗过的，干净的、一致的、规范的、准确的数据。下游用户直接使用DW层 数据，而ODS层原则上不容许下游用户直接接触。

–明细层：保存最细粒度的事实表和维度表

orders、pruducts表

–汇总层：设计主要是出于性能以及避免重复计算考虑，如何设计须要根据业务需求以及明细层实际汇总频率来肯定 –原则上，业务使用频繁的维度须要对这些数据创建汇总层，汇总的指标能够和业务需求方共同设计完成。

orders、pruducts等同一业务的多表join起来造成宽表

•应用层：

数据来源于DW层，原则上访问不了ODS层。各个业务方或者部门能够创建本身的数据集市（Data Mart），只包含部门或者业务方本身关心的明细层和汇总层的数据。通常由下游用户本身维护和开发。

 

数据仓库 数 据 仓 库 规 范 设 计

•对于公司来讲，使用数据的用户成百上千，如何下降你们对于数据使用的沟通成本、如何经过规范你们的行 为来下降使用数据的风险。须要经过规范来实现。

•数据仓库的规范包括不少方面，主要有： –命名规范 –开发规范 –流程规范 –安全规范 –质量规范

数据仓库 命 名 规 范

•表命名规范：为了让数据全部相关方对于表包含的信息有一个共同的认知。好比说属于哪一层（ODS,DW明 细，DW汇总、应用层）？哪一个业务线/部门？哪一个维度（商品、卖家、买家、类目）？哪一个时间跨度（天、月、年、实时）？增量仍是全量？ •数据平台建设者应该首先规定数据仓库的分层、业务/部门、常见威慑时间跨度的英文缩写，并根据这个缩写 来命名。

dw_sale_iterm_20180801

数据仓库 开 发 规 范

•开发规范主要用于规范和约束数据开发人员和使用人员的习惯，以最大限度下降数据使用风险，并同时保证 用户准守最佳实践。主要包括如下几个方面： –数据任务的分类和存放（即目录结构的划分）：公共代码如何存放，我的代码如何存放，项目和产品的代码如何分类存 放，实际项目中须要统筹规划并保证每人都遵照，方便用户找到对应项目、产品或者各个层次的代码（ODS、DWD、DWS、ADS） –代码的编程规范：好比任务注释的规范必须包含哪几部分、代码对其规范、代码的开发约定等 –最佳实践：有些最佳实践（灵活运用时间分区、timestamp定义到毫秒仍是秒、数据类型定义规范多个）都须要开发规 范来约束，以确保最佳实践得以落地。

数据仓库 流 程 规 范

数据仓库 数 据 仓 库 构 建 示 例

- - 商 品 维 度 表

•商品维度表命名dim_fr_item，设计说明：

1. 维度表设计的首要问题是维度表的拆分以及合并问题

–主要存放共有属性

2. 对于缓慢变化维和微型维度的问题，dim_fr_item经过快 照和分区字段来解决。

–dim_fr_item将天天存放一份全量数据快照，存放的生命周期 由业务需求肯定

•出于属性扩展性考虑，dim_fr_item将包含JSON和 KeyValue的大字端，但相应地会增长了使用成本。

数据仓库 销 售 事 实 表

 

数据仓库 数 据 平 台 架 构

- - 数 据 湖

•数据湖和数据仓库的核心区别：

1. 数据湖存放全部数据：数据湖存储结构化、半结构化（JSON、XML）和非结构化（语音、视频）数据，同时存放全部数据， 不只包括如今须要用到的数据，也包括之后会用到的数据或者压根不用的数据；而数据仓库一般存放的是通过处理、结构化的数据

2. Schema-On-Read：数据在数据湖中保存他们原有的形态知道即将被使用的时候才会进行转换（shema-on-read）；而数 据仓库在写入以前必须定义好结构和形态（schema-on-write）

3. 更容易适应变化：若数据有价值且可被重复利用的，转换为平常任务。若是没用的无须投入人力和时间成本

4. 更快的洞察能力：由于数据湖包含全部数据和数据类型，而且它可以让用户在数据通过清洗、转换、结构化以前就访问数据 ，这种方式使得用户可以比传统数据仓库方式更快获得结果。鼓励用户自助、自由分析数据。