Sqoop 导出到 SQL Server 失败/挂起更多列数



我正在尝试将数据从HDFS导出到SQL Server。原始表有超过 500 列,每次我执行 Sqoop 导出作业时,它都会卡住,显示 mapReduce 以 100% 完成。我创建了两个虚拟表,如下所示,以找出确切问题仍然存在的位置。 表1 和表2 之间的唯一区别是后者有一个额外的列 [col14 varchar(5)]

首先,我为 Table1 运行导出作业,该表有 13 列 [数据类型 varchar (5)]。作业成功完成,并将所有 3 条记录导出到 SQL Server。

接下来,我执行了包含 14 列的 Table2 的导出作业。当我运行此作业时,我没有看到任何错误消息/异常,但是在地图以 100% 完成后它会永远挂起。SQL Server 活动监视器显示正在创建一个进程,但它没有从 Hadoop 接收任何数据/准备语句。

此问题是否仅存在于 SQL Server 中?导出到 SQL Server 的列数是否有任何限制?是否需要调整群集中的任何配置更改?请指教。

配置

Hadoop 版本 – Cloudera 2.6.0-CDH-5.5.2 |Sqoop 版本 – 1.4.6 |SQL Server 版本 – 2008 R2

6 节点群集 - 1 NN 和 5DN |映射任务 - 2 GB/1vCPU |减少任务 - 2GB/1vCPU

表1

CREATE TABLE [dbo].[tbldummy1]
(
[col1] [varchar] (5) NOT NULL,
[col2] [varchar](5) NULL,
[col3] [varchar](5) NULL,
[col4] [varchar](5) NULL,
[col5] [varchar](5) NULL,
[col6] [varchar](5) NULL,
[col7] [varchar](5) NULL,
[col8] [varchar](5) NULL,
[col9] [varchar](5) NULL,
[col10] [varchar](5) NULL,
[col11] [varchar](5) NULL,
[col12] [varchar](5) NULL,
[col13] [varchar](5) NULL,
CONSTRAINT [PK_dummy1] PRIMARY KEY ([col1] ASC))

表1的sqoop命令

  sqoop export 
--connect “jdbc:sqlserver://x.x.x.x:port;database=xxxxxxx” 
--username xxxxxx --password yyyyyy 
--table tbldummy1 
--export-dir /user/hue/Out1 
--input-fields-terminated-by '|' 
-m 1 
--verbose

表 1 的输入数据

aa|01|02|03|04|05|06|07|08|09|10|11|12
bb|01|02|03|04|05|06|07|08|09|10|11|12
cc|01|02|03|04|05|06|07|08|09|10|11|12

表2

CREATE TABLE [dbo].[tbldummy2](
    [col1] [varchar] (5) NOT NULL,
    [col2] [varchar](5) NULL,
    [col3] [varchar](5) NULL,
    [col4] [varchar](5) NULL,
    [col5] [varchar](5) NULL,
    [col6] [varchar](5) NULL,
    [col7] [varchar](5) NULL,
    [col8] [varchar](5) NULL,
    [col9] [varchar](5) NULL,
    [col10] [varchar](5) NULL,
    [col11] [varchar](5) NULL,
    [col12] [varchar](5) NULL,
    [col13] [varchar](5) NULL,
    [col14] [varchar](5) NULL,
 CONSTRAINT [PK_dummy2] PRIMARY KEY ([col1] ASC))

表 2 的 sqoop 命令

sqoop export 
--connect "jdbc:sqlserver://x.x.x.x:port;database=xxxxxxx" 
--username xxxxxx --password yyyyyy 
--table tbldummy2 
--export-dir /user/hue/Out2 
--input-fields-terminated-by '|' 
-m 1 
--verbose

表 2 的输入数据

aa|01|02|03|04|05|06|07|08|09|10|11|12|13
bb|01|02|03|04|05|06|07|08|09|10|11|12|13
cc|01|02|03|04|05|06|07|08|09|10|11|12|13

表 2 的控制台日志

16/03/16 23:35:01 INFO mapreduce.Job: Running job: job_1458150283440_0028
16/03/16 23:35:07 INFO mapreduce.Job: Job job_1458150283440_0028 running in uber mode : false
16/03/16 23:35:07 INFO mapreduce.Job:  map 0% reduce 0%
16/03/16 23:35:18 INFO mapreduce.Job:  map 100% reduce 0%

我们最终遇到了同样的问题 - sqoop 导出到 SQL Server 中的表达到 100%,然后它一直挂起,直到达到 10 分钟的超时期限,之后作业失败。在我们的调查中,我们发现造成这种情况的原因实际上是SQL Server端的复合主键冲突,我们在Hadoop集群端没有任何可见性。解决此 PK 冲突后,sqoop 导出成功完成。

我还想指出,访问权限不是问题,我们通过 sqoop eval 成功运行插入来测试这一点,它没有问题。

作为下一步,我建议您首先通过运行 sqoop eval 来测试您的写入访问权限。确认能够通过 sqoop eval 在目标表中插入记录后,请继续列出 SQL Server 中目标表强制实施的所有约束,然后在数据湖中添加适当的逻辑以防止此类记录导出到 SQL Server。如果可以确保导出到 SQL Server 的数据不违反 SQL Server 端的任何约束,则应解决 sqoop 导出问题。如果这不能解决您面临的问题,请告诉我们。

您的 xxxx 数据库中的 xxxx 用户的权限似乎有问题。在映射阶段后的导出操作中,作业尝试执行插入-更新查询,但如果它没有用户名的权限,它可能会卡住。尝试db_writer角色分配给用户。另一种选择,如果可能,请尝试在 sa 帐户下执行操作,以了解是否是这种情况。

您的错误日志没有显示太多堆栈,要了解错误,我建议检查故障节点的 yarn 日志。

在您检查SQL Server方面的问题之前,我已经在下面调整了您的sqoop作业,请尝试进行这些更改,我很确定它将解决您面临的问题。

#Changes Made - #Increase the number of mappers to 8 or 10 for faster process
#columns mapping - You have to give your column names in SQL server table in the sequence to match with your file 
sqoop export 
--connect "jdbc:sqlserver://x.x.x.x:port;database=xxxxxxx" 
--username xxxxxx --password yyyyyy 
--table tbldummy2 
--export-dir /user/hue/Out2 
--input-fields-terminated-by '|' 
-m <increase to higher number depending on your cluster> 
--columns "col1,col2,col2"
--verbose

相关内容

  • 没有找到相关文章

最新更新