急中生智~利用Spark core完成”ETL”!


背景介绍:
今天接到老板分配的一个小任务:开发一个程序,实现从数据库中抽取数据并生成报表(这是我们数据库审计平台准备上线的一个功能)。既然是要生成报表,那么首先得有数据,于是便想到从该业务开发云主机域名系统的测试环境抽取业务表的数据,然后装载至自己云主机上的Mysql中。
本来以为只要”select …into outfile”和”load data infile…”两个命令就可以搞定的,可是还是出了意外。测试环境导出的
txt文件在云主机load时,报了”Row 1 doesn’t contain data for all columns”这样的warning,表中的数据自然也是凌乱且不完整的。
仔细分析,感觉可能是两个方面出了问题:
1.由于测试环境的网段是隔离的,所以为了拿到”select …into outfile”时生成的数据,我是打开CRT的日志,然后执行
“cat xxx.txt”,变相地将数据获取到了本地,然后上传至云主机的;
2.测试环境的Mysql和云主机上Mysql的小版本不一致。
这两个问题看似都没法解决,现在只有文本文件,怎么办?使用Spark不就得了!
之前也写过一篇使用Spark分析Mysql慢日志的博文,自己对Spark core的各种算子比较熟悉,所以决定试一试。实战演练:
表结构如下:文本结构如下:观察文本结构可知,每个字段间都有数个空格,而且两两字段间的空格数并不一致,所以得先使用Spark core将文本中字段提取出来,以便后续插入。
闲话少说,直接上程序!(以下程序均使用scala在eclipse ide for scala中编写和执行)在插入的过程中,第一条记录总是会报错(后续语句插入正常),将eclipse中打印出的报错的insert语句手工粘贴至mysql执行时,仍报相同错误:

从报错看是遇到了bug,并且1147这个值有问题,将相邻语句放入Notepad对比:

从图中可看出,1147的千位上的1确实发生了异常改变,而第二条语句中的1148是正常的,猜测可能是某个未知bug导致了第一条记录发生了异常改变。这个猜测在后续得到了证实:当把1147所在行从文本中删除后(此时1148所在行为第一条记录),1148所在行也报出同样的错误,而后续语句均可正常插入。
由于数据是作分析用的,所以丢失一条无伤大雅,而且这个bug实在诡异,这里就不再深究了。细心的童鞋在看了代码后应该会问:数据插入的效率如何?实不相瞒,效率很差!5000条的数据足足用了近半个小时,即使是在这样的OLAP场景下,这样的效率也是不可容忍的!
仔细研究代码可发现,在对RDD调用foreach方法进行插入的时候,每一条记录都要创建一个连接,并且每一次insert都会在Mysql中触发一次commit操作(autocommit参数默认是打开的),这些都是很消耗资源的操作,插入效率自然很差。
发现这些问题后,针对代码进行了修改:修改后的代码规避了上述缺陷,在同样插入5000条数据的情况下,只用了221s!效率大大提升!
到Mysql验证数据:至此,问题圆满解决!整个过程和数据仓库领域的ETL很接近,抽取-转换-装载,三个环节都有涉及,只是没有使用
kettle之类的工具罢了。总结:
大数据时代,DBA应该积极做出改变,掌握一定开发技能,以便更好地适应时代变化,切不可固守自己的一亩三分地!最后,给我们上海分组自研的数据库审计平台打个广告 ^.^
数据库审计平台是我们分组历时两年打造的产品,可用于Mysql、Oracle、Postgres等多种数据库,具备以下核心工能:
1.审计违规sql,前端一键生成报告
2.对相同功能点的sql可实现自动归类,方便后续统一整改
3.内嵌Percona toolkit,前端一键调用
4.一键抓取低效sql,并自动给出优化建议
还有很多很酷的功能就不一一介绍了,总之,谁用谁说好!感兴趣的DBA童鞋可以留言,可免费试用哦!

相关推荐: MySQL几个容易混淆的概念

1、MySQL数据库服务:是MySQL软件、MySQL实例和MySQL数据库 这几个部分的总称,有时简称 MySQL服务2、MySQL实例:指mysqld进程3、MySQL数据库:是MySQL data目录下的一系列物理文件的集合,至少有4个(test、mys…

免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 06/04 18:56
下一篇 06/04 18:56

相关推荐