Configurando azkaban sirius na prática: o que funciona e onde você vai travar
Se você chegou até aqui é porque precisa orquestrar workflows Hadoop ou Spark e não quer perder tempo reinventando a roda. O azkaban sirius é basicamente uma distribuição do Apache Azkaban com ajustes internos que a galera da infraestrutura costuma usar quando o padrão não comporta. A gente vai falar de como botar pra rodar, os problemas que aparecem e o que não está nos manuais.
O que é azkaban sirius e por que escolher ele
O Azkaban original nasceu na LinkedIn como scheduler de workflows Hadoop. O azkaban sirius traz essencialmente a mesma base, mas com pacotes pré-compilados que já vêm com algumas extensões e configurações de produção que exigem menos ajuste manual. Não é um produto diferente, é uma versão curada do mesmo código. Se você quer zero configuração inicial, talvez funcione. Se precisa de customizações profundas, ainda vai mexer no código fonte. Na minha experiência, o diferencial real do azkaban sirius em relação ao Azkaban puro está nos scripts de deploy e no banco de dados embutido. Você consegue subir um ambiente de testes em cerca de 15 minutos. Um ambiente de produção com MySQL e executores distribuídos leva mais ou menos uma hora, dependendo da sua rede interna.
Instalação passo a passo
Vamos direto ao ponto. Baixe o pacote do azkaban sirius do repositório oficial ou do link que seu time compartilha internamente. O arquivo vem como .tar.gz ou .zip, geralmente na faixa de 200 a 300 MB. Extraia o conteúdo em um diretório no seu servidor. O caminho recomendado é /opt/azkabansirius ou algo similar, mas isso é questão de preferência. Entre nessa pasta e você vai encontrar três diretórios principais: executeweb, executor-web e plugins. O executeweb é o servidor web. O executor-web é onde os jobs realmente rodam. Os plugins ficam separados para não poluir o diretório principal.
Configure o banco de dados. O azkaban sirius suporta H2 por padrão, que é bom para testes, mas para produção você precisa do MySQL. Crie um banco vazio, defina um usuário e configure o arquivo conf/azkaban.properties com os dados de conexão. A string de conexão do MySQL precisa ter allowPublicKeyRetrieval=true se você estiver usando a versão 8 ou superior, senão o conector trava na primeira tentativa de login. Aqui vai um problema real que eu encontrei: depois de configurar o MySQL, o script de inicialização do azkaban sirius dá erro silencioso e não popula as tabelas. O log fala "Database initialization failed" mas não mostra qual tabela falhou. A solução foi rodar manualmente o script sql/create-all-sql-2.5.0.sql (ou a versão correspondente ao seu pacote) diretamente no MySQL antes de subir o serviço. Esse detalhe não está documentado em nenhum lugar que eu tenha visto.
Após popular o banco, inicie o servidor web com o comando bin/start-web.sh e depois os executores com bin/start-executor.sh em cada nó onde você quer que jobs sejam executados. A comunicação entre web server e executores é feita via HTTPS e requer que o certificado SSL esteja configurado corretamente. Se pular essa parte, os executores ficam offline e você não entende o porquê.
Configurações que fazem diferença
O arquivo azkaban.properties é onde a mágica acontece. Aqui estão os parâmetros que mais impacto têm: azkaban.default.flow.compiler: Defina como azkaban.flow.DefaultFlowCompiler para o comportamento padrão. Não mude isso sem motivo, porque compiladores alternativos podem quebrar workflows que usam globs em tipos de job mistos.
azkaban.executor.memcheck: Desative isso em ambientes onde os jobs não têm limite de memória definido. O executor cancela fluxos inteiros se um job individual passar do threshold, e isso gera dor de cabeça desnecessária. Sete para false e controle a memória via resource manager do Hadoop/YARN. azkaban.server.maxthreads: O valor padrão é 20. Se você tem mais de 50 workflows concurrentes rodando, aumente para 50 ou 80. Jobs que ficam esperando thread disponível no pool causam timeouts que parecem problemas de rede mas são simplesmente fila saturada.
👉 Clique no botão abaixo para saber mais sobre o assunto!
azkaban.plugin dir: Certifique-se de que o diretório de plugins corresponde exatamente ao que existe no filesystem. Eu perdi duas horas num domingo à noite porque o caminho estava configurado como /opt/plugins em vez de /opt/azkabansirius/plugins. O serviço subia, mas nenhuma extensão carregava.
Estruturas de projeto e types.xml
O azkaban sirius usa um arquivo chamado types.xml na pasta conf para registrar quais types de job estão disponíveis. Se você precisar adicionar um tipo customizado, como um job que chama uma API REST interna, precise registering esse tipo no types.xml e garantir que o plugin correspondente esteja na pasta plugins/. Caso contrário, o workflow é aceito pelo sistema mas falha na execução com erro "unknown job type". Uma armadilha comum: o arquivo types.xml é lido na inicialização do executor, não do web server. Isso significa que se você atualizar o types.xml, precisa reiniciar o executor, não o web server. Reiniciar o web server não resolve. Já vi gente reiniciando o serviço errado e passando meia hora sem entender.
Workflow example
Vamos a um exemplo concreto. Digamos que você tenha três stages: extração de dados de um banco OLTP, transformação com Spark, e carga em um data lake S3. O flow definition fica num arquivo .flow dentro do projeto ZIP que você sobe pela interface web. O arquivo define jobs com IDs, tipos e dependências. Um job de extração usa type command e executa um script SQL export. O job de transformação usa type spark e aponta para o JAR compilado. O job de carga usa type command e executa um aws s3 cp. As dependências são declaradas no campo dependsOn.
Aqui vai algo que poucos mencionam: jobs com type spark no azkaban sirius herdam automaticamente as variáveis de ambiente definidas no flow level. Isso é útil para passar paths de configuração, mas também é perigoso. Se você definir uma variável chamada SPARK_HOME no flow, ela sobrescreve a do sistema. Verifique sempre o que está setado antes de subir um fluxo novo.
Monitoramento e troubleshooting
O log do executor fica em logs/executor.log. O log do web server em logs/azkaban-web-server.log. Ambos seguem o padrão log4j. O problema é que o log do executor é extremamente verboso em modo INFO. Configure para WARN em produção, senão o log cresce cerca de 2 GB por dia em um cluster médio. Um caso específico que me marcou:Jobs que ficavam pendurados no estado PENDING mesmo quando todos os executores estavam online. O motivo era um deadlock na tabela execution_jobs no banco MySQL. O azkaban sirius faz lock pessimista em várias linhas simultaneamente durante a escalada de workflow, e em clusters com muitos jobs paralelos isso gera contenção. A solução foi aumentar o innodb_lock_wait_timeout para 60 segundos e dividir o workflow em subtarefas menores, com no máximo 30 jobs em paralelo por execução.
Limitações e alternativas
O azkaban sirius tem pontos fracos. O primeiro é a ausência de suporte nativo a containers. Se você trabalha com Kubernetes ou Docker, o Azkaban puro já não é ideal, e a versão sirius não corrige isso. Nesse cenário, considere o Airflow ou o Prefect, que têm suporte muito melhor a containers e orquestração moderna. O segundo ponto fraco é a interface web. Ela funciona, mas é datada. Navegar por workflows grandes com centenas de jobs torna a UI lenta, e exports de logs ficam truncados. Não há busca global por job name, por exemplo. Você precisa saber o ID exato da execução para encontrar o log.
O terceiro: o azkaban sirius não escala horizontalmente no lado do web server. Você pode ter múltiplos executores, mas só um web server ativo. Se esse nó cair, todo o schedule para. Para alta disponibilidade, você precisa de um load balancer na frente com health checks e failover manual.
Dica final que economiza tempo
Antes de subir qualquer workflow para produção, ródiga uma validação local usando o modo solo do azkaban sirius. Esse modo roda tudo em um único processo, sem banco externo, e detecta erros de sintaxe no .flow e dependências cíclicas antes que eles estraguem uma execução real. Leva dois minutos e evita dor de cabeça.
