Это потому, что сам kudu не будет выдавать никаких исключений (только поднимать предупреждение) и, следовательно, impala (справедливо) примет задачу выполненной.
Относительно того, почему Куду решил сделать это таким образом, мы можем только строить догадки.
Это только мое мнение. Kudu (и Impala) предназначены для аналитической нагрузки вместо транзакционной нагрузки. Что обычно включает в себя пакетную обработку больших объемов данных. Было бы нежелательно, чтобы приложение не работало из-за небольшого количества записей с дублирующимися ключами.
Таким образом, поведение по умолчанию вставляет все записи с неповторяющимися ключами и пропускает все дубликаты ключей. Это можно изменить с помощью upsert, который заменяет дубликаты.
Согласно документации Imapala
Если оператор INSERT пытается вставить строку с теми же значениями для столбцов первичного ключа, что и существующая строка, эта строка отбрасывается и операция вставки продолжается. Когда строки отбрасываются из-за дублирования первичных ключей, инструкция заканчивается предупреждением, а не ошибкой. (Это изменение по сравнению с ранними выпусками Kudu, где по умолчанию в таких случаях возвращался с ошибкой, и для успешного выполнения оператора требовался синтаксис INSERT IGNORE. Предложение IGNORE больше не является частью синтаксиса INSERT.)
В ситуациях, когда вы предпочитаете заменять строки дублирующимися значениями первичного ключа, а не отбрасывать новые данные, вы можете использовать оператор UPSERT вместо INSERT. UPSERT вставляет строки, которые являются совершенно новыми, и для строк, которые соответствуют существующему первичному ключу в таблице, столбцы не первичного ключа обновляются, чтобы отразить значения в «добавленных» данных.
Если вы действительно хотите хранить новые строки, а не заменять существующие, но не можете этого сделать из-за ограничения уникальности первичного ключа, рассмотрите возможность воссоздания таблицы с дополнительными столбцами, включенными в первичный ключ.