Modelar dados semiestruturados
Este artigo recomenda padrões para o armazenamento de dados semiestruturados, dependendo de como sua organização usa os dados. O Databricks oferece funções, tipos de dados nativos e sintaxe de consulta para trabalhar com dados semiestruturados, aninhados e complexos.
As considerações a seguir afetam o padrão que o senhor deve usar:
Os campos ou tipos na fonte de dados mudam com frequência?
Quantos campos exclusivos no total estão contidos na fonte de dados?
O senhor precisa otimizar suas cargas de trabalho para gravações ou leituras?
A Databricks recomenda o armazenamento de dados como tabelas Delta para consultas posteriores.
Usar variante
Em Databricks Runtime 15.3 e acima, o senhor pode usar o tipo VARIANT
para armazenar dados semiestruturados JSON uso de dados uma codificação otimizada que supera o desempenho de JSON strings para leituras e gravações.
O tipo VARIANT
tem aplicações semelhantes às de JSON strings. Algumas cargas de trabalho ainda se beneficiam do uso de structs, mapas e matrizes, especialmente para dados com esquemas bem conhecidos que se beneficiariam da otimização da disposição dos dados e da coleta de estatísticas.
Para obter mais detalhes, consulte os artigos a seguir:
Usar strings JSON
O senhor pode armazenar dados em uma única coluna de cadeias de caracteres usando a formatação padrão JSON e, em seguida, consultar os campos em JSON usando a notação :
.
Muitos sistemas emitem registros como strings ou registros codificados por bytes em JSON. A ingestão e o armazenamento desses registros como strings têm uma sobrecarga de processamento muito baixa. O senhor também pode usar a função to_json
para transformar qualquer estrutura de dados em JSON strings.
Considere os seguintes pontos fortes e fracos ao optar por armazenar dados como JSON strings:
Todos os valores são armazenados como strings sem informações de tipo.
O JSON é compatível com todos os tipos de dados que podem ser representados por meio de texto.
JSON suporta strings de comprimento arbitrário.
Não há limites para o número de campos que podem ser representados em uma única coluna de dados JSON.
Os dados não precisam de pré-processamento antes de serem gravados na tabela.
O senhor pode resolver problemas de tipo presentes nos dados em cargas de trabalho downstream.
JSON oferece o pior desempenho na leitura, pois o senhor precisa analisar as cadeias inteiras para cada consulta.
JSON strings oferecem grande flexibilidade e soluções fáceis de implementar para obter dados brutos em uma tabela lakehouse. O senhor pode optar por usar o JSON strings para muitos aplicativos, mas eles são especialmente úteis quando o resultado mais importante de uma carga de trabalho é armazenar uma representação completa e precisa de uma fonte de dados para processamento posterior. Alguns casos de uso podem incluir:
A ingestão de dados de transmissão de um serviço de fila, como o Kafka.
Registro de respostas de consultas à API REST.
Armazenamento de registros brutos de uma fonte de dados upstream não controlada pela sua equipe.
Supondo que sua lógica de ingestão seja flexível, o armazenamento de dados como JSON strings deve ser resiliente, mesmo que o senhor encontre novos campos, alterações na estrutura de dados ou alterações de tipo na fonte de dados. Embora as cargas de trabalho downstream possam falhar devido a essas alterações, sua tabela contém um histórico completo dos dados de origem, o que significa que o senhor pode corrigir os problemas sem precisar voltar à fonte de dados.
Usar structs
O senhor pode armazenar dados semiestruturados com structs e ativar todas as funcionalidades nativas das colunas, mantendo a estrutura aninhada da fonte de dados.
O Delta Lake trata os dados armazenados como structs da mesma forma que qualquer outra coluna, o que significa que não há diferença funcional entre structs e colunas. Os arquivos de dados Parquet usados pelo Delta Lake criam uma coluna para cada campo em uma estrutura. O senhor pode usar campos de struct como colunas de clustering ou colunas de particionamento e pode coletar estatísticas sobre structs para ignorar dados.
Em geral, as estruturas proporcionam o melhor desempenho na leitura, pois suportam todas as otimizações de ignorar dados e armazenam campos individuais como colunas. O desempenho pode começar a ser prejudicado quando o número de colunas presentes chega a centenas.
Cada campo em um struct tem um tipo de dados, que é imposto na gravação da mesma forma que as colunas. Dessa forma, os structs exigem um pré-processamento completo dos dados. Isso pode ser vantajoso quando se deseja que apenas dados validados sejam confirmados em uma tabela, mas pode levar a dados descartados ou a falhas no trabalho ao processar registros malformados de sistemas upstream.
As estruturas são menos flexíveis do que JSON transmissão para a evolução do esquema, seja para a evolução dos tipos de dados ou para a adição de novos campos.
Usar mapas e matrizes
O senhor pode usar uma combinação de mapas e matrizes para replicar formatos de dados semiestruturados nativamente no Delta Lake. Não é possível coletar estatísticas sobre os campos definidos com esses tipos, mas eles oferecem desempenho equilibrado tanto na leitura quanto na gravação de conjuntos de dados semiestruturados com cerca de 500 campos.
Tanto o key quanto o valor dos mapas são digitados, portanto, os dados são pré-processados e o esquema é aplicado na gravação.
Para acelerar as consultas, a Databricks recomenda o armazenamento de campos que são frequentemente usados para filtrar dados como colunas separadas.
Preciso achatar meus dados?
Se o senhor estiver armazenando o uso de dados JSON ou mapas, considere armazenar os campos usados com frequência para filtrar consultas como colunas. A coleta de estatísticas, o particionamento e o clustering não estão disponíveis para campos em strings ou mapas JSON. O senhor não precisa fazer isso para dados armazenados como structs.