慌了! Apache Sqoop正式退役?

意外发现

前两天打算迁移一份数据,自然而想到了Apache Sqoop,遂打开Apache官网寻找下载链接,但是竟然没有找到他的踪影。

慌了! Apache Sqoop正式退役?_第1张图片

这不科学啊,前几个月还看到过来着,有点不死心,直接尝试登陆直接https://sqoop.apache.org/

慌了! Apache Sqoop正式退役?_第2张图片

Aapche Sqoop官网

Project Sqoop has retired. For details please refer to its Attic page.

Apache基金会里竟然还有项目退役一说,仔细看了下,原来Apache Sqoop在2021年6月就已经进入Attic了,就是最近的事情。不过,「Attic」是啥啊?并没有听说过;进入到Attic的项目会咋样?,我们继续探索下。

慌了! Apache Sqoop正式退役?_第3张图片

Apache Attic介绍

Apache Attic原来就相当于Apache的小黑屋,如果Apache托管的项目长时间不活跃(超过2年没有release新版本,没有committer、contributer并且没有未来roadmap),就会选择将项目移动到Attic中,这也就相当于Apache的项目管理了,掌管整个项目的生命周期。

Sqoop移动到Attic的项目对咱们有啥影响呢?

目前将Sqoop做数据迁移工具公司不在少数,当Sqoop移动到Attic后,单单使用来说是完全不受影响的;Apache Attic依旧会提供代码库的下载;但是不会再修复任何的bug,release新版本了,并且也不会再重启社区。

看到这里其实就没有这么慌了,我们还能继续用,不过如果遇到问题,我们只能自己建个分支去fix了,从侧面来说,也能说明Sqoop在某个角度是成功的,毕竟曾经成为Apache顶级项目,如果真的是长时间没有release,有可能是他确实已经够成熟了。

准备关闭Attic页面的时候,顺便扫了一眼在Attic中的项目,基本都不认识,但也看到几个熟悉的身影,如Chukwa,Sentry,Eagle。相信也有不少公司在使用,比如我们公司还在使用Sentry。换个角度,现在技术快速更迭太迅速了,随着时间流逝,没准过些年Hadoop、Spark也有可能没落呢。以后的事情又谁知道呢?没辙,继续学吧,今天我们先来聊聊Sqoop。


Sqoop定位和现状

简单来说Sqoop的定位就是Hadoop生态存储和结构化存储之间的数据迁移。我们比较常见的场景就是HDFS/HBase/Hive和MySql/Oracle之间的数据互导。Sqoop作为数据传输的桥梁,通过定义MapReduce的InPutFormat和OutPutFormat来对接源存储和目的存储。

注意在Sqoop中上只会涉及MapReduce中的Map阶段,而不会有Reduce阶段

慌了! Apache Sqoop正式退役?_第4张图片

Sqoop架构简图

目前Sqoop总体有两大版本分为Sqoop1和Sqoop2,Sqoop1的最新release是1.4.7;Sqoop2的最新release是1.99.7;这里如果大家使用的话推荐使用Sqoop1,而Sqoop2虽然增加了CLI和Rest api,但实际上是一个半成品,跟Sqoop1也完全不兼容,并且无论是CDH还是之前Apache都是不建议生产使用的,自己随便玩玩还可以。本篇主要介绍的版本还是基于Sqoop1.


Sqoop迁移原理

核心逻辑

整个Sqoop的迁移过程,都会对应着一个MapReduce作业,实际上只有Map阶段,而迁移大致分为5个部分,如下所示。

慌了! Apache Sqoop正式退役?_第5张图片

Sqoop逻辑简图

「Initializer」:整个Sqoop迁移的初始化阶段,完成迁移前的准备工作,如连接数据源,创建临时表,添加依赖的jar包等。

「Partitioner」:源数据分片,根据作业并发数来决定源数据要切分多少片。

「Extractor」:开启extractor线程,内存中构造数据写入队列之中;

「Loader」:开启loader线程,从队列中读取数据并写入对应后端;

「Destroyer」:整个迁移的收尾工作,断开sqoop与数据源的连接,完成资源回收;


流程解析

当迁移任务启动后,首先会进入初始化部分,使用JDBC检查导入的数据表,检索出表中的所有列以及列的数据类型,并将这些数据类型映射为Java数据类型,在转换后的MapReduce应用中使用这些对应的Java类型来保存字段的值,在每次Sqoop的任务执行时,代码生成器使用这些信息来创建对应表的类,用于保存从表中抽取的记录,即xxxx.java文件。紧接着Partitioner会根据--split-by或者-m指定整个任务的分片数量,如不指定默认是4个分片(每一个partition对应着一个Mapper),然后编译成一个本地Jar包用于提交MapReduce作业。当任务提交到集群后,每个Mapper会分别启动一个Extractor线程和Loader线程,整个MapReduce的InputFormat实际上是通过JDBC读取原端数据写入到Context中,而Loader线程将从Context中读出写入对应的数据作为OutPutFormat迁移的目的端。当任务执行完成后,yarn资源释放,随之Destroyer回收所有与数据源的连接。这里主要讲述的是Import的过程,而export流程与import十分相似,是把数据解析为一条条insert 语句,在此不过多解析。


Sqoop迁移实战

恰逢本人正在做Doris到Hive的迁移测试(Doris是一个基本兼容MySQL协议的OLAP引擎),实战围绕Doris的进行展开

迁移前准备

  • JDK/ZooKeeper/HDFS/Yarn/Hive的部署不是本篇重点,网上文档很多,可以自行参考部署。

  • 本片讲述的是Sqoop1,附下载地址http://archive.apache.org/dist/sqoop/。注意Sqoop部署的的时候需要导入mysql-connector-java.jar,其他正常修改sqoop-env.sh即可,总体Sqoop的部署比较简单。

  • 我们先来看看Doris源端数据表格式。该表有3497079条数据

    慌了! Apache Sqoop正式退役?_第6张图片

开始迁移

  • 启动Sqoop任务开始迁移,会提交MapReduce作业到Yarn上,我们最终的目的是将数据落地到HDFS上。

sqoop  import  \
--connect jdbc:mysql://Host:IP/ods_canoe  # jdbc连接地址
--username user  # 用户
--password password  # 密码
--delete-target-dir  # 删除对应HDFS目录下的数据
--target-dir /Canoe  # 对应HDFS的目录位置
--table dw_canoe_cmdb_host_cost  # 源端的表名
--split-by buy_age #  根据buy_age字段进行切分,注意是Int类型
--compress  # 启动压缩
--compression-codec org.apache.hadoop.io.compress.SnappyCodec  # 使用Snappy压缩
-m 10  # 10个分片即10个Map
  • 当然我们可以使用Sqoop将Doirs中的数据直接导入到hive中,但由于Doris数据格式DATETIME,在Hive中是不兼容的,因此本次没有使用这种方法。如果数据类型匹配,可以使用如下参数直接导入hive。

--hive-import   # 数据导入到hive中
--hive-table testSqoop   # hive中的表名
--hive-database default  # hive中的库名
  • MapReduce任务执行完成后,我们检查下HDFS是否有数据生成。

hadoop fs -ls /Canoe
Found 11 items
-rw-r--r--   3 work supergroup          0 2021-06-16 19:58 /Canoe/_SUCCESS
-rw-r--r--   3 work supergroup   11978345 2021-06-16 19:58 /Canoe/part-m-00000.snappy
-rw-r--r--   3 work supergroup   11694631 2021-06-16 19:58 /Canoe/part-m-00001.snappy
-rw-r--r--   3 work supergroup    6726724 2021-06-16 19:57 /Canoe/part-m-00002.snappy
-rw-r--r--   3 work supergroup   14511453 2021-06-16 19:58 /Canoe/part-m-00003.snappy
-rw-r--r--   3 work supergroup   10708857 2021-06-16 19:58 /Canoe/part-m-00004.snappy
-rw-r--r--   3 work supergroup    4459765 2021-06-16 19:57 /Canoe/part-m-00005.snappy
-rw-r--r--   3 work supergroup    1289616 2021-06-16 19:57 /Canoe/part-m-00006.snappy
-rw-r--r--   3 work supergroup      94095 2021-06-16 19:57 /Canoe/part-m-00007.snappy
-rw-r--r--   3 work supergroup        999 2021-06-16 19:57 /Canoe/part-m-00008.snappy
-rw-r--r--   3 work supergroup      42111 2021-06-16 19:57 /Canoe/part-m-00009.snappy

HDFS结果验证

  • 由于我设置的使用Snappy格式进行压缩,我们来检查下实际的行数是否与Doris中相同。

hadoop fs -text  /Canoe/*|wc -l
21/05/16 19:58:54 INFO compress.CodecPool: Got brand-new decompressor [.snappy]
3497079

数据导入Hive

  • 验证了HDFS数据后,我们来创建Hive表,注意这里有两种选择,

  1. 创建Hive普通表,然后将数据Load到表中

  2. 创建Hive外部表,制定到之前导出的/Canoe路径下

「hive普通表方式」

hive> CREATE   TABLE   `test_sqoop` (
    >   `date_time` date ,
    >   `ip` varchar(35)  ,
    >   `host_name` varchar (64) ,
    >   `category` varchar (64) ,
    >   `buy_age` int  COMMENT ,
    >   `suit_type` varchar(64)  ,
    >   `instance_name` varchar(200) ,
    >   `site` varchar(200) ,
    >   `charge_type_name` varchar(64) ,
    >   `price` double  ,
    >   `price_avg` double ,
    >   `default_discount` ,
    >   `time_stamp` date ) # 注意hive中只有date类型,没有datetime类型
    > ROW FORMAT DELIMITED FIELDS TERMINATED BY ","

hive> load data inpath '/Canoe' overwrite into table test_sqoop;

「2.hive外部表方式」

hive> CREATE  external TABLE   `test_sqoop` (
    >   `date_time` date ,
    >   `ip` varchar(35)  ,
    >   `host_name` varchar (64) ,
    >   `category` varchar (64) ,
    >   `buy_age` int  COMMENT ,
    >   `suit_type` varchar(64)  ,
    >   `instance_name` varchar(200) ,
    >   `site` varchar(200) ,
    >   `charge_type_name` varchar(64) ,
    >   `price` double  ,
    >   `price_avg` double ,
    >   `default_discount` ,
    >   `time_stamp` date ) # 注意hive中只有date类型,没有datetime类型
    > ROW FORMAT DELIMITED FIELDS TERMINATED BY ","
    > location '/Canoe';

Hive结果验证

hive> select count(*) from test_sqoop;
Query ID = work_20210816200848_acbb8c1a-b114-4872-9e76-45f5420d02ba
Total jobs = 1
Launching Job 1 out of 1
Starting Job = job_1595742917056_0028, Tracking URL = http://testjie01:23188/proxy/application_1595742917056_0028/
Hadoop job information for Stage-1: number of mappers: 10; number of reducers: 1
2021-06-16 20:08:56,677 Stage-1 map = 0%,  reduce = 0%
2021-06-16 20:09:02,938 Stage-1 map = 50%,  reduce = 0%, Cumulative CPU 22.88 sec
2021-06-16 20:09:03,975 Stage-1 map = 90%,  reduce = 0%, Cumulative CPU 37.03 sec
2021-06-16 20:09:05,010 Stage-1 map = 100%,  reduce = 0%, Cumulative CPU 39.51 sec
2021-06-16 20:09:08,131 Stage-1 map = 100%,  reduce = 100%, Cumulative CPU 42.16 sec
MapReduce Total cumulative CPU time: 42 seconds 160 msec
Ended Job = job_1595742917056_0028
MapReduce Jobs Launched:
Stage-Stage-1: Map: 10  Reduce: 1   Cumulative CPU: 42.16 sec   HDFS Read: 61581414 HDFS Write: 8 SUCCESS
Total MapReduce CPU Time Spent: 42 seconds 160 msec
OK
349707

其他有意思的功能

「增量同步」可以通过sqoop job创建、执行一个sqoop任务:根据增量字段,记录上一次的最大值,每次同步大于该值的数据增量同步数据至hive,创建任务后每次执行会自动更新--last-value的值。

--incremental append  # 增量同步
--check-column abc   # 检查的的字段
--last-value 'xxxx-xx-xx xx:xx:xx'

「自定义导入内容」使用 --query参数,用户可以根据需求,自定义所需的内容。

--query 'SELECT a.*, b.* FROM a JOIN b on (a.id == b.id) WHERE $CONDITIONS' \

「迁移加速」如果迁移MySQL的数据,可以添加--direct参数,使用MySQL的mysqldump去优化JDBC连接数据库部分。

「未提交数据查询」Sqoop 提供读取 read-uncommitted 事务的能力,只需要带上参数 --relaxed-isolation 即可,功能挺有意思,但这个我还没测试过,如果有试过的同学,可以文末留言。


Sqoop的遗憾

总体来说,整个迁移实战的结果是符合预期,Doirs迁移Hive完成。虽然Sqoop功能还强大的,但也有一些小遗憾,如果某个任务失败重试的话,会存在数据重复的问题,这时如果要保证一致性语义,需要通过额外去重操作完成;此外Sqoop迁移过程中,数据实时写入兼容性还不太好。虽然Sqoop2看着规划是挺香的,很遗憾不了了之了,由衷希望Sqoop的社区可以再续往日辉煌。

Bash wishes!!!


「往期原创推荐」

  • 啥?分布式啥?啥事务?

  • 一文入魂!聊透分布式系统一致性!

  • 拜托!这才是分布式系统CAP的正确打开方式!

  • 震惊!全网唯一 直击范围分片本质[适用HBase、Tidb等]

  • 大数据基础-求锤得锤,你要的一致性hash来了(下)[附代码]

  • 大数据基础-求锤得锤,你要的一致性hash来了(上)[附代码]

「往期最佳实践」

  • 小米HDFS-Tering冷热数据分层存储

  • 小米HBase HBCK2.0实战

  • 小米HDFS 短路读优化

  • 快手EB级HDFS挑战与实践

  • 快手Yarn资源调度优化实践

你可能感兴趣的:(数据迁移,apache,数据仓库,hadoop,分布式存储,分布式计算)