Maxwell和Canal的选型和规划
The following article is from 杨建荣的学习笔记 Author 杨建荣
相关推荐：数据同步之道（Sqoop、dataX、Kettle、Canal、StreamSets）
正文
一般说要比较，基本都会拿出这幅图来（数据带有主观特点，仅供参考）
我们在这个基础上做些补充。
01
首先对于这个工具的定位，我们如果是主要基于数据流转来作为虚拟从库这样一个组件，其实选择Maxwell和Canal的差别会比较明显。
Maxwell的定位基本上一句话就能说清楚，MySQL+Kafka，如果是基于MySQL和Kafka组合的技术栈，Maxwell无疑是一种可直接上手的工具，基本不需要复杂的配置即可跑通一个demo,快速开始测试,换句话说Maxwell部署很简单，上手简单，跑通一个完整的测试全然没有问题，对于缺乏基础建设，短时间内需要快速迭代的项目和公司比较合适。
Canal的部署相对来说要复杂许多，对于开发侧的要求较高，有两个值得一提的参考点，一个是bootstrap,对于数据初始化来说，这是一个缺失，和Canal这个工具本身的定位有关，第二个是数据落地，得自己写客户端，当然除此之外，在服务高可用，文档，数据分区，自带图形管理工具方面，Canal确实有自身的优势，而且据说产品内部版本已经对接了商业数据库侧。对于大中型的项目，具有团队开发优势的项目和公司来说，可以考虑，或者可以作为自造轮子的参考。
02
这几天看了下两个开源项目相关的代码，有了更进一层的认识。GitHub的流行度是一个风向标，
从这个流行度来看，两个项目的量级确实差别挺大，一方面阿里有自身的开源号召力，Maxwell在这个数据面前略显逊色。
不过从代码层面来看，逐步理解了这个差异，首先关于MySQL协议的Java实现，这个整个工具的核心部分，在Canal中都是自下而上都实现了，而Maxwell中翻了一圈代码，竟然没有，发现是在另外一个开源项目mysql-binlog-connector-java中，这个项目的协议实现很精巧，对于理解协议层的一些细节很有帮助。
当然从更细一层来说，Canal是模拟MySQL Slave，主动从Master端拉取日志数据。而mysql-binlog-connector是一个解析库，它有两种模式：BinaryLogFileReader日志读取模式，和BinaryLogClient客户端访问模式，在实现方式上更加灵活，而且BinaryLogFileReader这个部分的实现算是一个杀手级特性，如果规划了binlog集市，在这个基础之上简直如虎添翼。
Maxwell还有什么细节，它基于C3P0连接池，所以在Slave端会看到有几个复制相关的会话，在测试框架部分采用了TestNG的开源项目，在数据落地部分，支持的目标端非常丰富，Redis，Kafka，Kinesis，在数据接入层面的功能非常完善，目前看没有后端的功能支持。
03
Canal的实现是前后端组合，还包含一个子项目是平台化管理入口，它对接的后端更多是基于自身的技术栈体系，把整个链路能够打通。
对于我们当前的状态来说，我觉得接入Maxwell能够跑通整个数据链路，而且至少在Virtual Slave这一个技术栈上面来说，它是相对技术独立，可以做一些相关的定制工作的，从绝大多数公司的情况来说也是如此，毕竟数据库到大数据的数据流建设相对是隔离的，彼此上下游的建设能够互相映衬。如果目标足够统一，集中优势，选择Canal才是一种长期的策略。
如果您喜欢本文，欢迎点击右上角，把文章分享到朋友圈~~
往期推荐
欢迎加入中台|数仓技术交流群。戳：数据交流群！
进群方式：请加微信（微信号：iom1128），回复：数据，通过审核会自动拉你进群。
(备注：行业-职位-城市)
01. 后台回复「经典」,即可领取大数据数仓经典书籍。
02. 后台回复「中台」,即可领取大厂中台架构高清ppt。
03. 后台回复「加群」,或添加小助微信ID：iom1128 拉您入群（大数据|数仓|分析|Flink|资源）或领取资料。
Q: 关于数据仓库，你还想了解什么？
欢迎大家扫描下方二维码订阅「数据仓库与Python大数据」内容并推荐给更多数据方向的朋友，希望有更多机会和大家交流。
更多精彩，请戳"阅读原文"到"数仓之路"查看
！关注不迷路~ 各种福利、资源定期分享！