🚀 Resumo da funcionalidade solicitada:
Atualmente, o job Glue disponibilizado no repositório não considera qualquer tipo de alerta ou notificação de execução com ou sem sucesso. Este pedido refere-se à inclusão deste tipo de lógica (provavelmente em declarações Terraform) para criação de um tópico SNS responsável por notificar o usuário, via e-mail, da execução do job.

Em um primeiro momento, esta funcionalidade poderia focar na notificação de execuções com erro, para depois avaliar a possibilidade de envio de diferentes e-mails de acordo com o sucesso da operação.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Obter notificações sobre execuções bem sucedidas do job
• Obter notificações sobre execuções mal sucedidas do job
• Ter um maior observability do processo
• Analisar as melhores práticas de configuração de notificações em um projeto Terraform

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Alta complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Avaliar a criação de um tópico SNS no Terraform
• Vincular evento de finalização de execução do Job ao tópico SNS criado
• Criar novas variáveis de configuração da notificação (flag, e-mail, entre outras)

🚀 Resumo da funcionalidade solicitada:
Em um ambiente analítico, é comum encontrar etapas de transformação relacionadas à agregação de dados e extração de atributos estatíticos de variáveis relevantes para o processo de análise. Neste contexto, novos atributos são criados em DataFrames com agregações como, por exemplo, soma, média, máximo e mínimo. Além disso, em fluxos específicos de trabalho, é possível até encontrar atributos como desvio padrão, variância, quartil, entre outros. Pensando nisso, seria altamente relevante possuir um método de transformação na classe GlueETLManager com a capacidade de extrair múltiplos atributos estatíticos de uma coluna numérica com uma única chamada parametrizável pelo usuário.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Aprimorar seus fluxos de transformação de forma mais consolidada e organizada
• Adicionar uma etapa de extração de atributos estatíticos de colunas numéricas

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Média complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Consultar o método date_attributes_extraction() da classe GlueETLManager com atuação relativamente semelhatne
• Parametrizar escolhas de atributos de estatísticos para que o usuário decida quais atributos consolidar no DataFrame resultante
• Adicionar argumento do método para definir colunas de agrupamento aos quais as agregações serão aplicadas

🚀 Resumo da funcionalidade solicitada:
A classe GlueTransformationManager do script principal main-terraglue.py possui um método chamado generate_dataframe_dict() capaz de retornar um dicionário de DataFrames Spark de acordo com alguns parâmetros de leitura fornecido pelo usuário. No estado atual, a única possibilidade de atuação no Job Glue em termos de transformação é a partir de métodos nativos de DataFrames (ou DynamicFrames), exigindo assim um conhecimento prévio, por parte do usuário, em métodos do tipo.

O pedido de feature aqui consolidado propõe a criação de um flag no método de geração de DataFrames para a criação de tabelas temporárias no Spark (views) para cada um dos DataFrames lidos, permitindo assim que o usuário codifique os métodos de transformação no Job a partir operações em SQL. Nesse formato de trabalho, o método generate_dataframe_dict() poderia continuar retornando um dicionário de DataFrames, porém com a devida criação de tabelas temporárias realizada a partir da execução do método DataFrame.createOrReplaceTempView() para cada uma das origens. Os nomes das tabelas temporárias criadas poderiam respeitar as chaves do dicionário DATA_DICT fornecido pelo usuário na instância da classe GlueTransformationManager.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Obter tabelas temporárias criadas automaticamente para todas as origens que fazem parte do Job
• Codificar transformações usando SQL a partir das tabelas temporárias criadas
• Ter uma maior gama de possibilidades em termos de operações de transformação no Job

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• [Média] complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Criar um flag (ou um atributo da classe GlueTransformationManager) para indicar a criação (ou não) de tabelas temporárias Spark para cada origem
• Validar o flag de criação de tabelas temporárias no método generate_dataframe_dict()
• Executar o comando DataFrame.createOrReplaceTempView() para cada origem lida
• Passar a chave da origem como nome da tabela temporária criada dentro do laço for de repetição

🚀 Resumo da funcionalidade solicitada:
A cobertura de testes unitários é um indicador essencialmente importante para validar se a aplicação está realmente sendo testada em seus principais pontos de decisão. Dito isso, ter um alto valor de coverage é um indicativo positivo de que os testes unitários foram bem codificados. Essa requisição de feature nasce como uma necessidade de aumentar o coverage para 85%.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Ter em mãos um maior leque de testes unitários para serem usados e aplicados em jobs do Glue
• Maior segurança no código

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Alta complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Consultar os reports de coverage no Codecov para verificar quais partes da aplicação não estão sendo testadas
• Incrementar, aos poucos, a suíte de testes para incorporar partes do código ainda não testadas

🚀 Resumo da funcionalidade solicitada:
Operações com datas podem ser comumente encontradas em jobs de transformação de dados. Dessa forma, o pedido de feature em questão se materializa a partir da inclusão de um método (não estático) na classe GlueTransformationManager capaz de receber um atributo de data e realizar a extração de diversos outros atributos específicos, como por exemplo, ano, mês, dia, dia da semana, dia útil do mês, entre outros.

Em outras palavras, o usuário poderia querer incluir, em seu DataFrame resultante, uma quebra específica de atributos de data a partir de uma coluna única, possibilitando análises e filtros mais refinados por parte dos consumidores da base resultante. Todo este processo poderia ser implementado a partir da execução de funções de data nativas do Spark com base em diferentes formatos resultantes de data.

Visando proporcionar ideias adicionais a este pedido de feature, este método a ser construído poderia receber, como parâmetros:

• A referência da coluna de data original cujos atributos serão extraídos
• Um flag indicando se a coluna original está em um formato de string (is_str)
  • Em caso verdadeiro (is_str=True), uma conversão poderia ser feita a partir de um outro parâmetro fornecido pelo usuário contendo o formato da coluna data (date_format)
• Uma série de outros argumentos adicionais abraçados pelo parâmetro **kwargs que poderiam receber quais os atributos de data a serem extraídos no seguinte formato:
  • ano=True
  • mes=True
  • dia=True
  • dia_da_semana=True`
  • Entre outros
• Incluir sufixo de nome da coluna para nomear os novos atributos de datas criados (ex: ano_order, mes_order, etc...)

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Criar novos atributos úteis na base de dados resultante
• Trabalhar com diversas informações de data
• Criar, automaticamente, novas colunas com base em uma coluna já existente
• Contribuir com um fornecimento mais relevante de dados como produto

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Alta complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Incluir método não estático na classe GlueTransformationManager
• Adicionar regras para extração de datas a partir de coluna de data
• Gerenciar parâmetros da função passados pelo usuário para garantir a eficiência do método

🚀 Resumo da funcionalidade solicitada:
Ao entregar tabelas no catálogo de dados e democratizá-las para outros usuários, é importante mapear alguns indicadores essenciais capazes de proporcionar uma visão clara e direta sobre os ganhos e benefícios envolvidos na entrega em questão. Em outras palavras, é preciso saber se os usuários estão, de fato, utilizando e consumindo a tabela entregue para os seus mais variados propósitos e se o produto está realmente servindo os propósitos aos quais o mesmo se propunha no início do desenvolvimento.

Para isso, é preciso imaginar uma forma de conseguir mapear o consumo das tabelas entregues.

Esta requisição de feature engloba o mapeamento das possibilidades existentes e as rotas possíveis para implementar uma solução capaz de entregar uma visão de consumo das tabelas entregues.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Obter indicadores altamente relevantes de consumo da base de dados disponibilizada
• Mapear e acompanhar a efetividade de consumo das tabelas
• Garantir que os dados disponibilizados estão servindo os propósitos aos quais foram designados
• Ter um rico processo de observability para aprimoramento da tomada de decisão
• Mapear dores e propor soluções visando otimizar o consumo de dados por parte de usuários

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Extrema complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Coletar acessos no bucket alvo onde a tabela está armazenada
• Extrair logs de acesso ao bucket ou através do CloudTrail
• Construir processo sólido para transformação da informação coletada em insights relevantes para os produtores de dados
• Adicionar um módulo Terraform de observability para declarar os recursos necessários para implementação do processo de controle e extração de acessos (logs s3 ou CloudTrail)
• Trabalhar com arquivos JSON para facilitar a integração com possíveis outros sistemas de armazenamento, como o próprio s3, o DynamoDB ou outros)
• Analisar se o CloudWatch pode entregar alguma solução pronta de controle de acessos a caminhos do s3

🚀 Resumo da funcionalidade solicitada:
Com as recentes evoluções do script main-terraglue.py e as funcionalidades entregues, pode ser altamente provável encontrar aplicações Spark escritas com este template com um número extremamente elevado de linhas de código, dificultando assim a legibilidade e a manutenção do código. Dessa forma, uma ideia viável para facilitar cada vez mais as interações com o usuário final desenvolvedor do código é separar algumas funcionalidades específicas em módulos .py posicionados no diretórios /src da aplicação e lidos como módulos apartados dentro do script principal.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Ter uma aplicação principal com poucas linhas de código
• Focar apenas no desenvolvimento dos métodos de transformação da classe GlueTransformationManager
• Encapsular e tornar invisível todo o processo de preparação da classe GlueJobManager
• Navegar pelo script em uma IDE ou no AWS Management Console com maior facilidade, dado o número reduzido de linhas de código a serem desenvolvidas/analisadas
• Aumentar o nível de organização e gerenciamento do código/aplicação, separando e encapsulando tudo aquilo que não precisa de uma atuação direta do desenvolvedor/engenheiro

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Alta complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Separar todo o conteúdo da classe GlueJobManager em um script apartado
• Separar alguns métodos da classe GlueTransformationManager em um script apartado. Alguns métodos candidatos:
  • job_initial_log_message()
  • generate_dynamic_frames_dict()
  • generate_dataframes_dict()
  • add_partition()
  • write_data_to_catalog()
• Manter, no script main-terraglue.py, apenas os métodos de transformação que precisam de uma atuação direta do usuário para adaptação e inclusão das regras de transformação do Job. Métodos a serem manditos:
  • Métodos com prefixo transform_
  • run()

O processo principal ainda continuaria no seguinte formato:

if __name__ == "__main__":

    # Inicializando objeto para gerenciar o job e as transformações
    glue_manager = GlueTransformationManager(
        argv_list=ARGV_LIST,
        data_dict=DATA_DICT
    )

    # Executando todas as lógicas mapeadas do job
    glue_manager.run()

🚀 Resumo da funcionalidade solicitada:
Visando incrementar ainda mais o processo de entrega contínua já consolidado neste repositório, faz-se necessária uma análise de viabilidade para adicionar etapas de validação não apenas da aplicação do projeto, como linter, pydocstyle ou mesmo testes unitários, mas também todo o processo de definição da infraestrutura terraform presente. Para isso, é preciso considerar etapas adicionais no processo de Continuous Delivery do repositório para validar minimamente a codificação de infra implementada.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Analisar melhores práticas do GitHub Actions para validação da infraestrutura Terraform codificada em seus respectivos repositórios
• Ter uma maior segurança de que a infraestrutura terraglue provisionada está coerente e condizente com os objetivos traçados

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Média complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Consultar no marketplace de ações do GitHub para validar a presença de ações do Terraform para serem utilizadas
• Iniciar pelo processo de planejamento através do comando terraform plan
• Analisar viabilidade de colocar um processo de terraform apply para implantação automática da infra (provavelmente inviável dentro da proposta estabelecida)

🚀 Resumo da funcionalidade solicitada:
Em muitos casos, garantir a segurança do processo durante as etapas de execução de um job Glue é fundamental. Para isso, as configurações de segurança (ou security configuration) de um job contemplam especificações sobre criptografia dos dados no S3, dos logs no CloudWatch e de outros insumos necessários para a execução do processo. Adicionar uma configuração de segurança na pipeline de infra responsável por implantar o job na conta AWS alvo seria fundamental para assimiliar este elemento presente em muitas situações corporativas.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Garantir que o job Glue implantado segue as melhores práticas de segurança e criptografia dos dados

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Média complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Consultar a documentação oficial do Terraform e procurar por recursos responsáveis por garantir essa configuração
• Avaliar se essa configuração de segurança está presente como parâmetro do recurso aws_glue_job

🚀 Resumo da funcionalidade solicitada:
Entre as funcionalidades atualmente disponíveis no projeto, o script main-terraglue.py atua como uma aplicação Spark completamente codificada e fornecida como um exemplo end to end de implantação de um job do Glue na AWS. Entretanto, em cenários práticos de trabalho, principalmente encontrados em grandes companhias, é imprescindível que as aplicações implantadas na nuvem estejam atreladas a uma suíte de testes eficaz e de grande cobertura. Dessa forma, esta issue refere-se ao pedido de desenvolvimento de testes, dentro do repositório da aplicação, para que exemplificar um cenário onde o job do Glue para a geração de uma base na camada SoT com dados do e-commerce brasileiro seja submetido a testes.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Verificar as melhores práticas para o desenvolvimento de testes em aplicações que envolvem jobs do Glue na AWS
• Analisar a sintaxe e a codificação de testes via pytest
• Garantir que suas respectivas implantações também estejam vinculadas a diferentes cenários de testes
• Adaptar os testes de exemplo disponibilizado em cenários reais de trabalho

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Alta complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Analisar como implementar testes na AWS envolvendo jobs do Glue
• Analisar se a biblioteca moto proporciona mocks para o Glue
• Criar um diretório de tests/ dentro de app/ para implementação dos testes
• Desenvolver script de testes com base na biblioteca pytest
• Analisar a usabilidade de features do pytest, como @mark, @fixture, entre outras

🚀 Feature needed:
After a little while after the first terraglue disclosure, many things have changed. This issue signs the need to do a complete refactor on the repository, including changing logic, docs and many other features. The idea is to use this issue as a central point for documenting the steps taken.

🏆 Feature benefits:
With this new features, user would:

• Improve terraglue as a whole.

📚 Complexity:
The best category that fits into the development of this new feature is:

• Extreme complexity

🚀 Resumo da funcionalidade solicitada:
Em alguns casos, ambientes AWS são configurados para restringir algumas operações dos usuários de acordo com alguns critérios de segurança específicos. Dessa forma, a configuração de restrição acesso público nos buckets criados no módulo storage pode ocasionar erros de permissão por conta do recursos aws_s3_bucket_public_access_block (alguns usuários podem não ter permissão pra esse tipo de configuração).

Assim, esta requisição de feature se materializa na criação de uma variável nos módulos root e storage (arquivo variables.tf em ambos) que funciona como um flag booleano para indicar a configuração (ou não) de acesso restrito aos buckets. O valor default dessa variável seria True, mas permitiria que o usuário a alterasse de acordo com as configurações específicas do seu respectivo ambiente alvo AWS.

Posteriormente, dentro do módulo storage, essa variável seria utilizada dentro de uma condition declarada no recurso aws_s3_bucket_public_access_block para validação de sua criação.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Estabelecer configurações específicas em buckets S3 de acordo com as premissas do ambiente AWS utilizado
• Evitar erros de AccessDenied na impossibilidade de aplicar configurações específicas em buckets S3
• Garantir que os demais recursos do projeto Terraform que dependam da criação dos buckets não sofram impactos e sejam devidamente criados

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Média complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Criar uma variável booleana nos módulos root e storage
• Utilizar essa variável booleana como um flag de condição na declaração do recurso aws_s3_bucket_public_access_block

📚 Target modules, classes or functions:
Project componentes that needs a documentation improvement:

• All the markdown files in docs/ folder
• README.md

🚀 Resumo da funcionalidade solicitada:
Após uma recente descoberta no LinkedIn do usuário @cirolini sobre uma ação do GitHub capaz de integrar com o ChatGPT, esta requisição de feature visa consolidar um teste independente no terraglue para inclusão desta ação na esteira e validar seus benefícios. Link de referência: cirolini/chatgpt-github-actions

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Automatizar o code review através da ChatGPT

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Alta complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Consultar a documentação oficial no link de referência proporcionado acima

🚀 Resumo da funcionalidade solicitada:
Para um melhor gerenciamento dos processos de criptografia e configuração de segurança do job Glue (#31), é importante garantir o uso de uma chave gerenciada pelo cliente (Customer Managed Key) com permissões para criptografar dados e arquivos temporários no s3 e também logs no cloudwatch.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Aplicar a security configuration em um job Glue com CMK
• Garantir a criptografia dos insumos gerados durante a execução do job
• Ter maior liberdade no uso de chaves KMS para criptografia

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Média complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Criar CMK via KMS via Terraform
• Pesquisar sobre a política de acessos da chave para permitir as ações desejadas (s3 e cloudwatch)
• Vincular a chave KMS criada na configuração de segurança do job (modules/glue)

📚 Funções, métodos ou objetos alvo:
Elementos de código que necessitam de melhorias na documentação:

• README.md

✏️ Detalhes adicionais:
Após algumas rodadas de testes com usuários beta testers, foram identificados alguns pontos importantes relacionados a como a documentação do projeto está estruturada. Visando sempre entregar algo de valor aos usuários, faz-se necessária uma revisão na documentação para proporcionar uma jornada mais fácil de entendimento e uso da ferramenta.

Além disso, esta nova proposta de documentação deve trazer consigo uma nova gestão visual e organização dos elementos e imagens que compõem as etapas documentadas.

📚 Funções, métodos ou objetos alvo:
Elementos de código que necessitam de melhorias na documentação:

• Arquivo EXAMPLES.md na raiz do repositório

✏️ Detalhes adicionais:
Este arquivo serve como uma forma de consolidar as principais possibilidades de uso do terraglue como produto e solução. Uma ideia inicial de table of contents para este arquivo pode ser visualizada abaixo:

• Antes de começar
• Cenário 1: um primeiro passo na análise dos recursos
  • Buckets SoR, SoT, Spec e outros
  • Dados na camada SoR
  • Catalogação no Data Catalog
  • Athena workgroup
  • IAM policies e roles
  • Glue job
  • Dados na camada SoT
• Cenário 2: aprendendo mais sobre o runtime Terraform
  • O módulo storage
  • O módulo catalog
  • O módulo iam
  • O módulo glue
• Cenário 3: compreendendo detalhes de um job Spark no Glue
  • A classe GlueJobManager
  • A classe GlueTransformationManager
• Cenário 4: implementando seu próprio conjunto de dados
  • Utilizando dados próprios
  • Visualizando efeitos na conta AWS
• Cenário 5: implementando seu próprio job do Glue
  • Codificando novas transformações
  • Executando jobs próprios

🚀 Resumo da funcionalidade solicitada:
A cobertura de testes unitários é um indicador essencialmente importante para validar se a aplicação está realmente sendo testada em seus principais pontos de decisão. Dito isso, ter um alto valor de coverage é um indicativo positivo de que os testes unitários foram bem codificados. Essa requisição de feature nasce como uma necessidade de aumentar o coverage para 92%.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Ter em mãos um maior leque de testes unitários para serem usados e aplicados em jobs do Glue
• Maior segurança no código

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Alta complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Consultar os reports de coverage no Codecov para verificar quais partes da aplicação não estão sendo testadas
• Incrementar, aos poucos, a suíte de testes para incorporar partes do código ainda não testadas

🚀 Resumo da funcionalidade solicitada:
Este pedido de feature refere-se à inclusão, no módulo glue do projeto Terraform, de recurso responsável pelo agendamento do job do Glue de acordo com parâmetros passados pelo usuário e definidos nos arquivos variables.tf. Com isso, uma maior completude da jornada de utilização de jobs do Glue poderá ser evidenciada ao usuário, permitindo ter em mãos um exemplo completo não apenas de implantação de jobs, mas também de agendamento do mesmo.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Agendar jobs do Glue
• Avaliar como a declaração e configuração de agendamento de um Job pode ser feita no Terraform

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Média complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Pesquisar na documentação do Terraform como agendar jobs do Glue
• Incluir parâmetros de configuração nos arquivos de variáveis dos módulos root e glue do projeto

🚀 Resumo da funcionalidade solicitada:
Em dinâmicas práticas envolvendo a utilização do Glue para os mais diversos processos de ETL, é provável encontrar situações onde os dados de origem do processo estão armazenados como tabelas em bancos de dados relacionais no RDS. Assim, faz-se necessária uma funcionalidade capaz de endereçar a leitura de dados com este tipo de origem, permitindo obtê-los e transformá-los nos objetos básicos de trabalho (DynamicFrames ou DataFrames).

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Configurar a leitura de dados presentes em um banco de dados RDS
• Adicionar maiores possibilidades de criação de jobs através da utilização de dados em múltiplas origens

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Alta complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Analisar formas de realizar a leitura de dados em bancos RDS através do SDK boto3
• Verificar formas de conexão nativas entre Glue e RDS
• Garantir que as permissões de acesso à bancos RDS estão presentes na role IAM do job Glue

📚 Funções, métodos ou objetos alvo:
Elementos de código que necessitam de melhorias na documentação:

• Arquivo ppt presente em docs/ppt/terraglue-presentation-pitch.pptx

✏️ Detalhes adicionais:
Como forma de globalizar o uso do terraglue como projeto, é essencial ter um pitch ou uma apresentação oficial que possa ser utilizada e/ou consumida por usuários para um melhor entendimento da solução.

🚀 Feature needed:
This issue signs an opportunity to create unit tests for the Spark application deployed as a Glue job in the project. As the Spark application is now using sparksnake package and a new auxiliar module transformers.py, when users calls the terraglue module with mode="learning", it's important to ensure that the Spark application deployed works as expected.

🏆 Feature benefits:
With this new features, user would:

• Improve the user experience when calling the module with learning module
• Ensure that the transformation steps on the Spark application work as expected

📚 Complexity:
The best category that fits into the development of this new feature is:

• High complexity

💡 Ideas on how to develop it:
To develop this new feature, would be possible to:

• Search for best practices to test Glue jobs
• Use the pytest Python package

🚀 Resumo da funcionalidade solicitada:
De acordo com a recente novidade divulgada no AWS re:Invent 2022 sobre o Glue Data Quality, esta requisição de feature está relacionada à análise e studo sobre a possibilidade de inclusão de elementos do Glue Data Quality dentro do job Glue criado e disponibilizado para transformação de dados de E-Commerce.

🏆 Resumo sobre benefícios da nova funcionalidade:
Com a implementação dessa nova funcionalidade, os usuários poderiam:

• Analisar as melhores práticas de inclusão de regras de qualidade dos dados através do Terraform
• Incluir uma camada de qualidade no processo de geração de dados a partir de jobs do Glue

📚 Provável complexidade:
A melhor opção que descreve a complexidade associada a esta funcionalidade é:

• Extrema complexidade

💡 Ideias de implementação:
Para implementação da funcionalidade, seria possível:

• Verificar se a feature Glue Data Quality já está disponível para uso
• Verificar se já existem APIs disponibilizadas para serem chamadas a partir de ferramentas de IaC (como o Terraform)
• Analisar se o Terraform possui um resource disponível para inclusão de insumos do Glue Data Quality
• Analisar e a inclusão de insumos do Glue Data Quality em um job do Glue se dará a partir de um novo resource ou através de parâmetros dentro do resource de job do Glue já existente