Como é que o armazenamento colunar acelera a análise de sensores domésticos?

O armazenamento colunar acelera a análise de dados de sensores domésticos ao manter juntos os valores dos mesmos campos, permitindo que as consultas analíticas evitem ler dados que não lhes dizem respeito.

Uma tabela de histórico de uma casa inteligente pode conter marcas temporais, IDs de dispositivos, divisões, temperaturas, humidade, consumo de energia, estado de movimento, nível da bateria, indicadores de qualidade e metadados relativos a milhões de observações. A maioria das consultas históricas utiliza apenas alguns desses campos e agrega muitas linhas, o que é praticamente o oposto de uma aplicação que obtém repetidamente um registo atual completo. Os esquemas colunares otimizam esse percurso de leitura e agregação ao alterarem tanto o que é necessário ler como a forma como lotes de valores semelhantes chegam à CPU.

O esquema colunar separa os campos de que uma consulta analítica realmente precisa

Um registo orientado por linhas mantém juntos todos os campos de uma observação, o que é conveniente quando a aplicação precisa da observação completa. Uma representação orientada por colunas agrupa, em vez disso, os valores por campo, permitindo que uma consulta de temperatura de seis meses se concentre na marca temporal, na divisão e na temperatura, sem transportar cadeias de firmware, dados da bateria e estados não relacionados dos dispositivos durante a mesma leitura.

O Apache Parquet é um formato de dados orientado por colunas concebido para o armazenamento e a obtenção eficientes de grandes volumes de dados. Essa separação física é a primeira razão pela qual uma consulta analítica restrita pode mover menos dados do que uma leitura de linhas completas sobre a mesma tabela lógica.

A vantagem aumenta à medida que os registos se tornam mais largos e as consultas continuam seletivas. Um relatório de consumo energético doméstico pode utilizar apenas a marca temporal, os watts e o ID do dispositivo, apesar de o esquema de ingestão incluir muitos campos adicionais necessários para painéis e gestão de dispositivos.

A projeção e o pushdown de filtros impedem que dados desnecessários entrem na leitura

O esquema colunar cria a possibilidade de ignorar campos não utilizados, mas o motor de consultas tem de transmitir esse conhecimento ao leitor de ficheiros para que a poupança de armazenamento se transforme em poupança real de E/S. Se todas as colunas forem carregadas primeiro e eliminadas depois, o formato físico não proporcionou todo o seu benefício.

O DuckDB pode aplicar projeção e pushdown de filtros ao ler Parquet, pelo que apenas são lidas as colunas necessárias e os filtros podem contribuir para ignorar partes do ficheiro. Assim, uma consulta à humidade média de uma divisão pode restringir tanto os campos como, quando os metadados o permitem, os intervalos de linhas relevantes antes da execução completa.

Num serviço de análise local, isto reduz as leituras do disco, o trabalho de descompressão, o tráfego de memória e o volume de dados intermédios transferidos entre operadores. O ganho é maior em leituras longas nas quais os campos solicitados representam uma pequena fração do esquema armazenado.

O pushdown não é automático em todas as pipelines. Envolver os dados numa transformação opaca ou utilizar um leitor que não consiga expor predicados à camada de armazenamento pode forçar uma materialização maior do que a exigida pelo próprio formato de ficheiro.

O armazenamento conjunto de valores semelhantes proporciona melhor localidade aos codificadores e compressores

As colunas de sensores apresentam frequentemente padrões de valores repetitivos ou que mudam lentamente: os nomes das divisões repetem-se, os estados booleanos permanecem inalterados durante longos períodos, as marcas temporais avançam de forma monotónica e as temperaturas ocupam um intervalo numérico restrito. Agrupar cada tipo de valor proporciona aos codificadores um fluxo mais regular do que intercalar todos os campos de cada observação.

O Parquet suporta compressão de páginas de colunas em páginas de dados codificadas, permitindo que cada bloco de coluna utilize um codec de compressão depois de os seus valores terem sido codificados. Uma melhor compressão reduz os bytes que um servidor doméstico tem de conservar e ler durante a análise histórica.

A taxa de compressão depende da carga de trabalho, não sendo garantida apenas pela palavra “colunar”. Payloads cifrados de elevada cardinalidade ou valores binários já comprimidos podem beneficiar pouco, enquanto etiquetas repetidas e séries numéricas estruturadas costumam apresentar mais redundância aproveitável.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Os metadados dos grupos de linhas permitem ao leitor ignorar intervalos que não podem corresponder

As consultas históricas incluem frequentemente condições seletivas, como um intervalo de datas, uma classe de dispositivo ou leituras acima de um determinado limite. Se os metadados ao nível do ficheiro ou do grupo de linhas provarem que uma região não pode satisfazer o predicado, lê-la e descodificá-la seria trabalho desperdiçado.

O DuckDB pode utilizar metadados de mínimo/máximo do Parquet como eliminação de ficheiros baseada em zonemaps durante o pushdown de filtros, enquanto o Parquet também define filtros Bloom opcionais que podem ajudar a determinar se determinados valores poderão estar presentes num bloco de coluna. Estas estruturas aceleram as consultas ao evitarem intervalos comprovadamente irrelevantes, e não ao tornarem mais barato o cálculo das linhas correspondentes depois de carregadas.

A ordenação dos dados influencia a eficácia desta filtragem. Ficheiros agrupados aproximadamente por tempo, divisão ou dispositivo podem criar intervalos de metadados mais restritos do que dados intercalados aleatoriamente, pelo que uma disposição de escrita adequada pode ampliar os benefícios do armazenamento colunar.

A eliminação baseada em metadados é probabilística ou conservadora, consoante a estrutura, e os falsos positivos podem continuar a provocar leituras adicionais. A garantia importante é que a filtragem não deve eliminar intervalos que possam conter correspondências válidas.

Os lotes colunares adaptam-se bem à execução vetorizada pela CPU

Depois de as colunas selecionadas estarem na memória, os operadores analíticos aplicam repetidamente o mesmo cálculo a muitos valores: comparações, somas, médias, chaves de agrupamento ou transformações. Valores contíguos tornam esse trabalho mais favorável às caches da CPU e às instruções que processam vários valores numa só operação.

O Apache Arrow descreve um esquema de memória colunar que melhora a localidade e permite computação vetorizada com processadores compatíveis com SIMD. Assim, um motor de consultas local pode processar lotes de temperaturas ou leituras de consumo energético, em vez de desempacotar repetidamente registos heterogéneos completos, uma linha de cada vez.

Esta vantagem diz respeito ao percurso de execução analítica, e não apenas à compressão em disco. Mesmo um SSD rápido pode desperdiçar largura de banda a alimentar campos que a CPU ignora imediatamente, enquanto uma pipeline colunar reduz essa movimentação antes do início dos cálculos.

O armazenamento colunar favorece mais as leituras históricas do que o estado atual mutável

O mesmo esquema eficiente para leituras abrangentes não é automaticamente a melhor representação para atualizações frequentes de pontos individuais, pequenas transações ou obtenção do estado completo de um dispositivo. A automação doméstica e a análise a longo prazo podem, por isso, beneficiar de percursos de armazenamento diferentes, mesmo quando descrevem os mesmos sensores.

O Arrow troca explicitamente uma forte localidade analítica por operações de mutação mais dispendiosas, ilustrando o limite mais amplo: os sistemas colunares destacam-se quando muitos valores são lidos em conjunto, enquanto a reescrita contínua de pequenos registos pode favorecer outra estrutura.

Uma stack doméstica prática pode manter uma base de dados orientada por linhas ou orientada para estados para o estado atual dos dispositivos e escrever periodicamente as observações históricas em ficheiros colunares para análise. A separação da gestão e da análise local da ZimaSpace reflete a mesma ideia arquitetural: o percurso que tem de reagir a um evento em tempo real não precisa de partilhar o esquema físico de dados utilizado para meses de análise retrospetiva.

A questão útil não é, portanto, saber se o armazenamento colunar é universalmente mais rápido. É saber se a carga de trabalho dominante lê um subconjunto de campos em muitas linhas históricas, porque é esse o padrão de acesso que transforma a separação das colunas em menos E/S e num processamento de lotes mais eficiente.