DataPipeline已经完成了很多优化和提升工作，可以很好地解决当前企业数据集成面临的很多核心难题。

1. 任务的独立性与全局性。

从Kafka设计之初，就遵从从源端到目的的解耦性。下游可以有很多个Consumer，如果不是具有这种解耦性，消费端很难扩展。企业做数据集成任务的时候，需要源端到目的端的协同性，因为企业最终希望把握的是从源端到目的端的数据同步拥有一个可控的周期，并能够持续保持增量同步。在这个过程中，源端和目的端相互独立的话，会带来一个问题，源端和目的端速度不匹配，一快一慢，造成数据堆积现象严重。所以，企业用户在建立一个数据任务之后，我们希望对任务进行缓冲的控制，避免数据丢失。

2. 任务并行化的方式。

如果企业客户有1000张数据表需要建立数据集成的任务，就要考虑用什么方式进行任务切分最佳。其中一种方式是把1000张表切分成若干个任务。这种情况下，Source Task的负载很难做到均衡，Sink Task可以消费多个Topics，依然存在负载不均的问题，每个任务负载多少张表其实是很难均衡的。每增加一个任务都会触发Rebalance机制。可以想象，每一张表都通过Source Connector和Sink Connector初始化一个源端和目的端任务，会大大增加Rebalance的开销。

3. 异构数据的映射。

在给企业客户做数据集成的时候，50%几率都会遇到一些脏活累活——异构数据源的映射（Mapping）。这个映射对很多互联网公司来说不是那么严重什么事儿，因为数据库设计的都比较符合规范，对字段的命名方式等都会比较“优雅”（统一）。但是在传统企业里，由于很多业务系统都会外包，还有一些意识的原因，导致数据库设计的没有那么规范和统一。用Kafka Connect做数据集成的时候，需要尽可能做到异构数据精准的还原，尤其金融行业客户对此要求比较高。另外，当确实遇到数据之间不匹配的情况时，可以在业务数据之间进行比较合理的映射。

另外，源端的Source Record包含了每一列的基本数据类型（INT16、STRING等）以及可选的meta信息（例如“name”）。目的端处理Sink Record的时候，需要依据基本数据类型以及meta信息决定映射关系。

4. Schema变化的处理策略。

给企业做数据集成的时候，需要根据数据源Schema的变化给出对应的处理策略。基于Kafka Connect框架，我们提供了以下几种处理策略：

（1）Backward Compatibility：可使用最新的Schema一致访问所有数据，e.g. 删除列、添加具有默认值的列。

（2）Forward Compatibility：可使用最旧的Schema一致访问所有数据，e.g. 删除具有默认值的列。

（3）Full Compatibility：可任意使用新旧Schema访问所有数据。

Kafka Connect推荐使用Backward Compatibility，这也是Schema Registry的默认值。另外，企业用户还会提出源端删除列，目的端需要忽略，源端添加具有默认值列，目的端需要跟随等需求，都以Task为单位进行配置和实现。

更多关于实时数据集成的问题，欢迎直接访问官方网址申请试用：www.datapipeline.com