Como reduzir a carga do DB operacional e garantir a segurança dos dados com o Redash

Se você é um engenheiro solo que, cansado de esperar pela aprovação de pagamento de ferramentas de BI pagas, decidiu implementar seus próprios dashboards no pipeline, o Redash é a alternativa mais realista. No entanto, você não deve se limitar a apenas visualizar os resultados das consultas. No momento em que uma consulta de agregação pesada paralisa o banco de dados (DB) operacional ou informações sensíveis de clientes são expostas em um dashboard compartilhado com a equipe de marketing, as portas do inferno se abrem. Reuni aqui métodos de configuração específicos para garantir estabilidade de nível empresarial, economizando o orçamento de infraestrutura.

Implementando cache de consultas para isolar a carga do DB operacional

Situações em que consultas analíticas causam falhas no serviço são comuns em startups em estágio inicial. Executar consultas com joins complexos no DB operacional todas as vezes é perigoso. Usando o Query Results Data Source (QRDS) do Redash, você pode separar fisicamente a carga aplicada ao servidor operacional. O QRDS funciona movendo os dados de origem para o mecanismo SQLite interno do Redash para processamento.

Na prática, mesmo em especificações de nível AWS t3.medium, o uso do QRDS pode reduzir a carga do DB em mais de 80%. Primeiro, ative o QRDS nas configurações de fonte de dados. Escreva uma consulta de agregação pesada, memorize o número do ID dessa consulta e, em seguida, chame-a em outra janela de consulta no formato SELECT * FROM cached_query_123. A estrutura faz com que o DB operacional seja consultado apenas uma vez, enquanto os usuários do dashboard visualizam apenas o resultado em cache.

Um ponto de atenção aqui é o gerenciamento dos background workers. Um worker do Celery consome geralmente de 200MB a 400MB de memória ao processar resultados de consulta. Se o número de consultas aguardando no caminho /status.json continuar aumentando, você deve ajustar o WORKERS_COUNT. Tenha cuidado, pois se você aumentar apenas os workers quando houver falta de memória, a instância irá travar.

Prevenindo acidentes com separação de permissões e mascaramento

O compartilhamento de dados é uma faca de dois gumes. Ao conceder permissões às equipes de marketing ou planejamento, você deve obrigatoriamente criar e atribuir um grupo "View Only". A prioridade é impedir que eles modifiquem consultas por engano ou vasculhem a estrutura das tabelas.

Para bloquear incidentes de segurança na fonte, crie uma nova conta de nível "Read-only" com apenas permissões de SELECT no nível do mecanismo de banco de dados. Em seguida, para informações sensíveis como e-mails ou números de telefone, defina uma View que processe o mascaramento usando a função CONCAT do SQL, como jo**@gm****.com. Conecte o Redash apenas a esta View. O analista obterá as métricas estatísticas necessárias, mas ficará em um estado onde nunca poderá ver os dados originais.

Ataques externos são defendidos com configurações do Nginx. O básico é bloquear qualquer acesso fora do IP fixo da empresa e da faixa da VPN interna com a diretiva deny all. Além disso, ativar a variável de ambiente REDASH_DISABLE_PUBLIC_URLS pode evitar situações em que URLs públicas são criadas sem o conhecimento do administrador, causando vazamento de dados para o exterior.

Aumentando a velocidade de percepção de falhas com integração ao Slack

Dashboards não fazem sentido apenas quando você está olhando para eles. Quando uma métrica específica ultrapassa um limite, o sistema deve falar com você primeiro. Ao conectar o recurso Redash Alert com um Webhook do Slack, os desenvolvedores podem intervir imediatamente em caso de taxas de falha de pagamento ou erros no servidor.

Ao incluir {{ALERT_NAME}} e {{QUERY_RESULT_VALUE}} no modelo de mensagem de alerta, é possível entender a gravidade da situação apenas olhando para a mensagem no Slack. Com este sistema, o tempo levado desde a percepção da falha até o início da depuração é reduzido para menos da metade.

No entanto, se você enviar notificações para todas as variações, acabará ignorando as mensagens devido à "fadiga de alertas". Use a configuração Just Once para ajustar as notificações para que ocorram apenas quando a métrica ultrapassar o limite pela primeira vez e quando retornar ao normal. Se você inserir no código da consulta uma lógica que calcula a taxa de aumento em relação ao período anterior em vez de valores absolutos, será conveniente pois não precisará modificar o limite toda vez que o serviço crescer.

Design de parâmetros para um ambiente de autoatendimento

Se você está perdendo uma ou duas horas por dia com solicitações simples de extração de dados, isso é prova de que não está usando os parâmetros de consulta corretamente. Ao inserir uma sintaxe como {{ date_range }} na consulta, um widget de seleção de data aparecerá no topo do dashboard. Permita que funcionários de áreas não técnicas extraiam dados alterando o período por conta própria.

Para evitar erros de consulta causados por erros de digitação, recomenda-se o tipo Dropdown List. Para dados que mudam frequentemente, como listas de produtos, conectar uma Query Based Dropdown List manterá a lista atualizada automaticamente.

Por questões de segurança, é recomendável evitar o tipo de entrada de texto livre. Como isso pode ser um canal para ataques de SQL Injection, o Redash permite isso de forma limitada apenas para administradores. Para dashboards de usuários comuns, é mais seguro posicionar apenas seletores de data ou dropdowns onde apenas valores validados podem ser escolhidos. Ao criar esse ambiente, o desenvolvedor ganha tempo para se concentrar apenas na implementação da lógica central.