免费做产品画册的网站,产品推广方式都有哪些,软件开发过程中存在哪些问题,企业建立企业网站有哪些优势?在数仓建设的过程中#xff0c;由于未能完全按照规范操作#xff0c; 从而导致数据仓库建设比较混乱#xff0c;常见有以下问题#xff1a;
数仓常见问题
● 数仓分层不清晰#xff1a;数仓的分层没有明确的逻辑#xff0c;难以管理和维护。 ● 数据域划分不明确…在数仓建设的过程中由于未能完全按照规范操作 从而导致数据仓库建设比较混乱常见有以下问题
数仓常见问题
● 数仓分层不清晰数仓的分层没有明确的逻辑难以管理和维护。 ● 数据域划分不明确没有明确的数据域划分导致数据冗余和不一致。 ● 模型设计不合理模型设计没有考虑业务的实际需求导致数据质量低下。 ● 代码不规范代码不符合规范导致维护困难。 ● 命名不统一命名不统一导致数据难以理解和使用。 ● 主题域划分不完整主题域划分没有涵盖所有业务需求导致数据缺失。
除此之外其他还有比如数据质量数据集成性能元数据管理数据安全等问题。
数据架构分层
数仓分层标准
一般情况下大体可以按照如下方式进行分层 ● 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?__bizMzU2ODQ3NjYyMAmid2247488738idx1sn189694698b6d749c77340116cbc96bf4chksmfc8c0241cbfb8b5748da839811a901f9442e47e216b8dfc69fbb0a510cb7a432ce35399d3090scene21#wechat_redirect
