Fala dataholics, mais algumas dicas rápidas que podem ser bastante útil no seu dia a dia, hoje compartilharei 4 maneiras que você pode utilizar para saber em qual ambiente está rodando seu código de forma dinâmica, sem precisar alterar ele para rodar em Desenvolvimento e depois alterar novamente para rodar em Produção, tendo que ajustar sempre os valores das variáveis de controle quando você enviar para o Deploy na sua esteira de CICD.
Apesar de estar citando 4 maneiras, existem outras formas que você pode trabalhar no seu ambiente, não se prenda somente nessas 4, mas espero que alguma delas te ajude.
Já escrevi outro post com tema parecido, dá uma conferida nesse sobre Widgets, a qual é a dica de número 4 desse post.
1 - Variáveis de ambiente configuradas por Cluster
A primeira maneira acredito que seja a mais simples de aplicar, seria utilizando as variáveis de ambiente do seu Cluster Databricks, contudo, você precisa configurar essas variáveis sempre que criar um novo cluster, seja ele All Purpose ou Job Cluster.
Configurei 3 variáveis no cluster, a quantidade de variáveis e nomes é você que decide, usarei nesse exemplo essas 3:
environment - Define se o ambiente é Dev ou Prod, isso pode te ajudar a apontar e referenciar os objetos, storages, origens, destinos de forma simples.
storageroot - Define a Storage Account para aquele ambiente, apontando para o Storage de DEV ou PROD
database - Define qual o Hive default para gravar ou acessar as tabelas, apenas para exemplo, em alguns ambientes existem centenas de databases e essa variável pode não fazer sentido.
Como utilizar?
Basta resgatar os valores e para facilitar a utilização no código jogar elas em variáveis do seu notebook.
Geralmente em Dev é comum deixar Prints ativos, então com essas variáveis você pode customizar seu código para não precisar reapontar nada quando mudar de DEV para PROD, apenas garanta que os clusters terão as variáveis configuradas.
Note que estou utilizando as variáveis para formar o caminho de onde salvarei minhas informações, esse mesmo código pode ser enviado para produção sem nenhuma modificação.
Esse modelo é útil quando a sua segregação de DEV e PROD não é feita por Workspaces e é realizada no mesmo Worksapace separando por Cluster, então cada cluster recebe as configurações do seu respectivo ambiente.
2 - Azure Tags - Automaticamente adicionadas ao cluster
Essa outra maneira que é usando Tags, é focada para quem separa DEV e PROD com Workspaces diferentes, nesse caso especÃfico não falarei das Tags tradicionais do Cluster, pois, daria na mesma do exemplo 1, precisaria configurar em todos os clusters, com essa maneira que irei te mostrar todo novo cluster já nasce automaticamente com elas.
Utilizar Tags nos seus recursos, independente da Cloud é uma prática muito comum para organização, categorização, separação de cobrança e muitas outras vantagens.
E podemos utilizar essas tags dentro dos nossos clusters também, veja abaixo que criei Tags no meu recurso do Azure (Databricks Worksace):
Imagine que você possui 2 Workspaces de Databricks, 1 para DEV e 1 para PROD, você pode criar tags no Worksapce (recurso), e todos os clusters daquele Workspace vão herdar elas automaticamente.
O seu Cluster Databricks já possui algumas Tags automáticas e quando você tem tags no nÃvel do Recurso\Workspace elas são herdadas automaticamente:
Bom, mas elas não são tão simples de recuperar igual às tags customizadas e tags default, veja como recuperar uma tag default:
Porém, essas tags especificas, ficam apenas dentro do clusterAllTags.
Então, dei um jeitinho de facilitar e recuperar essas tags:
Daqui para frente é seguir o fluxo.
Essa dica pode facilitar sua vida, ao invés de ficar colocando tags\variáreis em cada novo cluster, você define apenas 1 vez no recurso.
3 - Spark Conf - Fixando valor no notebook
Outra maneira, não tão elegante quanto as outras, seria utilizar como referência a Tag OrgId, essa tag identifica o id que fica fixo na sua URL, esse valor é imutável e pode ser uma referência para identificar DEV e PROD também.
Essa dica também é focada para quem separa os ambientes por Workspaces.
4 - Widgets
Conforme mencionei no inÃcio, tenho um post com mais detalhes de como parametrizar utilizando Widgets, sem dúvidas é uma das minhas preferidas.
Utilizar Widgets pode facilitar a parametrização, passando manualmente no notebook ou enviando pela sua ferramenta de orquestração, como Databricks Workflows, Azure Data Factory, Airflow e outros.
Então dessa maneira, independente se você separa os ambientes por Workspaces ou Cluster, você consegue enviar parâmetros de forma mais dinâmica.
Seguem os códigos no github:
Era isso pessoal, espero que te ajude.
Fique bem e até a próxima.
Comentarios