As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Práticas recomendadas para o Amazon Managed Workflows for Apache Airflow
Este guia descreve as práticas recomendadas ao usar o Amazon Managed Workflows for Apache Airflow.
**Topics**
+ [Ajuste de desempenho para o Apache Airflow no Amazon MWAA](best-practices-tuning.md)
+ [Como gerenciar dependências do Python em requirements.txt](best-practices-dependencies.md)
# Ajuste de desempenho para o Apache Airflow no Amazon MWAA
Este tópico descreve como ajustar o desempenho de um ambiente Amazon Managed Workflows for Apache Airflow usando [Como usar opções de configuração do Apache Airflow no Amazon MWAA](configuring-env-variables.md).
**Contents**
+ [Como adicionar uma opção de configuração do Apache Airflow](#best-practices-tuning-console-add)
+ [Agendador do Apache Airflow](#best-practices-tuning-scheduler)
+ [Parâmetros](#best-practices-tuning-scheduler-params)
+ [Limites](#best-practices-tuning-scheduler-limits)
+ [Pastas do DAG](#best-practices-tuning-dag-folders)
+ [Parâmetros](#best-practices-tuning-dag-folders-params)
+ [Arquivos DAG](#best-practices-tuning-dag-files)
+ [Parâmetros](#best-practices-tuning-dag-files-params)
+ [Tarefas](#best-practices-tuning-tasks)
+ [Parâmetros](#best-practices-tuning-tasks-params)
## Como adicionar uma opção de configuração do Apache Airflow
Use o procedimento a seguir para adicionar uma opção de configuração do Airflow ao seu ambiente.
1. Abra a [página Ambientes](https://console.aws.amazon.com/mwaa/home#/environments) no console do Amazon MWAA.
1. Escolha um ambiente.
1. Escolha **Editar**.
1. Escolha **Próximo**.
1. Escolha **Adicionar configuração personalizada** no painel **Opções de configuração do Airflow**.
1. Escolha uma configuração na lista suspensa e insira um valor, ou digite uma configuração personalizada e insira um valor.
1. Escolha **Adicionar configuração personalizada** para cada configuração que você deseja adicionar.
1. Escolha **Salvar**.
Consulte [Como usar opções de configuração do Apache Airflow no Amazon MWAA](configuring-env-variables.md) para saber mais.
## Agendador do Apache Airflow
O agendador do Apache Airflow é um componente central do Apache Airflow. Um problema com o agendador pode DAGs impedir a análise e o agendamento de tarefas. Para obter mais informações sobre o ajuste do agendador do Apache Airflow, consulte [Ajustar o desempenho do agendador](https://airflow.apache.org/docs/apache-airflow/2.2.2/concepts/scheduler.html#fine-tuning-your-scheduler-performance) no site de documentação do Apache Airflow.
### Parâmetros
Esta seção descreve as opções de configuração disponíveis para o agendador do Apache Airflow (Apache Airflow v2 e versões posteriores) e os respectivos casos de uso.
------
#### [ Apache Airflow v3 ]
| Configuração | Caso de uso |
| --- | --- |
| **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** O número de processos que o Celery Executor usa para sincronizar o estado da tarefa. **Padrão**: 1 | Você pode usar essa opção para evitar conflitos de fila limitando os processos que o Celery Executor usa. Por padrão, um valor é definido como `1` para evitar erros na entrega de registros de tarefas ao CloudWatch Logs. Definir o valor como `0` significa usar o número máximo de processos, mas pode causar erros ao entregar logs de tarefas. |
| **[scheduler.scheduler\$1idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#scheduler-idle-sleep-time)** O número de segundos de espera entre o processamento consecutivo do arquivo DAG no “loop” do agendador. **Padrão**: 1 | Você pode usar essa opção para liberar o uso da CPU no agendador ao **aumentar** o tempo de inatividade do agendador após terminar de recuperar os resultados da análise do DAG, localizar e enfileirar tarefas e executar tarefas em fila no *Executor*. Aumentar esse valor consome o número de threads do agendador executados em um ambiente em `dag_processor.parsing_processes` para o Apache Airflow v2 e para o Apache Airflow v3. Isso pode reduzir a capacidade de análise DAGs dos agendadores e aumentar o tempo necessário DAGs para serem preenchidos no servidor web. |
| **[scheduler.max\$1dagruns\$1to\$1create\$1per\$1loop](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#max-dagruns-to-create-per-loop)** O número máximo de DAGs a serem criados *DagRuns*por “loop” do agendador. **Padrão**: 10 | Você pode usar essa opção para liberar recursos para agendar tarefas **diminuindo** o número máximo de *DagRuns*“loop” do agendador. |
| **[dag\$1processor.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parsing-processes)** O número de threads que o agendador pode executar paralelamente ao agendamento DAGs. **Padrão:** usar `(2 * number of vCPUs) - 1` | Você pode usar essa opção para liberar recursos **diminuindo** o número de processos que o agendador executa paralelamente para analisar. DAGs Recomendamos manter esse número baixo se a análise do DAG estiver afetando o agendamento de tarefas. Você **deve** especificar um valor menor que a contagem de vCPUs em seu ambiente. Consulte [Limites](#best-practices-tuning-scheduler-limits) para saber mais. |
------
#### [ Apache Airflow v2 ]
| Configuração | Caso de uso |
| --- | --- |
| **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** O número de processos que o Celery Executor usa para sincronizar o estado da tarefa. **Padrão**: 1 | Você pode usar essa opção para evitar conflitos de fila limitando os processos que o Celery Executor usa. Por padrão, um valor é definido como `1` para evitar erros na entrega de registros de tarefas ao CloudWatch Logs. Definir o valor como `0` significa usar o número máximo de processos, mas pode causar erros ao entregar logs de tarefas. |
| **[scheduler.idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#scheduler-idle-sleep-time)** O número de segundos de espera entre o processamento consecutivo do arquivo DAG no “loop” do agendador. **Padrão**: 1 | Você pode usar essa opção para liberar o uso da CPU no agendador ao **aumentar** o tempo de inatividade do agendador após terminar de recuperar os resultados da análise do DAG, localizar e enfileirar tarefas e executar tarefas em fila no *Executor*. Aumentar esse valor consome o número de threads do agendador executados em um ambiente em `scheduler.parsing_processes` para o Apache Airflow v2 e para o Apache Airflow v3. Isso pode reduzir a capacidade de análise DAGs dos agendadores e aumentar o tempo necessário DAGs para serem preenchidos no servidor web. |
| **[scheduler.max\$1dagruns\$1to\$1create\$1per\$1loop](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#max-dagruns-to-create-per-loop)** O número máximo de DAGs a serem criados *DagRuns*por “loop” do agendador. **Padrão**: 10 | Você pode usar essa opção para liberar recursos para agendar tarefas **diminuindo** o número máximo de *DagRuns*“loop” do agendador. |
| **[scheduler.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes)** O número de threads que o agendador pode executar paralelamente ao agendamento DAGs. **Padrão:** usar `(2 * number of vCPUs) - 1` | Você pode usar essa opção para liberar recursos **diminuindo** o número de processos que o agendador executa paralelamente para analisar. DAGs Recomendamos manter esse número baixo se a análise do DAG estiver afetando o agendamento de tarefas. Você **deve** especificar um valor menor que a contagem de vCPUs em seu ambiente. Consulte [Limites](#best-practices-tuning-scheduler-limits) para saber mais. |
------
### Limites
Esta seção descreve os limites que você deve considerar ao ajustar os parâmetros padrão do agendador.
**scheduler.parsing\$1processes, scheduler.max\$1threads (somente v2)**
Dois threads são permitidos por vCPU para uma classe de ambiente. Pelo menos um thread deve ser reservado para o agendador de uma classe de ambiente. Se você notar um atraso no agendamento de tarefas, talvez seja necessário aumentar sua [classe de ambiente](environment-class.md). Por exemplo, um ambiente grande tem uma instância de contêiner Fargate de 4 vCPUs para seu agendador. Isso significa que um máximo total de `7` threads está disponível para uso em outros processos. Ou seja, dois threads multiplicaram quatro vCPUs, menos um para o próprio agendador. O valor que você especifica em `scheduler.max_threads` (somente v2) e `scheduler.parsing_processes` não pode exceder o número de threads disponíveis para uma classe de ambiente, conforme mostrado:
+ **mw1.small**: não deve exceder `1` thread para outros processos. O thread restante é reservado para o agendador.
+ **mw1.medium**: não deve exceder `3` threads de outros processos. O thread restante é reservado para o agendador.
+ **mw1.large**: não deve exceder `7` threads de outros processos. O thread restante é reservado para o agendador.
## Pastas do DAG
O agendador do Apache Airflow verifica continuamente a pasta em seu ambiente. DAGs Quaisquer arquivos `plugins.zip` contidos ou arquivo Python (`.py`) contendo instruções de importação “airflow”. Todos os objetos Python DAG resultantes são então colocados em um arquivo *DagBag*para que esse arquivo seja processado pelo agendador para determinar quais tarefas, se houver, precisam ser agendadas. A análise do arquivo Dag ocorre independentemente de os arquivos conterem objetos DAG viáveis.
### Parâmetros
Esta seção descreve as opções de configuração disponíveis para a DAGs pasta (Apache Airflow v2 e versões posteriores) e seus casos de uso.
------
#### [ Apache Airflow v3 ]
| Configuração | Caso de uso |
| --- | --- |
| **[dag\$1processor.refresh\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#config-dag-processor-refresh-interval)** O número de segundos em que a DAGs pasta deve ser examinada em busca de novos arquivos. **Padrão:** 300 segundos | Você pode usar essa opção para liberar recursos **aumentando** o número de segundos para analisar a DAGs pasta. Recomendamos aumentar esse valor se você tiver longos tempos de análise`total_parse_time metrics`, o que pode ser devido a um grande número de arquivos em sua DAGs pasta. |
| **[dag\$1processor.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-file-process-interval)** O número de segundos após os quais o agendador analisa um DAG e as atualizações do DAG são refletidas. **Padrão:** 30 segundos | Você pode usar essa opção para liberar recursos ao **aumentar** o número de segundos que o agendador espera antes de analisar um DAG. Por exemplo, se você especificar um valor de `30`, o arquivo DAG será analisado a cada 30 segundos. Recomendamos manter esse número alto para diminuir o uso da CPU em seu ambiente. |
------
#### [ Apache Airflow v2 ]
| Configuração | Caso de uso |
| --- | --- |
| **[scheduler.dag\$1dir\$1list\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-dir-list-interval)** O número de segundos em que a DAGs pasta deve ser examinada em busca de novos arquivos. **Padrão:** 300 segundos | Você pode usar essa opção para liberar recursos **aumentando** o número de segundos para analisar a DAGs pasta. Recomendamos aumentar esse valor se você tiver longos tempos de análise`total_parse_time metrics`, o que pode ser devido a um grande número de arquivos em sua DAGs pasta. |
| **[scheduler.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-file-process-interval)** O número de segundos após os quais o agendador analisa um DAG e as atualizações do DAG são refletidas. **Padrão:** 30 segundos | Você pode usar essa opção para liberar recursos ao **aumentar** o número de segundos que o agendador espera antes de analisar um DAG. Por exemplo, se você especificar um valor de `30`, o arquivo DAG será analisado a cada 30 segundos. Recomendamos manter esse número alto para diminuir o uso da CPU em seu ambiente. |
------
## Arquivos DAG
Como parte do loop do agendador do Apache Airflow, arquivos DAG individuais são analisados para extrair objetos do DAG Python. No Apache Airflow v2 e versões posteriores, o agendador analisa um número máximo de [processos de análise](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes) ao mesmo tempo. O número de segundos especificado em `scheduler.min_file_process_interval` (v2) ou `dag_processor.min_file_process_interval` (v3) deve passar antes que o mesmo arquivo seja analisado novamente.
### Parâmetros
Esta seção descreve as opções de configuração disponíveis para os arquivos DAG do Apache Airflow (Apache Airflow v2 e versões posteriores) e os respectivos casos de uso.
------
#### [ Apache Airflow v3 ]
| Configuração | Caso de uso |
| --- | --- |
| **[dag\$1processor.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dag-file-processor-timeout)** O número de segundos antes do *DagFileProcessor*tempo limite de processamento de um arquivo DAG. **Padrão:** 50 segundos | Você pode usar essa opção para liberar recursos **aumentando** o tempo necessário antes que o tempo limite seja *DagFileProcessor*atingido. Recomendamos aumentar esse valor se você tiver tempos limite nos registros de processamento do DAG que resultem em impossibilidade DAGs de carregamento. |
| **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dagbag-import-timeout)** O tempo limite do número de segundos antes de importar um arquivo do Python. **Padrão:** 30 segundos | Você pode usar essa opção para liberar recursos ao **aumentar** o tempo necessário até que o agendador atinja o tempo limite ao importar um arquivo Python para extrair os objetos DAG. Essa opção é processada como parte do “loop” do agendador e deve conter um valor menor que o valor especificado em `dag_processor.dag_file_processor_timeout`. |
| **[core.min\$1serialized\$1dag\$1update\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-serialized-dag-update-interval)** O número mínimo de segundos após o qual os serializados DAGs no banco de dados são atualizados. **Padrão:** 30 | Você pode usar essa opção para liberar recursos **aumentando** o número de segundos após os quais os serializados DAGs no banco de dados são atualizados. Recomendamos aumentar esse valor se você tiver um número DAGs grande ou complexo DAGs. Aumentar esse valor reduz a carga no agendador e no banco de dados à medida que DAGs são serializados. |
| **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-serialized-dag-fetch-interval)** O número de segundos em que um DAG serializado é recuperado do banco de dados quando já está carregado no. DagBag **Padrão**: 10 | Você pode usar essa opção para liberar recursos ao **aumentar** o número de segundos em que um DAG serializado é recuperado. O valor deve ser maior que o valor especificado em `core.min_serialized_dag_update_interval` para reduzir as taxas de “gravação” do banco de dados. Aumentar esse valor reduz a carga no servidor web e no banco de dados à medida que DAGs são serializados. |
------
#### [ Apache Airflow v2 ]
| Configuração | Caso de uso |
| --- | --- |
| **[core.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-file-processor-timeout)** O número de segundos antes do *DagFileProcessor*tempo limite de processamento de um arquivo DAG. **Padrão:** 50 segundos | Você pode usar essa opção para liberar recursos **aumentando** o tempo necessário antes que o tempo limite seja *DagFileProcessor*atingido. Recomendamos aumentar esse valor se você tiver tempos limite nos registros de processamento do DAG que resultem em impossibilidade DAGs de carregamento. |
| **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dagbag-import-timeout)** O tempo limite do número de segundos antes de importar um arquivo do Python. **Padrão:** 30 segundos | Você pode usar essa opção para liberar recursos ao **aumentar** o tempo necessário até que o agendador atinja o tempo limite ao importar um arquivo Python para extrair os objetos DAG. Essa opção é processada como parte do “loop” do agendador e deve conter um valor menor que o valor especificado em `core.dag_file_processor_timeout`. |
| **[core.min\$1serialized\$1dag\$1update\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-serialized-dag-update-interval)** O número mínimo de segundos após o qual os serializados DAGs no banco de dados são atualizados. **Padrão:** 30 | Você pode usar essa opção para liberar recursos **aumentando** o número de segundos após os quais os serializados DAGs no banco de dados são atualizados. Recomendamos aumentar esse valor se você tiver um número DAGs grande ou complexo DAGs. Aumentar esse valor reduz a carga no agendador e no banco de dados à medida que DAGs são serializados. |
| **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-serialized-dag-fetch-interval)** O número de segundos em que um DAG serializado é recuperado do banco de dados quando já está carregado no. DagBag **Padrão**: 10 | Você pode usar essa opção para liberar recursos ao **aumentar** o número de segundos em que um DAG serializado é recuperado. O valor deve ser maior que o valor especificado em `core.min_serialized_dag_update_interval` para reduzir as taxas de “gravação” do banco de dados. Aumentar esse valor reduz a carga no servidor web e no banco de dados à medida que DAGs são serializados. |
------
## Tarefas
Tanto o agendador quanto os operadores do Apache Airflow estão envolvidos em tarefas de enfileiramento e desenfileiramento. O agendador leva as tarefas analisadas prontas para serem agendadas de um status **vazio** para um status **agendado**. O executor, também em execução no contêiner do agendador no Fargate, coloca essas tarefas em fila e define o status como **Em fila.** Quando os operadores têm capacidade, retiram a tarefa da fila e definem o status como **executando**, que posteriormente muda o status para **Êxito** ou **Falha** com base no sucesso ou falha da tarefa.
### Parâmetros
Esta seção descreve as opções de configuração disponíveis para tarefas do Apache Airflow e os casos de uso delas.
As opções de configuração padrão que o Amazon MWAA substitui estão marcadas em. *red*
------
#### [ Apache Airflow v3 ]
| Configuração | Caso de uso |
| --- | --- |
| **[core.parallelism](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** O número máximo de instâncias de tarefas que podem ter o status `Running`. **Padrão:** definido dinamicamente com base em `(maxWorkers * maxCeleryWorkers) / schedulers * 1.5`. | Você pode usar essa opção para liberar recursos ao **aumentar** o número de instâncias de tarefas que podem ser executadas simultaneamente. O valor especificado deve ser o número de operadores disponíveis multiplicado pela densidade de tarefas dos operadores. Recomendamos alterar esse valor somente quando houver um grande número de tarefas bloqueadas no estado “Em execução” ou “Em fila”. |
| **[core.execute\$1tasks\$1new\$1python\$1interpreter](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#execute-tasks-new-python-interpreter)** Determina se o Apache Airflow executa tarefas bifurcando o processo principal ou criando um processo em Python. **Padrão**: `True` | Quando definido como `True`, o Apache Airflow reconhece as alterações feitas nos seus plug-ins como um novo processo Python criado para executar tarefas. |
| **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** O Amazon MWAA substitui a instalação básica do Airflow por essa opção para escalar operadores como parte de seu componente de ajuste de escala automático. **Padrão:** não aplicável | *Any value specified for this option is ignored.* |
| **[celery.worker\$1autoscale](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-autoscale)** A simultaneidade de tarefas para operadores. **Padrões:** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/mwaa/latest/userguide/best-practices-tuning.html) | Você pode usar essa opção para liberar recursos ao **reduzir** a simultaneidade `minimum`, `maximum` de tarefas dos operadores. Os trabalhadores aceitam até as tarefas `maximum` simultâneas configuradas, independentemente de haver recursos suficientes para fazer isso. Se as tarefas forem agendadas sem recursos suficientes, elas falharão imediatamente. Recomendamos alterar esse valor em tarefas que consomem muitos recursos ao reduzir os valores para serem menores que os padrões a fim de permitir mais capacidade por tarefa. |
------
#### [ Apache Airflow v2 ]
| Configuração | Caso de uso |
| --- | --- |
| **[core.parallelism](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** O número máximo de instâncias de tarefas que podem ter o status `Running`. **Padrão:** definido dinamicamente com base em `(maxWorkers * maxCeleryWorkers) / schedulers * 1.5`. | Você pode usar essa opção para liberar recursos ao **aumentar** o número de instâncias de tarefas que podem ser executadas simultaneamente. O valor especificado deve ser o número de operadores disponíveis multiplicado pela densidade de tarefas dos operadores. Recomendamos alterar esse valor somente quando houver um grande número de tarefas bloqueadas no estado “Em execução” ou “Em fila”. |
| **[core.dag\$1concurrency](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-concurrency)** O número de instâncias de tarefas que podem ser executadas simultaneamente para cada DAG. **Padrão:** 10000 | Você pode usar essa opção para liberar recursos ao **aumentar** o número de instâncias de tarefas autorizadas a serem executadas simultaneamente. Por exemplo, se você tiver cem DAGs com dez tarefas paralelas e quiser que todas DAGs sejam executadas simultaneamente, você pode calcular o paralelismo máximo como o número de trabalhadores disponíveis multiplicado pela densidade de tarefas do trabalhador em`celery.worker_concurrency`, dividido pelo número de. DAGs |
| **[core.execute\$1tasks\$1new\$1python\$1interpreter](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#execute-tasks-new-python-interpreter)** Determina se o Apache Airflow executa tarefas bifurcando o processo principal ou criando um processo em Python. **Padrão**: `True` | Quando definido como `True`, o Apache Airflow reconhece as alterações feitas nos seus plug-ins como um novo processo Python criado para executar tarefas. |
| **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** O Amazon MWAA substitui a instalação básica do Airflow por essa opção para escalar operadores como parte de seu componente de ajuste de escala automático. **Padrão:** não aplicável | *Any value specified for this option is ignored.* |
| **[celery.worker\$1autoscale](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-autoscale)** A simultaneidade de tarefas para operadores. **Padrões:** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/mwaa/latest/userguide/best-practices-tuning.html) | Você pode usar essa opção para liberar recursos ao **reduzir** a simultaneidade `minimum`, `maximum` de tarefas dos operadores. Os trabalhadores aceitam até as tarefas `maximum` simultâneas configuradas, independentemente de haver recursos suficientes para fazer isso. Se as tarefas forem agendadas sem recursos suficientes, elas falharão imediatamente. Recomendamos alterar esse valor em tarefas que consomem muitos recursos ao reduzir os valores para serem menores que os padrões a fim de permitir mais capacidade por tarefa. |
------
# Como gerenciar dependências do Python em requirements.txt
Este tópico descreve como instalar e gerenciar dependências do Python em um arquivo `requirements.txt` para um ambiente Amazon Managed Workflows for Apache Airflow.
**Contents**
+ [Teste DAGs usando o utilitário Amazon MWAA CLI](#best-practices-dependencies-cli-utility)
+ [Instalando dependências do Python usando o formato de arquivo de requisitos PyPi .org](#best-practices-dependencies-different-ways)
+ [Opção 1: dependências do Python do Python Package Index](#best-practices-dependencies-pip-extras)
+ [Opção dois: wheel do Python (.whl)](#best-practices-dependencies-python-wheels)
+ [Como usar o arquivo `plugins.zip` em um bucket do Amazon S3](#best-practices-dependencies-python-wheels-s3)
+ [Como usar um arquivo WHL hospedado em uma URL](#best-practices-dependencies-python-wheels-url)
+ [Como criar arquivos WHL a partir de um DAG](#best-practices-dependencies-python-wheels-dag)
+ [Opção três: dependências do Python hospedadas em um repositório privado PyPi compatível com /PEP-503](#best-practices-dependencies-custom-auth-url)
+ [Como habilitar logs no console do Amazon MWAA](#best-practices-dependencies-troubleshooting-enable)
+ [Acessando registros no console CloudWatch de registros](#best-practices-dependencies-troubleshooting-view)
+ [Como acessar erros na IU do Apache Airflow](#best-practices-dependencies-troubleshooting-aa)
+ [Login no Apache Airflow](#airflow-access-and-login)
+ [Cenários de exemplo de `requirements.txt`](#best-practices-dependencies-ex-mix-match)
## Teste DAGs usando o utilitário Amazon MWAA CLI
+ O utilitário da interface de linha de comandos (CLI) replica localmente um ambiente do Amazon Managed Workflows for Apache Airflow.
+ A CLI cria localmente uma imagem de contêiner Docker semelhante a uma imagem de produção do Amazon MWAA. Você pode usar isso para executar um ambiente Apache Airflow local para desenvolver e DAGs testar plug-ins e dependências personalizados antes da implantação no Amazon MWAA.
+ Para executar a CLI, consulte on. [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images) GitHub
## Instalando dependências do Python usando o formato de arquivo de requisitos PyPi .org
A seção a seguir descreve as diferentes maneiras de instalar dependências do Python de acordo com o Formato de Arquivo de [Requisitos PyPi](https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format) .org.
### Opção 1: dependências do Python do Python Package Index
A seção a seguir descreve como especificar dependências do Python do [Python Package Index](https://pypi.org/) em um arquivo `requirements.txt`.
------
#### [ Apache Airflow v3 ]
1. **Testar localmente**. Adicione bibliotecas adicionais de forma iterativa para encontrar a combinação certa de pacotes e suas versões, antes de criar um arquivo `requirements.txt`. Para executar o utilitário Amazon MWAA CLI, consulte on. [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images) GitHub
1. **Revise os extras do pacote Apache Airflow**. Para acessar uma lista dos pacotes instalados para o Apache Airflow v3 no Amazon MWAA, consulte no site. [aws-mwaa-docker-images `requirements.txt`](https://github.com/aws/amazon-mwaa-docker-images/blob/main/requirements.txt) GitHub
1. **Adicione uma declaração de restrições**. Adicione o arquivo de restrições do seu ambiente Apache Airflow v3 na parte superior do seu arquivo. `requirements.txt` Os arquivos de restrições do Apache Airflow especificam as versões do provedor disponíveis no momento de um lançamento do Apache Airflow.
No exemplo a seguir, substitua *\$1environment-version\$1* pelo número da versão do seu ambiente e *\$1Python-version\$1* pela versão do Python compatível com seu ambiente.
Para obter informações sobre a versão do Python compatível com o ambiente do Apache Airflow, consulte [Versões do Apache Airflow](airflow-versions.md#airflow-versions-official).
```
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"
```
Se o arquivo de restrições determinar que o pacote `xyz==1.0` não é compatível com outros pacotes em seu ambiente, `pip3 install` não conseguirá impedir que bibliotecas incompatíveis sejam instaladas em seu ambiente. Se a instalação falhar em qualquer pacote, você poderá acessar os registros de erros de cada componente do Apache Airflow (o agendador, o trabalhador e o servidor web) no fluxo de log correspondente em Logs. CloudWatch Para obter mais informações sobre tipos de log, consulte [Acessando registros do Airflow na Amazon CloudWatch](monitoring-airflow.md).
1. **Pacotes do Apache Airflow**. Adicione os [extras do pacote](http://airflow.apache.org/docs/apache-airflow/2.5.1/extra-packages-ref.html) e a versão (`==`). Isso ajuda a evitar que pacotes com o mesmo nome, mas com versões diferentes, sejam instalados em seu ambiente.
```
apache-airflow[package-extra]==2.5.1
```
1. **Bibliotecas Python**. Adicione o nome do pacote e a versão (`==`) em seu arquivo `requirements.txt`. Isso ajuda a evitar que uma atualização futura de última hora do [PyPidomínio.org](https://pypi.org) seja aplicada automaticamente.
```
library == version
```
**Example Boto3 e psycopg2-binary**
Esse exemplo de código é fornecido para fins de demonstração. As bibliotecas boto e psycopg2-binary estão incluídas na instalação básica do Apache Airflow v3 e não precisam ser especificadas em um arquivo `requirements.txt`.
```
boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6
```
[Se um pacote for especificado sem uma versão, o Amazon MWAA instalará a versão mais recente do pacote em .org. PyPi](https://pypi.org) Essa versão pode entrar em conflito com outros pacotes em seu `requirements.txt`.
------
#### [ Apache Airflow v2 ]
1. **Testar localmente**. Adicione bibliotecas adicionais de forma iterativa para encontrar a combinação certa de pacotes e suas versões, antes de criar um arquivo `requirements.txt`. Para executar o utilitário Amazon MWAA CLI, consulte on. [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images) GitHub
1. **Revise os extras do pacote Apache Airflow**. Para acessar uma lista dos pacotes instalados para o Apache Airflow v2 no Amazon MWAA, acesse no site. [aws-mwaa-docker-images `requirements.txt`](https://github.com/aws/amazon-mwaa-docker-images/blob/main/requirements.txt) GitHub
1. **Adicione uma declaração de restrições**. Adicione o arquivo de restrições do seu ambiente Apache Airflow v2 na parte superior do seu arquivo `requirements.txt`. Os arquivos de restrições do Apache Airflow especificam as versões do provedor disponíveis no momento de um lançamento do Apache Airflow.
A partir do Apache Airflow v2.7.2, seu arquivo de requisitos deve incluir uma declaração `--constraint`. Se você não fornecer uma restrição, o Amazon MWAA especificará uma para garantir que os pacotes listados em seus requisitos sejam compatíveis com a versão do Apache Airflow que você está usando.
No exemplo a seguir, substitua *\$1environment-version\$1* pelo número da versão do seu ambiente e *\$1Python-version\$1* pela versão do Python compatível com seu ambiente.
Para obter informações sobre a versão do Python compatível com o ambiente do Apache Airflow, consulte [Versões do Apache Airflow](airflow-versions.md#airflow-versions-official).
```
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"
```
Se o arquivo de restrições determinar que o pacote `xyz==1.0` não é compatível com outros pacotes em seu ambiente, `pip3 install` não conseguirá impedir que bibliotecas incompatíveis sejam instaladas em seu ambiente. Se a instalação falhar em qualquer pacote, você poderá acessar os registros de erros de cada componente do Apache Airflow (o agendador, o trabalhador e o servidor web) no fluxo de log correspondente em Logs. CloudWatch Para obter mais informações sobre tipos de log, consulte [Acessando registros do Airflow na Amazon CloudWatch](monitoring-airflow.md).
1. **Pacotes do Apache Airflow**. Adicione os [extras do pacote](http://airflow.apache.org/docs/apache-airflow/2.5.1/extra-packages-ref.html) e a versão (`==`). Isso ajuda a evitar que pacotes com o mesmo nome, mas com versões diferentes, sejam instalados em seu ambiente.
```
apache-airflow[package-extra]==2.5.1
```
1. **Bibliotecas Python**. Adicione o nome do pacote e a versão (`==`) em seu arquivo `requirements.txt`. Isso ajuda a evitar que uma atualização futura de última hora do [PyPidomínio.org](https://pypi.org) seja aplicada automaticamente.
```
library == version
```
**Example Boto3 e psycopg2-binary**
Esse exemplo de código é fornecido para fins de demonstração. As bibliotecas boto e psycopg2-binary estão incluídas na instalação básica do Apache Airflow v2 e não precisam ser especificadas em um arquivo `requirements.txt`.
```
boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6
```
[Se um pacote for especificado sem uma versão, o Amazon MWAA instalará a versão mais recente do pacote em .org. PyPi](https://pypi.org) Essa versão pode entrar em conflito com outros pacotes em seu `requirements.txt`.
------
### Opção dois: wheel do Python (.whl)
O wheel do Python é um formato de pacote projetado para enviar bibliotecas com artefatos compilados. Há vários benefícios em usar pacotes wheel como um método para instalar dependências no Amazon MWAA:
+ **Instalação mais rápida**: os arquivos WHL são copiados para o contêiner como um único ZIP e depois instalados localmente, sem precisar baixar um por um.
+ **Menos conflitos**: você pode determinar a compatibilidade de versões de seus pacotes com antecedência. Como resultado, não há necessidade de `pip` para elaborar recursivamente versões compatíveis.
+ **Mais resiliência**: com bibliotecas hospedadas externamente, os requisitos posteriores podem mudar, resultando em incompatibilidade de versões entre contêineres em um ambiente do Amazon MWAA. Por não depender de uma fonte externa para dependências, cada contêiner tem as mesmas bibliotecas, independentemente de quando cada contêiner é instanciado.
Recomendamos os seguintes métodos para instalar dependências do Python a partir de um arquivo wheel do Python (`.whl`) no seu arquivo `requirements.txt`.
**Topics**
+ [Como usar o arquivo `plugins.zip` em um bucket do Amazon S3](#best-practices-dependencies-python-wheels-s3)
+ [Como usar um arquivo WHL hospedado em uma URL](#best-practices-dependencies-python-wheels-url)
+ [Como criar arquivos WHL a partir de um DAG](#best-practices-dependencies-python-wheels-dag)
#### Como usar o arquivo `plugins.zip` em um bucket do Amazon S3
O agendador, os trabalhadores e o servidor web do Apache Airflow (para o Apache Airflow v2.2.2 e versões posteriores) pesquisam plug-ins personalizados durante a inicialização no contêiner Fargate gerenciado para seu ambiente em. AWS`/usr/local/airflow/plugins/*` Esse processo começa antes de `pip3 install -r requirements.txt` do Amazon MWAA para as dependências do Python e da inicialização do serviço no Apache Airflow. Um `plugins.zip` arquivo pode ser usado para qualquer arquivo que você não queira que seja alterado continuamente durante a execução do ambiente ou que não queira conceder acesso aos usuários que escrevem DAGs. Por exemplo, arquivos de wheel de biblioteca Python, arquivos PEM de certificado e arquivos YAML de configuração.
A seção a seguir descreve como instalar um wheel que está no arquivo `plugins.zip` em seu bucket do Amazon S3.
1. **Baixe os arquivos WHL necessários**. Você pode usar [https://pip.pypa.io/en/stable/cli/pip_download/](https://pip.pypa.io/en/stable/cli/pip_download/)com os existentes `requirements.txt` no Amazon MWAA ou em [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)outro contêiner [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2) para resolver e baixar os arquivos Python wheel necessários.
```
pip3 download -r "$AIRFLOW_HOME/dags/requirements.txt" -d "$AIRFLOW_HOME/plugins"
cd "$AIRFLOW_HOME/plugins"
zip "$AIRFLOW_HOME/plugins.zip" *
```
1. **Especifique o caminho em seu `requirements.txt`**. Especifique o diretório de plug-ins na parte superior do seu requirements.txt usando [https://pip.pypa.io/en/stable/cli/pip_install/#install-find-links](https://pip.pypa.io/en/stable/cli/pip_install/#install-find-links) e instrua `pip` a não instalar de outras fontes usando [https://pip.pypa.io/en/stable/cli/pip_install/#install-no-index](https://pip.pypa.io/en/stable/cli/pip_install/#install-no-index), conforme mostrado no seguinte código:
```
--find-links /usr/local/airflow/plugins
--no-index
```
**Example wheel em requirements.txt**
O exemplo a seguir pressupõe que você tenha carregado o wheel em um arquivo `plugins.zip` na raiz do seu bucket do Amazon S3. Por exemplo:
```
--find-links /usr/local/airflow/plugins
--no-index
numpy
```
O Amazon MWAA busca o wheel `numpy-1.20.1-cp37-cp37m-manylinux1_x86_64.whl` da pasta `plugins` e o instala em seu ambiente.
#### Como usar um arquivo WHL hospedado em uma URL
A seção a seguir descreve como instalar um wheel hospedado em uma URL. A URL deve ser acessível publicamente ou de dentro do Amazon VPC personalizado que você especificou para seu ambiente do Amazon MWAA.
+ **Forneça um URL**. Forneça o URL de um wheel em seu arquivo `requirements.txt`.
**Example arquivo wheel em um URL público**
O exemplo a seguir baixa um wheel de um site público.
```
--find-links https://files.pythonhosted.org/packages/
--no-index
```
O Amazon MWAA busca o wheel a partir da URL que você especificou e a instala em seu ambiente.
**nota**
URLs não são acessíveis a partir de servidores web privados, instalando os requisitos no Amazon MWAA v2.2.2 e versões posteriores.
#### Como criar arquivos WHL a partir de um DAG
Caso você tenha um servidor Web privado que use o Apache Airflow v2.2.2 ou versões posteriores e não consiga instalar os requisitos porque seu ambiente não tem acesso a repositórios externos, é possível usar o seguinte DAG para obter seus requisitos existentes do Amazon MWAA e empacotá-los no Amazon S3:
```
from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from airflow.utils.dates import days_ago
S3_BUCKET = 'my-s3-bucket'
S3_KEY = 'backup/plugins_whl.zip'
with DAG(dag_id="create_whl_file", schedule_interval=None, catchup=False, start_date=days_ago(1)) as dag:
cli_command = BashOperator(
task_id="bash_command",
bash_command=f"mkdir /tmp/whls;pip3 download -r /usr/local/airflow/requirements/requirements.txt -d /tmp/whls;zip -j /tmp/plugins.zip /tmp/whls/*;aws s3 cp /tmp/plugins.zip s3://amzn-s3-demo-bucket/{S3_KEY}"
)
```
Depois de executar o DAG, use esse novo arquivo como seu `plugins.zip` do Amazon MWAA, opcionalmente, empacotado com outros plug-ins. Em seguida, atualize seus `requirements.txt` precedidos por `--find-links /usr/local/airflow/plugins` e `--no-index` sem adicionar `--constraint`.
Esse método permite que você use as mesmas bibliotecas off-line.
### Opção três: dependências do Python hospedadas em um repositório privado PyPi compatível com /PEP-503
A seção a seguir descreve como instalar um extra do Apache Airflow hospedado em uma URL privada com autenticação.
1. Adicione seu nome de usuário e senha como [opções de configuração do Apache Airflow](configuring-env-variables.md). Por exemplo:
+ `foo.user` : `YOUR_USER_NAME`
+ `foo.pass` : `YOUR_PASSWORD`
1. crie seu arquivo `requirements.txt`. Substitua os espaços reservados no exemplo a seguir pelo seu URL privado e pelo nome de usuário e senha que você adicionou como [opções de configuração do Apache Airflow](configuring-env-variables.md). Por exemplo:
```
--index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com
```
1. adicione outras bibliotecas ao seu arquivo `requirements.txt`. Por exemplo:
```
--index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com
my-private-package==1.2.3
```
## Como habilitar logs no console do Amazon MWAA
A [função de execução](mwaa-create-role.md) do seu ambiente Amazon MWAA precisa de permissão para enviar registros para CloudWatch Logs. Para atualizar as permissões de um perfil de execução, consulte [Perfil de execução do Amazon MWAA](mwaa-create-role.md).
Você pode ativar os logs do Apache Airflow no nível `INFO`, `WARNING`, `ERROR` e `CRITICAL`. Quando você escolhe um nível de log, o Amazon MWAA envia logs desse nível e de todos os níveis mais altos de severidade. Por exemplo, se você habilitar registros no `INFO` nível, o Amazon MWAA enviará `INFO` registros e `WARNING``ERROR`, e níveis de `CRITICAL` log para CloudWatch Logs. Recomendamos habilitar os logs do Apache Airflow no nível `INFO` do agendador para acessar os logs recebidos para `requirements.txt`.
![\[Esta imagem mostra como habilitar logs no nível INFO.\]](http://docs.aws.amazon.com/pt_br/mwaa/latest/userguide/images/mwaa-console-logs-info.png)
## Acessando registros no console CloudWatch de registros
Você pode acessar os logs do Apache Airflow para o agendador que agendar seus fluxos de trabalho e analisar sua pasta `dags`. As etapas a seguir descrevem como abrir o grupo de registros para o agendador no console do Amazon MWAA e acessar os registros do Apache Airflow no console Logs. CloudWatch
**Para acessar os logs para um `requirements.txt`**
1. Abra a [página Ambientes](https://console.aws.amazon.com/mwaa/home#/environments) no console do Amazon MWAA.
1. Escolha um ambiente.
1. Escolha **grupo de logs de agendador do Airflow** no painel **Monitoramento**.
1. Escolha o log `requirements_install_ip` em **Fluxos de logs**.
1. Consulte a lista de pacotes que foram instalados no ambiente em `/usr/local/airflow/.local/bin`. Por exemplo:
```
Collecting appdirs==1.4.4 (from -r /usr/local/airflow/.local/bin (line 1))
Downloading https://files.pythonhosted.org/packages/3b/00/2344469e2084fb28kjdsfiuyweb47389789vxbmnbjhsdgf5463acd6cf5e3db69324/appdirs-1.4.4-py2.py3-none-any.whl
Collecting astroid==2.4.2 (from -r /usr/local/airflow/.local/bin (line 2))
```
1. Analise a lista de pacotes e verifique se algum deles encontrou algum erro durante a instalação. Se algo der errado, pode ocorrer um erro semelhante ao seguinte:
```
2021-03-05T14:34:42.731-07:00
No matching distribution found for LibraryName==1.0.0 (from -r /usr/local/airflow/.local/bin (line 4))
No matching distribution found for LibraryName==1.0.0 (from -r /usr/local/airflow/.local/bin (line 4))
```
## Como acessar erros na IU do Apache Airflow
Você também pode verificar sua IU do Apache Airflow para identificar se um erro pode estar relacionado a outro problema. O erro mais comum que você pode encontrar com o Apache Airflow no Amazon MWAA é:
```
Broken DAG: No module named x
```
Se ocorrer esse erro na IU do Apache Airflow, provavelmente está faltando uma dependência necessária em seu arquivo `requirements.txt`.
### Login no Apache Airflow
Você precisa de [Política de acesso ao Apache Airflow UI: Amazon MWAAWeb ServerAccess](access-policies.md#web-ui-access) permissões para que seu Conta da AWS in AWS Identity and Access Management (IAM) acesse sua interface de usuário do Apache Airflow.
**Para acessar sua IU do Apache Airflow**
1. Abra a [página Ambientes](https://console.aws.amazon.com/mwaa/home#/environments) no console do Amazon MWAA.
1. Escolha um ambiente.
1. Escolha **Abrir a IU do Airflow**.
## Cenários de exemplo de `requirements.txt`
Você pode misturar e combinar diferentes formatos no seu `requirements.txt`. O exemplo a seguir usa uma combinação das diferentes formas de instalar extras.
**Example Extras em PyPi .org e um URL público**
Você precisa usar a `--index-url` opção ao especificar pacotes de PyPi .org, além de pacotes em uma URL pública, como um repositório personalizado compatível com PEP 503. URLs
```
aws-batch == 0.6
phoenix-letter >= 0.3
--index-url http://dist.repoze.org/zope2/2.10/simple
zopelib
```