Connecteur Spark Azure Cosmos DB : contrôle du débit

Le connecteur Spark vous permet de communiquer avec Azure Cosmos DB à l’aide d’Apache Spark. Cet article décrit le fonctionnement de la fonctionnalité de contrôle de débit. Consultez nos exemples Spark dans GitHub pour commencer à utiliser le contrôle de débit.

Cet article décrit l’utilisation des groupes de contrôle de débit globaux dans le connecteur Spark Azure Cosmos DB, mais la fonctionnalité est également disponible dans le kit de développement logiciel (SDK) Java. Le kit de développement logiciel (SDK) vous permet de limiter la consommation d’unités de requête (RU) dans le contexte d’une instance de connexion client unique à l’aide de groupes de contrôle de débit globaux et locaux. Par exemple, vous pouvez appliquer cette approche à différentes opérations au sein d’un même microservice ou éventuellement à un seul programme de chargement de données. Pour en savoir plus, découvrez comment utiliser le contrôle du débit dans le kit de développement logiciel (SDK) Java.

Pourquoi le contrôle de débit est-il important ?

Le contrôle du débit permet d’isoler les besoins en performances des applications qui s’exécutent sur un conteneur. Le contrôle du débit limite la quantité d’unités de requête qu’un client Spark spécifique peut consommer.

Plusieurs scénarios avancés tirent parti du contrôle du débit côté client :

• Différentes opérations et tâches ont des priorités différentes : il peut être nécessaire d’empêcher les transactions standard d’être limitées en raison des activités d’ingestion ou de copie de données. Certaines opérations ou tâches ne sont pas sensibles à la latence et sont plus tolérantes à la limitation que d’autres.
• Fournir l’impartialité/l’isolation à différents utilisateurs ou abonnés : une application a généralement de nombreux utilisateurs. Certains utilisateurs peuvent envoyer trop de requêtes, qui consomment tout le débit disponible et entraînent la limitation des autres utilisateurs.
• Équilibrage de charge du débit entre différents clients Azure Cosmos DB : dans certains cas d’utilisation, il est important de s’assurer que tous les clients obtiennent un partage juste (égal) du débit.

Le contrôle du débit permet de limiter le débit d’unité de requête à un niveau plus granulaire si nécessaire.

Fonctionnement du contrôle du débit

Pour configurer le contrôle du débit pour le connecteur Spark, vous devez d’abord créer un conteneur qui définit les métadonnées de contrôle du débit. La clé de partition est groupId et ttl est activé. Ici, vous créez ce conteneur à l’aide de Spark SQL et l’appelez ThroughputControl :

    %sql
    CREATE TABLE IF NOT EXISTS cosmosCatalog.`database-v4`.ThroughputControl 
    USING cosmos.oltp
    OPTIONS(spark.cosmos.database = 'database-v4')
    TBLPROPERTIES(partitionKeyPath = '/groupId', autoScaleMaxThroughput = '4000', indexingPolicy = 'AllProperties', defaultTtlInSeconds = '-1');

L’exemple précédent crée un conteneur avec mise à l’échelle automatique. Si vous préférez l’approvisionnement standard, vous pouvez remplacer autoScaleMaxThroughput par manualThroughput.

Dans la configuration Spark d’une application spécifique, vous pouvez ensuite spécifier des paramètres pour la charge de travail. L’exemple suivant définit le contrôle du débit sur enabled. L’exemple définit le paramètre name du groupe de contrôle du débit et un paramètre targetThroughputThreshold. Vous définissez également les paramètres database et container dans lesquels le groupe de contrôle du débit est géré :

    "spark.cosmos.throughputControl.enabled" -> "true",
    "spark.cosmos.throughputControl.name" -> "SourceContainerThroughputControl",
    "spark.cosmos.throughputControl.targetThroughputThreshold" -> "0.95", 
    "spark.cosmos.throughputControl.globalControl.database" -> "database-v4", 
    "spark.cosmos.throughputControl.globalControl.container" -> "ThroughputControl"

Dans l’exemple précédent, le paramètre targetThroughputThreshold est défini sur 0,95. La limitation du débit se produit (et les demandes sont retentées) lorsque les clients consomment plus de 95 % (+/- 5 à 10 %) du débit alloué au conteneur. Cette configuration est stockée en tant que document dans le conteneur de débit, qui ressemble à cet exemple :

    {
        "id": "ZGF0YWJhc2UtdjQvY3VzdG9tZXIvU291cmNlQ29udGFpbmVyVGhyb3VnaHB1dENvbnRyb2w.info",
        "groupId": "database-v4/customer/SourceContainerThroughputControl.config",
        "targetThroughput": "",
        "targetThroughputThreshold": "0.95",
        "isDefault": true,
        "_rid": "EHcYAPolTiABAAAAAAAAAA==",
        "_self": "dbs/EHcYAA==/colls/EHcYAPolTiA=/docs/EHcYAPolTiABAAAAAAAAAA==/",
        "_etag": "\"2101ea83-0000-1100-0000-627503dd0000\"",
        "_attachments": "attachments/",
        "_ts": 1651835869
    }

Le contrôle du débit ne calcule pas au préalable les unités de requête de chaque opération. Au lieu de cela, il effectue le suivi des utilisations de RU après l’opération en fonction de l’en-tête de réponse. Par conséquent, le contrôle du débit est basé sur une approximation et ne garantit pas que la quantité de débit est disponible pour le groupe à un moment donné.

Ainsi, si le nombre de RU configuré est bas au point qu’elles soient entièrement utilisées par une seule opération, le contrôle du débit ne peut pas éviter que les RU dépassent la limite configurée. Le contrôle du débit convient mieux lorsque la limite configurée est plus haute qu’une opération unique qu’un client dans le groupe de contrôle concerné peut exécuter.

Lorsque vous lisez au moyen d’un flux de requête ou de modification, vous devez configurer la taille de page dans spark.cosmos.read.maxItemCount (par défaut 1 000) afin qu’elle soit modeste. Ainsi, le contrôle du débit client peut être recalculé avec une fréquence plus élevée et reflété plus précisément à tout moment. Lorsque vous utilisez le contrôle du débit pour un travail d’écriture en bloc, le nombre de documents exécutés dans la même demande est automatiquement ajusté en fonction du taux de limitation pour permettre au contrôle du débit de commencer le plus tôt possible.

Pour chaque client Spark qui utilise le groupe de contrôle du débit, un enregistrement est créé dans le conteneur ThroughputControl, avec une ttl de quelques secondes. Par conséquent, les documents disparaissent rapidement si un client Spark ne s’exécute plus activement. Voici un exemple :

    {
        "id": "Zhjdieidjojdook3osk3okso3ksp3ospojsp92939j3299p3oj93pjp93jsps939pkp9ks39kp9339skp",
        "groupId": "database-v4/customer/SourceContainerThroughputControl.config",
        "_etag": "\"1782728-w98999w-ww9998w9-99990000\"",
        "ttl": 10,
        "initializeTime": "2022-06-26T02:24:40.054Z",
        "loadFactor": 0.97636377638898,
        "allocatedThroughput": 484.89444487847,
        "_rid": "EHcYAPolTiABAAAAAAAAAA==",
        "_self": "dbs/EHcYAA==/colls/EHcYAPolTiA=/docs/EHcYAPolTiABAAAAAAAAAA==/",
        "_etag": "\"2101ea83-0000-1100-0000-627503dd0000\"",
        "_attachments": "attachments/",
        "_ts": 1651835869
    }

Dans chaque enregistrement client, l’attribut loadFactor représente la charge sur le client concerné, par rapport aux autres clients du groupe de contrôle du débit. L’attribut allocatedThroughput indique le nombre d’unités de requête actuellement allouées à ce client. Le connecteur Spark ajuste le débit alloué pour chaque client en fonction de sa charge. Ainsi, chaque client obtient une part du débit disponible proportionnelle à sa charge. Tous les clients ne consomment pas plus que le total alloué pour le groupe de contrôle du débit auquel ils appartiennent.

Contenu connexe

• Consultez Exemples Spark dans GitHub.
• Découvrez comment gérer les données avec le connecteur OLTP Azure Cosmos DB Spark 3 pour API pour NoSQL.
• Découvrez plus en détail Apache Spark.