一、背景

数据仓库的核心是展现层和提供优质的服务。ETL 及其规范、分层等所做的一切都是为了一个更清晰易用的展现层。

1. 数仓架构的原则：

底层业务的数据驱动为导向同时结合业务需求驱动

便于数据分析

屏蔽底层复杂业务

简单、完整、集成的将数据暴露给分析层

底层业务变动与上层需求变动对模型冲击最小化

业务系统变化影响削弱在基础数据层（资金订单改造）

结合自上而下的建设方法削弱需求变动对模型的影响

数据水平层次清晰化

高内聚松耦合

主题之内或各个完整意义的系统内数据的高内聚

主题之间或各个完整意义的系统间数据的松耦合

构建仓库基础数据层

使得底层业务数据整合工作与上层应用开发工作相隔离，为仓库大规模开发奠定基础

仓库层次更加清晰，对外暴露数据更加统一

数仓模型不只是考虑如何设计和实现功能，设计原则应该从访问性能、数据成本、使用成本、数据质量、扩展性来考虑。如何搭建一个好的数据仓库：

数仓设计的3个维度：

2. 主流建模方法

当前主流建模方法为：ER模型、维度模型。

ER模型常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合， 站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。缺陷：需要全面梳理企业所有的业务和数据流，周期长，人员要求高。

维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型。优点：不需要完整的梳理企业业务流程和数据，实施周期根据主题边界而定，容易快速实现demo，而且相对来说便于理解、提高查询性能、对称并易扩展。

作为大数据板块，数据来源更加广泛，针对的业务域也更加宽广，所以维度建模相对来说更加灵活并适用。

在讨论维度建模之前，关注数仓和BI的基本目标是非常有意义的，在做日常的数据需求的时候，经常会遇到如下几个痛点：

收集了海量数据，不知道如何去做ETL；

不同来源的数据该如何去聚合；

如何方便业务人员快速方便的获取数据；

如何定义重要的数据指标；

如何确保数据准确性；

数据如何支持决策；

基于上面的痛点，就需要搭建一套DW/BI系统（当然现在市面上有很多类似的产品，例如：如：QuickBI、GrowingIO、神策、猛犸等等），但是对于公司而言，适合自己的才是最好的，大部分公司选择自己搭建或者利用开源的软件（例如MateBase），这个系统必须满足：

DW/BI系统能够方便的存储信息（或者说能跟现在主流的数据库打通）。也就是说系统展现的内容必须是容易理解的，对于业务人员必须直观而且好操作，数据结构和标示必须符合业务思维过程和词汇，用户能够以各种形式切割和分析数据，同时能够快速的将查询结果反馈。

DW/BI系统必须以一致性的形式展现信息（指标的唯一性）。也就是说数据必须是可信的，同一指标定义在不同的数据源中，所含的意义必须相同，既同名同意性。

DW/BI系统能够适应变化（模块的低耦合）。当用户需求、业务维度需要调整的调整的时候，设计的DW模型必须能够兼容这些变化，已经存在数据和指标不应该被破坏或修改，就算一些指标的调整，也要以适当的方式描述变化，并对用户完全透明。

DW/BI系统必须保证数据安全（数据安全）。能展示的数据必须是统计的结果数据，一些详单展现和下载必须和平台的权限系统挂钩，避免数据泄漏。

DW/BI系统成功的标示是业务群体接收并使用，而且必须配套一个展现模块的监控系统，能够让产品方知道各个模块的使用情况，对一些访问量比较少的模块可以适当的调整和优化。

二、数据仓库介绍

1. 定义

数据仓库，由数据仓库之父Bill Inmon 在1991 年出版的“Building the Data Warehouse”定义且被广泛接受的——面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。从定义上来看，数据仓库的关键词为面向主题、集成、稳定、反映历史变化、支持管理决策，而这些关键词的实现就体现在分层架构内。

说到数仓不可避免的和传统的数据库进行比对：

所以数仓是面向分析型的，主要集中在数据的ETL、数仓模型的建立、数据治理、数据质量的监控、数据资产的沉淀、数据指标体系的搭建，为了方便快速的达到数据获取和数据支撑的目的，同时规避了数据指标不统一造成的数据准确性不足的问题以及重复建设的冗余而建立的一套公司层面或者业务支撑层面的一套规范化数据流向的方案。

2. 目的

数仓的核心是解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题，并提供给分析人员一个清晰可用的展现层，方便快速的业务支撑。

3. 特征

1. 集成（面向主题）

数据是分散的，由于事务处理应用分散、蜘蛛网问题、数据不一致问题、外部数据和非结构化数据。数据仓库中的数据是为分析服务的，而分析需要多种广泛的不同数据源以便进行比较、鉴别，因此数据仓库中的数据必须从多个数据源中获取，这些数据源包括多种类型数据库以及文件系统等，它们通过数据集成而形成数据仓库中的数据。

这块的集成主要集中在数据源大量的数据预处理工作（ETL），通常的模型方式是通过E-R模型进行数据整合。目的将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。

特点：

一般是公司总栈层面的整合，所以需要全面了解企业业务和数据；实施周期非常长，需要整合全部的数据，并在企业业务角度对数据进行相似性组合和合并，并进行一致性处理；对建模人员的能力要求非常高；

2. 相对稳定（非易失）

数据仓库中的数据是经过抽取而形成的分析型数据，不具有原始性，主要供企业决策分析之用，执行的主要是‘查询’操作，一般情况下不执行‘更新’操作。同时，一个稳定的数据环境也有利于数据分析操作和决策的制订。

但这也不等于数据仓库中的数据不需要‘更新’操作。一般来说会建立数仓模型一些数据的生命周期管理，依据数仓数据的重要程度、数据调用情况等等指标，对已有的数据进行规范化管理。

3. 反映历史变化（全量或者增量变更）

数据仓库中的数据必须以一定时间段为单位进行统一更新，因为数仓数据是支撑公司层面业务数据从开始到发展过程中的所有数据变化，所以需要进行数据全量存储，并记录历史变化的过程，方便业务数据能够溯源。

合并全量数据的方式有三种，分别为全量更新、增量变更及增量流水。

全量更新，数据抽取时把源系统表的数据全量抽取过来，这个一般是每天建立一个时间分区，保留全量的数据，不过缺点很明显就是太占存储空间。

增量变更及增量流水，数据抽取时把源系统表内变化的数据抽取过来。两者区别是，增量变更的数据除了包含新增数据外，还包含对历史数据有变更的数据，而增量流水的数据只包含新增数据。

增量流水的数据处理方法相对简单，直接把增量数据入库到表内即可。增量变更的数据一般采用拉链模型来处理，这样既保证可以查询到任意时刻的历史全量快照，也可以减少数仓的存储空间。

然而，拉链模型有两个明显的缺陷，一个是当发现拉链表内某一扣环的数据异常时，拉链表应如何恢复准确性与完整性，另一个是随着数据不断增加，拉链表会越来越大，每日拉链操作的效率会越来越低。

所以在拉链和全量更新的时候，是根据业务表的具体情况来进行选择的。一般来说，数据量很大，但是每天更新的占的比重很少，才会选择拉链的模式。

数仓建设解决的痛点：

使用门槛高：数据工作是一个专业性特别强的一个工作，对于人员的要求比较高。在一些数据的工作当中需要人员有专业的数据基础能力，这样就导致了数据人力的缺失，可能会影响业务的数据支持力度；

口径不一致：在使用数据过程当中，口径不一致是特别常见的一种问题，这种问题可能会导致一种数据使用和分析的差异，而且会降低业务的数据分析效率，最终对业务决策造成严重影响；

数据可靠性低：在生产过程中，降低业务的数据分析效率，最终会对业务决策造成严重的影响，不仅数据链路过程很长，其中还会引入很多数据质量问题。并且，由于环节过多，也带来了生产时间延迟的问题，可能直接影响到后续核心报表，推荐、模型的优化；

跨业务难度大：因为缺少一个统一的数据建设的规划、标准和规范，所以难以指导各个业务或者整个生产链路的各个环节，以拥有一个标准化的生产和处理过程，就导致了多个业务的数据难以融合，难以发挥更大的数据价值；

接入成本高：这主要应用在一个新的业务场景下，也就是说，如果有新的业务接入或者新的场景需要使用数据，很多工作都需要人工处理。去申请各种资源、权限、找数据并且串联整个数据的采集、生产、计算、同步和展示等各个环节，这是一个耗时长、效率低，最终还是很容易出错的过程；

获取数据难：可能在大家日常工作中会发现，我们数据的生产到最终使用，中间可能要经历一个比较长的时间周期或者一个比较宽的团队跨度，用户可能无法很快地找到想要的数据，或者数据团队生产出来的数据并没有真正触达到业务，来达到它的数据价值；

数据资产模糊：这个点可能和获取数据难有一点点关联，数据资产模糊的话更多的是在说我们需要对公司的数据资产做一个整体的管理，如果没有这个整体的管理，就会导致对数据资产的级别和我们自己拥有什么数据资产都很模糊。最终就是导致数据的优势难以发挥出来，而且虽然我们耗费了很多计算资源、人力资源、存储资源，但没有带来相应的价值，最终导致资源效率极低。

针对上面的痛点，一般来说先是能够达到快速的业务支撑的目的，在期间不可避免的出现重复建设和数据指标不统一的问题，在业务发展到一定程度再去补充数据治理的能力和数据指标监控能力能力。

治理工作的内容主要包括对数据和任务进行日常审计，然后通过数据血缘和使用情况，对数据的冗余度进行有效评估，并进行相应的优化，以减少资源和人力的浪费。

同时在生产过程中，如果出现生产不稳定的情况，我们也可以快速地发现问题，进而优化整个的生产链路，提高整个数据生态的健康度。

不过有一点，在数仓模型建设过程中，需要先规范好一些维度：

数据表创建的约束性：比如我们需要对表有的命名规范要求，如果没有一个工具去管理，可能会因为大家对规范的理解不一致，最终导致落地过程中依然存在各种各样的差异性；

数据信息的可描述性：指在创建表的过程中，为了快速地满足业务，很少去添加一些相关的描述信息，导致数据缺少描述性。所以需要要求用户在数据创建的过程中把信息描述的足够精细，方便后续的数据使用过程；

数据建模体系的完整性：指在数据开发过程中，要有整体的业务考虑，落地一些通用性的维表，避免用户为了快速地满足业务需求跳过某些过程，最终导致建模的扩展性较差；

4、数据关系的维度与指标管理的系统性：数据的血缘关系、数据指标建立的标准、对外输出统一的指标和维度，促使我们后续数据表和字段的相互关系是有记录可查询的，而且数仓的指标是唯一和准确的。

当然上面针对具体的公司，数仓这块的侧重点可能不一样，需要做的工作也不尽相同。目前我们公司的架构如图：

三、维度建模介绍

1. DW/BI架构：

源事务：业务库或者日志等各个方面的数据源，一般不维护历史信息。

ETL：目的是构建和加载数据到展现区的目标维度模型中，划分维度和事实。

模型：围绕业务过程度量事件进行构建，为满足用户无法预估的需求，必须包含详细的原子数据。

为避免数据的冗余存储造成的浪费和低效，并方便多业务部门查询方便以及同一指标的数据准确性和业务的扩展性，一般采取以下的架构模式：

2. 维度建模

用于度量的事实表，事实表一般会有两个或者多个外健与维度表的主键进行关联。事实表的主键一般是组合健，表达多对多的关系。

用于描述环境的维度表，单一主键。维度表的属性是所有查询约束和报表标示的来源。维度提供数据的入口点，提供所有DW/BI分析的最终标识和分组。

所以维度建模表示每个业务过程包含的事实表，事实表里面存储事件的数值化度量，围绕事实表的是多个维度表，维度表包含事件发生的实际存在的文本环境。

从图表中能看出来，维度模型（星型模型）比较简单，而且适于变化，各个维度的地位相同。可根据业务情况进行新增或者修改（只要维度的单一值已经存在事实表中）。

雪花模型：

维度建模主要是4个主要决策：

选择业务过程

业务过程是通常表示的是业务执行的活动，与之相关的维度描述和每个业务过程事件关联的描述性环境。

通常由某个操作型系统支持，例如：订单系统。

业务过程建立或获取关键性能度量。

一系列过程产生一系列事实表。

声明粒度

粒度传递的是与事实表度量有关的细节级别。

精确定义某个事实表的每一行表示什么。

对事实表的粒度要达成共识。

确认维度

健壮的维度集合来粉饰事实表。

维度表示承担每个度量环境中所有可能的单值描述符。

确认事实

不同粒度的事实必须放在不同的事实表中。

事实表的设计完全依赖物理活动，不受最终报表的影响。

事实表通过外健关联与之相关的维度。

查询操作主要是基于事实表开展计算和聚合。

其中粒度是非常重要的，粒度用于确定事实表的行表示什么，建议从关注原子级别的粒度数据开始设计，因为原子粒度能够承受无法预估的用户查询，而且原子数据可以以各种可能的方式进行上卷，而一旦选择了高粒度，则无法满足用户下钻细节的需求。

事实是整个维度建模的核心，其中雪花模型或者星型模型都是基于一张事实表通过外健关联维表进行扩展，生成一份能够支撑可预知查询需求的模型宽表，而且最后的查询也是落在事实表中进行。

目前常见的维度模型：

星型模型

每一个维表都与都与事实表相关联。数据冗余量较大

雪花模型

有些维表可能不与事实表直接关联，而是通过其他维表关联到事实表。数据冗余量较小

星座模型

由多个事实表相组合，维表是公共的。企业中一般都是星座模型

注意：

维度表的唯一主键应该是代理健而不是来自系统的标示符，也就是所谓的自然健，因为自然键通常具有一定的业务含义，但日久天长，这些信息是有可能发生变化的，而代理健可以提高关联效率并将关系数据库设计和业务的解耦。

维度表和事实表关联的每个连接应该基于无含义的整数代理健。

固定深度层次在维度表中应该扁平化，规范化的雪花模型不利于多属性浏览，而且大量的表和连接操作会影响性能。

非完全独立的维度应该合并为一个维度，将同一层次的元素标示为事实表中不同维度是错误的，会增加查询和存储负担，最后变成蜈蚣表，例如：日维度、周维度、月维度等可以合并为一个周期维度。

四、维度建模案例

维度建模是一个迭代设计过程，设计工作从总线矩阵中抽取实体级别的初始图形化模型开始，详细建模过程要深入定义、资源、关系、数据质量问题以及每张表的数据转换，主要目标是建立满足用户需求的模型，校验可加载到模型中的数据，为ETL提供明确的方向。

1. 雪花模型案例

这是一个以客户创建为事实表的售前流程的雪花模型。

事实表：客户创建信息表

维度表：销售信息表、店铺信息表、跟进表/约见表/风控通过表/订单表的维度上卷。

以上面的维度模型可以聚合出创建、跟进、风控等各个维度的上层展现的数据。

2. 扩展：实时即未来

目前不少公司都在尝试以Flink、Kudu为基础的实时数仓架构，里面的数仓分层模型和离线的数仓架构基本相同。

下图为实时数仓架构，离线和实时的差不多，具体实时的架构图见：

ODS原始层是存放原始数据，主要是埋点数据（日志数据）和业务操作数据（binlong），数据源主要是Mysql、HDFS、Kafka等

DW中间层主要存放ETL和主题汇总之后的中间层数据，这块又分为：

DWD：事实表（data warehouse detail） 数据仓库明细表，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。

DWS：事实表 （data warehouse summary） 数据仓库轻度汇总层，按照各个业务域进行轻度汇总成分析某一个主题域的服务数据，一般是宽表。

DIM：维度表，公共维度层，基于维度建模理念思想，建立整个业务过程的一致性维度，主要使用 MySQL、Hbase、Redis 三种存储引擎，对于维表数据比较少的情况可以使用 MySQL，对于单条数据大小比较小，查询 QPS 比较高的情况，可以使用 Redis 存储，降低机器内存资源占用，对于数据量比较大，对维表数据变化不是特别敏感的场景，可以使用HBase 存储。

DM数据集市层，以数据域+业务域的理念建设公共汇总层，对于DM层比较复杂，需要综合考虑对于数据落地的要求以及具体的查询引擎来选择不同的存储方式，分为轻度汇总层和高度汇总层。

轻度汇总层以宽表的形式存在，主要是针对业务域进行快速方便的查询；

高度汇总层由明细数据层或轻度汇总层通过聚合计算后写入到存储引擎中，产出一部分实时数据指标需求，灵活性比较差，主要做大屏展现。

理论上上面还一APP层，应用层，主要是通过这几层之后，生成轻度或者高度汇总的数据，然后根据业务域进行接口封装提供给上层使用。但是实时数仓面临以下几个实施关键点：

端到端数据延迟、数据流量的监控；

故障的快速恢复能力；

数据的回溯处理，系统支持消费指定时间段内的数据；

实时数据从实时数仓中查询，T+1数据借助离线通道修正；

业务数据质量的实时监控；

思考：

实时数仓架构和数据中台一样，虽然都是属于当前比较热门的概念，但是对于实时数仓的狂热追求大可不必。

首先，在技术上几乎没有难点，基于强大的开源中间件（例如：Flink、kudu等）实现实时数据仓库的需求已经变得没有那么困难。

其次，实时数仓的建设一定是伴随着业务的发展而发展，武断的认为实时数仓架构最符合当前公司的需求是不对的。实际情况中随着业务的发展数仓的架构变得没有那么非此即彼。

最后，如何顺畅的将传统的离线数仓+实时链路处理流程升级到实时数仓架构是个很大的问题，毕竟中间涉及到很多的数据模式、技术中间件、计算引擎都不太一样。

常见的数仓命名规则：前缀（ODS/DWD/MID）+主题域（user/shp）+业务类型+自定义表名+后缀（dd/ds/pi）

五、数仓分层

数据仓库分层没有绝对的规范，适合的就是最好的，特别是企业已经有一个初版的数仓的时候，需要做好改造成本和可理解性之间的平衡。

数据仓库是一套方法论，从规范定义、模型设计到数据服务，再到数据可管理、可追溯、可复用。

很多人都关注数仓分层的具体分法和逻辑，而且目前市场上主流的分层方式眼花缭乱，不过看事情不能只看表面，还要看到内在的规律，不能因为分层而分层。

分层的目的解决当前业务快速的数据支撑目的，为未来抽象出共性的框架并能够赋能给其他业务线，同时为业务发展提供稳定、准确的数据支撑，并能够按照已有的模型为新业务发展提供方向，也就是数据驱动和赋能。

好分层架构，有以下好处：

清晰数据结构：每一个数据分层都有对应的作用域，在使用数据的时候能更方便的定位和理解。

数据血缘追踪：提供给业务人员或下游系统的数据服务时都是目标数据，目标数据的数据来源一般都来自于多张表数据。若出现目标数据异常时，清晰的血缘关系可以快速定位问题所在。而且，血缘管理也是元数据管理重要的一部分。

减少重复开发：数据的逐层加工原则，下层包含了上层数据加工所需要的全量数据，这样的加工方式避免了每个数据开发人员都重新从源系统抽取数据进行加工。

数据关系条理化：源系统间存在复杂的数据关系，比如客户信息同时存在于核心系统、信贷系统、理财系统、资金系统，取数时该如何决策呢？数据仓库会对相同主题的数据进行统一建模，把复杂的数据关系梳理成条理清晰的数据模型，使用时就可避免上述问题了。

屏蔽原始数据的影响：数据的逐层加工原则，上层的数据都由下一层的数据加工获取，不允许跳级取数。而原始数据位于数仓的最底层，离应用层数据还有多层的数据加工，所以加工应用层数据的过程中就会把原始数据的变更消除掉，保持应用层的稳定性。

一般来说数仓分层有以下几个共性：

源系统数据归集到数仓的缓冲层，或称为贴源层（ODS）；

主要收集来自各业务线或行业内的外部数据并对数据进行汇总，ODS层不承担任何的数据清洗和治理的工作，在数据上和业务系统保持一致，ODS层采用分区表的形式按批次存储据,ODS层保留了业务系统的原始数据，不对外开放查询。

ODS层主要以全量方式同步数据，保留全量数据恢复的能力，同步的数据为T+1的新增和变更记录，永久保存历史数据。

数据仓库层，具备数据标准化及合并全量数据的标准层，其中数仓建模主要集中在这一层（DW）。

具备主题划分及明细数据整合的主题层（DM）。

具备提供数据服务给下游系统使用的集市层，或称为应用层（APP）；

当然这个分层可以进一步拆分，其中最主要的是DW层的模型建立：

其实相对来说数仓模型的建设并不复杂，只要关注以下几点就行：

OneData：数仓所有数据只加工一次，对应到数仓的设计层面，要求有统一的维度，对于明细层数据，相同粒度的度量只加工一次，对于汇总层的数据，相同粒度的指标只存在一份。避免重复建设的问题；

OneIndex：数仓指标体系都具有唯一性，通过原子指标+派生指标来规范所有的指标系统，避免数据不一致性的问题；

OneService：数据服务划清了数据和应用的边界，数据服务提供的是加工好的指标数据，应用通过数据服务，直接获取计算的结果，强制把公共计算逻辑下沉到数据层面，提高了数据的共享能力，避免通过不同层次获取数据导致的数据准确性和安全性的问题；

OneLine：最大程度上保障数据流转的透明性，不同层级做不同层级的数据处理逻辑，不可逆向依赖，方便后续数据血缘关系、数据地图的建立，避免数据杂乱，无法溯源；

OneEntity：这块主要是模型方面的建设，同一个用户，在同一个模型中，可能存在重复的记录，如何识别两个 ID 是同一个用户，做到所有用户只有唯一的 ID 标识，这个是 OneEntity 要解决的问题，其实归根结底就是ID-Mapping问题。

六、问题

1. 维度建模的缺点

维度建模之前需要进行大量的数据预处理，因此会导致大量的数据处理工作（ETL）。

当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。

如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。

维度建模的领域主要适用与数据集市层，它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。

当前公司的数仓模型架构：

首先对ETL得到的数据进行ER建模，关系建模，得到一个规范化的公司层面的数据仓库模式。然后用这个中心仓数据库为公司各部门建立基于维度建模的数据集市。

而维度建模都集中在各个DM层里面，也就是针对具体的业务线或者主题域，这样紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。

2. 分层的误区

数仓层内部的划分不是为了分层而分层，分层是为了解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题。

业界较为通行的做法将整个数仓层又划分成了 dwd、dwb、dws、dim、mid 等等很多层。然而我们却始终说不清楚这几层之间清晰的界限是什么，或者说我们能说清楚它们之间的界限，复杂的业务场景却令我们无法真正落地执行。

所以数据分层这块一般来说三层是最基础的：

至于DW层如何进行切分，是根据具体的业务需求和公司场景自己去定义，一般来说需要：

分层是解决数据流向和快速支撑业务的目的；

必须按照主题域和业务域进行贯穿；

层级之间不可逆向依赖。

如果依赖ODS层数据可以完成数据支撑，那么业务方直接使用落地层这也有利于快速、低成本地进行一些数据方面的探索和尝试。

确定分层规范后，后续最好都遵循这个架构，约定成俗即可；

血缘关系、数据依赖、数据字典、数据命名规范等配套先行；

DW 内的分层没有最正确的，只有最适合你的。

3. 宽表的误区

在数仓层开始引入了宽表。所谓宽表，迄今为止并没有一个明确的定义。通常做法是把很多的维度、事实上卷或者下钻之后关联到某一个事实表中，形成一张既包含了大量维度又包含了相关事实的表。

宽表的使用，有其一定的便利性。使用方不需要再去考虑跟维度表的关联，也不需要了解维度表和事实表是什么东西。

但是随着业务的增长，我们始终无法预见性地设计和定义宽表究竟该冗余多少维度，也无法清晰地定义出宽表冗余维度的底线在哪里。

一个可能存在的情况是，为了满足使用上的需求，要不断地将维表中已经存在的列增加到宽表中。这直接导致了宽表的表结构频繁发生变动。

目前我们所采用的做法是：

根据主题域和业务域，将某个业务的所有节点梳理清楚；

将关键节点的数据作为事实表依据，然后横向扩充其他事实表上卷数据（包含一些统计指标），同时纵向的添加该节点上一些主键对应的维度；

宽表的涉及不依赖具体的业务需求而是根据整体业务线相匹配；

尽量用维度建模代替宽表；

为什么说尽量用维度建模代替宽表，就算字段和数据会冗余，维度建模的方式也会表全量数据的宽表模式较好，原因：

维度建模是以某一个既定的事实为依据，既然是事实表，那么这块的业务如果不变动的情况下，事实表的粒度基本不会改变；

事实表和维度表解耦，维度表的变更事实表基本不会影响，结果表也只需要回刷一下数据流程即可；

新增维度完全可以按照星型模型或者雪花模型动态添加新维度；

维度模型可以作为宽表的基础，一旦确定全部的数据流程，可以通过维度模型再生成对应宽表进行快速的业务支撑；

4. 指标管理

数仓模型中，最重要的模块可能就是数据治理，我们在建立数仓分层的时候，虽然解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题，但是在给业务方提供不同数据需求的情况下不可避免的会发生一下几个问题：

指标定义不够清晰明确，两个页面上的指标定义其实是不同的，但是展示给商家看到的可能是同一个中文名称。又或者同样一个含义的指标在不同的界面上展示的名称却不相同，让人产生歧义。

同一个指标因为由不同的数据开发同学来制作，可能会被重复开发，不但造成资源浪费，还会造成维护困难。

对于需要新开发的指标，不仅缺少开发工具简化开发流程，甚至该使用哪些表，不该使用哪些表很大程度上都要凭借数据开发同学与数仓同学的经验。如果稍微马虎一点或者缺乏经验，比如使用了某些业务域下特有的表或者不是由数仓提供的统一中间层的表就可能会使用错误的数据，造成后期返工等情况。

而且在数据需求越来越多，数据中台提供的指标也日益丰富。但是指标定义混乱，描述不清会严重影响数据的可信度和数据开发的成本，所以就需要搭建一个指标系统，来维护已有的数据指标，并为未来可能新增的指标建立相应的规范。

如何去建立好这个指标库或者指标系统呢。

一般来说指标系统主要分为：原子指标和派生指标

在数仓分层的时候，进行维度建模，那么就必须指定好相应的主题域和事实表处理的最小逻辑（也就是事实），那么在这个基础上可以先定义原子指标。

原子指标：原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词 ，如支付金额。原子指标描述的其实是一种指标的类型，比如订单支付金额，支付订单数，下单订单数，PV，UV 等等。但是仅仅一个原子指标是不能直接取数的。

但业务方更关心的指标，是有实际业务含义，可以直接取数据的指标。比如店铺近1天订单支付金额就是一个派生指标，会被直接在产品上展示给商家看。这个指标却不能直接从数仓的统一中间层里取数（因为没有现成的事实字段，数仓提供的一般都是大宽表）。需要有一个桥梁连接数仓中间层和业务方的指标需求，于是便有了派生指标。

派生指标=维度+原子指标+修饰词。当维度，原子指标，修饰词都确定的时候就可以唯一确定一个派生指标，同时给出具体数值。

例如：店铺近1天订单支付金额中店铺是维度，近1天是一个时间类型的修饰词，支付金额是一个原子指标。

业务方制作每一个派生指标都是通过选择维度，原子指标，修饰词三种元数据来定义的，相对于使用名称来区别不同指标，更可以保证指标的唯一性。如果2个派生指标是不同的，那他们的组成部分一定会有区别，或是不同维度，或是不同原子指标，修饰词。

所以在指标管理的过程中，指标库给予每个指标一个精确且唯一的定义。通过指标库可以快速且规范的查询，开发和使用指标。

指标库主要提供如下服务：

通过设置指标的组成要素来唯一精确定义每个指标（派生指标）。

通过指标在业务域内唯一的性质，解决指标重复定义，重复开发，部分数据对不上的问题。

通过将数仓中间层录入指标库为新制作指标提供指导性的 SQL 或库表推荐。

打通其他各数据平台：

打通数据开发平台和统一数据服务平台，为指标的定义，调度，在线使用提供一条龙服务，简化开发流程。

打通数据资产管理平台，沉淀指标的资产价值。

打通 BI 平台，提供拖拽维度，指标生成报表的功能。

其中派生指标的生成是通过：业务域+维度+原子指标+修饰词来唯一确定的。

在数仓搭建的时候，业务域、维度、原子指标都是已经明确的，而修饰词是维度的某一些特殊的值，对应 SQL 中的 where 过滤条件。所以如果在数据产品的层面在某个业务域对指标数据定义、生产、使用等过程的流程规范化与平台化，那么就能够从源头上解决上面出现的数据指标不统一、重复开发、指标体系不好维护的问题。