!1346 fix docs problem of star tree

Merge pull request !1346 from tushengxia/master

hetu-docs/en/preagg/join-queries.md

@@ -1,4 +1,4 @@
-##Join Query Support
+## Join Query Support
 StarTree Cube can help optimize aggregation over join queries as well. The optimizer looks for aggregation subtree pattern in the logical plan that typically looks like following.
 ```
   AggregationNode
@@ -17,13 +17,13 @@ StarTree Cube can help optimize aggregation over join queries as well. The optim
 If the query matches the pattern, the optimizer rewrites the logical plan by replacing the Fact TableScanNode with Cube TableScanNode. This is similar to the single 
 table rewrite.
 
-###Star Schema Support
+### Star Schema Support
 Join Query optimizer supports star schema only. A star schema is a data warehousing architecture model where one fact table references multiple dimension tables, which, when viewed as a diagram, 
 looks like a star with the fact table in the center and the dimension tables radiating from it. All kinds of joins are supported.
 
 ![star-schema](../images/star-schema.png "star schema")
 
-###Cube Management
+### Cube Management
 `Create Cube` can be still be used to define Cubes to optimize Join queries as well. The difficult part is identifying GROUP construct while building the Cubes. With single table 
 queries, the GROUP BY clause will contain columns only from same the table. But with join queries, especially star schema queries, the GROUP BY contain columns from Dimension tables and not the Fact table. 
 Let's analyze more with following query
@@ -48,7 +48,7 @@ GROUP = (lo_orderdate, lo_partkey, lo_suppkey));
 ```
 The optimizer parses the join conditions and uses those columns to identify the matching Cubes. The performance gain is realized if Cube size is smaller than fact table.
 
-###Limitations
+### Limitations
 * Only star schema is supported.
 * Count distinct not supported because Cube does not store actual dimension values.
 * Queries won't be optimized if Cubes are defined on both Fact and Dimension as the optimizer does not have capability to differentiate between two.
@@ -60,6 +60,6 @@ The optimizer parses the join conditions and uses those columns to identify the
    WHERE toYear(lo_orderdate) = 1993 AND lo_discount BETWEEN 1 AND 3 AND lo_quantity < 25;
 ```
 
-###Future
+### Future
 * Support for snowflake schema
 * Building a single cube over multiple tables

hetu-docs/en/preagg/overview.md

@@ -224,7 +224,7 @@ SHOW CUBES;
    as the process involves merging multiple Cube predicates into one. Only Cube predicates defined on Integer, Long and Date types can be merged properly. Support for Char, 
    String types still need to be implemented.
    
-##Performance Optimizations on Star Tree
+## Performance Optimizations on Star Tree
 1. Star Tree Query re-write optimization for same group by columns: If the group by columns of the cube and query matches, the query is 
 re-written internally to select the pre-aggregated data. If the group by columns does not matches, the additional aggregations are 
 internally applied on the re-written query.

hetu-docs/zh/index.md

@@ -64,7 +64,7 @@ headless: true
 
 - [Star Tree多维数据集](#)
     - [概述]({{< relref "./docs/preagg/overview.md" >}})
-    - [加入支持]({{< relref "./docs/preagg/join-queries.md" >}})
+    - [Join支持]({{< relref "./docs/preagg/join-queries.md" >}})
     - [语句]({{< relref "./docs/preagg/statements.md" >}})
 
 - [连接器]({{< relref "./docs/connector/_index.md" >}})

hetu-docs/zh/preagg/join-queries.md

@@ -1,4 +1,4 @@
-##Join查询的支持
+## Join查询的支持
 StarTree Cube也可以帮助优化对join查询的聚合。优化器在逻辑计划中寻找聚合子树结构，通常如下所示。
 ```
   AggregationNode
@@ -16,12 +16,12 @@ StarTree Cube也可以帮助优化对join查询的聚合。优化器在逻辑计
 
 如果确认查询与结构匹配，优化器会通过将Fact TableScanNode替换为Cube TableScanNode来重写逻辑计划。这类似于单表重写。
 
-###Star架构的支持
+### Star架构的支持
 Join查询优化器仅支持Star架构。Star架构是一种数据仓库架构模型，其中一个事实表引用多个维度表，从图表上看，它看起来像一个星形，事实表位于中心，维度表从它向外辐射。支持各种连接。
 
 ![star-schema](../images/star-schema.png "star schema")
 
-###Cube管理
+### Cube管理
 `Create Cube`仍可用于定义Cubes以优化Join查询。困难的部分是在构建多维数据集时识别GROUP构造。对于单表查询，GROUP BY子句将只包含来自同一个表的列。但是对于连接查询，尤其是Star架构查询，GROUP BY包含来自Dimension表而不是Fact表的列。
 让我们通过以下查询进行更多分析。
 ```sql
@@ -43,7 +43,7 @@ GROUP = (lo_orderdate, lo_partkey, lo_suppkey));
 ```
 优化器解析join条件并使用这些列来识别匹配的Cubes。如果Cube大小小于事实表，则可以实现性能提升。
 
-###限制
+### 限制
 * 仅支持Star架构。
 * 不支持count distinct，因为Cube不存储实际的维度值。
 * 如果在Fact和Dimension上都定义了Cube，则不会优化查询，因为优化器无法区分两者。
@@ -55,6 +55,6 @@ GROUP = (lo_orderdate, lo_partkey, lo_suppkey));
    WHERE toYear(lo_orderdate) = 1993 AND lo_discount BETWEEN 1 AND 3 AND lo_quantity < 25;
 ```
 
-###未来
+### 未来
 * 支持Snowflake架构
 * 在多个表上构建单个Cube

hetu-docs/zh/preagg/overview.md

@@ -222,6 +222,6 @@ SHOW CUBES;
    但是这种实现仍然存在局限性，因为该过程涉及将多个Cube谓词合并为一个。
    只有定义在Integer、Long和Date类型上的Cube谓词才能正确合并。 对Char、String类型的支持仍需实现。
    
-##Star Tree上的性能优化
+## Star Tree上的性能优化
 1. 对同一个group by列的星型查询重写优化：如果查询语句与Cube组匹配，则会改写查询计划将聚合运算结果重定向到Cube结果，否则将添加其他聚合结果内部应用于重写语句。
 2. 平均聚合函数的star tree表扫描优化：如果查询语句与group by列的Cube匹配，则会改写查询计划将聚合运算结果重定向到Cube的预聚合列的平均值结果，否则语句将在内部重写，以选择star tree预聚合Sum和Count结果，随后计算平均值。