Unity Catalog, Lakehouse bien architecturé et optimisation des coûts / Blogs / Perficient

J’ai écrit sur l’importance de migration vers Unity Catalog comme élément essentiel de votre Plateforme de gestion de données. Tout exercice de migration implique le passage d’un état actuel à un état futur. Une migration de Hive Metastore vers Unity Catalog nécessitera une planification autour des espaces de travail, des catalogues et de l’accès des utilisateurs. C’est également l’occasion de réaligner certaines de vos pratiques actuelles qui peuvent être moins qu’optimales avec des pratiques plus récentes et meilleures. En fait, certaines de ces améliorations pourraient être plus faciles à financer qu’un simple jeu de gouvernance. Un modèle complet à utiliser à titre indicatif est le Framework Lakehouse bien architecturé Databricks. J’ai discuté des sept piliers du cadre bien architecturé de Lakehouse en général et je veux maintenant me concentrer sur optimisation des coûts.

Présentation de l’optimisation des coûts

J’avais placé l’optimisation des coûts comme premier pilier à aborder puisque j’ai vu de nombreux projets axés sur la gouvernance, comme les migrations du catalogue Unity, échouer en raison du manque d’impératif de financement clair. Je peux généralement obtenir une assistance à long terme bien plus importante en matière de réduction des coûts, en particulier dans le cloud. Les principes d’optimisation des coûts dans Databricks sont relativement simples : commencer avec une ressource qui s’aligne sur la charge de travail, évoluer de manière dynamique selon les besoins, surveiller et gérer de près. Des principes simples signifient rarement des implémentations simples. Habituellement, je vois des charges de travail qui ont été supprimées et déplacées du point de vue sur site sans être réécrites pour le nouvel environnement, ainsi que de nouveaux travaux qui semblent avoir été écrits sur site. Les ressources de calcul créées il y a un an et demi pour un type de travail sont simplement réutilisées en tant que « meilleure pratique ». Et pas de suivi efficace. Il existe des bonnes pratiques qui peuvent être mises en œuvre assez facilement et qui peuvent avoir un réel impact sur vos résultats.

Comprenez vos options de ressources

Tout d’abord, commencez à utiliser Delta comme cadre de stockage. Deuxièmement, commencez à utiliser des environnements d’exécution à jour pour vos charges de travail. Troisièmement, utilisez le calcul des tâches au lieu du calcul polyvalent pour vos tâches et utilisez l’entrepôt SQL pour vos charges de travail SQL. Vous souhaiterez probablement utiliser des services sans serveur pour vos charges de travail BI et le service de modèles ML et IA. Vous n’avez probablement pas besoin de GPU, sauf si vous faites du deep learning. Photon cela aidera probablement vos requêtes plus complexes et il vous suffit de l’activer pour le savoir. L’utilisation des types d’instances les plus récents vous apportera généralement un gain de prix/performances (ex : instances AWS Graviton2). Des optimisations supplémentaires par exemple nécessitent un peu plus de réflexion, mais honnêtement, pas beaucoup plus. Par défaut, utilisez simplement le dernier type d’instance à usage général. Utilisez des charges de travail optimisées en mémoire pour le ML. Certains travaux de ML et d’IA, mais pas tous, peuvent bénéficier du GPU, mais soyez prudent. Utilisez des charges de travail optimisées pour le stockage pour une analyse de données ponctuelle et interactive. Utilisez le calcul optimisé pour les tâches structurées de streaming et de maintenance.

L’avenir du Big Data

Avec quelques conseils, vous pouvez créer une plateforme de données adaptée aux besoins de votre organisation et tirer le meilleur parti de votre capital de données.

Obtenez le guide

Le vrai travail consiste à choisir la taille de calcul la plus efficace. La première chose que je recommande habituellement est de retirer autant de travail que possible du nœud pilote et de transférer le travail vers les nœuds travailleurs. Comme J’ai déjà mentionnéles exécuteurs effectuent des transformations (carte, filtre, groupBy, sortBy, sample, randomSplit, union, distinct, coalesce, repartition) tandis que le pilote effectue des actions (réduire, collecter, compter, min, max, somme, moyenne, stddev, variance, saveAs ). Une fois que vous vous êtes assuré que les travailleurs font le bon travail, vous devez savoir sur quoi ils travaillent. Cela impliquait de comprendre la quantité de données que vous consommez, comment elles sont parallélisées et partitionnées, quelle est leur complexité. Mon meilleur conseil ici est de mesurer vos emplois et d’identifier ceux qui doivent être réévalués. Limitez ensuite votre dette technique (et réelle) à l’avenir en appliquant les meilleures pratiques.

Assurez-vous d’allouer dynamiquement les ressources autant que possible. Déterminez si les ressources fixes peuvent ou non utiliser l’instance ponctuelle. Terminaison automatique. Examinez les pools de clusters, car Databricks ne change pas lorsque les instances sont inactives dans le pool.

Surveillance et rétrofacturation

Le console de compte est ton ami. Taguez toutes les personnes qui possèdent leur propre chéquier. Pensez au contrôle des coûts lorsque vous configurez des espaces de travail et des clusters et étiquetez en conséquence. Vous pouvez baliser le cluster, l’entrepôt SQL et les pools. Certaines organisations ne mettent pas en œuvre de modèle de rétrofacturation. C’est très bien; commencer aujourd’hui. Sérieusement, personne n’évolue sans responsabilité. Des efforts sont nécessaires pour concevoir des charges de travail rentables. Vous constaterez des charges de travail considérablement optimisées une fois que les gens commenceront à recevoir une facture. Vous serez surpris du nombre de flux de travail « en temps réel » qui peuvent utiliser le déclencheur AvailableNow une fois qu’un montant en dollars entre en jeu. Une stratégie d’optimisation des coûts n’est pas la même chose qu’un décret général de réduction des coûts. Ne me croyez pas sur parole : si vous n’adoptez pas la première, vous ferez l’expérience de la seconde.

Conclusion

L’optimisation des coûts est généralement le meilleur pilier sur lequel se concentrer, car elle peut avoir un impact immédiat sur le budget et comporte souvent une pente politique abrupte à gravir en raison de l’importance d’un modèle de rétrofacturation. La réévaluation des modèles d’espace de travail est une partie importante de la préparation à la migration d’Unity Catalog et l’optimisation des coûts grâce au balisage peut être une partie importante de cette conversation.