Сравнение 1 миллиона биометрических (маленьких) файлов с использованием Hadoop/HDFS

Я новичок в Hadoop, прочитал проблему с небольшим файлом в Hadoop, теперь у меня есть проблема, которую нужно решить, помогите мне начать

Проблема:

Исходный результат: более 1 миллиона (приблизительно) файлов, каждый из которых имеет размер почти 1 КБ (нельзя предотвратить создание или регулирование размера)

Группировка результатов. Исходные результаты группируются в 1000 файлов в группе .

Требуется задание:

Файлы в группе должны сравниваться по принципу «один к одному». Файлы представляют собой двоичные миниатюрные (биометрические) файлы с определенной стандартной структурой (заголовок, содержимое и т. д.).

Поскольку ожидается, что исходный результат со временем увеличится, я хотел бы провести сравнение на Hadoop.

Вклад в Hadoop:

‹ InputFile > ‹ HARFile > ‹ Output >

‹ Пример входного файла >:

Обратите внимание, что имена файлов являются уникальными идентификаторами, и одно только имя файла может помочь.

            08RTC345744.txt 08RTC345746.txt
            08RTC345744.txt 08RTC3457XX.txt
            08RTXX457XX.txt 08YYC3457YY.txt
            ..................
             XXXXXXN.txt YYYYYYN.txt

Алгоритм процесса: (не реализован, а просто идея)

  1. Читать входной файл построчно
  2. Прочитайте каждый файл в строке с помощью har:// (например, прочитайте har://xxx/08RTC345744.txt и har://xxx/08RTC345746.txt)
  3. Сравните файл, считанный с hdfs (HAR), используя соответствующий биометрический алгоритм.
  4. если они показывают сходство Emit ‹ Filenames > ‹ Count >

‹ HARFile SAMPLE Files >

08RTC345744.txt 
08RTC345746.txt
08RTC345745.txt 
08RTC3457XX.txt
08RTXX457XB.txt 
08YYC3457YY.txt

1) Лучше реализовать в Hadoop?

2) Я читал, что сравнение небольших файлов является проблемой в Hadoop, лучше ли сформировать файл HAR для набора групп, а затем сравнить?

3) Будет ли мой алгоритм обработки работать или нет?

4) эффективен? Я думаю, конечно, нет, любая другая идея?

5) Любая идея относительно MapReduce для биометрического сопоставления?

6) Является ли HBASE решением?


person Micky C002    schedule 26.12.2014    source источник


Ответы (1)


Объем данных, которые у вас есть, находится на грани того, чтобы их можно было обрабатывать в кластере Hadoop. Небольшого кластера будет достаточно, если у вас не будет гораздо больше файлов.

Первая проблема, с которой вы столкнулись, — это загрузка ваших данных в кластер. У вас есть много маленьких файлов, каждый из которых содержит одну запись данных, если я правильно понял. В итоге вы хотите получить меньше больших файлов. Чтобы решить эту проблему, я бы объединил файлы до или в момент приема. Файлы HAR не являются хорошим вариантом. Есть несколько способов сделать это, и это в основном зависит от того, как ваши данные будут поступать в ваш кластер и как вы будете их обрабатывать позже. Вы можете проверить. Если ваши данные поступают в виде неограниченного потока, проверьте: - Apache Flume - Apache Kafka - Apache Storm - Apache Spark Если ваши данные уже где-то есть, и вы выполняете разовую работу: - Реализуйте свою собственную программу, которая выполняет слияние.

Общим здесь является то, что вы хотите представить каждый из ваших файлов как одну запись данных. Затем вы можете выбрать формат файла, в котором вы хотите хранить множество записей. Правильно настроив вышеуказанные инструменты, вы получите большие файлы на вашей HDFS, содержащие записи данных.

Затем вам нужно решить, как вы хотите обрабатывать данные. Вы хотите сравнить записи друг с другом, и для этого вы также можете использовать ряд инструментов:

  • Обычный MapReduce. Реализуйте все с помощью инструментов низкого уровня. Узнайте, как сделать перекрестное соединение эффективным, поскольку это то, что вы делаете.
  • Улей. Реализуйте UDF, который вызывает ваш алгоритм сравнения, и выразите всю работу в виде SQL-запроса.
  • Свинья. Подобно улью, но с собственным языком сценариев.
  • Апач Спарк. Более новый инструмент с хорошим API, способный реализовать работу, как с MapReduce, но гораздо проще и чище.

Что использовать, в конечном итоге будет зависеть от вашего варианта использования и доступной среды.

person miljanm    schedule 31.12.2014