# data_architecture

**Repository Path**: public_static_void/data_architecture

## Basic Information

- **Project Name**: data_architecture
- **Description**: 数据架构总结
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-10-10
- **Last Updated**: 2025-12-07

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 数据架构
最近参与完成一个大型养殖企业的数据仓库架构项目，现对实施过程中的关键问题和解决方案进行总结沉淀。

## 项目背景
本项目为某大型养殖集团构建新一代数据仓库，旨在建立标准化、可扩展的企业级数据架构。

项目特点与挑战：

1、系统性重构：业务系统全面升级，数据仓库需从零开始建设，而非局部适配改造

2、全域覆盖：架构设计需满足当前需求并具备前瞻性，支持未来3-5年的业务发展

3、同步上线：数据平台与业务系统需同步交付，对协同能力和交付节奏要求极高

## 业务流程梳理

1、数据架构必须服务于业务，深入理解业务流程是成功的基础。前期梳理工作包括：

2、流程建模：识别核心业务流程及关键业务对象，确定数据架构覆盖范围

3、资产评审：与业务部门共同评审，识别企业核心数据资产及管理责任人

4、技术评估：了解源系统技术栈（如MySQL分库分表方案）、数据规模及增长趋势，为技术选型提供依据

## 主数据
主数据是数据架构的基石，应在项目初期完成设计和治理。

#### 主数据定义
主数据是企业核心业务实体的一致、共享、权威的数据源，具有跨流程、跨系统共享的特性。

#### 主数据识别
采用"四同"判断标准：同源（唯一来源）、同义（一致含义）、同构（相同结构）、同步（实时一致）。例如，猪场编码在繁殖、育肥、销售、财务等系统中被广泛引用，是典型的主数据。

#### 主数据标准

1、编码规则：采用"场景-类型-层级-序号"结构，如FM-A-01-001表示"猪场-A区-1号舍-001栏位"

2、属性规范：定义字段的元数据标准，包括数据类型、长度、值域及校验规则

3、治理机制：明确数据Owner、维护流程及质量监控规则

#### 主数据开发

1、表设计原则：代理键 + 业务键 + 核心属性 + 扩展属性 + 审计字段。字段按业务重要性排序，关联属性集中存放

2、命名规范：采用统一前缀策略，如pigfarm_id、pigfarm_code、pigfarm_name，避免命名不一致导致的集成问题

3、历史追溯：关键主数据采用拉链表设计，结构为：代理键 + 业务键 + 属性集 + 生效时间 + 失效时间 + 审计字段

## 数据入湖
数据湖作为企业数据底座，其数据质量直接影响上层应用。

入湖策略

1、同步方式：根据数据量和变更频率选择全量或增量同步。建议阈值：单表>500万行或>25GB采用增量同步

2、实时能力：基于CDC技术（如Flink CDC、Debezium）实现关键业务数据的实时同步

3、数据源管理：建立数据源注册机制，记录源系统的技术特征和数据特性

常见问题与对策

1、数据类型映射：跨数据库类型转换时，预留充足长度（建议源端长度的3倍），或采用兼容性更好的String类型

2、数据一致性：针对源端物理删除，采用"软删除标记+定期全量比对"方案；针对更新时间不刷新问题，在源端建立触发器或审计机制

3、异常处理：建立数据质量检查点，对缺失主键、违反约束等异常数据进入隔离区人工处理

## 数据模型
#### DWI层（数据整合层）
DWI层聚焦数据标准化和初步整合，提升数据可用性：

数据清洗：过滤无效数据（软删除记录、测试数据、超期历史数据），修复明显错误

字段标准化：空值统一处理、代码转义、字符集转换、单位统一

数据整合：

1、多源整合：如将HR系统与CRM系统的员工信息按主键合并

2、分表整合：将业务系统分库分表的同一逻辑表重新整合

3、头行合并：将订单头与订单行按业务键合并为宽表

#### DWR层（数据报告层）
DWR层作为数据仓库的核心，提供业务就绪的明细数据：

业务对象整合：以业务实体为中心，整合相关业务流程数据。如运输指令表整合指令、发货、到货、签收全链路信息

维度扩展：通过代理键关联维度表，补充关键描述信息

标签派生：基于业务规则生成衍生标签，如客户价值分层、产品生命周期阶段

数据发散控制：严格验证表关联关系，对多对多关联采用预聚合或桥接表处理，避免数据膨胀

## 指标拆解
#### 业务指标管理

建立业务驱动的指标管理体系：

1、指标定义：采用"指标名称 + 业务口径 + 计算逻辑 + 数据来源"的四要素定义法

2、责任机制：每个指标明确业务Owner和技术Owner，业务Owner负责口径定义，技术Owner负责实现逻辑

3、沟通验证：开发人员需将技术实现方案反向讲解给业务方，确保理解一致

#### 指标分层设计
借鉴华为DataArts框架，构建三级指标体系：

1、原子指标：不可再拆解的基础指标，如"出栏数量"、"饲料消耗量"，与DWR表的度量字段直接对应

2、衍生指标：原子指标 + 统计维度 + 过滤条件，如"华北区月度出栏数量"

3、复合指标：多个衍生指标计算得出，如"料肉比" = "饲料消耗总量" ÷ "出栏总重量"，要求参与计算的指标维度一致

## 数据集市
DM层面向最终用户提供可消费的数据产品，采用维度建模方法。

#### 模型选型
星型模型：事实表直接关联所有维度表，查询简单高效，适合大多数分析场景

雪花模型：维度表规范化设计，减少数据冗余，适合维度层次复杂且变更频繁的场景

选择建议：优先采用星型模型，仅在维度数据量极大或存在明显冗余时考虑雪花模型

#### 维度设计
维度是数据分析的视角，设计要点：

维度选取：采用"最小完备集"原则，选取核心分析维度，避免过度设计。如销售分析必备：时间、产品、渠道、客户四个维度

属性组织：将高频查询属性置于维度表前列，相关属性集中存储

缓慢变化处理：对于需要历史追溯的维度属性（如客户等级），采用SCD Type 2设计；对于不需要追溯的属性（如客户联系电话），采用SCD Type 1直接更新

#### 度量设计
度量是分析的量值，设计策略：

原子度量：如"销售金额"、"销售数量"，直接存储在事实表中，支持任意维度组合的汇总

衍生度量：如"平均单价"、"毛利率"，建议通过视图或计算字段实现，避免物理存储冗余

半可加度量：如"库存数量"，在时间维度上不可加，需标注特殊聚合规则

维度与度量增加场景处理：

新增维度：评估与现有维度关系。如新增"促销活动"维度，若每笔销售都可对应活动，则在事实表增加外键

新增度量：首先确认计算粒度。如同粒度原子度量（如"成本金额"）可直接加列；衍生指标（如"折扣率"）建议逻辑计算；不同粒度指标（如"订单运费"）需新建事实表

## 数据应用
#### 看板设计
分层展现：战略层（KPI）、战术层（过程指标）、操作层（明细数据）三层结构

交互设计：支持钻取、联动、筛选等交互操作，如从大区销量钻取到省份明细

性能优化：针对高频查询建立汇总层，确保关键看板亚秒级响应

#### 报表体系
固定报表：标准格式的业务报表，如日报、周报、月报，支持定时推送

自助分析：提供拖拽式分析界面，支持业务人员自主探索数据

数据服务：通过API方式为下游系统提供数据服务，保证数据一致性

#### 智能分析
预测分析：基于历史数据建立预测模型，如出栏量预测、饲料需求预测

异常检测：实时监控关键指标，自动识别异常波动并告警

根因分析：通过关联分析技术定位问题根本原因，如销量下降与天气因素的关联关系

## 其他思考

数据治理先行：在技术实施前建立数据治理体系，包括组织、流程、标准、工具四个维度

数据治理一定是从上至下的，如果从下至少通常面临各种阻碍

迭代演进：采用"整体规划、分步实施、快速迭代"策略，每期聚焦2-3个关键业务场景

AI时代借助AI能高效的完成编码、检查、排错等费时的工作