当前位置：首页 > news >正文

数仓一些问题

news 2025/10/5 7:33:33

公共层和数据集市层的区别和特点?

区别

服务对象与范围
- 公共层:通常是为整个数据仓库体系以及多个业务部门或应用场景提供通用的数据和服务支持，是跨部门、跨业务的，为企业整体的数据处理和分析提供基础。
- 数据集市层:主要面向特定的部门、业务主题或特定的用户群体，满足他们特定的数据分析和决策需求，服务范围相对较窄。
数据内容与粒度
- 公共层:包含明细事实数据、维表数据及公共指标汇总数据等，数据粒度可以是明细级别的，也有一定的汇总数据，能提供较为全面和详细的数据基础。
- 数据集市层:一般是轻度汇总级的数据，通常不存在明细数据，是对数据仓库中的数据按照特定主题和需求进行进一步筛选、汇总和整理后得到的。
数据模型设计
- 公共层:更多采用维度模型方法，常使用维度退化等手法，将维度退化至事实表中，减少事实表和维表的关联，以提高明细数据表的易用性。
- 数据集市层:通常采用星型或雪花模型，以更直观和便捷的方式组织数据，方便特定业务的查询和分析。
建设和维护主体
- 公共层:一般由数据仓库团队或数据治理团队进行统一建设和维护，确保数据的规范性、一致性和通用性。
- 数据集市层:可以由特定部门的业务人员或数据分析人员与数据仓库团队合作建设，也可能由数据仓库团队根据不同部门需求分别构建和维护。

特点

公共层
- 数据通用性强:能为多个业务场景和分析需求提供通用的数据支持，避免重复建设和数据不一致性。
- 指标统一规范:基于统一的数据体系构建命名规范、口径一致和算法统一的统计指标，提升数据的可信度和可复用性。
- 数据整合度高:对来自不同数据源的数据进行深度整合和清洗，提供高质量的基础数据。
数据集市层
- 针对性强:专门针对特定部门的业务需求进行定制化设计，能快速满足该部门的数据分析和决策需求。
- 模型自由度更高:由于聚焦特定需求，模型设计和建设相对简单自由，能够快速实现并投入使用，帮助业务部门快速获取数据价值。

如何提高数仓模型的复用性？

架构及规范制约

数仓架构管理

合理的数仓分层犹如搭建稳固的大厦框架。从底层原始数据层到上层应用数据层，各层职责清晰。当企业数仓分层中明确DWS 层(公共模型层)的分层定位为公共模型层，要求所有开发工程师日常工作中，面对各类通用分析需求，如统计每日商品销售总额、每月用户活跃时长等，优先引用DWS 层的轻度汇总模型，无需每次从海量原始数据中重新计算，直接调用该层模型，大幅节省计算资源与开发时间。当然，标准化dwd数据明细事实模型和dim维度模型，保证了数据溻俎在整个数仓体系中的一致性，减少了因模型不统一导致数据使用者放弃引用的问题，提升模型在不同业务场景下的复用性。

数据域划分

数仓中数据繁多且复杂，数据域划分如同给海量数据贴上精准标签。开发工程师面对新业务需求时，能依据数据域快速定輕踊建滫呀则关模Ⓔ篑型轄導螗侈。例如在电商数仓中，用户相关数据归为用户数据域，商品数据归为商品数据域。当开展用户留存率分析项目时，开发工程师可直接在用户数据域查找相关模型，无需在庞大的数仓中盲目检索。清晰的数据域划分，不仅提高模型查找效率，还使得模型在不同业务场景间的复用更加便捷，提升了模型的整体复用性。

建立模型设计规范

统一的模型设计规范涵盖多方面内容。数据处理规范确保不同模型对相同数据源的数据清洗、转换、加载方式一致。例如，对于日期格式，统一规定为"YY-MM-DD”，避免不同模型间数据格式不兼容问题，方便模型间的数据整合与复用。模型结构规范明确了事实表与维度表的关联方式、主键与外键设置等，使开发工程师在理解和维护模型时更加容易。当新业务需求需对现有模型进行扩展时，依据规范，开发工程师能快速上手。规范还促进团队协作，不同开发人员开发的模型遵循相同规则，优秀模型可在团队内更好传播与复用，提升团队整体开发效率与模型复用性。

平台能力辅助支撑

元数据管理平台

元数据管理平台能记录数据模型的详细信息，包括业务元数据(如业务术语、业务规则等)和技术元数据(如数据存储位置、数据类型、数据处理逻辑等)。这使得数据仓库开发人员在寻找可复用的模型时，能够快速了解模型的全貌，准确判断其是否适用于当前需求，从而提高模型的复用效率。这些信息帮助开发工程师快速判断模型是否适用于当前业务需求，降低复用模型的学习成本，提高模型引用水平，进而提升复用性。

指标管理平台

指标管理平台能辅助数仓团队提高数仓模型复用性，在需求分析环节，团队借助平台可快速检索现有指标及关联模型，精准判断能否支挥当前需求，若能满足则避免重复开发，节省时间与资源;平台还能凭借其智能算法对数仓中的指标和模型进行重复性识别判断，整合相似或冗余部分，清晰呈现可用的标准模型，促使团队在构建新模型时优先考虑复用，减少不必要的创新，进而提升数仓模型整体复用率，推动数仓建设高效发展

建立模型复用度量化评价系统

建立模型复用度量化评价系统能从多方面辅助数仓团队提升数据模型复用性。它借助模型被引用次数、覆盖业务场景数量等量化指标，直观呈现模型复用情况，让团队精准识别高复用模型，总结成功设计经验用于新模型开发，也能定位复用性差的模型，分析结构、功能等缺陷加以优化或淘汰。评价结果可作为激励手段，促使开发人员为获认可，在设计时就注鑊炅重模型通用性与灵活性，从源头提升质量。同时，量化数据为团队决策提供依据，资源优先向复用模型倾斜，项目优先选用适配模型，减少重复劳动，全方位提升团队数据模型复用水平。

需求承接及开发管理

需求评审把控

在需求评审阶段，把控好数据模型复用问题，开发工程&模型评审方需要仔细分析新需求如何尽量基于已有模型基础上支撑，尽量增加模型复用性，降低烟囱式开发。例如:新报表需求可能只需在现有 DWS 层汇总表基础上增加几个维度或修改统计指标。此时，开发工程师推动使用现有模型扩展，而非新建 ADS 层报表模型。这样既节省开发时间，避免重复开发相似功能模型，减少数仓模型兄余，又保证数据一致性(新报表与现有模型基于相同数据来源和处理逻辑)，提高现有模型复用率。

定期优化重构:

随着数仓发展，技术债积累，出现兄余模型。例如不同时期开发多个相似DWS 层汇总表，功能大部分重看。开发工程师通过技术债评估，识别这些冗余模型，将其合并为统一模型，简化数仓结构，提高管理效率。对于过度耦合模型，如一个模型既处理用户信息又涉及订单关联分析，功能复杂不便维护和复用。开发工程师将其拆分为功能单一的用户信息模型和订单关联模型，每个子模型专注一个业务功能，方便在其他业务场景复用，提升模型灵活性和复用性。

详尽的业务调研

数仓开发前期，充分的业务调研至关重要。开发工程师深入与各业务团队沟通，了解业务流程和数据需求。例如与多个业务团队交流，发现渠道维度在销售数据分析、用户行为分析等多种业务分析中频繁使用。设计数仓模型时，开发工程师优先将渠道维度标准化设计并实现，确保其一致性和通用性。新业务需求出现时，因已有标准化高频维度和指标模型，开发工程师可直接复用或少量调整，提高模型通用性和复用性，更好满足多个业务场景需求。

团队模型分享文化
组织定期的知识分享会和培训活动，让开发人员分享在数仓模型开发和复用方面的经验和技巧，提高团队整体的技术水平和复用意识。例如，邀请经验丰富的开发人员介绍如何设计具有高复用性的模型，分享一些成功的模型复用案例等。同时，针对新入职的员工或对某些技术不熟悉的员工，开展针对性的培训，帮助他们快速堂握数仓模型开发和复用的相关知识和技能。分享者还能从他人反馈中优化模型，形成模型复用良性循环，提高团队模型复用率。

如何衡量公共层建设的好坏？

数仓公共层的完善度直接影响数据复用性、开发效率和业务价值。以下从数仓架构、模型设计，数据质量、性能效率、规范治理、成本控制、业务价值七大维度系统化衡量:(当然大家不用讲那么细，知道从哪些方面去讲，以及这些方便代表什么就差不多了，更多的的理解问题;)

1.数仓架构完善度

分层职责明确性
- 层次清晰度:分层架构应层次分明，每个层次的职责和功能明确。通常分为 ODS、DWD、DWS、ADS 等层次，ODS 层负责原始数据的采集和存储，DWD层进行数据的清洗和明细化处理，DWS层对数据进行汇总和轻度聚合ADS 层为具体的应用提供数据支持。检查各层次的数据处理任务是否清晰，是否存在职责混淆的情况。
- 文档完备性:完善的分层架构应该有详细的设计文档，包括各层次的设计目标、数据处理流程、数据流向等。通过检查文档，可以了解架构设计的思路和意图，判断分层架构是否经过精心设计和规划。同时，文档也是后期维护和优化的重要依据。
- 命名规范一致性:各层次的表名、字段名等命名应遵循统一的规范，通过命名能够清晰地反映出数据所在的层次、数据的主题和用途。例如，DWD 层的表名可以以"dwd"为前缀，后面跟着具体的业务主题，如dwd order detail” 表示订单明细数据。
数据域划分完善度
- 完整性:检查数据域是否覆盖了业务系统中的所有主要业务板块和主题领域。例如，一个电商数仓应包含商品、订单、用户、库存等数据域，若缺少某个关键业务的数据域，则说明分层架构存在缺陷。
- 划分合理性:数据域的划分应遵循业务逻辑和数据特性，每个数据域内的数据应具有较高的相关性和内聚性。以商品数据域为例，其中应包含与商品本身属性、价格、分类等相关的数据，而不应混入与订单流程相关的数据。
- 扩展性:考察数据域的设计是否考虑到未来业务的扩展和变化。例如，随着业务的发展，若新增了跨境电商业务，现有的数据域是否能够方便地容纳和处理新业务产生的数据，是否需要对数据域进行大规模的调整和重构。
层间调用关系
- 依赖关系合理性:上层数据对下层数据的依赖应符合数据处理的逻辑顺序，不存在不合理的跨层依赖或循环依赖。例如，ADS 层的数据应该依赖于 DWS 层或 DWD 层经过处理和汇总后的数据，而不应直接依赖于 ODS 层的原始数据，以免导致数据处理的混乱和效率低下。
- 调用链路清晰性:层间的数据调用链路应清晰可查，通过数据血缘关系图或相关的无数据管理工具，可以直观地看到数据从底层到上层的流动过程，包括经过了哪些处理步骤和转换操作。这有助于在数据出现问题时快速定位和清勿排查故障。
- 数据一致性维护:检查层间数据在传递和处理过程中是否能够保持一致性。例如，DWD 层对数据进行清洗和转换后，传递到 DWS 层进行汇总计算，在这个过程中要确保数据的关键属性和业务逻辑没有被破坏，保证各层次数据在语义和数值上的一致性。
跨层引用率
- 若DWS/ADS层直接引用ODS层数据比例过高，说明DWD层建设不完善，导致重复加工和兄余计算。
- 量化指标:跨层引用率(ODS→DWS/ADS引用占比)应<x%。
公共层表引用率
- 评估DWD/DWS层表被下游模型调用的比例。引用率越高，说明公共层复用性越强，分层价值越显著
- 计算方法:公共层表引用率=0(DWD/DWS层被引用的表数)/公共层总表数
- 主题覆盖度: 衡虽公共层是否覆盖核心业务主题，避免重要业务数据未被分层整合
- 分层规范度:检查分层架构是否遵循明确的分层规范(如分层命名、主题域划分、表归类等)。例如，“表归类率”可量化分层信息的完整性，即表是否归属正确的分层和主题域条

2.模型设计的完善度

高内聚低耦合
- 标准:模型内字段的业务相关性高，跨模型依赖链路短且清。
- 评估方法:统计模型内字段的业务主题关联度(如同一模型内字段是否属于同一业务过程)，并分析模型间依赖层级(依赖层级超过3级需优化)。
核心模型与扩展模型分离
- 标准:核心模型(如大宽表)仅包含高频核心字段，低频或个性化字段独立为扩展模型。
- 评估方法:检查核心模型字段被下游引用的占比(如核心模型字段复用率超过80%为优)，且扩展模型不侵入核心模型逻辑。
公共逻辑下沉
- 标准:共性计算逻辑(如口径转换、维度关联)集中在DWD/DWS层，避免上层重复实现。
- 评估方法:通过血缘分析识别重复逻辑(如相同计算逻辑在不同任务中出现次数)，推动逻辑下沉。
成本与性能平衡
- 标准:模型冗余度低(如相同数据不重复存储)，且查询响应时间符合业务需求。
- 评估方法:统计冗余表占比(冗余表存储量/总存储量)，并监测高频查询的平均响应时间(如超过5秒需优化)。
数据可回滚与一致性
- 标准:模型支持历史数据回溯，且相同字段的定义和命名全局一致。
- 评估方法:验证时间分区表的历史数据可回溯性，检查跨模型同名字段的定义一致性(如字段类型、计算口径)
规范遵循度
- 标准:模型命名、字段命名符合分层规范(如dwd_{业务域}事实表)，且词根体系统一。
- 评估方法:审计模型命名合规率(合规命名模型数/总模型数)及字段词根覆盖率(符合词根字段数/总字段数)。
模型复用性
- 公共层模型被上层引用的比例(如DWD表被ADS层引用率)应>70%。
- 优化方向:通过维度建模(星型模型)和标准化主键设计(自然键+代理键)提升复用性。

3.数仓规范治理完善度

命名规范遵循度
- 评估模型命名、字段命名是否符合分层命名规则(如dwd_{业务域}_事实表)及词根体系要求。
- 示例:表命名需包含分层缩写、业务域、增量/全量标识等要素
分层准入机制合规性
- 检查新增表是否严格遵循分层逻辑(如ODS层仅存储原始数据，公共逻辑强制下沉至DWD/DWS层)，避免跨层引用或逻辑冗余
元数据管理
- 是否维护完整血缘关系(如上下游依赖)、业务元数据信息和数据字典?
- 量化指标:元数据覆盖率应>90%。
安全管控
- 敏感数据(如身份证号)是否脱敏?
- 权限分配是否遵循最小化原则(如开发人员仅访问测试层)

4.数据质量完善度

完整性
- 关键业务数据(如交易流水、用户行为日志)是否全量盖?
- 检查方法:通过数据探查工具验证空值率(如用户ID空值率<0.01%)。
一致性
- 同一指标在不同层级中的口径是否一致(如"GMV"统一定义为“订单金额-退款金额”)?
- 检查方法:构建一致性校验规则库(如跨层金额差异<0.1%)。
准确性
- 异常值处理是否合理(如负金额自动标记为脏数据)?
- 检查方法:抽样验证数据与业务逻辑的匹配性(如用户年龄分布符合实际业务场景
及时性
- 任务能否及时产出

5.性能效率完善度

查询性能
- 高频查询(如用户行为分析)响应时间是否达标(P95<5秒)?
- 优化手段:通过预聚合表(DWS层)减少J0IN复杂度，或小文件优化等手段优化表数据探查性能。
资源效率
- 冷热数据是否分层存储(如历史数据归档至低成本存储)?
- 冷热数据分层存储占比需 >80%，公共层存储成本占总成本应<30%
- 量化指标:公共层存储成本占总成本比例应<30%?
产出时效性
- ETL任务SLA达成率应>95%;高频查询时间 (P95)应 <5秒
- 优化手段:通过全量改增来量，模型优化，参数优化，链路优化等手段提升数据链路产出效率。

6.成本控制完善度

存储成本
- 存储成本资源利用率:统计公共层冗余存储占比(如相同数据在不同模型的重复存储量)，衡量存储成本优化效果
- 通过冷数据归档(如OSS低成本存储)降低存储成本，冷数据占比应>60%
- 对热数据采用高性能的固态硬盘(SSD)存储，提高数据读取速度。通过数据压缩技术，如 Snappy等，减少数据存储空间占用，降低存储成本。
- 定期评估存储成本，对比不同存储方案的费用，结合数据访问频率和存储需求，适时调整存储策略。
计算成本
- 是否实现弹性计算能力，根据数据处理任务的负载情况，动态调整计算资源。在数据处理任务高峰期增加计算节点，任务完成后释放多余资源，避免资源浪费。
- 源消耗Top10任务优化率需>50%，避免重复计算
开发与维护成本合理性
- 评估人力投入与维护费用占比，包括重复开发任务数、模型回湖成本等
- 关键指标:公共层任务数占总任务数的比例(理想值应低于30%)