基于Kafka Connect框架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包含了每一列的基本数据类型（INT1六、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