de haute performance analyses des données en temps réel sur Hadoop Data

Le défi

J'ai passé de nombreuses années à travailler avec les clients d'Actian sur des solutions de bases de données et j'ai pensé qu'il serait utile de discuter d'une expérience client récente avec expérience client d'une grande entreprise de médias (que j'appellerai "XYZCo"). Cette expérience est similaire à celle que je continue à observer chez d'autres clients et les leçons apprises s'appliquent aussi bien aux cas d'utilisation Hadoop que non Hadoop.

Dans ce cas, l'équipe d'analyse des données big data de XYZCo s'est adressée à Actian parce qu'elle avait besoin d'analyses des données en temps réel de de haute performance analyses des données en temps réel pour ses données Hadoop, et que ses systèmes actuels n'étaient pas en mesure de répondre aux attentes de l'entreprise. Ils étaient soumis à une pression énorme pour améliorer la productivité de leurs analystes de données, car l'analyse de certains grands ensembles de données ne se terminait jamais et ils devaient réduire les frais généraux de traitement des données et les retards pour permettre l'analyse et le reporting en temps réel de l 'entrepôt de données.

La situation

Le client disposait de deux tables de faits et de dimensions très volumineuses dans sa base de données. Pour répondre à des questions commerciales sur l'attrition des clients, la valeur à vie et le marché, il avait besoin de joindre les deux tables pour exécuter des requêtes.

Les bases de données existantes et les solutions Hadoop étant très inefficaces pour joindre les données (parfois, les jointures importantes ne se terminent jamais), XYZCo avait adopté une pratique consistant à joindre les tables ensemble et à créer unetable intermédiaire pré-jointe/matérialisée, sur laquelle les requêtes ultérieures étaient exécutées. Cette méthodologie fonctionnait mais présentait plusieurs problèmes : la table de pré-jonction, la matérialisation, était ÉNORME ; sa taille était exponentielle par rapport à celle de la table1 et de la table2 (et pas seulement des copies de la table1 et de la table2), et immédiatement après sa création, la matérialisation était "périmée" ; elle ne pouvait pas être constamment mise à jour à partir de la table1 et de la table2, qui changeaient constamment, mais restait avec les anciennes valeurs au moment de la création. En outre, les performances de la requête par rapport à cette matérialisation n'étaient pas très bonnes et certaines requêtes ne fonctionnaient tout simplement pas... les données étaient tout simplement trop volumineuses.

En outre, ce client disposait de gros volumes de données structurées dans un magasin de données Hadoop. Il utilisait actuellement Hive ainsi que des outils d'analyse basés sur SQL, notamment Tableau. Le client avait l'habitude de pré-joindre les données de plusieurs tables sources avec l'avantage "perçu" d'une interrogation plus simple et plus rapide par d'autres outils et processus en aval. De plus, la plupart de ces agrégats/jointures étaient exportés au format CSV pour être introduits dans d'autres outils ou matérialisés pour un SQL "perçu" comme plus simple, car le schéma devenait une seule table source aplatie.

Comparaison des solutions

Test de matérialisation à l'ancienne

XYZCo nous a demandé d'effectuer également le test de matérialisation à l'ancienne en utilisant Actian VectorH, la base de données SQL en colonnes de de haute performance d'Actian qui fonctionne nativement dans Hadoop, avec l'idée qu'il s'agirait d'une comparaison directe avec Hive. C'est ce que nous avons fait.

Une grande partie de toute matérialisation est le temps passé à faire des E/S pour écrire le grand ensemble de résultats matérialisés. Bien que VectorH ait été beaucoup plus rapide que Hive sur la jointure elle-même, la partie E/S de l'ensemble du processus de matérialisation a éclipsé n'importe quel composant de jointure - rapide ou lent. Bien que beaucoup plus rapide sur la jointure elle-même, VectorH, dans ce cas, a exécuté l'ensemble du processus de matérialisation dans le même délai que Hive parce qu'une grande partie du temps a été consacrée à l'écriture de l'ensemble de résultats, qui était le même pour les deux produits.

Une fois construit, nous avons exécuté les requêtes contre la matérialisation, VectorH était environ deux fois plus rapide que l'autre produit. Rappelez-vous pour une lecture ultérieure que la taille de la matérialisation est exponentielle par rapport à celle des tables sources.

Bien qu'impressionnants, ces résultats ne sont pas à la hauteur de ce que je vais vous dire à propos de l'approche à la demande d'Actian.

analyses des données en temps réel Avec Actian VectorH On-Demand

Après avoir effectué le test de matérialisation intermédiaire de la vieille école, nous avons voulu montrer au client une meilleure façon de procéder. Nous avons démontré qu'avec VectorH, les requêtes sur les données de base (sans étape de matérialisation intermédiaire) avec la jointure effectuée à la demande, étaient des ordres de grandeur plus rapides !

Voici les données brutes capturées sur les systèmes Hive et VectorH des clients pour les résultats d'une seule exécution. Notez que les tests VectorH ont été effectués sur un cluster deux fois plus petit que le cluster Hive. VectorH présente d'excellentes caractéristiques d'évolutivité linéaire, c'est pourquoi nous avons normalisé les résultats pour une plateforme équivalente.

Comme mentionné précédemment, une matérialisation était dans la même zone, VectorH était deux fois plus rapide sur les requêtes contre une matérialisation. Ce qui est plus intéressant, cependant, ce sont les cas où Hive n'a pas été en mesure de réaliser des scénarios de jointure à la demande et où Actian VectorH a fait preuve d'une vitesse extraordinaire.

Les avantages susmentionnés ne concernent qu'une seule exécution. Que se passe-t-il dans des situations réelles avec des centaines de requêtes de clients et une mise à jour continue des données ?

Le tableau ci-dessous montre ce qui se passe avec seulement 100 et 200 requêtes clients, plus une actualisation des données clients. Remarquez qu'avec la vitesse de VectorH, l'ancienne solution, même en utilisant des pré-matérialisations, est toujours plus lente, prend du temps pour la re-matérialisation et ne pourra jamais rattraper son retard. L'approche Actian VectorH écrase le concurrent en termes de performance. Cela s'ajoute aux autres avantages : les résultats sont basés sur des données actuelles plutôt que sur des données périmées, l'espace disque est économisé, il y a moins d'administration, etc.

Notez également que ces résultats ne tiennent même pas compte de la simultanéité. VectorH bénéficie d'une incroyable simultanéité. Les chiffres mentionnés ci-dessus seraient encore meilleurs pour VectorH si nous les avions obtenus dans une situation de simultanéité.

Conclusion

Dans la solution à la demande, les résultats des requête reflétaient TOUJOURS les données actuelles et non les résultats d'une matérialisation périmée, ce qui permettait analyses des données en temps réel et des résultats plus précis.

Les analystes n'ont plus à attendre la création d'un instantané et leurs jointures peuvent être effectuées de manière ad hoc.

Les performances nettes ont été nettement plus rapides qu'avec une préagrégation géante car chaque requête ne scanne que les données dont elle a besoin plutôt que toutes les lignes d'une matérialisation gigantesque, ce qui réduit les entrées-sorties coûteuses et évite les temps d'arrêt liés à la reconstruction de la matérialisation intermédiaire.

Les vues ont été utilisées pour masquer la logique de jointure aux utilisateurs finaux, simplifiant ainsi les requêtes. Comme il n'y a pas de duplication des données via la matérialisation, l'espace de stockage est réduit au minimum.

Sans un moteur de JOIN rapide comme VectorH, cette approche est généralement peu pratique pour les très grands ensembles de données.

Prochaines étapes

Vous voulez en savoir plus sur Actian VectorH ?

Vous pouvez également télécharger et essayer Actian Vector vous-même. Vous ne serez pas déçu, et si vous avez besoin d'aide pour comprendre, demandez à la communauté ou contactez eval@actian.com pour demander une évaluation de 30 jours de VectorH avec un Supportentreprise gratuit.

À propos de Mary Schulte

Mary Schulte est ingénieur commercial principal chez Actian. Elle a passé l'essentiel de sa carrière à travailler pour des fournisseurs de bases de données de premier plan tels qu'Informix, Netezza et, aujourd'hui, Actian. Pendant plus de vingt ans, elle n'a travaillé qu'avec Informix en tant que consultante dans une société de conseil, puis en tant que formatrice et ingénieur commercial pour Informix Corp. et IBM. Elle a écrit des milliers de lignes de programmes Informix 4GL et ESQL/C pour des clients de divers secteurs dans le monde entier. Basée à Dallas, elle a travaillé en étroite collaboration avec American Airlines sur sa mise en œuvre innovante de la nouvelle technologie Informix datablade à la fin des années 1990. Mary travaille chez Actian depuis 2006, principalement sur la technologie Vector base de données analytique . Elle pense que le fait qu'IBM ait conclu un accord avec HCL et que HCL ait acquis Actian est un heureux hasard, car elle travaille à nouveau avec son Informix bien-aimé !