了解幂等性如何保护您免受数据集成失败的最糟糕后果。
幂等性防止数据同步失败时创建重复数据。为了提高效率，数据仓库按批装载记录，而不是单个记录。这也意味着进度是按批记录的，而不是单个记录。当数据集成同步被中断时，通常不可能确定故障发生时正在处理的准确记录，这意味着为了恢复同步，数据管道必须从最近一批的开始处开始。这意味着已经处理过的数据必须再次处理。
假设您有以下四批数据要同步到数据仓库。第一个批处理已经完成，同步(绿色条)正在第二个批处理的中途。跟踪进度的光标(红色箭头)当前被设置为第一批的末尾。
所有来自第一批的记录(“foo，”“bar，”“baz，”“qux，”和“corge”)，以及一些来自第二批的记录(“grault，”“garply，”和“waldo”)，已经被加载:
然后，同步被中断:
当它再次恢复时，数据管道引用游标，识别出第一批已经完成，而第二批还没有完成。第二批必须重新启动。
当第二个批处理完成时，游标被更新到第二个批处理的末尾。
先前从第二批(在本例中是“grault”、“garply”和“waldo”)同步的记录被重新引入到目标(红色行)。没有幂等性，记录被复制:
相比之下，使用幂等性，每个唯一的记录都被正确地识别，没有重复。
失败可以是“硬的”，也可以是“软的”。上面的插图提到了硬失败，意思是程序由于异常而退出，迫使系统从游标指示的位置再次恢复。
“软”故障的危害性更大，因为数据同步不会失败，但已损坏的数据被加载到目标。软故障需要人工干预和彻底的调查，以识别来自过去的光标，以便回滚。如果没有幂等性，这可能意味着损坏记录的正确值和不正确值同时存在于目标中，更不用说在重同步范围内的任何正确记录的副本了。
故障可能发生在现代数据栈的以下三个阶段中的任何一个:
源:数据源异常不可用，导致同步中断。
管道:有时候管道本身会打嗝并停止工作。
目标:对数据仓库的查询失败会中断同步，升级和迁移也会如此。
如上所述，所有这些失败的共同主题是，已经加载的数据值被重新引入到目标，可能会创建重复或冲突的值。
源可能暂时或永久不可用。临时故障可能是由于网络或查询故障引起的。永久故障可能导致故障转移，这意味着资源意外地变得完全不可用，导致该资源切换到自身的备用备份副本。当管道切换到备份资源时，已经获取的一些记录可能会再次获取。
管道故障是最常见的故障类型。一般来说，管道故障是以下原因造成的:
基础设施中断(即服务器宕机)
证书错误或丢失
资源限制(即内存泄漏)
软件缺陷
任何操作过数据管道(尤其是传统的ETL流)的人都知道在实践中有多常见故障。即使是更简单、更耐用的ELT管道也会周期性地中断。
由于查询失败，同步有时会在目的地失败。查询可能因为资源限制而失败——节点可能太忙，或者可能计划停机。
此外，组织会定期从一个目的地升级或迁移到另一个目的地。这个过程通常涉及维护运行到旧目标的数据管道，以便在配置新目标时它仍可操作。这个新目标将使用来自旧目标的数据副本填充，但是为了确保不会丢失更新，您需要倒带游标，以便将一些相同的记录重新引入到目标。
上面描述的每个故障的共同主题是，恢复需要回滚到以前的某个游标，将一些记录重新引入到目标。如果没有幂等性，这种重新引入将导致重复记录，破坏数据存储库的完整性。人为干预通常是必要的，以修复这些数据完整性问题。
有了幂等性和唯一识别记录的能力，就不会出现重复或任何相关的下游问题。尽管源、管道和目的地故障是不可避免的，但幂等数据管道本质上是自校正的，在很大程度上消除了人类参与数据完整性取证的需要。