大数据数据仓库建模工具

转载

mob64ca1403528a 2024-07-18 20:41:40

一：数仓建模原则

维度建模应该使用最基础的原子数据进行填充，以支持不可预知的来自用户查询的过滤和分组请求。用户通常不希望每次只看到一个单一的记录，但是你无法预测用户想要掩盖或者显示那些数据。

在组织事实表时候，粒度有三个基本原则：事务，周期快照，累加快照。无论粒度如何，事实表中的度量单位都必须达到相同水平的详细程度；如果事实表中的事实表现的粒度不一样，企业用户容易混淆，BI应用程序也会随之变得不堪一击，从而导致返回的结果不对等低级错误的发生。

主要从数据业务特性和访问特性两个角度考虑：

将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型

将高概率同时访问的数据放在一起，将低概率同时访问的数据分开存储

建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的字段过度侵入核心模型，以免破坏核心模型的架构简洁性与可维护性

越底层的公用处理逻辑越应该在数据链路的底层进行封装与实现，以提高代码复用

不要让公用的处理逻辑暴露给应用层实现

不要让公用的处理逻辑多处同时存在

序号	处理方式	对象	描述
1	关键字段抽取	Map、Json、Php数组、字符串（正则）	线上经常会使用半结构化类型字段来存储大量信息，可以根据具体使用频次和重要程度，在数据链路的底层将其解析抽取出来作为单独字段
2	加工新字段	已有字段、关联维表	主要是归类处理，可以基于已有字段处理归类类型，或者在加工维表时处理归类逻辑；枚举值汉化（注意，如果线上新增枚举值需要及时处理，否则影响产出数据准确性，可以通过值域检查捕获新增值）
3	加工新表	抽取关键信息	如果公用的逻辑处理足够复杂，则可以将改处理过程单独加工成一张独立的表。例如，分析用户行为时会关注一些常用的用户维度，如接入网络、实验分组、渠道来源等，这种情况可以事先处理一张每日活跃用户表，以达到公共处理逻辑下沉的目的

适当的数据冗余可换取查询和刷新的性能，不宜过度冗余与数据复制

处理逻辑不变，在不同时间多次运行数据结果确定不变

注意添加时间约束，如果目的是处理截止到当天日期以前的历史所有数据，务必限制：dt <= '当天参数'

有些业务指标在特定周期内会随着时间的变化而变化，但时间一旦越过边界后需要保证重跑结果不变，对于这种情况需要明确发酵周期。例如，注册后7天转化率

维度一致性：不同业务过程的事实表若有相同的维度，则要使用相同的维度表（或其视图）；不同维度表若具有相同含义的属性，应该保证名称和内容一致，这样可以实现跨事实表钻取（物化视图）

命名一致性：具有相同含义的字段在不同表的命名必须相同，必须使用规范定义中的名称，命名做到见其名知其意。

代码一致性：多个数据源对相同属性可能采用不同的值域描述，数仓建设时需要将其统一。例如对性别的描述，可能是“男, 女”、“1, 0”或者“F, M”，这种情况就需要统一规范

1.维度表是用来描述事实的，因此维度表的主键是与其关联的事实表的外健

2.维度表通常比较宽，是扁平的非3NF表，信息冗余并包含大量的低粒度的文本属性

3.避免维度表中属性有NULL值

4.维度表中代码值和中文含义要同时存在

5.避免混淆维度表中可度量属性和事实表中的事实

6.注意维度表变化（属性值变更，例如名称变化），通常情况下维度表的变化是缓慢的，但与事实表关联时需要保证维度信息的正确

7.维度表层次关系处理，冗余和扁平化

8.维表兜底值约定

1 .面向业务，数据能够清楚的描述业务过程，不要包含与业务无关的事实

2. 事实表应当只保留维度表的外健，不建议保留描述性信息

3.建设事实表时要声明事实粒度，不同粒度的事实不能放在同一张事实表中

事务型事实表（原子事实表）：通常是明细表，拥有最丰富的维度信息和最细粒度的事实，一般具有退化维度（DD）
周期型事实表：通常是汇总表，关注某个固定周期内的聚合事实，一般由原子事实表加工产出，维度上可以有所缩减
累积型事实表：关注业务的整个过程（物流），单条数据会随着时间的变化而更新，一般是需要重跑或全量处理数据。例如用户骑行过程，会关注几个关键里程如开锁、关锁、支付、评价

4.分解不可加事实为可加事实