Экспорт Sqoop в SQL Server терпит неудачу/зависает для большего количества столбцов

Question

Я пытаюсь экспортировать данные из HDFS в SQL Server. Исходная таблица имеет более 500 столбцов, и каждый раз, когда я выполняю работу по экспорту Sqoop, она застревает, показывая, что mapreduce завершен на 100%. Я создал две фиктивные таблицы, как показано ниже, чтобы узнать, где точно сохраняется проблема. Единственное различие между таблицей 1 и таблицей 2 состоит в том, что у более поздней версии есть один дополнительный столбец [col14 varchar (5)]

Во-первых, я выполнил экспортное задание для Table1, которое имеет 13 столбцов [тип данных varchar (5)]. Задание успешно завершено и экспортировано все 3 записи на SQL Server.

Затем я выполнил экспортное задание для Table2 с 14 столбцами. Когда я запускал это задание, я не видел сообщений об ошибках/исключениях, но он зависает навсегда после завершения карты на 100%. Монитор активности SQL Server показывает, что процесс создается, но он не получает никаких данных/подготовленных заявлений от Hadoop.

Эта проблема существует только с SQL Server? Есть ли ограничение на количество столбцов, экспортированных на SQL Server? Нужно ли мне настраивать изменения конфигурации в моем кластере? Пожалуйста, порекомендуйте.

Конфигурация

Hadoop Версия - Cloudera 2.6.0-CDH-5.5.2 | Sqoop Version - 1.4.6 | Версия SQL Server - 2008 R2

6 Узел Кластер - 1 NN & 5DN | Задача карты - 2 ГБ/1vCPU | Уменьшить Задача - 2 Гб/1vCPU

Table1

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)) 

Sqoop Команда для Table1

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)) 

Sqoop Команда для таблицы 2

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% 

Answer 1

кажется, что у вас есть проблемы с привилегиями вашего пользователя хххххх в базе данных ххххххх. При операции экспорта после фазы карты задание пытается выполнить запрос на вставку-обновление, но если у него нет необходимых разрешений для имени пользователя, он может застрять. Попробуйте назначить роль db_writer вашему пользователю.Другой вариант, если это возможно, попробуйте выполнить операцию под учетной записью sa, чтобы понять, если это так.

Answer 2

Мы столкнулись с той же проблемой на нашем конце - экспорт 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 должна быть разрешена. Сообщите нам, если это не решит проблему, с которой вы столкнулись.

Answer 3

В вашем журнале ошибок не отображается много стека, чтобы понять ошибку, которую я предлагаю проверять журналы нитей для неудавшихся узлов.

Перед тем, как проверить проблемы со стороны 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