Разбор объемного текста с помощью Hadoop: лучшие практики для генерации ключей

Question

У меня есть «большой» набор полных предложений с разделителями строк, которые я обрабатываю с помощью Hadoop.Я разработал картограф, который применяет некоторые из моих любимых техник НЛП.Существует несколько различных приемов, которые я сопоставляю с исходным набором предложений, и моя цель на этапе сокращения состоит в том, чтобы собрать эти результаты в группы таким образом, чтобы все члены группы разделяли одно и то же исходное предложение.

Я чувствую, что использование всего предложения в качестве ключа - плохая идея.Я чувствовал, что генерация некоторого хэш-значения предложения может не сработать из-за ограниченного числа ключей (необоснованное убеждение).

Кто-нибудь может порекомендовать лучшую идею / практику для генерации уникальных ключей для каждого предложения? В идеале, я хотел бы сохранить порядок.Однако это не главное требование.

Aντίο,

Answer 1

Несмотря на ответ, который я уже дал вам о том, какой может быть правильная хеш-функция, я действительно рекомендую вам просто использовать сами предложения в качестве ключей, если у вас нет конкретной причины, почему это проблематично.

Answer 2

Стандартное хеширование должно работать нормально.Большинство алгоритмов хеширования имеют пространство значений, намного превышающее число предложений, с которыми вы, вероятно, будете работать, и, таким образом, вероятность столкновения будет по-прежнему крайне низкой.

Answer 3

Хотя вы, возможно, захотите избежать простых хеш-функций (например, любой недоделанной идеи, которую вы могли бы быстро придумать), потому что они могут не перепутать данные предложения в достаточной степени, чтобы избежать коллизий, во-первых, одной из стандартныхкриптографические хеш-функции, вероятно, вполне подойдут, например, MD5, SHA-1 или SHA-256.

Для этого можно использовать MD5, даже если было обнаружено столкновений и алгоритмсчитается небезопасным для интенсивных целей безопасности.Это не критичное для безопасности приложение, и обнаруженные коллизии возникли из тщательно сконструированных данных и, вероятно, не возникнут случайным образом в ваших собственных данных предложений НЛП.(См., Например, Йоханнес Шинделин объяснение того, почему, вероятно, нет необходимости менять git на использование хэшей SHA-256, чтобы вы могли понять причину этого.)