Определение зависимостей для проектов MapReduce и рабочих процессов Oozie

Question

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

Мы используем распределение Hadoop от Cloudera (CDH).

Наш технологический процесс разработки:

• проект MapReduce размещен в SVN РЕПО
• каждый из них имеет POM файл зависимостей определенной (и некоторые другие вещи тоже)
• мы также создать Oozie рабочий проекты, в которых эти проекты MapReduce определены как зависимые в POM и которые отвечают за определение потока выполнения проектов MapReduce.
• Артефакт сборки проекта Oozie представляет собой файл jar, содержащий все используемые им контейнеры MapReduce, и Зависимости Ir (мы используем сборку плагин Maven, чтобы сжать его), это артефакт мы потом развернуть на HDFS (после распаковки)
• мы строим проекты с Maven, управляемых Дженкинс
• успешно сборок получить развернутые на сервер Archiva
• развертывание в HDFS по требованию от Archiva, получение артефакта проекта проекта Oozie, извлечение его и перенос его в HDFS
• некоторые зависимости (а именно те, которые используются Oozie; Hive, Sqoop, соединитель MySQL, Jline, commons -... и т. Д.) Не нужны для строительства проектов, но им необходимо для работы

Еще со мной?

Теперь дебаты об определении этих зависимостей проектов MapReduce и Oozie. Есть две точки зрения.

Говорят, что не обязательно определять эти зависимости (то есть, которые не нужны для создания проектов) в файлах POM, а вместо этого иметь их в общей папке в HDFS и всегда предполагать, что они есть.

Плюсы:

• дэвы не нужно заботиться о них (впрочем, они заботятся о некоторых других)
• , скорее всего, при обновлении распределения CDH, это легче обновлять их в общий каталог, чем в каждой индивидуальности проекта (не уверен, если это необходимо, хотя)

Cons:

• определенные зависимости определены для проектов, некоторые из них считаются неприемлемыми, некоторые из них не считаются правильными
• общий каталог может стать стоком неиспользуемых JAR, и никто не будет знать, что еще используется, а какие нет
• код становится менее переносимым потому что он предполагает, что эти JAR всегда присутствуют в HDFS с правильной версией

Так что вы, ребята, думаете?

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

Answer 1

Я голосую за второе, что означает обрабатывать и поддерживать зависимости для каждого проекта, а не для общего каталога. Причина заключается в том, что общий каталог будет меняться с течением времени, и через некоторое время другой проект больше не будет работать, потому что кто-то удалит некоторые зависимости и т. Д. Поэтому лучше удержать зависимости в помпе, для которой они предназначались. Кроме того, любой проект будет работать без всякой зависимости от текущего состояния общей папки.

Вы можете подумать о родительском пом, который содержит значения по умолчанию зависимости, которые следует использовать. Это можно обрабатывать через определение в разделе dependencyManagement, а конкретный проект определяет реальные зависимости без версий. Другим решением может быть использование import scope.

<dependency> 
    <groupId>yourGroupIdy</groupId> 
    <artifactId>YourArtifactId</artifactId> 
    <version>1.0</version> 
    <scope>import</scope> 
</dependency> 

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