Gestion des données in-memory dans CAS

de Nicolas Housset · 08/11/2022 ·

La manière dont le serveur SAS Viya Cloud Analytic Services (CAS) gère les données en mémoire est un sujet complexe. Il y a de nombreuses subtilités et possibilités à aborder, ce qui le rend compliqué. J'aborde le sujet dans plusieurs articles, cependant, la plupart de ces comportements peuvent être réduits à quelques règles simples qui décrivent suffisamment la majorité des situations. Cet article vous fournira un guide concis mais illustratif sur le fonctionnement interne de la gestion des données en mémoire par CAS.

Le CAS_DISK_CACHE

L'une des nombreuses nouvelles fonctionnalités de SAS Cloud Analytics Services (CAS) par rapport au LASR (le moteur in-memory de SAS 9 ) est la possibilité d'utiliser une mémoire cache comme réserve de stockage pour les données en mémoire. Cette mémoire cache offre une flexibilité pour les opérations en mémoire, garantissant que le CAS :

Maintient la disponibilité des tables lorsque plus de données sont chargées que de RAM physique disponible.
Fournit une protection en cas de défaillance imprévue d'un worker CAS.

Pour améliorer l'efficacité de la mémoire, CAS organise les données en mémoire en blocs et effectue une cartographie en mémoire de ces blocs. Les blocs sont stockés sous forme de fichiers temporaires, le CAS_DISK_CACHE

La taille requise pour ce cache varie pour chaque déploiement, mais peut aller jusqu'à faire plusieurs téraoctets.

La structure des répertoires doit être identique sur chaque contrôleur et chaque worker, mais le contrôleur n'a pas besoin du même volume d'espace que chaque worker( Le contrôleur utilise également temporairement le répertoire de cache pour stocker les fichiers téléchargés.)

Les données in-memory et le CAS_CACHE_DISK

Le memory-mapping associe une adresse dans la RAM à un emplacement dans un espace de stockage localement accessible, le CAS_CACHE_DISK

La plupart du temps, le CAS va mapper en mémoire toutes les données chargées vers le CAS_DISK_CACHE. Cependant, le CAS_DISK_CACHE n'est pas la seule réserve de stockage pour les données en mémoire.

Si les données sources d'origine sont déjà au format SASHDAT non chiffré et accessibles via un stockage local, alors le CAS les mappera en mémoire vers cet emplacement comme réserve de stockage, mais uniquement pour les données sources. J'en parle dans la section suivante.

Toutes les modifications apportées aux données en mémoire sont exclusivement mappées en mémoire vers le CAS_DISK_CACHE.

CAS s'appuie sur le système d'exploitation pour gérer les déplacements des données entre la ram physique ou dans le CAS_CACHE_DISK. C'est le système d'exploitation qui déplace les données vers/depuis le
CAS_CACHE_DISK . Voici une explication simplifiée : Le CAS place initialement les données soit en RAM soit sur le disque, puis crée la table
memory map. Ensuite, CAS fait référence à l'emplacement en mémoire des données dont il a besoin. Si les données sont déjà en RAM, c'est parfait, elles sont instantanément disponibles. Sinon, le système d'exploitation fait un "page in" les données depuis le CAS_CACHE_DISK à l'extrémité de la memory map. De même, si des données en RAM ne sont pas utilisées et que le système d'exploitation détermine qu'il doit libérer cet espace pour d'autres tâches, le système d'exploitation va automatiquement executer un page de ces données sur le disque

Il existe d'autres situations non abordées ici, mais l'idée générale est que le système d'exploitation gère très efficacement l'accès aux données grâce aux tables de mappage en mémoire.

Cette approche fournit efficacement un schéma de mémoire virtuelle qui augmente la quantité de données que le CAS peut prendre en charge et traiter, réduisant ainsi le besoin d'une gestion manuelle de la disponibilité des tables en mémoire.

SASHDAT, le format des données in-memory

CAS analyse les données au format SASHDAT, quel que soit leur format d'origine. Les données chargées dans le CAS peuvent provenir de diverses sources et formats grâce à la technologie SAS Data Connector. Et bien sûr, le CAS peut également réécrire ces données dans de nombreux autres formats.

Cependant, les données en mémoire du CAS sont exclusivement au format SASHDAT, quelle que soit leur source d'origine ou leur destination finale. La structure SASHDAT est optimisée pour le traitement analytique distribué.

Lorsque une caslib pointe vers une source de données au format SASHDAT accessible en local, CAS effectue une cartographie en mémoire directement vers l'emplacement source (et il n'utilise donc pas CAS_DISK_CACHE pour soutenir ces blocs). La création des cartes en mémoire est une opération mineure et rapide. Ainsi, lorsque la directive loadTable est exécutée, CAS charge cette table SASHDAT extrêmement rapidement, beaucoup plus rapidement que ce qui serait physiquement possible. Cela s'explique par le fait qu'il construit simplement ces cartes en mémoire à ce moment-là.

C'est lorsque les données sont consultées par CAS pour des travaux d'analyse que le système d'exploitation réalise que les données ne sont pas encore en RAM, et il met alors les données en page depuis le disque source (ce qui signifie que le premier travail d'analyse doit attendre plus longtemps que les suivants).

Pour les tables SASHDAT vraiment volumineuses, envisagez d'exécuter une tâche préliminaire qui forcera le système d'exploitation à mettre en page les données avant que de véritables utilisateurs finaux ne tentent d'y accéder.

Le CAS_CACHE_DISK et la réplication

CAS_DISK_CACHE est l'endroit où toutes les copies répliquées des données sont stockées En plus de servir de backend de stockage de mémoire virtuelle, CAS_DISK_CACHE assure également la protection des données pour les travailleurs CAS. Des copies supplémentaires de blocs SASHDAT peuvent être stockées dans CAS_DISK_CACHE, de sorte qu'une table SASHDAT complète reste disponible même si un travailleur CAS tombe en panne (emportant avec lui sa portion de blocs de données).

Conclusion

Ces règles visent simplement à décrire une compréhension de base du fonctionnement du CAS en ce qui concerne les données en mémoire. Il existe de nombreuses considérations de configuration et de programmation disponibles pour traiter une large gamme de scénarios différents qui ne suivent pas ces règles. Cependant, je trouve que ces règles fournissent un bon point de départ pour explorer ces variations.

En tant que schéma de mémoire virtuelle, l'idée est que CAS_DISK_CACHE offre une résilience lorsqu'il y a une pression excessive sur la RAM en raison de la quantité de données. Vous l'avez compris, si nécessaire, les tables en mémoire peuvent être mises en page vers le cache CAS via les mappages en mémoire. Après tout, il est préférable que CAS fonctionne lentement lors de l'accès à une table rarement utilisée que de rencontrer des problèmes de mémoire insuffisante. Cependant, il existe certains éléments CAS pour lesquels il n'y a pas de mappage en mémoire - ils doivent rester en mémoire pour que CAS fonctionne. Le point ici est que CAS_DISK_CACHE n'est pas suffisant pour toutes les opérations de mémoire virtuelle, alors faites attention lorsque vous comptez sur lui. Je vous recommande la lecture de l'article When is CAS_DISK_CACHE used?

Il est important de comprendre que CAS_DISK_CACHE est une considération cruciale dans la configuration de la machine hôte. Il doit être pris en compte en termes de taille et de performances avec du matériel réel lors du dimensionnement approprié d'une solution SAS Viya.

Cependant, la mémoire virtuelle ne fournit pas des performances équivalentes à la RAM. Elle est beaucoup, beaucoup plus lente. Pour maintenir des performances réactives, il est plus important de s'assurer que les hôtes CAS disposent d'une quantité suffisante de RAM en premier lieu. Priorisez vos investissements sur la RAM en premier lieu.