一、数仓规划

1.1 数据分层

  • 数据引入层 ODS（Operational Data Store）：原始数据
    • 将原始的结构化数据增量或全量同步至数仓，数据表的结构与原始数据所在的数据系统中的表结构一致
    • 将原始的非结构化数据（例如，日志信息）进行结构化处理，并存储至数仓
    • 根据实际业务需求，记录原始数据的历史变化或对原始数据进行简单的清洗
  • 明细数据层 DWD（Data Warehouse Detail）：基于业务过程
    • 存储大量体现业务活动状况的实际数据或详细数值，是数据聚合后依据某个维度生成的结果表
    • 将明细数据表的某些重要维度属性字段适当冗余，即宽表化处理（维度退化）；也可以减少明细数据表及维度表的关联，提高明细表的易用性
  • 汇总数据层 DWS（Data Warehouse Summary）：基于主题
    • 根据上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表（存储一个数据域下相同时间周期、相同维度的多个派生指标的统计数据）
  • 应用数据层 ADS（Application Data Service）：基于场景
    • 个性化指标加工：定制化、复杂性指标（大部分是复合指标）
    • 基于应用的数据组装：宽表集市，趋势指标（存储相同时间周期、相同维度的多个原子指标、派生指标或统计粒度的统计数据）
  • 公共维度层 DIM（Dimension）：基于维度，根据实际业务，构建一致性数据分析维度表，降低数据计算口径和算法不统一的风险
    • 确定维度主键
    • 添加维度属性
    • 关联不同维度

image.png

1.2 业务分类

当业务比较复杂，不同类型业务彼此间需要共享数据域，但是又希望能在模型设计和应用过程中快速定位本业务的数据时，可结合业务情况，规划不同的业务分类，在后续建模的维度表和真实表中，将其关联到对应的业务分类中

1.3 数据域和业务过程

1.3.1 数据域

数据域是较高层次的数据归类标准，是业务人员使用数据时第一个分组入口，帮助业务人员从数据中快速圈定自己的业务数据。数据域通常是根据业务类别、数据来源、数据用途等多个维度，对数据进行划分，比如：客服（crm）、财务（financial）、供应链（supply）、销售（sales）、市场（market）、生产制造（mes）等

1.3.2 业务过程

业务过程业务过程是对业务活动流程的描述，例如在电商领域，加购、下单、支付等都可以是一个业务过程。每个业务过程用于衡量业务过程的原子指标和派生指标，实际业务的真实数据表（明细表）也可关联具体的业务过程

数据域 业务过程
会员店铺域 注册、登录、装修、开店、关店
商品域 发布、上架、下架、重发
日志域 曝光、浏览、点击
交易域 下单、支付、发货、确认收货
服务域 商品收藏、拜访、培训、优惠券领用
采购域 商品采购、供应链管理

二、数据指标

2.1 数据指标

原子指标=业务过程+度量

派生指标=原子指标 + 时间周期 + 一个或多个修饰词（可理解为对原子指标业务统计范围的圈定）

image.pngimage.png

  • 维度：分析事实的环境
    • 属性：维度的列，维度属性是查询约束条件、分组和报表标签生成的基本来源
  • 度量：即事实 ，度量通常为数值型数据
  • 指标：是衡量业务特征的统计数值，具有明确的统计口径和计算逻辑
    • 原子指标=业务过程+度量
      • 业务限定：统计的业务范围（类似于SQL中where后的条件，不包括时间区间）。例如，下单实际支付金额的业务口径为：用户下单生成订单后，通过支付渠道支付了订单金额的总和。
    • 派生指标= 时间周期 + 一个或多个修饰词 + 原子指标（可理解为对原子指标业务统计范围的圈定），用于统计目标指标在具体时间、维度、业务条件下的数值表现。例如，统计一个自然日中线上和线下生鲜门店的下单总数。
      • 修饰词（统计粒度）：定义数据汇总的程度，可理解为聚合运算时的分组条件（类似于SQL中的group by的对象）。粒度是维度的一个组合，指明统计范围。例如，某个指标是某个卖家在某个省份的成交额，则粒度就是卖家、地区这两个维度的组合。
      • 时间周期：用于确定需要统计的时间范围（类似于SQL中where后的时间条件）。例如，一个自然日。
    • 原子指标与派生指标间的关系
      • 原子指标归属于业务过程
      • 派生指标唯一归属一个原子指标，继承原子指标的数据域，与修饰词的数据域无关。例如，支付金额为原子指标，最近一个月商品A的支付金额（时间周期为最近一个月，修饰词为商品A，原子指标为支付金额）为派生指标

        2.2 构建流程

        image.png
  1. 业务调研
    1. 梳理整体业务架构，各个业务板块之间的联系和信息流动的流程
    2. 已有的业务板块的主要功能及获取的数据
  2. 需求分析
    1. 沉淀出指标的定义和粒度
  3. 分析业务过程
  4. 划分数据域
    1. 根据系统设计文档、数据字典和数据模型设计文档，逆向导出物理数据模型
    2. 数据域的划分既能涵盖当前业务需求，又能让新业务可以被包含进已有的数据域或扩展新的数据域
  5. 明确统计指标

  6. 构建总线矩阵

    1. 定义每个数据域下的业务过程和维度 | 数据域 | 业务过程 | 一致性维度 | | | | | | | | | | —- | —- | —- | —- | —- | —- | —- | —- | —- | —- | —- | | | | 省份 | 城市 | 类目ID | 类目名称 | 品牌ID | 品牌名称 | 商品ID | 商品名称 | 成交金额 | | 交易域 | 下单 | Y | Y | Y | Y | Y | Y | Y | Y | N | | | 支付 | Y | Y | Y | Y | Y | Y | Y | Y | N | | | 发货 | Y | Y | Y | Y | Y | Y | Y | Y | N | | | 确认收货 | Y | Y | Y | Y | Y | Y | Y | Y | Y |

  7. 模型设计

    三、研发规范

    3.1 研发规范整体流程

    image.png
    阶段规划

  8. 需求阶段：数据产品经理承接业务方数据需求

  9. 设计阶段：数据产品经理、数据开发者综合性能、成本、效率、质量等因素，更好地组织与存储数据。
  10. 开发阶段：数据开发者高效、规范地进行编码工作。
  11. 测试阶段：测试人员准确地暴露代码问题与项目风险，提升产出质量。
  12. 发布阶段：将具备发布条件的程序平稳地发布到线上稳定产出。
  13. 运维阶段：运维人员保障数据产出的时效性和稳定性。

角色职责

  • 数据产品经理：负责承接、评估业务方提出的数据需求，并组织需求评审、产出产品需求文档，同时需要把控其它更为细化的技术评审。
  • 设计人员：根据已定稿的产品需求文档所述需求，进行数据探查，了解数据形态（数据质量、数据分布），同时根据探查结果实现表设计、Mapping设计、调度设计等细分设计工作。
  • 开发人员：根据设计人员产出的稿件，制定计划并实现代码，同时进行单元测试与代码评审。
  • 测试人员：负责验证需求与结果的一致性，发现代码问题与项目风险。
  • 运维人员：负责发布任务，并处理数据、程序、调度、监控告警等异常事件，保障数据产出时效、程序高效运行和生产稳定性。

    3.2 需求阶段

    3.2.1 首次需求流程
    评估完成需求的技术、数据、合规的可行性后，以细化需求的方式完成产品需求文档，并组织需求评审会议多方共同敲定需求最终实现方案
    3.2.2 迭代需求流程