数据仓库的哪些事儿，

数据仓库

大数据平台

简介

通常说的大数据平台主要包括三部分：

1. 数据相关的工具、产品和技术：

• 批量数据采集传输sqoop，spark
• 离线数据处理Hadoop，Hive，Spark
• 实时流处理Storm，Spark Streaming，Flink

1. 数据资产：

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

1. 数据管理：有了工具和数据，需要进行管理才能让数据价值最大和风险最小

• 相关数据管理技术和概念：数据仓库、数据建模、数据质量、数据规范、数据安全和元数据管理

离线平台

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

离线数据平台架构

离线数据平台架构

• 在大数据出现之前，离线数据平台就是数据仓库，数据部门也就是数据仓库部门
• hadoop出现之前，数据仓库的主要技术是商业化数据，比如微软的SQL Server、甲骨文
  Oracle、IBM的DB2等
• 随着数据量的爆炸性增长，Hadoop的MapReduce，Spark，Hive等大数据技术被应用到
  数据仓库中。
• 离线数据平台另一关键技术是数据的建模：维度表 事实表
• 离线数据内容建设会对精心加工后的数据进行分层：

1. ODS原始数据层
2. DWD明细数据层
3. DWS汇总层
4. ADS集市数据层

数据仓库技术 -OLTP&OLAP

• OLTP：(online transaction Processing)：

1. OLTP数据库，如商业性的Oracle、MS SQL Server和开源的MySQL等关系数据库
2. 主要用于事务处理：增删改查
3. OLTP核心需求：单条记录的高效快速处理，索引技术、分库分表

• OLAP：

1. OLAP数据库，专门的分析型数据库，是为了满足分析人员的统计分析需求而发展起来的
2. OLAP一般只需要处理数据查询请求，数据都是批量导入的，因此通过列存储、列压缩和
   位图索引等技术可以大大加快响应请求速度

OLTP&OLAP对比

• 需求上不同：

1. OLTP侧重单条数据的处理效率
2. OLAP侧重数据分析，需要访问大量的数据，单条数据分析没有意义

• 资源和性能上：

1. 分析上需要频繁的统计和查询，统计需要全表扫描，会大量占用数据库的资源，严重影响
   线上的OLTP的性能，所以需要单独为分析建立OLAP的分析型的数据库。
2. OLTP的分布式为了解决海量单条数据请求压力，将所有用户请求均匀分布到每个节点上
3. OLAP的分布式为了将用户单次对大数据集的请求任务分配到各个节点上独立计算然后再进
   行汇总返回（map reduce原理）

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行式存储：把所有字段都存储在一起

Hadoop数据仓库

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

数据仓库建模技术

• 三种搭建数据仓库的方式：

1. 传统OLTP数据库中搭建
2. 商业性数据仓库产品中搭建（MPP架构的Teradata）
3. 基于Hadoop来搭建

• 不管哪种方式都会面临以下问题：

1. 怎么组织数据仓库中的数据？
2. 怎么组织才能使得数据使用最为方便和便捷？
3. 怎么组织才能使得数据仓库具有良好的可扩展性和可维护性？

两种数据仓库的架构

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

RalphaKimball建模方法论

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

星形架构

• 维度建模的Kimball数据仓库通常以星形架构来呈现
• 由于星形紧贴业务过程，非常直观和符合业务人员的视角，因此被广泛和大量使用

基于维度的 “总线体系架构 ”

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

仓库体系架构

BillInmon建模方法论

• 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大促）等
– 算法需求：实时数据训练的算法效果和离线数据训练的算法效果有着天壤之别，因为时效性比较好，带来
的算法效果会更好

实时平台架构

实时数据平台

• 实时数据平台首先要保证数据来源的实时性。数据来源主要分为两类：

1. 数据库：注意业内最佳实践并不是直接访问数据库抽取数据，而是会直接采集数据变更日志
2. 日志文件
   • 数据采集工具（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
– 加密：通过加密算法，将原始数据变为无意义字符，只有应用“密钥”才能查看原始数据

维度建模技术

维度建模过程

• 维度建模过程顺序分为四个过程：

1. 选取业务过程：针对项目业务活动，不如百度主要业务活动是搜索，维度模型是同部门捆绑在一起的，所以无法避
   免数据不一致的情况，（比如业务编码、含义），需要从全局考虑。
2. 定义粒度：对事实表实际代表的内容和含义给出明确的说明，粒度传递了事实表度量值相联系的细节所达到的程度
   的信息。（比如：订单信息orders表，更细粒度的priors表每个订单具体的商品信息）粒度定义需要最大程度选择

业务过程中最为原子性的粒度，这样能让后续处理更加灵活

1. 确定维度：维度是对度量的上下文和环境的描述。（比如用户的注册的基本信息，商品的基本属性信息）
2. 确定事实：通过业务过程可能要分析什么来确定。比如促销活动，需要度量的是销售量和销售金额

维度表设计

• 维度表示维度建模的灵魂，在维度表设计中碰到的问题直接关系到维度建模的好坏。
• 主要问题：
– 维度变化：维度是缓慢变化的过程
– 维度层次：某个维度表中的属性之间存在的从属关系
– 维度一致性：两个维度如果有关系，要么相同，要么是子集。不一致包括表内容和属性上的不一致。
– 维度整合和拆分：同一个维度来自多个业务系统，需要整合和拆分。
– 维度其他

维度变化

• 维度表的数据通常来自与业务系统，商品是会发生变化的，比如商品的所属类目、商品价格、商品描述
等。这些变化可能是之前错误的修正，或者实际商品更新。这个变化称为“缓慢变化维”
• 确定源数据变化在维度表中如何表示非常重要，根据变化内容的不同，下游分析可能要求用不同的办法
来处理。
– 商品的描述信息变化：也许业务人员不太敏感，可以直接覆盖
– 商品所属类目变化：涉及到这个商品的销售活动是哪个类目的
• 是全部归到新类目，还是全部归到旧类目？
• 变化前归到就类目，还是变化后归到新类目？

• 缓慢变化维的几种处理办法：
– 重新维度值：当一个维度值属性发生变化时，重写维度值方法直接用新值覆盖旧值。在
不需要保留维度属性历史变化的情况。
– 插入新的维度行：不维护维度属性变化，通过插入新的行来保存和记录变化的情况。保
存了变化前后的历史数据，但是没有变化的数据会有冗余现象。
– 插入新的维度列：下游分析需要用到变化前和变化后的属性值，有能用变化后的属性值
来分析变化前的所有事实，这时可以采用插入新的维度列。这样会导致表结构需要发生
变化，或者提前预留。

维度层次

• 维度层次指的是某个维度表中属性之间存在的从属关系问题。比如商品的类目可能是有层次的（一级类
目、二级类目、三级类目等），那么维度建模如何处理这些层次结构的呢？
• 有两种处理办法：
– 将所有维度层次结构去全部扁平化，冗余存储到一个表中，星形架构
– 新建类目维度表，并在维度表中维护父子关系，雪花架构
• 在维度建表中一般采用星形架构，虽然牺牲了部分的存储，但是给用户使用带来了便捷，也减低了学习
使用的成本。
• 维度层级结构通常和钻取练习在一起，所谓钻取就是对信息的持续深入挖掘。
• 钻取的实质是增加或者减少维度分为两种：
– 向下钻取：从汇总数据深入到细节数据。比如年度销售总额增长20%，增加时间维度，分析季度增长率

– 向上钻取：从细节数据概括到汇总数据。

维度一致性

• 维度设计理论中，数据仓库是在对多个主题、多个业务过程的多次迭代过程中逐步建立的，逻辑上划分
迭代过程为数据集市
– 数据集市一般由一张和多张紧密关联的事实表以及多个维度表组成，一般是部门或者面向某个特定的主题。
– 数据仓库则是企业级的、面向主题的、集成的数据集合
• 如果分步建立数据集市的过程中维度表不一致，那么数据集市就会变成孤立的集市，不能从逻辑上组合
成一个集成的数据仓库，而一致性就是为了解决这个问题。
• 维度一致性：两个维度如果有关系，要么完全一样，要么数据逻辑上是另一个的子集。
– 内容不一致：某种交易上缺失了部分商品，那么对这些缺失商品的交易分析无法完成。
– 维度不一致：比如日期格式、类目和日组合成一个数据信息、
• 可以采用共享同一个维度表或者让其中一个维度表示另一个维度表的子集的方式保证一致性。

维度整合 &拆分

• 有时候出现同一个维度表来自于多个前台业务系统的问题，此时会带来维度整合和拆分问题。比如：移
动端交易系统和PC端交易系统的系统架构和底层数据库、表结构等的不同。
• 同一个维度的整个需要考虑以下问题：
– 命名规范：要确保一致和统一
– 字段类型：统一整合为一个字段类型
– 字段编码和含义：编码及含义要整个为一致的。
• 对于业务系统的不同通常有两种处理办法：
– 建立一个基础的维度表，此基础维度表包含这些不同业务的共有属性，同时简历各自业务的单独维度表以包含其独
特的业务属性。
– 拆分，即不合并，即各个业务差异独特性的业务各自建立完全独立的两个维度表，各自管理各自维度表和属性。

• 实际操作中，对于业务差异大的业务，耦合在一起并不能带来很大的便利和好处，因此通常倾向于拆分（
即不合并），各自管理各自的维度表。对于业务相似度比较大的业务，则可以采用第一种办法。

深入事实表
• 事实表示维度建模的核心和基本表。事实表存储了业务过程的各种度量和事实，而这些度量和事实正是
下游数据使用人员关心和分析的对象。
• 事实表的三种主要的类型：
– 事务事实表：记录业务过程原子粒度的事件，每个事务一条记录。
– 快照事实表：业务的状态（当前状态、历史状态），比如商品的库存，挤压促销。
– 累计快照事实表：适用于具有工作流或者流水线形式的业务的分析。比如：漏斗分析（浏览、点击、转化）

数据仓库
事务事实表
• 事务事实表记录业务过程的事件，而且是原子粒度的事件。
• 数据在事务发生后产生，数据的粒度通常是每个事务一条记录。
• 一旦事务被提交，事实表数据被插入。
• 通过事务事实表存储单词业务事件/行为的细节，以及存储与事件相关的维度细节，
用户可以单独聚合分析业务事件和行为。

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

1. 选择业务过程
   • 理解POS系统记录的顾客购买情况，什么时候、什么商品、哪个收银台、销售了哪些商品等
2. 定义粒度
   • 用户购买行为体现在一张小票，事务事实选择最原子粒度的事件，所以小票的子项目（商品）是超市零

售事务事实表的粒度

1. 确定维度
   • 粒度确定后，销售日期、销售商品、销售收银台、收银员、销售门店等维度就容易被确定下来了。细节

（促销行为）

1. 确定事实
   • 确定哪些事实和度量应该在事实表中出现。本例：商品销售数量、销售价格、销售金额等

数据仓库
快照事实表
• 在实际业务中，除了关心单次的业务事件和行为外，很多时候还关心业务的状态（
当前状态、历史状态），比如在商品中对应的是库存情况。
• 快照事实表，又叫周期快照事实表，指间隔一定的周期对业务的状态进行一次拍照
并记录下来的事实表。最常见的例子：销售库存，账户余额等
• 对比事务事实表发生才会记录，周期快照则必须捕获当前每个实体的状态。比如：
某个商品当天没有售卖，事务事实表不会有记录，但周期快照需要对其库存进行定
时记录。
• 周期快照事实表的周期需要和业务方共同确定，最常见的周期（day、Week、

Month）

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

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

量

1. 定义粒度
   • 主要指定库存的周期。周期为day的记录计算：100家连锁店*10000个商品=100w行记录/day
2. 确定维度
   • 周期（天、周、月等）、商品、仓库
3. 确定事实

• 库存量、增量度量（库存价值、库存成本、周期销售量、去化天数【基于周期内销售预计需要库存天数】）

数据仓库
累计快照事实表
• 累计快照事实表非常适用于具有工作流或者流水线形式业务的分析，这些业务通
常涉及多个时间点或者有主要的里程碑事件，是从全流程角度对业务状态的拍照
• 以车险举例：
– 主要事件：客户报案、保险公司立案、客户提交理赔材料、理赔审批通过和付款。
– 目标：分析各个理赔的状态、步骤间的耗时

1. 选择业务过程：更好的理解保险公司的车险理赔业务，业务过程是车险理赔
2. 定义粒度：某个客户的保险理赔申请作为一个记录
3. 确定维度：快照周期、理赔申请人、受理人、审核人、网点等
4. 确定事实：索赔金额、审批金额、打款金额、处理时长

数据仓库构建

业务需求

• 以零售业务为例，涉及到全国连锁业务形态、收银台购物流程、商品供应链、商品库存管理等。这么大规模
的零售，运营设计到什么？
– 整个公司的整体销售趋势如何？
– 是否应该对某些滞销商品进行促销？
– 客户是否流失？
– 某些畅销商品是否应该及时补货？
– 如何选择自营商品从而利润最大化？
• 数据仓库平台是以上问题实现数据化运营的前提和基础。基于数据仓库平台生成的各种销售报表和库存报表是
公司管理层和各个城市运营人员决策的主要依据。

数据仓库架构设计

• 数据仓库在实际设计中，通常出于可维护性、性能成本以及使用便捷性考虑，会对数据仓库中的表进行分层
• ODS层：源头数据原封不同存储一份，是后面DW层（仓库层）的源数据，ODS层存储的是历史增量或者全
量数据
• DW层：
– ODS层经过ETL生成，这一层的数据一定是清洗过的，干净的、一致的、规范的、准确的数据。下游用户直接使用DW层
数据，而ODS层原则上不允许下游用户直接接触。
– 明细层：保存最细粒度的事实表和维度表
– 汇总层：设计主要是出于性能以及避免重复计算考虑，如何设计需要根据业务需求以及明细层实际汇总频率来确定
– 原则上，业务使用频繁的维度需要对这些数据建立汇总层，汇总的指标可以和业务需求方共同设计完成。
• 应用层：数据来源于DW层，原则上访问不了ODS层。各个业务方或者部门可以建立自己的数据集市（Data

Mart），只包含部门或者业务方自己关心的明细层和汇总层的数据。一般由下游用户自己维护和开发。

数据仓库规范设计

• 对于公司来说，使用数据的用户成百上千，如何降低大家对于数据使用的沟通成本、如何通过规范大家的行
为来降低使用数据的风险。需要通过规范来实现。
• 数据仓库的规范包括很多方面，主要有：
–命名规范
–开发规范
–流程规范
– 安全规范
– 质量规范

命名规范

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

开发规范

• 开发规范主要用于规范和约束数据开发人员和使用人员的习惯，以最大限度降低数据使用风险，并同时保证
用户准守最佳实践。主要包括以下几个方面：
–数据任务的分类和存放（即目录结构的划分）：公共代码如何存放，个人代码如何存放，项目和产品的代码如何分类存
放，实际项目中需要统筹规划并保证每人都遵守，方便用户找到对应项目、产品或者各个层次的代码（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.更快的洞察能力：因为数据湖包含所有数据和数据类型，并且它能够让用户在数据经过清洗、转换、结构化之前就访问数据
，这种方式使得用户能够比传统数据仓库方式更快得到结果。鼓励用户自助、自由分析数据。