迁移至MySQL的数据流转流程优化

数据流转在很多公司都有实践和落地的场景，如果说关系型数据库/NoSQL是在分，则在数据仓库体系中就是在合，数据分分合合，各取所需。一般来说，数据消费主要有两种渠道，一种是通过报表等形式交付，数据精确度高，实时性要求相对不高，也就是我们常说的统计方向，另外一类是重在数据分析，通过分析过往历史的数据设计相应的模型，发挥数据更深层次的价值，这种一般都是数据工程类项目，基于大数据体系。如果两种体系并存彼此独立，那么就会是如下的数据通道.

其中在数据仓库中进行大量的计算任务，一般都是集群的形式呈现，资源消耗较高，而数据集市则是数据仓库中计算后的结果集存储，体量相对来说要小很多。

如果原有的一套机制需要保留，数据库迁移到了MySQL集群中，那么对于数据的切分粒度会更细，通常是分片的形式，比如数据被切分为了4份，那么在数据消费的流程中就需要导出4份csv文件，然后将csv文件加载到ETL服务器中，统计侧可以直接加载消费数据，而对于大数据侧，可以通过文件上传的方式上传到HDFS，然后执行加载任务。整个任务执行过程中，数据导出的csv文件是同一份，但是会涉及完全不同的两套流程，如下图所示：

这种使用方式很难看到优点，所以需要进一步改进，主要的表现是数据通道过于定制化，会导致同一份数据消费结果可能不同，因为涉及的流程较长，所以存在潜在风险的点也会多一些。对此，我做了反向思考，这种模式其实也反应出数据交付模式不够统一，不够清晰。对于数据消费方来说，通过数据库的访问模式远比使用csv文件要友好得多，而且对于数据校验的配置也更好在数据库中进行管理。所以接下来的改进是推出了一个新的角色：数据源集市，也就是无论上游是集群还是单实例，数据的出口就在数据源集市，对于数据消费方式相对透明的，一般来说对于T+1的需求是足够的，唯一的瓶颈点其实就在于这个csv文件聚合过程。

上面的这种方案优点比较明显，但是瓶颈也比较明显，即要实现近实时的需求显然是不合适的。比如对于大数据分析需求来说，很大程度上都是基于近实时的分析和处理才能更大的发挥价值，而T+1对于大数据分析来说太慢了，当然对于T+1的统计需求来说，如果所有的事情和问题都需要在第二天0点后才能开始，那么很多问题是后知后觉的，所以也可以考虑近实时的数据交付，这里有两条完全不同的通道，一个是提供近实时刷新的数据源集市(数据库），可以根据统计侧的需求自行进行增量的提取，而对于大数据侧则可以完全基于Kafka的方式进行数据消费，就不需要再读取数据库了。

其中的一个核心组件就是Maxwell,当然也可以通过Canal等方式实现,而近实时的数据传输也确实是一个趋势。