Sq oop иногда приносит больше записей, чем то, что есть в источнике? - PullRequest
0 голосов
/ 28 февраля 2020

Видя странную проблему, когда (очень редко) 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 при нормальных обстоятельствах, поэтому в этом случае отладку будет еще сложнее, поскольку они могут вызывать другие проблемы (хотя и не совсем уверен, что такое побочные эффекты может быть ).

...