一致性语义
一致性语义
批量同步需要以一种事务性的方式完成同步，无论是同步一整块的历史数据，还是同步某一天的增量，该部分数据到目的地，必须是以事务性的方式出现的。而不是在同步一半时，数据就已经在目的地出现了，这可能会影响下游的一些计算逻辑。并且作为一个数据融合产品，当用户在使用 DataPipeline 时，通常需要将存量数据同步完，后面紧接着去接增量。然后存量与增量之间需要进行一个无缝切换，中间的数据不要丢、也不要多。
DataPipeline 作为一个产品，在客户的环境中，我们无法对客户数据本身的特性提出强制要求。我们不能要求客户数据一定要有主键或者有唯一性的索引。所以在不同场景下，对于一致性语义保证，用户的要求也不一样的：比如在有主键的场景下，一般我们做到至少有一次就够了，因为在下游如果对方也是一个类似于关系型数据库这样的目的地，其本身就有去重能力，不需要在过程中间做一个强一致的保证。但是，如果其本身没有主键，或者其下游是一个文件系统，如果不在过程中间做额外的一致性保证，就有可能在目的地产生多余的数据，这部分数据对于下游可能会造成非常严重的影响。
数据一致性的链路视角
-
在源端做一个一致性抽取，即当数据从通过数据连接器写入到 MQ 时，和与其对应的 offset 必须是以事务方式进入 MQ 的。
-
一致性处理，譬如 Flink 提供了一个端到端一致性处理的能力，它是内部通过 checkpoint 机制，并结合 Sink 端的二阶段提交协议，实现从数据读取处理到写入的一个端到端事务一致性。其它框架，例如 Spark Streaming 和 Kafka Streams 也有各自的机制来实现一致性处理。
-
一致性写入，在 MQ 模式下，一致性写入，即 consumer offset 跟实际的数据写入目的时，必须是同时持久化的，要么全都成功，要么全部失败。
-
一致性衔接，在 DataPipeline 的产品应用中，历史数据与实时数据的传输有时需要在一个任务中共同完成。所以产品本身需要有这种一致性衔接的能力，即历史数据和流式数据，必须能够在一个任务中，由程序自动完成它们之间的切换。