chaojianok commented on a change in pull request #11897:
URL: https://github.com/apache/flink/pull/11897#discussion_r415230158
##########
File path: docs/dev/table/tuning/streaming_aggregation_optimization.zh.md
##########
@@ -22,33 +23,34 @@ specific language governing permissions and limitations
under the License.
-->
-SQL is the most widely used language for data analytics. Flink's Table API and
SQL enables users to define efficient stream analytics applications in less
time and effort. Moreover, Flink Table API and SQL is effectively optimized, it
integrates a lot of query optimizations and tuned operator implementations. But
not all of the optimizations are enabled by default, so for some workloads, it
is possible to improve performance by turning on some options.
+SQL 是数据分析最广泛使用的语言。Flink Table API 和 SQL 使用户能够以更少的时间和精力定义高效的流分析应用程序。而且，Flink
Table API 和 SQL
是有效优化过的，它集成了许多查询优化和算子实现。但并不是所有的优化都是默认开启的，因此对于某些工作负载，可以通过打开某些选项来提高性能。
-In this page, we will introduce some useful optimization options and the
internals of streaming aggregation which will bring great improvement in some
cases.
+这里我们将介绍一些实用的优化选项以及流式聚合的内部原理，它们在某些情况下能带来很大改进。
-<span class="label label-danger">Attention</span> Currently, the optimization
options mentioned in this page are only supported in the Blink planner.
+<span class="label label-danger">注意</span> 目前，这里提到的优化选项仅支持 Blink 计划器。
-<span class="label label-danger">Attention</span> Currently, the streaming
aggregations optimization are only supported for [unbounded-aggregations]({{
site.baseurl }}/dev/table/sql/queries.html#aggregations). Optimizations for
[window aggregations]({{ site.baseurl
}}/dev/table/sql/queries.html#group-windows) will be supported in the future.
+<span class="label label-danger">注意</span> 目前，流聚合优化仅支持 [无界聚合]({{ site.baseurl
}}/zh/dev/table/sql/queries.html#aggregations)。[窗口聚合]({{ site.baseurl
}}/zh/dev/table/sql/queries.html#group-windows) 优化将在未来支持。
* This will be replaced by the TOC
{:toc}
-By default, the unbounded aggregation operator processes input records one by
one, i.e., (1) read accumulator from state, (2) accumulate/retract record to
accumulator, (3) write accumulator back to state, (4) the next record will do
the process again from (1). This processing pattern may increase the overhead
of StateBackend (especially for RocksDB StateBackend).
-Besides, data skew which is very common in production will worsen the problem
and make it easy for the jobs to be under backpressure situations.
+默认情况下，无界聚合算子是一个一个的处理输入的记录，也就是说，（1）从状态读取累加器，（2）累积/撤回记录至累积器，（3）将累加器写回状态，（4）下一条记录将再次从（1）开始处理。
这种处理模式可能会增加 StateBackend 开销（尤其是对于 RocksDB
StateBackend）。此外，生产中非常常见的数据倾斜会使这个问题恶化，并使 job 容易承受反压的情况。
-## MiniBatch Aggregation
+<a name="minibatch-aggregation"></a>
Review comment:
Do you mean the line 39? It's for the anchor.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
