Introdução No , mostrei como construir um pipeline de CI usando e GitLab. Nesta postagem, mostrarei como atingir o mesmo objetivo com a estrutura de implantação do Databricks mais recente e recomendada, . O DAB é ativamente apoiado e desenvolvido pela equipe do Databricks como uma nova ferramenta para agilizar o desenvolvimento de dados complexos, análises e projetos de ML para a plataforma Databricks. blog anterior databricks CLI eXtensions Databricks Asset Bundles Vou pular a introdução geral do DAB e seus recursos e encaminhá-lo para a documentação do Databricks. Aqui, vou me concentrar em como migrar nosso projeto dbx do blog anterior para DAB. Ao longo do caminho, explicarei alguns conceitos e recursos que podem ajudá-lo a compreender melhor cada etapa. Padrão de desenvolvimento usando Databricks GUI Na postagem anterior, usamos a GUI do Databricks para desenvolver e testar nosso código e fluxos de trabalho. Para esta postagem do blog, queremos poder usar nosso ambiente local para desenvolver nosso código também. O fluxo de trabalho será o seguinte: Crie um repositório remoto e clone-o em nosso ambiente local e no espaço de trabalho do Databricks. Usamos aqui. GitLab Desenvolva a lógica do programa e teste-a dentro da GUI do Databricks ou em nosso IDE local. Isso inclui scripts Python para construir um pacote Python Wheel, scripts para testar a qualidade dos dados usando pytest e um notebook para executar o pytest. Envie o código para o GitLab. O acionará um GitLab Runner para construir, implantar e lançar recursos em Databricks usando Databricks Asset Bundles. git push Configurando seus ambientes de desenvolvimento CLI do Databricks Em primeiro lugar, precisamos instalar o Databricks CLI versão 0.205 ou superior em sua máquina local. Para verificar a versão instalada da CLI do Databricks, execute o comando . Para instalar a CLI do Databricks versão 0.205 ou superior, consulte . databricks -v Instalar ou atualizar a CLI do Databricks Autenticação O Databricks dá suporte a entre a CLI do Databricks em nossa máquina de desenvolvimento e seu espaço de trabalho do Databricks. Para este tutorial, usamos a autenticação de token de acesso pessoal do Databricks. Consiste em duas etapas: vários métodos de autenticação Crie um token de acesso pessoal em nosso workspace do Databricks. Crie um perfil de configuração do Databricks em nossa máquina local. Para gerar um token do Databricks em seu espaço de trabalho do Databricks, vá para Configurações do usuário → Desenvolvedor → Tokens de acesso → Gerenciar → Gerar novo token. Para criar um perfil de configuração, crie o arquivo na sua pasta raiz com o seguinte conteúdo: ~/.databrickscfg [asset-bundle-tutorial] host = https://xxxxxxxxxxx.cloud.databricks.com token = xxxxxxx Aqui, o é o nome do nosso perfil, o host é o endereço do nosso espaço de trabalho e o token é o token de acesso pessoal que acabamos de criar. asset-bundle-tutorial Você pode criar esse arquivo usando a CLI do Databricks executando em seu terminal. O comando solicitará o e . Se você não especificar o sinalizador , o nome do perfil será definido como . databricks configure --profile asset-bundle-tutorial host do Databricks o token de acesso pessoal --profile DEFAULT Integração Git (Databricks) Como primeira etapa, . Em seguida, criamos um repositório remoto e , bem como em nossa máquina local. Finalmente, precisamos configurar a autenticação entre a CLI do Databricks no executor do Gitlab e nosso espaço de trabalho do Databricks. Para fazer isso, devemos adicionar duas variáveis de ambiente, e às nossas configurações de pipeline CI/CD do Gitlab. Para isso abra seu repositório no Gitlab, vá em configuramos as credenciais do Git e conectamos um repositório remoto ao Databricks clonamos-o em nosso repositório Databricks DATABRICKS_HOST DATABRICKS_TOKEN Configurações → CI/CD → Variáveis → Adicionar variáveis Tanto o dbx quanto o DAB são construídos em torno das , portanto, em sua essência, eles são muito semelhantes. Seguirei as etapas para criar um pacote manualmente a partir de nosso projeto dbx existente. APIs REST do Databricks A primeira coisa que precisamos configurar para nosso projeto DAB é a configuração de implantação. No para definir e configurar nossos ambientes e fluxos de trabalho (jobs e pipelines). Para configurar o ambiente, utilizamos e para definir os fluxos de trabalho, utilizamos . dbx, usamos dois arquivos .dbx/project.json deployment.yml No DAB, tudo vai para , que está localizado na pasta raiz do seu projeto. Veja como parece: databricks.yml bundle: name: DAB_tutorial #our bundle name # These are for any custom variables for use throughout the bundle. variables: my_cluster_id: description: The ID of an existing cluster. default: xxxx-xxxxx-xxxxxxxx #The remote workspace URL and workspace authentication credentials are read from the caller's local configuration profile named <asset-bundle-tutorial> workspace: profile: asset-bundle-tutorial # These are the default job and pipeline settings if not otherwise overridden in # the following "targets" top-level mapping. resources: jobs: etl_job: tasks: - task_key: "main" existing_cluster_id: ${var.my_cluster_id} python_wheel_task: package_name: "my_package" entry_point: "etl_job" # take a look at the setup.py entry_points section for details on how to define an entrypoint libraries: - whl: ../dist/*.whl - task_key: "eda" existing_cluster_id: ${var.my_cluster_id} notebook_task: notebook_path: ../notebooks/explorative_analysis.py source: WORKSPACE depends_on: - task_key: "main" test_job: tasks: - task_key: "main_notebook" existing_cluster_id: ${var.my_cluster_id} notebook_task: notebook_path: ../notebooks/run_unit_test.py source: WORKSPACE libraries: - pypi: package: pytest # These are the targets to use for deployments and workflow runs. One and only one of these # targets can be set to "default: true". targets: # The 'dev' target, used for development purposes. # Whenever a developer deploys using 'dev', they get their own copy. dev: # We use 'mode: development' to make sure everything deployed to this target gets a prefix # like '[dev my_user_name]'. Setting this mode also disables any schedules and # automatic triggers for jobs and enables the 'development' mode for Delta Live Tables pipelines. mode: development default: true workspace: profile: asset-bundle-tutorial root_path: /Users/${workspace.current_user.userName}/.bundle/${bundle.name}/my-envs/${bundle.target} host: <path to your databricks dev workspace> O arquivo de configuração do pacote consiste em seções chamadas mapeamentos. Esses mapeamentos nos permitem modularizar o arquivo de configuração em blocos lógicos separados. Existem 8 mapeamentos de nível superior: databricks.yml pacote variáveis área de trabalho artefatos incluir recursos sincronizar alvos Aqui, usamos cinco desses mapeamentos para organizar nosso projeto. : pacote No mapeamento do , definimos o nome do pacote configurável. Aqui também podemos definir um ID de cluster padrão que deve ser usado para nossos ambientes de desenvolvimento, bem como informações sobre a URL e branch do Git. bundle : variáveis Podemos usar o mapeamento para definir variáveis personalizadas e tornar nosso arquivo de configuração mais reutilizável. Por exemplo, declaramos uma variável para o ID de um cluster existente e a usamos em diferentes fluxos de trabalho. Agora, caso queira utilizar um cluster diferente, basta alterar o valor da variável. variables : recursos O mapeamento é onde definimos nossos fluxos de trabalho. Inclui zero ou um de cada um dos seguintes mapeamentos: , , e . Este é basicamente nosso arquivo no projeto dbx. Embora existam algumas pequenas diferenças: resources experiments jobs models pipelines deployment.yml Para , devemos incluir o caminho para nosso pacote wheel; caso contrário, o Databricks não conseguirá encontrar a biblioteca. Você pode encontrar mais informações sobre como construir pacotes de rodas usando DAB . python_wheel_task aqui Podemos usar caminhos relativos em vez de caminhos completos para executar as tarefas do notebook. O caminho para a implantação do notebook é relativo ao arquivo no qual esta tarefa é declarada. databricks.yml : alvos O mapeamento é onde definimos as configurações e recursos das diferentes etapas/ambientes dos nossos projetos. Por exemplo, para um pipeline típico de CI/CD, teríamos três alvos: desenvolvimento, preparação e produção. Cada destino pode consistir em todos os mapeamentos de nível superior (exceto ) como mapeamentos filhos. Aqui está o esquema do mapeamento de destino ( ). targets targets databricks.yml targets: <some-unique-programmatic-identifier-for-this-target>: artifacts: ... bundle: ... compute_id: string default: true | false mode: development resources: ... sync: ... variables: <preceding-unique-variable-name>: <non-default-value> workspace: ... O mapeamento filho nos permite substituir as configurações padrão que definimos anteriormente nos mapeamentos de nível superior. Por exemplo, se quisermos ter um espaço de trabalho isolado do Databricks para cada estágio do nosso pipeline de CI/CD, devemos definir o mapeamento filho do espaço de trabalho para cada destino. workspace: profile: my-default-profile targets: dev: default: true test: workspace: host: https://<staging-workspace-url> prod: workspace: host: https://<production-workspace-url> incluir: O mapeamento nos permite dividir nosso arquivo de configuração em módulos diferentes. Por exemplo, podemos salvar nossos recursos e variáveis no arquivo e importá-los para nosso arquivo . include resources/dev_job.yml databricks.yml # yaml-language-server: $schema=bundle_config_schema.json bundle: name: DAB_tutorial #our bundle name workspace: profile: asset-bundle-tutorial include: - ./resources/*.yml targets: # The 'dev' target, used for development purposes. # Whenever a developer deploys using 'dev', they get their own copy. dev: # We use 'mode: development' to make sure everything deployed to this target gets a prefix # like '[dev my_user_name]'. Setting this mode also disables any schedules and # automatic triggers for jobs and enables the 'development' mode for Delta Live Tables pipelines. mode: development default: true Para uma explicação mais detalhada das configurações DAB, confira configurações do Databricks Asset Bundle Fluxos de trabalho Os fluxos de trabalho são exatamente o que descrevi no blog anterior. As únicas diferenças são a localização dos artefatos e arquivos. O esqueleto do projeto aqui está como é o projeto final ASSET-BUNDLE-TUTORAL/ ├─ my_package/ │ ├─ tasks/ │ │ ├─ __init__.py │ │ ├─ sample_etl_job.py │ ├─ __init__.py │ ├─ common.py ├─ test/ │ ├─ conftest.py │ ├─ test_sample.py ├─ notebooks/ │ ├─ explorative_analysis.py │ ├─ run_unit_test.py ├─ resources/ │ ├─ dev_jobs.yml ├─ .gitignore ├─ .gitlab-ci.yml ├─ databricks.yml ├─ README.md ├─ setup.py Validar, implantar e executar Agora, abra seu terminal e execute os seguintes comandos no diretório raiz: Primeiro, devemos verificar se nosso arquivo de configuração tem o formato e a sintaxe corretos. Se a validação for bem-sucedida, você obterá uma representação JSON da configuração do pacote configurável. Em caso de erro, corrija-o e execute o comando novamente até receber o arquivo JSON. validar: databricks bundle validate a implantação inclui a construção do pacote Python wheel e sua implantação em nosso espaço de trabalho do Databricks, a implantação dos notebooks e outros arquivos em nosso espaço de trabalho do Databricks e a criação de trabalhos em nossos fluxos de trabalho do Databricks. implantar: databricks bundle deploy Se nenhuma opção de comando for especificada, a CLI do Databricks usará o destino padrão conforme declarado nos arquivos de configuração do pacote configurável. Aqui, temos apenas um alvo, então isso não importa, mas para demonstrar isso, também podemos implantar um alvo específico usando o sinalizador . -t dev execute os trabalhos implantados. Aqui, podemos especificar qual trabalho queremos executar. Por exemplo, no comando a seguir, executamos o trabalho no destino dev. run: test_job databricks bundle run -t dev test_job na saída você obtém um URL que aponta para o trabalho executado em seu espaço de trabalho. você também pode encontrar seus trabalhos na seção Workflow do seu espaço de trabalho do Databricks. do pipeline de CI Configuração A configuração geral do nosso pipeline de CI permanece a mesma do projeto anterior. Consiste em duas etapas principais: e . No estágio , o executa os testes de unidade e implanta um fluxo de trabalho separado para teste. O estágio , ativado após a conclusão bem-sucedida do estágio de teste, cuida da implantação do seu fluxo de trabalho ETL principal. teste implantação de teste unit-test-job de implantação Aqui, temos que adicionar etapas adicionais antes de cada estágio para instalar a CLI do Databricks e configurar o perfil de autenticação. Fazemos isso na seção do nosso pipeline de CI. A palavra-chave é usada para definir uma matriz de comandos que devem ser executados antes dos comandos de cada tarefa. Mais sobre isso pode ser encontrado . before_script before_script script aqui Opcionalmente, você pode usar a palavra-chave para definir uma matriz de comandos que devem ser executados APÓS cada trabalho. Aqui, podemos usar para limpar após o término de cada trabalho. Em geral, nosso pipeline passa por estas etapas: after_project databricks bundle destroy --auto-approve Instale a CLI do Databricks e crie o perfil de configuração. Construa o projeto. Envie os artefatos de build para o workspace do Databricks. Instale o pacote wheel em seu cluster. Crie os trabalhos em fluxos de trabalho do Databricks. Execute os trabalhos. aqui está a aparência do nosso : .gitlab-ci.yml image: python:3.9 stages: # List of stages for jobs, and their order of execution - test - deploy default: before_script: - echo "install databricks cli" - curl -V - curl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | sh - echo "databricks CLI installation finished" - echo "create the configuration profile for token authentication" - echo "[asset-bundle-tutorial]" > ~/.databrickscfg - echo "token = $DATABRICKS_TOKEN" >> ~/.databrickscfg - echo "host = $DATABRICKS_HOST" >> ~/.databrickscfg - echo "validate the bundle" - databricks bundle validate after_script: - echo "remove all workflows" #- databricks bundle destroy --auto-approve unit-test-job: # This job runs in the test stage. stage: test script: - echo "Running unit tests." - pip3 install --upgrade wheel setuptools - pip install -e ".[local]" - databricks bundle deploy -t dev - databricks bundle run -t dev test_job deploy-job: # This job runs in the deploy stage. stage: deploy # It only runs when *both* jobs in the test stage complete successfully. script: - echo "Deploying application..." - echo "Install dependencies" - pip install -e ".[local]" - echo "Deploying Job" - databricks bundle deploy -t dev - databricks bundle run -t dev etl_job Notas Aqui estão algumas notas que podem ajudá-lo a configurar seu projeto de pacote: Neste blog, criamos nosso pacote manualmente. Na minha experiência, isso ajuda a compreender melhor os conceitos e recursos subjacentes. Mas se quiser iniciar seu projeto rapidamente, você pode usar modelos de pacote padrão e não padrão fornecidos pela Databricks ou outras partes. Confira para saber como iniciar um projeto com o modelo Python padrão. esta postagem do Databricks Quando você implanta seu código usando , a CLI do Databricks executa o comando para construir seu pacote usando o arquivo . Se você já possui instalado, mas sua máquina usa o alias em vez de , você terá problemas. No entanto, isso é fácil de corrigir. Por exemplo, e estão dois threads Stack Overflow com algumas soluções. databricks bundle deploy python3 setup.py bdist_wheel setup.py o python3 python python3 aqui aqui Qual é o próximo Na próxima postagem do blog, começarei com minha primeira postagem sobre como iniciar um projeto de aprendizado de máquina no Databricks. Será a primeira postagem do meu próximo pipeline de aprendizado de máquina de ponta a ponta, cobrindo tudo, desde o desenvolvimento até a produção. Fique atento! Recursos . repositório para este tutorial Certifique-se de atualizar o cluster_id em resources/dev_jobs.yml Migrar de dbx para pacotes | Blocos de dados na AWS Tarefas de trabalho de desenvolvimento do Databricks Asset Bundles | Blocos de dados na AWS Modos de implantação do Databricks Asset Bundle | Blocos de dados na AWS Desenvolva uma roda Python usando Databricks Asset Bundles | Blocos de dados na AWS Pacotes de ativos do Databricks: uma abordagem padrão e unificada para implantação de produtos de dados no Databricks (youtube.com) repositório e slides https://github.com/databricks/databricks-asset-bundles-dais2023
