数据架构（Data Architecture）

定义与目标

数据架构定义企业级数据的结构、数据域、数据流与管理机制，目标是保障数据的一致性、可用性、可控性和价值最大化，支撑业务与应用架构的实现。

数据架构不是数据库表设计。它更关心企业有哪些核心事实，这些事实由谁产生、谁维护、谁消费、如何共享、如何保证质量。表结构是落地结果之一，但不是数据架构的全部。

主要内容

• 数据愿景与原则（准确、可用、安全、共享）
• 数据域划分与数据对象模型
• 主数据（MDM）、参考数据与元数据管理
• 数据流与集成（ETL/ELT、数据总线、事件流）
• 数据质量管理与数据治理
• 数据安全与隐私保护（合规：GDPR/网络安全法）
• 数据平台与技术（数据仓库、数据湖、湖仓一体）

关键工件

• 数据域模型与数据字典
• 概念/逻辑/物理数据模型（ERD）
• 主数据模型与数据标准
• 数据血缘与数据目录（Data Catalog）
• 数据质量标准与度量
• 数据安全策略与分级分类

方法与步骤（对应ADM Phase C-Data）

1. 明确数据驱动因素与范围
2. 现状数据架构基线与问题识别
3. 目标数据架构与平台蓝图
4. 数据治理框架与组织职责
5. 数据集成策略与标准（API、消息、批处理）
6. 数据质量与安全策略制定
7. 差距分析与迁移路线图

数据治理

• 组织：数据委员会、数据管理员（Owner/Steward）
• 政策：数据标准、命名规范、生命周期管理
• 流程：采集、存储、使用、共享、归档、销毁
• 工具：数据目录、质量平台、血缘分析、隐私脱敏

例子：库存数据为什么必须统一口径

零售企业里，“库存”看似是一个字段，实际可能拆成多种业务事实：

数据对象	含义	常见问题
仓库库存	仓库实物库存数量	和门店库存、在途库存口径混用
门店库存	门店可用于销售或自提的库存	门店盘点延迟导致线上展示不准
可售库存	当前允许前端售卖的库存	没扣除锁定库存，容易超卖
锁定库存	下单未支付或待履约时预占的库存	释放规则不清会导致库存长期占用
在途库存	调拨或采购途中尚未入库的库存	被误认为可售，影响履约承诺

数据架构要定义这些对象的标准含义、责任系统、更新链路和质量规则。例如可售库存可以由库存中心统一计算，订单中心只发送锁定和释放事件，门店系统负责实物盘点，数据平台负责沉淀历史和分析口径。

从业务对象到数据服务

数据架构落地时，建议按“业务对象 -> 数据标准 -> 责任系统 -> 共享方式”推进：

1. 识别核心业务对象：会员、商品、订单、库存、门店、仓库、供应商。
2. 定义标准口径：字段含义、编码规则、生命周期状态。
3. 明确数据 Owner：谁有权创建、修改、废弃和发布数据。
4. 设计共享方式：同步 API、异步事件、批处理、数据仓库或数据湖。
5. 建立治理规则：质量校验、血缘追踪、权限控制、审计和脱敏。

数据安全与隐私

• 数据分级分类与访问控制（RBAC/ABAC）
• 数据加密（静态/传输/使用中加密）
• 安全审计与合规评估
• 数据最小化与隐私保护设计（Privacy by Design）

平台与技术

• 数仓/大数据/实时平台（Lambda/Kappa架构）
• 数据湖与湖仓一体（Hudi/Iceberg/Delta Lake）
• 流处理（Kafka/Flink）与消息中间件
• 元数据与治理平台（Atlas/Amundsen/Purview）

最佳实践

• 以业务能力驱动数据域与主数据识别
• 建立共享数据服务与标准接口
• 数据质量“左移”，嵌入开发与运营流程
• 数据安全内建，合规前置
• 度量与看板化，持续改进

总结

数据架构将数据视为企业资产。它的关键不是堆技术平台，而是让核心数据对象有统一口径、清晰责任、可靠流动和可治理的生命周期，从而支撑应用协作、业务分析和智能决策。