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

这是学习笔记的第  2301 篇文章

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

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

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

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

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

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

各大平台都可以找到我

  • 微信公众号:杨建荣的学习笔记

  • Github:@jeanron100

  • CSDN:@jeanron100

  • 知乎:@jeanron100

  • 头条号:@ 杨建荣的学习笔记

  • 网易号:@杨建荣的数据库笔记

  • 大鱼号:@杨建荣的数据库笔记

  • 腾讯云+社区:@杨建荣的学习笔记

近期热文:

使用图表分析2020北京积分落户的数据

MySQL 8.0给开发方向带来的一些困扰

关于故障复盘的一些总结

迁移到MySQL的业务架构演进实战

MySQL业务双活的初步设计方案

如何优化MySQL千万级大表,我写了6000字的解读

一道经典的MySQL面试题,答案出现三次反转

小白学MySQL要多久?我整理了10多个问题的答案

转载热文:

MGR用哪个版本?5.7 vs 8.0

SQLcl这个可爱的小工具,来了解一下呀~

CPU占用又爆了?MySQL到底在干什么

这个MySQL优化原理剖析,比照X光还清楚

自己动手写SQL执行引擎

最受欢迎的微服务框架概览

程序员,保住你的钱袋子!

QQ群号: 763628645

QQ群二维码如下, 添加请注明:姓名+地区+职位,否则不予通过

在看 ,让更多人看到

杨建荣的学习笔记
我还没有学会写个人说明!
上一篇

PgSQl临时表创建及应用实例解析

你也可能喜欢

评论已经被关闭。

插入图片