Critique de Greenplum 6: Homme à tout faire, maître de certains

Une base de données MPP (traitement massivement parallèle) distribue les données et les requêtes sur chaque nœud d'un cluster de serveurs de base. L'approche de Greenplum pour la construction d'un entrepôt de données MPP est unique. En s'appuyant sur une base de données open source établie, PostgreSQL, ils sont en mesure de concentrer les efforts d'ingénierie sur l'ajout de valeur là où cela compte: la parallélisation et la planification des requêtes associées, un magasin de données en colonnes pour l'analyse et des capacités de gestion.

Greenplum est détenu et développé par Pivotal, avec le soutien de la communauté open source, et est disponible gratuitement sous la licence Apache 2. La dernière version, Greenplum 6.0, va un long chemin vers la réintégration du noyau Greenplum avec PostgreSQL, incorporant près de six ans d'améliorations du projet PostgreSQL. Ces efforts signifient qu'à l'avenir, Greenplum bénéficiera de nouvelles fonctionnalités et améliorations «gratuitement», tandis que Pivotal se concentre sur le bon fonctionnement de ces ajouts dans un environnement parallèle.

Architecture de Greenplum

Une base de données MPP utilise ce que l'on appelle une architecture de partage rien . Dans cette architecture, des serveurs de base de données individuels (basés sur PostgreSQL), appelés segments, traitent chacun une partie des données avant de renvoyer les résultats à un hôte maître. Des architectures similaires sont observées dans d'autres systèmes de traitement de données, comme Spark ou Solr. C'est l'une des principales caractéristiques architecturales qui permet à Greenplum d'intégrer d'autres systèmes parallèles, comme l'apprentissage automatique ou l'analyse de texte.

Étant donné que Solr, par exemple, a une architecture distribuée similaire, Greenplum peut relier les instances de traitement Solr individuelles aux hôtes de segment pour fournir une expérience de requête et d'analyse plus ou moins transparente. Cela signifie également que les données sont traitées sur place, évitant ainsi des mouvements coûteux de données sur le réseau.

Pivot

Déploiement de Greenplum

Greenplum peut être déployé de plusieurs manières: dans les trois principaux clouds via leurs marchés respectifs, en conteneur ou sur du métal nu. Comme pour toute application de cluster, les meilleures performances sont obtenues sur des machines bare metal dédiées. J'ai déployé un cluster à deux nœuds sur Google Cloud Platform avec tous les cloches et sifflets en quelques minutes. Et j'ai installé Greenplum localement dans une VM en utilisant les binaires précompilés en une heure environ.

L'installation locale était nécessaire car Greenplum 6 n'est pas encore disponible dans les nuages; il est prévu pour novembre 2019. L'installation locale m'a également donné l'occasion d'évaluer la qualité de la documentation Greenplum. Comme vous pouvez vous y attendre d'un autre produit propriétaire à source fermée, il est excellent.

Le fait de disposer de plusieurs options de déploiement permet aux entreprises d'affiner leurs déploiements en fonction des exigences opérationnelles. Par exemple, les modèles peuvent être entraînés sur un cluster bare metal multi-nœuds pour un développement rapide de modèles, puis déployés sur une seule instance de Pivotal Postgres exécutant un point de terminaison REST dans un conteneur pour opérationnaliser le modèle.

Requêtes fédérées Greenplum

Aujourd'hui, les données sont partout - dans différents endroits, différents formats et différentes «températures». Le Pivotal Extension Framework (PXF), introduit dans Greenplum 5, est né de l'ancien connecteur HDFS pour devenir une méthode générale d'accès aux tables de données externes dans Greenplum. PXF se connecte également à différents formats de données, tels que des fichiers texte (par exemple, des journaux Web), des bases de données étrangères, ORC, Parquet et HBase. De nouvelles sources de données peuvent être ajoutées à PFX à l'aide d'une API Java.

En combinant PXF avec les capacités d'accès externe apportées avec PostgreSQL 9.4, Greenplum peut effectuer des requêtes fédérées sur les emplacements de données, y compris les flux Kafka, HDFS, Spark et les magasins d'objets Amazon S3. Cette dernière capacité, qui interroge les magasins d'objets Amazon S3, inclut l'API S3 SELECT native d'Amazon, améliorant les performances en filtrant en périphérie. 

Les requêtes fédérées peuvent être plus utiles que vous ne l'imaginez. Par exemple, supposons que nous souhaitons localiser tous les individus qui:

travailler à '' et se connaître 'directement' et dont les noms sonnent comme 'Doug' ou 'Steve' et se sont téléphoné dans les 24 heures depuis Singapour ou San Francisco

Ce type de requête peut être vu dans une enquête sur la fraude ou en réponse à une demande d'informations d'un régulateur financier. Dans une entreprise typique, cette information sera répartie sur une demi-douzaine de systèmes différents ou plus et il faudra peut-être une semaine ou plus pour y répondre. Avec la requête fédérée, nous pouvons l'assembler en une seule requête et répondre en une heure. Dans une ère de surveillance réglementaire renforcée, de nombreuses entreprises ont du mal à éviter des amendes pour répondre tardivement aux requêtes, et les requêtes fédérées aident beaucoup ici.

Analyse Greenplum et apprentissage automatique

L'extension MADlib de Greenplum, une bibliothèque SQL pour l'analyse de données et l'apprentissage automatique, a été initialement développée par plusieurs universités et Greenplum. MADlib a été conçu pour fonctionner avec l'architecture parallèle sans partage de Greenplum. Tous les algorithmes d'apprentissage automatique ne peuvent pas être mis en parallèle, mais pour ceux qui le peuvent, MADlib atteint une évolutivité plus ou moins linéaire avec la taille de l'ensemble de données, tout en évitant les transferts de données. MADlib comprend un peu plus de 50 des algorithmes d'apprentissage automatique les plus couramment utilisés.

L'une des fonctionnalités les plus utiles de MADlib est l'interface SQL, qui permet au data scientist citoyen d'ajouter de la valeur sans avoir à gravir la courbe d'apprentissage de Python ou R. Les modèles peuvent être déployés via un point de terminaison MADlib REST pour opérationnaliser les informations analytiques. Pour une entreprise qui a un niveau moyen de maturité analytique et qui met en œuvre des stratégies de gestion des décisions de champion / challenger, l'utilisation de SQL peut augmenter le nombre de modèles considérés sans que des ressources supplémentaires soient détournées d'une équipe centrale.

Pour l'analyste de données traditionnel, le connecteur PivotalR (disponible sur CRAN) fournit une interface de langage R classique à MADlib en traduisant le code R en instructions SQL correspondantes sur le client, puis en les envoyant au cluster Greenplum pour exécution. Cela évite le transfert de données et permet la manipulation de grandes trames de données qui seraient autrement impossibles dans R en raison de contraintes de mémoire.

Pivot

Entrepôt de données HTAP

Le traitement transactionnel / analytique hybride (HTAP) est un terme inventé par Gartner. Leur définition:

Le traitement transactionnel / analytique hybride (HTAP) est une architecture d'application émergente qui «brise le mur» entre le traitement des transactions et l'analyse. Il permet une prise de décision plus informée et «en temps réel». 

En pratique, cela signifie que les cas d'utilisation du système sont un mélange de requêtes longues et courtes, ainsi que de mises à jour et de suppressions. Afin de prendre en charge HTAP et d'éviter la famine des ressources, Greenplum implémente une forme de conteneurisation SQL appelée groupes de ressources qui permet l'isolation des ressources dans un environnement HTAP mutualisé. En utilisant un groupe de ressources, vous pouvez limiter le processeur, la RAM (par groupe ou requête) et la concurrence maximale. Les groupes de ressources améliorent les performances sur les charges de travail mixtes et empêchent la concurrence des requêtes pour les ressources.

L'une des principales différences entre PostgreSQL et Greenplum est le planificateur de requêtes. Bien que Greenplum ait hérité du planificateur de requêtes PostgreSQL lors de sa création, une planification efficace des requêtes dans un environnement distribué est très différente de celle sur une seule machine. Pour cette raison, Greenplum a entrepris de créer son propre planificateur de requêtes, en se basant sur le Framework Cascades pour l'optimisation des requêtes. Cet algorithme évalue tous les plans de requête possibles et leur attribue un coût, en sélectionnant le plan d'exécution le moins coûteux (le plus rapide).

Greenplum fournit quelques fonctionnalités pour aider le planificateur de requêtes à éviter le mouvement des données, comme la possibilité de répliquer les tables de dimension sur chaque nœud du cluster pour des opérations de jointure locale plus rapides et une compression de données ajustable.

Le traitement des données semi-structurées est hérité de PostgreSQL et inclut JSON et JSONB, XML, des paires clé-valeur (HSTORE) et du texte brut. GIN (Generalized Inverted Index), également hérité de PostgreSQL, peut être utilisé pour indexer une colonne de texte fréquemment utilisée. Pour les requêtes de texte plus complexes, GPText peut être utilisé. GPText intègre les segments Greenplum aux fragments Apache Solr pour fournir des requêtes de recherche en langage naturel. Étant donné que les fragments Solr se trouvent sur le même nœud, ils ont la même architecture parallèle.

Performance de Greenplum

Les bases de données HTAP nécessitent un équilibre entre les requêtes analytiques volumineuses et de longue durée, les requêtes ad hoc courtes et les transactions ACID du côté OLTP de l'équation. De bonnes performances dans ce scénario de charge de travail mixte sont importantes pour le cas d'utilisation hybride que Greenplum vise. Le noyau PostgreSQL 9.4 a donné à Greenplum 6 une foule d'optimisations, principalement pour éviter les verrous, qui se traduisent par une augmentation de 60 fois des performances par rapport à Greenplum 5 sur les benchmarks TPC-B.

Pivot

Étant donné que PostgreSQL a ouvert la voie à d'autres optimisations (et est maintenant sur la version 12), nous pouvons nous attendre à d'autres améliorations dans Greenplum car le noyau est à nouveau mis à jour dans Greenplum 7.

Centre de commande Greenplum

Le centre de commande Greenplum fait partie de l'offre Pivotal et fournit une interface Web pour surveiller et gérer un cluster Greenplum (ou plusieurs clusters). Bien qu'il soit peu probable que les administrateurs de base de données à noyau dur abandonnent leurs interfaces de ligne de commande, le centre de commande est un outil de gestion bienvenu pour les déploiements au niveau des services qui peuvent ne pas avoir accès à un administrateur de base de données à plein temps. Je l'ai trouvé facile à naviguer et bien documenté. Les utilisateurs, requêtes, nœuds, segments et groupes de ressources peuvent tous être facilement gérés via l'interface.

Greenplum dans l'entreprise

Greenplum constitue un choix idéal pour une norme ministérielle, car il peut gérer des charges de travail mixtes, y compris l'analyse prédictive, sur une seule plateforme. Si vous ne choisissez pas de logiciel à la carte dans un menu ELA, ou si vous souhaitez échapper au `` purgatoire pilote '' de l'IA, l'investissement dans l'approche HTAP de Greenplum pourrait fournir un moyen d'augmenter les utilisations innovantes de l'apprentissage automatique et de l'analyse à un prix inférieur. que des solutions concurrentes.

Greenplum est également une évidence pour les remplacements Netezza ou Teradata au niveau de l'entreprise. Et bien que Greenplum ne soit pas tout à fait prêt à arracher OLTP à Oracle Database ou Microsoft SQL Server dans toute l'entreprise, cela fonctionnera bien pour les systèmes transactionnels de taille moyenne.

Greenplum est un bon exemple de la règle des 80/20. Bien qu'il n'effectue aucune tâche unique ainsi qu'un outil conçu à cet effet, il le fait assez bien pour couvrir 80% des cas d'utilisation, et cela sans les frais organisationnels et opérationnels impliqués dans l'assemblage de plusieurs systèmes et en les intégrant dans un pipeline d'analyse. Cela pèse lourdement en sa faveur lorsque l'on considère le coût total de possession.

Coût : Open source gratuit sous licence Apache 2.0. 

Plateformes : disponibles en tant que code source; en tant que paquets pour les distributions CentOS, Red Hat, Debian et Ubuntu Linux; et sur les marchés Amazon Web Services, Microsoft Azure et Google Cloud Platform.