2013-12-26 2 views
0

Я начал работу над аналитическим проектом. Варианты использования - это понимание моделей покупки клиентов и источников данных, таких как веб-журналы, реляционные базы данных (в которых хранится мастер продукта, мастер-клиент). Команда реляционной базы данных, команда hadoop совершенно другая. Во время обсуждения архитектуры обсуждалось, что основные данные (Product, Customer) будут одноразовой загрузкой, а инкрементные обновления будут ежедневным sqoop от oracle до hdfs и использование Hive для создания текущего представления (со всем последним продуктом изменения). Начинается с сведений о продукте.Работа с основными данными Обновления в hadoop

  1. Начальный уровень продукта составляет около 10G на стороне Oracle.
  2. Суточный прирост варьируется от 5 МБ до 100 МБ.

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

Как никто сталкивается с таким решением и как вы его обрабатываете?

ответ

1

Я пока не вижу проблемы. Если вы начинаете с одного большого файла и добавляете по 1 файл каждый день, вы получите около 1000 файлов через год, что не является проблемой (по крайней мере, не для узла имен).
Тем не менее, его не оптимально хранить небольшой файл в HDFS независимо от его количества.
Я рекомендую вам аппликативный подход к этому и объединить файлы после того, как прошло достаточно времени, например:

  1. Создания ежемесячных разделов на вашем столе (основной продукт), каждый день вставить новый файл таблица, после окончания месяца, вставляет перезапись данных обратно в тот же раздел.
  2. Если утверждение данных не выполняется просто путем вставки, но существует более сложная логика, решение может создавать основную таблицу, а затем копировать инкрементные данные в местоположение HDFS и создавать внешнюю таблицу в этом месте.
    Сочетание этих двух таблиц с использованием union all в view и создание процесса загрузки для загрузки данных из HDFS в основную таблицу, когда это возможно.

Если вы столкнулись с конфликтом имен узлов относительно слишком большого количества небольших файлов, вы можете прочитать о способах решения проблемы «небольших файлов» here.