Escolha granularidade numa coluna ou tabela com base nos requisitos
A granularidade é uma das decisões de design mais críticas que tomas ao construir um modelo de dados. Define o nível de detalhe capturado nas suas tabelas e afeta diretamente os custos de armazenamento, o desempenho das consultas e as perguntas analíticas que pode responder. Como engenheiro de dados, compreender a granularidade ajuda-o a desenhar tabelas que cumpram os requisitos de negócio mantendo operações eficientes.
Esta unidade explica o que significa granularidade no contexto da modelação dimensional e como avaliar diferentes opções de granularidade com base nos requisitos da sua organização.
Compreenda o que a granularidade representa
Granularidade, por vezes chamada de "grão", descreve o nível de detalhe que cada linha de uma tabela representa. Numa tabela de factos, o nível de detalhe define qual evento de negócio ou medição é capturado por cada linha. Numa tabela de dimensões, o grão determina como as entidades são representadas e versionadas.
Considere um cenário de dados de sensores IoT. Pode desenhar a sua tabela de factos em diferentes níveis de granularidade:
Granularidade ao nível do milissegundo: Cada linha representa uma única leitura do sensor captada ao nível do milissegundo. Isto recolhe a informação mais detalhada, incluindo carimbos temporários precisos, valores dos sensores e identificadores de dispositivo para cada medição.
Segunda granularidade agregada: Cada linha representa o valor médio, mínimo ou máximo do sensor para um dispositivo por segundo. As leituras individuais são resumidas em estatísticas por segundo.
Granularidade agregada por minuto: Cada linha representa estatísticas agregadas de sensores para um dispositivo durante um minuto total. Isto proporciona menos detalhes, mas requer menos armazenamento.
O grão que escolhes afeta tudo a jusante. Uma vez que perdes detalhes por agregação, não consegues recuperá-los. Se a sua tabela agregada por minutos mostrar que o sensor X teve uma temperatura média de 75°C durante um minuto específico, não pode determinar quais milissegundos tiveram picos de temperatura nem identificar o momento exato em que ocorreu uma anomalia.
Avaliar fatores que influenciam as decisões de granularidade
Escolher a granularidade adequada requer equilibrar múltiplas preocupações concorrentes. A escolha certa depende do contexto empresarial específico e das restrições técnicas.
Os requisitos empresariais determinam o nível de detalhe.
As questões analíticas que a sua organização precisa de responder devem ser o principal fator para determinar a granularidade. Pergunte a si próprio: qual é o nível de análise mais detalhado exigido?
Se os engenheiros de operações precisarem de detetar anomalias de equipamento ao nível do milissegundo, os agregados por minuto não serão suficientes. Se a gestão só precisar de resumos de utilização por hora por linha de produção, armazenar todas as leituras de sensores desperdiça recursos.
Considere estes cenários:
| Requisito de negócio | Granularidade mínima necessária |
|---|---|
| Detetar anomalias de vibração do equipamento em tempo real | Nível de evento em milissegundos |
| Analisar as tendências de temperatura para manutenção preditiva | Segundo nível agregado |
| Monitorizar o consumo de energia por hora por dispositivo | Nível agregado minuto |
| Reporte métricas diárias de produção por unidade | Nível agregado por hora |
Os padrões de consulta moldam o desempenho
A forma como os utilizadores consultam os seus dados influencia a granularidade ótima. Quando as consultas normalmente filtram e agregam para níveis superiores, armazenar dados excessivamente detalhados cria sobrecarga desnecessária de processamento. Cada consulta precisa analisar e agregar mais linhas do que o necessário.
Ao mesmo tempo, armazenar dados com uma granularidade demasiado grosseira impede que os utilizadores se aprofundem para responder a perguntas detalhadas. Encontrar o equilíbrio requer compreender tanto os padrões de consulta atuais como os previstos.
Os custos de armazenamento e computação acumulam-se
Granularidade mais fina significa mais linhas, o que aumenta os custos de armazenamento. Também aumenta os custos de computação porque as consultas têm de processar mais dados. No Azure Databricks, estes custos acumulam-se ao longo do tempo à medida que os dados históricos se acumulam.
Uma instalação de produção com milhares de sensores a captar leituras em intervalos de milissegundos poderia gerar milhares de milhões de linhas diariamente com a mais fina granularidade. Agregar estatísticas por segundo ou por minuto poderia reduzir a contagem de linhas em 99% ou mais, traduzindo-se diretamente em custos de armazenamento e consulta mais baixos.
Os requisitos de conformidade e auditoria são importantes
Os requisitos regulamentares por vezes exigem níveis específicos de granularidade. As organizações de serviços financeiros muitas vezes têm de manter detalhes ao nível das transações para fins de auditoria, independentemente dos custos de armazenamento. As organizações de saúde podem precisar de acompanhar as interações individuais dos pacientes por razões de conformidade.
Quando a conformidade orientar a sua decisão de granularidade, documente claramente os requisitos. Esta justificação ajuda quando as partes interessadas questionam porque está a armazenar mais detalhes do que as necessidades analíticas sozinhas exigiriam.
Aplicar a granularidade às tabelas de factos
As tabelas de factos beneficiam mais de decisões cuidadosas de granularidade porque normalmente contêm os maiores volumes de dados. O grão de uma tabela de factos é determinado pela combinação das suas chaves de dimensão.
Uma tabela de factos de vendas com chaves de dimensões para data, produto, cliente e loja tem uma granularidade de "uma linha por produto, por cliente, por loja, por dia." Cada combinação única destes valores dimensionais cria uma linha distinta. Adicionar uma chave de dimensão temporal ao nível das horas mudaria o grão para "uma fila por produto, por cliente, por loja, por hora", aumentando significativamente o número de filas.
Importante
Declara explicitamente a granulação da tua tabela de factos antes de adicionar qualquer coluna. A declaração de grão serve como um contrato que orienta todas as decisões subsequentes de design. Por exemplo: "Esta tabela de factos contém uma linha por item de encomenda de venda."
Ao desenhar tabelas de factos, considere se precisa de:
Grão atómico: O nível mais detalhado capturado no sistema de origem. Escolher grão atómico oferece máxima flexibilidade analítica porque se pode sempre agregar para níveis superiores, mas nunca desagregar para níveis inferiores.
Grão agregado: Dados pré-resumidos a um nível superior ao da fonte. Tabelas de factos agregadas melhoram o desempenho das consultas para padrões analíticos comuns, mas limitam as perguntas que os utilizadores podem responder.
Muitas organizações mantêm tabelas factuais atómicas e agregadas, utilizando tabelas agregadas como otimização de desempenho, preservando o detalhe atómico para análises ad hoc. No Azure Databricks, as vistas materializadas podem manter automaticamente estas tabelas agregadas, atualizando-as à medida que os dados atómicos subjacentes mudam.
Aplicar granularidade às tabelas de dimensões
As tabelas de dimensões também têm um nível de granularidade, embora funcione de forma diferente do nível de granularidade das tabelas factuais. O grão dimensional determina como representa e versiona as suas entidades empresariais.
Para a dimensão do cliente, pode escolher:
- Uma linha por cliente: O estado atual de cada cliente, atualizado no local quando os atributos mudam (SCD Tipo 1).
- Uma linha por cliente por versão: Uma nova linha para cada alteração significativa, preservando estados históricos (SCD Tipo 2).
- Uma linha por cliente por período de tempo: Instantâneos periódicos que capturam atributos do cliente em intervalos regulares.
O grão dimensional que escolhes deve alinhar-se com o grão da tua tabela de factos. Se a sua tabela de factos regista transações individuais com chaves substitutas para a dimensão do cliente, o grão da sua dimensão de cliente deve suportar essa relação. Uma transação que referencia a versão 5 do cliente deve ser capaz de encontrar essa versão específica na tabela de dimensões.
Equilibrar compromissos ao selecionar a granularidade
Nenhuma escolha de granularidade é universalmente correta. Cada decisão envolve compensações que deve avaliar em função dos seus requisitos específicos.
| Consideração | Granularidade fina | Baixa granularidade |
|---|---|---|
| Flexibilidade analítica | Alto - pode responder a perguntas detalhadas | Baixo - limitado à análise agregada |
| Custos de armazenamento | Mais linhas para armazenar | Mais baixo - menos linhas |
| Desempenho de consultas | Mais lento para consultas agregadas | Mais rápido para padrões comuns |
| Análise histórica | Suporta análise em momentos específicos | Pode perder detalhes históricos |
| Apoio à conformidade | Melhor para requisitos de auditoria | Pode não cumprir os regulamentos |
Quando tens dúvidas, começar com uma granularidade mais fina é muitas vezes mais seguro. Podes sempre criar tabelas agregadas mais tarde para otimização de desempenho, mas não podes recuperar detalhes que nunca foram capturados. No entanto, esta orientação assume que tem orçamento e infraestrutura para suportar inicialmente armazenamento mais detalhado.
Compreender como escolher a granularidade adequada permite-lhe desenhar modelos de dados que apoiem as necessidades analíticas da sua organização, ao mesmo tempo que gerem custos de forma eficaz. Os detalhes de implementação para construir e carregar tabelas na granularidade escolhida no Azure Databricks são abordados em unidades posteriores.