Soluções com Foco no Usuário

No meu post Como foi ser um Estagiário de Dados?, compartilho um resumo da minha jornada e cito que além dos dashboards no Power BI foram necessárias soluções amigáveis para analistas com e sem conhecimento em linguagens de programação e SQL, que queriam explorar os dados em suas próprias análises ou precisavam extrair relatórios.

Recriei as soluções e estou utilizando os dados dos meus projetos de estudo spotifEx e waypointEx.

Reportium

Reportium possibilitava a extração de um arquivo "csv" com base na regra de negócio vigente no pipeline de dados, especificada pelo analista. Inicia solicitando as datas "inicial" e "final" do período de interesse, e em seguida, mostra a quantidade de registros localizados. Pensei que a visualização dessa informação aliada a percepção da velocidade que o arquivo foi gerado, poderia trazer conhecimento sobre os limites do hardware quanto a memória e processamento. Por fim, solicita o local desejado para salvar o arquivo.

Criei usando Python com as bibliotecas FreeSimpleGUI e PyArrow, além da API que fornece os dados. A versão que é apresentada na imagem, está rodando no Ubuntu. O sistema operacional lá era o Windows e por isso transformei em um executável (.exe) usando o PyInstaller, para que o usuário não precisasse ter o Python instalado no computador.

Apache Drill

Alguns analistas tinham algum conhecimento em SQL e queriam uma liberdade maior ao consumir os dados, mas sem escrever consultas grandes e complexas. Inicialmente seria diretamente no PostgreSQL, nosso Data WareHouse, mas não era possível ocultar os schemas que o usuário não tinha autorização. A solução era um equilíbro entre: parecer que está conectado no banco de dados, acessar só o necessário e sem escrever muito SQL.

Apache Drill é um mecanismo de consulta SQL que permite fazê-lo diretamente em JSON, Parquet, CSV, Object Storage como S3 e MongoDB, sendo leve e excelente para consultas ad-hoc. Comecei minhas pesquisas pensando em usar o Trino, mas ele parecia muito para o que eu tinha em mente. Queria começar pequeno e escalar caso fosse necessário, e Drill se sai bem como nó único.
Aproveitando o próprio pipeline de dados, uma etapa resolvia as complexidades existentes na solicitação do analista e gerava um arquivo parquet, que era salvo em um volume compartilhado com o Drill.

Para melhorar a experiência do usuário, além da reunião de entrega/treinamento, um membro da equipe criou um manual para que os analistas tivessem por escrito como configurar e se conectar, e montamos um "kit" compactado com: material escrito, Dbeaver Portable, driver para o Drill (drill-jdbc.jar) e um arquivo .sql com consultas prontas, para alterar somente os parâmetros.

GraphiQL

Enquanto desenvolvia a API que compartilho nos posts intitulados Começando uma API para Self-Service BI, vi em GraphiQL uma possibilidade de uso pelos analistas com algum conhecimento em linguagens de programação, restando apenas escrever resolvers amigáveis que gerariam queries amigáveis, melhorando a qualidade da experiência. Deveria priorizar como o usuário gostaria de pedir os dados e não como os dados estavam guardados, democratizando o acesso.

GraphiQL é um ambiente visual e interativo que roda no navegador e é usado para consultar APIs GraphQL, sendo a ferramenta padrão para quem quer escrever, testar e documentar as consultas. Tem autocompletar inteligente e um painel lateral de "Docs" que é gerado automaticamente ao se conectar na API, refletindo o que está no backend, facilitando o entendimento de como os dados estão conectados no servidor.

R-Conn

R-Conn facilitava que os analistas usando o R fizessem conexões ao PostgreSQL e ao Apache Impala sem complexidades e muitas linhas de código, com suas credenciais de conexão em variáveis de ambiente e uma forma padronizada de se conectar, para que eles se preocupassem somente com a análise dos dados. Para facilitar ainda mais começamos a experimentar dbplyr e implyr, que traduzem código com sintaxe do dplyr para SQL.

notifEx

notifEx tinha como foco meu coordenador e os pares que trabalhavam diretamente nos pipelines de dados. Eles não achavam fácil verificar na interface do Apache Airflow se o pipeline havia concluído com sucesso, e se não, qual tinha sido o erro, e em qual task. Cogitamos enviar notificações por e-mail, mas pareceu menos custoso a longo prazo ter um painel compartilhado onde todos poderiam ter a mesma informação. No exemplo mostrado, recriei um pouco diferente, mas se estivesse verde, rodou com sucesso, e se vermelho, deu erro... e informava a DAG, a task e o erro.

Criei usando Python e a API do Google Calendar configurada no Google Cloud.

Melhorar a experiência do usuário tem que ser um dos objetivos!
Recebemos feedbacks positivos como:
   -  Agora temos acesso aos dados com facilidade!
   -   Houve diminuição no tempo de entrega dos relatórios.
   -   Estamos experimentando criar nossas próprias visualizações!

O início da democratização dos dados, permitindo que usuários de negócio acessem, explorem e visualizem dados sem depender de muitos conhecimentos técnicos.

Hoje, busco alinhar tecnologias e arquiteturas que diminuam gargalos de performance e custos com a experiência amigável de quem vai consumir os dados.

Porque no final das contas se o usuário não usar a solução, como será extraído o valor?

E você, o que achou? Como faria?
Obrigado pela leitura.