Utiliser Snowflake et Databricks ensemble / Blogs / Perficient

Il ne s’agit pas d’une autre comparaison entre Briques de données et Flocon de neige; ils sont pas dur trouver. Il s’agit d’un guide pratique sur l’utilisation conjointe de Databricks et de Snowflake dans votre organisation. De nombreuses entreprises ont mis en œuvre les deux produits. Parfois, il existe une divergence entre les deux en ce qui concerne les données stockées, créant ainsi de nouveaux silos de données. Les utilisateurs de Databricks souhaitent accéder aux données qui se trouvent uniquement dans Snowflake et vice versa. Parfois, les problèmes concernent l’optimisation ; L’exécution du processus dans Snowflake par opposition à Databricks serait-elle moins chère ou plus rapide et vice versa. Parfois, c’est les deux. Quoi qu’il en soit, de nombreuses organisations disposent à la fois de Snowflake et de Databricks et il vaut la peine de voir comment ils peuvent être utilisés ensemble.

Regardez sous le capot

Il existe différentes approches tactiques pour utiliser Snowflake et Databricks ensemble. Bien que les deux directions soient possibles, les détails de base de la mise en œuvre sont très différents. Nous discuterons également de l’accès géré par rapport aux données externes. Snowflake et Databricks exploitent tous deux les fournisseurs de cloud pour le stockage. Les deux produits ont un concept de tables gérées (internes) ou non gérées (externes). Une ressource gérée est un fichier stocké dans le cloud dont le cycle de vie est géré par Snowflake ou Databricks tandis que le cycle de vie d’un fichier externe n’est entièrement contrôlé par aucun des deux produits. En d’autres termes, si vous SUPPRIMER une table gérée ; les métadonnées et les données sous-jacentes sont supprimées. Si vous SUPPRIMER une table non gérée, seules les métadonnées sont affectées. Les tableaux externes sont généralement considérés comme étant en lecture seule, mais des exceptions intéressantes sont apparues.

Accéder aux données Snowflake à partir de Databricks

Databricks 11.3+ a un Flocon de neige connectér. Vous spécifiez Snowflake comme format lorsque vous lisez ou écrivez à partir de Snowflake : spark.read/write.format("snowflake"). Les Databricks et les Flocon de neige la documentation souligne l’importance de stocker les informations d’identification Snowflake dans Secrets des Databricks. La page de documentation comporte un exemple simple de cahier que je vous recommande d’essayer d’abord juste pour tester la connectivité. C’est aussi une bonne idée à examiner Fédération Lakehouse pour interroger les données Snowflake (entre autres) sans avoir à déplacer les données dans Databricks. Snowflake dispose d’une fonctionnalité de partage sécurisé et commence à ouvrir cet accès à d’autres fournisseurs (comme Salesforce) mais pas Databricks pour le moment.

Une autre façon de lire les tables Snowflake dans Databricks est de lire tables externes. Les tables externes dans Snowflake sont traditionnellement des ressources en lecture seule. C’est une autre histoire avec Apache Iceberg tables qui utilisent le Parquet Apache format de fichier. Vous pouvez configurer un volume externe pour tables Iceberg puis fournissez l’accès dans Snowflake à l’utilisateur Databricks externe en lui donnant un accès en lecture seule à un nouveau rôle IAM. Ensuite, créez un nouveau cluster dans Databricks et fournissez à Spark Config les informations de connexion nécessaires dont le catalogue Snowflake a besoin, ainsi que les variables d’environnement qui incluent les clés nécessaires pour accéder à la couche de stockage du fournisseur de cloud et ajoutez les environnements d’exécution Iceberg Spark et le pilote Snowflake JDBC à la bibliothèque de pilotes. Il n’est pas nécessaire d’avoir un entrepôt sur Snowflake pour Databricks ; tout le calcul aura lieu dans le cluster Datbricks Spark.

Accéder aux données Databricks depuis Snowflake

Snowflake ne se connecte pas directement à Databricks ; il utilise un scène externe pour accéder aux tables Databricks externes ou non gérées. Snowflake et Databricks sont tous deux natifs du cloud et utilisent tous deux les options de stockage pour AWS, Azure et GCP. Lorsque vous créer une table externe dans Databricksvous combinez un chemin de stockage avec un identifiant de stockage. Databricks gère à la fois les métadonnées et les données d’une table gérée alors qu’il gère uniquement les métadonnées des tables externes. Si vous envisagez cette approche, c’est une bonne idée de comprendre comment Snowflake peut s’intégrer pleinement à Delta Lake.

Conclusion

Databricks peut lire/écrire sur les tables gérées par Snowflake, interroger les tables gérées et externes de Snowflake à l’aide de Lakehouse Federation ou lire des tables externes et même lire/écrire des tables Iceberg externes. Snowflake ne peut nativement lire les données Databricks que dans le sens où Databricks et Snowflake peuvent lire les données du stockage cloud. Snowflake peut également lire les données dans Databricks mis à disposition via Delta Share.

Considérations d’entreprise

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

J’ai brièvement évoqué la façon dont chaque produit peut communiquer avec l’autre simplement pour montrer les garde-fous autour de ce qui est possible. Nous disposons de beaucoup plus d’outils de Databricks pour le partage de données uniquement du point de vue de la cuisson. Cependant, nous devons examiner plus qu’une simple matrice de fonctionnalités pour voir comment les données peuvent être utilisées de manière plus efficace et efficiente. Pour cela, nous devons évaluer ces options du point de vue de la sécurité, de la gouvernance et des coûts.

Sécurité

Au début de cet article, j’ai recommandé d’essayer l’exemple de bloc-notes Databricks pour voir si vous pouviez accéder à Snowflake. J’ai fait ça pour une raison ; Je parie que c’était dur. Ce n’est pas techniquement difficile, mais il y a beaucoup de choses à déballer ici. Le modèle RBAC de Snowflake permet un contrôle d’accès plus précis au sein de la base de données, tandis que Databricks se concentre sur la sécurité de l’espace de travail et du cluster. Snowflake gère le cryptage des données et l’accès sécurisé aux données tandis que Databricks exploite le fournisseur de cloud. J’ai souligné que Databricks utilise une approche de gestion des secrets tandis que Snowflake utilise la gestion des clés de chiffrement pour les données au repos. Databricks utilise des UDF et des vues dynamiques pour prendre en charge les filtres de lignes et le masquage au niveau des colonnes, qui ne seraient pas disponibles pour une instance Snowflake accédant à la table externe. L’édition Enterprise de Snowflake fournit sécurité au niveau des lignes via des politiques d’accès qui, je pense, devraient fonctionner avec le connecteur Databricks. Sécurité au niveau des colonnes dans Snowflake, ce qui pourrait impliquer masquage dynamique des données ou tokenisation externenécessiterait également des tests approfondis.

Gouvernance

Databricks s’appuie sur Unity Catalog pour fournir une solution unifiée pour toutes les données et ressources d’IA, y compris le traçage des données et les contrôles d’accès. Delta Lake fournit des transactions ACID et une gestion des versions des données. Snowflake permet un voyage dans le temps pour l’audit et la récupération des données, le marquage des objets et la classification des données pour la conformité et la confidentialité, le masquage des données et la sécurité au niveau des lignes, ainsi que l’accès aux données granulaires à différents niveaux de stockage de données. Fondamentalement, la gouvernance dans Databricks se concentre sur la gouvernance du traitement et de l’analyse des données, tandis que Snowflake se concentre sur le stockage et l’accès aux données. Les deux adoptent des approches valables et solides en matière de gouvernance, mais leurs approches ne sont pas les mêmes. Cela ne veut pas dire que là volonté il y a des divergences ; c’est juste que c’est plus probable là-bas pourrait être.

Coût

Il existe également de nombreux articles moins chers. Ce n’est pas un de ces articles. Objectivement, ils ont tous deux des structures de coûts différentes. Snowflake a séparé ses coûts de calcul et de stockage. Le stockage est calculé par To et par mois et inclut les données actives et historiques (données de voyage dans le temps et de sécurité). Le calcul est basé sur Crédits flocon de neige, qui est un modèle de consommation temporel calculé en fonction du type et de la taille des entrepôts de calcul utilisés. Utilisations des Databricks Unités Databricks (DBU) pour représenter une unité de capacité de traitement par heure et des frais basés sur le type et le nombre de nœuds dans un cluster. Vous payez pour exécuter des clusters. Essayer de comparer la valeur monétaire relative d’une unité Snowflake Credit ou Databricks n’est pas très utile. Vous pouvez faire quelques hypothèses de base.

Les workflows de traitement lourds impliquant des transformations de données complexes peuvent parfois être plus rentables dans Databricks que dans Snowflake, car ces opérations peuvent consommer plus de ressources de calcul. Cependant, si vous avez beaucoup de transformations qui devront être exécutées sur une base Nœud exécuteur Spark, Snowflake pourrait avoir un avantage. Les autres charges de travail qui nécessitent beaucoup de temps de calcul, comme les analyses en temps réel et les charges de travail à haute concurrence, sont généralement moins chères sur Databricks. Les opérations simples d’entrepôt de données ainsi que les tâches de traitement de données petites ou peu fréquentes seront probablement moins chères sur Snowflake. Malgré de forts efforts marketing des deux côtés, Snowflake est généralement moins cher pour effectuer des travaux d’entrepôt de données et Databricks est généralement moins cher pour l’analyse et le traitement des données.

Exemples d’options

Nous avons brièvement abordé certains détails de mise en œuvre et considérations pratiques d’entreprise concernant l’utilisation conjointe de Snowflake et Databricks. Il est généralement utile de considérer Databricks comme une plate-forme d’analyse de données unifiée et Snowflake comme un entrepôt de données. Plus simplement, Databricks est bon pour la transformation des données et utilisé par le genre de personnes qui aiment Python et Jupyter Notebooks. Snowflake est préféré par ceux qui aiment les outils de reporting comme Talend et SQL. Les deux sociétés ont des services marketing qui seraient offensés par cette caractérisation, mais c’est parti. Cela nous donne une bonne base pour commencer à visualiser une stratégie de données dans laquelle nous brisons les silos qui se forment autour des produits que nous avons achetés afin de briser les silos de données.

Couche de stockage cloud

Nous avons vu que les deux peuvent lire des fichiers à partir d’un stockage de données cloud. Chacun d’eux préférerait que vous gériez ces fichiers au sein de leur système, mais ces deux productions ont des modèles de tarification basés sur la consommation. Il n’est pas déraisonnable, par exemple, de stocker les données brutes dans un stockage cloud, comme S3. AWS pourrait gérer le cycle de vie, la gestion des versions, l’archivage et la suppression délibérée de ces fichiers. S’ils ne sont gérés par aucun système capable d’exécuter une DROP TABLE, vous pouvez essentiellement avoir une couche Bronze immuable (à emprunter à la architecture médaillon). Techniquement, les données sont partagées entre Databricks et Snowflake, mais pas entre. Cette approche nous donne des outils de gouvernance et de sécurité rudimentaires, mais ils ont l’avantage d’être fondamentaux et partagés.

Couche de bronze

C’est peut-être à cause de leurs racines open source, mais Databricks a l’avantage en matière de partage et d’intégration. Si la source des données ne peut pas être entièrement sur le stockage cloud, il est logique que Databricks soit la source des données. La raison en est que Databricks est plus efficace pour la plupart des tâches ETL. Même s’il existe des exceptions, ce ne sont que des exceptions. Je pense que les tables externes ont du sens pour Databricks au niveau Bronze, je ne pense pas que ce soit un argument aussi fort lorsque nous arrivons à Silver et Gold.

Couche d’or

La couche Gold est généralement constituée d’ensembles de données agrégés qui sont principalement utilisés à des fins de reporting. Databricks a un Entrepôt SQL, mais Snowflake reste clairement le gagnant pour les cas d’utilisation de l’entreposage de données basé sur SQL. Utiliser Delta Share pour rendre ces données disponibles dans Snowflake est généralement une stratégie assez sûre. L’agrégation anonymise généralement les informations sensibles, de sorte qu’il n’est pas nécessaire d’avoir le type de contrôle de données précis dont dispose Snowflake et que Databricks ne peut pas fournir via Delta Share. En fait, Snowflake est tellement meilleur dans ce domaine que vous trouverez peut-être une pratique courante pour les databricks de lire ces tables de couches d’or de Snowflake. Ce qui nous amène à la couche Argent.

Couche d’argent

La couche Silver est généralement utilisée pour l’analyse, l’apprentissage automatique et l’IA. Databricks a été le premier à adopter ce domaine, mais GenAI a incité tout le monde à reprendre son jeu dans cet espace et Snowflake ne fait pas exception. C’est là que chaque entreprise sera différente. Considérez que vous aurez besoin d’un modèle unifié de sécurité, de gouvernance et de conformité à cette couche pour les données partagées. Imprégnez-vous-en pourrait aider ici. Une autre approche peut consister à stocker certaines tables de la couche Silver en tant que tables externes afin que Snowflake puisse les utiliser. Il s’avère que si Snowflake dispose d’une table dans cette couche à laquelle les utilisateurs de Databricks souhaitent accéder, ce serait très simple.

Conclusion

Nous avons vu qu’utiliser Snowflake et Databricks ensemble est tout à fait possible, à la fois plus facile et plus compliqué que vous ne le pensiez, et pourrait être une très bonne idée. Snowflake et Databricks ont des forces et des faiblesses différentes selon qui utilise les données et comment. Même s’il est possible de partager les données à chaque étape de leur cycle de vie, il existe des problèmes pratiques liés à la sécurité, à la gouvernance et aux coûts qui nécessitent une analyse minutieuse. Entrer en contact Contactez-nous si vous souhaitez en savoir plus sur la manière dont l’utilisation conjointe de Snowflake et Databricks peut s’intégrer dans vos initiatives stratégiques en matière de données.