Как исправить ошибки сжатия OData в Azure Data Factory

Azure Data Factory OData‑источник часто сталкивается с проблемами декомпрессии, когда в заголовках запроса указана сжатие, обычно из‑за несовпадения методов сжатия между источником и возможностями ADF. Решение состоит в правильной настройке заголовков запроса и в том, чтобы тип сжатия в наборе данных соответствовал реальному формату сжатия, используемому источником.

Содержание

• Понимание проблемы сжатия
• Настройка заголовков сжатия в OData‑источнике
• Согласование типа сжатия в наборе данных
• Альтернативные решения
• Устранение распространённых ошибок

Понимание проблемы сжатия

Ошибки декомпрессии возникают из‑за того, что OData‑источник ADF имеет ограничения при работе с сжатыми ответами. При настройке заголовков сжатия ADF отправляет запрос с этими заголовками, но внутренний механизм декомпрессии может не обработать ответ корректно.

Согласно обсуждениям на Reddit, пользователи успешно запрашивают сжатые данные, задав заголовок accept encoding: deflate, но затем сталкиваются с трудностями при чтении сжатых данных. Это указывает на проблему в возможностях декомпрессии ADF, а не в запросе.

В репозитории OData GitHub отмечается аналогичная проблема: DataServiceContext.ExecuteBatch не поддерживает сжатые ответы, и решение заключается в правильной настройке как запроса, так и метода декомпрессии.

Настройка заголовков сжатия в OData‑источнике

Чтобы корректно настроить сжатие для вашего OData‑источника, выполните следующие шаги:

Конфигурация заголовков запроса

1. В наборе данных OData перейдите на вкладку Connection.
2. Разверните раздел Custom headers.
3. Добавьте следующие заголовки:
   • Accept-Encoding: gzip, deflate (или конкретный метод сжатия, поддерживаемый вашим API)
   • Accept: application/json (или соответствующий тип контента)

Как показано в исследовании, один пользователь успешно обошёл проблемы сжатия, запрашивая сжатые данные с заголовком accept encoding: deflate — Reddit.

Расширенная конфигурация

Для более сложных сценариев можно использовать активность Web вместо прямого OData‑источника:

{
    "name": "WebActivity",
    "type": "WebActivity",
    "typeProperties": {
        "method": "GET",
        "url": "your-odata-endpoint",
        "headers": {
            "Accept-Encoding": "gzip, deflate",
            "Accept": "application/json"
        },
        "authentication": {
            "type": "ServicePrincipal"
        }
    }
}

Согласование типа сжатия в наборе данных

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

Конфигурация набора данных

1. Перейдите к вашему набору данных OData‑источника.
2. Откройте настройки Format.
3. В разделе Compression type выберите подходящий вариант:
   • GZip: для файлов .gz
   • ZipDeflate: для файлов .zip
   • TarGzip: для файлов .tar.gz
   • None: если сжатие на уровне набора данных не применяется

Как указано в документации Microsoft, «Когда вы указываете свойство сжатия в наборе данных входа, активность копирования читает сжатые данные из источника и декомпрессирует их».

Важно: Если вы используете OData‑источник напрямую без файлового сжатия, возможно, понадобится установить тип сжатия на «None» и обрабатывать декомпрессию другими способами.

Альтернативные решения

1. Использовать Azure Functions для декомпрессии

Если ADF не может напрямую обработать сжатый ответ, используйте Azure Function для предварительной декомпрессии данных:

public static async Task<HttpResponseData> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req,
    ILogger log)
{
    // Декомпрессируем gzip‑ответ
    using var decompressedStream = new GZipStream(req.Body, CompressionMode.Decompress);
    using var decompressedReader = new StreamReader(decompressedStream);
    var decompressedContent = await decompressedReader.ReadToEndAsync();
    
    // Возвращаем декомпрессированный контент
    var response = req.CreateResponse(HttpStatusCode.OK);
    response.Headers.Add("Content-Type", "application/json");
    response.WriteString(decompressedContent);
    return response;
}

2. Binary Source с настройками сжатия

Для файлового сжатия используйте Binary Source с конкретными настройками сжатия:

{
    "source": {
        "type": "BinarySource",
        "storeSettings": {
            "type": "AzureBlobFSReadSettings",
            "recursive": false
        },
        "formatSettings": {
            "type": "BinaryReadSettings",
            "compressionProperties": {
                "type": "ZipDeflateReadSettings"
            }
        }
    }
}

Этот подход хорошо работает для сжатых файлов, хранящихся в Blob Storage.

3. Data Flow Transformation

Используйте Data Flow в Azure Data Factory для обработки сжатия:

1. Создайте Data Flow с OData‑источником.
2. Добавьте трансформацию Derived Column или Select.
3. При необходимости используйте выражения для декомпрессии.
4. Настройте sink с соответствующими параметрами сжатия.

Устранение распространённых ошибок

Ошибка «Cannot decompress the source data»

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

• Проверьте реальный формат сжатия, используемый API‑источником.
• Совпадайте тип сжатия в наборе данных точно.
• Попробуйте разные варианты сжатия (GZip vs Deflate).

В StackOverflow пользователи решали эту проблему, выбрав «ZipDeflate» вместо других типов при работе с файлами .gz.

Ошибка «End of Central Directory record could not be found»

Это указывает на повреждённый zip‑файл. Согласно Microsoft Q&A, это может произойти из‑за неподдерживаемых методов сжатия. Внутренняя библиотека zip в ADF поддерживает только метод «deflate».

Проблемы производительности с большими файлами

Для файлов более 1 ГБ, как отмечено в Microsoft Q&A, могут возникать ограничения. Решения:

• Декомпрессируйте большие файлы вручную перед обработкой.
• Используйте стратегии разбиения на части.
• Рассмотрите Azure Databricks для обработки очень больших сжатых наборов данных.

Источники

1. Azure Data Factory - Decompression error when file was copied via ADF - Stack Overflow
2. Azure Data Factory: How to deal with compressed JSON - Reddit
3. DataServiceContext.ExecuteBatch Does Not Support Compressed Response - OData GitHub
4. Data Compression in Azure Data Factory via Data Flow - Microsoft Q&A
5. Supported file formats (legacy) - Azure Data Factory & Azure Synapse | Microsoft Learn
6. Decompress a tar.Z file in Azure Data Factory - Microsoft Q&A
7. ADF Copy activity is failing when extracting zip files - Microsoft Q&A
8. Data factory unable to unzip nested zip file in copy activity error out - Microsoft Q&A

Заключение

Чтобы успешно включить сжатие для OData‑источников Azure Data Factory, необходимо решить обе части: конфигурацию запроса и обработку декомпрессии.

1. Настройте правильные заголовки с Accept-Encoding: gzip, deflate для запроса сжатых данных от API‑источника.
2. Согласуйте типы сжатия в наборе данных для избежания ошибок декомпрессии.
3. Рассмотрите альтернативные подходы (Azure Functions, Binary Source, Data Flow), если прямое сжатие OData не работает.
4. Проверьте настройки на небольших файлах до масштабирования на большие наборы данных.

Ключевой вывод: OData‑источник ADF имеет ограничения при работе с некоторыми форматами сжатия, поэтому может потребоваться внедрить пользовательские решения или использовать другие активности для достижения преимуществ сжатия, которые вы наблюдали в Postman. Для постоянных проблем следите за реальными методами сжатия, используемыми вашим API‑источником, и корректируйте конфигурацию ADF соответственно, либо реализуйте предварительную обработку сжатия вне OData‑источника.