Как справиться с потенциальной потерей данных при сравнении типов данных в разных группах

Предыстория. Наша группа проходит обновление Cloudera до 6.1.1, и мне было поручено определить, как справиться с потерей неявного преобразования типов данных между типами данных. См. Ссылку ниже для получения информации о соответствующих примечаниях к выпуску.

https://docs.cloudera.com/documentation/enterprise/6/release-notes/topics/rg_cdh_611_incompatible_changes.html#hive_union_all_returns_incorrect_data

Эта проблема не только влияет на запросы UNION ALL, но также существует функция, которая выполняет сравнение столбцов с разными типами данных (например, от STRING до BIGINT).

Группа решила, что мы не хотим изменять метаданные базовой таблицы. Таким образом, решение состоит в том, чтобы учесть потенциальную потерю данных с помощью функции CAST () для преобразования данных. В случае UNION ALL мы приводим метаданные к целевой таблице. Но, выполняя сравнения, я пытаюсь определить самый простой и легкий способ выполнять сравнения без получения ошибочных результатов.

Вопрос:

Могу ли я просто преобразовать все в STRING или VARCHAR () при выполнении сравнения? Есть ли потенциальные проблемы, которые могут привести к неверным результатам?

Обновление: если есть проблемы с этим подходом, есть ли правильное решение для их решения?

Примечание: это моя первая работа с Hadoop / HIVE, и я узнал, что все, что я знаю о РСУБД, не всегда применимо.


person J Weezy    schedule 03.10.2019    source источник


Ответы (1)


Не исключено, что у вас возникнут проблемы. Например, если сравнивать строку с int, то:

  • '1.00' = 1 -> true, потому что значения сравниваются как числа

Но как струны:

  • '1.00' = '1' -> false, потому что значения сравниваются как строки

Думаю, у вас могут быть похожие проблемы со свиданиями.

person Gordon Linoff    schedule 03.10.2019