在数仓建设的过程中，由于未能完全按照规范操作， 从而导致数据仓库建设比较混乱，常见有以下问题：
数仓常见问题
● 数仓分层不清晰：数仓的分层没有明确的逻辑，难以管理和维护。
● 数据域划分不明确：没有明确的数据域划分，导致数据冗余和不一致。
● 模型设计不合理：模型设计没有考虑业务的实际需求，导致数据质量低下。
● 代码不规范：代码不符合规范，导致维护困难。
● 命名不统一：命名不统一，导致数据难以理解和使用。
● 主题域划分不完整：主题域划分没有涵盖所有业务需求，导致数据缺失。
除此之外，其他还有比如：数据质量，数据集成，性能，元数据管理，数据安全等问题。
数据架构分层
数仓分层标准
一般情况下，大体可以按照如下方式进行分层：
● ODS (结构与源系统基本保持一致的增量或者全量数据)
● DWD (数仓明细层，来源于 ODS 清洗转化，基于具体业务构建明细事实表，可适当冗余某些重要属性，必要时做宽表处理)
● DWS（汇总层，一般基于指标构建初步汇总事实表，注意命名规范，口径一致，为上层提供一致性公共指标）
● DIM（维表层，以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表）
● ADS （数据服务层，主要存放数据产品个性化的统计指标数据，直接对接消费者）
开发路径
● 数据调研（分析业务需求，需要哪些指标，具体口径，梳理业务库表关系字段含义等信息）
● 数据域划分（对业务过程或维度进行抽象，比如交易、流量、用户域等）
● 构建总线矩阵 （明确业务过程所属的数据域，业务过程与分析维度的关系）
● 明确统计指标 （一般指的是原子指标与派生指标）
● 模型设计（构建一致性维表(DIM)，事实表(DWD)，汇总模型(DWS)，应用汇总模型(ADS)）
● 开发（业务逻辑SQL开发，测试、数据验证）
● 部署（上线（如T-1调度），依赖配置、任务监控、DQ 任务检测）
表规范
在建立 Hive 数据仓库表时，针对不同数据层次和类型（如增量、全量、小时级数据），我们通常遵循以下规范：
-
命名规范
分层命名
数据仓库分为不同层次，每层次对应不同的数据处理阶段。
命名格式为：{层级名称}{业务域} {具体业务描述}_{产出属性}
示例：
ods_user_new_inc_df (ods层用户新增天级全量表)
ods_user_active_di (ods层用户活跃天级增量表)
-
分区规范
对于增量、全量、小时级数据，建议根据业务需求采用分区表，提高查询效率。
○ 按日期分区：适用于每天新增数据，如每日更新。
示例：PARTITIONED BY (dt STRING)
○ 按小时分区：适用于每小时新增数据，如小时级别的增量数据。
示例：PARTITIONED BY (dt STRING, hr STRING)
○ 全量数据：通常不分区，但可以根据业务需求分区。
示例：定期全量导入时，可以按日期分区，表名如dim_customer。
模型设计基本原则
● 高内聚和低耦合
主要从数据业务特性和访问特性两个角度来考虑：
○ 将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型；
○ 将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。
● 核心模型与扩展模型分离
建立核心模型与扩展模型体系，核心模型包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化或是少量应用的需要，不能让扩展字段过度侵入核心模型，破坏了核心模型的架构简洁性与可维护性。
● 公共处理逻辑下沉
越是底层公用的处理逻辑更应该在数据调度依赖的底层进行封装与实现，不要让公共的处理逻辑暴露给应用层实现，不要让公共逻辑在多处同时存在。
● 成本与性能平衡
适当的数据冗余换取查询和刷新性能，不宜过度冗余与数据复制。
● 数据可回滚
处理逻辑不变，在不同时间多次运行数据结果确定不变。
● 指标一致性
相同的字段含义在不同表中字段命名必须相同，必须使用规范定义中的名称。
● 命名清晰可理解
表命名需清晰、一致，表名需易于消费者理解和使用。
● 层次依赖合理
○ DWD应严格遵守层次依赖，理论上只可引用ODS、DIM和部分DWD数据，不可引用处于下游层次的ADS等数据，以避免出现"反向引用"的情况；
○ DWS应严格遵守层次依赖，理论上只可引用DIM、DWD数据，不可引用处于下游层次的ADS等数据，以避免出现"反向引用"的情况。
如何设计分层？
● ODS
基本上是将业务系统数据原封不动的抽取到数仓，一般采用增全量的方式进行。可以考虑使用的工具如 sqoop,datax,seatunnel等。
● DWD/DWS:
一般情况下，一个比较好的公共层遵循一下几个原则：
迭代升级
○ 1、数据域的划分是建设公共层的前提，但是数据域不是一成不变的，由于业务不同，对应的数据域划分也自然各不相同，有时候需要灵活处理，并且要根据业务的发展而调整相关数据域的划分。
○ 2、其实，数据域的目的是为了给数据分类，所以尽量以业务分析视角去组织公共数据，从而保持数据的独立性。
公共层要考虑的核心问题
公共层需要考虑的一个核心问题是：是否具有共性
○ 1、DWS层的原则：DWS的核心诉求是通过空间换时间，在节约成本、提升效率的同时，实现数据口径的一致性。既如此，那就不能为了加工DWS而加工DWS数据，要基于是否是业务的核心指标判断是否要沉淀公共层，另外，如果是事后沉淀公共层，那要看下需要沉淀的指标的应用场景有多少，假如只在一个地方使用，那也就没有沉淀DWS的必要了
○ 2、DWD的原则：一般情况下，DWD的模型相对好设计一些，核心是基于维度建模，冗余维度属性，降低频繁关联，提升基础数据模型的易用性
复用性、易用性、稳定性
公共层模型不是为某一应用场景单独设计的，而是面向大部分的应用场景进行设计，因此需要进行一定的抽象以提升通用性，从而尽可能覆盖更多的应用场景。
○ 复用性
■ 指标复用性抽象：转变不可累加指标为可累加指标，如比率型建议保留分子分母；
■ 粒度复用性抽象：以最大公约数的逻辑抽象复用，比如上游表ADS1是子公司粒度、表ADS2是一级类目粒度，那就可以设计出sku粒度的DWS表
○ 易用性
在不影响模型产出时效性的情况下，需尽量考虑模型易用性，提升应用研发的使用效率。易用性的设计主要指的是宽表设计和水平切分，用于降低下游理解和多表关联。
■ DWS模型易用性上，通过冗余维度属性、采用大宽表方式构建，以提升下游易用性。
■ DWS冗余相对不易变的维度属性，减少下游频繁关联；
■ 如无时效性问题，同数据域同粒度进行宽表设计，提升下游易用性；
■ DWD模型易用性上，通过采用星型模型、维度冗余和信息完善度进行设计，以提升下游易用性，模型设计应以星型模型为主。
○ 稳定性
通过大宽表的建设方式，公共层极大提升了模型的易用性，但因应用场景差异化，时效性也对应有不同的要求。公共层需进行必要的的稳定性设计，满足下游重要应用高时效性产出的要求。
■ 扁平化设计提升稳定性：公共层整体需扁平化设计，进行不要依赖层级过深
■ DWS稳定性设计：结合访问热度、数据稳定情况，进行必要的解耦设计，以提升DWS模型的稳定性；比如根据访问的热度，将1d、nd、td的数据模型进行垂直拆分，
■ 对于DIM维表也可以根据垂直拆分的方式，保证核心维度的产出效率，将低热度的扩展维度属性与核心维度属性进行拆分
成本和效率要有一个权衡
一般情况下，对于数据量比较小的场景，可以优先构建DWD，后构建DWS，在构建DWS的过程中，可以优先构建细粒度的DWS表(为了扩展性)，最后沉淀粗粒度的DWS表。对于数据体量比较大的情况，可以优先构建粗粒度的DWS，对于DWD的构建，可以采用水平拆分的方式，比如不在冗余半结构的字段(attributes扩展字段)，从而提升产出的时效，提升下游的使用效率。
● ADS
应用层的定位为根据特定业务诉求，按照业务角度组织数据以快速满足业务需求。应用层研发核心关注研发效率、口径一致性，以及核心应用的稳定性。
一个好的应用层模型需要重点关注以下几个原则：
-
需求驱动
需求驱动构建集市：按需最小原则设计，除非有明确的业务延续，否则不做过度的扩展设计。应用层的设计需要考虑业务定制的需求，提供面向业务定制的应用数据，如报表数据、大宽表等，供线上系统使用。
划分集市域、共性抽象下沉
○ 与公共层类似，以高内聚低耦合的原则对集市进行划分，让单集市数据研发聚焦在某一领域的业务需求实现；集市间应该避免互相依赖，避免复杂度的提升。
○ ADS也可以抽象出公共部分，通过依赖ADS数据，提升开发的效率和产出效率
-
减少对ODS的依赖
减少直接引用ODS表，降低源系统变更带来的改造成本，架构合理上考虑，公共层针对复用性的场景进行模型沉淀，当源系统变更时，通过公共层适应性改造屏蔽下游变更。
参考
https://blog.51cto.com/xpleaf/4896831
https://developer.aliyun.com/article/927293
https://mp.weixin.qq.com/s?__biz=MzU2ODQ3NjYyMA==&mid=2247488738&idx=1&sn=189694698b6d749c77340116cbc96bf4&chksm=fc8c0241cbfb8b5748da839811a901f9442e47e216b8dfc69fbb0a510cb7a432ce35399d3090&scene=21#wechat_redirect