45亿数据迁移记录

原创
01/13 13:59
阅读数 512

45亿数据迁移记录

  • 背景

    • 数据库数据量日益增加,逐渐开始显得很是臃肿,日常查询统计的时候,仅仅是count(1) 查询下总数,耗费的时间也在500s左右,而且之前的orcle数据库,前期建立的时候,也未考虑太多,未进行索引,分表,等优化。后面鉴于种种考虑,以及后期的规划,准备将数据迁移至clickhouse(oracle -> clickhouse)。
    • clickhouse 相关背景
      • ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。
      • 相关介绍
    • 迁移相关考虑
      • 数据库现有数据45亿
      • 每天还有新数据持续入库-数据量 3000万/天
  • 资源

    • 服务器资源 CPU 16C;内存 48G;硬盘 500G磁盘左右,总共3台
  • 准备

    • 开始查看相关的数据迁移工具
      • datax 阿里推出的一个,但是相对而言,社区不是很活跃。相关链接
      • waterdrop 社区活跃,作者很用心。再次感谢在使用过程中给与我的帮助 相关链接
  • 过程-时间-思考

    1. 选择方式,与迁移工具

    • 首先,选择截断数据日期,进行之前的数据迁移。
    • 最开始看的datax 的相关,这里说下datax的clickhouse官方还没提供指定的插件,所有无法直接到达clickhouse。
    • 尝试 oracle -> datax -> mysql -> clickhouse 使用 clickhouse 的insert into ,clickhouse 对mysql 有很好的支持。
      • 尝试失败,mysql 数据迁移过去以后,一旦到达亿级别,数据库统计无结果。考虑过,使用datax分任务,分表,但是数据已经45亿,分表量太小。花费时间过长。
    • 尝试 oracle -> datax -> hdfs -> waterdrop -> clickhouse 尝试使用 datax 迁移数据到hdfs,然后使用 waterdrop 在把数据从 hdfs 到 clickhouse 。
      • 这个是可行的,但是在这期间,我在github 上面发现了其他网友扩展的datax 的 clickhouse 的插件,毕竟这个方案还需要 hdfs 做一步的中转。
    • 尝试 oracle -> datax -> clickhouse
      • 在网上查看相关文档,发现有朋友在github 提供了 datax 的 clickhouse 的插件。参考地址
      • 尝试相关插件,发现可行。

    1. clickhouse 建表,查看相关优化

    • 了解 clickhouse 的相关表引擎,为迁移建表准备。之前的文档有相关说明。
      • 着重了解了我们需要使用的表引擎,最后选定引擎 MergeTree(合并树引擎) Distributed(分布式引擎)
      • MergeTree 后续需要持续落入数据。并且对数据按照时间进行合并,优化效率。参考链接
      • Distributed clickhouse 公司这边建立的是集群,而且分布式引擎,可以并行处理数据,最后在总表会合,效率高。参考链接

    1. 准备shell脚本,依次执行脚本,顺序执行

    • 这里需要说明,为什么要依次执行?
      • datax 那里可以进行份job,一起执行,但是我这里,没有选择并发处理多任务。前期测试的时候,我这边设置了datax 的一个优化参数线程数 channel 为15 ,同时执行多个任务。但是这样大数据量并发读写操作,给oracle 的服务器,以及迁移的服务器带来了几个问题。
        • 多个任务同时读取oracle ,导致oracle那边出现了阻塞现象,有的任务已经开始拉取,有的任务迟迟不见开始。
        • 过多的任务,启动过多的线程,导致linux迁移的服务器最后经常出现cpu 锁死,任务极度不稳定,进行奔溃,迁移失败。
    • datax 支持where 条件,准备sql 的where 条件,进行数据库的 用创建时间进行分割数据,使每个任务的job 拉取数据量保持平衡,过滤一部分无效数据。

    1. 建立临时表,每个任务的时间分区,对应一个datax 的配置。防止数据拉取过程中某个任务失败。

    • 我这边建立clickhouse 的临时job表,建立了14个, 每个集群所在的节点,是7个,每个datax 在两台服务器分别顺序执行7个任务。
    • 中间会有任务失败,所有最后拉取完毕以后,查看每个job 的日志,失败的,进行清表,二次拉取。
    • 全部成功以后,使用 clickhouse 的 insert into 插入之前的建立的正式表,进行数据合并,至此45亿数据拉取成功。
  • 总结

    • 迁移过程中,主要耗费时间在前期的工具,以及方案备选,因为之前没做过此类事情,所以查看每个工具,而后选择测试的方案也不相同。
  • linux 脚本

echo '开始释放缓存'

echo 3 > /proc/sys/vm/drop_caches

echo '缓存清理完毕,执行第4次任务'

python2 /home/datax/bin/datax.py --jvm="-Xms3G -Xmx3G"  /home/datax/job/job_clickhouse4.json >/home/datax/log/job_clickhouse4.log  2>&1

echo '第4次任务执行完毕'


echo '开始睡眠'

sleep 1h

echo '结束睡眠'



echo '开始释放缓存'

echo 3 > /proc/sys/vm/drop_caches

echo '缓存清理完毕,执行第5次任务'

python2 /home/datax/bin/datax.py --jvm="-Xms3G -Xmx3G"  /home/datax/job/job_clickhouse5.json >/home/datax/log/job_clickhouse5.log  2>&1

echo '第5次任务执行完毕'

job 与 临时表 后面添加后缀 _数字 以方便区分。与任务日志对应。 而这里的睡眠是因为,clickhosue 拉取数据以后,就会整理文件,整理文件会耗费内存以及性能,进行睡眠,先让他进行整理。

datax的多job

clickhouse 的分表

展开阅读全文
打赏
0
0 收藏
分享
加载中
这个格式好像没问题啊
01/21 10:13
回复
举报
更多评论
打赏
1 评论
0 收藏
0
分享
返回顶部
顶部