SSIS操作和优化指南.docx

操作和优化指南 技术文章作者： 、 、 、 、 技术审校： 、 、 、 发布时间： 年 月适用范围： ； 摘要： () 是一种高效的数据移动工具，可作为整个提取、转换和加载 () 解决方案的一部分以及作为数据移动解决方案的一部分，在 () 中移入和移出数据。 可以有效地用于在云中的源和目标之间移动数据，以及用于混合方案中在云和内部之间移动数据。本白皮书概要介绍了针对云中的源和目标的 最佳做法，论述了针对 项目的项目规划（无论该项目是全都处于云中还是涉及混合数据移动），并且通过一个示例演练了如何通过向外扩展数据移动来最大限度地提高混合移动的性能。版权信息本文档按“原样”提供。本文档中的信息和表达的观点（包括 和其他 网站引用）如有更改，恕不另行通知。您应承担使用本文档所带来的风险。本文档中提及的某些示例只是为了便于说明，纯属虚构。不应据此联想或妄加推断。本文档不向您提供对任何 产品中的任何知识产权的任何法律权利。您可以出于内部参考目的复制和使用本文档。 。保留所有权利。目录简介项目设计问题范围和说明为什么数据移动在 中如此重要关键的数据移动方案初始数据加载和从内部迁移到云将云生成的数据移到内部系统在云服务之间移动数据现有工具、服务和解决方案 () 中的 类大容量复制程序 () 存储 和队列设计和实现选择设计和实现平衡的体系结构数据类型注意事项解决方案包装和部署创建可移植解决方案包和代码组件分发 作为数据移动目标体系结构注意事项针对在不丢失管道进展的情况下重新开始的设计基本原则具有单个目标的示例具有多个目标的示例针对重新开始的其他提示针对无需手动干预的重试进行设计纳入重试 性能优化选项优化网络设置。网络设置。注意：在更改您的网络接口卡的设置以便使用极大帧时，请确保网络基础结构可以支持此类型的帧。 包设置 数据的特殊注意事项使用 中的新功能监视跨分布式系统的性能将性能统计信息记入日志查看执行统计信息监视数据流结论简介 () 是一种高效的数据移动工具，可作为整个提取、转换和加载 () 解决方案的一部分或作为不要求转换的数据移动解决方案的一部分，在 () 中移入和移出数据。 对于多种源和目标都很有效，无论这些源和目标是全都处于云中、全都处于内部还是在混合解决方案中混用。本白皮书概要介绍了针对云中的源和目标的 最佳做法，论述了针对 项目的项目规划（无论该项目是全都处于云中还是涉及混合数据移动），并且通过一个示例演练了如何通过向外扩展数据移动来最大限度地提高混合移动的性能。项目设计在云和内部数据存储区之间移动数据的项目可能会涉及不同解决方案中的不同过程。而其中的许多环节常常是从最初对目标的填充开始（这可能要获取来自其他系统或平台的数据），在整个过程中进行维护（例如在数目变化的分区或分片中对数据集进行重新平衡），并且可能要继续定期执行大容量数据操作或刷新。与传统的、完全内部的数据移动环境相比，涉及云的数据移动解决方案在项目设计和基本假设上往往存在很大差异。许多所学知识、经验以及做法仍将适用，但需要进行改变以便适应差异，例如随着您移到商用资源的共享池，您的环境不再是独立的并且不再完全由您控制。这些差异要求更加平衡、更具可伸缩性的方法以便获得成功。问题范围和说明对于从开始就是为云构建的本机解决方案以及对于迁移的解决方案来说，需要来回移动数据。这可能在应用程序生命周期的多个阶段中发生。这些阶段包括生产前测试、初始数据加载、云生成的数据和原始内部数据库之间后续的数据同步以及从云向下到其他内部系统（例如数据仓库）进行的重复的数据快照。图数据移动方案本节主要针对初始数据加载阶段：考虑从源数据库提取数据、从内部移到云以及将数据加载到最终目标的端到端体验。要特别强调的是，本白皮书中描述的大多数（如果不是全部）最佳做法和优化同样适用于大多数描述的方案，只需进行很小的改动。我们将在接下来的几节中讨论这些方案及其主要问题。为什么数据移动在 中如此重要在传统的数据中心中，应用程序和系统之间的数据移动挑战通常与应用程序兼容性、过程业务流程和同步以及物理硬件资源和网络功能之类的问题相关；而在 之类的云环境中，还存在若干其他层面的复杂性。此类复杂性可能存在于内部和云之间（或者不同云服务之间）的连接等方面，并且可能与连接可靠性、带宽和延迟相关。考虑这一复杂性对于开发最佳的数据移动解决方案而言至关重要。如果您的解决方案中涉及大量移动部件时，将您的工作侧重于在所涉及的所有组件和技术之间寻找平衡的设计可能更为重要。您应该尽力避免在整个链条中最薄弱的环节上出现“数据洪流”，因为这将会对所有其他方面产生负面影响。基于我们的测试，其中一个关键环节就是数据目标以适当的速率吸收从外部推送到其中的数据量的能力。最常见的方法是使用自定义的分片 () 将目标数据库向外扩展到多个后端节点。如果要加载的数据量非常大（截至撰写本文之时，超过 小时就被视为非常大），则此技术将是必需的，并且可将此技术应用于 实例以及在 虚拟机 () 中运行的 。由于此技术不会在数据加载解决方案中自动引入线性扩展，因此还需要进一步平衡解决方案中的其他移动部件。在下面的几节中，我们将讨论最关键的几个方面以及可用来实现最优结果的设计选项。关键的数据移动方案下面是我们可视作整体端到端数据移动体验一部分的三个主要方案。这三个方案包含了我们迄今为止已发现的大多数重复性主题和挑战。 初始数据加载和从内部迁移到云 将云生成的数据移到内部系统 在云服务之间移动数据初始数据加载和从内部迁移到云图 初始数据加载方案需要从内部移到云环境的每个应用程序都需要移动一定量的数据。在数据量变得很大时，此操作可能会带来一些重大挑战，促使我们使用与内部使用的方法稍有不同的方法。原因主要集中于以下几个方面：公共网络带宽和延迟，以及在云环境中承载数据库（ 或 ）的物理硬件节点中提供的用于执行数据加载阶段的（共享）资源量。有一些特定的方法（见图 ）可有助于尽量减少性能最低的组件对整个解决方案的影响，例如将原始数据分区为多个存储桶文件并且在跨网络传输前对这些文件进行压缩。对数据进行分区还将有助于在云端简化将这些数据插入到数据目标的操作，因为这些目标非常有可能跨多个 实例进行分片或由多个 承载。无论是在内部还是在云端实际执行导入和导出操作， 都扮演着重要的角色。整体解决方案可能需要 存储和队列之类的其他技术，以便存储中间文件格式以及协调跨 导入过程的多个实例的复制和检索操作。有关与将数据库架构和对象迁移到 相关的详细信息，请参阅将以数据为中心的应用程序迁移到 () 指南。将云生成的数据移到内部系统这个方案是前一种方案的变体形式，因为从技术角度来说，这个方案是将加载过程和数据流颠倒过来，但是在整体目标上可能有一些差异。此方案通常与需要反复检索并加载到内部系统（例如数据仓库）的云生成的数据相关联，或者与作为本地事务解决方案数据源的数据相关联。这意味着在前一节中提到的大多数方法和技术对于此方案也适用。 将提取云端上的数据，然后对数据进行压缩并将数据发送回内部系统，在内部系统中，所有的传统指导原则还将适用。有关详细信息，请参阅数据加载性能指南 ()。在云服务之间移动数据有几种方案需要在不同的云服务和数据库之间移动数据。其中包括在需要彼此交互的不同解决方案之间进行的数据交换，以及在不同分片中承载的表之间重新分布分区数据，如下面的图 中所图 在数据库分片之间移动数据示 或虚拟机中的 或虚拟机中的 的。这些分片可由 实例或者 中的 均匀地承载，而无需更改基础方法和体系结构。与以前的方案不同的是，整个数据移动过程通常将在单个 区域的边界内发生，从而显著降低了网络延迟的影响，并且消除了通过中间存储位置（本地磁盘或 存储）导出和导入数据的需要。尽管某些方案可能要求跨区域移动数据，但这不在本白皮书的论述范畴之内。同时，由于数据源和目标都将在共享的云环境中承载，因此更加需要对加载阶段特别加以优化。现有工具、服务和解决方案为了实现涵盖前述方案的解决方案，您可以混用现有工具和新工具，并且混用在内部和云中都可以起到帮助作用的组件和方法。在混合环境中，上述某些组件可能需要与内部的现有系统和数据源共存一处，而其他一些组件可能更适合与云中的数据目标共存。 ()作为主要的数据移动和集成解决方案， 提供了多种不同形式的工具，涵盖了在这一系列方案中所要求的大多数方面。尽管并不是为混合环境专门设计的，但随着 的出现， 包在内部和在云中都可以执行，并且可能能够将这两种环境直接联系起来。这就打开了一扇大门，使 开发人员社区中的大量知识和技能能够重复使用，因为许多现有专业人员对这些技术已经熟练掌握并且颇有心得；但是，一定要理解的是，在将数据从内部移到云中时，并非使用 实现的所有现有 流程都可以直接重复使用。根据流程的复杂程度、数据量和速度，以及基于云的数据目标（例如在 中运行的 和 ）之间的固有差异，需要在某些程度上对结构进行重新设计。其中的某些挑战可能在于，当前缺乏能够在连接到 时处理云连接实际情况的功能，或者在设计 包时需要考虑到这些包必须在数据加载过程中能够处理失败和重试，从而导致设计所需的工作量太大。另一个挑战可能在于，在设计包时需要考虑到这些包必须能够连接到分区的（分片的）数据目标，而这些数据目标中的数据库实体可能分布到有时候数目会发生变化的物理节点上。必须对分区逻辑和元数据加以管理，并且必须能够从应用程序配置文件或数据结构检索到这些信息。 平台已具有用于应对这些挑战的大多数功能。例如，您可以使用数据流组件（例如有条件拆分和多播转换）实现分区逻辑。在解决上述任何体系结构方面的挑战时，还需要执行某些工作以便切实实现新设计，通过使用传统的可视化工具方法或通过使用更为自动化的编程方法，构建出更复杂的解决方案。对于编程的方法， 提供了完全可编写脚本的环境，能够执行从在转换管道内创建自定义任务到帮助故障排除和调试包执行的引擎检测在内的一系列任务。 中提供了一个基于公共目录的完整监视和管理解决方案，可以帮助您设计分布式数据移动解决方案并且收集与包执行统计信息和结果有关的信息。 中的 类如果开发自定义数据移动解决方案是解决特定数据移动问题的首选方法，则 数据访问库内的 ( ) 类可能是用于完成这项工作的最常用工具之一。这个类是在 大容量复制 的基础上加上瘦封装构建的，它可以接受数据表作为输入，可以接受现有数据库连接，并且可以提供快速且完全可配置的方法将数据加载到 或 中。使用 类与基于云的数据目标进行交互的一个重要方面就是能够轻松地使用更适合的 () 类（这个类是暂时性故障处理应用程序块 () 的一部分）替代传统的 () 类来与服务器交互。这极大简化了在新的或现有数据加载过程中实现重试逻辑机制的任务。该库的另一个有趣的方面是能够提供标准重试策略以及定制的重试策略，从而可以针对不同的连接条件轻松地进行调整。 类公开所有必需的特性和属性，以便能够对加载过程进行调整，使其可适合几乎任何条件。本文将说明如何根据数据加载过程所运行的位置、该过程需导入的数据量以及该过程和数据目标之间可用的连接类型，对批大小进行优化。如果单个批内的数据量非常低，例如每批只包含 到 行的数据，这时 类就不是将数据加载到目标中的最高效的选择。在这种情况下， 类在数据加载开始前建立初始元数据检查所需的系统开销可能会影响整体性能。因此，对于较小的批，有一个很好的替代方法，那就是定义用于实现所需架构的表值参数 ()，并使用“ * ”加载数据。有关使用大容量复制 的完整示例，请参阅 类()。大容量复制程序 ()有时候，我们也会使用大容量复制程序（针对前文的 类一节中所述的大容量复制 创建的一个命令行实用工具）来将数据大容量移入或移出 实例。该程序是一款简单但功能却很强大的工具，可有效地自动执行简单的数据移动解决方案。该工具的主要优点之一就是可以很方便地在 计算节点或 中自动安装工具，并且可以轻松地使用经过相应调整可在云环境中运行的现有脚本。但另一方面， 不提供任何高级的连接管理功能。此外， 在实现可靠数据移动任务方面所需的工作与 相差无几，但所基于的重试操作却可能导致连接不稳定和丢失。而且，与我们提到的其他工具不同， 必须从本地驱动器、映射的驱动器或连接的驱动器上承载的物理文件中导入或导出数据。这使得无法将数据直接从源传送到目标，或者无法像 或基于 的应用程序那样以编程方式从不同源读取数据。 存储 和队列从严格意义上讲， 存储功能并不能算是与数据移动相关的工具，但对于实现在内部和云过程之间要求中间存储的复杂解决方案，以及用来协调这两个环境之间各个阶段和操作的功能而言， 存储功能都是不可或缺的一部分。 存储 可以作为一个强大的存储机制，用来加载中间文件以及在 计算节点或 和内部运行的应用程序之间交换这些文件；而 存储队列可以作为一个简单的消息传递工具，用于控制和协调从数据加载过程对以 形式存储的文件和内容的访问。 存储 和 存储队列可以很轻松地集成到现有应用程序中，这得益于 存储客户端库。该库提供了一组简单的类，可以与存储帐户、容器、 和相关操作进行交互。该库隐藏了基于 的基础接口的详细信息，并且在内部和云数据之间提供一个桥梁。有关使用 存储队列以及 的详细信息，请参阅如何使用队列存储服务 ( ) 和如何在 中使用 存储服务 ()。设计和实现选择若干因素可能会影响与混合数据移动解决方案有关的设计和实现选择。与“白手起家”相比，重复利用现有项目和过程的要求可能对体系结构决策的影响力最大，而团队成员的技能集和个人情况（例如，您是有更多的现成的开发人员还是更多的 ）也会对决策产生影响。您的团队所拥有的技能集，是能够以编程方式构建完全自定义的解决方案，还是能够对现有 流程进行调整？在任何一种情况下，在您将云引入设计时都要考虑一些事项，因为您对传统的内部环境所作出的某些显而易见的假定在云环境中可能是无效的。另一个重要的设计方面是放置和运行特定数据移动任务和服务的位置，例如执行分片或数据压缩活动的有条件拆分逻辑。根据在组件级别实现这些任务的方式（ 管道或自定义任务），这些组件可能会大量占用 。为了平衡对资源的使用，可能有必要将这些任务移到 并且利用云环境与生俱来的灵活性。同时，尽量接近要进行操作的数据源可能会带来甚至更大的好处，因为这样做会降低网络延迟，而网络延迟在此类型的解决方案中可能真的是很关键的因素。通过计划和测试，可帮助您确定具体的资源瓶颈，并且帮助您制订如何实现不同任务的决策。您还必须从实现混合方案所需的工作量以及混合方案所带来的好处两个方面进行权衡，决定是采用全新的混合方案，还是将现有解决方案改编成混合方案。不过凡事有利必有弊，将解决方案的某些部分移到云中可以得到某些技术上的好处，但是也可能由此部分丧失原有的优势，因此您必须权衡利弊，明确正确的方向，从而在混合方案的实现中取得成功。这些权衡会对解决方案设计的各个具体方面产生影响。如何既能够利用云平台所提供的众多向外扩展功能，而又不会失去太多对解决方案组件的控制？如何能够在设计为向外扩展而不是向上扩展的平台上运行我的数据加载过程，而且仍然能够获得可接受且可预测的性能？要解决这些疑问，您需要放弃有关网络连接性能和可靠性以及始终运行的应用程序组件和服务的一些固有想法，而是应该对可以添加以便解决性能问题的资源进行计划。这就要求您了解目标环境的特性：在这个环境中，需要针对失败进行设计，延迟通常要高出您过去的体验，并且强烈期望将工作负荷划分到许多较小的虚拟机或服务上。设计和实现平衡的体系结构在设计具有多个移动部件（而其中没有任何一个部件必然成为传统内部组件的“最佳”替代品）的复杂数据移动解决方案时，所有这些注意事项应该会引导我们的设计沿着正确的方向进行。应遵循以下指导原则：将数据移动过程分解为从数据源提取到数据目标加载的多个更小的部分，这些部分必须异步进行且加以协调，以便适合于混合解决方案所带来的延迟时间更长的环境。在一个环境中的所有组件之间找到适当的平衡将比满足针对单个组件的硬性等级（限制）重要得多。甚至此过程中的单独步骤（例如数据加载）也可能需要划分为若干更小的加载流（适合不同的分片或物理数据库），以便克服我们的 体系结构中单个后端节点的限制。由于我们的系统中某些组件（ 节点和用于承载 的 的 存储 存储库）具有高度可用、共享和多租户的特性，因此将过多数据推送到单个节点中可能会造成其他性能问题。例如，其中一个性能问题就是复制机制出现“堵塞”，使整个数据加载过程的速度降低。图平衡的数据加载体系结构的示意图数据类型注意事项所使用的数据库架构、实体设计和数据类型在许多方面都可能会影响数据移动过程。通常，在将数据从数据源大容量加载到 或用于临时操作的本地存储中时，能够实现高压缩的数据类型可带来若干好处。在通过网络传输数据前对数据进行压缩可提高进性能。解决方案包装和部署实现和部署横跨内部数据中心和云环境的解决方案通常意味着您需要处理若干组件和服务。如果您计划部署数据移动解决方案的多个实例，则在部署和配置所有这些部分时提供高度自动化就变得更为重要。虚拟化技术可帮助创建一个主映像。主映像可在内部和 基础结构中使用，以便简化在这两个环境中需提供的常见服务的部署。同时，就应用程序和关联的包和服务而言，与 角色和辅助角色之类的其他 计算节点所能提供的功能相比，使用 会引入一些限制（例如，考虑一下启动任务）。如果您已在利用软件分发功能，例如通过 和 产品系列提供的功能，还有一种可能就是要分发的解决方案组件和包中的一些组件在云中运行、而其他一些组件在内部环境中运行。此外还有一种可能，就是手动安装和配置不同的解决方案组件，例如 和 （用于访问 存储功能），以及作为分布式环境一部分运行的每个 中要求的所有应用程序安装包 ()。创建可移植解决方案当您在向外扩展体系结构中运行某一解决方案时，有一个方面将变得越来越重要，那就是必须能够迅速重新配置选项，例如连接字符串、凭据以及解决方案包含的所有其他配置选项。这通常要求某种形式的集中式配置机制，其中，系统将访问信息并且将这些信息传播到数据移动过程涉及的所有不同的组件和服务，以便确保尽量降低每次更改所需的工作量。请记住，标准工具（例如 ）以及定制组件和应用程序均可轻松地使用此方法实现。 存储可以是保存和维护配置信息的好选择，因为从内部和云组件均可轻松地访问和使用 存储。需要指出的是， 平台已包括若干功能，可简化对解决方案进行移植和缩放的操作，例如配置文件和参数。构成端到端数据移动解决方案的其他过程和服务可实现相同类型的可配置方法，从而便于在不同环境之间移动解决方案。包和代码组件分发在所有解决方案元素都已实现后，您选择跨多个计算机在物理上分发不同 包和代码组件的过程将变得至关重要。另一个更关键的方面将是如何在不同服务器和 内承载和执行这些包和代码元素。尽管 中的 本机环境提供不同的包存储类型和部署模型，但开发端到端数据移动解决方案可能要求不同的选择。如果您需要运行一些业务流程服务应用程序以便监视和控制数据移动过程，如何实现这些服务应用程序？您可以使用多少基础 体系结构？在“用于 和混合数据移动的 ”白皮书中提供了分发和协调组件的具体示例。该白皮书位于 库中针对 的 白皮书节点下。 和基于 的物理服务器并不实现 平台为 角色和辅助角色提供的某些功能。因此，最佳选择是将这些组件作为 服务实现，以便确保这些过程能够在不同主机引导时启动，并且将独立于该特定计算机上的交互式用户会话继续运行。利用 平台，可以非常容易地创建和包装此类型的软件包，然后可使用前述选项将软件包分发和部署到不同主机上。业务流程服务应用程序与不同的外部组件（ 存储、队列等）进行交互，调用 执行引擎 ()，并且在多个主机或 上协调数据加载和转换任务。包执行所要求的自定义组件还将需要跨多个节点进行分发。使用此分布式方法，可以创建强健、可移植和灵活的部署和执行环境，以便在完全混合的体系结构中承载我们的端到端数据移动解决方案。 作为数据移动目标尽管 和 具有相似之处，但将它们视为等同是错误的。 与 数据库存在一些差异，可能会影响应用程序的执行方式。 是实现全面的多租户体系结构的一种托管服务。与传统的 实现不同， 包含内置的高可用性 () 和自动备份之类的功能，并且在商用硬件而非大型服务器上运行。数据库运行常用于内部环境的一部分功能，包括数据库压缩、并行查询、列存储索引、表分区等。有关 的功能限制的详细信息，请参阅 功能限制 ( ) ()。 和 之间的一个最大差异是： 公开向外扩展的多租户服务，其中，不同的订阅分别共享 数据中心中的一个或多个计算机的资源。目标是通过偶尔将客户移动到不同计算机，平衡数据中心内的整体负荷。这些计算机是标准的基于机架的服务器，追求的是提供最高的性价比，而不是最高的总体性能。并非每个 节点在其托管产品服务中都需要使用非常高端的硬件。在某个客户应用程序需要超过针对单个计算机的限制时，必须对该应用程序进行修改，以便将客户工作负荷分布到多个数据库上（可能意味着分布到多个计算机上），而非分布到单个服务器。尽管此环境具备灵活性和可管理性，但有一个需要进行权衡的方面，就是有时候您的应用程序可能会意外移到其他计算机。因为会话是无状态的，所以，应用程序的设计应使用避免单点故障的技术。这包括在适当的时候在其他层中进行缓存以及对连接和命令使用重试逻辑以便能够应对故障。此外，在 基础结构中，不同的层将不会位于相同的网络子网中，因此，客户端应用程序和 之间将存在某些延迟方面的差异。甚至在应用程序和数据库处于同一个物理数据中心时也是如此。传统的 数据加载解决方案一般都需要很多往返数据流量，但是这种方式会因为 中的物理网络差异而运行速度更慢。对于熟悉早期客户端服务器计算的那些用户，此处可以采用同样的解决方法：仔细考虑解决方案中两个层之间的往返流量以处理任何可见的延迟差异。体系结构注意事项针对 包的一些最常见挑战是如何在执行期间处理意外失败，以及当您在失败后必须恢复处理时，如何尽量缩短完成 过程的执行所需的时间量。对于文件系统任务之类的控制流任务，可以使用检查点来恢复执行，而无需重新处理已完成的工作。有关使用检查点的完整说明，请参阅通过使用检查点重新启动包 ()。通常，数据流是 包中最大的部分。在本节中，您将看到用于对包进行设计以便允许在出现故障时自动重试的策略，以及用于对数据流管道进行设计以便允许从故障点重新开始而不是重试整个数据流的策略。在“用于 和混合数据移动的 ”白皮书中介绍了在 平台中进行暂时性故障处理的其他注意事项。该白皮书位于 库中针对 的 白皮书节点下。针对在不丢失管道进展的情况下重新开始的设计在设计包时，最关注的设计要点之一就是确保在出现失败时不会丢失包在执行到该故障点之前所取得的所有进展。对于包的控制流中的项，可通过使用检查点来实现这一点。但是，能够在不丢失所取得进展的情况下重新开始数据流只能通过对包进行设计来实现。在本节中，您将看到一个针对包设计的策略，该策略允许数据流从故障点重新开始，并且允许包自动重试，以便在连接丢失时不会失败。在将数据移入或移出 时，对此类连接丢失或短暂中断进行计划变得特别重要。基本原则尽管在任何数据移动过程中性能都十分重要，但是，如果在数据移动过程中发生某个意外情况，您应该在性能要求与您可以承担的数据进展丢失量之间进行权衡。在每个数据移动中，您都必须具有某种方法以便知道哪些数据已抵达目标，哪些数据还没有抵达。在仅插入数据时，最常见的是由主键单独确定数据抵达情况。对于其他一些数据，可按上次修改日期确定。无论数据特性如何，针对重新开始进行设计的第一个部分就是要理解如何标识已在目标存在的数据、在目标必须更新的数据以及仍需传送到目标的数据。在您建立了对这些数据的理解之后，就可以对这些数据进行划分和排序，从而允许您只处理尚未到达目标的数据，或者尽量减少在任何阶段必须完成的返工量。通过对数据划分块区和排序，您可以轻松地跟踪已处理哪些块区，然后通过排序，可以跟踪任何块区内的哪些记录已处理。按照这个方法执行，您无需将每个源行与目标进行比较以便知道是否已处理该记录。更复杂的 过程可能有若干临时环境。每个临时环境都是 的一个阶段的目标。在这些类型的环境中，将您的每个临时环境视作一个单独的目标，并且针对重新开始对您的 的每个分段进行设计。具有单个目标的示例可重新开始的最简单数据流是以一个整数作为主键的小型数据流。在 是源时，您可以使用相应的最佳做法，限制从源提取的数据，然后对源进行查询。请考虑 的典型示例表：“”。该表具有以下结构：.(,(),)在这个示例中，该表使用一个整数作为主键。如果数据在移动时将是静态的，或者数据仅插入此表中（没有更新），则您只需知道该主键，即可了解某一行是否到达目标。将每个主键值与目标进行比较的代价相对高昂。而是应使用一个策略，按 列对源文件中的数据进行排序。对于此类策略，您只需要知道数据是按顺序进行处理的，以及在目标已提交的最高 是什么。在一个 包中，您可以通过执行以下操作做到这一点。1. 检查您的目标上的最高键。2. 从您的源生成查询，以便仅提取 高于目标上的最高 的记录。3. 在您的源查询中使用 可确保在下次启动包时，最高 的比较仍然有效。在 中，使用关系数据源作为您的源，您可以使用执行 任务将最高值提取到您的包中的变量中。但是，应考虑完全没有任何行在目标中存在的可能性。()在检索最大 时，需要考虑的一点是空表的检索结果将为 。这可能使包中使用的逻辑出现一些问题。一个更好的方法是首先在您的源上使用执行 任务，找出您的源中的最小未处理 。接下来，在您的目标中查询最大 ；如果该值不存在，则使用一个低于您的源中最小 的值。生成您的源查询以便只提取高于该值的记录，并且不要忘记在您的查询中使用 。注意：尽管从逻辑上讲，只需通过从目标中检索一个值，并且使用 函数或者在您的源查询的 子句中使用 语句，可以获取相同的结果，但这样做可能会导致性能问题，特别是在您的源查询会导致增加复杂性时。不要极力采用这种快捷方式。而是应找到可以安全地用作下限的值，并且使用该值生成源查询。注意：如果您的源是 ，则对聚集索引使用 子句不会导致 执行额外的排序工作。已对数据进行排序，从而无需执行 即可检索数据。如果位于目标的数据在同一列上也具有聚集索引，则在源进行排序会优化您的源查询，并且优化向目标插入数据的操作。它所具有的另一个效果是确保 管道内的排序，因此使您能够在故障点处重新开始数据流。若要生成此示例包，请执行以下操作。1. 在新项目或现有项目中创建一个新包。将该包重命名为“”。2. 创建连接管理器以便连接到您的源和目标。对于此示例，为源服务器和目标服务器创建一个 连接管理器。3. 将一个新的执行 任务拖到控制流图面上，并且将其重命名为“从源提取最小 ”。4. 在包级别创建一个 变量并将其命名为 。我们将使用此变量存储您刚添加的执行 任务所提取的值。确保数据类型为 ，以便匹配表中 的值，并且设置相应的初始值。5. 按照如下所示配置“从源提取最小 ”。a. 对其进行编辑并且将“连接”设置为您的源服务器的连接管理器。b. 尽管您可以在某个变量中存储您的 ，但对于此示例，将 保留为“直接输入”。打开 的输入窗口，并且输入以下查询：(), )注意：在将您的 查询输入 的编辑器中之前对这些查询进行测试。这样做可以简化调试工作，因为在 查询编辑器窗口中没有真正的调试帮助。图：对执行 任务进行配置以便在源找到最小 。c. 单击“确定”关闭“输入 查询”窗口。d. 将属性设置为“单行”。e. 在执行 任务编辑器的左窗格中，单击“结果集”以便配置您将从该查询捕获值的方式。f. 单击“添加”按钮以便添加结果集。g. 在新的结果集中，将“结果名称”更改为。请确保（您在步骤 中创建的步骤）显示在“变量名称”之下。该变量将存储该 查询的结果。h. 关闭“执行 任务编辑器”。在关闭后，该任务上应该没有显示任何错误。6. 将另一个执行 任务拖到控制图面上。将该任务命名为“从目标提取最大 ”。将成功优先约束从“从源提取最小 ”连接到这个新任务。7. 创建作用域为包的一个新变量。将这个新变量命名为。向其提供 的数据类型以便匹配 的数据类型，并且为其提供适当的初始值。8. 为新任务打开“执行 任务编辑器”，并且执行以下操作：a. 将设置为“单行”。b. 设置为您的目标服务器连接管理器c. ：直接输入d. 对于，使用 (), ?) 注意：? 是一个查询参数。我们将暂时设置该参数的值。e. 单击“确定”关闭“查询编辑器”，然后在的左窗格中单击“参数映射”。f. 单击“添加”以便添加单个参数。i. 对于“变量名称”，选择。ii. 对于“方向”，您应该选择“输入”。iii. 数据类型应该是 ，在此上下文中这是 位整数。iv. 将“参数名称”更改为。请注意，该名称必须更改为 。字符名称将导致错误。g. 在左窗格中，单击“结果集”。单击“添加”按钮以便添加新结果集。i. 将“结果名称”更改为 。ii. 在“结果集”下，选择作为您在步骤 中创建的变量的。在此任务执行后该变量将包含您输入的查询的结果。注意：下一步将因您在数据流中使用的源的类型而异。 源可将包含 语句的 变量用作其查询。 连接不能这样做，但可对其进行参数化，以便将某个包或项目参数用作其源查询。在此第一个示例中，您将 源与包含源查询的变量一起使用。9. 将一个数据流任务拖到您的控制图面上。将其重命名为“主数据移动”，并且将成功优先约束从“从目标提取最大 ”连接到此数据流任务。当包在此时执行时，您已存储了为当前执行建立起始点而需要知道的值。接下来，您需要设置一个变量以便承载 源查询。10. 创建作用域为包级别的一个新变量。将该变量命名为并且将数据类型设置为字符串。您将通过执行以下操作，使用表达式基于您为查询的起始点确定的值在运行时动态派生此变量的值。a. 单击“表达式”列右侧的省略号按钮以打开表达式生成器。b. 在表达式生成器的左上部窗口中展开“变量和参数”节点。您将使用在步骤 中创建的变量。您应该在列出的变量中看到此变量。该变量的数据类型为 ；但是，您将使用它作为 变量的一部分。为此，您将需要将其转换为 数据类型。在右上角的面板中，展开“类型转换”节点以便找到 (, ) 类型转换。c. 在“表达式”中，键入您的查询。在需要您的变量名称或类型转换的位置，您可以将它们从适当的窗口拖到“表达式”框中以便添加它们。这将有助于减少此编辑器中拼写错误的数目。按如下所示生成表达式： , , , , , , , , (, ) 请注意，使用类型转换将您的整数值更改为宽度最宽为 个字符的字符串。使用 个字符宽度是为了确保其足够大，足以包含整个范围的 值（在适用时会包括负值）。对于 ，您将需要 个字符宽度。根据检索的数据类型调整字符变量的大小。在您键入了表达式后，单击“计算表达式”按钮以便确保 可以对您的表达式进行正确分析。您将看到它会正确将 的初始值放置于计算的表达式中。在运行时将会相应设置该值。请确保在您的 语句中包含 子句。只有通过 ，您才能从关系数据库中获取有保证的顺序。您生成的重新开始方法取决于键值的顺序。d. 单击“确定”按钮关闭表达式生成器。您的动态构建的 语句现在存储于您的 变量中。11. 双击“主数据移动”数据流任务以便打开数据流设计图面。12. 将一个 源拖到您的数据流控制图面上。将其重命名为“从 检索”。注意：不能在数据流组件的名称中包含句点，因此，不允许使用“从 提取”的全名。如果您没有在表名称中使用下划线，则可以在 命名规范中使用下划线代替句点。13. 双击“从 检索”源以便打开“ 源编辑器”。a. 对于“ 连接管理器”，选择您的“源服务器”连接管理器。b. 在“数据访问模式”下拉列表中，选择“变量中的 命令”。c. 在“变量名称”下拉列表中，选择在步骤 中创建的变量。d. 单击“预览”确保您的查询可在源服务器上运行。e. 在编辑器的“列”页上，确保选择了所有列。f. 单击“确定”以退出“ 源编辑器”。14. 将一个 目标拖到控制图面上。将其重命名为“ 目标”。将“从 检索”源连接到这个新目标。通过双击打开该目标，然后通过执行以下操作进行配置。a. 在“ 连接管理器”下拉列表中选择“目标服务器”连接管理器。b. 对于“数据访问模式”，如果“表或视图 快速加载”尚未选择，则选择它。c. 在“表或视图的名称”下，从下拉列表中进行选择，或者键入您的目标服务器的名称。在这个例子中，该名称是。d. 如果您在使用上面给出的 的定义，则对于演示，可以保留“连接管理器”页上的默认设置。如果您在使用 数据库，将需要选择“保留标识值”。e. 在编辑器的“映射”页上，映射您的列。注意：在几乎所有情况下，最好将错误行发送到目标文件并且重定向输出。这并不是在管道上演示重新开始所必需的。有关创建错误流和重定向行的步骤，请参阅在数据流组件中配置错误输出 ()。f. 单击“确定”以退出“ 目标编辑器”。15. 通过开始一个导入并停止，然后重新开始，对此方法进行测试。每次数据流都应该自需要移动的下一行拾取。之前的行将被忽略。您刚刚生成了一个在失败后可重新开始其数据流的简单的包。可使用该包作为起始点，用于有关设计可重试的包的示例。请注意，您不希望该控制流中的任何任务保存检查点。如果该包失败并且必须重新开始，则您需要执行“从源提取最小 ”和“从目标提取最大 ”组件，以便找到该数据流在前一次执行中中断时的确切位置。在任何时候只要在数据中存在一些特性，从而能够找到数据流的中断点，那么像例子中所展现的那样对包进行设计以便能够找到其进展情况并重新开始其流就是一个很好的做法。而在更容易受到网络不确定性影响的环境（例如云）中，这一做法变得尤为重要。具有多个目标的示例此原则可以扩展到具有多个目标的数据流。此原则很有用的一个情形就是在将数据移入分片的数据模型（就像使用 通常所做的那样）时。在这些情形中，使用有条件拆分将每一行发送到其正确目标；或者对于引用数据，可以使用多播将所有数据发送给所有目标。下面是为重新开始进行设计时要牢记的关键原则。 不同的目标在失败时可能会进展到不同点。因此，您必须找到在每个目标中插入的最高键值。创建一个变量以便承载每个目标上的最高值。 在您的源上的起始点将是已成功插入目标中的最低键值之后的下一条记录。例如，如果插入某一分片集的最高键值如下所示，则在您的源上，您必须从 之后的下一条记录恢复您的数据流。o o o 因为这会产生某些数据可能被多次提取的可能性，所以您必须对每个目标进行筛选，以便避免主键冲突。使用有条件拆分转换可筛选出已处理的键值。对于上面的分片示例，您要创建名为 、 和 的变量。在执行 任务中，您要找到要在每个变量中存储的值。在有条件拆分中，您可以定义名为 、 和 的输出。输出的表达式应该如下所示。 如果任何行进入在特定分片上小于 的管道，但记录转到该分片，将不会发送该记录并且将不会遇到任何主键冲突。让这些记录转到默认输出，或者任何断开连接的输出，这样将不会进一步处理它们。图 ：针对 个分片配置的有条件拆分，并且配置为在目标没有主键冲突时允许重新开始。在任何执行开始时，每个目标上的最大键值存储于 变量中。在管道中，发往具有过低键值的分片的那些行将不会发送到目标，因此将不会被重新处理。这些行将转到默认输出。因为默认输出未连接，因此它们将不会在管道中进一步发展。针对重新开始的其他提示 在您的目标是某个文件时，使用一个变量表示您的文件名并且使每个文件名都有意义（例如，在文件名末尾追加序号或时间戳）。将不同数据块区处理到不同文件。如果您按相同顺序进行处理，并且您的块区明确定义，则可以查看已创建的文件并且从那里确定起始点。根据您的需求和逻辑，您可能需要移动、重命名或删除已处理的文件。 如果您的源是多个文件，则单独处理各文件并且跟踪当前文件是哪个文件。在重新开始时，您可以从最后一个成功处理的文件之后恢复。使用按文件名或日期排序，以便确保您每次都按照相同顺序处理文件，从而可以轻松确定成功处理的最后一个文件。 当 是您的源时，您可以使用 字符串数据类型查询整数值。只要字符串可以转换为 整数， 在优化期间就将转换数据类型。使用此原则，您可以将示例包中的和变量更改为字符串，更改“从目标提取最大 ”中的输入参数类型，并且将此包用作也将使用字符主键的模板。不要对 中的任何其他数据类型使用 数据类型，因为这将导致在检索最小和最大键值时执行完全扫描。 如果您的源是一个文件，或者是不能使用 或任何其他类型的筛选子句进行查询的任何源，则在您的数据流中执行以下操作。1. 将有条件拆分转换放置于您的源和目标组件之间。2. 在有条件拆分中，配置一个输出。将该输出命名为，或者命名为让您知道您并不想要这些行的其他某个名称。3. 对于使行发送到目标的条件，使用表达式筛选出已在您的目标中的行。例如，前一个示例的表达式将如下所示。 4. 不要将输出连接到任何组件，除非您真的需要对这些行进行计算。其仅有的用途就是筛选出在您的上次运行时处理的行。这不会阻止您读取已从该文件处理的行，但会阻止您再次将它们发送到目标，从而节省网络带宽。因为这些行未发送到您的目标，所以，无需从您的目标中删除任何数据。 在处理复合键时，使用关联的子查询来找到准确停止点。请确保按相同键对您的数据进行排序。下面是一个示例。(),(),()请注意该示例中采用的顺序。如果您在移动来自所有员工的所有记录，并且该顺序是您的键的顺序，这就是一个很好的排序。但是，如果所有（或某些）员工已在目标存在，并且您想要仅导入自上次导入后生效的更改，则应该按 、 和 排序才能够从您离开的位置执行恢复。对您所导入的内容进行分析，以便定义使您能够确定应该在何处继续执行的点的顺序。针对无需手动干预的重试进行设计 源和目标组件并不直接包括重试逻辑。但是， 包开发人员不会对处理这种情况束手无策。通过对您的包进行设计，以便您可以重新开始您的 包而不会丢失在数据流中已取得的进展，也使您能够在失败后通过其他一些考量自动重试。在将数据移入或移出 之类的情形中，您可能需要自动重试以便处理暂时性故障条件，例如资源或连接受到限制的情况。本节基于在上一节中阐释的概念并且以您的包中一个简单的重试逻辑为例进行了说明。然后，它将演示使用一个分块方法来允许重试每个块区，以便在暂时性故障更有可能发生的期间增加您的包的可靠性。有关 限制的详细信息，请参阅 性能和弹性指南()。纳入重试对于单个包，纳入重试涉及以下步骤。1. 确定失败前包应重试的最大次数。为了清楚明白地阐明本示例，我们将确定在使包失败前组件最多允许 次重试。在您的包中创建名为的一个变量。使这个变量的类型为 并且向其赋值 。在包的表达式中将使用该变量。2. 设置一个变量以便存储您的成功状态。在您的 包中创建一个新变量。将这个新变量命名为。3. 使用 循环在数据流未成功的情况下执行重试，直至达到最大重试次数。4. 将您的数据流任务放置于 循环内。5. 将 循环的属性设置为数据流应重试的最大次数，以便重试后如果成功将不会使您的包失败。您应该通过使用在步骤 中设置的 变量的表达式来执行此操作。6. 使用上一节中所示的执行 任务找到源上的最小键值以及目标上的最大键值。对于简单重试，这可以在 循环内实现。对于更高级的示例，这可以在控制流中 循环之前的其他位置出现。7. 将您的执行 任务放置于 循环中。8. 将成功约束从执行 任务连接到该数据流任务。9. 将成功优先约束从该数据流任务连接到一个脚本任务，该脚本任务将成功状态变量设置为以便脱离 循环。下面是该脚本任务的配置示例。10. 针对预期要长于您的最频繁出现的问题或预期最麻烦的问题的时间，将失败优先约束从该数据流任务连接到另一个脚本任务。对于此示例，我们将使用 秒钟以避免可能出现的限制情形。将成功变量的值设置为 。11. 对于该 循环中的每个任务，将属性设置为。在此配置中，只有在 循环使用了所有已配置重试尝试后失败时，它才会报告失败并且因此使包失败。12. 配置失败后的执行 任务以便再次检查源上的最小键值以及目标上的最大键值，从而可以在不重新执行任何工作的情况下恢复进展。按照本文前面的针对在不丢失管道进展的情况下重新开始的设计一节中的“针对重新开始进行设计”小节中所述，对此进行设置。每当数据流中出现错误时，如果尚未达到最大重试次数，则该过程将返回到目标处最大键值的点。该过