Resource Groups

Documentation: trino.io Canvas: Resource Group

Resource group config file

etc/resource-groups.properties

JSON

{
	"rootGroups": [],
	"selectors": [],
	"cpuQuotaPeriod": ""
}

Database

DB Type

• MySQL
• PostgreSQL
• Oracle

PostgreSQL config example

resource-groups.configuration-manager=db
resource-groups.config-db-url=jdbc:postgresql://localhost:5432/trino
resource-groups.config-db-user=user
resource-groups.config-db-password=password

SQL Tables

• resource_groups_global_properties
• resource_groups
• selectors

DDL

Transclude of resource-groups-db-ddl

Properties

Так как в одной БД теоритически могут храниться RG для разных окружений необходимо заполнять так же колонку environment. Значение должно совпадать с таким же значением в файле node.properties.

schedulingPolicy

• fair (✅): First-in-first out, подгруппы должны так же выполнять запрос по очереди.
• weighted_fair: подгруппы выбираются на основе их веса планирования (schedulingWeight) и количества запросов, которые они уже выполняют параллельно. Ожидаемая доля выполняемых запросов для подгруппы вычисляется на основе весов для всех подгрупп, имеющих право на выполнение в данный момент. Для запуска следующего запроса выбирается подгруппа с наименьшим параллелизмом по отношению к ее доле.
• weighted: запросы выбираются просто пропорционально их параметру query_priority (заданному в свойствах сессии). Подгруппы выбираются для запуска новых запросов пропорционально их schedulingWeight.
• query_priority: Все подгруппы так же должны использовать это значение. Запрос выбирается строго в соответствии с query_priority.

Шаблоны

В определении групп можно использовать шаблоны вида ${USER} или bi-${toolname}, что позволяет создавать например группы вида:

 {
	"name": "${USER}",
    "softMemoryLimit": "10%",
    "hardConcurrencyLimit": 3,
    "maxQueued": 10
}

по факту это именная группа выставляющая лимиты для каждого пользователя. Вот селектор для неё:

{
	"group": "global.adhoc.other.${USER}"
}

Selectors

Так как в случае хранения селекторов в базе данных их порядок не гарантирован важно заполнять колонку priority. Чем больше число в ней тем выше приоритет у селектора т.е. тем он как бы выше в JSON представлении.

queryType

• SELECT: SELECT queries.
• EXPLAIN: EXPLAIN queries (but not EXPLAIN ANALYZE).
• DESCRIBE: DESCRIBE, DESCRIBE INPUT, DESCRIBE OUTPUT, and SHOW queries.
• INSERT: INSERT, CREATE TABLE AS, and REFRESH MATERIALIZED VIEW queries.
• UPDATE: UPDATE queries.
• DELETE: DELETE queries.
• ANALYZE: ANALYZE queries.
• DATA_DEFINITION: Queries that alter/create/drop the metadata of schemas/tables/views, and that manage prepared statements, privileges, sessions, and transactions.

Example

Resource Groups Example

Example

{
  "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-${toolname}",
              "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"
    },
    {
      "userGroup": "admin",
      "group": "admin"
    },
    {
      "source": ".*pipeline.*",
      "queryType": "DATA_DEFINITION",
      "group": "global.data_definition"
    },
    {
      "source": ".*pipeline.*",
      "group": "global.pipeline.pipeline_${USER}"
    },
    {
      "source": "jdbc#(?<toolname>.*)",
      "clientTags": ["hipri"],
      "group": "global.adhoc.bi-${toolname}.${USER}"
    },
    {
      "group": "global.adhoc.other.${USER}"
    }
  ],
  "cpuQuotaPeriod": "1h"
}

Example Selectors

There are four selectors, that define which queries run in which resource group:

• The first selector matches queries from bob and places them in the admin group.
• The second selector matches queries from admin user group and places them in the admin group.
• The third selector matches all data definition (DDL) queries from a source name that includes pipeline and places them in the global.data_definition group. This could help reduce queue times for this class of queries, since they are expected to be fast.
• The fourth selector matches queries from a source name that includes pipeline, and places them in a dynamically-created per-user pipeline group under the global.pipeline group.
• The fifth selector matches queries that come from BI tools which have a source matching the regular expression jdbc#(?<toolname>.*) and have client provided tags that are a superset of hipri. These are placed in a dynamically-created sub-group under the global.adhoc group. The dynamic sub-groups are created based on the values of named variables toolname and user. The values are derived from the source regular expression and the query user respectively. Consider a query with a source jdbc#powerfulbi, user kayla, and client tags hipri and fast. This query is routed to the global.adhoc.bi-powerfulbi.kayla resource group.
• The last selector is a catch-all, which places all queries that have not yet been matched into a per-user adhoc group.

Description

Together, these selectors implement the following policy:

• The user bob and any user belonging to user group admin is an admin and can run up to 50 concurrent queries. Queries will be run based on user-provided priority.

For the remaining users:

• No more than 100 total queries may run concurrently.
• Up to 5 concurrent DDL queries with a source pipeline can run. Queries are run in FIFO order.
• Non-DDL queries will run under the global.pipeline group, with a total concurrency of 45, and a per-user concurrency of 5. Queries are run in FIFO order.
• For BI tools, each tool can run up to 10 concurrent queries, and each user can run up to 3. If the total demand exceeds the limit of 10, the user with the fewest running queries gets the next concurrency slot. This policy results in fairness when under contention.
• All remaining queries are placed into a per-user group under global.adhoc.other that behaves similarly.

Ссылка на оригинал