Les Mapping Data Flows d'Azure Data Factory coûtent-ils plus cher que les données qu'ils déplacent ?

Les Mapping Data Flows sont la façon dont Azure Data Factory transforme les données sans écrire de code, et sous le canvas chacun tourne sur un cluster Spark managé. Le cluster démarre, le flow s’exécute, le cluster s’arrête, et la facture est à l’heure de vCore. Pour une grosse transformation, le compromis se justifie. Pour un chargement d’entrepôt ordinaire, c’est un cluster démarré pour faire le travail d’une seule instruction SQL.

Pourquoi le coût dérive

• Chaque exécution entraîne le coût d’un cluster. Le démarrage prend plusieurs minutes, et ces minutes sont facturées que le flow traite un million de lignes ou dix mille.
• Le garder chaud déplace le coût, il ne le supprime pas. Un time to live sur l’integration runtime évite l’attente et facture le cluster inactif à la place.
• Les petits chargements sont les plus nombreux. La plupart des chargements d’entrepôt sont petits et fréquents, ce qui est la pire configuration pour une tarification par cluster.
• Les données sont déjà dans une base. Elles sont extraites de l’entrepôt vers Spark, transformées, puis réécrites, alors que le moteur de l’entrepôt aurait pu faire le travail sur place.

Rien de tout cela n’est la faute des Data Flows. Spark est tarifé pour de la transformation lourde. Les chargements standards d’un entrepôt ne sont pas lourds.

Où la transformation devrait se situer

• Dans le moteur qui détient les données. Fabric, Synapse, Azure SQL et SQL Server sont tous des moteurs ensemblistes. Un chargement delta est une instruction qu’ils exécutent bien.
• En delta, pas en passe complète. Un chargement de vault généré compare avec ce qui est déjà historisé et ne touche que ce qui a changé.
• Généré une fois par plateforme. Du SQL ensembliste ajusté au moteur cible, plutôt qu’ajusté flow par flow au gré de celui qui l’a construit.

Ce qui change avec Datavault Builder

Datavault Builder génère des chargements delta ensemblistes pour les hubs, les links et les satellites, compilés pour Fabric, Synapse, Azure SQL ou SQL Server, de sorte que les transformations standards s’exécutent dans l’entrepôt sans qu’aucun cluster n’intervienne.

• Pas de cluster pour les chargements standards. Le chargement est une instruction dans le moteur qui détient déjà les données. Pas de démarrage, pas de temps d’inactivité.
• Chaque chargement est un delta. Seules les lignes nouvelles et modifiées circulent, donc le coût suit l’ampleur des changements de la source plutôt que sa taille.
• L’historique est un satellite, pas un recalcul. Les questions sur l’état passé trouvent leur réponse dans les changements stockés, sans recalculer le passé chaque nuit.
• Spark reste pour le travail qui relève de Spark. Les transformations très volumineuses ou non relationnelles peuvent garder un cluster. Elles sont l’exception, et elles ne fixent plus le prix de tout le reste.
• Le calcul devient une question de dimensionnement. La capacité de l’entrepôt se réserve et se prévoit. Des minutes de cluster par exécution, non.

Ce qu’il faut décider

Prenez les lignes Mapping Data Flow de la facture Azure et triez les flows par nombre de lignes traitées par exécution. Tout ce qui se trouve sous le point où le démarrage d’un cluster coûte plus cher que le travail lui-même est un chargement qui devrait être généré en SQL.