1.数据仓库的概念
数据仓库是一个为数据分析而设计的企业级数据管理系统。数据仓库可集中、整合多个信息源的大量数据，借助数据仓库的分析能力，企业可从数据中获得宝贵的信息进而改进决策。同时，随着时间的推移，数据仓库中积累的大量历史数据对于数据科学家和业务分析师也是十分宝贵的。
目前大数据平台的架构有以下三种架构:
① 数据仓库(Data Warehouse)是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化的（Time Variant）数据集合，用于支持管理决策和信息的全局共享。
② 数据湖（Data Lake）是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。数据湖是以其自然格式存储的数据的系统或存储库，通常是对象blob或文件。
③ 湖仓一体(Data LakeHouse): 为企业提供一个统一的、可共享的数据底座，避免传统的数据湖、数据仓库之间的数据移动，将原始数据、加工清洗数据、模型化数据，共同存储于一体化的“湖仓”中，既能面向业务实现高并发、精准化、高性能的历史数据、实时数据的查询服务，又能承载分析报表、批处理、数据挖掘等分析型业务。
1.1数据仓库的核心架构
1.2 数据仓库建模的意义
如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措。
数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后，数据才能得到高性能、低成本、高效率、高质量的使用。
高性能：良好的数据模型能够帮助我们快速查询所需要的数据。
低成本：良好的数据模型能减少重复计算，实现计算结果的复用，降低计算成本。
高效率：良好的数据模型能极大的改善用户使用数据的体验，提高使用数据的效率。
高质量：良好的数据模型能改善数据统计口径的混乱，减少计算错误的可能性。
1.2 数据仓库建模方法论
1.2.1 ER模型
数据仓库之父Bill Inmon提出的建模方法是从全企业的高度，用实体关系（Entity Relationship，ER）模型来描述企业业务，并用规范化的方式表示出来，在范式理论上符合3NF。
1）实体关系模型
实体关系模型将复杂的数据抽象为两个概念——实体和关系。实体表示一个对象，例如学生、班级，关系是指两个实体之间的关系，例如学生和班级之间的从属关系。
2）数据库规范化
数据库规范化是使用一系列范式设计数据库（通常是关系型数据库）的过程，其目的是减少数据冗余，增强数据的一致性。
这一系列范式就是指在设计关系型数据库时，需要遵从的不同的规范。关系型数据库的范式一共有六种，分别是第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF）。遵循的范式级别越高，数据冗余性就越低。
3）三范式
省略………………
下图为一个采用Bill Inmon倡导的建模方法构建的模型，从图中可以看出，较为松散、零碎，物理表数量多。
这种建模方法的出发点是整合数据，其目的是将整个企业的数据进行组合和合并，并进行规范处理，减少数据冗余性，保证数据的一致性。这种模型并不适合直接用于分析统计。
1.2.2 维度模型
数据仓库领域的令一位大师——Ralph Kimball倡导的建模方法为维度建模。维度模型将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。
注：业务过程可以概括为一个个不可拆分的行为事件，例如电商交易中的下单，取消订单，付款，退单等，都是业务过程。
下图为一个典型的维度模型，其中位于中心的SalesOrder为事实表，其中保存的是下单这个业务过程的所有记录。位于周围每张表都是维度表，包括Date（日期），Customer（顾客），Product（产品），Location（地区）等，这些维度表就组成了每个订单发生时所处的环境，即何人、何时、在何地下单了何种产品。从图中可以看出，模型相对清晰、简洁。
维度建模以数据分析作为出发点，为数据分析服务，因此它关注的重点的用户如何更快的完成需求分析以及如何实现较好的大规模复杂查询的响应性能。
1.3维度建模之事实表
事实表是维度建模的核心表和基本表。
它存储了业务过程中的各种度量和事实，而这些度量和事实正是下游数据使用人员所要关心和分析的对象。
目前事实表主要探讨三种：
- · 事务事实表
- · 快照事实表
- · 累计快照事实表
还有一种特殊的事实表——无事实的事实表，最后还将讨论事实表的聚集和汇总。
1.3.1事务事实表
事务事实表是维度建模事实表中最为常见、使用最为广泛的事实表。
事务事实表通常用于记录业务过程的事件，而且是原子粒度的事件。事务事实表中的数据在事务事件发生之后，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改。
我们通过事务事实表存储单次业务事件 / 行为的细节，以及存储与事件相关的维度细节，用户即可以单独或者聚合分析业务事件和行为。
事务事实表的粒度确定是事务事实表设计过程中的关键步骤，一般都会包含可加的度量和事实。理解概念的最佳途径无疑是实际的例子，因此下面将结合超市零售业务以及维度建模的四个环节来说明事务事实表。
（1）选择业务过程
在超市的零售示例中，业务用户做的事情是更好的理解POS系统记录顾客购买的情况，那么很容易确定业务过程就是POS系统记录的顾客购买情况，即在什么时候、什么商品、哪个收银台、销售了哪些产品等。
（2）定义粒度
顾客单次购买行为的体现是一张购物小票，但是事务事实表应该选择最原子粒度的事件，所以小票的子项（在业务上的动作即为收银员每次扫描的商品条码）应该是超市零售事务事实表的粒度。
（3）确定维度
小票子项的粒度确定后，销售日期、销售商品、销售收银台、销售门店等维度很容易被确定了。另一个不太容易考虑到的是维度是促销行为，但是通过和业务人员交流或者查看报表表头等也能够发现此维度。
（4）确定事实
维度设计的最后一步，是确定哪些事实和度量应该在事实表中出现。对于本例，商品销售数量、销售价格和销售金额很容易确定下来。但是实际上，商品的成本价是确定的，因此可以很容易地确定商品的销售毛利：（商品实际销售价格－商品成本价） 销售数量，基于下游使用便利这一因素，也应该将此放人事务事实表中。
基于毛利润也可以计算出毛利率，那么毛利率这种比例应该放入事务事实表吗？在事实表的设计中，一个常见的原则是只存放比例的分子和分母，因此比例的计算是和业务强，业务逻辑可能非常的复杂，所以一般不加入事实表中。
至此，我们也完成了超市零售事务的事实表和维度表的设计，超市零售事务事实表以及相关的维度表如图所示：
1.3.2快照事实表
在实际的业务活动中，除了关心单次的业务事件和行为外，很多时候还关心业务的状态（当前状态、历史状态）。以超市零售业务为例，管理人员和分析人员除了关心销售情况，还会关心商品的库存情况，例如哪些商品的库存情况，例如哪些商品库存告罄需要补货、哪些积压需要促销，而这正是快照事实表（也叫周期快照事实表）所要解决发范畴。
所谓周期快照事实表，是指间隔一定的周期对业务的状态进行一次拍照并记录下来的事实表。最常见的例子是销售库存、银行账户余额等。
与事务事实表的稀疏性不同（这里的稀疏性是相对的），周期快照事实表通常被认为是稠密的。因此事务事实表只有事务发生才会记录，但是周期快照则必须捕获当前每个实体的状态。
比如，某个商品如果某天没有销售，那么这个商品不会存在于当天的事务事实表中的，但是为了记录其库存情况，即使没有销售行为，也必须再周期快照事实表中对其进行拍照。
周期快照事实表的周期通常需要和业务方共同确定，最常见的周期是天、周和月等。
周期快照事实表中的事实一般是半可加的，如某个商品的库存可以跨商品、仓库等相加，但是明显在时间上相加是没有意义的。
下面就以超市的库存业务为例来介绍周期快照事实表的设计过程。
（1）选择业务过程
本例是为了更好地理解超市的库存情况，因此业务过程就是商品的库存情况，即在什么时候、什么商品、哪个仓库的库存量如何。
（2）定义粒度
这里的粒度主要指库存的周期，商品的粒度很容易确定（注意这里是 SKU 级别）。选择库存的周期需要考虑到数据量膨胀情况。
考虑如下例子，某个超市有 万个商品（即SKU）， 其有 100 家连锁店，那么每天对其库存拍照将有 100*10000=100 万行记录，那么一年将有 365*1000000=3.65亿条记录。当然随着目前存储的日益廉价，这些都不是问题，但是设计人员需要考虑到这些因素。
（3）确认维度
对于超市零售库存，相应的维度为周期（天 周、月等） 商品、仓库（总仓、分仓或者门店等）。
（4）确定事实
这里的事实很容易确定，即库存量。但是仅仅记录现存库存是不够充分的，因为业务上通常会和其他事实协同来度量库存的变化趋势、快慢等，所以还可对周期快照事实表的事实进行增强 。
基于上述设计的周期快照事实表及相关维度如图所示：
1.3.3累计快照事实表
事实表的第三种类型是累计快照事实表，相比前两者，累计快照事实表没那么常见，但是对于某些业务场景来说非常有价值。
累计快照事实表非常适用于具有工作流或者流水线形式业务的分析，这些业务通常涉及多个时间节点或者有主要的里程碑事件，而累计快照事实表正是从全流程角度对其业务状态的拍照。
考虑车险理赔业务，一次车险的理赔通常包括客户报案、保险公司立案、客户提交理赔材料、理赔审批通过和付款等关键步骤，而累积快照事实表正是从全流程角度对每个车险理赔单的拍照，拍照内容即是其关键步骤的各个状态，便于业务人员一目了然地分析各个理赔单的状态、步骤间的耗时等。
下面以车险理赔业务为例来介绍累计周期快照事实表。
（1）选择业务过程
本例是为了更好地理解保险公司的车险理赔业务，因此业务过程就是车险理赔，即在什么时候、 哪个理赔申请所处的状态如何。
（2）定义粒度
累计周期快照事实表的粒度一般很容易确定，就是业务的某个实体，这里即为保险理赔申请。
（3）确定维度
对于累计周期快照事实表，相关的维度包含快照周期（天、周、月 和年等）、理赔申请人、受理 、审核人、网点 电话或者实体）等。
（4）确定事实
这里的事实包括索赔金额、审批金额、打款金额、处理时长等。
1.3.4无事实的事实表
在维度建模中，事实表是过程度量的核心，也是存储度量的地方 但事实表并不总是需要包含度量和事实，这类不包含事实的事实表被称为 无事实的事实表。
乍一听有点奇怪，但是请考虑下面业务场景，银行客户服务中心接受客户电话咨询或者在线业务咨询，这里并没有任务的业务度量值，唯一的度量值就是单次咨询事件。其他类似事件还有学生课程出席情况、用户在网站上的浏览行为、客户对广告的点击行为等。
无事实的事实表通常人为增加一个常量列（其列的值总是为 1) 来方便对业务时间的统计分析。其实就是类似于事务事实表的特殊情况。
以学生在各门课程中的出席情况为例给出无事实的事实表的维度设计方案：
1.3.5总结
在经典的维度建模事实表设计中，事实表将仅存储维度表外键、选定的度量以及退化维度等，例如我们前面提到的超市零售事务事实表。
这样的设计主要是出于存储的成本以及处理的性能考虑 ，如果把维度的属性字段等都放在事实表中，那么将带来大量的存储开销，而且处理性能也将大大受到影响。但是在大数据时代，随着 HDFS、MapReduce 为代表的各种分布式存储和计算技术的发展，存储成本以及性能等不再是关键，所以在维度建模理论反规范化思想的基础上，可以更进一步地把常用的维度属性沉淀在事实表中，这样下游使用更为直接和便捷，不需要每次都关联相关维度表获取有关维度属性 也就是说，以存储的冗余为代价，换来了下游的使用便捷以及多次关联计算开销，而在大数据时代，这是完全划算的。
1.4 维度建模之维度表
1.4.1 维度表概述
维度表是维度建模的基础和灵魂。前文提到，事实表紧紧围绕业务过程进行设计，而维度表则围绕业务过程所处的环境进行设计。维度表主要包含一个主键和各种维度字段，维度字段称为维度属性。
1.4.2 维度表设计步骤
1）确定维度（表）
在设计事实表时，已经确定了与每个事实表相关的维度，理论上每个相关维度均需对应一张维度表。需要注意到，可能存在多个事实表与同一个维度都相关的情况，这种情况需保证维度的唯一性，即只创建一张维度表。另外，如果某些维度表的维度属性很少，例如只有一个**名称，则可不创建该维度表，而把该表的维度属性直接增加到与之相关的事实表中，这个操作称为维度退化。
2）确定主维表和相关维表
此处的主维表和相关维表均指业务系统中与某维度相关的表。例如业务系统中与商品相关的表有sku_info，spu_info，base_trademark，base_category3，base_category2，base_category1等，其中sku_info就称为商品维度的主维表，其余表称为商品维度的相关维表。维度表的粒度通常与主维表相同。
3）确定维度属性
确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表。维度属性可直接从主维表或相关维表中选择，也可通过进一步加工得到。
确定维度属性时，需要遵循以下要求：
（1）尽可能生成丰富的维度属性
维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源，是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。
（2）尽量不使用编码，而使用明确的文字说明，一般可以编码和文字共存。
（3）尽量沉淀出通用的维度属性
有些维度属性的获取需要进行比较复杂的逻辑处理，例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理，可将这些维度属性沉淀到维度表中。
1.4.3维度的设计要求
1.4.3.1 规范化与反规范化
规范化是指使用一系列范式设计数据库的过程，其目的是减少数据冗余，增强数据的一致性。通常情况下，规范化之后，一张表的字段会拆分到多张表。
反规范化是指将多张表的数据冗余到一张表，其目的是减少join操作，提高查询性能。
在设计维度表时，如果对其进行规范化，得到的维度模型称为雪花模型，如果对其进行反规范化，得到的模型称为星型模型。
数据仓库系统的主要目的是用于数据分析和统计，所以是否方便用户进行统计分析决定了模型的优劣。采用雪花模型，用户在统计分析的过程中需要大量的关联操作，使用复杂度高，同时查询性能很差，而采用星型模型，则方便、易用且性能好。所以出于易用性和性能的考虑，维度表一般是很不规范化的。
1.4.3.2 维度变化
维度属性通常不是静态的，而是会随时间变化的，数据仓库的一个重要特点就是反映历史的变化，所以如何保存维度的历史状态是维度设计的重要工作之一。保存维度数据的历史状态，通常有以下两种做法，分别是全量快照表和拉链表。
1）全量快照表
离线数据仓库的计算周期通常为每天一次，所以可以每天保存一份全量的维度数据。这种方式的优点和缺点都很明显。
优点是简单而有效，开发和维护成本低，且方便理解和使用。
缺点是浪费存储空间，尤其是当数据的变化比例比较低时。
2）拉链表
拉链表的意义就在于能够更加高效的保存维度信息的历史状态。
1.4.3.3 多值维度
如果事实表中一条记录在某个维度表中有多条记录与之对应，称为多值维度。例如，下单事实表中的一条记录为一个订单，一个订单可能包含多个商品，所会商品维度表中就可能有多条数据与之对应。
针对这种情况，通常采用以下两种方案解决。
第一种：降低事实表的粒度，例如将订单事实表的粒度由一个订单降低为一个订单中的一个商品项。
第二种：在事实表中采用多字段保存多个维度值，每个字段保存一个维度id。这种方案只适用于多值维度个数固定的情况。
建议尽量采用第一种方案解决多值维度问题。
1.4.3.4 多值属性
维表中的某个属性同时有多个值，称之为“多值属性”，例如商品维度的平台属性和销售属性，每个商品均有多个属性值。
针对这种情况，通常有可以采用以下两种方案。
第一种：将多值属性放到一个字段，该字段内容为key1:value1，key2:value2的形式，例如一个手机商品的平台属性值为“品牌:华为，系统:鸿蒙，CPU:麒麟990”。
第二种：将多值属性放到多个字段，每个字段对应一个属性。这种方案只适用于多值属性个数固定的情况。
2. 数据仓库的设计与实施
2.1 指导方针
首先，在建设数据仓库时，要进行充分的业务调研和需求分析，业务调研和需求分析做得是否充分直接决定了数据仓库建设是否成功；其次，进行数据总体架构设计，主要是根据数据域对数据进行划分，按照维度建模理论，构建总线矩阵、抽象出业务过程和维度；再次，对报表需求进行抽象整理出相关指标体系，依据工具完成指标规范定义和模型设计；最后，就是代码研发和运维。
2.2. 实施工作流程
2.2.1数据调研
2.2.1.1业务调研
数据仓库的建设是要涵盖所有业务领域，还是各个业务领域独自建设，业务领域内的业务线也同样会面临着这个问题，所以构建大数据仓库，就需要了解各个业务领域、业务线的业务有什么共同点和不同点 ，以及各个业务线可以细分为哪几个业务模块，每个业务模块具体的业务流程又是怎样的。在数仓建设项目启动前，可以请相关的业务人员介绍具体的业务，以便明确各个团队的分析、运营人员的需求。可以详细了解以下信息：
- 组织架构和分工界面。各个部门对数仓的需求不同，需要对不同部门分别进行调研（例如，数据分析、运营、维护部门）。--没做
- 整体业务架构，各个业务模块之间的联系与信息流动的流程，梳理出整体的业务数据框架。--没有
- 各个已有的业务系统的主要功能及获取的数据。--有个框架
以电商业务为例，公司的电商业务板块分为招商、供应链、营销、服务四个板块，梳理出各业务板块的需求数据框架如下图所示。
此外，还需要进一步了解各业务板块中已有的业务流程，业务流程通常与业务板块紧密耦合，对应一个或多个表及其所属数据源，可以作为构建数仓的原始数据来源。
2.2.1.2需求调研
在未考虑数据分析师、业务运营人员数据需求的情况下，单纯根据业务调研建设的数据仓库，可能可用性较差。完成业务调研后，需要进一步收集数据使用者的需求，进而对需求进行深度思考和分析，并改进数据仓库。
需求分析的途径有两种：
- 通过与分析师、业务运营人员的沟通获知需求。
- 对报表系统中现有的报表进行研究分析。
在需求分析阶段，您需要沉淀出业务分析或报表中的指标，以及指标的定义和粒度。粒度可以作为维度的输入。建议您思考下列问题，对后续的数据建模将有巨大的帮助：
- 业务数据是根据什么（维度、统计粒度，简称“粒度”，是维度或维度组合）汇总的，衡量标准是什么？例如，“省份”或者“类目”是维度，订单数是原子指标。
- 基于上个问题，进一步思考明细数据层的事实模型和公共可引用的维度模型、汇总数据层的汇总模型应该如何设计？是否有公共使用，命名及逻辑相似的统计指标，目前已经重复建设使用，需要通过上述设计规范化？
举例： 数据分析师需要了解A公司电商业务中最近1天厨具类目的成交金额。
- 当获知这个需求后，您需要分析：根据什么（维度）汇总、汇总什么（原子指标）、汇总的范围有多大（业务范围即业务限定，时间范围即统计周期）。例如，类目是统计粒度（基于维度），成交金额的总和是原子指标。该案例中，粒度应该是“类目”，“类目为厨具”是业务限定，最近1天是统计周期。
说明 本例从类目为统计粒度的角度，分析需求处理。您可以在即席查询中定义汇总模型的筛选过滤条件，设定统计粒度的维度属性值为厨具，以免汇总模型数据稀疏。在真实业务场景下，可以根据业务需求、使用频度、复用性及汇总层数据计算存储进行考虑，拆解分析。例如，本例中还可以定义全表为粒度，只是该粒度中无需维度，然后定义业务限定是类目为厨具，其他保持不变，如无特殊数据情况，也可得到相同数据结果，只是计算存储过程消耗可能有不同。上述案例，不同路径，组合定义出来的派生指标，可能是相同结果，但是命名、计算逻辑实现可能略有不同。目前Dataphin上对于该类派生指标，认为是不同业务场景的指标，不进行强制去重。
- 基于上述拆解，您还需要进一步思考并设计明细数据层的事实模型（原子指标中成交金额的数据来源）、公共可引用的维度模型（统计粒度的来源，且需要与成交金额所属事实模型有关联关系）和汇总数据层模型（原子指标、业务限定、统计周期的拆解和定义方式）。
需求调研的分析产出通常是记录业务需求的规范定义文档（派生指标、原子指标、业务限定、统计周期、统计粒度（即维度））。结合业务调研情况，您可以进一步产出设计明细逻辑模型设计文档（维度模型、事实模型）与概念模型设计文档（维度、业务过程及其关系）。
2.2.2数仓分层
2.2.2.1数仓分层概述
基于阿里巴巴OneData方法论最佳实践，在阿里巴巴的数据体系中，建议将数据仓库分为三层：数据引入层（ODS，Operational Data Store）、数据公共层（CDM，Common Dimenions Model）和数据应用层（ADS，Application Data Store）。
数据仓库自顶向下的分层和各层用途如下图所示。
- 数据引入层（ODS，Operational Data Store，又称数据基础层）：将原始数据几乎无处理地存放在数据仓库系统中，结构上与源系统基本保持一致，是数据仓库的数据准备区。这一层的主要职责是将基础数据同步、存储到MaxCompute。
- 数据公共层（CDM，Common Dimenions Model）：存放明细事实数据、维表数据及公共指标汇总数据。其中，明细事实数据、维表数据一般根据ODS层数据加工生成。公共指标汇总数据一般根据维表数据和明细事实数据加工生成。
CDM层又细分为维度层（DIM）、明细数据层（DWD）和汇总数据层（DWS），采用维度模型方法作为理论基础， 可以定义维度模型主键与事实模型中外键关系，减少数据冗余，也提高明细数据表的易用性。在汇总数据层同样可以关联复用统计粒度中的维度，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。
- 维度层（DIM，Dimension）：以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。为了避免在维度模型中冗余关联维度的属性，基于雪花模型构建维度表。
在Dataphin中，维度层的表通常也被称为维度逻辑表。
- 明细数据层（DWD，Data Warehouse Detail）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可以结合企业的数据使用特点，将明细事实表的某些重要属性字段做适当冗余，也即宽表化处理。
在Dataphin中，明细数据层的表通常也被称为事实逻辑表。
- 汇总数据层（DWS，Data Warehouse Summary）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。
在Dataphin中，汇总数据层的表通常也被称为汇总逻辑表，用于存放派生指标数据。
- 数据应用层（ADS，Application Data Store）：存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成。
2.2.2.1各层的具体如何设计
（1) ODS(数据引入层)
ODS层存放您从业务系统获取的最原始的数据，是其他上层数据的源数据。业务数据系统中的数据通常为长期累积的、非常细节的数据，且访问频率很高，是面向应用的数据。
1）数据引入层表设计
在ODS层主要包括的数据有：交易系统订单详情、用户信息详情、商品详情等。这些数据未经处理，是最原始的数据。在逻辑层面上，这些数据都是以二维表的形式存储。严格地说，虽然ODS层不属于数仓建模的范畴，但是合理地规划ODS层并做好数据同步也非常重要。本教程中，使用了6张ODS表：
- 记录用于拍卖的商品信息：s_auction。
- 记录用于正常售卖的商品信息：s_sale。
- 记录用户详细信息：s_users_extra。
- 记录新增的商品成交订单信息：s_biz_order_delta。
- 记录新增的物流订单信息：s_logistics_order_delta。
- 记录新增的支付订单信息：s_pay_order_delta。
说明
- 表或字段命名尽量和业务系统保持一致，但是需要通过额外的标识来区分增量和全量表。在Dataphin中，di后缀的事实模型为增量表（事务型），df后缀的事实模型为全量表（周期快照型）。
- 命名时需要特别注意冲突处理。例如，不同业务系统的表可能是同一个名称，为区分两个不同的表，您可以将这两个同名表的来源数据库名称作为后缀或前缀。例如，表中某些字段的名称刚好和关键字重名了，可以通过规范定义后缀添加_col1解决。
2）ODS层设计规范
ODS层表命名、数据同步任务命名、数据产出及生命周期管理、资产质量规范，详情请参见ODS层设计规范。
3）数据同步加载与处理
ODS的数据需要由各数据源系统同步、存储到MaxCompute，才能用于进一步的数据开发。本教程建议您使用Dataphin的数据引入功能完成数据同步，详情请参见概述。在使用数据引入功能的过程中，建议您遵循以下规范：
一个系统的源表只允许同步一次到MaxCompute，保持表结构的一致性。
数据引入支持全量数据同步、实时增量数据同步（分钟或小时调度实现）两种同步方式。
ODS层的表建议以统计日期及时间分区表的方式存储，便于管理数据的存储成本和策略控制，Dataphin中默认时间分区的名字为ds。
数据引入支持手动调整源表和目标表的同步字段。
如果源表字段在目标表中不存在，用户需手动添加目标字段，或删除源表字段。
如果源表字段与目标表字段不匹配，用户需先删除目标字段，然后重新添加与之匹配的字段。
（2) DIM(维度层)
（3) DWD(明细数据层)
（4) DWS(汇总数据层)
汇总数据层以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求构建公共粒度的汇总表。汇总数据层的一个表通常会对应一个统计粒度（维度或维度组合）及该粒度下若干派生指标。
1)汇总表设计原则
聚集是指针对原始明细粒度的数据进行汇总。DWS汇总数据层是面向分析对象的主题聚集建模。在本教程中，最终的分析目标为：最近一天某个类目（例如，厨具）商品在各省的销售总额、该类目销售额Top10的商品名称、各省用户购买力分布。因此，我们可以以最终交易成功的商品、类目、买家等角度对最近一天的数据进行汇总。数据聚集的注意事项如下：
- 聚集是不跨越事实的。聚集是针对原始星形模型进行的汇总。为获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此聚集是不跨越事实的，所以原子指标只能基于一张事实表定义，但是支持原子指标组合为衍生原子指标。
- 聚集会带来查询性能的提升，但聚集也会增加ETL维护的难度。当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。
此外，进行DWS层设计时还需遵循数据公用性原则。数据公用性需要考虑汇总的聚集是否可以提供给第三方使用。您可以思考，基于某个维度的聚集是否经常用于数据分析中。如果答案是肯定的，就有必要把明细数据经过汇总沉淀到聚集表中。
2)汇总表规范
公共汇总表命名规范：dws_统计粒度。 举例如下：
- dws_report（report汇总表）
- dws_user（user汇总表）
3)创建汇总表
汇总模型的设计参考整理出的指标体系（主要是派生指标）即可。汇总表与派生指标的对应关系是，一张汇总表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标。
2.2.3 建模设计
2.2.3.1数据域划分
数据仓库是面向主题的应用，主要功能是将数据综合、归类并进行分析利用。数据仓库模型设计除横向的分层外，通常还需要根据业务情况纵向划分数据域。数据域是联系较为紧密的数据主题的集合，是业务对象高度概括的概念层次归类，目的是便于数据的管理和应用。
通常您需要阅读各源系统的设计文档、数据字典和数据模型设计文档，研究逆向导出的物理数据模型。然后，进行跨源的主题域合并，梳理出整个企业的数据域。
数据域是指面向业务分析，将业务过程或维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新，但不轻易变动。划分数据域时，需满足以下两点：
- 能涵盖当前所有的业务需求。
- 能在新业务进入时，无影响地被包含进已有的数据域中和扩展新的数据域。
在业务调研之后，可以进行数据域的划分。划分数据域，需要分析各个业务模块中有哪些业务活动。数据域，可以按照用户企业的部门划分，也可以按照业务过程或者业务板块中的功能模块划分。
例子1 A公司电商营销业务板块
A公司电商营销业务板块可以划分为如下表所示的数据域。数据域中的每一部分，都是根据实际业务过程进行归纳、抽象得出的。
|
数据域 |
业务过程举例 |
|
会员和店铺域 |
注册、登录、装修、开店、关店 |
|
商品域 |
发布、上架、下架、重发 |
|
日志域 |
曝光、浏览、单击 |
|
交易域 |
下单、支付、发货、确认收货（交易成功） |
|
服务域 |
商品收藏、拜访、培训、优惠券领用 |
|
采购域 |
商品采购（供应链管理） |
例子2 零售事业群的业务行态
零售事业群的业务行态分两大块，线上自营电商和线下商超，所涉及的主要业务流程有：
|
功能模块/业务线 |
业务动作 |
|
交易 |
下单、支付、退货、退款 |
|
供应链 |
采购、运输、仓储（入库、上架、拣选、出库、盘点等） |
|
会员 |
新增会员、会员登录、会员信息修改 |
|
履约 |
接单、发货、配送、签收 |
|
商品管理 |
商品上架、下架、类目修改 |
|
用户行为跟踪 |
商品浏览、店铺浏览、网页区块点击 |
|
售后服务 |
投诉、举报 |
|
评价 |
好评、改评价、打分 |
例子3 马蜂窝数仓主题、主题域划分
马蜂窝数仓主题、主题域划分案例
以马蜂窝订单交易模型的建设为例，基于业务生产总线的设计是常见的模式，首先调研订单交易的完整过程，定位过程中的关键节点，确认各节点上发生的核心事实信息。
例子4 网易云音乐数仓主题、主题域划分
网易云音乐数仓主题、主题域划分案例
网易云音乐将一级主题域划分为参与者、服务及产品，版权及协议、公共、事实这5个大的主题域，二级细节分类按照业务过程抽象获得。
2.2.3.2构建总线矩阵
在进行充分的业务调研和需求调研后，就要构建总线矩阵了。需要做两件事情 :明确每个数据域下有哪些业务过程;业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。
例子1:
例子2:
例子3:
一个业务过程对应维度模型中一张事务型事实表，一个维度则对应维度模型中的一张维度表。所以构建业务总线矩阵的过程就是设计维度模型的过程。但是需要注意的是，总线矩阵中通常只包含事务型事实表，另外两种类型的事实表需单独设计。
按照事务型事实表的设计流程，选择业务过程à声明粒度à确认维度à确认事实，得到的最终的业务总线矩阵需要包括度量值。
2.2.3.3明确统计指标
明确统计指标具体的工作是，深入分析需求，构建指标体系。构建指标体系的主要意义就是指标定义标准化。所有指标的定义，都必须遵循同一套标准，这样能有效的避免指标定义存在歧义，指标定义重复等问题。
1）指标体系相关概念
（1）原子指标
原子指标基于某一业务过程的度量值，是业务定义中不可再拆解的指标，原子指标的核心功能就是对指标的聚合逻辑进行了定义。我们可以得出结论，原子指标包含三要素，分别是业务过程、度量值和聚合逻辑。
例如订单总额就是一个典型的原子指标，其中的业务过程为用户下单、度量值为订单金额，聚合逻辑为sum()求和。需要注意的是原子指标只是用来辅助定义指标一个概念，通常不会对应有实际统计需求与之对应。
（2）派生指标
派生指标基于原子指标，其与原子指标的关系如下图所示。
与原子指标不同，派生指标通常会对应实际的统计需求。请从图中的例子中，体会指标定义标准化的含义。
（3）衍生指标
衍生指标是在一个或多个派生指标的基础上，通过各种逻辑运算复合而成的。例如比率、比例等类型的指标。衍生指标也会对应实际的统计需求。
2）指标体系对于数仓建模的意义
通过上述两个具体的案例可以看出，绝大多数的统计需求，都可以使用原子指标、派生指标以及衍生指标这套标准去定义。同时能够发现这些统计需求都直接的或间接的对应一个或者是多个派生指标。
当统计需求足够多时，必然会出现部分统计需求对应的派生指标相同的情况。这种情况下，我们就可以考虑将这些公共的派生指标保存下来，这样做的主要目的就是减少重复计算，提高数据的复用性。
这些公共的派生指标统一保存在数据仓库的DWS层。因此DWS层设计，就可以参考我们根据现有的统计需求整理出的派生指标。
标签：业务,数据仓库,建模,实践,指标,维度,数据,事实 From： https://www.cnblogs.com/ohtang/p/17237782.html