defina as configurações de uma implantação antes de iniciar um job.
Pré-requisitos
Antes de começar, certifique-se de ter:
As permissões necessárias para acessar um namespace e configure recursos do job. Para mais informações, consulte Grant permissions on namespaces.
Uma implantação já criada. Para mais informações, consulte Deploy a job.
configure as definições da implantação
Localize o workspace e clique em Console na coluna Actions.
No painel de navegação à esquerda, escolha O&M > Deployments. Na página Deployments, clique em nome da implantação.
Na aba Configuration, localize a seção a ser edite e clique em Edit no canto superior direito.
-
modifique as configurações nas seções a seguir:
clique em Save.
Básico
Os parâmetros a seguir estão disponíveis na seção Basic. A disponibilidade varia de acordo com o tipo de implantação.
|
Parâmetro |
Tipo de implantação |
Descrição |
|
Engine Version |
SQL, JAR, Python |
A versão do engine Flink a ser usada. |
|
Additional Dependencies |
SQL, JAR, Python |
Arquivos de dependência adicionais para a implantação. |
|
Description |
SQL, JAR, Python |
Uma descrição textual da implantação. |
|
Label |
SQL, JAR, Python |
Rótulos para organizar e identificar a implantação. |
|
JAR Uri |
JAR |
O URI do arquivo JAR a ser execute. |
|
Entry Point Class |
JAR |
O nome totalmente qualificado da classe principal. |
|
Entry Point Main Arguments |
JAR, Python |
Argumentos passados para o ponto de entrada. |
|
Kerberos Name |
JAR, Python |
O nome do principal do Kerberos para autenticação. |
|
Python Uri |
Python |
O URI do arquivo Python a ser execute. |
|
Entry Module |
Python |
O módulo Python a ser usado como ponto de entrada. |
|
Python Libraries |
Python |
Dependências adicionais de bibliotecas Python. |
|
Python Archives |
Python |
Arquivos compactados exigidos pelo job Python. |
Para obter detalhes sobre os parâmetros, consulte Develop an SQL draft (implantações SQL) ou Deploy a job (implantações JAR e Python).
Em implantações SQL, clique em Edit na seção Basic visualize uma mensagem de confirmação. clique em OK para confirme. Você será redirecionado para a página do SQL Editor para edite e implantar novamente a implantação.
Parâmetros
Checkpointing
|
Parâmetro |
Descrição |
|
Checkpointing Interval |
A frequência com que um checkpoint é gerado. Se não for defina, o checkpointing fica desativado. |
|
Checkpointing Timeout time |
O tempo máximo permitido para a conclusão de um checkpoint. Padrão: 10 minutos. Se o checkpoint não for concluído dentro desse tempo, a operação falha. |
|
Min Interval Between Checkpoints |
O intervalo mínimo entre dois checkpoints consecutivos. Quando a paralelização máxima do checkpoint é 1, este parâmetro defina o intervalo mínimo entre os checkpoints. |
Expiração de estado
|
Parâmetro |
Descrição |
|
State Expiration Time |
O tempo de vida (TTL) dos dados de estado de uma implantação. Padrão: 36 h. Dados de estado não acessados dentro desse período são removidos automaticamente do backend de estado, liberando memória. |
O TTL padrão de 36 horas baseia-se nas melhores práticas da alibaba cloud e difere do padrão do Apache Flink, que é 0 (o que significa que os dados de estado nunca expiram). defina o TTL com base nos seus padrões de acesso a dados para equilibrar a precisão da computação e o uso de memória.
Como funcionam os dados de estado:
Quando os dados entram no sistema pela primeira vez, o backend de estado os armazena. Se chegarem dados com a mesma chave primária, o Flink calcula em relação ao estado armazenado e atualiza o horário do último acesso. Caso os dados não sejam acessados novamente dentro do TTL, o Flink os trata como expirados e os remove. Reduzir o TTL diminui o consumo de memória e melhora a estabilidade do sistema, mas pode afetar a precisão para dados que chegam com atraso.
Política de reinicialização
O Flink controla o comportamento de reinicialização do job por meio de dois mecanismos independentes: a política de reinicialização do job e a política de recuperação de falhas da tarefa.
Política de reinicialização do job
A política de reinicialização do job determina se e como o job é reiniciado após uma falha.
Comportamento padrão (quando nenhuma política é defina explicitamente):
Se o checkpointing estiver ativado: o job é reiniciado usando Fixed Delay.
Se o checkpointing estiver desativado: o job não é reiniciado.
Para substituir o padrão, selecione uma destas políticas:
|
Política |
Descrição |
Parâmetros adicionais |
|
No Restarts |
O job não é reiniciado em caso de falha. |
— |
|
Fixed Delay (padrão) |
O job é reiniciado em um intervalo fixo após cada falha. |
Number of Restart Attempts, Delay Between Restart Attempts |
|
Failure Rate |
O job é reiniciado desde que a taxa de falha permaneça abaixo de um limiar defina. |
Failure Rate Interval, Max Failures per Interval, Delay Between Restart Attempts |
Política de recuperação de falhas da tarefa
A política de recuperação de falhas da tarefa determina quais tarefas são reiniciadas quando ocorre uma falha. configure-a defina jobmanager.execution.failover-strategy no campo Other Configuration.
|
Valor |
Comportamento |
|
|
Reinicia todo o job quando qualquer tarefa falha. |
|
|
Reinicia apenas o conjunto mínimo de tarefas necessário para recuperar a região de pipeline com falha, deixando as outras regiões inalteradas. |
Quando o failover-strategy é defina como region, diferentes regiões podem ter timestamps de início distintos após a recuperação — esse é o comportamento esperado. Por exemplo, se um job contiver duas cadeias source-sink sem conexões de dados entre elas e uma tarefa falhar, o Flink reinicia apenas a cadeia que contém a tarefa com falha, enquanto a outra cadeia continua em execução. Os horários de início das duas cadeias serão diferentes, o que é esperado.
Para mais informações, consulte Task Failure Recovery na documentação do Apache Flink.
Outras configurações
Use Other Configuration para defina parâmetros adicionais do Flink como pares chave-valor, por exemplo:
akka.ask.timeout: 10
jobmanager.execution.failover-strategy: fullAs configurações de tipo de GC (como -XX:+UseG1GC) não podem ser modificadas por meio do env.java.opts.
Logging
|
Parâmetro |
Descrição |
|
Log Archiving |
Define se os logs são arquivados. Ativado por padrão. Quando ativado, os logs históricos de implantação ficam disponíveis na aba Logs. No VVR 3.X, apenas o VVR 3.0.7 e versões posteriores oferecem suporte ao arquivamento de logs. No VVR 4.X, apenas o VVR 4.0.11 e versões posteriores oferecem suporte ao arquivamento de logs. Para mais informações, consulte visualize the logs of a historical deployment. |
|
Log Archives Expires |
O tempo de retenção dos logs arquivados. Padrão: 7 dias. |
|
Root Log Level |
O nível mínimo de gravidade para registro em log. Níveis em ordem crescente de urgência: TRACE, DEBUG, INFO, WARN, ERROR. |
|
Log Levels |
Pares personalizados de nome e nível de log para loggers específicos. |
|
Logging Profile |
O modelo de log a ser usado. Selecione default ou Custom Template. O Custom Template permite exportar logs para um armazenamento externo. Para mais informações, consulte Configure parameters to export logs of a deployment. |
Referências
Para controlar o tamanho do estado no nível do operador usando TTL, consulte a seção "State TTL hints" em Hints.
As configurações de log nesta página aplicam-se a uma única implantação. Para configure a exportação de logs para todas as implantações em um namespace, consulte Configure parameters to export logs of a deployment.