[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.

[Um Pouco sobre o conceito de Big Data]

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!)

 

[Uso de cores certas em gráficos]

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. 

[SQL Clean - passo a passo para uma boa documentação]

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.

[Truque simples no tratamento de dados duplicados]

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. 

[Utilização do conceito de CTE dentro do metabase]

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.  

 

[Prefira usar CTE ao invés de subqueries]

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.