Lakehouse Real-Time

Important

Cette fonctionnalité est en version bêta. Contactez votre équipe de compte Databricks pour activer cette fonctionnalité dans votre compte.

Lakehouse//RT est en développement actif. Les caractéristiques de performances et le jeu de fonctionnalités pris en charge changent avant la disponibilité générale.

Lakehouse Real-Time (Lakehouse//RT) est un calcul serverless conçu pour des cas d’usage à faible latence et à haute concurrence, tels que le service de données analytiques aux applications personnalisées, l’exécution d’analyses opérationnelles ou l’alimentation des tableaux de bord BI qui nécessitent des réponses de sous-seconde pour des centaines à des milliers d’utilisateurs simultanés.

Lakehouse//RT offre une latence inférieure à seconde sur les requêtes de lecture SQL sur vos tables de catalogue Unity qui utilisent des formats Delta Lake ou Apache Iceberg dans le stockage cloud. Vous créez et gérez Lakehouse/RT de la même façon que d’autres entrepôts SQL. Un administrateur d’espace de travail ou un utilisateur privilégié crée un ou plusieurs par espace de travail et affecte des autorisations aux utilisateurs.

Requirements

Pour utiliser Lakehouse//RT, vous devez :

Activer Lakehouse//RT dans votre espace de travail

Les administrateurs d’espace de travail peuvent activer la version bêta de Lakehouse//RT dans votre espace de travail :

  1. Dans le menu de votre espace de travail (en haut à droite), accédez aux aperçus.
  2. Recherchez Lakehouse RT.
  3. Activez l’aperçu.

Après avoir activé la préversion, le type d’entrepôt en temps réel devient disponible dans le flux de création de l’entrepôt SQL pour votre espace de travail.

Créer un entrepôt Lakehouse//RT

Pour créer un entrepôt Lakehouse//RT :

  1. Accédez à Compute>SQL Warehouses>.
  2. Sélectionnez Temps réel.
  3. Sélectionnez une taille de requête : Petite, Moyenne, Grande ou X Grande, selon les performances requises par vos requêtes.
  4. Configurez l’Autoscaling pour déterminer le nombre maximal de DBU pouvant vous être facturés par heure.
  5. Réglez l’arrêt automatique pour contrôler quand un entrepôt inactif s’arrête.
  6. Entrez un nom pour l’entrepôt.
  7. Cliquez sur Créer.

Pour attribuer des autorisations, accordez Peut utiliser, Peut surveiller ou Peut gérer aux utilisateurs et aux groupes, comme pour un entrepôt SQL.

Note

Vous ne pouvez pas actuellement mettre à niveau un entrepôt SQL existant vers Lakehouse//RT ou rétrograder un entrepôt Lakehouse//RT existant vers un autre type d’entrepôt.

Taille et échelle : un entrepôt Lakehouse//RT

Lakehouse//RT propose des réglages qui contrôlent la performance et le coût :

  • La taille de la requête contrôle le calcul disponible pour une seule requête.
  • La mise à l’échelle automatique contrôle dans quelle mesure l’entrepôt s’étend afin de traiter les requêtes simultanées.
  • L’arrêt automatique contrôle combien de temps un entrepôt d’inactivité reste en marche avant de s’arrêter.

La taille des requêtes et l’auto-scaling fonctionnent différemment des réglages de taille et d’échelle d’un SQL warehouse serverless.

Taille de la requête

La taille de la requête fixe le calcul maximal qu’une requête unique peut utiliser, ce qui détermine la vitesse à laquelle une requête individuelle peut s’exécuter. Il définit également le niveau minimal de ressources de calcul sur lequel l’entrepôt de données s’exécute, ainsi que le minimum qui vous est facturé tant que l’entrepôt de données est actif.

Vous définissez la taille de la requête lors de la création de l’entrepôt. Choisissez petit, moyen, grand ou x-grand. Une taille plus grande donne à chaque requête plus de calcul pour obtenir des résultats plus rapides, à un coût minimum plus élevé.

Ce paramètre est similaire en concept à la taille d’un entrepôt SQL serverless, qui rend également le calcul disponible pour une requête unique.

Mise à l’échelle automatique

L’autoscaling permet à un entrepôt d’ajouter du calcul pour servir davantage de requêtes simultanées, puis de le libérer lorsque la demande diminue. Vous définissez la capacité de calcul maximale jusqu’à laquelle l’entrepôt peut monter en charge, mesurée en DBU.

La mise à l’échelle automatique dans Lakehouse//RT diffère de la mise à l’échelle des clusters dans un entrepôt SQL sans serveur sur plusieurs points :

  • Elle se mesure en DBU, pas en clusters.
  • Le maximum est indépendant de la taille de la requête. Vous pouvez associer une petite taille de requête à un maximum élevé pour obtenir une forte concurrence sans donner plus de calcul à chaque requête.
  • La mise à l’échelle automatique de Lakehouse//RT ajoute et supprime uniquement les ressources de calcul nécessaires, plutôt que par incréments de clusters.

Pour voir à quel point un entrepôt évolue, utilisez sa page de surveillance.

Arrêt automatique

L’arrêt automatique met fin à l’entrepôt après qu’il soit resté inactif pendant un certain nombre de minutes, donc un entrepôt inactif n’accumule pas sans cesse des frais. Vous définissez le délai d’attente lorsque vous créez l’entrepôt.

L’arrêt automatique sur Lakehouse//RT fonctionne de la même manière que sur un entrepôt SQL sans serveur. Pour les valeurs par défaut et minimales, voir Configurer les paramètres de l’entrepôt SQL.

Surveiller l’activité Lakehouse//RT

Vous pouvez surveiller les requêtes Lakehouse//RT identiques à celles exécutées sur un entrepôt SQL :

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 entrepôt SQL serverless et vérifiez qu’elles s’exécutent en quelques secondes.
  • Utilisez des tables gérées par le catalogue Unity. Les tables managées avec optimisation prédictive et clustering liquide garantissent que vos données sont bien regroupées pour vos modèles de charge de travail.
  • Vérifiez que les requêtes sont sélectives. Pour une latence inférieure à la seconde, vérifiez que vos requêtes analysent moins de quantités de données. Filtrez en amont avec des clauses WHERE, sélectionnez uniquement les colonnes dont vous avez besoin et privilégiez les agrégations. La jonction entre les tables est prise en charge, mais si vous trouvez que votre requête devient complexe ou lente, envisagez d’utiliser des vues matérialisées qui pré-agrègent vos données pour accélérer les latences.
  • Vérifiez la couverture SQL. Lakehouse//RT prend uniquement en charge les requêtes de lecture compatibles ANSI. Vérifiez que vos charges de travail sont conformes à 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 dans le sélecteur de calcul dans l’une des fonctionnalités de Azure Databricks suivantes :

  • Éditeur SQL
  • Notebooks SQL
  • Tableaux de bord IA/BI
  • Explorateur de catalogues
  • Alerts

Types de tables

Lakehouse//RT interroge uniquement les données du catalogue Unity. Pour des performances optimales, utilisez des tables gérées par le catalogue Unity, qui fournissent au moteur la disposition des données dont elle a besoin pour une faible latence.

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

  • Tables managées (tables Delta Lake et Apache Iceberg)
  • Vues matérialisées et tables de diffusion en continu
  • Affichage des métriques

Connectivity

Lakehouse//RT accepte uniquement les connexions qui utilisent l’API d’exécution d’instruction. Il ne prend pas en charge le protocole Thrift hérité. Par conséquent, un pilote qui se connecte sans utiliser explicitement l’API d’exécution d’instruction reçoit une 501 erreur.

Vous pouvez vous connecter à un entrepôt Lakehouse//RT de la manière suivante :

Pricing

Pour plus d’informations sur la tarification, consultez la page de tarification de Lakehouse Real-Time .

Limitations

Lorsqu’une requête utilise une fonctionnalité non prise en charge, Lakehouse//RT retourne une erreur nommant la fonctionnalité. Pour exécuter correctement la requête, utilisez plutôt un entrepôt SQL serverless.

Outils et fonctionnalités

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

  • Génie
  • Agents génie
  • Tâches de travail

Types de tables

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

  • Tables du système
  • Tables Delta Sharing
  • Tables dans le stockage par défaut du catalogue Unity
  • Tables externes dans le catalogue Unity

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

  • Tables de metastore Hive (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)

Pilotes et connecteurs

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

  • ADBC
  • ODBC

Langage SQL

Lakehouse//RT exécute uniquement des requêtes de lecture SQL en mode ANSI . Il évalue toutes les contraintes de type implicite et les casts en fonction de règles ANSI SQL strictes, et ce comportement ne peut pas être désactivé. Sous la sémantique ANSI, les requêtes qui s’appuyaient sur un comportement non ANSI peuvent :

  • Générez une erreur d’exécution au lieu de produire silencieusement NULL. Par exemple, la conversion d’une chaîne non numérique en nombre.
  • Déclencher une erreur lors de l’analyse lorsqu’il n’existe aucun type commun sûr. Par exemple, COALESCE, , CASEou INdéfinissez des opérations entre des types incompatibles.
  • Renvoie un type de résultat différent de celui du mode hérité, car la promotion des chaînes ANSI et l’élargissement des types numériques sélectionnent des types sûrs, sans perte.

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

Lakehouse//RT ne prend pas en charge les éléments suivants :

  • Types de données : Les types de données GEOGRAPHY et GEOMETRY.
  • Fonctions : Fonctions IA, Python fonctions UDF, 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 destiné uniquement aux requêtes en lecture (SELECT). Les commandes d’écriture et ETL ne sont pas prises en charge, notamment :

  • Opérations d’écriture :INSERT, , UPDATE, DELETEMERGEet CREATE TABLE AS SELECT (CTAS).
  • DDL :CREATE, ALTER, DROPet d’autres instructions qui créent ou modifient des objets.
  • Instructions de sécurité :GRANT et REVOKE.
  • Scripts, procédures stockées, tables temporaires et transactions à plusieurs instructions.
  • Maintenance de Delta Lake :OPTIMIZE, ANALYZE, VACUUM, et REFRESH.

Sécurité du réseau

Important

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

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

Compliance

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

  • Last updated on