groupby part

Querying/groupby.md

@@ -241,6 +241,18 @@ groupBy v2通过寻址打开哈希引擎来用于聚合。哈希表使用给定
 
 初始bucket的默认数目是1024个，哈希表的默认最大负载因子是0.7。如果在哈希表中可以看到太多的冲突，可以调整这些数字。可以在[高级配置](#高级配置)部分中查看 `bufferGrouperInitialBuckets`和`bufferGrouperMaxLoadFactor`。
 
+**并行合并**
+
+一旦Historical使用哈希表完成数据聚合，它将对聚合结果进行排序并将其合并，然后再发送到Broker进行N路合并聚合。默认情况下，Historical使用其所有可用的处理线程（由`druid.processing.numThreads`配置)用于聚合，但使用单个线程对聚合结果进行排序和合并，这是一个http线程，用于向代Broker发送数据。
+
+这是为了防止一些繁重的groupBy查询阻塞其他查询。在Druid中，处理线程在所有提交的查询之间共享，它们是*不可中断的*。这意味着，如果一个重查询占用了所有可用的处理线程，那么所有其他查询都可能被阻塞，直到重查询完成。GroupBy查询通常比timeseries或topN查询花费更长的时间，因此它们应该尽快释放处理线程。
+
+但是，您可能会关心一些非常繁重的groupBy查询的性能。通常，重groupBy查询的性能瓶颈是合并排序的聚合。在这种情况下，也可以使用处理线程，这叫做*并行合并*。要启用并行合并，请参阅[高级配置](#高级配置)中的 `numParallelCombineThreads` 参数。
+
+启用并行合并后，groupBy v2引擎可以创建一个合并树来合并排序的聚合。树的每个中间节点都是一个线程，它合并了来自子节点的聚合。叶节点线程从哈希表（包括溢出的哈希表）读取和合并聚合。通常，叶进程比中间节点慢，因为它们需要从磁盘读取数据。因此，默认情况下，中间节点使用的线程较少。可以更改中间节点的阶数。请参阅[高级配置](#高级配置)中的 `intermediateCombineDegree`。
+
+请注意，每个Historical都需要两个合并缓冲区来处理带有并行合并的groupBy v2查询：一个用于计算每个段的中间聚合，另一个用于并行合并中间聚合。
+
 #### 备选方案
 #### 嵌套的GroupBy查询
 #### 配置