共用方式為


Azure Cosmos DB Spark 連接器:輸送量控制

適用於:NoSQL

Spark 連接器可讓您使用 Apache Spark 與 Azure Cosmos DB 通訊。 本文說明輸送量控制功能的運作方式。 請參閱 GitHub 中的 Spark 範例,以開始使用輸送量控制。

本文記載在 Azure Cosmos DB Spark 連接器中使用全域輸送量控制群組,但 Java SDK 中也提供此功能。 在 SDK 中,您可以使用全域和本機輸送量控制群組來限制單一用戶端連線實例內容中的要求單位 (RU) 耗用量。 例如,您可以將此方法套用至單一微服務內的不同作業,或套用至單一數據載入程式。 如需詳細資訊,請參閱如何在 Java SDK 中使用輸送量控制

警告

閘道模式不支援輸送量控制。 目前,針對 無伺服器 Azure Cosmos DB 帳戶,嘗試使用 targetThroughputThreshold 來定義百分比會導致失敗。 您只能使用 spark.cosmos.throughputControl.targetThroughput提供目標輸送量/RU 的絕對值。

為什麼輸送量控制很重要?

輸送量控制有助於隔離針對容器執行之應用程式的效能需求。 輸送量控制會限制特定 Spark 用戶端可取用的 RU 數量。

數個進階案例受益於用戶端輸送量控制:

  • 不同的作業和工作有不同的優先順序: 由於數據擷取或複製活動,可能需要防止一般交易受到節流。 某些作業或工作對延遲並不敏感,而且比其他作業更能承受節流。
  • 為不同的使用者或租使用者提供公平/隔離: 應用程式通常有許多使用者。 有些使用者可能會傳送太多要求,這會取用所有可用的輸送量,並導致其他人受到節流。
  • 不同 Azure Cosmos DB 用戶端之間的輸送量負載平衡: 在某些使用案例中,請務必確定所有用戶端都能獲得公平(相等)的輸送量份額。

輸送量控制可視需要啟用更細微層級 RU 速率限制的功能。

輸送量控制如何運作?

若要設定 Spark 連接器的輸送量控制,您必須先建立定義輸送量控制元數據的容器。 分割區索引鍵為 groupIdttl 已啟用。 在這裡,您會使用 Spark SQL 建立此容器,並加以呼叫 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');

上述範例會建立具有自動調整容器。 如果您偏好標準布建,可以使用 來取代 autoScaleMaxThroughput manualThroughput

重要

分割區索引鍵必須定義為 /groupId ,而且 ttl 必須啟用輸送量控制功能才能運作。

在特定應用程式的 Spark 組態中,您可以接著指定工作負載的參數。 下列範例會將輸送量控制項設定為 enabled。 此範例會定義輸送量控制群組 name 參數和 targetThroughputThreshold 參數。 您也會定義 database 輸送量控制群組維護所在的 和 container 參數:

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

在上述範例中 targetThroughputThreshold ,參數定義為 0.95。 當用戶端耗用配置給容器的輸送量超過 95% (+/- 5-10%) 時,會發生速率限制(和要求重試)。 此組態會儲存為輸送量容器中的檔,如下所示:

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

輸送量控制不會執行每個作業的 RU 預先計算。 而是會根據回應標頭追蹤作業「之後」的 RU 使用量。 因此,輸送量控制是以近似值 為基礎,且不保證 群組隨時都有可用的輸送量。

基於這個理由,如果設定的 RU 太低,單一作業就可以全部使用它,輸送量控制便無法避免 RU 超過設定的限制。 當設定的限制高於特定控制群組中用戶端可執行的任何單一作業時,輸送量控制效果最佳。

當您透過查詢或變更摘要讀取時,應該將頁面大小設定為 spark.cosmos.read.maxItemCount 中等數量(預設值 1000)。 如此一來,用戶端輸送量控件就可以以較高的頻率重新計算,並在任何特定時間更準確地反映。 當您使用大量寫入作業的輸送量控制時,單一要求中執行的檔數目會根據節流速率自動調整,以允許輸送量控制儘早開始。

警告

參數 targetThroughputThreshold 是不 可變的。 如果您變更目標輸送量閾值,則會建立新的輸送量控制群組。 (如果您使用 4.10.0 版或更新版本,它可以有相同的名稱。如果您想要確保這些作業全都立即取用新的閾值,則必須重新啟動所有使用群組的Spark作業。 否則,他們會在下一次重新啟動後挑選新的臨界值。

針對每個使用輸送量控制群組的 ThroughputControl Spark用戶端,會在容器中建立一筆記錄,且 ttl 需要幾秒鐘的時間。 因此,如果Spark用戶端不再主動執行,檔就會迅速消失。 以下是範例:

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

在每個客戶端記錄中 loadFactor ,屬性代表特定用戶端上的負載,相對於輸送量控制群組中的其他用戶端。 allocatedThroughput 屬性會顯示目前配置給此用戶端的 RU 數目。 Spark 連接器會根據其負載調整每個用戶端的已配置輸送量。 如此一來,每個客戶端都會取得與負載成正比的可用輸送量共用。 所有用戶端在一起不會耗用超過針對其所屬輸送量控制群組配置的總計。