Видя странную проблему, когда (очень редко) sq oop (версия: 1.4.7.3.1.0.0-78), кажется, приводит к несколько большему количеству записей, чем считается в источнике. Мой sq oop код выглядит следующим образом ...
{
sqoop import \
-Dmapreduce.map.memory.mb=3144 -Dmapreduce.map.java.opts=-Xmx1048m \
-Dyarn.app.mapreduce.am.log.level=DEBUG \
-Dmapreduce.map.log.level=DEBUG \
-Dmapreduce.reduce.log.level=DEBUG \
-Dmapred.job.name="Ora import table $tablename" \
-Djava.security.egd=file:///dev/urandom \
-Djava.security.egd=file:///dev/urandom \
-Doraoop.timestamp.string=false \
-Dmapreduce.map.max.attempts=10 \
-Dmapreduce.task.timeout=1500000 \
-Dorg.apache.sqoop.splitter.allow_text_splitter=true \
--connect $DBCNXN --username $DBUSER --password $DBPASSWORD \
--as-parquetfile \
--target-dir $importdir \
-query "$sqoop_query" \
--split-by $splitby \
--where "1=1" \
--num-mappers 12 \
--class-name "QueryResult_$tablename" \
--delete-target-dir
} || { echo -e "\nFailed to sqoop data from source DB"; exit 255; }
Указанные таблицы перезаписываются, а не увеличиваются (хотя я не могу проверить фактические данные между источником и приемником sq oop, поскольку источник обновляется каждый день с большим количеством строк).
Кто-нибудь с большим опытом sq oop знает, что здесь может происходить? Любые дальнейшие советы по отладке для изучения этого?
* Обратите внимание, что для двух таблиц, с которыми это происходит, для одной таблицы A splitby является нечисловым типом (varchar), а другая таблица B имеет составную PK (хотя мой разделенный столбец здесь обозначен цифрой c). Обе эти проблемы могут усложнить операции sq oop при нормальных обстоятельствах, поэтому в этом случае отладку будет еще сложнее, поскольку они могут вызывать другие проблемы (хотя и не совсем уверен, что такое побочные эффекты может быть ).