Миграция данных из различных RDBMS в HADOOP

[sshikov]

Такое впечатление, что автор остановился на полдороги. Как правило, миграция не заканчивается на выполнении одного запроса. Чаще по опыту нужно синхронизировать СУБД и Hadoop регулярно, и чем чаще (и чем ближе они друг к другу), тем лучше. Как минимум, бизнесу хочется иметь Т-1. А как только вы хотите периодичность — вам как правило нужно точно знать, на какой момент вы имеете копию. И тут начинается много чего интересного… Скажем, у нас бизнес хочет иметь в хадупе копию через час после закрытия опердня (если не раньше), чтобы успеть в этот же календарный день построить в хадупе отчетность для регулятора.

BTW, раз уж вы такое делаете, можете рассказать, с какой примерно скоростью удается доставать данные по JDBC? В идеале с указанием на то, сколько примерно ресурсов в наличии в СУБД и хадупе.

[neoflex]

Вы правы, отметив, что миграция не заканчивается на выполнении одного запроса, особенно, если бизнес хочет иметь в hadoop копию через час после закрытия опердня для построения отчетности. Для данных задач, может потребоваться разработка различных систем и сервисов, с развернутой архитектурой для реализации конкретных задач. В статье хотелось отразить концепцию взаимодействия СУБД и HADOOP, а также отразить некоторые важные нюансы протекания данного процесса.

Рассматривая вопрос скорости доставления данных по JDBC, тут есть множество посторонних факторов, которые могут повлиять на данный процесс (например: скорость передачи данных по сети, характеристики жестких дисков и др.). Рассматривая системы, с которыми мне приходилось работать, средняя скорость доставки данных для различных систем варьировалась от 70 до 100 Мбит/c.

[sshikov]

>некоторые важные нюансы
ну вот у нас нюанс простой — если вы хотите предикаты, или тем более, конкретные ключи, то надо учитывать, что спарк не умеет bind variables. Поэтому все условия — в запросе. А если ключей вам нужно много — то запрос быстро растет, достигает того размера, когда парсеру становится плохо. Ну т.е. у нас скажем были случаи, когда запрос получался размером в мегабайты, и этот запрос тупо ронял Oracle, или приводил к его деградации.

[Ninil]

Хорошо бы добавить в статью, каким образом будет физически выполняться экспорт, если размер таблицы намного больше размера ОЗУ?

[sshikov]

Спарк не держит весь датасет в памяти. Зачем? Если у вас 10 партиций, то для каждой из них одновременно в памяти будет fetchSize строк. А дальше вполне можно скидывать данные на диск в паркеты. Ну, по крайней мере если вы их сразу не обрабатываете в процессе экспорта — тогда да, потребности могут быть другие.

[Tellamonid]

А почему Spark, а а не sqoop? Sqoop же как раз сделан для миграции между реляционными базами и Хадупом, и обратно.

[sshikov]

Sqoop тупой как валенок. В частности, кто запрос-то будет строить для него? Ну в смысле, если там хоть какие-то условия нужны, которые меняются время от времени? А если запрос уже нужно построить — то зачем Sqoop нужен, когда спарк сам может выполнить?

[neoflex]

Apache Sqoop также является одним из решений миграции данных между РСУБД и Hadoop, но при миграции данных, может возникнуть потребность в индивидуальной обработке при извлечении данных и загрузкой в Hadoop. В таком случае Sqoop плохо подходит для реализации такого рода задач, и тогда предпочтительней будет использовать утилиты JDBC Apache Spark.