ETL efficace dans une base de données analytique ?

Récemment, j'ai travaillé sur un POC qui nécessitait une réflexion inhabituelle. Le défi était que le cas d'usage du client ne nécessitait pas seulement des analyses SQL de de haute performance mais aussi une bonne quantité d'ETL (Extract, Transform, and Load). Plus précisément, le client avait besoin d'ELT (ou même d'ETLT si l'on veut être tout à fait précis).

Pourquoi cela aurait-il pu poser problème ? En général, les bases de données analytiques et le traitement de type ETL ne font pas bon ménage ; ce dernier a tendance à être axé sur les lignes, tandis que la base de données analytique typique préfère nettement traiter les données de manière "volumineuse". En général, les bases de données analytiques sont capables de charger des données en masse à très grande vitesse, mais elles ont tendance à offrir un débit modeste ligne par ligne.

Une autre caractéristique typique est l'utilisation d'un verrouillage en écriture au niveau de la table, ce qui permet de sérialiser les transactions d'écriture en les limitant à une seule à la fois. Ceci est généralement accepté car les cas d'utilisation des bases de données analytiques ont tendance à concerner les requêtes plutôt que tout type de traitement des transactions. Cependant, lorsqu'une certaine forme d'ETL est nécessaire, elle est peut-être encore plus problématique que le débit ligne par ligne, car elle exige que le concepteur et l'outil de chargement soient conscients de cette caractéristique. Le concepteur doit souvent "sauter à travers des cerceaux" pour comprendre comment introduire les données dans la base de données analytique d'une manière que les autres membres de l'équipe peuvent comprendre et que l'outil peut fournir.

Je prépare ici le terrain pour la "grande révélation" selon laquelle les bases de données de traitement vectoriel d'Actian ne souffrent pas de ces inconvénients. Elles peuvent offrir à la fois des capacités analytiques haut de gamme et des capacités OLTP à la manière des technologies HTAP (Hybrid Transactional/Analytical Processing).

Notez les guillemets autour de "capacitésOLTP " - pour être clair, chez Actian, nous ne positionnerions pas ces bases de données OLTP de de haute performance , nous disons simplement que les capacités (verrouillage au niveau des lignes et modifications simultanées des tables) sont présentes même si la base de données est un moteur de traitement vectoriel, in-memory et en colonnes).

Quelle que soit la manière dont on les considère, ce sont ces capacités qui nous ont permis d'atteindre les objectifs du client, même s'il a fallu un peu de cajolerie. Dans la suite de ce billet, je décrirai les étapes que nous avons suivies et les résultats que nous avons obtenus. Si vous n'utilisateur pas Actian Vector ou Actian Vector in Hadoop ((VectorH), vous pouvez sauter à la fin, mais si vous utilisez la technologie, lisez ce qui suit.

Configuration de l'ETL

Pour en revenir au cas d'usage, le client avait besoin de charger en parallèle de grands volumes de données provenant de différentes sources dans les mêmes tables. Nous avons dit plus haut que nous offrions des "capacités OLTP", mais la configuration prête à l'emploi est plus adaptée à une mise à jour en bloc par table - nous avons dû modifier la configuration pour gérer plusieurs modifications en bloc simultanées.

Au cœur des bases de données Actian se trouve une architecture en colonnes et, dans tous les cas, le magasin de colonnes sous-jacent est modifié en une seule transaction. La fonction de mise à jour simultanée est issue d'une technologie astucieuse qui met en in-memory tampon les mises à jour de manière transparente et conforme à la norme ACID. La configuration par défaut suppose un petit modèle de mémoire et achemine donc les modifications à grande échelle directement vers le magasin de colonnes, tandis que les mises à jour plus petites sont acheminées vers le tampon in-memory . Les opérations de maintenance effectuées sur le tampon in-memory - telles que l'évacuation des modifications vers le magasin de colonnes - sont déclenchées par des seuils de ressources définis dans la configuration.

C'est ici que, avec la configuration par défaut, vous pouvez être confronté à un défi - des situations se présentent lorsque des mises à jour à grande échelle envoyées directement au magasin de colonnes peuvent entrer en conflit avec la routine de maintenance de la mémoire tampon in-memory . Pour que cela fonctionne bien, nous devons ajuster la configuration pour tenir compte du fait qu'il y a - presque certainement - plus de mémoire que ce que la configuration par défaut suppose. L'installateur pourrait peut-être définir ces paramètres en conséquence, mais avec une base installée importante, il est plus sûr de conserver le même comportement afin de maintenir la cohérence entre les versions.

Nous devions donc faire deux choses : premièrement, acheminer toutes les modifications via la mémoire tampon in-memory et, deuxièmement, configurer la mémoire tampon in-memory manière à ce qu'elle soit suffisamment grande pour traiter la quantité de données que nous allions charger. Nous aurions également pu faire une troisième chose, à savoir rendre les routines de maintenance manuelles et intégrer les commandes pour les déclencher dans les processus ETL eux-mêmes, en leur donnant un contrôle total sur ce qui se passe et à quel moment.

L'acheminement de toutes les modifications à travers le tampon in-memory se fait à l'aide du paramètre insertmode. Le changement de ce paramètre signifie que les opérations en masse qui iraient normalement directement dans le magasin de colonnes passent maintenant par le tampon in-memory , ce qui permet d'effectuer plusieurs opérations en masse simultanément.

Le dimensionnement du tampon in-memory consiste simplement à ajuster les valeurs de seuil en fonction de la quantité de mémoire disponible ou, comme nous l'avons suggéré plus haut, à faire en sorte que le processus soit entièrement contrôlé par le processus ETL.

Le tableau ci-dessous décrit les options de configuration qui affectent le processus :

Pour déclencher le processus de maintenance manuellement, exécutez :

modify <table> to combine

Si vous souhaitez obtenir plus de détails techniques sur la mise en œuvre de ce traitement, un article de la base de connaissances est disponible ici :

Résultat

Le chargement initial des données du client - avec la configuration par défaut - a pris environ 13 minutes. En ajustant les paramètres de mémoire pour que la routine de maintenance soit invoquée moins souvent, ce délai a été ramené à un peu plus de 9 minutes. Le passage à un traitement entièrement in-memory (toujours un flux unique à ce stade) a fait passer le temps à un peu moins de 9 minutes. Il s'agit là d'un aspect intéressant des tests : le fait de tout acheminer via le tampon in-memory n'a pas ralenti le processus, il a même amélioré le temps, même si ce n'est que par un petit facteur.

Une fois le chargement effectué via la mémoire tampon in-memory , le chargement peut être effectué en flux parallèles. Le résultat final a été de pouvoir charger les données en un peu plus d'une minute via huit flux parallèles. Il s'agit d'un bon résultat étant donné que le système existant du client - basé sur OLTP - prenait plus de 90 minutes pour charger les mêmes données avec dix flux parallèles.

Conclusion

Les bases de données analytiques sont généralement confrontées à des difficultés lorsqu'elles tentent de charger des données à l'aide d'outils et de méthodes ETL traditionnels - elles se caractérisent par une faible vitesse de traitement ligne par ligne et, plus particulièrement, par un verrouillage en écriture au niveau de la table.

Les bases de données de traitement vectoriel d'Actian disposent d'une technologie innovante qui leur permet d'éviter ces problèmes et d'offrir des "capacités OLTP". Bien qu'elles ne ciblent pas les cas d'utilisation OLTP, ces capacités permettent aux bases de données d'Actian d'utiliser simultanément des chargements à haute performance et de fournir ainsi de bonnes performances pour les charges de travail ETL.

Lire l'article KB

À propos d'Actian Corporation

Actian facilite l'accès aux données. Notre plateforme de données simplifie la façon dont les gens connectent, gèrent et analysent les données dans les environnements cloud, hybrides et sur site . Avec des décennies d'expérience dans la gestion des données et l'analyse, Actian fournit des solutions de de haute performance qui permettent aux entreprises de prendre des décisions basées sur les données. Actian est reconnu par les principaux analystes et a reçu des prix de l'industrie pour sa performance et son innovation. Nos équipes partagent des cas d'utilisation éprouvés lors de conférences (par exemple, Strata Data) et contribuent à des projets à code source ouvert. Sur le blog d'Actian, nous abordons des sujets tels que l'ingestion de données en temps réel, l'analyse de données, la gouvernance données, la gestion des données, la qualité des données, l'intelligence des données et l'analyse pilotée par l'IA.