presto Resource Groups

資源組

資源組限制資源使用，能夠對運行在其中的任務執行強制排隊策略，也能夠在子組間分配資源。一個任務屬於一個資源組，消費這個組的資源。除了對排隊任務限制外，當資源組用完資源時，不會致使正在運行的任務失敗，而是讓新的任務排隊。資源組可能有子組或者接收任務，也可能都不。

資源組和相關篩選規則由一個插件配置。etc/resource-groups.properties這個配置文件有以下內容，內部插件能夠讀取json配置文件。

resource-groups.configuration-manager=file
resource-groups.config-file=etc/resource_groups.json

修改resource-groups.config-file這個屬性的值指向一個json配置文件，這個能夠是一個相對路徑也能夠是一個絕對路徑。

資源組屬性

name（必須）：組名稱，能夠是一個模板

maxQueued（必須）：排隊任務的最大數量，一旦達到這個數量，新的任務將被拒絕

hardConcurrencyLimit（必須）：正在運行的任務的數量

softMemoryLimit（必須）：這個組分佈式內存的最大使用量，一旦到達，新任務排隊。能夠指定爲一個絕對值，也能夠指定對集羣的百分比。

softCpuLimit（可選）：一個週期裏可使用cpu的時間，hardCpuLimit也必須指定

hardCpuLimit（可選）：一個週期裏可使用的cpu時間

schedulingPolicy（可選）：指定排隊任務執行的優先級，子組執行任務的優先級，有如下三個選項：

• fair（默認）：排隊中的查詢以first-in-first-out形式調度，若是子組中有排隊，輪流執行 
• weighted_fair：子組選擇基於schedulingWeight和目前在運行的任務。運行的任務須要的資源是基於合格的子組的權重。選擇相對於其資源具備最少併發性的子組來啓動下一個查詢。
• weighted：排隊任務按照優先級順序隨機選擇，選擇子組與它們的調度權重成比例地啓動新查詢。
• query_priority：全部子組也必須指定query_priority，排隊任務將根據priority嚴格執行

schedulingWeight（可選）：子組權重，默認爲1

jmxExport（可選）：若是設置爲true，組相關的統計指標被嚇到JMX以便監控，默認爲false

subGroups（可選）：子組列表

選擇規則

user（可選）：匹配用戶名

source（可選）：匹配源頭

queryType（可選）：匹配任務類型

• DATA_DEFINITION：alter/create/drop schemas/tables/views的元數據和權限、會話、事物相關的任務
• DELETE：刪除數據的任務
• DESCRIBE：DESCRIBE, DESCRIBE INPUT, DESCRIBE OUTPUT, and SHOW類型的任務
• EXPLAIN：EXPLAIN類型的任務
• INSERT：INSERT 和 CREATE TABLE AS 類型的任務
• SELECT：SELECT類型的任務

clientTags（可選）：tag列表，每一個tag必須在用戶提交任務的tag列表裏 

group（必須）：這些任務運行的組

全局屬性

cpuQuotaPeriod（可選）：cpu份額被強制執行的時間

選擇器順序處理，匹配的第一個將被使用

提供選擇器屬性

source名字能夠以下設置：

• CLI：用--source屬性
• JDBC：經過鏈接實例設置ApplicationName屬性

Client tags能夠以下設置

• CLI：用--client-tags屬性
• JDBC：經過鏈接實例設置ClientTags屬性

例子

例子中的配置以下，這裏有多個資源組，一些是模板。模板容許管理員動態的構建資源樹。例如，在pipeline_${USER} 組中，${USER}將被擴展爲提交任務的用戶名。${SOURCE}也支持，將被擴展爲提交任務的來源。你能夠用自定義變量在source和user正則表達式中

這裏定義了四個篩選器，這些任務運行在子組中：

• 第一個篩選器匹配bob的任務，並放在admin組中運行
• 第二個篩選器匹配全部的來源名字包含pipeline的DDL任務，放在global.data_definition組中運行。這有助於減小這類任務的執行時間，由於他們通常須要快速運行
• 第三個篩選器匹配來源中包含pipeline的任務，並放在global.pipeline中的dynamically-created per-user pipeline組中
• 第四個篩選器來源於 BI tools 的任務，而且客戶端提供的tag是「hi-pri」的超集。他們被放在global.pipeline.tools組裏的動態建立的子組。動態子組的建立基於tool_name變量的名字，歷來源的正則表達式中取出。一個任務來源爲「jdbc#powerfulbi」，用戶爲「kayla」，客戶端tag爲「hipri」和「fast」，這個任務將被放在global.pipeline.bi-powerfulbi.kayla資源組中。
• 最後一個篩選器是針對全部沒有被前面匹配的任務。

這些篩選器繼承了以下策略：

• 用戶「bob」是管理員，能同時運行50個任務，任務運行基於用戶提供的priority

其它的用戶：

• 不能同時運行100個任務
• 來源爲「pipeline」的最多能夠同時運行5個DDL任務，先進先出
• Non-DDL任務運行在global.pipeline中，總併發爲45，每一個用戶併發爲5，先進先出
• 對應BI tools，每一個tools最多能夠運行10個任務，每一個用戶最多運行3個。若是超過10個，運行任務最少的用戶將能夠繼續運行，這樣是保持公平。
• 其它任務被放在global.adhoc.other中的per-user 組中運行，運行類似

{
  "rootGroups": [
    {
      "name": "global",
      "softMemoryLimit": "80%",
      "hardConcurrencyLimit": 100,
      "maxQueued": 1000,
      "schedulingPolicy": "weighted",
      "jmxExport": true,
      "subGroups": [
        {
          "name": "data_definition",
          "softMemoryLimit": "10%",
          "hardConcurrencyLimit": 5,
          "maxQueued": 100,
          "schedulingWeight": 1
        },
        {
          "name": "adhoc",
          "softMemoryLimit": "10%",
          "hardConcurrencyLimit": 50,
          "maxQueued": 1,
          "schedulingWeight": 10,
          "subGroups": [
            {
              "name": "other",
              "softMemoryLimit": "10%",
              "hardConcurrencyLimit": 2,
              "maxQueued": 1,
              "schedulingWeight": 10,
              "schedulingPolicy": "weighted_fair",
              "subGroups": [
                {
                  "name": "${USER}",
                  "softMemoryLimit": "10%",
                  "hardConcurrencyLimit": 1,
                  "maxQueued": 100
                }
              ]
            },
            {
              "name": "bi-${tool_name}",
              "softMemoryLimit": "10%",
              "hardConcurrencyLimit": 10,
              "maxQueued": 100,
              "schedulingWeight": 10,
              "schedulingPolicy": "weighted_fair"
              "subGroups": [
                {
                  "name": "${USER}",
                  "softMemoryLimit": "10%",
                  "hardConcurrencyLimit": 3,
                  "maxQueued": 10
                }
              ]
            }
          ]
        },
        {
          "name": "pipeline",
          "softMemoryLimit": "80%",
          "hardConcurrencyLimit": 45,
          "maxQueued": 100,
          "schedulingWeight": 1,
          "jmxExport": true,
          "subGroups": [
            {
              "name": "pipeline_${USER}",
              "softMemoryLimit": "50%",
              "hardConcurrencyLimit": 5,
              "maxQueued": 100,
            }
          ]
        }
      ]
    },
    {
      "name": "admin",
      "softMemoryLimit": "100%",
      "hardConcurrencyLimit": 50,
      "maxQueued": 100,
      "schedulingPolicy": "query_priority",
      "jmxExport": true
    }
  ],
  "selectors": [
    {
      "user": "bob",
      "group": "admin"
    },
    {
      "source": ".*pipeline.*",
      "queryType": "DATA_DEFINITION",
      "group": "global.data_definition"
    },
    {
      "source": ".*pipeline.*",
      "group": "global.pipeline.pipeline_${USER}"
    },
    {
      "source": "jdbc#(?<tool_name>.*)",
      "clientTags": ["hipri"],
      "group": "global.adhoc.bi-${tool_name}.${USER}"
    },
    {
      "group": "global.adhoc.other.${USER}"
    }
  ],
  "cpuQuotaPeriod": "1h"
}