Aller au contenu principal
Dernière mise à jour le

Paramètres du SQL warehouse pour les charges de travail de BI

Les charges de travail Business Intelligence présentent des caractéristiques distinctes qui nécessitent des considérations spécifiques en matière de configuration de SQL Warehouse. Cette page fournit des conseils sur l'analyse de vos exigences en matière de charge de travail BI et la configuration des SQL Warehouse pour offrir des performances, une rentabilité et une fiabilité optimales.

Workload Analyse et exigences SLA​

Chaque charge de travail BI est unique et nécessite une analyse minutieuse avant la configuration. Tenez compte des questions suivantes lors de l'évaluation de vos exigences :

  • **Migration ou nouvelle implémentation :** Cette charge de travail est-elle migrée depuis une autre plateforme, ou s'agit-il d'une nouvelle implémentation ? Les charges de travail migrées peuvent avoir des SLA et des références de performance établis.
  • Accords de niveau de service (SLA) : Quels sont vos besoins en matière de latence, de throughput et de disponibilité ? Documentez les SLA techniques et commerciaux.
  • Modèles d'accès : Comment les utilisateurs interagissent-ils avec les données ? Comprendre les schémas de query typiques permet d'adapter la configuration de votre warehouse et d'optimiser la couche de données pour la workload spécifique.

Modèles d'accès BI typiques​

Les workloads BI se répartissent généralement en deux catégories distinctes de modèles d'accès, chacune nécessitant des configurations différentes de SQL Warehouse.

Modèle DirectQuery / LiveQuery​

Les modèles DirectQuery query les données en temps réel, nécessitant des réponses à faible latence pour l'analytique interactive :

Caractéristiques :

  • Nombre élevé de queries
  • Les query renvoient généralement de petits jeux de résultats (moins de 1 000 enregistrements)
  • Généralement exécuté pendant les heures d'ouverture
  • Exigences strictes en matière de SLA avec de faibles attentes de latence
  • Modèles de query imprévisibles (tableaux de bord, rapports)
  • Les données consultées par query sont généralement inférieures à 5 Go.
  • Nécessite un compute hautement évolutif pour s'adapter aux modèles de pointe.

Performances attendues :

  • Temps de réponse des requêtes : secondes (généralement moins de 5 secondes pour les tableaux de bord interactifs)
  • Récence des données : à jour, reflétant les données les plus récentes

Workload profile :

  • Pics fréquents pendant les heures ouvrables
  • Variations de charge imprévisibles (générées par l'utilisateur)
  • Peut s'étendre à 24h/24 et 7j/7 pour les organisations mondiales

Modèle d'importation / d'extraction​

Les modèles d'importation extraient des données pour les systèmes en aval, en privilégiant le throughput par rapport à la latence :

Caractéristiques :

  • Faible nombre de query (scheduled refresh)
  • Généralement, de grands jeux de résultats (plus de 1 000 000 d’enregistrements)
  • Généralement planifié pendant les heures creuses
  • Modèles de query prévisibles (souvent axés sur l'exploration)
  • Données accédées par requête : jusqu'à des dizaines de Go

Performances attendues :

  • Temps de réponse de la query : minutes à heures (orienté batch)
  • Actualisation des données : instantané journalier ou jour précédent

Workload profile :

  • Fenêtres d'exécution planifiées et prévisibles
  • Caractéristiques de workload connues et exigences en matière de Ressources
  • Traitement par batch

Mélange de query dans les charges de travail DirectQuery​

Lorsque vous utilisez des modèles DirectQuery avec un modèle de données en schéma en étoile, vous pouvez vous attendre à la distribution de query suivante :

  • Queries de dimension : nombreuses petites queries analysant les tables de dimension (client, produit, temps)
  • **query de faits :** De nombreuses grandes query analysant des tables de faits avec des jointures et des agrégations
  • Requêtes d'extraction : certaines requêtes simples mais de longue durée pour de grandes extractions de données

Ce mélange varié de queries nécessite des SQL warehouses qui peuvent gérer efficacement les petites queries fréquentes et les grandes queries analytiques simultanément.

Stratégie multi-warehouse pour l'isolation des charges de travail​

Databricks recommande le provisionnement de plusieurs SQL Warehouse pour obtenir :

Dimensionnement adéquat et coûts optimaux​

  • Dimensionnez chaque warehouse de manière appropriée pour son modèle de charge de travail spécifique
  • Évitez le sur-provisionnement en séparant les charges de travail ayant des exigences de ressources différentes.
  • Utilisez des warehouses plus petits pour le développement et les tests, et des warehouses plus grands pour la production.
  • Utilisez l'évolutivité du warehouse pour trouver l'équilibre idéal entre performance et coût.

Meilleures performances globales​

  • Prévenir les conflits de ressources entre les modèles DirectQuery et Import/Extract
  • Isolez les tableaux de bord interactifs des opérations de refresh par batch.
  • Activer le dimensionnement indépendant en fonction des exigences de la charge de travail.

Refacturation et répartition des coûts​

  • Suivez l'utilisation et les coûts par unité commerciale, projet ou équipe
  • Activer des modèles de refacturation précis
  • Améliorer la visibilité et la responsabilité des coûts

Administration et gestion plus efficaces​

  • Attribuez la propriété et les responsabilités de gestion par équipe ou par projet
  • Appliquer différentes politiques d'arrêt automatique en fonction des modèles d'utilisation
  • Configurez des contrôles d'accès et de monitoring distincts

Configurations de warehouse recommandées​

Pour les charges de travail DirectQuery / LiveQuery​

  • Utilisez les SQL Warehouse Serverless pour la gestion automatique des ressources.
  • Configurer l'arrêt automatique agressif (15-30 minutes) pour l'optimisation des coûts.
  • Définissez la taille des clusters en fonction de la complexité de la query et du volume de données (start avec Medium, monter en charge si nécessaire).
  • Définissez le nombre minimal et maximal de clusters en fonction de la charge de travail prévue.
  • Surveillez la métrique Pic des query en attente et ajustez les clusters max en conséquence

Pour les charges de travail d'importation/extraction​

  • Utilisez les SQL Warehouses Pro ou Classic pour des Jobs prévisibles et planifiés.
  • Configurez des délais d'arrêt automatique plus longs (de 1 à 2 heures) si plusieurs jobs s'exécutent en séquence.
  • Utilisez des tailles de clusters plus grandes (Large, X-Large) pour les agrégations complexes
  • Envisagez une planification fixe pour l’aligner sur les fenêtres de batch.
  • Surveillez la durée des requêtes et ajustez le dimensionnement en fonction des exigences de SLA.

Pour plus d'information sur le dimensionnement et le comportement de mise à l'échelle du SQL Warehouse, consultez Dimensionnement, mise à l'échelle et comportement de mise en file d'attente du SQL Warehouse.

Pour un aperçu rapide des bonnes pratiques du service de BI, consultez l'aide-mémoire sur le service de BI.

Sur cette page