Dela via

Azure Cosmos DB Spark-anslutningsprogram: Dataflödeskontroll

  • Artikel

GÄLLER FÖR: NoSQL

Med Spark-anslutningsappen kan du kommunicera med Azure Cosmos DB med hjälp av Apache Spark. I den här artikeln beskrivs hur funktionen för dataflödeskontroll fungerar. Kolla in våra Spark-exempel i GitHub för att komma igång med dataflödeskontroll.

Den här artikeln dokumenterar användningen av globala dataflödeskontrollgrupper i Azure Cosmos DB Spark-anslutningsappen, men funktionerna är också tillgängliga i Java SDK. I SDK:t kan du använda globala och lokala dataflödeskontrollgrupper för att begränsa ru-förbrukningen (request unit) i kontexten för en enda klientanslutningsinstans. Du kan till exempel tillämpa den här metoden på olika åtgärder inom en enda mikrotjänst, eller kanske på ett enda datainläsningsprogram. Mer information finns i hur du använder dataflödeskontroll i Java SDK.

Varning

Dataflödeskontroll stöds inte för gatewayläge. För närvarande, för serverlösa Azure Cosmos DB-konton, försöker använda targetThroughputThreshold för att definiera ett procentresultat i fel. Du kan bara ange ett absolut värde för måldataflöde/RU med hjälp spark.cosmos.throughputControl.targetThroughputav .

Varför är dataflödeskontroll viktigt?

Dataflödeskontroll hjälper till att isolera prestandabehoven för program som körs mot en container. Dataflödeskontroll begränsar mängden RU:er som en specifik Spark-klient kan använda.

Flera avancerade scenarier har nytta av dataflödeskontroll på klientsidan:

  • Olika åtgärder och uppgifter har olika prioriteter: Det kan finnas ett behov av att förhindra att normala transaktioner begränsas på grund av datainmatning eller kopieringsaktiviteter. Vissa åtgärder eller uppgifter är inte känsliga för svarstider och är mer toleranta mot att begränsas än andra.
  • Ge rättvisa/isolering till olika användare eller klienter: Ett program har vanligtvis många användare. Vissa användare kan skicka för många begäranden som förbrukar alla tillgängliga dataflöden och gör att andra begränsas.
  • Belastningsutjämning av dataflöde mellan olika Azure Cosmos DB-klienter: I vissa fall är det viktigt att se till att alla klienter får en rättvis (lika) del av dataflödet.

Med dataflödeskontroll kan du använda mer detaljerad RU-hastighetsbegränsning efter behov.

Hur fungerar dataflödeskontroll?

Om du vill konfigurera dataflödeskontroll för Spark-anslutningsappen skapar du först en container som definierar metadata för dataflödeskontroll. Partitionsnyckeln är groupId och ttl är aktiverad. Här skapar du den här containern med hjälp av Spark SQL och anropar den 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');

I föregående exempel skapas en container med autoskalning. Om du föredrar standardetablering kan du ersätta autoScaleMaxThroughput med manualThroughput.

Viktigt!

Partitionsnyckeln måste definieras som /groupId och ttl måste vara aktiverad för att funktionen för dataflödeskontroll ska fungera.

I Spark-konfigurationen för ett visst program kan du sedan ange parametrar för arbetsbelastningen. I följande exempel anges dataflödeskontroll som enabled. Exemplet definierar en kontrollgruppparameter name för dataflöde och en targetThroughputThreshold parameter. Du definierar också parametrarna database och container där dataflödeskontrollgruppen underhålls:

    "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"

I föregående exempel definieras parametern targetThroughputThreshold som 0,95. Hastighetsbegränsning sker (och begäranden görs på nytt) när klienter använder mer än 95 procent (+/- 5–10 procent) av det dataflöde som allokerats till containern. Den här konfigurationen lagras som ett dokument i dataflödescontainern, vilket ser ut så här:

    {
        "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
    }

Dataflödeskontroll utför inte RU-förberäkning av varje åtgärd. I stället spårar den RU-användningarna efter åtgärden baserat på svarshuvudet. Därför baseras dataflödeskontrollen på en uppskattning och garanterar inte att mängden dataflöde är tillgängligt för gruppen vid en viss tidpunkt.

Om den konfigurerade RU:en därför är så låg att en enskild åtgärd kan använda allt, kan dataflödeskontrollen inte undvika att RU överskrider den konfigurerade gränsen. Dataflödeskontroll fungerar bäst när den konfigurerade gränsen är högre än en enskild åtgärd som en klient i den specifika kontrollgruppen kan köra.

När du läser via fråga eller ändringsflöde bör du konfigurera sidstorleken i spark.cosmos.read.maxItemCount (standard 1 000) till en blygsam mängd. På så sätt kan klientens dataflödeskontroll beräknas om med högre frekvens och återspeglas mer exakt vid en viss tidpunkt. När du använder dataflödeskontroll för ett skrivjobb med massvis justeras antalet dokument som körs i en enda begäran automatiskt baserat på begränsningshastigheten så att dataflödeskontrollen kan börja så tidigt som möjligt.

Varning

Parametern targetThroughputThreshold är oföränderlig. Om du ändrar tröskelvärdet för måldataflöde skapas en ny kontrollgrupp för dataflöde. (Om du använder version 4.10.0 eller senare kan den ha samma namn.) Du måste starta om alla Spark-jobb som använder gruppen om du vill se till att alla använder det nya tröskelvärdet omedelbart. Annars tar de upp det nya tröskelvärdet efter nästa omstart.

För varje Spark-klient som använder dataflödeskontrollgruppen skapas en post i containern ThroughputControl med några ttl sekunder. Därför försvinner dokumenten snabbt om en Spark-klient inte längre körs aktivt. Här är ett exempel:

    {
        "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
    }

I varje klientpost loadFactor representerar attributet belastningen på den specifika klienten i förhållande till andra klienter i dataflödeskontrollgruppen. Attributet allocatedThroughput visar hur många RU:er som för närvarande allokeras till den här klienten. Spark-anslutningsappen justerar allokerat dataflöde för varje klient baserat på belastningen. På så sätt får varje klient en del av det tillgängliga dataflödet som är proportionellt mot belastningen. Alla klienter tillsammans förbrukar inte mer än den totala allokerade för dataflödeskontrollgruppen som de tillhör.

Relaterat innehåll