读DAMA数据管理知识体系指南25数据集成活动

1. 规划和分析

1.1. 数据集成和互操作涉及在什么时间、什么地点、以什么方式能获得数据

1.2. 定义数据集成和生命周期需求

• 1.2.1. 定义数据集成需求涉及理解组织的业务目标，以及为实现这些目标而需要的数据和建议的技术方案

• 1.2.2. 数据保留的要求通常因数据域和类型而异

• 1.2.3. 数据集成和生命周期需求通常由业务分析师、数据管理专员和具有各种职能的架构师（包括IT）定义

• 1.2.4. 定义需求的过程可以创建并发现有价值的元数据

1.3. 执行数据探索

• 1.3.1. 数据探索(Data Discovery)应该在设计之前进行

• 1.3.2. 数据探索的目标是为数据集成工作确定潜在的数据来源

• 1.3.3. 数据探索将确定可能获取数据的位置以及可能集成的位置

• 1.3.4. 数据探索还包括针对数据质量的高级别评估工作，以确定数据是否适合集成计划的目标

  • 1.3.4.1. 评估不仅需要审查现有的文档，采访主题专家，而且还需要通过数据剖析或其他分析来验证根据实际数据收集的信息

  • 1.3.4.2. 几乎在任何情况下，对数据集的看法与实际探索发现的数据集会存在差异

• 1.3.5. 数据集成解决方案也可能涉及从组织外部获取数据

  • 1.3.5.1. 有大量且越来越多的有价值的信息可以免费或者从数据供应商那里获得

  • 1.3.5.2. 当来自组织外部的数据和组织内部数据集成在一起时，这是非常有价值的

• 1.3.6. 获取和集成外部数据需要做好规划

1.4. 记录数据血缘

• 1.4.1. 数据探索过程还将揭示数据是如何在一个组织中流动的信息

• 1.4.2. 此信息可用于记录高级数据血缘：数据是如何被组织获取或创建的，它在组织中是如何移动和变化以及如何被组织用于分析、决策或事件触发的

• 1.4.3. 详细记录的数据血缘可以包括根据哪些规则改变数据及其改变的频率

• 1.4.4. 血缘分析可能会识别使用中的系统所需的更新

• 1.4.5. 分析过程还可以提供改进现有数据流的机会

1.5. 剖析数据

• 1.5.1. 理解数据的内容和结构是实现数据集成成功的关键

  • 1.5.1.1. 数据剖析(Data Profiling)有助于实现这一目标

• 1.5.2. 数据结构中定义的数据格式和从实际数据中推断出来的格式

• 1.5.3. 数据的数量，包括null值、空或默认数据的级别

• 1.5.4. 数据值以及它们与定义的有效值集合的紧密联系

• 1.5.5. 数据集内部的模式和关系，如相关字段和基数规则

• 1.5.6. 与其他数据集的关系

• 1.5.7. 对潜在的源数据和目标数据进行更广泛的剖析，可以了解数据在多大程度上能满足特定数据集成活动的要求

• 1.5.8. 剖析的目标之一是评估数据的质量

  • 1.5.8.1. 对于特定用途的适用性，评估数据时需要记录业务规则，并测量数据满足这些业务规则的程度

• 1.5.9. 数据剖析包括验证与实际数据相关的数据假设

• 1.5.10. 剖析数据的要求必须与组织的安全和隐私规定保持平衡

1.6. 收集业务规则

• 1.6.1. 业务规则是需求的一个关键子集，是定义或约束业务处理方面的语句

• 1.6.2. 业务规则旨在维护业务结构、控制或影响业务的行为

• 1.6.3. 业务规则分为四类：业务术语定义、相互关联的术语的事实、约束或行为断言以及派生

• 1.6.4. 评估潜在的源数据集和目标数据集的数据

• 1.6.5. 管理组织中的数据流

• 1.6.6. 监控组织中的操作数据

• 1.6.7. 指示何时自动触发事件和警报

• 1.6.8. 对于主数据管理而言，业务规则包括匹配规则、合并规则、存活规则和信任规则

• 1.6.9. 收集业务规则也称为规则获取或业务规则挖掘

2. 设计数据集成解决方案

2.1. 设计数据集成解决方案

• 2.1.1. 评估和协商工作是需要在确定数据集成解决方案之前进行，所以通过建立企业标准可以让组织节省实施单个解决方案的时间

• 2.1.2. 支持和备份的操作资源是共享池的一部分

• 2.1.3. 选择交互模型

  • 2.1.3.1. 确定哪个交互模型或组合将满足需求——中心辐射型、点到点或发布订阅

• 2.1.4. 设计数据服务或交换模式

  • 2.1.4.1. 创建或重用现有的集成流来移动数据

  • 2.1.4.2. 应该与现有类似数据服务相辅相成，但要注意不要创建多个几乎完全相同的服务，因为在服务激增的情况下，故障排除和支持会变得越来越困难

  • 2.1.4.3. 任何数据交换规范设计都应该基于行业标准开始，或者以已经存在的其他交换模式为标准

2.2. 建模数据中心、接口、消息、数据服务

• 2.2.1. 数据集成和互操作中所需的数据结构包括数据持久化的数据结构

• 2.2.2. 主数据管理中心、数据仓库和数据集市、操作型数据存储库以及那些只是用于移动或转换数据的临时数据结构

2.3. 映射数据源到目标

• 2.3.1. 几乎所有的数据集成解决方案都包括从源结构到目标结构的数据转换

• 2.3.2. 做好从一个位置到另一位置的数据格式转换映射规则

  • 2.3.2.1. 指明源数据和目标数据的技术格式

  • 2.3.2.2. 指定源数据和目标数据之间所有中间暂存点所需的转换

  • 2.3.2.3. 描述最终或中间目标数据存储区中每个属性的填充方式

  • 2.3.2.4. 描述是否需要对数据值进行转换，如通过在表示适当目标值的表中查找源值

  • 2.3.2.5. 描述需要进行哪些计算

• 2.3.3. 转换可以在批量计划中执行，也可以由实时事件触发

2.4. 设计数据编排

• 2.4.1. 数据集成解决方案中的数据流必须做好设计和记录

• 2.4.2. 数据流程编排是从开始到结束的数据流模式，包括完成转换和/或事务所需的所有中间步骤

• 2.4.3. 批量数据集成的流程编排将设定数据移动和转换的频率

• 2.4.4. 批量数据集成通常被编码为一个调度器，它会在某个时间、周期或在事件发生时被触发启动

• 2.4.5. 实时数据集成流程编排通常由事件触发，如数据新增或更新

• 2.4.6. 实时数据集成流程编排通常更复杂，通常需要跨越多个工具来实现，甚至可能都不是线性的过程

3. 开发数据集成解决方案

3.1. 开发数据服务

• 3.1.1. 开发服务来获取、转换和交付指定的数据，并且匹配所选的交互模型

3.2. 开发数据流编排

• 3.2.1. 对集成或ETL数据流通常会采用专用工具以特有的方式进行开发

• 3.2.2. 互操作性需求可能包括开发数据存储之间的映射或协调点

3.3. 制定数据迁移方法

• 3.3.1. 当上线新的应用程序，或当应用程序退役或合并时，数据需要进行迁移

• 3.3.2. 数据迁移项目经常被低估或缺乏充分的设计，因为程序员只是被告知简单地移动数据

• 3.3.3. 在没有进行适当分析的情况下迁移数据时，这些数据通常看起来与通过正常业务处理而获得的数据不一样

• 3.3.4. 迁移后的数据可能无法像预期的那样与应用程序一起工作

3.4. 制定发布方式

• 3.4.1. 创建或维护关键数据的系统需要将这些数据提供给组织中的其他系统

• 3.4.2. 生成数据的应用程序应该在数据更改（事件驱动）或定期调度时，将新数据或更改后的数据推送到其他系统（特别是数据中心和企业数据总线）​

• 3.4.3. 最佳实践是为组织中的各种数据类型确定一个通用的消息定义（规范格式）​，并让具有适当访问权限的数据使用者（应用程序或个人）订阅接收有关数据更改的通知

3.5. 开发复杂事件处理流

• 3.5.1. 准备有关预测模型的个人、组织、产品或市场和迁移前的历史数据

• 3.5.2. 处理实时数据流，充分填充预测模型、识别有意义的事件（机会或威胁）​

• 3.5.3. 根据预测执行触发的动作

• 3.5.4. 对预测模型所需历史数据的准备和预处理可以在夜间进行批处理或准实时执行

  • 3.5.4.1. 一些预测模型可以预先在触发事件前填充

• 3.5.5. 识别出有意义事件的反应可以简单到只发出警告信息，也可以是特别复杂场景的自动部署

3.6. 维护数据集成和互操作的元数据

• 3.6.1. 在开发数据集成和互操作解决方案过程中，组织将创建和发现有价值的元数据

• 3.6.2. 可靠的元数据提高了组织管理风险、降低成本和从数据中获得更多价值的能力

• 3.6.3. 记录所有系统的数据结构涉及源、目标和缓存的数据集成，包括业务定义和技术定义（结构、格式、大小）以及数据在持久化的数据存储之间的转换

• 3.6.4. 大多数ETL工具供应商都将其元数据存储库打包为附加功能，以实现治理和管理监督

• 3.6.5. 对于数据集成和共享解决方案来说，特别重要的是SOA注册中心，它提供了一个不断发展变化的受控信息目录：即访问和使用应用程序中数据和功能的可用服务

4. 实施和监测

4.1. 启用已开发并通过测试的数据服务时，对实时数据处理过程需要实时监控运行状况

4.2. 应建立表示潜在问题的度量指标以及直接反馈问题的机制，尤其是当触发响应的复杂性和风险增加时，应建立对反馈问题的自动化处理和人工监控流程

4.3. 数据交互功能必须采用与最苛刻的目标应用程序或数据使用者相同的服务级别进行监视和服务