数据仓库篇数据集市落地方案

Posted 2021-04-24 大数据漫路求索

一、文章概述

数据集市可以分为两层，第一层为数据多维明细层，第二层为汇总层：

1. 多维明细层：多维明细层的数据为业务过程的原子粒度数据，可以直接从数据中台的DWD层直接读取。

2. 应用汇总层：数据集市的汇总数据多为各个业务部门的个性化统计需求，数据可以直接来源于数据中台的DWS/ADS层，同时也可以通过数据集市的基本多维明细层数据加工汇总而来。

二、数据集市的建设方法论

三、收集业务需求

数据集市往往是针对一类业务场景集中对数据进行分析，因此，需要统计的数据量和维度只局限在某个应用范围内，同时，他是直接面向具体的应用，因此数据集市中往往具备数据仓库中缺少的针对性衍生信息，例如指标、标签等。

基于以上场景，我们的数据小组成员可以按照需求整理文档。但是，我们并不是为了做报表需求而做设计开发工作，报表往往都是最终的指标。

四、文档化需求

访谈后紧接着做的事情就是，完成访谈详细报告。笔记中的缩略词和记录不全的句子在几天之后会变得难以理解。在完成合并文档时，应该撰写执行综合文档（项目概述）。总体上说，文档要以业务过程为中心。对每个业务过程，要描述业务方期望的指标度量。同时，处理每个过程的可行性评论也是很有必要的。

五、需求优先级

不可能一次迭代就能完成所有需求，因此有必要和团队的负责人、业务方协商优先级。可以考虑按照“潜在的业务价值”和“需求可行性”两个方面综合考虑优先级。

六、补充数据中台建设

数据中台主要是为了服务好数据集市，在整理数据集市的业务需求之后，我们需要追溯数据是否可以从数据中台生成，如果中台中没有，那么需要联系中台同学进行建设。数据中台要100%覆盖数据集市。数据中台的建设思路必须是维度建模思想。

数据中台主要是建设一些公用、最细粒度的事实表和维度表。以服务数据集市，由于数据集市的需求明确，我们可以在业务指标中，提炼出各个指标的业务过程。将各个业务过程的数据到中台中核对。

主要是解决掉数据集市从基础数仓，甚至ODS层直接提取数据的问题。基础数仓无论从主题还是数量级方面都不适合数据集市直接提取数据。

参见【数据仓库篇】数据中台落地方案

八、规划数据域和业务过程

在理解需求之后进行数据域和业务过程的划分，数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。数据域需要抽象提炼，并且长期维护。在划分数据域时，既能涵盖当前所有业务需求，又能保证在新业务进入时无影响的被包含到已有的数据域中。

业务过程是指公司的业务活动事件，如支付，退款都是业务过程。业务过程是一个不可拆分的行为事件。业务过程中的事件度量最终转化为事实表中的事实。每个业务过程对应着数据仓库总线矩阵的一行。

确定业务过程通常按照需求获取的结果来确定。优先的活动可以确定哪个总线矩阵行（以及由此产生的业务过程）将首先被建模。以此为基础，小组可以开始相关设计工作。

避免重复性建设，以及建设混乱，需要在系统里面编辑数据域和业务过程。同时为数据域和业务过程进行编码，方便后续建立数据仓库表做参考。

数据域

缩写

业务过程

九、确定统计粒度

声明粒度是维度设计的重要步骤，粒度用于确认某一事实表中的行表示什么，每个候选的维度和事实表必须与粒度保持一致。

由于数据中台属于公用数据，数据明细层的统计粒度建议到原子指标粒度（不能再往下拆分了），多维数据汇总层的统计粒度可以按照修饰词和维度的组合做一些汇总。

以维度建模作为理论基础，构建数据总线矩阵，划分和定义数据域，业务过程，维度，度量/原子指标，修饰类型，修饰词、时间维度、派生指标等。一般的指标体系可以划分为：原子指标、派生指标、修饰类型、修饰词、时间周期。

在拆分好原子指标、修饰词、时间周期就能够顺利的编写数据矩阵。

总线矩阵的编写参考【数据仓库篇】数据中台建设规范

十、确定维度及其属性

维度提供围绕某一业务事件所涉及的“谁、什么、何处、何时、为什么、如何”等背景，牢牢的掌握事实表的粒度，就能方便的设计出维度表。在详细设计阶段，将定义关键的一致性维度。因为数据中台是整个集团的资源，所以这些定义必须为集团所接受。数据管理人员和业务分析师是获得一致认可表和属性命名、描述和定义的关键资源。数据小组将主导该过程的展开并利用命名规则（目前有一套规则，需要不断完善）。需要对标准的业务定义和名称达成一致。

维度表是对分析主题所属类型的描述。比如“2018年8月21日在北京花了600万元买了一套房”，从这段信息中需要提取三个维度：时间维度（2018年8月21日），地点维度（北京），商品维度（房）。

dim表命名规范参见【数据仓库篇】数据中台建设规范

十一、确定事实

声明粒度是对事实表度量讨论的成果，因为事实都必须和粒度保持一致。在对业务需要做深入的分析之后，需要按照数据矩阵设计出事实表，事实表是对分析主题的度量。比如上面的例子，600万元就是事实信息。事实表包含了与各个维度想关联的外键码。事实表的度量通常是数值类型。

事实表主要有三种形式存在，模型设计人员需要根据具体情况创建相应的事实表。

事实表类型={transaction=>事务事实表,periodic=>周期快照事实表,accumulating=>累计快照事实表}

特点	事务事实	周期快照事实	累积快照事实
时间/时期	时间	时期	时间跨度较短的多个时点
粒度	每行代表一个交易事件	每行代表一个时间周期	每行代表一个业务周期
事实表加载	新增	新增	新增和修改
事实表更新	不更新	不更新	新事件产生时更新
时间维	业务日期	时期末	多个业务过程的完成日期
事实	交易活动	时间周期内的绩效	限定多个业务阶段内的绩效

在数据中台中，逻辑（物理）表的命名规范参见【数据仓库篇】数据中台建设规范

11.1 确定缓慢变化维

根据高层模型图和总线矩阵初步设计好维度表和事实表之后，应当再次考虑维度表的建设。针对维度表的每个属性，需要定义在源系统中发生变化时，对维度表会产生哪种影响。

11.2 建立详细的表设计文档 参考《主题域_事实表维度表样例.xlsx》

应该为每个维表和事实表建立不同个工作单。支持信息至少包括属性/实施名称、描述、示例值、每个维度属性的缓慢变化维类型标识。此外，详细的事实表设计应该确认每个维度键关系、适当的退化维度，以及事实表是可加、半可加还是完全不可加的相关规则。

11.3 维护更新总线矩阵

在详细建模过程中，通常对被建模的业务过程会有新的发现。常见的情况是，这些新发现往往会引入新的事实表以支持业务过程，可能产生新的维度，也可能需要重新规划或合并维度。在整个的设计过程中，始终要保持对总线矩阵的实时更新。

11.4 模型评审与验证

一旦数据小组对设计的模型充满信心之后，将进入到模型评审中，从以下小组获得反馈意见

1. 系统资源暂用评估

2. 业务方对模型的认可度，非常建议和业务方一起探讨模型，主要评估模型出的数据能否满足需求

11.5 形成完善的设计文档

在模型稳定之后，应该对设计小组的工作文件进行编制，生成设计文档。

项目的简短描述

1. 高级模型图

2. 详细的事实表和维度表设计图