yacc>>> Ну тогда расскажи мне на простом примере - вот у тебя есть большой CSV для импорта. Распараллель его не 10 отдельных узлов. А лучше на 100.
Татарин>> Что именно распараллелить? Побить файл на 10 кусков? на 100 - это сложнее, да? И засунуть их балками в SQL? И?
yacc> Это я вытащу в отдельную ветку ибо ты ляпнул и не подумал.
yacc> Чтобы прочитать CSV файл надо его распрасить. Более того - в каждый кусок вставить заголовок, который идет первой строчкой. И после разбития на файлы тебя ждет ... повторный парсинг ( уже каждого куска ) !
тут всё зависит от конкретной реализации и что понимается под словом импорт.
CSV всё таки можно нарезать частями и загрузить в acquisition layer балком.
главное что бы памяти хватило на ETL сервере при доставке.
заголовок тебе не нужно вставлять к файлам, скорее наборот ты фастлоадишь уже в готовую заранее пустую таблицы такой же структуры.
yacc> Более того - для каждой строчки сделать валидацию на предмет того, что преобразование в целевой тип возможно и не нарушает его: скажем целевая строчка VARCHAR(200) а у тебя есть строка длиной 300, которую невозможно вставить без обрезания. Потом тебе результаты обработки ... мержить
это само собой что нужно мерджить потом где-то если ты ранее порезал. где-то выигрываешь - где-то проигрываешь.
yacc> Далее, тебе потребуется не 1 а 10 или 100 коннекций к базе, причем по сети польется уже 10-100 кратный поток данных через сетевой интерфейс, что забьет остальную работу.
если параллелить что бы на разные узлы грузить то всё таки нагрузку на сеть мы тоже распараллелим, это не аргумент.
к тому же у тебя ETLные ноды к нодам кластера могут по отдельным линкам сидеть, а пользовательская сеть - по другим интерфейсам.
что тебе реально забьёт работу так это смешанная нагрузка если ты будешь грузить на пределе - а уже и витрины надо рассчитать и ad-hockеры пришли на работу и стали базу бомбить кривыми джойнами на все узлы.
а так гринплам например умеет принять разные части данных на разные сегментные ноды, а затем уже после окончания прогрузки между сегментами их синхронизировать.
yacc> Далее, целевая таблица как правило одна - т.е. сразу будут локи, если в нее запихивают данные 10-100 процессов одновременно, а если ты на каждый процесс создашь отдельную, то все равно потом мержить в одну.
а как ты хотел? ты так или иначе сначала закинул в престейдж-STG как смог , затем прогрузка в обычный STG, затем генерация суррогатников и далее по слоям прогрузка данных.
yacc> Поздравляю - ты создал больше гемора чем ускорил
это всё вопрос того что у тебя есть и того что нужно сделать. если нет мощности что бы успеть в окно прогрузки прогрузить тупо в лоб - добро пожаловать в мир геморроя.
вообще CSV это легко, вот если нужно XML или JSON прожёвывать большой - это да, вот тут реально может быть много секса.
и опять же редко когда у тебя один CSV. нужно же файловый пакет от источника прогрузить в котором пачка CSV (согласно шины данных), подписанных ЭЦП, какие-то архивы, какие-то инкрменты пришли. соответственно оно может уже на этом уровне параллелиться естественным образом.