Aller au contenu principal

Lakehouse Real-Time

info

Bêta

Cette fonctionnalité est en Bêta. Contactez l'équipe de votre compte Databricks pour activer cette fonctionnalité dans votre compte.

Lakehouse//RT est en cours de développement actif. Les caractéristiques de performance et l'ensemble des fonctionnalités prises en charge changeront avant la disponibilité générale.

Lakehouse Real-Time (Lakehouse//RT) est un compute serverless conçu pour les cas d'utilisation à faible latence et à high concurrency, tels que la diffusion de données analytiques à des applications personnalisées, l'exécution d'analyses opérationnelles ou l'alimentation de tableaux de bord BI qui nécessitent des réponses en moins d'une seconde pour des centaines à des milliers d'utilisateurs simultanés.

Lakehouse//RT offre une latence inférieure à la seconde sur les requêtes de lecture SQL sur vos tables Unity Catalog qui utilisent les formats Delta Lake ou Apache Iceberg dans le stockage cloud. Vous créez et gérez Lakehouse//RT comme vous le faites pour d'autres SQL Warehouse. Un administrateur de workspace ou un utilisateur privilégié en crée un ou plusieurs par workspace et attribue des autorisations aux utilisateurs.

Exigences

Pour utiliser Lakehouse//RT, vous devez :

  • Assurez-vous d'être dans une région prise en charge.
  • Faites activer la version Bêta de Lakehouse//RT dans votre workspace.

Activez Lakehouse//RT dans votre workspace

Les administrateurs du Workspace peuvent activer la version bêta de Lakehouse//RT dans votre Workspace :

  1. Dans le menu de votre workspace (coin supérieur droit), accédez à Aperçus .
  2. Recherchez Lakehouse RT .
  3. Activez l'aperçu.

Après avoir activé l'aperçu, le type de warehouse temps réel devient disponible dans le flux de création de SQL Warehouse pour votre Workspace.

Créer un warehouse Lakehouse//RT

Pour créer un warehouse Lakehouse//RT :

  1. Accéder à Compute > SQL Warehouses > Créer un SQL Warehouse .
  2. Select temps réel .
  3. Sélectionnez une taille de query : Small , Medium , Large ou X-Large , en fonction des performances requises par vos requêtes.
  4. Configurez la mise à l’échelle automatique pour déterminer le nombre maximal de DBU qui peuvent vous être facturés par heure.
  5. Définissez Arrêt automatique pour contrôler le moment où un warehouse inactif s'arrête.
  6. Saisissez un nom pour le warehouse.
  7. Cliquez sur Créer .

Pour attribuer des autorisations, accordez Peut utiliser , Peut surveiller ou Peut gérer aux utilisateurs et aux groupes, de la même manière qu'un SQL Warehouse.

remarque

Vous ne pouvez pas actuellement mettre à niveau un SQL warehouse existant vers Lakehouse//RT ou rétrograder un warehouse Lakehouse//RT existant vers un autre type de warehouse.

Dimensionner et monter en charge un warehouse Lakehouse//RT

Lakehouse//RT dispose de paramètres qui contrôlent les performances et les coûts :

  • La taille de la query contrôle le compute disponible pour une seule query.
  • La mise à l’échelle automatique contrôle la mesure dans laquelle le warehouse monte en charge pour servir des requêtes simultanées.
  • L’arrêt automatique contrôle la durée pendant laquelle un idle warehouse continue de fonctionner avant de s’arrêter.

La taille de la requête et la mise à l’échelle automatique fonctionnent différemment des paramètres de dimensionnement et de mise à l’échelle d’un SQL Warehouse Serverless.

Taille de la query

La taille de la query définit le compute maximal qu’une seule query peut utiliser, ce qui détermine la vitesse d’exécution d’une query individuelle. Elle définit également le compute minimal sur lequel l’entrepôt (warehouse) fonctionne, ainsi que le minimum qui vous est facturé pendant que l’entrepôt (warehouse) est actif.

Vous définissez la taille de la query lors de la création du warehouse. Choisissez Small , Medium , Large ou X-Large . Une taille plus importante offre à chaque query davantage de compute pour des résultats plus rapides, moyennant un coût minimum plus élevé.

Ce paramètre est similaire dans son concept à la taille d’un entrepôt SQL Serverless, qui définit également le compute disponible pour une seule query.

Dimensionnement automatique

L'autoscaling permet à un warehouse d'ajouter du compute pour servir davantage de requêtes simultanées, puis de le libérer lorsque la demande diminue. Vous définissez le compute maximal vers lequel le warehouse peut monter en charge, mesuré en DBU.

L'autoscaling sur Lakehouse//RT diffère du scaling de cluster sur un SQL warehouse serverless de plusieurs manières :

  • Il est mesuré en DBU, et non en clusters.
  • Le maximum est indépendant de la taille de la query. Vous pouvez associer une petite taille de query à un maximum élevé pour obtenir une high concurrency sans allouer plus de compute à chaque query.
  • La mise à l’échelle automatique de Lakehouse//RT ajoute et supprime uniquement le compute nécessaire, au lieu de procéder par incréments de clusters.

Pour voir dans quelle mesure un warehouse effectue un scaling, utilisez sa page de monitoring.

Arrêt automatique

L'arrêt automatique met fin au warehouse après un nombre défini de minutes d'inactivité, afin qu'un warehouse inactif ne continue pas à générer des frais. Vous définissez le délai d'inactivité lors de la création du warehouse.

L’arrêt automatique sur Lakehouse//RT fonctionne de la même manière que sur un SQL Warehouse Serverless. Pour les valeurs default et minimales, consultez Configurer les paramètres de SQL Warehouse.

Surveiller l'activité de Lakehouse//RT

Vous pouvez surveiller les queries Lakehouse//RT de la même manière que toute query exécutée sur un SQL Warehouse :

  • Historique des query : Les query Lakehouse//RT apparaissent dans l'UI de l'historique des query et la table système de l'historique des query.
  • Profils de query : ouvrez une query Lakehouse//RT dans l'interface utilisateur de l'historique des queries pour afficher son profil de query.
  • Page de monitoring : surveillez le throughput des queries, les queries en attente et l'historique des queries sur la page de monitoring de chaque warehouse Lakehouse//RT.
  • Facturation : l'utilisation de Lakehouse//RT apparaît dans les tables du système de facturation avec un sku_name de Lakehouse_Serverless.

Bonnes pratiques

Pour obtenir les meilleurs résultats de Lakehouse//RT : préparez vos charges de travail avant de les déplacer.

  • Validez d'abord sur SQL Serverless. Exécutez vos requêtes sur un SQL Warehouse serverless et confirmez qu'elles s'exécutent en quelques secondes.
  • Utilisez les tables gérées par Unity Catalog. Les tables gérées avec l'optimisation prédictive et le clustering liquide garantissent que vos données sont bien clusterisées pour vos modèles de charge de travail.
  • Vérifiez que les queries sont sélectives. Pour une latence inférieure à la seconde, vérifiez que vos query analysent de moindres quantités de données. Filtrez tôt avec les clauses WHERE, sélectionnez uniquement les colonnes dont vous avez besoin et appuyez-vous sur les agrégations. La jointure de tables est prise en charge, mais si votre query devient complexe ou lente, envisagez d'utiliser des vues matérialisées qui pré-agrègent vos données pour des latences plus rapides.
  • Vérifiez la couverture SQL. Lakehouse//RT ne prend en charge que les queries en lecture conformes à ANSI. Confirmez que vos workloads sont conformes à la norme ANSI et évitez les instructions, fonctions et types de données non pris en charge répertoriés sous Limitations.

Fonctionnalités prises en charge

Outils et interfaces

Vous pouvez sélectionner Lakehouse//RT à partir du sélecteur compute dans l'une des fonctionnalités Databricks suivantes :

  • Éditeur SQL
  • Notebooks SQL
  • Tableaux de bord AI/BI
  • Explorateur de catalogue
  • Alertes

Types de table

Lakehouse//RT interroge uniquement les données du Unity Catalog. Pour de meilleures performances, utilisez les tables gérées Unity Catalog, qui fournissent au moteur le layout de données dont il a besoin pour une faible latence.

Lakehouse//RT prend en charge les types de table suivants :

  • Tables gérées (tables Delta Lake et Apache Iceberg)
  • Vues matérialisées et tables de streaming
  • Vues métriques

Connectivité

Lakehouse//RT n'accepte que les connexions qui utilisent l'API d'exécution des instructions. Il ne prend pas en charge le protocole Thrift hérité, donc un Driver qui se connecte sans utiliser explicitement l'API d'exécution des instructions reçoit une erreur 501.

Vous pouvez vous connecter à un warehouse Lakehouse//RT des manières suivantes :

Tarifs

Pour les informations sur les tarifs, consultez la page des tarifs de Lakehouse Real-Time.

Limitations

Lorsqu’une query utilise une fonctionnalité non prise en charge, Lakehouse//RT renvoie une erreur nommant la fonctionnalité. Pour exécuter la query avec succès, utilisez un SQL Warehouse Serverless à la place.

Outils et fonctionnalités

Lakehouse//RT ne prend pas encore en charge les fonctionnalités suivantes :

  • Genie
  • Agents Genie
  • Tâches de jobs

Types de table

Les types de table suivants ne sont pas encore pris en charge :

  • Tables système
  • Tables Delta Sharing
  • Tables dans le stockage default d'Unity Catalog
  • Tables externes dans Unity Catalog

Lakehouse//RT ne prend pas en charge les types de table suivants :

  • Tables du Hive metastore (gérées ou externes)
  • Tables externes et fédération de requêtes (Lakehouse Federation)
  • Tables temporaires
  • Tables qui utilisent d'autres formats de données (CSV, JSON, Avro, Parquet, ORC et texte)

Drivers et connecteurs

Lakehouse//RT ne prend pas en charge les drivers et connecteurs suivants :

  • ADBC
  • ODBC

Langage SQL

Lakehouse//RT exécute les queries SQL en mode ANSI uniquement. Il évalue toutes les coercitions et conversions de type implicites selon des règles SQL ANSI strictes, et ce comportement ne peut pas être désactivé. Selon la sémantique ANSI, les requêtes qui s'appuyaient sur un comportement non-ANSI pourraient :

  • Signaler une erreur d'environnement d'exécution au lieu de produire silencieusement NULL. Par exemple, convertir une chaîne non numérique en nombre.
  • Déclenchez une erreur d'analyse-temps lorsqu'il n'y a pas de type commun sûr. Par exemple, COALESCE, CASE, IN ou des opérations d'ensemble entre types incompatibles.
  • Renvoie un type de résultat différent du mode hérité, car la promotion de chaîne ANSI et l'élargissement numérique choisissent des types sûrs et sans perte.

Pour obtenir des résultats prévisibles, utilisez des expressions CAST explicites lorsque les conversions implicites en mode ANSI ne produisent pas le comportement attendu.

Lakehouse//RT ne prend pas en charge ce qui suit :

  • Types de données : les types de données GEOGRAPHY et GEOMETRY.
  • Fonctions : fonctions IA, UDF Python, fonctions SQL spatiales et fonctions XPath et XML.
  • Gouvernance : contrôle d'accès basé sur les attributs (ABAC), y compris la sécurité au niveau des lignes et le masquage des colonnes.

Lakehouse//RT est uniquement destiné aux requêtes de lecture (SELECT). Les commandes d'écriture et ETL ne sont pas prises en charge, notamment :

  • Opérations d'écriture : INSERT, UPDATE, DELETE, MERGE et CREATE TABLE AS SELECT (CTAS).
  • DDL : CREATE, ALTER, DROP et autres instructions qui créent ou modifient des objets.
  • **Déclarations de sécurité :** GRANT REVOKEet.
  • Scripting, procédures stockées, tables temporaires et transactions multi-déclarations.
  • Maintenance de Delta Lake : OPTIMIZE, ANALYZE, VACUUM et REFRESH.

Sécurité du réseau

important

Lakehouse//RT s’exécute sur le compute Serverless de Databricks. Pour créer un pare-feu autour de votre stockage cloud tout en autorisant l’accès depuis le compute serverless, consultez Serverless compute firewall configuration. Les méthodes de configuration de pare-feu héritées ont été récemment obsolètes. S’ils sont toujours utilisés, le compute serverless peut renvoyer une erreur 403 Forbidden lors de la tentative d’accès à votre stockage.

Lakehouse//RT ne prend pas encore en charge les configurations réseau suivantes :

conformité

Les profils de sécurité de conformité ne sont actuellement pas pris en charge.