Choisir la bonne méthode pour accéder et analyser vos données est crucial. Alors que de plus en plus d'entreprises exploitent des plateformes avancées comme Qlik et Databricks pour des analyses performantes, comprendre comment optimiser les connexions de données devient essentiel. Lors de l'intégration de ces deux outils, une question se pose souvent: faut-il utiliser Direct Query ou charger les données dans Qlik? Chaque méthode offre des avantages et des considérations spécifiques selon la taille des données, les exigences de performance et les besoins en temps réel de votre organisation.
Dans cet aperçu, nous explorerons les principales différences entre Direct Query et le calcul en mémoire (in-memory) dans Qlik lorsque vous travaillez avec Databricks, vous aidant à décider quelle approche convient le mieux à votre stratégie de données.
Qu'est-ce que la requête directe et le calcul en mémoire
Direct Query permet aux utilisateurs d'accéder directement aux données depuis leur source sous-jacente sans les charger dans Qlik. Cette méthode permet de conserver les données en externe, ce qui peut considérablement accélérer l'interaction des utilisateurs avec leurs jeux de données. Direct Query est particulièrement utile pour ceux qui ont besoin d'informations en temps quasi réel ou qui travaillent avec de très grands jeux de données, pour lesquels le chargement complet peut s'avérer difficile.
Le calcul en mémoire, quant à lui, intègre les données au moteur en mémoire de Qlik, permettant une modélisation avancée et une interactivité plus poussée. Cette méthode offre une rapidité et une flexibilité inégalées, ce qui en fait le choix privilégié pour les tâches analytiques complexes.
Pourquoi choisir Direct Query
Bien que le calcul en mémoire soit une option puissante, Direct Query débloque des capacités uniques qui sont particulièrement précieuses dans certains scénarios :
- Informations en temps réel : Direct Query garantit que les utilisateurs travaillent toujours avec des données à jour, ce qui le rend idéal pour la surveillance des tableaux de bord et des rapports d'état.
- Optimisé pour le Big Data : lorsqu'il s'agit d'ensembles de données massifs (par exemple, plus de 20 millions de lignes), Direct Query permet aux utilisateurs d'analyser les informations sans les frais de temps et de ressources liés aux rechargements complets dans Qlik.
- Exploration efficace des données : les utilisateurs peuvent explorer de nouvelles bases de données et tables avant de décider si le chargement des données dans Qlik est nécessaire, simplifiant ainsi la découverte des données et réduisant la redondance.
- Fonctionnalité d'écriture différée transparente : avec Direct Query, les modifications des données sous-jacentes sont instantanément répercutées dans Qlik. Il s'agit d'un avantage considérable par rapport aux applications en mémoire, où les utilisateurs doivent recharger les tables modifiées pour afficher les dernières mises à jour. Grâce à Direct Query, les résultats les plus récents de la base de données sont affichés en temps réel, améliorant ainsi l'efficacité du workflow.
- Intégration avec la génération d'applications à la demande (ODAG) : Direct Query peut être utilisé dans l'application de sélection pour extraire efficacement des tranches de données ciblées, en appliquant des filtres à toutes les tables pertinentes. Cela simplifie le transfert des données sélectionnées vers le moteur en mémoire de Qlik Cloud, ce qui en fait la solution idéale lorsque seules des portions spécifiques des données sont nécessaires à une analyse plus approfondie. Pour plus d'informations, consultez les détails sur la fonctionnalité ODAG .
Premiers pas avec Direct Query
Commencer par la requête directe est très simple.
- Créez une connexion entre Qlik et votre base de données Cloud. Vous trouverez plus d'informations sur la connexion de Qlik à Databricks dans un article précédent : Connexion de Qlik Sense à Databricks : Connexion manuelle ou connexion partenaire.
- Créer une nouvelle application
- Depuis la page Aperçu de l'application, cliquez sur « Fichiers et autres sources ». Vous ne pouvez pas lancer de requête directe depuis l'éditeur de chargement de données.
- Cliquez sur votre connexion
- Cliquez sur les boutons en haut à droite pour sélectionner le mode de requête directe
- Sélectionnez vos tables et vos champs
L'exécution de ces étapes créera automatiquement un script SQL dans l'éditeur de chargement de données
Évaluation des performances des requêtes directes par rapport aux calculs traditionnels en mémoire
Données
Pour évaluer les performances, j'ai utilisé un ensemble de données Kaggle. Cet ensemble de données comprend des informations sur différentes URL, précisant si chacune d'elles est classée comme hameçonnage ou non. Le fichier CSV est volumineux : 2 Go, il comprend 2,5 millions de lignes et 18 colonnes.
Vous trouverez ci-dessous un aperçu de l'ensemble de données :
Visuels
Pour notre expérience, nous avons conçu cinq graphiques uniques pour refléter une gamme de types de visualisation couramment utilisés dans Qlik, tout en testant les limites de Direct Query.
1.Graphique à secteurs visualisant le pourcentage d'URL légitimes et de phishing
2. Graphique KPI visualisant le nombre total d'enregistrements
3. Graphique à barres visualisant la longueur moyenne des URL de phishing et des URL légitimes
4. Nuage de points visualisant la relation entre l'entropie moyenne et la longueur moyenne des URL
5. Tableau simple visualisant des informations détaillées sur les URL
Ces visuels ont été sélectionnés pour représenter différents niveaux de complexité. Par exemple, le graphique 4 contient une instruction IF générant une charge de calcul importante, tandis que le graphique 5 est conçu pour effectuer une analyse complète de la table afin d'extraire des données. À l'inverse, les rapports 1, 2 et 3 sont destinés à illustrer des scénarios plus courants.
Résultats
Nous avons sélectionné la valeur « Phishing » dans la colonne « Libellé » pour tester les performances. Nous avons utilisé l'extension Chrome Add Sense pour afficher le temps de calcul des différents graphiques. Vous trouverez les résultats ci-dessous.
| Graphique | Requête directe | Requête directe avec Zorder | Calcul en mémoire | |
| 1 | Diagramme | 901 ms | 798 ms | 74 ms |
| 2 | Graphique KPI | 1275 ms | 800 ms | 88 ms |
| 3 | Diagramme à barres | 1561 ms | 787 ms | 88 ms |
| 4 | Nuage de points | 1951 ms | 1007 ms | 89 ms |
| 5 | Table droite | 1867 ms | 644 ms | 107 ms |
Les résultats de performance de notre test mettent en évidence les différences clés de temps de calcul entre Direct Query et les méthodes de chargement traditionnelles pour différents types de graphiques. Si les méthodes de chargement traditionnelles permettent généralement des calculs plus rapides grâce au traitement en mémoire optimisé de Qlik, Direct Query offre un avantage considérable : l'accès aux données en temps réel, directement depuis la source.
Étant donné que Direct Query récupère les données en temps réel de la base de données Databricks sous-jacente pour chaque interaction, les performances dépendent de facteurs tels que la latence du réseau, les temps de traitement des requêtes et l'optimisation de la base de données. Ainsi, les utilisateurs disposent toujours des données les plus récentes, sans avoir à les recharger régulièrement. Pour les organisations qui privilégient les insights en temps réel et doivent interroger dynamiquement de grands ensembles de données, Direct Query peut être une option intéressante.
Nos tests ont également démontré que l'implémentation de ZORDER BY dans Databricks améliorait les performances de Direct Query en optimisant la récupération des données. Si le traitement en mémoire reste l'approche la plus rapide, ZORDER permet de réduire les temps de requête en regroupant les données fréquemment consultées, améliorant ainsi l'efficacité des utilisateurs de Direct Query.
Conclusion
Choisir la bonne approche pour accéder aux données et les analyser est crucial pour les entreprises qui exploitent des plateformes avancées comme Qlik et Databricks . Cet article explore les principales différences entre les requêtes directes et le calcul en mémoire , en soulignant leurs avantages et leurs cas d'utilisation.
Direct Query permet un accès aux données en temps réel et est particulièrement utile pour les scénarios impliquant de grands ensembles de données , la fonctionnalité d'écriture différée et l'analyse exploratoire de nouvelles bases de données. Il offre un moyen simplifié d'interagir avec les données directement depuis la source, ce qui le rend idéal pour obtenir des informations en temps réel et réduire la charge de chargement de grands ensembles de données.
Cependant, le calcul en mémoire reste l'option privilégiée si des performances maximales et des analyses avancées sont requises. Si Direct Query introduit une latence en raison de la nécessité d'envoyer des requêtes à la base de données à chaque sélection, les méthodes de chargement traditionnelles bénéficient du préchargement des données en mémoire, ce qui accélère les temps de réponse.
En fin de compte, le choix entre Direct Query et le calcul en mémoire doit être guidé par vos besoins spécifiques en matière de données, vos exigences de performance et la nature de vos tâches analytiques. Pour l'accès aux données en temps réel et la gestion de grands ensembles de données, Direct Query est un outil précieux. Pour les scénarios où la performance et la vitesse sont essentielles, le calcul en mémoire peut être plus adapté.
Plus d'informations
Pour plus d'informations, contactez-nous !
