Greenplum 6: revisão de novos recursos

Nos últimos 16 anos, o Greenplum, um DBMS aberto e massivamente paralelo, ajudou uma variedade de empresas a tomar decisões com base na análise de dados.

Durante esse período, a Greenplum penetrou em várias áreas de negócios, incluindo: varejo, fintech, telecomunicações, indústria, comércio eletrônico. Dimensionando para centenas de nós horizontalmente, tolerância a falhas, código-fonte aberto, total compatibilidade com PostgreSQL, transacionalidade e ANSI SQL - é difícil imaginar uma melhor combinação de propriedades para um DBMS analítico. A partir de grandes grupos de empresas gigantes globais, como Morgan Stanley (200 nós, 25 Pb de dados) ou Tinkoff (> 70 nós) e terminando com pequenas instalações de dois nós em startups acolhedoras, mais e mais empresas escolhem o Greenplum. É especialmente agradável observar essa tendência na Rússia - nos últimos dois anos, o número de grandes empresas domésticas que usam o Greenplum triplicou.

No outono de 2019, outro grande lançamento do DBMS foi lançado. Neste artigo, falarei brevemente sobre os principais novos recursos do GP 6.

A versão principal anterior do Greenplum versão 5 foi publicada em setembro de 2017, detalhes podem ser encontrados neste artigo . Se você ainda não sabe o que é Greenplum, pode ser obtida uma breve introdução neste artigo . É antigo, mas a arquitetura do DBMS reflete corretamente.

A versão atual, por direito, pode ser chamada de ideia coletiva: várias empresas de todo o mundo participaram do desenvolvimento - entre elas a Pivotal, Arenadata (onde o autor deste artigo trabalha), Alibaba.

Então, o que há de novo no Greenplum 6?

Tabelas replicadas

Deixe-me lembrá-lo que no Greenplum havia dois tipos de distribuição de tabelas em um cluster:

• Distribuição uniforme aleatória
• Distribuição em um ou vários campos

Na maioria dos casos, a junção de duas tabelas (JOINs) foi realizada com redistribuição de dados entre os segmentos do cluster durante a execução da consulta, e somente se as duas tabelas originalmente distribuídas pela chave de junção JOIN ocorressem localmente nos segmentos sem transferir dados entre os segmentos.

O GP 6 oferece aos arquitetos uma nova ferramenta de otimização de esquema de armazenamento - tabelas replicadas. Essas tabelas são duplicadas na íntegra em todos os segmentos do cluster. Qualquer conexão com essa tabela no lado direito será realizada localmente, sem redistribuir dados. Basicamente, o recurso é destinado ao armazenamento de diretórios volumosos.

Algoritmo de compressão Zstandard (ZSTD)

Apresentado em 2016 pelos desenvolvedores do Facebook, o algoritmo de compactação sem perdas atingiu quase imediatamente o coração da nossa equipe Arenadata, porque comparado ao Zlib (usado por padrão no Greenplum) possui taxas de compactação mais altas com menos tempo necessário para compactação e descompactação:


Fonte: cnx-software.com

A eficiência da compressão é um dos parâmetros mais importantes do DBMS analítico moderno. De fato, permite reduzir a carga no subsistema de disco relativamente caro do cluster, carregando CPUs relativamente baratas. Ao ler e gravar sequencialmente grandes quantidades de dados, isso resulta em uma redução significativa no custo total de propriedade do sistema.

Em 2017, nossa equipe adicionou suporte ao ZSTD para tabelas de colunas no Greenplum; no entanto, de acordo com a política de lançamento, esta revisão não chegou aos lançamentos menores oficiais do Greenplum. Até hoje, ele estava disponível apenas para clientes comerciais da Arenadata e, com o lançamento do 6.0, todos podiam usá-lo.

Otimização de expansão de cluster (expandir)

Nas versões anteriores do GP, a expansão horizontal do cluster (adicionando novos nós) apresentava algumas limitações:

• Embora a redistribuição dos dados tenha ocorrido em segundo plano sem tempo de inatividade, era necessário reiniciar o sistema ao adicionar novos nós
• O algoritmo de hash e distribuição de dados exigiu uma redistribuição completa de todas as tabelas durante a expansão - o processo de distribuição de dados em segundo plano pode levar horas ou até dias para clusters especialmente grandes
• Durante a distribuição em segundo plano das tabelas, qualquer junção era distribuída apenas

Greenplum 6 introduziu um algoritmo de expansão de cluster completamente novo, devido ao qual:

• Agora a expansão ocorre sem reiniciar o sistema - o tempo de inatividade não é necessário
• O algoritmo de hash consistente permite redistribuir apenas parte dos blocos ao adicionar nós, ou seja, a redistribuição em segundo plano das tabelas funciona muitas vezes mais rapidamente
• A lógica para alterar os diretórios do sistema mudou - agora, mesmo durante o processo de expansão, todas as conexões (JOINs) funcionam normalmente - localmente e distribuídas

Agora, a extensão Greenplum é uma questão de minutos, não de horas. Isso permitirá que os clusters sigam o crescente apetite das unidades de negócios.

Segurança no nível da coluna

Agora é possível distribuir direitos para colunas específicas nas tabelas (o recurso veio do PostgreSQL):

 grant all (column_name) on public.table_name to gpadmin; 

Jsonb

O armazenamento binário e ideal de objetos do tipo JSON está agora disponível no GP. Leia mais sobre o formato aqui .

Explicação automática

Outra grande extensão que veio para o GP do PostgreSQL. Foi modificado para funcionar no modo distribuído no cluster Greenplum pela equipe Arenadata.

Permite automaticamente que cada solicitação (ou tomada separadamente) no DBMS salve informações sobre:

• plano de solicitação;
• consumiu recursos em cada estágio da execução da consulta em cada segmento (nó);
• tempo gasto;
• o número de linhas processadas em cada estágio da consulta em cada segmento (nó).

Diskquota

Extensão do PostgreSQL que permite limitar o armazenamento em disco disponível para usuários e esquemas individuais:

 select diskquota.set_schema_quota('schema_name', '1 MB'); select diskquota.set_role_quota('user_name', '1 MB'); 

Novos recursos de distribuição do banco de dados Arenadata

Isenção de responsabilidade - haverá algumas linhas de publicidade a seguir :)

Deixe-me lembrá-lo que nós, Arenadata, estamos desenvolvendo, implementando e dando suporte à nossa plataforma de armazenamento de dados com base em tecnologias de código aberto - Greenplum, Kafka, Hadoop, Clickhouse. Nossos clientes são as maiores empresas russas nas áreas de varejo, telecomunicações, fintech e outras. Por um lado, somos os colaboradores dos próprios projetos de código aberto (comprometendo alterações no kernel); por outro lado, estamos desenvolvendo funcionalidades adicionais que estão disponíveis apenas para nossos clientes comerciais. Além disso, falaremos sobre os principais recursos.

Conector Tkhemali tcp Connector Greenplum -> Clickhouse

Em projetos, geralmente usamos o grupo Greenplum + Clickhouse - por um lado, isso nos permite usar os melhores modelos clássicos de construção de data warehouses (das fontes aos data marts) que exigem muitas conexões, sintaxe ANSI SQL desenvolvida, transacionalidade e outros chips que o Greenplum possui, por outro lado, para fornecer acesso a grandes vitrines construídas com uma velocidade máxima para um número significativo de usuários - e a Clickhouse não tem concorrentes nisso.

Para usar efetivamente esse pacote, desenvolvemos um conector paralelo especial, que transacionalmente (isto é, consistente mesmo no caso de uma transação de reversão) permite transferir dados do GP para o KH. Em geral, a arquitetura desse conector merece um artigo puramente técnico separado - na verdade, tivemos que implementar filas assíncronas paralelas com um sistema para selecionar dinamicamente o número de threads por inserção e fluxo de dados.

O resultado é uma velocidade de interação fantástica: em nossos testes em discos SATA típicos, alcançamos 1 Gb / s por inserção em um par de servidores Greenplum - Clickhouse. Como o cluster GP médio de nossos clientes consiste em mais de 20 servidores, a velocidade de interação é mais do que suficiente.

Conector Kafka

Fizemos o mesmo com a integração com o intermediário de mensagens Kafka - geralmente encontramos a tarefa de sobrecarregar dados do Kafka para o Greenplum no modo quase em tempo real (segundos ou dezenas de segundos). No entanto, a arquitetura do conector para Kafka é diferente. Um conector é um cluster de processos sincronizados separados (lançados no Docker) com descoberta automática, que, por um lado, são consumidores Kafka e, por outro lado, inserem dados diretamente nos segmentos Greenplum. O conector pode funcionar com o Kafka Registry e garante a consistência completa dos dados transferidos, mesmo em caso de falhas de hardware.

Sistema de gerenciamento e monitoramento

A operação do sistema em produção exige muito da implantação, atualização e monitoramento do cluster. É importante que tudo o que acontece no DBMS seja transparente para operações e especialistas em DBA.

Nosso sistema de gerenciamento e monitoramento Arenadata Cluster Manager (ADCM) fornece aos profissionais de operação todas as ferramentas necessárias. De fato, a implantação e a atualização do cluster Greenplum são feitas com o toque de um botão na interface gráfica (todos os sistemas operacionais, serviços, montagem de disco e configurações de rede são feitos automaticamente). Além disso, você obtém uma pilha de monitoramento totalmente configurada, pronta para integrar-se aos seus sistemas corporativos. A propósito, o Arenadata Cluster Manager pode gerenciar não apenas o Greenplum, mas também o Hadoop, Kafka, Clickhouse (nossos conjuntos desses serviços são necessários. Suas versões gratuitas, como a própria ADCM, podem ser baixadas totalmente grátis em nosso site , apenas preenchendo o pop-up).

Conclusão

Se você estiver usando o Greenplum 5.X, recomendo atualizar o cluster para a versão atual 6.X nos próximos 2-3 meses.

Se você ainda não estiver usando o Greenplum, junte-se a nós! Nós, Arenadata, estamos sempre prontos para ajudá-lo com isso.

Referências

Greenplum no github
Canal Greenplum Russia Telegram - faça suas perguntas diretamente aos usuários do Greenplum
Documentação do Greenplum 6