Greenplum 6: revue des nouvelles fonctionnalités

image Au cours des 16 dernières années, Greenplum, un SGBD ouvert et massivement parallèle, a aidé diverses entreprises à prendre des décisions basées sur l'analyse des données.

Pendant ce temps, Greenplum a pénétré dans divers domaines d'activité, notamment: la vente au détail, la fintech, les télécommunications, l'industrie, le commerce électronique. Mise à l'échelle horizontale de centaines de nœuds, tolérance aux pannes, code open source, compatibilité totale avec PostgreSQL, transactionnalité et ANSI SQL - il est difficile d'imaginer une meilleure combinaison de propriétés pour un SGBD analytique. Partant d'énormes grappes dans des sociétés géantes mondiales, telles que Morgan Stanley (200 nœuds, 25 Pb de données) ou Tinkoff (> 70 nœuds), et se terminant par de petites installations à deux nœuds dans des startups confortables, de plus en plus d'entreprises choisissent Greenplum. Il est particulièrement agréable d'observer cette tendance en Russie - au cours des deux dernières années, le nombre de grandes entreprises nationales utilisant Greenplum a triplé.

À l'automne 2019, une autre version majeure du SGBD a été publiée. Dans cet article, je parlerai brièvement des principales nouvelles fonctionnalités de GP 6.

La précédente version majeure de Greenplum version 5 a été publiée en septembre 2017, les détails peuvent être trouvés dans cet article . Si vous ne savez toujours pas ce qu'est Greenplum, une brève introduction peut être obtenue à partir de cet article . Il est ancien, mais l'architecture du SGBD se reflète correctement.

La version actuelle, de droit, peut être qualifiée d'idée collective: plusieurs sociétés du monde entier ont participé au développement - parmi lesquelles Pivotal, Arenadata (où travaille l'auteur de cet article), Alibaba.

Alors quoi de neuf dans Greenplum 6?

Tables répliquées


Permettez-moi de vous rappeler que dans Greenplum, il y avait deux types de distribution de tables à travers un cluster:

  • Distribution uniforme aléatoire
  • Distribution sur un ou plusieurs domaines

Dans la plupart des cas, la jonction de deux tables (JOIN) a été effectuée avec une redistribution des données entre les segments de cluster pendant l'exécution de la requête, et uniquement si les deux tables ont été initialement distribuées par la clé de jointure JOIN s'est produite localement sur les segments sans transférer de données entre les segments.

GP 6 offre aux architectes un nouvel outil d'optimisation des schémas de stockage - des tables répliquées. Ces tables sont dupliquées en totalité sur tous les segments du cluster. Toute connexion à une telle table sur le côté droit sera effectuée localement, sans redistribution des données. Fondamentalement, la fonctionnalité est destinée au stockage de répertoires volumineux.

Exemple de requête avec table répliquée
CREATE TABLE expand_replicated … DISTRIBUTED REPLICATED; CREATE TABLE expand_random … DISTRIBUTED RANDOMLY; explain select * from expand_rnd a2 left join expand_replicated a3 on a2.gen = a3.gen #  ,    redistribute/broadcast Limit (cost=0.00..1680.04 rows=1 width=22) -> Gather Motion 144:1 (slice1; segments: 144) (cost=0.00..1680.04 rows=2 width=22) -> Hash Left Join (cost=0.00..1680.04 rows=1 width=22) Hash Cond: (expand_rnd.gen = expand_replicated.gen) -> Seq Scan on expand_rnd (cost=0.00..431.00 rows=1 width=10) -> Hash (cost=459.60..459.60 rows=2000000 width=12) -> Seq Scan on expand_replicated (cost=0.00..459.60 rows=2000000 width=12) 


Algorithme de compression Zstandard (ZSTD)


Présenté en 2016 par les développeurs de Facebook, l'algorithme de compression sans perte a presque immédiatement touché le cœur de notre équipe Arenadata, car comparé à Zlib (utilisé par défaut dans Greenplum), il a des taux de compression plus élevés avec moins de temps requis pour la compression et la décompression:


Source: cnx-software.com

L'efficacité de la compression est l'un des paramètres les plus importants du SGBD analytique moderne. En fait, cela vous permet de réduire la charge sur le sous-système de disques relativement cher du cluster en chargeant des CPU relativement bon marché. Lors de la lecture et de l'écriture séquentielles de grandes quantités de données, cela donne une forte réduction du TCO du système.

En 2017, notre équipe a ajouté la prise en charge ZSTD pour les tables de colonnes dans Greenplum, cependant, selon la politique de publication, cette révision n'a pas été introduite dans les versions mineures officielles de Greenplum. Jusqu'à aujourd'hui, il n'était disponible que pour les clients commerciaux d'Arenadata, et avec la version 6.0, tout le monde peut l'utiliser.

Optimisation de l'expansion du cluster (développer)


Dans les versions précédentes de GP, l'expansion de cluster horizontale (ajout de nouveaux nœuds) avait certaines limites:

  • Même si la redistribution des données s'est produite en arrière-plan sans interruption, un redémarrage du système était nécessaire lors de l'ajout de nouveaux nœuds
  • L'algorithme de hachage et de distribution des données nécessitait une redistribution complète de toutes les tables pendant l'expansion - le processus de distribution des données en arrière-plan pouvait prendre des heures, voire des jours, pour des clusters particulièrement importants.
  • Lors de la distribution en arrière-plan des tables, toute jointure était uniquement distribuée

Greenplum 6 a introduit un tout nouvel algorithme d'extension de cluster, grâce auquel:

  • L'extension se produit maintenant sans redémarrer le système - aucun temps d'arrêt n'est nécessaire
  • L'algorithme de hachage cohérent vous permet de redistribuer uniquement une partie des blocs lors de l'ajout de nœuds, c'est-à-dire que la redistribution en arrière-plan des tables fonctionne beaucoup plus rapidement
  • La logique de changement des répertoires système a changé - maintenant, même pendant le processus d'expansion, toutes les connexions (JOIN) fonctionnent comme d'habitude - à la fois localement et distribuées

Maintenant, l'extension Greenplum est une question de minutes, pas d'heures, cela permettra aux clusters de suivre l'appétit toujours croissant des unités commerciales.

Sécurité au niveau des colonnes


Il est maintenant possible de distribuer des droits sur des colonnes spécifiques dans les tables (la fonctionnalité est venue de PostgreSQL):

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

Jsonb


Le stockage binaire et optimal des objets de type JSON est désormais disponible dans le GP. En savoir plus sur le format ici .

Explication automatique


Une autre grande extension qui est venue au GP de PostgreSQL. Il a été modifié pour fonctionner en mode distribué sur le cluster Greenplum par l'équipe d'Arenadata.

Permet automatiquement à chaque demande (ou prise séparément) dans le SGBD d'enregistrer des informations sur:

  • plan de demande;
  • les ressources consommées à chaque étape de l'exécution de la requête sur chaque segment (nœud);
  • le temps passé;
  • le nombre de lignes traitées à chaque étape de la requête sur chaque segment (nœud).

Diskquota


Extension PostgreSQL qui vous permet de limiter le stockage sur disque disponible pour les utilisateurs individuels et les schémas:

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

Nouvelles fonctionnalités de distribution Arenadata DB


Avis de non-responsabilité - il y aura quelques lignes de publicité à côté :)

Permettez-moi de vous rappeler que nous, Arenadata, développons, implémentons et soutenons notre plate-forme de stockage de données basée sur des technologies open source - Greenplum, Kafka, Hadoop, Clickhouse. Nos clients sont les plus grandes entreprises russes dans les domaines de la vente au détail, des télécommunications, des technologies financières et autres. D'une part, nous contribuons eux-mêmes aux projets open source (en apportant des modifications au noyau), d'autre part, nous développons des fonctionnalités supplémentaires qui ne sont disponibles que pour nos clients commerciaux. Plus loin, nous parlerons des principales caractéristiques.

Tkhemali Connector aka Connector Greenplum -> Clickhouse


Dans les projets, nous utilisons souvent le bouquet Greenplum + Clickhouse - d'une part, cela nous permet d'utiliser les meilleurs modèles classiques de construction d'entrepôts de données (des sources aux data marts) qui nécessitent de nombreuses connexions, une syntaxe SQL ANSI développée, la transactionnalité et d'autres puces que Greenplum possède, d'autre part, pour donner accès à de grandes vitrines intégrées avec une vitesse maximale à un nombre important d'utilisateurs - et Clickhouse n'a pas de concurrents dans ce domaine.

Pour utiliser efficacement un tel bundle, nous avons développé un connecteur parallèle spécial qui, de manière transactionnelle (c'est-à-dire cohérent même dans le cas d'une transaction de restauration) vous permet de transférer des données du GP vers KH. En général, l'architecture de ce connecteur mérite un article purement technique distinct - en fait, à l'intérieur, nous avons dû implémenter des files d'attente asynchrones parallèles avec un système pour sélectionner dynamiquement le nombre de threads par insert et le flux de données.

Le résultat est une vitesse d'interaction fantastique: dans nos tests sur des disques SATA typiques, nous obtenons jusqu'à 1 Gb / s par insert sur une paire de serveurs Greenplum - Clickhouse. Étant donné que le cluster GP moyen de nos clients comprend plus de 20 serveurs, la vitesse d'interaction est plus que suffisante.

Connecteur Kafka


Nous avons fait de même avec l'intégration avec le courtier de messages Kafka - nous rencontrons souvent la tâche de surcharger les données de Kafka vers Greenplum en mode quasi-temps réel (secondes ou dizaines de secondes). Cependant, l'architecture du connecteur pour Kafka est différente. Un connecteur est un cluster de processus synchronisés séparés (lancés dans Docker) avec détection automatique, qui, d'une part, sont des consommateurs Kafka, et d'autre part, insèrent des données directement dans les segments Greenplum. Le connecteur peut fonctionner avec Kafka Registry et garantit la cohérence complète des données transférées même en cas de panne matérielle.

Système de gestion et de suivi


Le fonctionnement du système en production impose des exigences élevées sur le déploiement, la mise à jour et la surveillance du cluster. Il est important que tout ce qui se passe dans le SGBD soit transparent pour les opérations et les spécialistes DBA.

Notre système de gestion et de surveillance Arenadata Cluster Manager (ADCM) offre aux professionnels de l'exploitation tous les outils dont ils ont besoin. En fait, le déploiement et la mise à jour du cluster Greenplum se fait en un clic sur un bouton de l'interface graphique (tous les OS, services, montage de disque et paramètres réseau se font automatiquement), en plus, vous obtenez une pile de surveillance entièrement configurée, prête à s'intégrer à vos systèmes d'entreprise. Soit dit en passant, Arenadata Cluster Manager peut gérer non seulement Greenplum, mais aussi Hadoop, Kafka, Clickhouse (nos assemblages de ces services sont requis. Leurs versions gratuites, comme ADCM lui-même, peuvent être téléchargées gratuitement sur notre site Web , simplement en remplissant une fenêtre contextuelle).

Conclusion


Si vous utilisez Greenplum 5.X, je vous recommande d'envisager la mise à niveau de votre cluster vers la version actuelle 6.X dans les 2-3 prochains mois.

Si vous n'utilisez pas encore Greenplum, rejoignez-nous! Nous, Arenadata, sommes toujours prêts à vous aider.

Les références


Greenplum sur github
Greenplum Russia Telegram channel - posez vos questions directement aux utilisateurs de Greenplum
Documentation de Greenplum 6

Source: https://habr.com/ru/post/fr474008/


All Articles