Стоит ли анализировать содержимое хэша идентификатора или убрать хэш
Что проверяют
Понимаете ли вы, что хэш это не шифр, и отличаете ли ключ для связывания данных от признака для анализа. Заодно проверяют аккуратность с персональными данными: захэшированный идентификатор очень часто остаётся персональными данными.
Как отвечать
Сначала выясните назначение поля. Если хэш это псевдоним пользователя, он и есть ключ: на нём держатся связи витрин и дедупликация, убирать его нельзя. Анализировать содержимое бессмысленно: выход криптографической функции равномерен, из него не извлекается ничего, кроме факта совпадения значений.
Что действительно имеет смысл смотреть:
- формат и длину, они подсказывают алгоритм и наличие соли;
- долю уникальных значений и подозрительные повторы;
- стабильность значения для одного объекта между источниками.
Осмысленное использование самой строки одно: детерминированное разбиение по остатку для шардирования или выборки. Если поле техническое, ни с чем не связывается и никем не читается, его лучше убрать из витрины, лишний ключ путает и мешает партиционированию. Когда аналитике нужны атрибуты исходника, их выносят отдельными явными полями с понятными правилами доступа, а не выковыривают из хэша.
Где спотыкаются
Говорят, что хэширование анонимизирует данные. Обратимости нет, но одинаковая почта даёт одинаковый хэш, значит человека можно сматчить между базами, а короткое поле вроде телефона вскрывается перебором словаря за разумное время. Соль меняет картину, но ломает связывание между системами.
Убирают хэш, не проверив потребителей. Через месяц выясняется, что на нём строился ключ партиционирования или связь двух витрин, а восстановить старые значения уже нечем.
Пробуют считать признаки из строки: первый символ, количество цифр, длина. Для модели это чистый шум, который на обучении иногда выглядит как работающий признак и красиво разваливается на проде.