1.1. 数据集成和互操作(DII)描述了数据在不同数据存储、应用程序和组织这三者内部和之间进行移动和整合的相关过程

1.2. 数据集成是将数据整合成物理的或虚拟的一致格式

1.3. 数据互操作是多个系统之间进行通信的能力

1.4. 管理职能

1.4.1. 数据迁移和转换

1.4.2. 数据整合到数据中心或数据集市

1.4.3. 将供应商的软件包集成到组织的应用系统框架中

1.4.4. 在不同应用程序或组织之间数据共享

1.4.5. 跨数据存储库和数据中心分发数据

1.4.6. 数据归档

1.4.7. 数据接口管理

1.4.8. 获取和接收外部数据

1.4.9. 结构化和非结构化数据集成

1.4.10. 提供运营智能化和管理决策支持

1.5. 依赖于数据管理的其他领域

1.5.1. 数据治理

1.5.1.1. 用于治理转换规则和消息结构

1.5.2. 数据架构

1.5.2.1. 用于解决方案设计

1.5.3. 数据安全

1.5.3.1. 无论数据是持久化、虚拟化还是在应用程序和组织之间流动，都要确保解决方案对数据的安全性进行适当的保护

1.5.4. 元数据

1.5.4.1. 用于知晓数据的技术清单（持久的、虚拟的和动态的）、数据的业务含义、数据转换的业务规则、数据操作历史和数据血缘

1.5.5. 数据存储和操作

1.5.5.1. 管理解决方案的物理实例化

1.5.6. 数据建模和设计

1.5.6.1. 用于设计数据结构，包括数据库中的物理持久化的结构、虚拟的数据结构以及应用程序和组织之间传送的消息结构

1.6. 数据集成和互操作对数据仓库和商务智能、参考数据和主数据管理至关重要，因为所有这些都关注数据从源系统转换和集成到数据中心，以及从数据中心到目标系统，最终交付给数据消费者（人和系统）的过程

1.7. 数据集成和互操作是新兴大数据管理领域的核心

1.7.1. 大数据旨在整合各种类型的数据，包括存储在数据库中的结构化数据、存储在文档或文件中的非结构化文本数据以及其他类型的非结构化数据，如音频、视频和流媒体数据

2.1. 主要目的是为了对数据移动进行有效管理

2.2. 主要责任就是管理数据在组织内部的存储库与其他组织之间的双向流动过程

2.2.1. 如果管理不当，移动数据的过程可能会压垮IT资源和能力，并弱化对传统应用程序和数据管理领域需求的支持能力

2.3. 每个购买的应用程序都有自己的一组主数据存储、交易数据存储和报表数据存储，这些数据存储必须与组织中的其他数据存储集成

2.3.1. 扩大了企业数据集成和互操作性的需求

2.4. 对企业来说，管理数据集成的复杂性以及相关成本是建立数据集成架构的原因

2.4.1. 企业级的数据集成设计远远比分散的或点对点的解决方案效率更高、成本更低

2.4.2. 在应用程序之间采用点对点的解决方案，可能产生出成千上万的接口，即使最有效率和最有能力的IT支撑组织也会被迅速拖垮

2.5. 数据仓库和主数据解决方案，如数据中心(Data Hub)，通过整合许多应用程序所需的数据，并为这些应用程序提供一致的数据视图，从而能缓解这个问题

2.5.1. 通过使用企业数据集成技术（如中心辐射型集成(Hub-and-Spoke Integration)和规范化消息模型等）可以极大地简化管理这些数据的复杂性

2.6. 另一个业务驱动因素是维护管理成本

2.6.1. 在使用多种技术来移动数据时，每种技术都需要特定的开发和维护技术，这样都会造成支撑成本增加

2.6.2. 标准工具的应用可以降低维护和人力成本，并提高故障排除工作的效率

2.6.3. 降低接口管理的复杂性不仅可以减少接口的维护成本，并使支撑资源能更有效地在企业其他优先事务中发挥作用

2.7. 数据集成和互操作(DII)还支持组织遵守数据处理标准和规则的能力

2.7.1. 企业级数据集成和互操作系统可以重用代码，从而实现规则的兼容性，并简化兼容性验证工作

3.1. 实施目标

3.1.1. 及时以数据消费者（人和系统）所需的格式提供数据

3.1.2. 将数据物理地或虚拟地合并到数据中心

3.1.3. 通过开发共享模型和接口来降低管理解决方案的成本和复杂度

3.1.4. 识别有意义的事件（机会和威胁），自动触发警报并采取相应行动

3.1.5. 支持商务智能、数据分析、主数据管理以及运营效率的提升

3.2. 原则

3.2.1. 采用企业视角确保未来的可扩展性设计，通过迭代和增量交付实现

3.2.2. 平衡本地数据需求与企业数据需求，包括支撑与维护

3.2.3. 确保数据集成和互操作设计和活动的可靠性

3.2.3.1. 业务专家应参与数据转换规则的设计和修改，包括持久性和虚拟性

4.1. 数据集成和互操作的核心是抽取、转换和加载(ETL)这一基本过程

4.2. 无论是在物理状态下或虚拟状态下，批量的或实时的执行ETL都是在应用程序和组织之间数据流动的必要步骤

4.3. ETL可以作为定期调度事件执行（批处理），也可以在有新数据或数据更新后执行（实时或事件驱动）

4.3.1. 操作型数据处理往往是实时或准实时的

4.3.2. 分析或报表所需的数据通常在批量作业中

4.4. 对于需要超低延迟的数据集成需求来说，它通常不会包括数据集成中间结果的物理分段

4.5. 抽取

4.5.1. 抽取过程包括选择所需的数据并从其源数据中提取

4.5.2. 被抽取的数据会在磁盘或内存中的物理数据存储库中进行储存

4.5.3. 如果在磁盘上进行物理缓存，则缓存数据库可以和源数据库或目标数据库合并，或者与两者都合并

4.6. 转换

4.6.1. 转换过程是让选定的数据与目标数据库的结构相兼容

4.6.2. 转换包括多种情况

4.6.2.1. 格式变化

4.6.2.1.1. 技术上的格式转换，如从EBCDIC到ASCII的格式转换

4.6.2.2. 结构变化

4.6.2.2.1. 数据结构的变化，如从非规范化到规范化的记录

4.6.2.3. 语义转换

4.6.2.3.1. 数据值转换时保持语义的一致化表达

4.6.2.4. 消除重复

4.6.2.4.1. 如规则需要唯一的键值或记录，以确保包括扫描目标、检测和删除重复行的方法

4.6.2.5. 重新排序

4.6.2.5.1. 改变数据元素或记录的顺序以适应已定义的模式

4.6.3. 转换可以批量执行，也可以实时执行，或者是将转换结果存储在物理状态下的缓存区域，或者是将转换后的数据存储在虚拟状态下的内存中，直至移动到加载步骤为止

4.7. 加载

4.7.1. 加载过程是在目标系统中物理存储或呈现转换结果

4.8. 抽取、加载、转换(ELT)

4.8.1. 如果目标系统比源系统或中间应用系统具有更强的转换能力，那么数据处理的顺序可以切换为ELT——抽取、加载、转换

4.8.2. ELT允许在数据加载到目标系统后再进行转换

4.8.3. ELT允许源数据以原始数据的形式在目标系统上实例化，这对其他进程是有用的

4.8.4. 用ELT的方式加载至数据湖，这在大数据环境中是很常见的

4.9. 映射

4.9.1. 映射(Mapping)是转换的同义词，它既是从源结构到目标结构建立查找矩阵的过程，也是该过程的结果

4.9.2. 映射定义了要抽取的源数据与抽取数据的识别规则、要加载的目标与要更新的目标行的识别规则（如果有的话）以及要应用的任何转换或计算规则

5.1. 时延(Latency)是指从源系统生成数据到目标系统可用该数据的时间差

5.2. 不同的数据处理方法会导致不同程度的数据延迟

5.2.1. 延迟可以是很高（批处理）或较高（事件驱动），甚至是非常低（实时同步）

5.3. 批处理

5.3.1. 大多数数据在应用程序和组织之间以一批文件的形式移动，要么是根据数据使用者的人工请求，要么是按周期自动触发

5.3.1.1. 这种类型的交互称为批处理或ETL

5.3.2. 对于批处理数据集成解决方案，在源中的数据更改和目标中的数据更新之间，通常会有明显的时延，从而导致高延迟

5.3.3. 批处理对于在短时间内处理大量数据非常有用，它倾向用于数据仓库数据集成解决方案，即使在低延迟解决方案可用时也是如此

5.3.4. 为了实现快速处理和低延迟，一些数据集成解决方案使用微批处理

5.3.4.1. 微批处理是指使批处理的运行频率高于按天更新的频率，如每5分钟运行一次

5.3.5. 批量数据集成可用于数据转换、迁移和归档以及从数据仓库和数据集市中抽取和加载数据

5.3.6. 为了避免数据集的不完整，对数据转移到数据仓库的作业应按照每日、每周或每月的报表来进行调度

5.4. 变更数据捕获

5.4.1. 变更数据捕获是一种通过增加过滤来减少传送带宽需求的方法，只包含在特定时间范围内更改过的数据

5.4.2. 源系统填入特定的数据元素

5.4.3. 源系统进程在更改数据时被添加到一个简单的对象和标识符列表，然后用于控制抽取数据的选择

5.4.4. 源系统复制已经变化的数据

5.4.5. 在基于日志的更改数据捕获中，数据库管理系统创建的数据活动日志被复制和处理，然后寻找将其转换并应用到目标数据库的特定更改

5.5. 准实时和事件驱动

5.5.1. 大多数未采用批量方式的数据集成解决方案都是使用准实时或事件驱动的方式

5.5.2. 数据在特定的时间表内是以较小的集合进行处理，或者在事件发生时处理，如数据更新

5.5.3. 准实时(Near-Real-Time)处理具有更低的延迟，而且通常因为工作是随时间分布的，所以系统负载较低

5.5.3.1. 通常比同步数据集成解决方案要慢一些

5.5.4. 准实时数据集成解决方案通常是使用企业服务总线来实现

5.5.5. 状态信息和进程的依赖必须由目标应用程序加载过程来进行监控

5.6. 异步

5.6.1. 在异步数据流中，提供数据的系统在继续处理之前不会等待接收系统确认更新

5.6.2. 异步意味着发送或接收系统可能会在一段时间内离线，而另一个系统可以正常运行

5.6.3. 由于在异步配置中对应用程序进行的数据更新不是及时的，所以称为准实时集成

5.6.4. 在接近实时的环境中，源中进行的更新与中继到目标数据集之间的延迟通常为秒级或分级

5.7. 实时，同步

5.7.1. 有些情况下，源数据和目标数据之间不允许存在时间延迟或其他差异

5.7.2. 当一个数据集的数据必须与另一个数据集的数据保持完美的同步时，必须使用实时的同步解决方案

5.7.3. 如果任何需要更新数据的应用程序处于不可用状态，那么主应用程序中的事务就无法完成

5.7.4. 两阶段提交要确保事务中的所有内容更新，要么都是成功的，要么都没有成功

5.7.5. 在状态管理方面，实时的、同步的解决方案比异步解决方案的需求少，因为事务处理的顺序显然应由更新应用程序管理

5.8. 低延迟或流处理

5.8.1. 随着事件的发生，“流数据”在事件发生后立即从计算机系统实时连续地流出

5.8.2. 数据流捕捉事件，诸如购买商品或金融证券、社会媒体评论以及从传感器监控位置、温度、使用情况或其他的读数等

5.8.3. 低延迟数据集成解决方案旨在减少事件的响应时间

5.8.4. 传统磁盘驱动器的读写过程比处理内存或固态磁盘驱动器中数据的速度要慢数千倍

5.8.5. 异步解决方案通常用于低延迟解决方案，这样事务在处理下一个数据之前不需要等待后续进程的确认