Guia do engenheiro de dados para armazenamentos de dados não tradicionais

Engenharia de dados

Com a ascensão do big data e da ciência de dados, muitas funções de engenharia estão sendo desafiadas e expandidas. Uma função da nova era é a engenharia de dados .

Originalmente, o objetivo da engenharia de dados era o carregamento de fontes de dados externas e o design de bancos de dados (projetando e desenvolvendo pipelines para coletar, manipular, armazenar e analisar dados).

Desde então, cresceu para suportar o volume e a complexidade do big data. Portanto, a engenharia de dados agora engloba uma ampla gama de habilidades, desde rastreamento na Web, limpeza de dados, computação distribuída e armazenamento e recuperação de dados.

Para engenharia de dados e engenheiros de dados, o armazenamento e a recuperação de dados é o componente crítico do pipeline, juntamente com a forma como os dados podem ser usados ​​e analisados.

Nos últimos tempos, muitas novas e diferentes tecnologias de armazenamento de dados surgiram. No entanto, qual é o mais adequado e possui os recursos mais adequados para a engenharia de dados?

A maioria dos engenheiros está familiarizada com bancos de dados SQL, como PostgreSQL, MSSQL e MySQL, que são estruturados em tabelas de dados relacionais com armazenamento orientado a linhas.

Dada a onipresença desses bancos de dados, não os discutiremos hoje. Em vez disso, exploramos três tipos de armazenamentos de dados alternativos que estão crescendo em popularidade e que introduziram diferentes abordagens para lidar com dados.

No contexto da engenharia de dados, essas tecnologias são mecanismos de pesquisa, armazenamentos de documentos e armazenamentos colunares.

• Os mecanismos de pesquisa são excelentes em consultas de texto. Quando comparado a correspondências de texto em bancos de dados SQL, como LIKE , os mecanismos de pesquisa oferecem recursos de consulta mais altos e melhor desempenho imediato.
• Os armazenamentos de documentos fornecem melhor adaptabilidade do esquema de dados do que os bancos de dados tradicionais. Ao armazenar os dados como objetos de documentos individuais, geralmente representados como JSONs, eles não exigem predefinição de esquema.
• As lojas colunares são especializadas em consultas de coluna única e agregações de valor. As operações SQL, como SUM e AVG , são consideravelmente mais rápidas em armazenamentos colunares, pois os dados da mesma coluna são armazenados mais próximos no disco rígido.

Neste artigo, exploramos todas as três tecnologias: Elasticsearch como mecanismo de pesquisa, MongoDB como armazenamento de documentos e Amazon Redshift como armazenamento colunar.

Ao entender o armazenamento alternativo de dados, podemos escolher o mais adequado para cada situação.

Para comparar essas tecnologias, examinaremos como elas indexam, fragmentam e agregam dados.

Cada estratégia de indexação de dados melhora determinadas consultas e dificulta outras.

Saber quais consultas são usadas com mais frequência pode influenciar qual armazenamento de dados adotar.

Sharding, uma metodologia pela qual os bancos de dados dividem seus dados em partes, determina como a infraestrutura crescerá à medida que mais dados forem ingeridos.

Escolher um que corresponda ao nosso plano de crescimento e orçamento é fundamental, e isso se aplica a qualquer empresa de ciência de dados, independentemente do tamanho.

Por fim, cada uma dessas tecnologias agrega seus dados de maneira muito diferente.

Quando estamos lidando com gigabytes e terabytes de dados, a estratégia de agregação errada pode limitar os tipos e desempenhos de relatórios que podemos gerar.

Como engenheiros de dados, devemos considerar todos os três aspectos ao avaliar diferentes armazenamentos de dados.

contendores

Mecanismo de pesquisa: Elasticsearch

O Elasticsearch rapidamente ganhou popularidade entre seus pares por sua escalabilidade e facilidade de integração. Construído sobre o Apache Lucene, ele oferece uma funcionalidade de indexação e pesquisa de texto poderosa e pronta para uso. Além das tarefas tradicionais do mecanismo de pesquisa, pesquisa de texto e consultas de valor exato, o Elasticsearch também oferece recursos de agregação em camadas.

Armazenamento de documentos: MongoDB

Neste ponto, o MongoDB pode ser considerado o banco de dados NoSQL obrigatório. Sua facilidade de uso e flexibilidade rapidamente ganharam popularidade. O MongoDB suporta consultas ricas e adaptáveis ​​para investigar documentos complexos. Os campos frequentemente consultados podem ser acelerados por meio da indexação e, ao agregar uma grande quantidade de dados, o MongoDB oferece um pipeline de vários estágios.

Loja colunar: Amazon Redshift

Juntamente com o crescimento da popularidade do NoSQL, os bancos de dados colunares também ganharam atenção, especialmente para análise de dados. Ao armazenar dados em colunas em vez das linhas usuais, as operações de agregação podem ser executadas diretamente do disco, aumentando muito o desempenho. Há alguns anos, a Amazon lançou seu serviço hospedado para uma loja colunar chamada Redshift.

Indexação

Capacidade de indexação do Elasticsearch

De muitas maneiras, os mecanismos de pesquisa são armazenamentos de dados especializados na indexação de textos.

Enquanto outros armazenamentos de dados criam índices com base nos valores exatos do campo, os mecanismos de pesquisa permitem a recuperação com apenas um fragmento do campo (geralmente texto).

Por padrão, essa recuperação é feita automaticamente para cada campo por meio de analisadores.

Um analisador é um módulo que cria várias chaves de índice avaliando os valores de campo e dividindo-os em valores menores.

Por exemplo, um analisador básico pode examinar “a rápida raposa marrom pulou sobre o cachorro preguiçoso” em palavras como “o”, “rápido”, “marrom”, “raposa” e assim por diante.

Esse método permite que os usuários encontrem os dados pesquisando fragmentos nos resultados, classificados por quantos fragmentos correspondem aos mesmos dados do documento.

Um analisador mais sofisticado poderia utilizar distâncias de edição, n-gramas e filtrar por palavras irrelevantes, para construir um índice de recuperação abrangente.

Capacidade de indexação do MongoDB

Como um armazenamento de dados genérico, o MongoDB tem muita flexibilidade para indexar dados.

Ao contrário do Elasticsearch, ele indexa apenas o campo _id por padrão e precisamos criar índices para os campos comumente consultados manualmente.

Comparado ao Elasticsearch, o analisador de texto do MongoDB não é tão poderoso. Mas oferece muita flexibilidade com métodos de indexação, desde o composto e geoespacial para consultas ideais até o TTL e esparso para redução de armazenamento.

Capacidade de indexação do Redshift

Ao contrário do Elasticsearch, MongoDB ou mesmo bancos de dados tradicionais, incluindo PostgreSQL, o Amazon Redshift não oferece suporte a um método de indexação.

Em vez disso, reduz o tempo de consulta mantendo uma classificação consistente no disco.

Como usuários, podemos configurar um conjunto ordenado de valores de coluna como a chave de classificação da tabela. Com os dados classificados no disco, o Redshift pode pular um bloco inteiro durante a recuperação se seu valor estiver fora do intervalo consultado, aumentando muito o desempenho.

Fragmentação

Capacidade de Sharding do Elasticsearch

O Elasticsearch foi desenvolvido com base no Lucene para escalar horizontalmente e estar pronto para produção.

O dimensionamento é feito criando várias instâncias do Lucene (shards) e distribuindo-as em vários nós (servidores) em um cluster.

Por padrão, cada documento é roteado para seu respectivo estilhaço por meio de seu campo _id .

Durante a recuperação, o nó mestre envia a cada fragmento uma cópia da consulta antes de finalmente agregá-los e classificá-los para saída.

Capacidade de Sharding do MongoDB

Dentro de um cluster MongoDB, existem três tipos de servidores: roteador, config e shard.

Ao dimensionar o roteador, os servidores podem aceitar mais solicitações, mas o trabalho pesado acontece nos servidores de fragmentos.

Assim como no Elasticsearch, os documentos do MongoDB são roteados (por padrão) via _id para seus respectivos shards. No momento da consulta, o servidor de configuração notifica o roteador, que fragmenta a consulta, e o servidor do roteador então distribui a consulta e agrega os resultados.

Capacidade de fragmentação do Redshift

Um cluster do Amazon Redshift consiste em um nó líder e vários nós de computação.

O nó líder lida com a compilação e distribuição de consultas, bem como a agregação de resultados intermediários.

Ao contrário dos servidores de roteador do MongoDB, o nó líder é consistente e não pode ser dimensionado horizontalmente.

Embora isso crie um gargalo, também permite o armazenamento em cache eficiente de planos de execução compilados para consultas populares.

Agregando

Capacidade de agregação do Elasticsearch

Os documentos no Elasticsearch podem ser agrupados por valores exatos, de intervalo ou até mesmo temporais e de geolocalização.

Esses buckets podem ser agrupados em granularidade mais fina por meio de agregação aninhada.

Métricas, incluindo médias e desvios padrão, podem ser calculadas para cada camada, o que permite calcular uma hierarquia de análises em uma única consulta.

Sendo um armazenamento baseado em documentos, ele sofre a limitação de comparações de campo intra-documento.

Por exemplo, embora seja bom filtrar se os seguidores de um campo forem maiores que 10, não podemos verificar se os seguidores são maiores que outro campo seguindo .

Como alternativa, podemos injetar scripts como predicados personalizados. Esse recurso é ótimo para análises pontuais, mas o desempenho é prejudicado na produção.

Capacidade de agregação do MongoDB

O pipeline de agregação é poderoso e rápido.

Como o próprio nome sugere, ele opera em dados retornados de forma faseada.

Cada etapa pode filtrar, agregar e transformar os documentos, introduzir novas métricas ou desfazer grupos previamente agregados.

Como essas operações são feitas em etapas e garantindo que os documentos e campos sejam reduzidos a apenas filtrados, o custo de memória pode ser minimizado. Comparado ao Elasticsearch e até mesmo ao Redshift, o Aggregation Pipeline é uma maneira extremamente flexível de visualizar os dados.

Apesar de sua adaptabilidade, o MongoDB sofre a mesma falta de comparação de campos intra-documento que o Elasticsearch.

Além disso, algumas operações, incluindo $group , exigem que os resultados sejam passados ​​para o nó mestre.

Assim, eles não aproveitam a computação distribuída.

Aqueles que não estão familiarizados com o cálculo de pipeline em etapas acharão certas tarefas pouco intuitivas. Por exemplo, resumir o número de elementos em um campo de matriz exigiria duas etapas: primeiro, a operação $unwind e, em seguida, a operação $group .

Capacidade de agregação do Redshift

Os benefícios do Amazon Redshift não podem ser subestimados.

Agregações frustrantemente lentas no MongoDB ao analisar o tráfego móvel são resolvidas rapidamente pelo Amazon Redshift.

Com suporte ao SQL, os engenheiros de banco de dados tradicionais terão facilidade para migrar suas consultas para o Redshift.

Deixando de lado o tempo de integração, o SQL é uma linguagem de consulta comprovada, escalável e poderosa, compatível com comparações de campo entre documentos/linhas com facilidade. O Amazon Redshift melhora ainda mais seu desempenho compilando e armazenando em cache as consultas populares executadas nos nós de computação.

Como um banco de dados relacional, o Amazon Redshift não tem a flexibilidade de esquema que o MongoDB e o Elasticsearch têm. Otimizado para operações de leitura, sofre impactos de desempenho durante atualizações e exclusões.

Para manter o melhor tempo de leitura, as linhas devem ser classificadas, adicionando esforços operacionais extras.

Adaptado para aqueles com problemas do tamanho de petabytes, não é barato e provavelmente não vale o investimento, a menos que haja problemas de dimensionamento com outros bancos de dados.

Escolhendo o vencedor

Neste artigo, examinamos três tecnologias diferentes – Elasticsearch, MongoDB e Amazon Redshift – no contexto da engenharia de dados. No entanto, não há um vencedor claro, pois cada uma dessas tecnologias é pioneira em sua categoria de tipo de armazenamento.

Para engenharia de dados, dependendo do caso de uso, algumas opções são melhores que outras.

• MongoDB é um fantástico banco de dados inicial. Ele fornece a flexibilidade que desejamos quando o esquema de dados ainda não foi determinado. Dito isso, o MongoDB não supera casos de uso específicos nos quais outros bancos de dados se especializam.
• Embora o Elasticsearch ofereça um esquema fluido semelhante ao MongoDB, ele é otimizado para vários índices e consultas de texto às custas do desempenho de gravação e do tamanho do armazenamento. Assim, devemos considerar a migração para o Elasticsearch quando nos encontrarmos mantendo vários índices no MongoDB.
• O Redshift requer um esquema de dados predefinido e não possui a adaptabilidade fornecida pelo MongoDB. Em troca, ele supera outros bancos de dados para consultas envolvendo apenas uma (ou algumas) colunas. Quando o orçamento permite, o Amazon Redshift é uma grande arma secreta quando outros não conseguem lidar com a quantidade de dados.