Jump to content

kassia.andrade

Pessoal da TecnoSpeed
  • Contagem de Conteúdo

    7
  • Ingressou

  • Última visita

  • Dias Ganhos

    1

kassia.andrade ganhou o dia em Outubro 20 2023

kassia.andrade teve o conteúdo mais curtido!

Informações Pessoais

  • Cidade
    Maringá
  • Estado
    Paraná (PR)

Clientes & Parceiros

  • Você é um cliente TecnoSpeed?
    Não
  • Você é um parceiro da Casa do Desenvolvedor?
    Não

Visitantes Recentes do Perfil

O bloco de visitantes recentes está desativado e não está sendo mostrado a outros usuários.

Conquistas de kassia.andrade

  • Ótima Reputação Raro
  • Positividade Raro

Emblemas Recentes

11

Reputação na Comunidade

  1. kassia.andrade

    Data Mesh

    Olá, tudo bem? Hoje falarei um pouco sobre a aboradagem do Data Mesh. O Data Mesh é um conceito novo, que parte do princípio em que os dados são vistos como Produto. Nessa abordagem a arquitetura de dados funciona de forma descentralizada, em oposição ao uso do Data Warehouse que concentra informações em um local centralizado. O grande objetivo do Data Mesh é permitir uma maior escalabilidade na analise de dados , garantindo o compartilhamento e disponibilidade dos dados de uma forma mais rápida e eficaz dentro e fora da organização. Procura responder toda complexidade e volatilidade de uma empresa de grande porte, mantendo a agilidade diante do crescimento aumentando a proporção do valor dos dados em relação ao investimento. Atualmente, e em grande parte das empresas, temos o modelo de arquitetura de dados centralizada, contendo uma equipe especializada em tratar os dados e transforma-los em produto(informação). Na abordagem do Data Mesh, essa equipe centralizada continuaria com o trabalho de analise mas cada parte da organização teria a obrigação de gerar dado como produto, fazendo com que os dados se tornassem disponíveis quase que em tempo real, pois os dados sairiam da fonte já como produto pronto para uso em analise, seja para a criação de relatório, responder chamados de clientes com base em informações específicas ou Machine Learning. Nessa arquitetura, o dado não passaria por todo o processo de ETL como é feito no formato centralizado de extração de dados da fonte, processamento, tratamento e armazenamento. O dado sairia pronto da fonte para uso, reduzindo o tempo de tratamento deste, ocasionando assim na rapidez da disponibilidade desse produto de dados. Algumas características do Data Mesh: Sistemas operacionais e analíticos são integrados. Os dados são vistos como Produto. Estrutura de dados descentralizada. Acessibilidade aos dados quase em tempo real. Dados e código como uma unidade e não como um subproduto de dados do código. Dados como um produto para compartilhar e não como ativo a ser coletado. Por fim, o Data Mesh ainda é pouco implementado e é uma abordagem um tanto utópica em alguns aspectos. Seria um sonho termos dados disponíveis em um curto espaço de tempo sem gasto de tempo em tratamento e processamento dos dados. Em contrapartida, para que isso fosse possível seria necessário equipes especializadas em dados dentro de todos os departamentos da empresa de forma descentralizada,uma arquitetura com fonte de dados interligada com as demais fontes e uma grande mudança na cultura de dados, consequentemente implicando em um custo um tanto alto. Agora reflita um pouco..será que uma arquitetura descentralizada seria a resposta para muitos problemas de processamento, pipeline e burocracia na área de dados ? Referencia: Data Mesh(entregando valor em escala e orientado a dados) por Zhamak Dehghani.
  2. Olá pessoal , tudo bem ? Nesse artigo falarei sobre o conceito de Big data. Para um melhor entendimento irei começar abordando os 5 "V". Velocidade,Volume, Variedade, Veracidade e Valor. Velocidade: Velocidade na coleta , organização , tratamento e analise dos dados. Volume: Se refere ao tamanho desses dados que podem ser gigantescos em alguns senários. Variedade: É o formato como esse dado esta disposto, podendo ser imagem , video , texto , audios e afins. Veracidade: Se refere a qualidade e confiabilidade dos dados. Esses dados podem vir bem bagunçados da fonte e é preciso trata-los para trazer crediilidade na analise. Valor: O valor que será agregado na analise , o retorno que esta analise trará para organização. Em um rapido resumo do conceito abordando os 5 "V", imaginaremos um cenario (curtidas, postagens e comentários do facebook..instagram) com inumeros tamanhos(Volume) e tipos diferentes(Variedade) de dados como videos , fotos, textos ,img. etc.. sendo armazenados em um curto espaço de tempo(Velocidade) em um banco de dados. Outro ponto , esses dados não estão vindo em formato normalizado é preciso trata-los.(Veracidade) A maioria desses dados vão para bancos NoSQL como Neo4J , MongoDB por ser tratar de bancos que permitem acesso rápido a dados não estruturados. Após esse armazenamento , entram em cena profissionais como Analistas e Cienctistas de dados , Engenheiro de ML(machine learning) para retirar (Valor e Veracidade) dos dados aramazenados, entregando um resultado final de informação que podem ser entregues em diversos formatos como gráficos, paineis ou planilhas (Visualização dos dados). Por fim, as utilidades do Big Data são imensas e amplamente utilizadas nos dias de hoje. Como recomendação de produtos ,prever trafego de automoveis , analise de imagens sensiveis etc. E apartir dessa utilização de dados surge outra problematica , da privacidade dos dados que não irei abordar neste artigo. (Refiltam!)
  3. Olá pessoal , tudo bem ? Nesse artigo falarei sobre as cores utilizadas na construção de um gráfico. Na hora de criar um gráfico as cores não parecem ser tão importantes mas elas fazem uma grande diferença na rapidez do entendimento do usuário final ao receber a informação. Oque é um Dashboards?: O dashboard é composto por gráficos. Oque é um Gráfico?: O gráfico compõe o dashboard. Ao apresentar dados de comparação como no exemplo na imagem baixo: Existe uma comparação entre os meses , quando ele atinge a meta (a linha verde) ele mostra a cor azul e quando não atinge mostra a cor vermelha que significa alerta. Rapidamente o usuário entende que precisa investigar oque ocorreu naqueles meses vermelhos. No caso anterior, a cor vermelho e azul são cores opostas representando a conotação negativa/positiva. No caso abaixo, temos um gráfico de categorias: Na imagem acima, esta mostrando uma porcentagem por categorias de modalidade de transporte, nesse caso foi escolhido várias cores para compor as categorias. Prefira utilizar cores de intensidade quando precisar destacar algo que exista uma categoria para ser mostrada. Como no exemplo abaixo, mesmo usando uma tonalidade mais simples como o cinza ,essa intensidade de cores proporciona uma melhor organização da informação visto que é um gráfico informativo de categorias e não de comparativo como no exemplo anterior. Nesse caso pode ate usar cores do logo da empresa ou da causa, como por exemplo tonalidade de azul para uma instituição financeira ,pois a cor azul tende a passar segurança ou uma tonalidade de verde se o painel abordar causas ambientais por exemplo. Mas caso a cor da marca seja vermelha, essa cor é uma cor considerada de alerta na cultura ocidental , portanto o recomendado é usa-la somente fora do gráfico. Como, por exemplo, nas bordas de um dashboard como na imagem abaixo. Para finalizar pense em seu publico alvo , se houver um daltônico entre os usuários do dashboard prefira usar a combinação de laranja e azul, e evitar usar as combinações de roxo e azul ou vermelho e marrom , pois para o daltônico essas cores podem parecer iguais, então se o objetivo era mostrar cores antagônicas ,isso pode ir por agua a baixo. Prefira criar um gráfico com fundo branco para que a informação se destaque , evite usar o fundo colorido pois muitas vezes pode deixar a informação um tanto apagada ou bagunçada. Com algumas dicas simples o dashboard/gráfico pode se tornar atraente para o usuário final.
  4. Olá pessoal, tudo bem ? Quem nunca se deparou com um código legado e demorou um pouco para entender mesmo com um bom conhecimento da linguagem em questão? Vou citar alguns steps simples utilizando a linguagem SQL como exemplo para termos códigos clean pensando sempre em quem vai ler este no futuro. Algumas questões para considerar: 1 - Indentação Procure organizar seu código, quanto maior for o código maior a dificuldade de compreensão. Por isso sempre deixe organizado de uma forma lógica e de fácil entendimento. Exemplo de cógigo sem indentação: SELECT tabela_exemplo1.a,tabela_exemplo1.c,tabela_exemplo2.b, row_number() over (partition by tabela_exemplo2 order by data_a desc) --comentários FROM tabela_exemplo1 Exemplo de código indentado: SELECT tabela_exemplo1.a, tabela_exemplo1.c, tabela_exemplo2.b, row_number() over (partition by tabela_exemplo2 order by data_a desc) --comentários FROM tabela_exemplo1 2 - Formatos acessíveis. Procure utilizar CTEs ao invés de subqueries. As CTEs começam de cima para baixo, as subqueries começam do meio do código e vai irradiando para cima e para baixo,o que torna um pouco mais demorado para entender conforme o tamanho do código. Se preferir criar subqieries não há problema desde que o código esteja devidamente comentado,indentado, com alias adequados e reduzido ao máximo, evitando pergaminhos. Exemplo de CTE: with motivos_tbA_tbB as ( --começo do código SELECT tabela_exemplo1.a, tabela_exemplo1.c, tabela_exemplo2.b, row_number() over (partition by tabela_exemplo2 order by data_a desc) FROM tabela_exemplo1 LEFT JOIN tabela_exemplo2 ON tabela_exemplo1.a= tabela_exemplo2.a LEFT JOIN tabela_exemplo3 datas ON tabela_exemplo3.data = date_trunc('month',tabela_exemplo2.data) LEFT JOIN shop_cadempresa ON shop_cadempresa.handle = shop_contratos.id_empresa ) SELECT COUNT (c) qtd_vendida , --final do código a AS motivo_venda FROM motivos_tbA_tbB Exemplo de Subquery: SELECT COUNT (c) qtd_vendida , --final do código a AS motivo_venda FROM ( SELECT --começo do código tabela_exemplo1.a, tabela_exemplo1.c, tabela_exemplo2.b, row_number() over (partition by tabela_exemplo2 order by data_a desc) FROM tabela_exemplo1 LEFT JOIN tabela_exemplo2 ON tabela_exemplo1.a= tabela_exemplo2.a LEFT JOIN tabela_exemplo3 datas ON tabela_exemplo3.data = date_trunc('month',tabela_exemplo2.data) LEFT JOIN shop_cadempresa ON shop_cadempresa.handle = shop_contratos.id_empresa ) motivos_tbA_tbB 3 - Comentarios úteis. Crie comentários uteis no código, caso seja uma formula complexa ou que exija uma explicação maior faça um breve comentário e coloque a explicação da lógica na propria documentação do código. 4 - Alias uteis e não x, y ,z .. Na correria do dia dia é mais fácil colocar um x,y..z mas isso não deixa muito claro a lógica do código pra quem vê pela primeira vez. Exemplo de alias sem identificação : select --parte3 * from ( select --parte 2 * FROM ( select --parte 1 * from A where ativo is true )x )y Exemplo de alias com identificação: with contratos_ativo as ( --parte 1 select * from A where ativo is true ), clientes as ( --parte2 select * from contratos ) select --parte 3 * from clientes 5 - Tamanho do código. Procure enxugar ao máximo o código para não virar o famoso pergaminho. Exemplo final: with motivos_tbA_tbB as ( SELECT tabela_exemplo1.a, tabela_exemplo1.c, tabela_exemplo2.b, row_number() over (partition by tabela_exemplo2 order by data_a desc) /*faça comentarios uteis */ FROM tabela_exemplo1 LEFT JOIN tabela_exemplo2 ON tabela_exemplo1.a= tabela_exemplo2.a LEFT JOIN tabela_exemplo3 datas ON datas.data = date_trunc('month',tabela_exemplo2.data) --caso queria dar um alias na tabela não tem problema desde de que seja um nome util e não x..z..y LEFT JOIN shop_cadempresa ON shop_cadempresa.handle = shop_contratos.id_empresa ) SELECT COUNT(c) qtd_vendida, a AS motivo_venda FROM motivos_tbA_tbB WHERE row_number = 1 /*faça comentarios uteis */ GROUP BY 2 ORDER BY 1 ASC Um código bem documentado poupa tempo de leitura,entendimento e manutenção ao se tornar um legado. A indentação ajuda a achar as palavras chaves no código de uma forma mais rápida, a organização do código começando de uma forma lógica de cima pra baixo usando a CTE ajuda a encontrar mais rápido os pontos chave do código e usando alias que represente cada parte do código ajuda a entender melhor a lógica usada e consequentemente oque esta acontecendo na query,ficando mais claro o entendimento.
  5. Olá pessoal, existem vários truques para lidar com o tratamento de dados seja esse em linguagem Python , R ou SQL. Um dos comandos que vou apresentar hoje é o SELECT INTO do SQL. Existem algumas situações em que esse comando é bem útil em bancos de analise onde temos várias fontes de dados. Lembrando que não é recomendado o uso deste comando em bancos em produção. Comando: SELECT INTO FROM Exemplo de caso: Na tabela_original temos dados duplicados, e uma reimportarão destes dados resultaria em horas de extração pois são muitos registros. Nesse caso, passamos esses dados com distinct para desduplicar os dados para a tabela_temporaria utilizando o comando SELECT INTO. Agora temos a tabela_temporaria com os dados certos sem duplicação. Segundo passo, removemos os dados da tabela_original onde os dados estão ainda duplicados, e por fim utilizamos novamente o comando SELECT INTO para exportar esses dados já corrigidos da tabela_temporaria para a tabela_original. Exemplo pratico: SELECT DISTINCT * INTO tabela_temporaria FROM tabela_original drop table tabela_original select * into tabela_original from tabela_temporaria Esse truque simples pode poupar muito tempo quando há a necessidade de exportar dados de uma tabela para outra.
  6. Olá pessoal , tudo bem? Vou falar um pouco sobre o uso da funcionalidade de CTEs dentro do Metabse. Existe uma forma dentro do ambiente Metabase que é possível criar uma CTE (referenciar uma query existente ) onde os demais componentes do dashboard irá sempre chamar esta query principal sem a necessidade de escrever todo código SQL novamente. desde que não exista filtros no dashboard. Passo a passo: COMPONENTE 1: Crie a query normalmente. exemplo: SELECT * FROM orders AS o INNER JOIN products AS p ON o.product_id = p.id WHERE p.category = 'blabla' AND o.created_at BETWEEN '2019-01-01' AND '2019-12-31' COMPONENTE 2: No componente que irá referenciar a query acima somente crie {{#}} no where da query e selecione no canto direito na aba variables no filtro dropdown question# o nome do componente onde esta a query principal, assim é possível fazer a ligação entre as queries : SELECT * FROM {{#}} Simples, fácil e poupa tempo. Agora o componente 2 consegue acessar a query do componente 1 como se fosse uma CTE. Ponto negativo, havendo a necessidade de ter um filtro de período de data no dashboard , por exemplo, não seria possível utilizar essa lógica. Se na query principal existir um filtro , este não surtira efeito no componente que referencia a query principal. O que pode mudar a qualquer momento com as atualizações da ferramenta , muitas funcionalidades podem ser melhoradas e adicionadas a cada atualização. Se a funcionalidade de CTE for capaz de aceitar filtros , então essa técnica seria muito valiosa para poupar código e tempo e aumentar a produtividade.
  7. Olá pessoal , tudo bem? Vou falar um pouco sobre CTEs e seus benefícios para as boas práticas de documentação. Oque é uma CTE? CTE é uma expressão de tabela comum, derivada de uma consulta simples. Sintaxe: [ WITH <common_table_expression> [ ,...n ] ] <common_table_expression>::= expression_name [ ( column_name [ ,...n ] ) ] AS ( CTE_query_definition ) Porque usar CTE? Visando as boas práticas para manutenção do código SQL, as CTEs são mais fáceis de ler por terem uma lógica de começo e fim melhor definida, desde que estejam devidamente indentadas. Facilitam o entendimento e debugação da query SQL. Como usar as CTEs? O ideal é sempre que usar uma CTE , a proxima corresponda a última CTE criada, desse jeito será bem fácil de identificar as informações ao debugar a query. Use sempre nomes que façam sentido para as CTEs , evite usar s1, tb2 ..etc.., lembre-se quem esta lendo seu código precisa entende-lo! Se houver mais de uma CTE , a anterior deverá ser seguida de virgula antes de começar a próxima. Exemplo de uso da CTE: WITH vendas_cte AS -- Definição da primeira CTE ( SELECT id_vendedor SUM(valor_total) AS valor_total_vendas, YEAR(adata) AS ano_vendas FROM vendas.vendas_pedidos WHERE id_vendedor IS NOT NULL GROUP BY id_vendedor, YEAR(data) ) , /*Use a virgula para separar uma CTE da outra Define a segunda query, onde não usamos mais o WITH , o WITH é utilizado apenas no começo. A partir da segunda CTE utilizamos apenas o nome da CTE seguida de 'as'. Essa CTE retorna dados de venda por ano e por pessoa */ vendas_quota_cte AS ( SELECT id_empresa, SUM(quota_vendas) AS quota_vendas, YEAR(data) AS quota_vendas_ano FROM vendas.historico_quota_vendedor GROUP BY id_empresa, YEAR(data) ) --definição de query normal que utiliza as duas CTEs anteriores como tabela SELECT id_vendedor , ano_vendas , FORMAT(valor_total_vendas,'C','en-us') AS total_vendas , quota_vendas_ano , FORMAT (quota_vendas, 'C' ,'en-us') AS quota_vendas , FORMAT (valor_total_vendas -quota_vendas, 'C','en-us') AS acima_abaixo_quota FROM vendas_cte JOIN vendas_quota_cte ON vendas_quota_cte.id_empresa = vendas_cte.id_vendedor AND vendas_cte.ano_vendas = vendas_quota_cte.quota_vendas_ano ORDER BY id_vendedor, ano_vendas; Comaparação de CTE e subquery: Exemplo de CTE: with detalhes as ( select id_usuario, nome, row_number() over (partition by id_usuario order by data_atualizacao desc) as rank_detalhe from billingdaddy.billing_stored_details ), atualizacoes as ( select id_usuario, nome from detalhes -- a segunda CTE chama a primeira CTE e assim por de ante where rank_detalhe = 1 ) select * from atualizacoes Exemplo de subquery: Nesse exemplo existe apenas uma subquery, imagine várias subqueries como seria confuso de debugar. select id_usuario, nome from ( select id_usuario, nome, row_number() over (partition by id_usuario order by data_atualizacao desc) as rank_detalhe from billingdaddy.billing_stored_details ) atualizacoes where rank_detalhe = 1 Limitações da CTE: Não suporta INSERT, UPDATE, DELETE e MERGE, apenas instrução SELECT. Não é possível utilizar cláusula ORDER BY , exceto quando uma cláusula TOP é especificada. Concluindo ..não é só no mundo do desenvolvimento que é necessário criar códigos legíveis e de fácil manutenção, no universo da analise de dados ,principalmente em scripts SQL também existe essa necessidade. Crie sempre sua query pensando no legado ,independentemente da linguagem utilizada, lembre-se que sempre terá alguém que precisará ler e entender seu código.
×
×
  • Create New...