在单一层面来看，数据集成问题在我们的现实场景中非常简单，即从多种源获取数据，清理和转换数据，然后将数据加载到适当的数据存储区中以用于分析和报告。遗憾的是，对于一个典型的数据仓库或商业智能项目，企业需要在其数据集成阶段花费 60~80 ％的可用资源。为什么会如此艰难呢？
技术挑战
技术挑战首先来自于源系统。我们正在从收集交易（如客户承诺获取、购买或以其他方式获得东西）数据向收集预交易（如网页点击或通过 RFID 标记追踪客户意图的机制）数据转变。现在不仅可以通过传统的源和格式（如数据库和文本文件）获取数据，而且正日益可以以各种不同的格式（从专有文件到 Microsoft Office 文档以及基于 XML 的文件）和基于 Internet 的源（如 Web 服务和 RSS 流）获取数据。最具针对性的挑战是：
◆多种源与多种不同的格式。
◆结构化、半结构化和非结构化数据。
◆在不同时间从源系统获得的数据信息。
◆庞大的数据量。
在理想情况下，即使您能够设法以某种方式在一个位置获得所需的所有数据，也会面临新的挑战，包括：
◆数据质量。
◆不同数据格式的识别。
◆数据格式转换（转换为业务分析可用的格式）。
假设您能够通过某种方式获得所需的所有数据，并且可以清理、转换数据以及将数据映射成为一种有用的格式。即便如此，您仍然可以不使用传统的数据移动和集成方式。更确切的说，可以从一种固定的、长期的、面向成批数据的方式向不固定的、短期的、基于需求的方式转变。大多数组织在“停机时间”使用一种面向成批数据的处理方式，因为在这段时间内用户不会在系统上发出大量请求。这种方式通常会在夜间、使用一个预先定义的处理时长为 6~8 小时的批处理窗口来执行，因为此时办公室里应该没有任何人。但随着每种大小和类型的业务的日益全球化，实际的情况已并非如此。现在从全世界的企业来看，它们只有很少（假如有）的停机时间，而且无论何时总是有人会呆在办公室的某个地方。
结果您发现：
◆尽快加载数据的压力日益加大。
◆需要在同一时间加载多个目标位置的数据。
◆目标位置存在多样性。
您不仅需要实现所有这些任务，还需要尽可能快地实现它们。例如在线业务就是一种极端的情况，
最后，当你既需要针对应用程序整合的实时事务处理技术、又需要针对海量数据的集成技术来解决企业业务问题时，如何将数据紧密集成到公司的整体集成架构中，就变得更加重要。
组织挑战
在大型组织中进行数据集成存在两大问题，这就是“权力”挑战和“舒适地带”挑战。
“权力”挑战
数据就是力量，通常要使人们相信数据是一个公司的真正有价值的共有资产很困难。要使企业的数据集成获得成功，那么多个数据源的全部所有者都必须了解项目的用途和动向。有关各方缺乏合作是造成数据集成项目失败的一个主要原因。行政部门的帮助、达成的共识，以及强大的数据集成团队和多方相关人员是决定成功与否的少数关键因素，这些因素可以帮助解决问题。
“舒适地带”挑战
在以多种方式分析孤立的需求时，可以解决数据集成的挑战。手动编码解决了约60％的数据集成问题。可用于解决类似问题的技术包括从复制、ETL、SQL 到企业应用程序集成（EAI）。人们总是倾向于使用他们熟悉的技术。虽然这些技术的功能有些重复，而且或许它们也能够独立完成任务，但我们可以优化这些技术，使它们能够解决各式各样的问题。当尝试解决企业数据集成的问题时，假如缺乏健全的体系结构及适当的技术选择，则可能导致失败。
经济挑战
本文前面概述的与组织和技术相关的问题，共同导致了数据集成成为任何数据仓库/商业智能项目的最昂贵部分。导致数据集成成本增加的主要因素是：
◆以数据集成必需的格式来获取数据的过程，最终变成了一个充满组织权力游戏的缓慢而曲折的过程。
◆清理数据以及从多种源将数据映射为一种连贯的、有意义的格式极其困难。
◆标准的数据集成工具往往不能提供足够的功能或可扩展性来满足项目的数据转换要求。这可能会导致需要对为了完成任务而开发特殊ETL代码所发生的咨询费用支付巨额金钱。
◆公司的不同部门都在关注数据孤岛中的数据集成问题。
当需要集中解决这些问题时，这些数据集成方面的努力所引起的额外费用将会纳入全企业范围的数据集成体系结构。
随着组织发展过程中对数据入库和商业智能需求的增加，有缺陷的数据集成体系结构将变得越来越难以维护，总体拥有成本也会激增。
这种企业必须持续集成数据。但是，实际的批处理窗口操作时间和滞后时间总会超时数分钟。许多这种情形下的决策过程是使用持续运行的软件自动完成的。
面对不允许有任何停机时间的业务需求，可扩展性和性能变得越来越重要。
假如没有适当的技术，那么在入库和集成处理的每个步骤，系统几乎都需要分段处理。由于在提取、转换和加载（Extract, Transform and Load， ETL）的处理中需要合并不同的（特别是非标准的）数据源，而且需要执行更复杂的操作（如数据挖掘和文本挖掘），这加大了对数据分段处理的需要。举例来说，在图 1 中，由于进行分段处理，使“关闭循环”（即开始分析并处理新数据）进程所用时间也相应增加。这些传统的 ELT 体系结构（与加载之前发生的增值 ETL 进程相对）为应对新出现的业务需求，对系统能力施加严格的限制。
图一
日益增加的全球性法规需求，要求公司保持清晰的审计线索。仅保持数据可靠是不够的，还需要数据能够被跟踪和验证。