a站是哪个app百度企业信用信息查询

前言

    在数据仓库开发中，数据仓库的设计和维护一直是一个备受关注的话题。随着业务需求的不断变化，数据仓库的结构也需要随之调整。

  面试过程中，多次被提问：当DWS构建好后，突然来了一个新的需求，需要添加某个或某几个维度字段时，应该如何处理？是重构现有DWS，还是新建一张DWS？

   首先需分析加维度的目的是什么，是原有的dws模型粒度太粗不足以支持业务分析嘛？一般能想到的处理思路如下：

（1）直接修改

      好处：效率高、改的快

      坏处：粒度变细之后，下游依赖的数据会有问题，如果直接展示明细，很可能一条变两条，妥妥的数据事故。

（2）新建dws

      好处：对原有dws无影响

      坏处：可能功能重复，逻辑没复用，成本也会陡然上升

（3）新建dws ，且原有dws会依赖新dws（同层级依赖）

       优点：逻辑和成本兼顾，下游无影响

        缺点：改造成本大

看到大佬分享的一个 思路，借鉴如下：

一、初步思路

    面对这样的需求时，首先要明确DWS的设计原则。DWS层的由来：将ADS层多张表引用的公共逻辑下沉到DWS层，通过构建主题宽表的方式实现逻辑复用（模型设计的原则之一）。

     因此对于一些业务场景相对简单的数仓，DWS层或许根据没必要创建。

     DWS层的主要作用：对数据进行某一颗粒度的轻度聚合，并不涉及复杂的维度扩展需求。

 结论：面对新增维度字段的需求，不建议直接进行DWS重构或新增一张DWS表，而是通过其他方式实现需求。

   ps: 毕竟，当下游ADS多个指标都用到该新增维度，后期进行模型优化时，才逐步将能够复用的公共逻辑沉淀至DWS宽表。

二、解答思路

（1）DWS只做某颗粒度且不带维度的聚合

     在DWS的设计中，我们强调其应专注于某一特定颗粒度的数据聚合，不涉及具体的维度。

这样设计的好处是能够保持数据处理的高效性和简洁性。如果在DWS层面增加过多的维度字段，可能会导致Group By操作变得过于复杂和繁重，影响查询性能和数据处理的效率。

（2）ADS层做宽表，利用颗粒度下的维表进行关联

     对于需要添加维度字段的需求，我们可以在ADS（应用数据服务）层进行处理。具体来说，可以通过在ADS层创建宽表，并利用颗粒度下的维表作为驱动表进行关联操作。这样，不仅能够满足新增维度字段的需求，还能保持数据仓库设计的灵活性和扩展性。

三、实际操作步骤

（1）确定新增维度字段的业务需求

    在处理新增维度字段需求时，首先需要明确这些维度字段的具体业务含义和使用场景。了解这些信息有助于更好地设计后续的数据模型和处理逻辑。

（2）设计并构建ADS层的宽表

    根据新增维度字段的需求，在ADS层设计新的宽表。宽表的设计要充分考虑数据的查询需求和关联操作的性能。在创建宽表时，可以利用现有的维表作为驱动表（主表）进行关联，将新增的维度字段整合到宽表中。

（3）数据处理与同步

    在设计好宽表后，需要进行相应的数据处理和同步操作。可以通过ETL（抽取、转换、加载）流程将数据从DWS层抽取出来，按照新的数据模型进行转换，并加载到ADS层的宽表中。

（4）数据校验与优化

    在完成数据处理和同步后，需要对数据进行校验，确保新增的维度字段和原有数据的一致性。同时，可以对数据查询性能进行优化，确保在新的数据模型下能够高效地进行查询和分析。

四、DWS层增加维度的潜在风险

在讨论解决方案时，我们还需要明确DWS层增加维度字段的潜在问题和风险：

（1）查询性能下降

    在DWS层增加过多的维度字段，可能会导致Group By操作变得复杂，查询性能下降。特别是在处理大规模数据时，这种影响会更加明显。

（2）数据模型复杂化

   在DWS层增加维度字段，可能会导致数据模型变得复杂，难以维护和扩展。在实际操作中，往往需要进行大量的调优和调整，增加了开发和运维的成本。

（3）数据一致性问题

    在DWS层进行复杂的维度扩展，可能会引发数据一致性问题。特别是在多源数据集成和处理时，需要考虑数据的一致性和完整性，增加了处理难度。

五、总结

    在应对DWS新增维度字段需求时，我们不建议直接在DWS层进行重构或新增表，而是通过在ADS层创建宽表，并利用维表进行关联的方式解决问题。这样既能够满足业务需求，又能够保持数据仓库的高效性和灵活性。同时，在实际操作中，需要充分考虑数据处理的性能和一致性，确保数据仓库的稳定运行。

    通过上述方法，可以在保持数据仓库设计原则的基础上，灵活应对不断变化的业务需求，构建高效、可靠的离线数据仓库。

参考文章：

数仓有关dws，ads设计策略的一个面试问题记录