Architecture, moteurs d’exécution, coûts et modélisation : les questions sur Snowflake, Databricks et le choix entre les deux.
Cliquez sur une question pour dérouler la réponse attendue.
Services cloud, calcul par virtual warehouses et stockage colonnaire partagé : une seule copie des données, plusieurs entrepôts isolés, facturés séparément.
Lire la réponse détailléeUn virtual warehouse est le cluster de calcul Snowflake : il exécute les requêtes, pas le stockage. Vous le choisissez par taille de t-shirt (XS, S, M… jusqu’aux XL). Doubler la taille double à peu près les crédits à la seconde, et vise à doubler le parallélisme — pas à « rendre le SQL plus intelligent ».
En entretien, on attend un raisonnement, pas un chiffre magique.
Scale-up (passer de M à L) : la même requête, plus de cœurs, utile quand une requête scanne trop ou spill sur disque distant. Scale-out (mode multi-cluster) : plusieurs clusters de même taille, utile quand beaucoup de requêtes s’empilent — la BI du lundi matin, pas un gros chargement unique.
La méthode concrète : partir petit, lire le query profile (octets scannés, spilling, files d’attente), puis décider si le problème est le volume d’une requête ou la concurrence. Séparer les charges — un warehouse ETL, un warehouse dashboards — évite qu’un MERGE de nuit étouffe Tableau.
Le piège : un XL allumé huit heures « au cas où » coûte plus cher qu’un M bien suspendu. Dimensionner, c’est aussi éteindre.
Snowflake facture le warehouse tant qu’il est démarré, y compris à vide. Auto-suspend l’arrête après une période d’inactivité (souvent 60 secondes à quelques minutes). Auto-resume le rallume à la prochaine requête. C’est le levier le plus simple sur la facture : un M oublié allumé un week-end vaut des centaines de crédits pour zéro travail.
L’intervieweur vérifie que vous voyez les deux faces.
Trop agressif (suspendre après 30 secondes) : chaque trou entre deux clics de dashboard relance le warehouse. La première requête après reprise est plus lente — cache SSD local perdu — et l’utilisateur sent un « froid ». Trop laxiste (dix minutes) : vous payez l’attente entre deux jobs.
La réponse solide cite aussi le plancher de facturation : un warehouse qui s’allume est facturé au moins une minute, puis à la seconde. Enchaîner des micro-réveils peut donc coûter plus qu’un warehouse qui reste tiède pendant un créneau de BI.
Ce que vous réglez vraiment : un délai aligné sur le rythme de la charge, pas une valeur par défaut jamais revue.
Unités de stockage colonnaires d’environ 50 à 500 Mo non compressés, avec métadonnées min-max. Snowflake élague celles qui ne peuvent pas contenir les lignes filtrées, sans que vous posiez de partitions à la main.
Lire la réponse détailléeUne clustering key dit à Snowflake dans quel ordre réécrire les micro-partitions au fil du temps, pour que les filtres fréquents retrouvent des min/max serrés. Ce n’est pas un index B-tree. Le service Automatic Clustering consomme des crédits tant que la table dérive.
Vous en posez une quand trois conditions sont vraies : la table est grande (souvent centaines de Go ou plus), les requêtes filtrent toujours les mêmes colonnes à haute sélectivité (date d’événement, id compte), et le profil montre un pruning faible — beaucoup de partitions scannées pour peu de lignes. Sur une table de 20 Go déjà chargée par date, le clustering automatique est du gaspillage.
L’ordre des colonnes compte : d’abord la plus filtrée et à cardinalité raisonnable (une date), ensuite un identifiant si les filtres le combinent. Une clé trop large (UUID en premier) ne range rien d’utile.
Vous vous en passez si l’ingestion arrive déjà naturellement ordonnée, ou si Search Optimization convient mieux à du point lookup sur une clé rare. En entretien, le signal est : mesurer le clustering depth, puis décider — pas poser une clé sur chaque table « pour plus tard ».
Le crédit mesure surtout le calcul allumé : warehouses, plus des services serverless. Le stockage et la sortie réseau sont une autre ligne. Le piège, ce sont les crédits invisibles — clustering, services cloud, entrepôts oubliés.
Lire la réponse détailléeTime Travel est la fenêtre utilisable par vous : relire une table AT un instant ou une requête, UNDROP une table, cloner l’état d’hier. La rétention va de 0-1 jour (édition standard, défaut 1) jusqu’à 90 jours en édition supérieure, réglable par table. Vous payez le stockage des versions conservées.
Fail-safe commence après la fin du Time Travel : 7 jours supplémentaires, uniquement via le support Snowflake, pour un sinistre (suppression accidentelle découverte trop tard, corruption opérationnelle). Vous ne pouvez pas faire un SELECT Fail-safe vous-même. Ce n’est pas un outil de debug.
L’intervieweur veut la conséquence coût : une table qui change beaucoup, avec 90 jours de Time Travel, double ou triple le stockage apparent. Baisser DATA_RETENTION_TIME_IN_DAYS sur les tables de staging n’est pas de l’avarice, c’est de l’hygiène. Transient et temporary tables n’ont pas de Fail-safe — d’où leur intérêt pour l’éphémère.
La confusion fréquente : Time Travel n’est pas une sauvegarde hors compte. Si quelqu’un drop le compte ou si vous avez besoin d’une copie dans un autre cloud, c’est de la réplication ou un export, pas AT TIMESTAMP.
CREATE … CLONE fabrique une base, un schéma ou une table qui pointe vers les mêmes micro-partitions que la source. Aucun octet n’est recopié au moment du clone. Snowflake facture du stockage supplémentaire seulement quand l’un des deux côtés écrit : copie sur écriture. D’où « zero-copy ».
En entretien, on l’attend pour trois usages : un environnement de recette à partir de la prod en quelques secondes, un point de restauration avant un MERGE risqué, un jeu de données figé pour un audit. Combiné à Time Travel, vous clonez l’état de 2 h du matin sans avoir prévu un dump.
Ce que le clone ne copie pas comme on l’imagine : ce n’est pas un export portable hors Snowflake ; les privilèges se rejouent selon que vous clonez objet ou base ; les stages externes et certaines intégrations ne suivent pas « magiquement ». Et un clone n’est pas gratuit pour toujours : une recette qui réécrit toute la table paie bientôt autant que la prod.
La phrase qui tranche : le clone est un alias de métadonnées, pas une sauvegarde hors site.
Snowflake n’accorde presque rien à un utilisateur directement : les privilèges vont à des rôles, les utilisateurs se voient attribuer des rôles, et les rôles forment une hiérarchie. GRANT SELECT ON TABLE … TO ROLE analyste puis GRANT ROLE analyste TO USER …. Le rôle actif de la session détermine ce que vous pouvez faire ; USE ROLE n’est pas un détail de confort.
Les rôles système à citer sans les confondre : ACCOUNTADMIN (clés de la maison — on ne travaille pas avec au quotidien), SECURITYADMIN (utilisateurs, rôles, grants de rôles), USERADMIN (création d’identités), SYSADMIN (objets : bases, warehouses). Le modèle sain : des rôles métier (finance_lecteur, etl_ecriture) sous SYSADMIN, jamais une équipe entière en ACCOUNTADMIN.
L’intervieweur cherche deux réflexes. Future grants (ON FUTURE TABLES IN SCHEMA) pour que les nouvelles tables héritent des droits, sinon chaque pipeline casse le lundi. Et le principe du moindre privilège sur les warehouses : pouvoir USAGE un XS de lecture n’implique pas de pouvoir démarrer le L d’ETL.
La relance senior : masquer des colonnes (Dynamic Data Masking, row access policies) en plus du RBAC objet — le rôle dit quelle table, la politique dit quelles lignes.
Le result cache renvoie un résultat déjà calculé, sans warehouse. Le cache du warehouse garde des micro-partitions sur SSD local : la requête se recalcule, mais scanne moins loin.
Lire la réponse détailléeUn stream est un curseur de changements sur une table (inserts, updates, deletes — CDC métier, pas un bus Kafka). Il expose les lignes non consommées depuis la dernière lecture transactionnelle. Une task est un job SQL (ou procédure) déclenché sur cron ou après une autre task. Ensemble, ils font de l’ELT incrémental natif : la task lit le stream, MERGE vers une table cible, et le décalage du stream avance dans la même transaction. Si le MERGE échoue, on ne « perd » pas l’offset.
L’intervieweur vérifie que vous connaissez les limites. Ce n’est pas du streaming à la seconde : la granularité est celle de la task (souvent minutes). Un stream stale si on ne le consomme pas assez tôt par rapport au Time Travel de la source. Les streams sur vues complexes ou sur tables qui changent de clustering massivement demandent de relire le contrat. Pour un vrai flux événementiel à faible latence, on parle Snowpipe + tâches, ou une plateforme de streaming — pas d’une task toutes les heures déguisée.
La phrase attendue : streams + tasks remplacent une file d’Airflow qui fait SELECT * depuis hier, pas un cluster Spark Structured Streaming.
Snowpark est une API DataFrame (Python, Scala, Java) dont le plan part dans Snowflake, sur un warehouse — pas sur votre laptop. Tant que vous enchaînez filtres, jointures et agrégations, c’est du SQL avec une autre syntaxe. L’intérêt commence quand le SQL devient un mensonge : branches impératives, UDF/UDTF Python, procédures stockées qui orchestrent plusieurs étapes, features ML, parsing de documents, logique que vous ne voulez pas maintenir en dix CTE.
L’intervieweur veut le critère, pas le marketing. Vous passez à Snowpark quand l’unité de travail n’est plus une requête mais un programme qui doit rester près des données (évite l’extract de 40 Go vers un notebook). Vous restez en SQL/dbt quand l’équipe est analyste, que les tests sont des contrats de colonnes, et que le plan doit rester lisible dans l’UI.
Le piège : une UDF Python ligne à ligne tue le moteur vectorisé autant qu’ailleurs. Snowpark n’est pas « Spark dans Snowflake ». Pas de cluster générique, pas le même écosystème MLlib/streaming. Si le besoin est un entraînement distribué sur des fichiers bruts, vous n’avez pas « gagné » en traduisant le notebook en Snowpark : vous avez déplacé la question de plateforme.
Le Secure Data Sharing donne à un compte consommateur un accès live à des objets d’un compte fournisseur : mêmes micro-partitions, pas d’export, pas de pipeline de copie. Le fournisseur crée un share, y ajoute bases ou tables, et autorise un compte (ou une listing Marketplace). Le consommateur monte le share comme une base en lecture. Quand le fournisseur INSERT, le consommateur voit les nouvelles lignes selon les droits — sans facturer un second stockage côté copie.
Contrainte à citer : le share direct suppose le même région du même cloud. Autre région ou autre cloud : replication / listings qui traversent, et là le coût de transfert revient. Un reader account sert un partenaire qui n’a pas Snowflake.
L’intervieweur distingue ça d’un COPY INTO S3 ou d’un dump : le sharing n’est pas une sauvegarde, c’est un droit de lecture sur la source. La gouvernance reste chez le fournisseur (révoquer le share coupe l’accès). C’est pour cela que des éditeurs vendent des données « en place » plutôt que d’envoyer des CSV.
Le lakehouse, en une phrase : les garanties d’un entrepôt (ACID, schéma, SQL, gouvernance) sur le stockage bon marché et ouvert d’un lac (objets cloud, fichiers Parquet/Delta), sans imposer une copie propriétaire pour chaque usage.
Vous dépliez ensuite en trois mots que l’intervieweur reconnaît. Lac : les données restent des fichiers que d’autres moteurs peuvent, en principe, lire. Maison : Delta Lake ajoute journal, MERGE, time travel, qualité. Catalogue : Unity Catalog pose un namespace et des droits au-dessus des chemins S3. Sans le troisième, vous avez un lac avec des notebooks ; sans le second, vous avez des Parquet qui se corrompent au premier job interrompu.
Ce n’est pas « Databricks = le lakehouse » comme tautologie, ni « c’est juste Spark sur S3 ». La phrase qui évite le slogan : on unifie analytics SQL, ingénierie et data science sur les mêmes tables, au lieu d’un entrepôt d’un côté et d’un data lake poubelle de l’autre.
La relance fréquente : « Et un entrepôt classique, alors ? » Vous répondez que l’entrepôt copie souvent les données dans un format propriétaire pour gagner le SQL ; le lakehouse inverse la contrainte : le fichier reste le socle, le SQL et les jobs viennent s’y brancher. Si tout tient déjà dans des marts Snowflake et que personne ne touche au lac, ce n’est pas la phrase à forcer.
Un cluster all-purpose est une session Spark interactive : notebooks, exploration, bibliothèques custom, GPU parfois. Il reste souvent allumé tant que quelqu’un l’utilise, et se facture au DBU interactive — le tarif le moins généreux. Un job cluster naît pour une tâche schedulée et meurt après : même famille Spark, bien moins cher, pas pour le clavier.
Un SQL warehouse (classique ou serverless) est le chemin BI / SQL : endpoints, Photon, concurrence pensée pour des dashboards, pas pour installer pip au milieu d’un notebook. C’est lui qu’on branche sur Power BI ou Tableau.
L’erreur de prod : faire tourner les extraits Looker sur un all-purpose partagé « parce que l’équipe l’avait déjà ». Vous payez l’interactif, vous mélangez un fit() sklearn et un REFRESH, et personne ne sait qui gonfle le cluster. La règle d’entretien : all-purpose pour penser, jobs pour les pipelines, SQL warehouse pour les requêtes de consommation. Si le besoin est uniquement du SQL de dashboard, allumer un cluster Spark interactif est un anti-patron de coût.
Photon est le moteur C++ vectorisé de Databricks : mêmes DataFrames, mêmes SQL, exécution plus proche d’un entrepôt colonnaire que d’une JVM qui boxe des objets. Le bénéfice attendu, c’est du scan / join / agg plus rapide et souvent moins de CPU pour la même requête SQL « simple ». Ce n’est pas un nouveau langage.
L’intervieweur, ici, ne veut pas le débat de plateforme. Il veut le piège opérationnel : Photon ne couvre pas tout. Une UDF Python, certains types imbriqués, des opérateurs de streaming, un reste d’API RDD — et l’étage retombe sur Spark JVM sans lever d’erreur. Vous pouvez avoir coché Photon, payer le supplément, et n’avoir 15 % du temps en nœuds Photon.
Comment vous le voyez : le plan (explain) préfixe les nœuds Photon… ; le query profile SQL affiche la part du temps Photon. En dessous d’un seuil que vous aurez fixé (par exemple la moitié du temps CPU), vous chassez l’UDF ou l’expression non native avant d’ajouter des workers.
La phrase qui clôt : un repli silencieux est un bug de coût, pas une alerte rouge. Si vous ne savez pas le mesurer, vous ne savez pas si Photon vous sert.
Un catalogue unique pour plusieurs workspaces : namespace à trois niveaux, droits, audit, lineage et volumes fichiers. Sans lui, chaque workspace réinvente des chemins S3 et des grants locaux.
Lire la réponse détailléeLes médailles sont une convention de couches, pas un produit Databricks. Bronze : la donnée telle qu’arrivée (fichiers, topic, API), schéma encore mou, historisée, rejouable. Silver : nettoyée, dédoublonnée, types corrigés, clés métier alignées — la table dont un ingénieur se sert pour joindre. Gold : produits consommables (faits, marts, agrégats, parfois One Big Table métier) pensés pour un dashboard ou un modèle.
L’intervieweur vérifie que vous savez pourquoi on ne saute pas une couche. Écrire le gold directement depuis le JSON brut mélange reprise sur incident, qualité et logique BI dans le même job : le jour où le producteur change un champ, tout explose. Bronze permet de rejouer ; silver porte les règles ; gold porte les contrats.
Ce n’est pas une religion à trois dossiers. Une petite équipe peut avoir bronze + gold si silver n’a pas de consommateurs. Inversement, multiplier les « platines » sans propriétaire, c’est du lac poubelle avec des noms chers. La question utile : qui est responsable de la qualité à chaque étage, et qui a le droit d’y lire.
Un notebook dit comment : lire, joindre, écrire, gérer les checkpoints à la main, relancer. Delta Live Tables — aujourd’hui souvent présentés comme pipelines déclaratifs / Lakeflow — dit quoi : cette table se calcule à partir de celles-là, avec telles expectations (expect, drop, fail). Le runtime orchestre l’ordre, le batch ou le streaming, les retries, les tables de monitoring de qualité.
L’intérêt en entretien : moins de colle Airflow pour un graphe de dépendances déjà dans les données, et une qualité visible (combien de lignes ont violé la règle) plutôt qu’un assert oublié. Le streaming et le batch partagent le même graphe : on ne maintient pas deux codes pour « la nuit » et « en continu ».
Le coût à nommer : vous cédez du contrôle (tuning fin, libs exotiques, certains patterns de streaming). Le debugging est un autre UI. Migrer un monolithe notebook de 2 000 lignes n’est pas un rename. La réponse mature : déclaratif pour les tables médaille stables avec contrats ; notebooks / jobs Spark pour l’exploration et les cas hors cadre.
Le schéma en étoile reste le contrat BI : faits minces, dimensions partagées. La One Big Table évite les jointures pour un usage unique, au prix des mises à jour et du stockage. Sur un moteur colonnaire, on choisit selon les consommateurs, pas selon la mode.
Lire la réponse détailléeUne SCD (surtout type 2 : une ligne par version, dates de validité, flag courant) vit dans une dimension silver/gold, pas dans le bronze et pas dans le fait. Le bronze garde l’événement brut (« l’API a dit ceci à 10:12 »). Le fait pointe une clé de substitution de version, ou — plus simple à servir — une clé métier plus un as_of résolu à la lecture. Mélanger l’historique d’adresse dans chaque ligne de ticket de caisse sans dim, c’est une OBT qui se prend pour une SCD.
Sur Snowflake, le motif est un MERGE sur la dim, souvent derrière un stream, avec clustering sur la clé métier si la table est énorme. Sur Databricks, même MERGE Delta, parfois une table CDF pour les avaleurs. Dans les deux cas : une vue dim_client_courant pour la BI qui ne veut pas d’historique, et la table versionnée pour le réglementaire.
L’intervieweur attend que vous refusiez la SCD type 2 en bronze « pour ne rien perdre » : vous perdez le grain et vous obligez chaque consommateur à réimplémenter la validité. Type 1 (écrasement) suffit quand personne n’a besoin d’hier. Type 3 (colonne précédente) est un compromis étroit. Le choix se justifie par une question métier (« doit-on recréditer selon l’adresse au jour J ? »), pas par un template.
On cherche les nœuds qui dominent le temps et les octets, pas le SQL joli. Pruning, spilling, files d’attente et part du moteur rapide disent si on doit réécrire, reclustering, ou seulement éteindre un entrepôt trop gros.
Lire la réponse détailléeLa saturation n’est pas « plus de SQL ». C’est un goulot précis.
Sur Snowflake, un warehouse a un nombre de slots / un degré de parallélisme lié à sa taille. Trop de requêtes simultanées : elles attendent (queued). Le query profile le montre ; le scale-up accélère chaque requête mais n’ouvre pas assez de files si le problème est le lundi matin de 40 dashboards. Le levier alors est le multi-cluster (même t-shirt, N clusters) ou la séparation des warehouses (ETL vs BI). Autre saturation : une seule requête énorme qui monopolise (spill, scan), et tout le monde attend derrière — là, isoler le job, pas agrandir pour tout le monde.
Sur Databricks, un SQL warehouse sature sur les slots et le scaling (min/max clusters serverless ou classic). Un cluster all-purpose sature autrement : mémoire d’exécuteurs, shuffle, fair scheduling entre notebooks, disque local. Deux data scientists qui cachent des DataFrames et un job de 2 To sur le même cluster, ce n’est pas de la concurrence SQL, c’est de la contention de JVM.
L’intervieweur veut que vous mesuriez queues vs CPU vs mémoire avant d’acheter plus grand. Et que vous citiez le thundering herd : un cache de résultats qui tombe, ou un REFRESH de 30 extraits à :00, sature un entrepôt sain le reste de l’heure.
Iceberg rend le format de table portable ; il n’égalise pas les moteurs, ni la gouvernance, ni la facture de sortie. Le choix se déplace vers le catalogue de référence et les charges, plus vers « qui possède le format ».
Lire la réponse détailléeUn senior relie identités, privilèges, classification et parcours des colonnes à un risque réel — fuite, mauvais chiffre, audit. L’outil (Unity Catalog, Horizon, tags) est un moyen, pas la réponse.
Lire la réponse détailléeLe calcul se paie à l’heure d’entrepôt ou de DBU. Le voyage se paie au gigaoctet qui sort d’une région, d’un cloud, parfois d’un compte : egress AWS/Azure/GCP, réplication Snowflake trans-région, UNLOAD vers un seau ailleurs, lecture d’un lac européen par un workspace américain, connecteur qui copie Snowflake vers Delta « pour le ML ». Une fois les fichiers doublés, vous payez aussi le stockage et le job qui doit rester synchronisé.
L’intervieweur veut un réflexe d’architecte : amener le calcul aux données, pas l’inverse. Même cloud, même région, même seau si possible. Le sharing Snowflake évite une copie quand le consommateur est déjà sur Snowflake dans la région. Iceberg « en place » évite un dump — mais pas un egress si le moteur est loin du seau.
Le piège : un POC Databricks qui lit 30 To via le connecteur Snowflake chaque nuit « parce que c’est plus simple que d’aligner les catalogues ». Le SQL a l’air cheap ; la ligne réseau et le temps de transfert dominent. Inversement, sortir de Snowflake pour un outil qui n’y accède pas se justifie — vous le chiffrez (To × tarif egress × fréquence), vous ne le subissez pas.
Classique : vous voyez (à peu près) le cluster — taille de warehouse Snowflake, types d’instances Databricks, min/max workers, idle. Vous payez ce qui est allumé, d’où auto-suspend et job clusters. Serverless : le fournisseur pose les machines, les reprend, scale avec la file. Vous payez l’usage plus un tarif souvent plus élevé à la seconde, en échange d’un démarrage rapide et de moins de boutons.
Sur Databricks, le contraste est net : SQL warehouse ou compute serverless contre clusters classic que vous dimensionnez. Sur Snowflake, le warehouse est déjà un cluster managé ; le « serverless » désigne surtout des services (tâches, Snowpipe, clustering) facturés à part, sans t-shirt à garder chaud.
L’intervieweur attend le compromis, pas un camp. Serverless : moins d’ops, moins de cache que vous contrôlez, parfois des limites (libs, réseau, GPU). Classique : meilleur pour une charge stable et longue (un ETL de 3 h sur un M dédié), pire pour l’oubli allumé. La bonne phrase : serverless pour les pics imprévisibles et la BI intermittente ; classique quand vous savez remplir la machine et que le prix à l’heure gagne.
Le clic dans l’UI n’est pas un déploiement. Un senior décrit une chaîne : Git comme source, revue, artefact, promotion dev → prod.
Côté SQL / tables : dbt ou des migrations versionnées (schemachange, Terraform provider Snowflake, Databricks Asset Bundles + SQL). Chaque changement de schéma a un PR, un run sur un clone ou un catalogue dev, des tests de contrat (nombre de lignes, nulls interdits). On ne CREATE OR REPLACE pas la gold prod à la main le vendredi.
Côté notebooks Databricks : Repos ou fichiers dans le bundle, pas « Untitled 12 ». Les jobs prod pointent un commit, pas le HEAD du workspace. Les secrets viennent d’un scope, jamais d’une cellule. Les clusters de job sont déclarés (politique, version runtime), reproductibles.
L’intervieweur cherche les trous que vous nommez : un dashboard Looker hors Git, un UDF créé à la console, un grant manuel. Et le rollback : revert Git + redeploy, ou clone Time Travel, pas « on corrige en prod ». CI/CD de la donnée, c’est autant les droits et les schedules que le texte SQL.
Snowflake suffit quand la charge est surtout du SQL analytique sur des tables déjà (ou facilement) structurées, que les consommateurs sont la BI et la finance, et que l’équipe veut une admin minimale : des warehouses, des rôles, du dbt, pas un runtime Spark à soigner. Pas de lac de fichiers hétérogènes à explorer, pas d’entraînement distribué, pas de streaming à la seconde.
Trois filtres plus décisifs que le catalogue produit. Où sont les données aujourd’hui ? Si le SI charge déjà Snowflake et que personne n’a un seau Delta, inventer un lakehouse « pour plus tard » ajoute de l’egress et une copie. Qui opère ? Deux analystes seniors et un consultant : le TCO d’un workspace Databricks mal tenu dépasse les crédits d’un M bien suspendu. Quel coût de non-décision ? Un entrepôt un peu cher et prévisible bat deux plateformes à moitié branchées.
Vous n’affirmez pas que Snowflake « ne sait pas le Python ». Snowpark existe. Vous affirmez que vous n’avez pas le volume de cas qui justifie une deuxième plateforme — et que le sharing, Time Travel et les clones couvrent déjà recette, partenaires et audit.
Databricks est le bon outil quand le centre de gravité n’est pas une table SQL unique, mais des fichiers et des programmes. Données déjà sur S3/ADLS en Parquet/Delta/JSON, data scientists qui partagent le même bronze que l’ingénierie, ML (features, entraînement, MLflow), streaming structuré, notebooks et jobs Spark comme unité de travail. L’équipe a — ou accepte d’acquérir — des compétences de cluster et de formats.
Même trois filtres que pour l’entrepôt, inversés. Les données sont déjà au lac : les lire en place coûte moins que de les avaler dans un warehouse pour les recracher. La charge sort du SQL : UDF complexes, librairies, GPU, traitements d’images ou de logs semi-structurés à gros volume. Une seule plateforme pour plusieurs métiers : éviter le pont quotidien « extract Snowflake → notebook → republier ».
Vous ne vendez pas « Spark donc plus puissant ». Vous dites : le lakehouse gagne quand le fichier et le modèle sont des citoyens, pas des exceptions — et quand Unity Catalog (ou équivalent) est prévu, sinon vous achetez un lac poubelle plus cher. Si le besoin réel tient en dashboards SQL sur des marts stables, ce n’est pas ce poste.