Распаковка фабрики данных Azure
У меня вопрос. У меня есть несколько файлов .zip на моем FTP-сервере, и я хочу распаковать и скопировать их в ADLS. В документации этому есть четкое объяснение:
«Прочтите файл .zip с FTP-сервера, распакуйте его, чтобы получить файлы внутри, и поместите эти файлы в Azure Data Lake Store. Вы определяете входной набор данных FTP со свойством JSON типа сжатия как ZipDeflate».
Я пробовал с этим, и на моем ADLS я получаю сжатый файл. Я попытался указать свойства файла, определить разделитель и прочее, и все еще получал сжатый файл в хранилище озера данных. Я думаю, это то, как я определяю набор выходных данных. Есть ли какие-то правила, как определять выходной набор данных, если входящий набор данных - это файлы .zip с FTP.
Ответы 1
Скорее всего, вы также определили сжатие своего выходного набора данных как ZipDeflate, поэтому вы получаете заархивированный файл на ADLS. Попробуйте изменить набор выходных данных (тот же, где вы настраиваете путь в ADLS), чтобы он не использовал сжатие. Вы должны иметь в своей деятельности копирования входной набор данных, в котором вы настраиваете ftp со сжатием, и выходной набор данных, где вы настраиваете большинство вещей для озера без сжатия.
Таким образом вы сообщаете фабрике данных, что нужно получить заархивированный файл и сохранить его в распакованном виде в ADLS.
Надеюсь, это помогло!
Источник - это место, откуда вы получаете данные, а приемник - это место, где вы их храните. Источник привязан к входному набору данных, приемник связан с выходным набором данных. Для всего вашего вывода не должно быть настроено сжатие, поэтому он сохраняет распакованный файл.
Спасибо, @Martin. Для zip-файла размером 90 МБ на его копирование и распаковку ушло 2,5 часа. (размер в распакованном виде 270 МБ) Это нормально, чтобы это длилось так долго или? Я знаю, что это зависит от сервера и прочего, просто хочу узнать ваше мнение.
Это зависит от оборудования компьютера среды выполнения интеграции (если ftp-сервер находится в помещении и вы используете IR), а также от пропускной способности ftp-сервера. Процесс распаковки не должен длиться так долго.
Только что проверил, у меня пропускная способность 9кбс. Я попробую использовать двоичную копию, а затем разархивирую ее с помощью пользовательского экстрактора u sql.
Привет, Мартин, просто хотел проверить, можем ли мы выполнить декомпрессию .7z таким же подходом?
Привет, в прошлый раз, когда я попробовал, это было невозможно. 7z - это обычно режим сжатия с низкой совместимостью. Если вы используете 7-zip для сжатия файлов, вы можете использовать его для сжатия в одном из поддерживаемых форматов, например GZip, BZip2 или Zip. Надеюсь, это помогло!
архивирует / распаковывает одну из функций среды выполнения интеграции, для которой требуется среда выполнения Java? некоторые вещи, такие как запись формата Parquet, требуют этого, тогда как другие вещи, такие как чтение и запись CSV, не требуют
Привет, Мартин, спасибо за ответ. Я определил поведение копирования в моем выходном наборе данных как двоичную копию. Моя логика: приемник исходного кода будет брать файлы и распаковывать их, а мне нужна двоичная копия для моего вывода. Теперь я вижу, что в моей папке .zip в хранилище озера данных находится распакованный текстовый файл. Думаю, он просто сохранил иерархию папок.