Хранение проанализированных данных журнала в hadoop и их экспорт в реляционную БД - PullRequest
Новая
       8

Хранение проанализированных данных журнала в hadoop и их экспорт в реляционную БД

1 голос
/ 20 июня 2010

У меня есть требование разбирать как логи доступа Apache, так и логи tomcat один за другим, используя map limit. Из журнала tomcat извлекаются некоторые поля, а из журнала Apache - остальные. Мне нужно объединить / отобразить извлеченные поля на основе временной метки и экспортировать эти сопоставленные поля в традиционный реляционный БД (например, MySQL).

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

Несколько подходов, о которых я думаю

1) Записать вывод карты, уменьшенный как из проанализированных журналов доступа Apache, так и из журналов Tomcat в отдельные файлы и объединить их в один файл (опять же на основе метки времени). Экспортируйте эти данные в MySQL.

2) Используйте Hbase или Hive для хранения данных в табличном формате в hadoop и экспортируйте их в MySQL

3) Непосредственно записать выходные данные преобразования карты в MySQL, используя JDBC.

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

1 Ответ

2 голосов
/ 11 июля 2010

Почти всегда предпочтительнее иметь меньшие, более простые задания MR и связывать их вместе, чем иметь большие, сложные задания. Я думаю, что ваш лучший вариант - пойти с чем-то вроде # 1. Другими словами:

  1. Обрабатывает протокол Apache httpd в едином формате.
  2. Обработка Tomcat регистрируется в едином формате.
  3. Соедините выходные данные 1 и 2, используя любую логическую логику, записав результат в один и тот же формат.
  4. Экспорт полученного набора данных в вашу базу данных.

Вероятно, вы можете выполнить объединение и преобразование (1 и 2) в одном шаге. Используйте карту, чтобы преобразовать и выполнить соединение со стороны сокращения.

Не похоже, что вам нужны / нужны издержки произвольного доступа, поэтому я бы не стал смотреть на HBase. Это не является его сильной стороной (хотя вы можете сделать это в смысле произвольного доступа, просматривая каждую запись в HBase по отметке времени, проверяя, существует ли она, объединяя запись или просто вставляя, если она не существует, но очень медленно, сравнительно). В Hive может быть удобно хранить «объединенные» результаты двух форматов, но вам все равно придется преобразовывать записи в этот формат.

Вы абсолютно не хотите, чтобы редуктор записывал напрямую в MySQL. Это эффективно создает DDOS-атаку на базу данных. Рассмотрим кластер из 10 узлов, каждый из которых выполняет 5 редукторов, и у вас будет 50 одновременных программ записи в одну таблицу. По мере роста кластера вы очень быстро превысите максимальное число подключений и задушите СУБД.

Все это говорит, спросите себя, имеет ли смысл помещать столько данных в базу данных, если вы рассматриваете полные записи журнала. Этот объем данных является как раз тем случаем, для которого Hadoop предназначен для долгосрочного хранения и обработки. Если вы вычисляете агрегаты этих данных, непременно добавьте их в MySQL.

Надеюсь, это поможет.

...