translate hive article to english

ydb/docs/en/core/concepts/glossary.md

@@ -421,7 +421,7 @@ A **memory controller** is an [actor](#actor) that manages {{ ydb-short-name }}
 
 ### Tablet types {#tablet-types}
 
-[Tablets](#tablet) can be considered a framework for building reliable components operating in a distributed system. {{ ydb-short-name }} has multiple components implemented using this framework, listed below.
+[Tablets](#tablet) can be considered a framework for building reliable components operating in a distributed system. Many {{ ydb-short-name }} components implemented using this framework, listed below.
 
 #### Scheme shard {#scheme-shard}
 
@@ -459,7 +459,7 @@ The **Mediator** is a system tablet that distributes the transactions planned by
 
 #### Hive {#hive}
 
-A **Hive** is a system tablet responsible for launching and managing other tablets. Its responsibilities include moving tablets between nodes in case of [node](#node) failure or overload.
+A **Hive** is a system tablet responsible for launching and managing other tablets. Its responsibilities include moving tablets between nodes in case of [node](#node) failure or overload. You can learn more about Hive in a [dedicated article](../contributor/hive.md).
 
 #### Cluster management system {#cms}
 

ydb/docs/en/core/contributor/general-schema.md

@@ -18,7 +18,10 @@ Dynamic nodes are not known in advance and are added to the system as new proces
 
 ## Tablets {#tablets}
 
-Special microservices called *tablets* run on each node. Each tablet has a specific type and ID and is a singleton, meaning that only one tablet with a specific ID can be running in the entire cluster at any given time. A tablet can launch on any suitable node. *Generation* is an important property of a tablet that increases with each subsequent launch. Please note that the distributed nature of the system and various issues, such as network partitioning problems, may result in a situation where the same tablet is actually running on two different nodes simultaneously. However, distributed storage guarantees that only one of them will successfully complete operations that change its state and that the generation in which each successful operation runs will not decrease over time.
+Special microservices called [tablets](../concepts/glossary.md#tablet) run on each node. Each tablet has a specific type and ID and is a singleton, meaning that only one tablet with a specific ID can be running in the entire cluster at any given time. A tablet can launch on any suitable node. [Generation](../concepts/glossary.md#tablet-generation) is an important property of a tablet that increases with each subsequent launch. Please note that the distributed nature of the system and various issues, such as network partitioning problems, may result in a situation where the same tablet is actually running on two different nodes simultaneously. However, distributed storage guarantees that only one of them will successfully complete operations that change its state and that the generation in which each successful operation runs will not decrease over time.
+
+For cluster-level [system tablets](../concepts/glossary.md#tablet-types), the node on which the tablet runs is selected using a mechanism called Bootstrapper, which implements [distributed consensus](https://en.wikipedia.org/wiki/Consensus_(computer_science)). User tablets are managed by a special tablet called [Hive](hive.md). Hive ensures that all tablets are running, distributes tablets across nodes, and manages [tablet channels](../concepts/glossary.md#channel) between storage groups.
+
 
 You can find out on which node the tablet in the current generation is running through the *StateStorage* service. To send messages to tablets, use a special set of libraries named *tablet pipe*. With this, knowing the ID of the target tablet, you can easily send the desired message to it.
 
@@ -44,7 +47,7 @@ The tablet writes blobs of different types to different *channels*. A channel sp
 
 ### Tablet channel history {#history}
 
-As mentioned previously, each group has a constant amount of data that fits into it and shares the bandwidth's throughput and the number of operations per second among all consumers. The load on tablets may vary. As a result, a group may become overloaded. To address this, the concept of history is introduced, which allows you to determine the group that a blob is written to based on its channel and generation.
+As mentioned previously, each group has a constant amount of data that fits into it and shares the bandwidth's throughput and the number of operations per second among all consumers. The load on tablets may vary. As a result, a group may become overloaded and it will be necessary to switch writes to another group. To address this, the concept of history is introduced, which allows you to determine the group that a blob is written to based on its channel and generation.
 
 This mechanism works as follows: