Миграция Java-приложения в Hadoop: блокпосты архитектуры / дизайна?

Question

Alrite .. итак ... вот ситуация: я отвечаю за разработку миграции программного обеспечения ETL (скорее EAI), основанного на java.Мне придется перенести это на Hadoop (версия apache).Технически, это скорее перезагрузка, а не миграция, потому что у меня нет базы данных для миграции.Речь идет об использовании Hadoop, так что фаза трансформации («ETL») идет параллельно.Это сделало бы мое программное обеспечение ETL,

1. Быстрее - с преобразованием parallel-iz-ed.
2. Масштабируемый - Обработка большего количества данных / больших данных - это добавление большего количества узлов.
3. Надежность - избыточность и надежность Hadoop добавят к функциям моего продукта.

Я протестировал эту конфигурацию - изменил мои алгоритмы преобразования в модель mapreduce, протестировал ее на высокопроизводительном кластере Hadoopи отметили производительность.Теперь я пытаюсь понять и документировать все те вещи, которые могут помешать редизайну / переархивированию / миграции приложения.Вот некоторые из них, о которых я мог подумать:

1. Два других этапа: извлечение и загрузка - мой инструмент ETL может работать с различными источниками данных. Итак, я должен перепроектировать свои адаптеры данных для чтения данных из этих данныхисточники, загрузить его в HDFS, а затем преобразовать его и загрузить в целевой источник данных?Может ли этот шаг стать огромным узким местом для всей архитектуры?
2. Обратная связь: Таким образом, мое преобразование завершается неудачно для записи - как я могу сообщить конечному пользователю, что ETL обнаружил ошибку в определенной записи?Короче говоря, как мне отслеживать, что на самом деле происходит на уровне приложения со всеми происходящими картами / сокращениями / слияниями и сортировками - веб-интерфейс Hadoop по умолчанию не для конечного пользователя, а для администраторов.Так стоит ли мне создавать новое веб-приложение, которое не использует веб-интерфейс Hadoop?(Я знаю, что это не рекомендуется)
3. Безопасность: Как мне обрабатывать авторизацию на уровне Hadoop?Кто может выполнять задания, кому не разрешено их запускать - как поддерживать ACL?

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

Answer 1

1. Я не ожидаю, что загрузка в HDFS будет узким местом, поскольку нагрузка распределяется между датоданиями, поэтому сетевой интерфейс будет лишь узким местом.Загрузка данных обратно в базу данных может быть узким местом, но я думаю, что это не хуже, чем сейчас.Я бы спроектировал задания так, чтобы их вход и выход находились в HDFS, а затем выполнял какую-то массовую загрузку результатов в базу данных.
2. Обратная связь является проблематичным моментом, поскольку на самом деле MR имеет только один результат - и это преобразованные данные.Всем другим приемам, таким как запись неудачных записей в файлы HDFS, будет не хватать «функциональной» надежности MR, поскольку это побочный эффект.Одним из способов решения этой проблемы является разработка программного обеспечения таким образом, чтобы оно было готово к дублированию неудачных записей.Существует также scoop = инструмент, специфичный для переноса данных между базами данных SQL и Hadoop.http://www.cloudera.com/downloads/sqoop/ В то же время я рассмотрел бы использование HIVE - если ваши преобразования SQL не так уж сложны - возможно, было бы целесообразно создать файлы CSV и выполнить первоначальную предварительную агрегацию с Hive, чтобы уменьшить объемы данных перед переходом к (возможно одноузловая) база данных.