Forem: Murilo Menezes Mendonça

Customizando modelos de MLFlow com PyFuncs

Murilo Menezes Mendonça — Thu, 03 Feb 2022 20:53:25 +0000

Se você estuda ou trabalha com ciência de dados e aprendizado de máquina, já deve ter se deparado com alguns problemas de reproducibilidade. Tipo assim, você não consegue treinar de novo um modelo que seja tão bom quanto o que você fez 3 meses atrás. Seja porque em algum momento você usou algum hiperparâmetro diferente, ou porque você não anotou em nenhum lugar qual foi a métrica que você conseguiu com aquele treino aquele dia.

Pode ser que você também tenha tentado serializar um modelo com um framework específico que aplicava sempre o método transform para realizar predições, e aí depois você decidiu mudar de framework e o método de predição era predict e isso acabou quebrando um pouco o fluxo de servir o modelo em produção.

Se isso te parece familiar, a boa notícia é que tem uma ferramenta maravilhosa que ajuda bastante nessa gestão do seu modelo. O Mlflow se define como uma “plataforma de código aberto para o ciclo de vida de Machine Learning”.

Componentes do Mlflow

São 4 os principais componentes do Mlflow, cada um com uma responsabilidade e um benefício próprio. O legal é que você define na sua estrutura o que mais faz sentido utilizar dentre esses componentes, não sendo necessária uma adoção completa de todos.

Mlflow Tracking: uma ferramenta web que te auxilia a registrar os parâmetros, artefatos e métricas de cada execução de treino realizada.
Mlflow Projects: define como criar um ambiente virtual, com a ajuda do Anaconda e executar todos os passos (entry-points) para reproduzir a pipeline da sua execução.
Mlflow Models: “empacota” todos os modelos em um formato único. Também é usado para servir os modelos em produção, construindo uma imagem e subindo um servidor baseado em APIs REST.
Mlflow Registry: Faz a gestão das diferentes versões e estágios do seu modelo, entre Staging até Production ou Arquivado.

Mlflow Models

Existem vários artigos que te ensinam como treinar e registrar um modelo “simples” de Mlflow, usando frameworks conhecidos. Seu código fica mais ou menos assim:

import mlflow
import pandas as pd
from sklearn.datasets import load_iris
from sklearn.ensemble import RandomForestClassifier

with mlflow.start_run():

        mlflow.sklearn.autolog()

        data=load_iris()

        X = pd.DataFrame(data.data, columns=data.feature_names)
        y = pd.DataFrame(data.target, columns=["target"])

        clf = RandomForestClassifier(n_estimators=20)
        clf.fit(X_train, y_train)

        mlflow.end_run()

Percebe que modificamos um código “usual” de treino em 3 linhas? Quando a gente executar esse pedaço de código, o mlflow irá registrar todos os hiperparâmetros, uma série de métricas de aprendizado e também o modelo serializado como um pickle usando o formato padronizado de um modelo de MLflow. Tudo isso vai ficar armazenado no seu servidor de Mlflow Tracking e pronto para ser “empacotado” pra produção. Legal, né?

Mas essa postagem aqui não apareceu pra te ensinar a usar o Mlflow base. Parto do princípio que você pelo menos já mexeu um pouquinho e já adotou, mas precisa saber como construir um modelo customizado.

Customizar um modelo pode ser interessante se você:

Quer que o seu método predict retorne algo além da coluna de predições
Precisa tratar os dados com outros métodos antes de fazer as predições
Quer servir um stack de modelos como um único modelo
Está utilizando algum framework desconhecido pelo Mlflow

Estrutura de PyFuncs

Para construir um modelo customizado, você terá que utilizar o "sabor" pyfunc. Ele é basicamente um wrapper que pode pegar qualquer modelo genérico e transformar em um modelo de MLflow. É importante também destacar que todos os modelos de MLflow herdam a mesma classe base. Ou seja, você, ao trabalhar com PyFuncs, está estendendo as funcionalidades que já foram pré-determinadas no mlflow.sklearn, por exemplo. Mas no fim das contas, o modelo vai seguir o mesmo padrão de encapsulamento.

Isso já garante pra gente uma uniformidade em como realizar as tuas predições. Mesmo que o seu framework utilize o método transform, todos os modelos de Mlflow irão implementar um método predict por padrão.

Para construir uma PyFunc, os imports no começo do código ficam:

import mlflow
import pickle
import cloudpickle

Você vai precisar conhecer um pouco de Programação Orientada a Objetos para poder criar o seu próprio modelo, mas não é difícil. Você vai herdar a classe PythonModel e também vai precisar informar algumas coisas extras, que os frameworks padronizados pelo MLflow e o autologging abstraíam pra você antes.

Vamos começar com um exemplo de como você define um modelo:

import mlflow

class MyModelWrapper(mlflow.pyfunc.PythonModel):

    def load_context(self, context):
        with open(context.artifacts["estimator"], "rb") as f:
            self.model = pickle.load(f)

    def predict(self, context, data):
        return self.model.predict(data)

Os dois métodos acima são necessários no seu wrapper para que você consiga registrar com sucesso seu modelo. Você basicamente irá dizer para o MLflow como carregar o modelo treinado (onde ele está, qual é nome dele) e como realizar as predições.

Imagine que você precisasse carregar um preprocessador antes, chamá-lo para transformar seus dados e só depois realizar as predições. O seu código ficaria assim:

class MyModelWrapper(mlflow.pyfunc.PythonModel):

    def load_context(self, context):
        with open(context.artifacts["preprocessor"], "rb") as f:
            self.preprocessor = pickle.load(f)

        with open(context.artifacts["estimator"], "rb") as f:
            self.model = pickle.load(f)

    def predict(self, context, data):
        transformed_data = self.preprocessor.transform(data)
        return self.model.predict(transformed_data)

Percebe como é flexível? Você precisa basicamente declarar o que muda de uma estrutura padrão de modelo para a sua necessidade. Nesse caso, você pode combinar múltiplos modelos treinados em um único modelo de MLflow, ou como fiz ali em cima, um pre-processador serializado junto com o estimador. Tudo isso vai ser entendido pelo seu "pacote" de modelos de MLflow em um único predict.

Mas... pera! Tá faltando alguma coisa. Como você treina esse modelo? De onde sai esse context.artifacts? 😨

Treinando seu modelo como uma PyFunc

Bom, como você tem mais flexibilidade, você vai ter um trabalinho maior também pra definir seu treino. Apesar de não ser estritamente necessário, recomendo fortemente que você inclua na sua classe MyModelWrapper o médoto fit. Aí você vai conseguir empacotar tudo em um fluxo de trabalho só, e vamos mostrar um exemplo de como fazer. Perceba que no nosso construtor estamos incluindo o preprocessador e o estimador:

class MyModelWrapper(mlflow.pyfunc.PythonModel):

    def __init__(self):

        self.preprocessor = MinMaxScaler()
        self.model = SVC()

    def load_context(self, context):
        with open(context.artifacts["preprocessor"], "rb") as f:
            self.processor = pickle.load(f)
        with open(context.artifacts["estimator"], "rb") as f:
            self.estimator = pickle.load(f)

    def fit(self, data:pd.DataFrame) -> None:
        # Making the splits
        X = data.drop('target', axis=1)
        y = data['target']

        # Training the transformer and scaling the data
        X_scaled = self.preprocessor.fit_transform(data)

        X_train, X_test, y_train, y_test = train_test_split(X_scaled, y, test_size=0.25)

        # Training your model Pipeline
        self.model.fit(X_train, y_train)

        # Evaluating and logging metric with MLFlow
        y_pred = self.model.predict(X_test)
        accuracy = accuracy_score(y_test, y_pred)
        mlflow.log_metric("accuracy", accuracy)

        # Dumping the fitted objects
        with open("fitted_processor.pkl", "wb") as f:
            cloudpickle.dump(self.preprocessor, f)

        with open("fitted_model.pkl", "wb") as f:
            cloudpickle.dump(self.model, f)

    def predict(self, context, data):
        transformed_data = self.preprocessor.transform(data)
        return self.model.predict(transformed_data)

Bom, primeira coisa que eu gostaria de pontuar é que estou utilizando o cloudpickle para persistir os modelos treinados. O MLflow se dá muito bem com esse serializador, e depois você pode usar o pickle para desserializar numa boa. Mas, caso necessário, você pode utilizar o serializador de sua escolha, desde que você ajuste depois o método load_context de acordo. Além disso, mesmo antes de termos definido a nossa execução, já podemos dizer qual métrica queremos acompanhar com o MLFlow.

Pra treinar o algoritmo, você vai precisar definir:

O ambiente de Anaconda para replicar seu experimento
Definir a classe do seu modelo
Definir um dicionário de artefatos
Definir o nome do diretório que contém os artefatos

Vamos ver o código então:

with mlflow.start_run():

    model = MyModelWrapper()

    data = read_data()

    model.fit(data)

    conda_env = "conda.yaml"

    artifacts = {
        "preprocessor" : "fitted_processor.pkl",
        "estimator" : "fitted_model.pkl"
    }

    mlflow.pyfunc.log_model(
        artifact_path='model',
        artifacts=artifacts,
        python_model = model,
        conda_env = conda_env
    )

    mlflow.end_run()

Esse conda.yaml é um arquivo que precisa estar na sua estrutura de execução, na mesma organização de pastas em que você executará o seu módulo de treino.

Além disso, o método fit faz o dump dos objetos serializados no seu diretório local. Então você abre um dicionário chamado artifacts e dá o nome das chaves de cada artefato que você está logando. Perceba que no load_context pegamos justamente os valores das chaves preprocessor e estimator do dicionário artifact. Você também pode adicionar a esse dicionário um plot de gráfico em JPEG ou até mesmo um arquivo CSV com as perdas em cada época da sua rede neural, por exemplo.

Enfim, artefatos servem para que você carregue informação junto com a sua execução de treino lá pro servidor do Mlflow Tracking. Ou mesmo modelos treinados, que precisarão aparecer no seu load_context depois 😄

Fazendo predições

Como comentei mais cedo, todos os modelos que forem registrados como modelos de MLflow terão a mesma estrutura. Seja ele um modelo “padrão”, utilizando frameworks conhecidos, ou mesmo o customizado, como acabamos de ver.

Pra fazer as predições, pra qualquer modelo de MLflow, a gente vai precisar fazer o seguinte:

import mlflow
import pandas as pd

logged_model = 'runs:/<run_id>/<artifact_directory>'
loaded_model = mlflow.pyfunc.load_model(logged_model)

loaded_model.predict(pd.DataFrame(data))

Então, só trocando a run_id você já pode usar o mesmo método de predição. Percebe o valor disso? O que a gente fez foi basicamente editar e estender tanto o que carregar quando eu chamar mlflow.pyfunc.load_model, como também como exatamente realizar as predições, chamando o método padronizado predict.

Parabéns, você agora já sabe como montar um modelo customizado com uma ferramenta mega poderosa 🥳

O que mais?

Se você se interessou por esse tópico e quer explorar ainda mais o MLflow Models, não deixe de conferir a documentação das PyFuncs, pois isso poderá te ajudar bastante no seu desenvolvimento.

De verdade, espero que esse tutorial seja útil pra você.

Tem dúvidas? Deixe seu comentário 😃

Configurando o Windows para trabalhar com Python no WSL 2

Murilo Menezes Mendonça — Mon, 27 Sep 2021 17:10:51 +0000

Se você trabalha com desenvolvimento ou está começando a aprender Python no Windows, talvez você já tenha tido alguma dificuldade com gestão de dependências, variáveis de ambiente e até mesmo permissão pra fazer as coisas porque não abriu seu Prompt de Comando como administrador. Esse post pode te dar um ganho de produtividade gigante, sem precisar abandonar esse tão famoso sistema operacional!

O que vamos fazer aqui é configurar um terminal de Ubuntu, uma distribuição de Linux mega popular, dentro do Windows, usando o WSL, ou Windows Subsystem for Linux. Sem a necessidade de ter dois Sistemas Operacionais instalados no seu PC, sem precisar de máquina virtual e nem nada. Tudo integrado e facinho 🤓. Aí além disso, vamos também rodar uma IDE super famosa de dentro desse terminal e garantir que você já consiga "sair jogando" pra desenvolver teu código Python (ou qualquer outra linguagem do seu interesse) depois de ler essa postagem.

Dividi em algumas pequenas etapas e vou colocar algumas capturas de tela pra você se guiar. Se tiver qualquer dúvida, pode comentar aqui que eu respondo se souber. Vamos nessa?

Instalando o WSL

O primeiro passo então é instalar e habilitar o WSL na sua máquina. Pra isso, abra como administrador o Powershell

E então execute o comando:



$ wsl --install

Esse processo vai demorar alguns minutos, dependendo da velocidade da sua internet e também do seu processador. Pra mim aqui foi em torno de 10 minutos. Uma vez que tiver tido sucesso ao instalar, reinicie seu computador.

Configurando o Ubuntu

Após reiniciar seu computador, procure por "Ubuntu" na barra de tarefas e abra a aplicação. Ele vai pedir pra você configurar um usuário e senha, que são as credenciais que você vai colocar pra configurar o seu terminal. Essa senha vai ser usada em muitas ocasiões que você precise de acesso como administrador, mas, por ser Linux (❤️), você consegue fazer isso sem a necessidade de reabrir o terminal e pra um comando específico, com sudo nome-do-comando. Enfim, escolha uma senha fácil de digitar e termine de configurar. Depois, feche a aplicação.

Ajustando a versão do WSL

Agora, abra de novo o Powershell como administrador e garanta que você está configurado na versão 2 do WSL, com o seguinte comando:



$ wsl --set-default-version 2

Instalando o VS Code e habilitando a extensão do WSL

Último mas não menos importante, baixe o Visual Studio Code e instale na sua máquina. Certifique-se de que você adiciona o comando "code" no seu $PATH (que por padrão já é habilitado).

Uma vez feito isso, procure e baixe uma extensão chamada Remote - WSL, clicando no ícone de blocos na aba esquerda do seu VS Code:

Feito isso, feche o VS Code.

Executando seu "olá mundo" de dentro do WSL

Agora pra etapa final, reabra o Ubuntu, crie uma pasta e inicie o VS Code de dentro do WSL, da seguinte forma:

Isso vai abrir a janela do VS Code e a partir daí você já consegue criar seu primeiro código hello-world.py com Python. Note que você está executando o VS Code de dentro do ambiente Ubuntu.

Então clique em "New Terminal" na aba de cima e execute o seu código dando o comando:



$ python3 hello-world.py

OLHA EU AQUI MUNDO!

Uhuuul! 🥳

Concluindo

Essa postagem foi bem curtinha, porque esse é um processo muito simples. Espero que ela seja útil pra você e se algo não ficou claro, me avisa aqui nos comentários!

Um abraço e até a próxima 🍻

Deploy do Airflow 2.0 no Kubernetes com Helm

Murilo Menezes Mendonça — Fri, 18 Jun 2021 21:58:58 +0000

A foto é do Loik Marras no Unsplash

Olá! Se você trabalha com pipelines de dados ou Jobs que precisam de uma resiliência maior do que um simples agendador de tarefas, como o cron, o Airflow pode ser uma excelente solução! Ele foi desenvolvido pelo time de dados do Airbnb, mas hoje pertence à fundação de software Apache. E claro, é um software de código aberto, mas você ainda vai precisar se preocupar com a infraestrutura pra mantê-lo de pé. Se você tem interesse em saber como subir uma instância de Airflow no Kubernetes, acho que esse post pode ser bem útil para você.

O que vamos fazer aqui?

Vou tentar trazer aqui um passo-a-passo super breve pra você conseguir fazer o deploy do Airflow na sua instância de Kubernetes com a ajuda do Helm. Não sabe do que se trata? Vou riscar a superfície sobre eles no próximo tópico, só pra que você não fique tãão perdido(a). Mas, como em muitas coisas relacionadas à tecnologia, faça seu dever de casa, procure outras postagens, faça cursos e se aprofunde. E claro, se alguma dúvida surgir, pode comentar aqui que eu tento ajudar com o que puder 😄

O Airflow pode funcionar em uma máquina virtual no seu provedor de nuvem ou mesmo na sua máquina local, como mostra esse tutorial do próprio time do Airflow. O que vamos utilizar nesse post é o Kubernetes, por se tratar de uma infraestrutura computacional bastante resiliente, performática e escalável.

Kubernetes

Em um resumo MEGA resumido, o Kubernetes é um serviço de gerenciamento de containers para garantir que sua aplicação sempre esteja de pé. Ele se baseia na sua declaração de como sua aplicação deve funcionar. Para isso, você faz uso de arquivos YAML, que vão dizer exatamente como sua aplicação fica de pé e como ela escala, e o serviço do Kubernetes garante que essas declarações irão se manter ao longo do tempo. Se no meio do caminho um container desliga, o Kubernetes provisiona um novo container. Se existirem muitos usuários, o Kubernetes consegue escalar o número de nós do seu cluster de máquinas, para que sua aplicação se mantenha sempre estável. E aí quando o número de usuários diminuir, ele também desliga as máquinas que não forem necessárias. Doido, né?

E o Helm? Pra que serve?

Bom, trabalhar com Kubernetes tem uma curva de aprendizado bastante inclinada. E você também pode demorar um pouco até que tudo funcione como você deseja, afinal, dependendo da complexidade da sua aplicação, o número de arquivos de configuração pode crescer consideravelmente. Pra tentar tornar esse processo mais amigável e fácil de manter, o projeto do Helm surgiu. Ele tenta templatear a maior parte "estática" das suas declarações, deixando as partes móveis em um único arquivo, comumente chamado values.yaml. E aí só com ele, você consegue declarar tudo o que você precisa pra subir sua aplicação.

Falar só sobre Airflow dá uma postagem bastante extensa. Mas vamos repassar o básico só pra gente se situar. Se você quiser, recomendo bastante que leia as documentações no site oficial.

Como eu comentei ali em cima, o Airflow é um serviço que vai te ajudar a "programaticamente criar, orquestrar e monitorar fluxos de trabalho". Para isso, você define sua sequência de tarefas com arquivos Python, que o Airflow irá entender e construir DAGs através deles.

É bem importante frisar que o papel do Airflow deve ser majoritariamente chamar outros serviços para realizar a computação pesada, porque é aí que ele brilha. A execução e paralelização de atividades em si vai ser mais bem executada quando feita por um cluster de Spark ou de PrestoSQL, por exemplo.

Web UI

A interface web é um componente que te permite visualizar todas as suas DAGs, o tempo de duração médio delas, a quantidade de falhas, o log de cada atividade. Com ela você também consegue ativar e pausar as suas DAGs, o que irá ser identificado pelo Scheduler.

Scheduler

O Scheduler (orquestrador) é o coração do Airflow, pois ele é quem irá identificar comandos da Web UI, como quando você ativa uma DAG manualmente, e também definições de periodicidade para ativar os seus pipelines. Mas quem irá realmente executar o comando que chama outras aplicações são os Workers.

Worker

O worker é o componente que de fato irá executar a tarefa. Se por exemplo você possui uma tarefa que vai chamar um executor externo, o comando que ativa isso é dado pelo worker.

Banco de dados

O Airflow precisa armazenar informações, como credenciais de usuários, strings de conexão e também logs de DAGs e isso tudo fica armazenado em um banco de dados relacional. Por padrão se utiliza o Postgres, mas é possível conectar a um banco MySQL caso necessário.

Depois dessa introdução talvez longa demais, vamos pro que interessa!

Requisitos necessários

Pra não ficar tão extenso por aqui, vou assumir aqui que você já tenha instalado e configurado na sua máquina:

kubectl
helm

Se estiver trabalhando com o MacOS, basta instalar ambas as ferramentas com o homebrew! 🍺

Também vou partir do princípio que você possui acesso a um cluster de Kubernetes no seu provedor de nuvem. Caso você esteja estudando e queira ter a experiência do Kubernetes na máquina local, dê uma olhada no Kind.

Deploy inicial

Para esse deploy, iremos utilizar o Helm chart oficial do Airflow. Para fazer a instalação padrão, basta você adicionar o repositório ao seu helm local com:

$ helm repo add apache-airflow https://airflow.apache.org
$ helm repo update

Então, crie um namespace que seja declarativo. Iremos utilizar aqui airflow-dev, para representar que essa é a instância de airflow em desenvolvimento. Defina também um nome para sua release. Normalmente se chama de airflow mesmo. Rode então os seguinte comandos:

$ kubectl create namespace airflow-dev
$ helm install airflow apache-airflow/airflow --namespace airflow-dev

Boa! 🤩 Com isso, você acaba de fazer a instalação padrão da sua primeira instância de Airflow. Mas em cenários reais, quase nunca essa instalação vai atender suas necessidades.

Customizando o chart do Helm

Como comentei, precisamos então acessar o arquivo values.yaml para que façamos as nossas alterações. Gosto bastante de começar criando um arquivo vazio, com esse mesmo nome, e ir customizando aos poucos, de acordo com o arquivo completo do repositório.

Vamos lá? Crie um arquivo vazio e comece a editá-lo com seu editor de texto preferido. Aqui eu to usando o VS Code, mas não importa muito.

$ mkdir airflow-deploy && touch airflow-deploy/values.yaml
$ code airflow-deploy

Definindo uma Fernet Key

Essa chave é super simples de gerar e, caso você não a defina, o Airflow irá definir uma por você. Ela serve para criptografar as informações que você armazenará no Banco de Dados, como chaves de acesso a outros serviços, então é bem importante utilizá-la. Vale lembrar que é importante ter esse valor no momento de instalação, e não de atualização da sua release. Então caso queira customizá-la, basta rodar o seguinte:

$ python -c "from cryptography.fernet import Fernet; FERNET_KEY = Fernet.generate_key().decode(); print(FERNET_KEY)"

Aí você copia o valor que aparecer no seu bash e coloca no values.yaml como:

fernetKey: <sua-chave-hasheada>

Banco de dados externo

Se você verificar, o deploy que você fez com o Helm ali em cima acabou de subir um Postgres no seu Kubernetes. Mas nem sempre é o desejável, principalmente se você já possui um banco de dados de pé para outras aplicações. Pra conectar com esse outro banco de dados, você vai precisar:

Desabilitar o Postgresql padrão
Criptografar sua string de conexão
Criar um secret no Kubernetes com a sua string de conexão

Para criptografar uma string, você vai executar esse comando no seu terminal:

$ echo -n 'sua-string-aqui' | base64

Para desencriptar e conferir, adicione o argumento -d após base64.

O secret pode então ser criado se você criar um arquivo com o nome airflow-db-secret.yaml e preencher com sua string criptografada no arquivo abaixo. Perceba que colocamos ali o namespace que você usou para seu deployment. Isso é importante para que a sua aplicação enxergue esse secret depois.

apiVersion: v1
kind: Secret
metadata:
  name: airflow-secret
  namespace: airflow-dev
type: Opaque
data:
  connection: <sua-connection-string-criptografada>

Aí você sobe esse secret pro seu Kubernetes com o seguinte comando:

$ kubectl apply -f airflow-db-secret.yaml

Existe uma alternativa com o kubectl que você consegue criar um segredo e não precisa criptografar essa string na mão. Sabe qual? 🤔

Seu values.yaml vai ficar assim, por enquanto:

postgresql:
  enabled: false

data:
  metadataSecretName: airflow-secret

Sincronizando suas DAGs

Agora que você já setou a conexão com o banco, precisamos pensar em como colocar suas DAGs (arquivos Python) pra dentro do Airflow. Uma opção bem fácil seria copiar os arquivos pra dentro da imagem de Docker antes de realizar o deploy. Mas isso não é uma boa prática, pois, a cada modificação ou mesmo nova DAG que seu time fizer, você vai precisar fazer uma atualização do seu deploy. E aí isso pode afetar algum pipeline que esteja rodando ou demorar um pouco mais pra acontecer. Ao invés disso, vamos usar um serviço bastante conveniente, chamado git-sync.
Ele funciona como um container extra, que fica presente em todos os Pods do Airflow. E o que ele faz é sincronizar com uma periodicidade que você definir com o seu repositório remoto. Aí todas as suas DAGs ficam alocadas no Github/Gitlab e você pode fazer o controle do que é sincronizado com um processo de Gitflow, por exemplo.

Pra isso, você precisará colocar os seguintes valores no seu values.yaml:

dags:
  persistence:
    enabled: false

  gitSync:
    enabled: true
    repo: git@github.com:<sua-organizacao>/<seu-repo>.git
    branch: main
    rev: HEAD
    depth: 1
    subPath: "src/dags"
    sshKeySecret: airflow-ssh-key

O primeiro argumento irá indicar que você não vai alocar suas DAGs em um Storage padrão, e na sequência já aparecem os argumentos do git-sync. Veja que você pode definir uma branch e até mesmo uma pasta dentro do seu repositório que você deseja que o Airflow enxergue as DAGs, definida no argumento subPath. Por último ali eu defini a minha chave SSH como um segredo do Kubernetes.

Você pode fazer isso com o seguinte comando:

$ kubectl create secret generic airflow-ssh-key --from-file=id_rsa=/path/das/chaves-ssh-locais -n airflow-dev

Customizando a imagem base

Se você estiver com as DAGs sendo sincronizadas via git-sync, customizar a imagem base pode não ser estritamente necessário. No entanto, caso você esteja trabalhando com algum provider, você vai precisar editar sua imagem.

Crie uma Dockerfile e estenda com o que você precisar. Eu vou instalar o pacote extra do Databricks aqui, pois é bastante relevante para meus pipelines de dados.

FROM apache/airflow:2.1.0
RUN pip install --no-cache-dir apache-airflow-providers-databricks==1.0.1

Beleza, aí você vai precisar buildar essa imagem e subir no seu repositório de preferência. Caso queria saber exatamente como fazer isso, confira as documentações do Docker Hub. Seu values.yaml vai ficar assim:

images:
  airflow:
    repository: <sua-organizacao>/<sua-imagem>
    tag: latest

registry:
  secretName: airflow-registry

Aqui eu também criei um secret para armazenar as minhas credenciais de login no meu repositório privado. Isso é bem importante caso esteja colocando customizações que não podem ser expostas. Pra isso, basta executar o seguinte comando:

$ kubectl create secret -n airflow-dev docker-registry airflow-registry --docker-server=<seu-servidor-docker> --docker-username=<seu-usuario> --docker-password=<sua-senha> --docker-email=<seu-email>

Exportando logs

Essa é uma das principais customizações, porque pela arquitetura padrão do Airflow no Kubernetes, as tarefas são executadas pelos Pods com os Workers. Esses Pods sobem quando a tarefa é demandada pelo Scheduler, executam e desligam. Só que ao desligar, os logs dessa execução são apagados junto do container.

Existem duas soluções principais pra isso: criar um Persistent Volume no Kubernetes e exportar os logs pra lá ou conectar-se a um Storage de nuvem, como por exemplo o s3. Nesse caso, vou mostrar como eu fiz para me conectar ao Blob Storage da Azure, que foi um pouco mais chato (de achar referência ou documentação, mas não de configurar) do que teria sido com o s3 ou GCS.

Basta você incluir o seguinte no seu values.yaml:

config:
  core:
    logging_level: "DEBUG"
    fab_logging_level: "DEBUG"
  logging:
    remote_logging: true
    remote_base_log_folder: "wasb-airflow-logs"
    remote_log_conn_id: "wasb_default"

Com isso, você está setando o nível de log das tarefas para "DEBUG". Você diz que os logs irão para uma pasta chamada wasb-airflow-logs. É bem importante que o nome da sua pasta comece com wasb-, caso contrário os templates não funcionarão (pelo menos não funcionaram pra mim).
Além disso, você precisa dizer o id da conexão que você fará com o Blob. No meu caso, chamei de wasb_default. Vou colocar um tópico para como setar essa conexão depois de subir as customizações ali em baixo, tá?

Agora quando você executar uma DAG, os logs das tarefas devem cair dentro do Blob, nessa localização. E você também consegue acessar diretamente da UI do Airflow, navegando pelas DAGs.

Exportando métricas para o Datadog

As documentações do Datadog no dia dessa postagem não contemplam exemplos com o Helm chart oficial do Airflow. E foi por essa dificuldade que resolvi escrever. É, como muita coisa na vida, ridiculamente simples. Mas por algum motivo as documentações do Datadog apontam pra um chart mantido pela comunidade e usam annotations ao invés do que o que é necessário. Estranho.

Enfim, temos aqui no nosso cluster a nossa instância de Datadog configurada com DaemonSets, que irão sempre ter Pods atrelados a todos os nós, para pegar métricas dos containers e Pods que subirem e monitorar o nosso cluster como um todo. No entanto, você consegue também exportar métricas específicas do Airflow para esse serviço através do StatsD. Pra não me alongar muito, o que você vai precisar fazer no values.yaml é o seguinte:

statsd:
  enabled: true

config:
  metrics:
    statsd_on: true
    statsd_port: 8125

extraEnv: |
  - name: AIRFLOW__METRICS__STATSD_HOST
    valueFrom:
      fieldRef:
        fieldPath: status.hostIP
  - name: DD_AGENT_HOST
    valueFrom:
      fieldRef:
          fieldPath: status.hostIP

A definição desses valores irá:

Criar um pod para onde irão ser direcionadas as métricas do Airflow
Mudar a porta padrão do StatsD para a 8125 (requerida pelo Datadog por padrão)
Apontar o host do StatsD do Airflow para o nó do Kubernetes onde ele está instalado
Apontar para o mesmo host onde está o Agent do Datadog

Parece muita coisa, mas são apenas essas as configurações que eu precisei pra fazer funcionar a conexão na minha instalação. Aí com isso posso criar um belíssimo dashboard para acompanhar a saúde da minha aplicação. Legal demais 😃

Outros

O que eu fiz foi não subir um componente de mensageria (Redis), que aumentaria bastante a complexidade da instalação nesse primeiro momento. Por isso, também desabilitei o Flower UI, que é uma interface gráfica para acompanhar esse serviço. Vamos ver então como ficou o arquivo values.yaml final?

# Fernet Key
fernetKey: <sua-chave-hasheada>

# Imagem customizada
images:
  airflow:
    repository: <sua-organizacao>/<sua-imagem>
    tag: latest

registry:
  secretName: airflow-registry


# Executor de Kubernetes
executor: "KubernetesExecutor"

# StatsD
statsd:
  enabled: true

extraEnv: |
  - name: AIRFLOW__METRICS__STATSD_HOST
    valueFrom:
      fieldRef:
        fieldPath: status.hostIP
  - name: DD_AGENT_HOST
    valueFrom:
      fieldRef:
          fieldPath: status.hostIP

# Redis e Flower
redis:
  enabled: false
flower:
  enabled: false

# Banco de Dados
postgresql:
  enabled: false
data:
  metadataSecretName: airflow-secret

# Git Sync
dags:
  persistence:
    enabled: false
  gitSync:
    enabled: true
    repo: git@github.com:<sua-organizacao>/<seu-repo>.git
    branch: main
    rev: HEAD
    depth: 1
    subPath: "src/dags"
    sshKeySecret: airflow-ssh-key

# Logs e StatsD
config:
  core:
    logging_level: "DEBUG"
    fab_logging_level: "DEBUG"
  logging:
    remote_logging: true
    remote_base_log_folder: "wasb-airflow-logs"
    remote_log_conn_id: "wasb_default"
  metrics:
    statsd_on: true
    statsd_port: 8125

logs:
  persistence:
    enabled: false

Subindo suas alterações

Para subir todas essas customizações, basta você rodar o seguinte comando:

$ helm upgrade airflow apache-airflow/airflow -n airflow-dev -f airflow-deploy/values.yaml

E é isso! Agora você tem uma aplicação super massa com muita coisa customizada de pé. Comemore! 🚀

Extra: Criando uma conexão com o seu Storage

Como comentei durante o tópico anterior, vamos ver como fazer para autenticar suas credenciais no Storage Account da Azure. A forma mais fácil de fazer isso é pela Web UI. Como você provavelmente ainda não setou um Ingress, para que você possa visualizar a web UI, faça um port-forward no container da web. Você pode fazer isso com o seguinte comando:

$ kubectl port-forward svc/airflow-webserver 8080:8080 --namespace airflow-dev

Com isso, vá ao seu localhost:8080 no seu navegador, logue com admin/admin e faça o seguinte caminho:
Admin > Connections > +
Aí defina o seguinte:

Conn Type: Azure Blob Storage
Blob Storage Login: <seu-storage-account>
Blob Storage Shared Access Key: <sua-chave-de-acesso>

Essa é uma das formas de se autenticar no Blob, a outra pode ser a própria string de conexão. Por padrão os logs irão para o seu Storage em um container chamado "airflow-logs", dentro da pasta que você definiu ali em cima.

Concluindo

Se você conseguiu acompanhar até aqui, ótimo. Acho que esse post pode ser muito útil para muitas pessoas que, como eu, podem ficar por dias travadas em alguns pontos que deveriam ser simples.

Ainda existem algumas coisas bem importantes para você fazer antes de considerar que possui uma instância em produção, como, por exemplo:

Configurar o Ingress e acessar a web UI através de um DNS
Configurar o PgBouncer para controlar o número de conexões abertas no seu banco de dados pelo Airflow
Dimensionar corretamente o seu cluster
Alocar os componentes em diferentes nós através de nodeSelectors
Criar a mesma instância em um ambiente isolado e vincular as DAGs a uma branch diferente no seu repositório
Construir pipelines de dados que entreguem muito valor para o seu negócio =)

Deletando os recursos

Se você quer fazer o deploy com uma fernetKey diferente, ou mesmo pausar a utilização de recursos, você pode deletar tudo o que foi feito com um simples comando:

$ helm delete airflow -n airflow

Espero que tenha sido uma boa leitura e, caso tenha alguma dúvida, me avisa aqui nos comentários.

Um abraço!

Git para Ciência de Dados

Murilo Menezes Mendonça — Fri, 20 Nov 2020 13:00:03 +0000

A foto de cima é do Yancy Min, do Unplash

Olá! Esse post é a minha estreia aqui e eu vou tentar deixar um pouco mais claro os conceitos de Git, o porquê que é bom de usar, as boas práticas que eu adoto no meu dia-a-dia e também alguns macetes pra você não ter problemas lá na frente - ou ter menos problemas, pelo menos. Eu to assumindo que você trabalha com Ciência de Dados, mas só pra tentar trazer alguns exemplos pra nossa realidade. Se você não é um DS, ainda acho que tem bastante coisa aqui pra aproveitar. Bora? 😄

O que é Git?

Pra colocar em uma frase: Git é uma ferramenta gratuita e de código aberto para controle de versão de código-fonte. O troço é tão relevante, que foi criado pelo Linus Torvalds, criador do Linux, justamente pra controlar as versões do kernel. Doido, né?

O básico

O que isso significa é que ele vai gerenciar pra você cada modificação que você fizer no seu modelo, alguma variável nova que você está calculando, enfim, tudo o que for modificado vai ser controlado por ele, através de cópias e chaves. Se quiser ler as documentações mais a fundo depois, dá uma olhada no site oficial.

Então imagina que você hoje tenha essa estrutura em uma pasta:

notebooks/
├── meu_modelo_v1.ipynb     
├── meu_modelo_v2.ipynb
├── meu_modelo_v2_27062021.ipynb
├── meu_modelo_final.ipynb
├── meu_modelo_final2.ipynb

E você vai passar a ter uma estrutura assim, quando começar a usar Git:

notebooks/
├── meu_modelo.ipynb

Ué, mas que bruxaria é essa? 🧙

Versões através de chaves

Com esse desenho lindo aqui em baixo (risos) eu tentei mostrar como fica o seu código ao longo do tempo, da direita pra esquerda. O que acontece é que cada versão do seu código vai ser copiada pelo Git e atribuída a uma chave identificadora única. Isso acontece toda vez que você salvar o seu trabalho, ou, quando você der um commit - eu vou explicar esse jargão um pouco mais pra frente.

Qual a diferença entre Git e Github?

Se a gente controlar as versões do nosso trabalho localmente, isso já dá uma aliviada muito grande. Mas se a gente pensa em trabalhar em equipe ou até mesmo em não depender do nosso computador funcionando sempre, é muito importante que isso vá pra algum lugar na nuvem, em um servidor remoto, para que a gente possa acessar depois. O Github é esse lugar.

Além de armazenar nosso código e arquivos, ele também possibilita a gente controlar algumas coisas através da sua interface gráfica, facilitando bastante o trabalho no dia-a-dia. Além do Github, existem outros servidores remotos de Git, como Gitlab e Bitbucket. Escolhi falar sobre o Github porque é gratuito, o mais popular e, na minha opinião, muito completo.

Trabalhando com Git no dia-a-dia

Dando um salto para o fluxo de trabalho, vamos falar um pouco agora sobre como a gente trabalha com Git no dia-a-dia. Essa é a parte mais densa dessa postagem, mas vamo junto que isso vai ser muito útil para você!

NOTA: Estou aqui partindo do pressuposto que você já baixou o Git na sua máquina e também tem uma conta no Github. Caso contrário, pesquise sobre como fazer e volte aqui depois!

Estrutura do Git e comandos principais

Um pouco mais abaixo eu resolvi deixar mais uma obra de arte para tentar visualmente caminhar pelos comandos mais importantes - não todos - e até entender como e porque a gente usa eles.

O primeiro e talvez mais frequente comando que você vai utilizar é o

$ git status

Com ele, você consegue saber o que tá acontecendo na sua pasta. Quais arquivos você tá e não tá controlando, se a sua versão do código está atualizada de acordo com o seu repositório e assim por diante. Sempre que você quiser conferir se deu certo o que você fez, mande um git status.

Quando você fizer as modificações no seu código, você vai mandá-lo pra uma área de staging, que vai basicamente indicar pro Git que esse código é um arquivo que você quer controlar a versão. Você faz isso através do comando:

$ git add meu_arquivo.py

Assim, o meu_arquivo.py irá ser indexado para que entre no seu próximo commit realizado. Se você quiser mandar para a área de indexação todos os seus arquivos de uma vez, use um wildcard, como:

$ git add .

Mas tenha cuidado! É muito fácil mandar algum arquivo ou diretório indesejado utilizando um wildcard. Então depois de adicionar os arquivos para a indexação, lembre-se de rodar um git status para saber o que está sendo indexado para ser versionado, tá?

Uma vez indexado, seu código poderá ser salvo no repositório local através do comando commit. Essa etapa também é super importante, pois aqui você terá a possibilidade de dar um resumo sobre quais foram as alterações feitas nessa nova versão do código, de uma forma breve e objetiva. Para isso, use o comando:

$ git commit -m "modelo com média de preços para treino"

O argumento -m possibilita que você escreva uma frase para representar esse commit. Essa parte é tão crítica, que existem alguns posts sobre como escrever uma boa mensagem no commit.

Uma vez que seu repositório local conhece as modificações que foram indexadas para esse commit, ta na hora de "empurrar" isso pra nuvem, com o comando

$ git push

Dependendo de como você estruturou sua conexão, isso pode mandar as modificações direto para o seu repositório no Github ou te pedir o login e senha. De todo modo, tá salvo!

Os comandos checkout, pull e fetch eu vou cobrir no próximo tópico.

Aproveite sua IDE!

Se você tá acostumado a trabalhar em uma IDE ou Editor de Texto, aproveite as funcionalidades que eles trazem para controle de versão de código. No PyCharm, por exemplo, as linhas que você modifica, apaga ou adiciona, criam marcadores específicos, que te indicam o que foi feito ali em relação ao código original.

Além disso, os arquivos modificados também ficam com cores diferentes. E não só você pode acompanhar visualmente as modificações, como também pode realizar add, commit e push com apenas alguns cliques. Eu gosto muito de fazer tudo em um lugar só, então vale muito a pena explorar isso. Confia! 🤞

Trabalhando em equipe

Bom, agora que você já tem uma ideia de como controlar as versões do código, chegou a hora de falar um pouco sobre como você faz pra utilizar isso na vida real, trabalhando com mais pessoas. E não ache que porque você é o único Cientista de Dados do seu projeto você está sozinho nessa.
O seu eu do futuro também é o seu colega de trabalho. Parece meio louco pensar nisso, mas se você passar alguns meses sem mexer com um projeto, vai ser muito difícil olhar pra trás e saber o que foi feito sem existir uma boa documentação e cuidado com o trabalho realizado.

Branches

Pensando em trabalhar com mais pessoas, é fundamental que exista um código principal e que sejam criadas versões espelhadas do seu projeto, para que você possa fazer quaisquer mudanças sem afetar o código principal.

Pensando nisso, criou-se o conceito de branch (em inglês, galho de árvore), que são ramificações do código principal. Para criar uma branch, você pode utilizar a interface gráfica do Github, clicando onde estiver escrito master (ou main), como mostra a figura:

Feito isso, mude para a branch criada no seu local de trabalho, utilizando os seguintes comandos:

$ git fetch
$ git checkout my_new_branch

Como vimos na figura da seção anterior, o git fetch irá pegar as modificações do repositório remoto e trazê-las para o repositório local. Isso faz com que o Git local possa identificar que uma nova branch chamada my_new_branch foi criada. Com o comando checkout, você irá passar a trabalhar nela.

A partir daqui, todas as suas modificações irão ser contempladas e realizadas na sua própria branch, sem afetar o código principal. Uma vez que você estiver satisfeito com as suas modificações, você poderá abrir uma Pull Request.

Pull Requests

Se você estiver trabalhando no seu código em uma branch específica, a versão principal ficará desatualizada em relação às suas modificações, certo? Por isso, quando você julgar que essas modificações podem fazer parte do código principal, abra uma Pull Request (PR). Pra fazer isso pelo Github, basta você abrir a aba de PR's, clicar em New Pull Request e seguir as instruções.

Vale ressaltar aqui que é muito importante que alguém revise suas modificações. Para isso, indique alguém do seu time para ser um "Reviewer" do lado direito da janela principal da PR. Isso faz com que a pessoa veja com clareza as modificações realizadas no seu código, escreva mensagens específicas, aprove ou até faça a requisição de modificações.

Uma vez aprovada a PR, o código principal irá contemplar as suas alterações e você contribuiu para o projeto de uma forma controlada e responsável!

Tendo em vista que outras pessoas podem ter feito PRs e modificações na branch principal, é importante periodicamente rodar o comando git fetch. Existe uma opção no VS Code que ele faz isso pra você!

Se você desejar que as alterações do código feitas venham diretamente para o seu local de trabalho, você também pode utilizar o comando:

$ git pull

Finalizando assim a lista de comandos que eu tinha prometido anteriormente.

Motivos para pensarmos em Gitflow

Esse tópico pode até ser considerado um pouco mais avançado, mas a filosofia dele é extremamente importante e eu estou colocando nessa postagem porque eu queria que alguém tivesse me dito isso quando eu estava começando.

Se você já trabalhou com desenvolvimento ou pelo menos foi em algum meetup, muito provavelmente você já ouviu a seguinte frase, entoada a plenos pulmões:

"NUNCA DÊ COMMIT NA MASTER"

Mas... por que?

Primeiro que, se você fizer um commit no código principal que esteja com algum pequeno bug, outras pessoas vão deixar de ter um código que funciona para trabalhar, e isso por si só já pode ser um baita problema.

Mas vamos pensar mais além, se temos uma aplicação em produção, como um modelo de Análise de Crédito, por exemplo, ele provavelmente vai estar sendo consumido por uma pipeline de Integração e Deploy contínuos (CI/CD). Isso significa que a aplicação se baseia na branch principal para funcionar. Se você der um commit diretamente nela, a aplicação vai ser automaticamente atualizada.

Se seu código possui erros, no melhor dos cenários ela para de funcionar. No pior dos cenários, ela irá entregar análises de crédito erradas e até trazer um grande prejuízo pra empresa. Chato, né? Então por isso que é muito importante sempre pensar em trabalhar em branches e realizar PR's. Essa é a mensagem.

O termo "Gitflow" é utilizado baseando-se numa metodologia que padroniza a nomenclatura de branches e também parte do princípio que o ciclo de vida de uma branch é bem curto - no máximo 3 dias. Isso faz com que o código seja constantemente revisado, que as modificações nele sejam incrementais e que exista uma política de governança bem estabelecida para o trabalho. Se quiser ler mais sobre, veja essa postagem em inglês da Atlassian.

Não versione dados com Git

"Bom, se é importante eu salvar meu trabalho e as versões dele, então fica mais fácil já colocar junto também os dados em CSV que eu tô utilizando, certo?"

E aqui vai um grande NÃO.

O Git foi feito para controlar inúmeras versões dos códigos escritos justamente porque são arquivos extremamente leves e fáceis de serem controlados. Se você trabalha com dados locais, como arquivos em CSV ou XLSX, crie um arquivo no seu repositório chamado .gitignore. Com ele, você vai poder dizer o que o Git não deve olhar quando verificar alterações. Um template que eu uso pode ser escrito assim:

# Python secondary files
__pycache__/
*.py[cod]
*$py.class
.ipynb_checkpoints/

# VS Code config file
.vscode/

# Datasets
*.csv
*.xlsx

# Environments
.env
.venv
env/
venv/
ENV/
env.bak/
venv.bak/


# Other files
.idea/
.idea/*

Existem ferramentas específicas para versionamento de dados, como o DVC, mas que fogem do escopo desse artigo.

Resumão

Nesse meu primeiro artigo, quis trazer um "curso relâmpago" de Git, com algumas especificidades de Data Science pra te ajudar a trilhar essa jornada e estabelecer conhecimentos fundamentais do Desenvolvimento de Software para o seu dia-a-dia.

Sei que se você nunca mexeu com Git essa postagem pode ter sido cheia de jargões ou conceitos que ainda estão um pouco obscuros pra você. Ao mesmo tempo em que é apaixonante, também pode ser exaustivo trabalhar com tecnologia. Não se desespere! Pesquise mais, leia mais e exercite sua curiosidade, que eu garanto que isso tudo vai se esclarecer aos poucos pra você.

Se mesmo assim tem algum conceito que eu falei aqui e que ainda não tá claro, me manda uma mensagem, comenta aqui em baixo e me ajude a tornar essa postagem ainda mais acessível.

Um abraço e boa caminhada! 🚀