基于Kafka Connect框架DataPipeline可以更好地解决哪些企业数据集成难题？
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
最新文章
- CSS3 Animation 帧动画 steps()
- SQL SERVER 数据库操作脚本
- Samba Server 配置
- C++成员变量的初始化顺序问题
- JavaScript排序算法——希尔排序
- 加载数据库驱动程序的方法和JDBC的流程
- linux查看内核版本、系统版本、系统位数（32or64）
- 使用POI读取excel文件内容
- Redis VS Memcached
- [Java,MVC] SpringMVC+Spring+hibernate 框架
- Python学习_从文件读取数据和保存数据
- objc_msgSend消息传递学习笔记 – 对象方法消息传递流程
- 菜鸟Android之路(上)
- vim note(6)--vim的一个较全的介绍（转）
- sql查询过程中 update，insert，delete可视化收影响行数
- js中的true,false盲点
- php socket多进程简单服务器（一）
- fedora添加ntfs文件系统支持
- Yale数据库上的人脸识别
- mysql监控利器mysqlmtop部署安装