项目数据治理（ETL）之前的数据资产划分

项目数据治理之前的数据资产划分

关键维度

• 业务领域/主题域

依据： 数据所支撑的核心业务流程和业务实体。

划分： 战略管理、投资管理、文化与品牌、市场营销、销售管理、产品研发、工艺管理、供应链管理、生产制造、试验验证、交付、售后服务、维保服务等。

目的： 

1、建立业务与技术沟通的桥梁

2、组织复杂数据的核心框架

3、明确数据所有权（Data Ownership）和责任

4、驱动以业务价值为导向的数据治理

5、支撑数据建模与集成

6、赋能数据发现与自助服务

7、促进跨部门数据共享与协作

实践： 企业级数据模型通常按主题域构建。

已划分层次：L1（主题域分组）、L2（主题域）、L3（业务对象）、L4（表证单书对应的逻辑实体）、L5（实体表及其字段）

梳理具体如下：

划分收录方法：线上文档、线上系统、线下主题域对应主体部门走访

二、数据来源与类型

来源： 内部系统（ERP, PHM, WMS, SHR,EAS等等）、外部数据（合作伙伴数据、公开数据、购买的数据）、物联网设备、车地数据、日志文件等。

类型：

结构化数据： 关系型数据库表、CSV文件等。

半结构化数据： JSON, XML, 日志文件、邮件等。

非结构化数据： 文档、图片、音频、视频等。

目的： 理解数据的获取方式、处理难度、存储需求和技术栈。

获取方式：

1、线上：中间件、接口、库表等

2、线下：文件、其它企业收录的一般业务数据信息等

三、数据敏感性与安全级别

依据： 数据包含信息的敏感程度、泄露可能造成的风险（财务损失、声誉损害、法律责任等）以及法律法规要求。

划分（常见等级）：

公开： 可对外自由发布的数据。

内部： 仅限企业内部员工访问的数据。

机密： 需严格授权访问的数据（如核心财务数据、未公开的战略计划）。

高度机密/受限制： 包含个人敏感信息（PII）、个人健康信息（PHI）、支付卡信息（PCI）、国家秘密等受法规严格保护的数据。

目的： 定义访问控制策略、加密要求、脱敏规则和审计强度。这是合规性和风险防控的核心维度

四、数据价值与关键性

依据： 数据对业务运营、决策支持、客户体验、收入生成或风险管理的贡献程度；数据不可用或质量差对业务造成的潜在影响。

划分（常见等级）：

关键/核心： 支撑核心业务流程、直接影响重大决策或收入的数据（如核心客户信息、主产品目录、关键交易记录）。发生问题会导致业务严重中断或重大损失。

重要： 对业务有显著影响，但非绝对核心的数据（如部分分析指标、辅助业务数据）。发生问题会影响效率和决策质量。

一般： 支持性、参考性或历史归档数据，影响范围有限。

低价值/临时： 短期使用或价值密度很低的数据。

目的： 指导资源（治理投入、质量监控、备份恢复优先级）的分配。高价值关键数据需要最强的治理保障。

一般使用方式：指标宽表，结合bi平台进行可视化，以及对数据进行下钻

• 数据生命周期阶段

依据： 数据从产生到消亡的不同阶段。

划分：

创建/采集： 数据首次产生或获取。

存储与处理： 数据被存储、清洗、整合、加工。

使用与分析： 数据被业务应用、报表、分析模型使用。

归档： 活动性降低但仍需保留的数据。

销毁： 数据生命周期结束，安全删除。

目的： 不同阶段有不同的管理重点（如采集阶段的元数据捕获和质量检查、使用阶段的访问控制和性能优化、归档阶段的成本控制、销毁阶段的合规审计）。

一般分层：ODS（贴源）、DWD（明细）、DWM（中间）、DWS(数据服务层)、DM（集市），具体依据企业需求进行适度划分（可适当整合维度关联，对数据维度进行适度的下钻、或者根据业务主体进行宽表拓展（具体遵循范式、或者星形），需要了解的自行查看范式建模以及星形 相关文档）

• 数据血缘与依赖关系

依据： 数据的来源、加工过程和下游消费者。

划分： 原始数据、衍生数据（ETL过程产生）、聚合/指标数据、报表/分析结果数据。

目的： 理解数据是如何产生的，变更的影响范围（影响分析），保障数据的可信度和可追溯性。识别关键的数据源和转换节点。

• 策略关联与自动化

核心思想： 划分的最终目的是驱动行动。将划分结果（标签）与具体的治理策略、控制措施和技术配置关联起来。

示例：

敏感性标签（机密/高度机密） 自动触发：强制访问控制、字段级加密、动态数据脱敏、严格的审计日志记录、限制数据导出。

关键性标签（核心/重要） 自动触发：更频繁的数据质量检查、更短的备份恢复目标（RPO/RTO）、更高的服务级别协议（SLA）、变更影响分析预警。

生命周期标签（归档） 自动触发：迁移到低成本存储、访问权限收紧、数据压缩。

主/参考数据标签 自动触发：变更审批流程、分发同步机制。

技术： 数据策略引擎、数据安全平台、数据质量工具、元数据驱动的自动化工作流。

• 持续维护

动态性： 数据资产、业务需求、法规环境都在不断变化。划分不是一次性的项目，而是一个持续的过程。

机制：

定期审查： 设定周期（如每季度、每年）全面审查划分标准和结果。

变更触发审查： 当发生以下情况时触发特定数据资产的重新评估：

新数据源接入或旧数据源下线。

数据模型/结构发生重大变更。

数据使用场景或业务重要性发生显著变化（如新法规出台、新核心业务上线）。

数据Owner变更。

发生数据安全事件或审计发现。

自动化辅助： 利用工具监控元数据变化、数据访问模式变化、策略合规性偏差，发出重新划分预警。

实施依据：4A架构

4A架构是指业务架构（Business Architecture）、应用架构（Application Architecture）、数据架构（Data Architecture）和技术架构（Technology Architecture）。这四个架构领域是企业架构的重要组成部分，它们相互关联、相互支撑，共同构成了企业信息化建设的完整体系。在进行数据治理以及构建数据资产时，4A架构提供了全面的视角和方法论指导。

业务架构（BA, Business Architecture）：定义了企业的战略目标、业务流程和组织结构，它帮助识别哪些数据对于支持关键业务流程和决策至关重要。业务架构为数据治理提供了一个框架，确保数据治理活动与企业的核心业务目标保持一致。

应用架构（AA, Application Architecture）：描述了支持业务功能所需的应用系统及其之间的交互关系。对于数据治理而言，应用架构需要考虑如何设计和部署能够有效管理数据生命周期的应用程序和服务。例如，通过应用架构可以确定数据集成点，确保数据可以在不同应用之间无缝流动。

数据架构（DA, Data Architecture）：专注于数据的收集、存储、使用及管理等方面的设计。数据架构定义了数据模型、数据库系统设计、数据流和数据治理策略等，是实现数据治理的核心部分。它包括制定数据标准、规范数据质量、确保数据安全和隐私保护等内容。

技术架构（TA, Technology Architecture）：指定了用于支持数据架构和应用架构的技术平台和基础设施。技术架构的选择会影响数据治理的有效性，比如选择合适的数据库管理系统、数据仓库解决方案或大数据处理平台等，都是为了更好地管理和利用数据资产。

综上所述，在数据治理和数据资产管理中遵循4A架构意味着：

在业务架构层面，要理解并反映数据对业务的价值。

在应用架构层面，要考虑如何设计应用程序来有效地管理数据。

在数据架构层面，需建立一套完整的数据管理体系，包括数据标准、数据质量、数据安全等。

在技术架构层面，则要选择合适的技术工具和基础设施以支持高效的数据处理和分析。

通过这样的综合考虑，企业可以确保其数据治理活动不仅满足技术要求，同时也符合业务需求，并且能够在整个组织范围内得到有效的实施和维护。