Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history
Co-authored-by: Ivan Blinkov <ivan@blinkov.ru>
  • Loading branch information
vporyadke and blinkov authored Jan 31, 2025
1 parent fc2d2d5 commit c1be092
Showing 1 changed file with 12 additions and 12 deletions.
24 changes: 12 additions & 12 deletions ydb/docs/ru/core/contributor/hive.md
Original file line number Diff line number Diff line change
@@ -1,44 +1,44 @@
# Hive

Hive — таблетка, отвечающая за управление другими таблетками, а именно, за выбор, на каких узлах базы запускать таблетку, принимает решение о необходимости перебалансировать таблетки и т.п.
Hive — таблетка, отвечающая за управление другими таблетками, а именно за выбор узлов базы для их запуска, принятие решений о необходимости перебалансировки таблеток и т.п.

Создание и удаление таблеток инициируется таблеткой [SchemeShard](../concepts/glossary.md#scheme-shard). При создании таблетки Hive присваивает ей уникальный TabletId, заполняет [TabletStorageInfo](general-schema.md#history), выбирает наиболее подходящий узел и отправляет на него команду поднять таблетку. В некоторых нестандартных ситуациях отдельная таблетка может прервать работу, тогда узел, на котором она была запущена, отправляет сообщение в Hive. Также Hive предполагает, что если связь с некоторым узлом потеряна, то запущенные на нём таблетки прекратили работу. В таких ситуациях Hive запускает таблетки на других узлах с увеличением поколения.
Создание и удаление таблеток инициируется таблеткой [SchemeShard](../concepts/glossary.md#scheme-shard). При создании таблетки Hive присваивает ей уникальный TabletId, заполняет [TabletStorageInfo](general-schema.md#history), выбирает наиболее подходящий узел и отправляет на него команду на запуск таблетки. В некоторых нестандартных ситуациях отдельная таблетка может прервать работу, тогда узел, на котором она была запущена, отправляет сообщение в Hive. Также Hive предполагает, что если связь с некоторым узлом потеряна, то запущенные на нём таблетки прекратили работу. В таких случаях Hive перезапускает таблетки на других узлах с увеличением поколения.

В кластере {{ ydb-short-name }} есть корневой Hive, который отвечает за [системные таблетки](../concepts/glossary.md#tablet-types) всех баз данных кластера. Hive конкретной базы данных в свою очередь отвечает за таблетки, обслуживающие пользовательскую нагрузку этой базы данных. Все узлы кластера регистрируются в корневом Hive, а в Hive конкретной базы регистрируются только вычислительные узлы этой базы. При регистрации узел сообщает в Hive, таблетки каких типов и в каких количествах могут быть на нём запущены.
В кластере {{ ydb-short-name }} есть корневой Hive, который отвечает за [системные таблетки](../concepts/glossary.md#tablet-types) всех баз данных кластера. Hive конкретной базы данных, в свою очередь, отвечает за таблетки, обслуживающие пользовательскую нагрузку этой базы. Все узлы кластера регистрируются в корневом Hive, а в Hive конкретной базы регистрируются только вычислительные узлы этой базы. При регистрации узел сообщает в Hive, какие типы таблеток и в каком количестве могут быть на нём запущены.

## Метрики потребления ресурсов

Для распределения таблеток по узлам Hive учитывает потребление ресурсов. Для каждой таблетки учитывается потребление 4 типов ресурсов:
Для распределения таблеток по узлам Hive учитывает потребление ресурсов. Для каждой таблетки отслеживается потребление четырёх типов ресурсов:

1. *CPU* — потребление процессора, считается как число микросекунд, потраченных на работу таблетки за последнюю секунду и для визуализации переводится в проценты ядра.
1. *CPU* — потребление процессора, рассчитывается как число микросекунд, затраченных на работу таблетки за последнюю секунду, и для визуализации переводится в проценты ядра.
1. *Memory* — потребление таблеткой оперативной памяти.
1. *Network* — генерируемый таблеткой объём трафика.
1. *Counter* — фиктивный ресурс, используемый для реализации равномерного распределения в штуках. Применяется для любых таблеток, для которых нет данных по трём другим ресурсам, а также для таблеток [колоночных таблиц](../concepts/datamodel/table.md#column-oriented-tables). Если у таблетки есть этот ресурс, то его значение всегда равно 1.

Дополнительно для определения перегруженных узлов используются метрики потребления ресурсов узла целиком: потребление оперативной памяти, и ресурсов процессора в пулах акторной системы. Эти значения переводятся в относительную величину (число от 0 до 1), и их максимум используется как значение общего потребления ресурсов узла — *Node usage*. Также для всех метрик на стороне Hive используется агрегация на окне, чтобы учитывать всплески нагрузки.
Дополнительно для определения перегруженных узлов используются метрики потребления ресурсов узла целиком: потребление оперативной памяти и ресурсов процессора в пулах акторной системы. Эти значения переводятся в относительную величину (число от 0 до 1), и их максимум используется как значение общего потребления ресурсов узла — *Node usage*. Также для всех метрик на стороне Hive применяется агрегация по окну, чтобы учитывать всплески нагрузки.

## Автобалансировка

В определённые моменты Hive может запустить процесс автобалансировки, перемещающий таблетки между узлами для улучшения распределения нагрузки. Ситуации, в которых это происходит, перечислены ниже. Автобалансировщик выбирает самый загруженный узел, взвешенно-случайным образом выбирает на нём таблетку и находит для таблетки более подходящий узел. Этот процесс повторяется, пока сбалансированность не будет восстановлена. Как именно определяется загруженность узла зависит от типа балансировки: например, при дисбалансе потребления CPU будет использоваться потребление CPU, а при неравномерном распределении колоночной таблицы — количество таблеток.
В определённые моменты Hive может запустить процесс автобалансировки, перемещающий таблетки между узлами для улучшения распределения нагрузки. Ситуации, в которых это происходит, перечислены ниже. Автобалансировщик выбирает самый загруженный узел, взвешенно-случайным образом выбирает на нём таблетку и находит для неё более подходящий узел. Этот процесс повторяется, пока сбалансированность не будет восстановлена. То, как именно определяется загруженность узла, зависит от типа балансировки: например, при дисбалансе потребления CPU учитывается потребление CPU, а при неравномерном распределении колоночной таблицы — количество таблеток.

### Дисбаланс потребления ресурсов

Для оценки сбалансированности потребления используется метрика *Scatter*, вычисляемая отдельно для каждого ресурса по формуле:

$$\mathrm{Scatter} = \frac{\mathrm{MaxUsage} - \mathrm{MinUsage}}{\mathrm{MaxUsage}},$$

где $\mathrm{MaxUsage}$ и $\mathrm{MinUsage}$ — соответственно максимум и минимум по потреблению данного ресурса среди всех узлов. Для нормировки потребления на каждом узле используется число доступных ресурсов на узле, которое может различаться между узлами. При низких нагрузках эта величина может сильно колебаться. Чтобы этого избежать, при вычислении $\mathrm{Scatter}$ считается, что потребление ресурса не может быть ниже 30%. Если Scatter превышает порог, запускается балансировка.
где $\mathrm{MaxUsage}$ и $\mathrm{MinUsage}$ — соответственно максимум и минимум потребления данного ресурса среди всех узлов. Для нормировки потребления на каждом узле используется число доступных ресурсов на узле, которое может различаться между узлами. При низких нагрузках эта величина может сильно колебаться. Чтобы этого избежать, при вычислении $\mathrm{Scatter}$ считается, что потребление ресурса не может быть ниже 30%. Если $Scatter$ превышает порог, запускается балансировка.

Максимальное из значений Scatter по разным ресурсам доступно в виде [сенсора](../devops/manual/monitoring.md) `Hive/MAX(BalanceScatter)` в подгруппе `tablets`.
Максимальное из значений $Scatter$ по разным ресурсам доступно в виде [сенсора](../devops/manual/monitoring.md) `Hive/MAX(BalanceScatter)` в подгруппе `tablets`.

### Перегруженность узла

Наличие сильно загруженного узла может негативно сказываться на работе {{ ydb-short-name }}: загруженность по CPU приводит к голоданию и увеличению задержки, а загруженность по памяти может привести к падению узла по out-of-memory. Балансировка запускается, если самый загруженный узел имеет загрузку больше 90%, а наименее загруженныйменьше 70%.
Наличие сильно загруженного узла может негативно сказываться на работе {{ ydb-short-name }}: загруженность по CPU приводит к голоданию и увеличению задержки, а загруженность по памяти может привести к падению узла по out-of-memory. Балансировка запускается, если загрузка самого загруженного узла превышает 90%, а наименее загруженногониже 70%.

Максимальное потребление на узле доступно в виде [сенсора](../devops/manual/monitoring.md) `Hive/MAX(BalanceScatter)` в подгруппе `tablets`.

### Равномерное распределение конкретного объекта

Для таблеток, которые используют ресурс Counter, также отслеживается равномерность распределения таблеток каждого объекта (каждой таблицы) с помощью метрики *ObjectImbalance*, аналогичной описанной выше Scatter. При рестартах узлов равномерность может нарушаться, и тогда запускается балансировка.
Для таблеток, которые используют ресурс Counter, также отслеживается равномерность распределения таблеток каждого объекта (каждой таблицы) с помощью метрики `ObjectImbalance`, аналогичной описанной выше $Scatter$. При рестартах узлов равномерность может нарушаться, и тогда запускается балансировка.

Максимальное из значений ObjectImbalance по разным объектам доступно в виде [сенсора](../devops/manual/monitoring.md) `Hive/MAX(BalanceObjectImbalance)` в подгруппе `tablets`.
Максимальное из значений `ObjectImbalance` по разным объектам доступно в виде [сенсора](../devops/manual/monitoring.md) `Hive/MAX(BalanceObjectImbalance)` в подгруппе `tablets`.

0 comments on commit c1be092

Please sign in to comment.