!1183 Hetu-Docs Changes: Preagg Chinese Translation Document Additions

Merge pull request !1183 from Daniel Zhang/preagg_doc_changes
2021-10-14 18:44:48 +00:00 · 2021-10-14 18:44:48 +00:00 · a215311e66
parent 37ec5ffdd6 2b533be3ba
commit a215311e66
7 changed files with 426 additions and 29 deletions
--- a/hetu-docs/en/index.md
+++ b/hetu-docs/en/index.md
@ -158,8 +158,6 @@ headless: true
    - [GRANT ROLES]({{< relref "./docs/sql/grant-roles.md" >}})
    - [INSERT]({{< relref "./docs/sql/insert.md" >}})
    - [INSERT OVERWRITE]({{< relref "./docs/sql/insert-overwrite.md" >}})
-    - [INSERT CUBE]({{< relref "./docs/sql/insert-cube.md" >}})
-    - [INSERT OVERWRITE CUBE]({{< relref "./docs/sql/insert-overwrite-cube.md" >}})
    - [JMX]({{< relref "./docs/sql/jmx.md" >}})
    - [PREPARE]({{< relref "./docs/sql/prepare.md" >}})
    - [RESET SESSION]({{< relref "./docs/sql/reset-session.md" >}})
@ -174,7 +172,6 @@ headless: true
    - [SHOW COLUMNS]({{< relref "./docs/sql/show-columns.md" >}})
    - [SHOW CREATE TABLE]({{< relref "./docs/sql/show-create-table.md" >}})
    - [SHOW CREATE VIEW]({{< relref "./docs/sql/show-create-view.md" >}})
-    - [SHOW CUBES]({{< relref "./docs/sql/show-cubes.md" >}})
    - [SHOW FUNCTIONS]({{< relref "./docs/sql/show-functions.md" >}})
    - [SHOW EXTERNAL FUNCTION]({{< relref "./docs/sql/show-external-function.md" >}})
    - [SHOW GRANTS]({{< relref "./docs/sql/show-grants.md" >}})
--- a/hetu-docs/en/preagg/overview.md
+++ b/hetu-docs/en/preagg/overview.md
@ -37,7 +37,7 @@ The following picture depicts the change in the logical plan after the optimizat
 ![img](../images/cube-logical-plan-optimizer.png)

 ## Recommended Usage
-1. Cubes are mose useful for iceberg queries that takes huge input and produces small input
+1. Cubes are most useful for iceberg queries that takes huge input and produces small input.
 2. Query performance is best when size of the Cube is less that on the actual table on which Cube was built.
 3. Cubes need to be rebuilt if the source table is updated. 

@ -47,7 +47,7 @@ operation on the update is considered as a change in the existing data even if o
 can't be differentiated, Cubes can't be used as it might result in incorrect result. We are working on a solution to overcome this limitation.

 ## Supported Connectors
-The following are supported Connectors for storing a cube
+The following are supported Connectors for storing a Cube
 1. Hive
 2. Memory
 3. Clickhouse
@ -58,7 +58,7 @@ The following are supported Connectors for storing a cube

   2.1. Overcome the limitation of Creating Cube for larger dataset.

-   2.2. Update cube if source table has been updated.
+   2.2. Update Cube if source table has been updated.

 ## Enabling and Disabling StarTree Cube
 To enable:
@ -73,13 +73,13 @@ SET SESSION enable_star_tree_index=false;
 ## Configuration Properties
 | Property Name                                     | Default Value       | Required| Description|
 |---------------------------------------------------|---------------------|---------|--------------|
-| optimizer.enable-star-tree-index                  | false               | No      | Enables StarTree Cube|
-| cube.metadata-cache-size                          | 50                  | No      | The maximum number of metadata for StarTree Cubes that could be loaded into cache before eviction happens|
+| optimizer.enable-star-tree-index                  | false               | No      | Enables StarTree Cube |
+| cube.metadata-cache-size                          | 50                  | No      | The maximum number of metadata for StarTree Cubes that could be loaded into cache before eviction happens |
 | cube.metadata-cache-ttl                           | 1h                  | No      | The maximum time to live of StarTree Cubes that are be loaded into cache before eviction happens |

 ## Dependencies

-StarTree Cube relies on Hetu metastore to store the Cube related metadata.
+StarTree Cube relies on Hetu Metastore to store the Cube related metadata.
 Please check [Hetu Metastore](../admin/meta-store.md) for more information.

 ## Examples
@ -118,11 +118,11 @@ SELECT nationkey, avg(nationkey), max(regionkey) FROM nation WHERE nationkey >=
 Since the data inserted into the Cube was for `nationkey >= 5`, only queries matching this condition will utilize the Cube.
 Queries not matching the condition would continue to work but won't use the Cube.

-## Building Cube for Large dataset
+## Building Cube for Large Dataset
 One of the limitations with the current implementation is that Cube cannot be built for a larger dataset at once. This is due to the cluster memory limitation.
 Processing large number of rows requires more memory than cluster is configured with. This results in query failing with message **Query exceeded per-node user memory
-limit**. To overcome this issue, **INSERT INTO CUBE** sql support was added. The user has ability to build a Cube for larger data by executing multiple
-insert into cube statements. The insert statement accepts a where clause, and it can be used to limit the number of processed and inserted into Cube.
+limit**. To overcome this issue, **INSERT INTO CUBE** SQL support was added. The user has ability to build a Cube for larger data by executing multiple
+insert into Cube statements. The insert statement accepts a where clause, and it can be used to limit the number of processed and inserted into Cube.

 This section explains the steps to build a Cube for larger dataset.

@ -146,7 +146,7 @@ INSERT INTO CUBE store_sales_cube WHERE ss_sold_date_sk BETWEEN 2451911 AND 2422
 ```

 ### Solution 1)
-To overcome this issue, multiple insert statements can be used into process rows and insert into cube and the number of rows can be limited by using where clause;
+To overcome this issue, multiple insert statements can be used to process rows and insert into Cube and the number of rows can be limited by using where clause;

 ```sql
 INSERT INTO CUBE store_sales_cube WHERE ss_sold_date_sk BETWEEN 2451911 AND 2452010;
@ -157,8 +157,8 @@ INSERT INTO CUBE store_sales_cube WHERE ss_sold_date_sk BETWEEN 2452211 AND 2452

 ### Solution 2)
 CLI has been modified to support creating Cubes for larger dataset and without need for multiple insert statements. CLI internally handles this process.
-Once the user runs create cube statement with where clause, the CLI takes care of creating the cube as well as inserting the data into it. This process improves the user experience and
-improves the memory footprint based on the cluster memory limits. CLI internally parses the converts the statement into one create cube statement followed by 
+Once the user runs create Cube statement with where clause, the CLI takes care of creating the Cube as well as inserting the data into it. This process improves the user experience and
+improves the memory footprint based on the cluster memory limits. CLI internally parses the converts the statement into one create Cube statement followed by 
 one or more insert statements. This change is only works if user executes the command from CLI and not via any other means i.e. JDBC, etc...

 ```sql
@ -183,13 +183,13 @@ SHOW CUBES;
   `Integer, TinyInt, SmallInt, BigInt, Date`
    
   For other data types, it is difficult to identify if two predicates are continuous therefore they cannot be merged together. And because of this issue, there is 
-   possibility that particular cube may not be used during query optimization even if the cube has all the required data. For example,
+   possibility that particular Cube may not be used during query optimization even if the Cube has all the required data. For example,

 ```sql
   INSERT INTO CUBE store_sales_cube WHERE store_id BETWEEN 'A01' AND 'A10';
   INSERT INTO CUBE store_sales_cube WHERE store_id BETWEEN 'A11' AND 'A20';
 ```
-   Here these two predicates cannot be merged into store_id BETWEEN 'A01' AND 'A20'; So the cube won't be used 
+   Here these two predicates cannot be merged into store_id BETWEEN 'A01' AND 'A20'; So the Cube won't be used 
   for queries that are spanning over two the predicates;

 ```sql
@ -199,23 +199,23 @@ SHOW CUBES;

 ```sql   
   INSERT INTO CUBE store_sales_cube WHERE ss_sold_date_sk > 2451911; 
-```   
-   The predicate is rewriten as ss_sold_date_sk >= 2451912 to be prepare for merging continous predicates. 
+```
+   The predicate is rewritten as ss_sold_date_sk >= 2451912 to be prepare for merging continous predicates. 
   Since the predicate is rewritten, they query using ss_sold_date_sk > 2451911 predicate will not match with Cube predicate so Cube won't be used to 
   optimize the query. The same is applicable for predicates with <= operator. ie. ss_sold_date_sk <= 2451911 is rewritten as ss_sold_date_sk < 2451912

 ```sql   
   SELECT ss_sold_date_sk, .... FROM hive.tpcds_sf1.store_sales WHERE ss_sold_date_sk > 2451911
 ```   
-3. Only Single column predicates can be merged. 
+3. Only single column predicates can be merged. 

 ## Open issues and Limitations
 1. StarTree Cube is only effective when the group by cardinality is considerably fewer than the number of rows in source table.
 2. A significant amount of user effort required in maintaining Cubes for large datasets.
-3. Only incremental insert into cube is supported. Cannot delete specific rows from Cube.
+3. Only incremental insert into Cube is supported. Cannot delete specific rows from Cube.
 4. Cubes created on a transaction table may expire automatically even if the source table has not been updated. This is due to the compaction policy which
   merges delta files into single large ORC file which in turn changes the last modified of time of the table. Cube status is determined by comparing last modified
-   timestamp of table when cube was created with the last modified time of the table when queries are executed.
-5. Openlookeng CLI has been modified to ease the process of creating Cubes for larger datasets. But still there are limitations with this implementation
-   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, 
+   timestamp of table when Cube was created with the last modified time of the table when queries are executed.
+5. OpenLooKeng CLI has been modified to ease the process of creating Cubes for larger datasets. But still there are limitations with this implementation
+   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.
--- a/hetu-docs/en/preagg/statements.md
+++ b/hetu-docs/en/preagg/statements.md
@ -44,7 +44,7 @@ Create a new partitioned Cube `orders_cube`:
      partitioned_by = ARRAY['orderdate']
    )

-Create a new Cube `orders_cube` with some source data filter
+Create a new Cube `orders_cube` with some source data filter:

    CREATE CUBE orders_cube ON orders WITH (
      AGGREGATIONS = ( SUM(totalprice), COUNT DISTINCT(orderid) ),
@ -52,7 +52,7 @@ Create a new Cube `orders_cube` with some source data filter
      FILTER = (orderdate BETWEEN 2512450 AND 2512460)
    )

-Create a new Cube `orders_cube` with some additional predicate on Cube columns
+Create a new Cube `orders_cube` with some additional predicate on Cube columns:

    CREATE CUBE orders_cube ON orders WITH (
      AGGREGATIONS = ( SUM(totalprice), COUNT DISTINCT(orderid) ),
@ -60,7 +60,7 @@ Create a new Cube `orders_cube` with some additional predicate on Cube columns
      FILTER = (orderdate BETWEEN 2512450 AND 2512460)
    ) WHERE orderstatus = 'PENDING';

-This is same as following
+This is same as following:
    
    CREATE CUBE orders_cube ON orders WITH (
      AGGREGATIONS = ( SUM(totalprice), COUNT DISTINCT(orderid) ),
@ -86,12 +86,12 @@ INSERT INTO CUBE cube_name [WHERE condition]
 ```

 ### Description
-`CREATE CUBE` statement creates Cube without any data. To insert data into Cube, use `INSERT INTO CUBE` sql.
+`CREATE CUBE` statement creates Cube without any data. To insert data into Cube, use `INSERT INTO CUBE` SQL.
 The `WHERE` clause is optional. If predicate is provided, only data matching the given predicate are processed from the source table and inserted into the Cube. 
 Otherwise, entire data from the source table is processed and inserted into Cube.

 ### Examples
-Insert data into the `orders_cube` Cube
+Insert data into the `orders_cube` Cube:

    INSERT INTO CUBE orders_cube WHERE orderdate > date '1999-01-01';
    INSERT INTO CUBE order_all_cube;
--- a/hetu-docs/zh/images/cube-logical-plan-optimizer.png
+++ b/hetu-docs/zh/images/cube-logical-plan-optimizer.png
--- a/hetu-docs/zh/index.md
+++ b/hetu-docs/zh/index.md
@ -62,6 +62,10 @@ headless: true
    - [HIndex语句]({{< relref "./docs/indexer/hindex-statements.md" >}})
    - [new-index]({{< relref "./docs/indexer/new-index.md" >}})

+- [Star Tree多维数据集](#)
+    - [概述] ({{< relref "./docs/preagg/overview.md" >}}>)
+    - [语句] ({{< relref "./docs/preagg/statements.md" >}})
+
 - [连接器]({{< relref "./docs/connector/_index.md" >}})
    - [CarbonData]({{< relref "./docs/connector/carbondata.md" >}})
    - [ClickHouse]({{< relref "./docs/connector/clickhouse.md" >}})
--- a/hetu-docs/zh/preagg/overview.md
+++ b/hetu-docs/zh/preagg/overview.md
@ -0,0 +1,221 @@
+# StarTree多维数据集
+## 介绍
+StarTree Cube，作为多维数据集，是存储为表格的物化预聚合结果。该技术旨在优化低延迟冰山查询。
+冰山查询是涉及**GROUP BY**和**HAVING**子句的SQL查询的一种特殊情况，其中答案集相对于扫描的数据大小而言较小。
+查询的特点是输入量大，输出量小。
+
+此技术允许用户在现有表上构建Cubes，其中包含旨在优化特定查询的聚合和维度。
+Cubes是汇总预聚合，与原始表相比，其维度和行数更少。
+较少的行数意味着花费在表扫描上的时间显着减少，从而减少查询延迟。
+如果查询是预聚合表的维度和度量的子集，
+那么Cube可以用来计算查询，而无需访问原始表。
+
+Cube有以下几个属性
+ - Cubes以表格格式存储
+ - 一般来说，可以为任何连接器中的任何表创建Cubes并存储在另一个连接器中
+ - 通过重写逻辑计划以使用Cube而不是原始表来减少查询延迟。
+
+## Cube的多维数据集优化器规则
+作为逻辑计划优化的一部分，Cube优化器规则使用Cubes分析和优化逻辑计划的聚合子树。
+该规则查找通常如下所示的聚合子树
+
+```
+AggregationNode
+|- ProjectNode[Optional]
+  |- ProjectNode[Optional]
+    |- FilterNode[Optional]
+      |- ProjectNode[Optional]
+        |- TableScanNode
+```
+
+规则通过子树解析，识别出与Cube元数据匹配的表名、聚合函数、where子句、group by子句
+识别任何可以帮助优化查询的Cube。在多个匹配的情况下，选择最近创建的Cube进行优化。如果找到任何匹配项，则整个
+使用Cube重写聚合子树。此优化器使用TupleDomain构造来匹配查询中提供的谓词是否可以被
+立方体。
+
+下图描绘了优化后逻辑计划的变化。
+
+![img](../images/cube-logical-plan-optimizer.png)
+
+## 推荐用法
+1. Cubes对于需要大量输入并产生少量输入的冰山查询最有用。
+2. 当Cube的大小小于构建Cube的实际表上的大小时，查询性能最佳。
+3. 如果源表更新，则需要重建Cubes。
+
+**注意：**
+如果在构建Cubes后更新源表，Cube优化器将忽略在表上创建的Cubes。原因是，任何
+即使在原始表中只插入了新行，对更新的操作也被视为对现有数据的更改。由于插入和更新
+不能区分，不能使用Cubes，因为它可能会导致不正确的结果。我们正在研究解决此限制的解决方案。
+
+## 支持的连接器
+以下是用于存储Cube的支持的连接器
+1. Hive
+2. Memory
+3. Clickhouse
+
+## 未来的工作
+1. 支持更多JDBC连接器
+2. 简化Cube管理
+
+   2.1. 克服为更大的数据集创建Cube的限制。
+
+   2.2. 如果源表已更新，则更新Cube。
+
+## 启用和禁用StarTree Cube
+启用：
+```sql 
+SET SESSION enable_star_tree_index=true;
+```
+禁用：
+```sql 
+SET SESSION enable_star_tree_index=false;
+```
+
+## 配置属性
+| 属性名称                                           | 默认值                | 是否必要 | 描述          |
+|---------------------------------------------------|---------------------|---------|--------------|
+| optimizer.enable-star-tree-index                  | false               | 否      | 启动StarTree Cube |
+| cube.metadata-cache-size                          | 50                  | 否      | 在驱逐发生之前可以加载到缓存中的 StarTree Cube 的最大元数据数 |
+| cube.metadata-cache-ttl                           | 1h                  | 否      | 在驱逐发生之前加载到缓存中的 StarTree Cube 的最大生存时间 |
+
+## 依赖关系
+
+StarTree Cube依赖于Hetu Metastore来存储Cube相关的元数据。
+请查看[Hetu Metastore](../admin/meta-store.md)以获取更多信息。
+
+## 例子
+
+创建StarTree Cube：
+```sql 
+CREATE CUBE nation_cube 
+ON nation 
+WITH (AGGREGATIONS=(count(*), count(distinct regionkey), avg(nationkey), max(regionkey)),
+GROUP=(nationkey),
+format='orc', partitioned_by=ARRAY['nationkey']);
+```
+接下来，将数据添加到Cube：
+```sql 
+INSERT INTO CUBE nation_cube WHERE nationkey >= 5;
+```
+使用WHERE子句创建StarTree Cube：
+请注意，以下查询仅通过CLI支持
+
+```sql 
+CREATE CUBE nation_cube 
+ON nation 
+WITH (AGGREGATIONS=(count(*), count(distinct regionkey), avg(nationkey), max(regionkey)),
+GROUP=(nationkey),
+format='orc', partitioned_by=ARRAY['nationkey'])
+WHERE nationkey >= 5;
+```
+
+当需要使用新的Cube时，只需使用包含在Cube中的聚合查询原始表：
+
+```sql 
+SELECT count(*) FROM nation WHERE nationkey >= 5 GROUP BY nationkey;
+SELECT nationkey, avg(nationkey), max(regionkey) FROM nation WHERE nationkey >= 5 GROUP BY nationkey;
+```
+
+由于插入Cube的数据是为`nationkey >= 5`，只有匹配此条件的查询才会使用Cube。
+不符合条件的查询将继续工作，但不会使用Cube。
+
+## 为大型数据集构建Cube
+当前实现的限制之一是不能一次为更大的数据集构建Cube。这是由于集群内存限制。
+处理大量行需要比集群配置更多的内存。这会导致查询失败并显示消息**Query exceeded per-node user memory limit**，也就是警告查询超出每节点用户内存限制。为了克服这个问题，**INSERT INTO CUBE** SQL支持被添加了。
+用户可以通过执行多个操作来为更大的数据构建一个Cube插入到Cube语句中。insert语句接受一个where子句，它可以用来限制处理和插入到Cube中的数量。
+
+本节介绍为更大的数据集构建Cube的步骤。
+
+让我们以TPCDS数据集和`store_sales`表为例。该表有10年的数据，
+用户想要构建2001年的Cube，由于集群内存限制，无法一次处理2001年的整个数据集。
+
+```sql
+CREATE CUBE store_sales_cube ON store_sales WITH (AGGREGATIONS = (sum(ss_net_paid), sum(ss_sales_price), sum(ss_quantity)), GROUP = (ss_sold_date_sk, ss_store_sk));
+
+SELECT min(d_date_sk) as year_start, max(d_date_sk) as year_end FROM date_dim WHERE d_year = 2001;
+ year_start | year_end 
+------------+----------
+    2451911 |  2452275 
+(1 row)
+```
+如果需要处理的行数很大并且查询内存超过为集群配置的限制，
+则以下查询可能会导致失败。
+
+```sql
+INSERT INTO CUBE store_sales_cube WHERE ss_sold_date_sk BETWEEN 2451911 AND 242275; 
+```
+
+### 解决方案1)
+为了克服这个问题，可以使用多个insert语句来处理行并插入cube中，并且可以使用where子句来限制行数；
+
+```sql
+INSERT INTO CUBE store_sales_cube WHERE ss_sold_date_sk BETWEEN 2451911 AND 2452010;
+INSERT INTO CUBE store_sales_cube WHERE ss_sold_date_sk >= 2452011 AND ss_sold_date_sk <= 2452110;
+INSERT INTO CUBE store_sales_cube WHERE ss_sold_date_sk BETWEEN 2452111 AND 2452210;
+INSERT INTO CUBE store_sales_cube WHERE ss_sold_date_sk BETWEEN 2452211 AND 2452275;
+```
+
+### 解决方案2)
+CLI已被修改以支持为更大的数据集创建Cubes，而不需要多个插入语句。CLI在内部处理这个过程。
+一旦用户运行带有where子句的create cube语句，CLI就会负责创建Cube并将数据插入其中。
+此过程改善了用户体验并改善了基于集群内存限制的内存占用。CLI在内部将转换语句解析为一个create Cube语句，然后是一个或多个insert语句。
+此更改仅在用户从CLI而非通过任何其他方式（例如JDBC等）执行命令时才有效。
+
+```sql
+CREATE CUBE store_sales_cube ON store_sales WITH (AGGREGATIONS = (sum(ss_net_paid), sum(ss_sales_price), sum(ss_quantity)), GROUP = (ss_sold_date_sk, ss_store_sk)) WHERE ss_sold_date_sk BETWEEN 2451911 AND 242275;
+```
+
+系统内部会重写所有连续的范围谓词并将其合并为单个谓词；
+
+```sql
+SHOW CUBES;
+
+           Cube Name             |         Table Name         | Status |         Dimensions          |                     Aggregations                      |                                     Where Clause                                     
+---------------------------------+----------------------------+--------+-----------------------------+-------------------------------------------------------+-------------------------------------------------------+------------------------------
+ hive.tpcds_sf1.store_sales_cube | hive.tpcds_sf1.store_sales | Active | ss_sold_date_sk,ss_store_sk | sum(ss_sales_price),sum(ss_net_paid),sum(ss_quantity) | (("ss_sold_date_sk" >= BIGINT '2451911') AND ("ss_sold_date_sk" < BIGINT '2452276')) 
+```
+
+**注意：**
+1. 系统将尝试将所有类型的Predicates重写为Range以查看它们是否可以合并在一起。
+   所有连续谓词将合并为单个范围谓词，其余谓词保持不变。
+
+   仅支持以下类型并且可以合并在一起。
+   `Integer, TinyInt, SmallInt, BigInt, Date`
+
+   对于其他数据类型，很难确定两个谓词是否连续，因此它们不能合并在一起。 
+   由于这个问题，即使Cube具有所有必需的数据，在查询优化期间也可能不会使用特定Cube。例如，
+
+```sql
+   INSERT INTO CUBE store_sales_cube WHERE store_id BETWEEN 'A01' AND 'A10';
+   INSERT INTO CUBE store_sales_cube WHERE store_id BETWEEN 'A11' AND 'A20';
+```
+   这里这两个谓词不能合并到store_id BETWEEN 'A01' AND 'A20'; 
+   因此，Cube不会用于跨越两个谓词的查询；
+
+```sql
+   SELECT ss_store_id, sum(ss_sales_price) WHERE ss_store_id BETWEEN 'A05' AND 'A15'; - Cube won't be used for optimizing this query. This is a limitation as of now.
+```
+   由于谓词重写，无法支持以下某些查询
+
+```sql   
+   INSERT INTO CUBE store_sales_cube WHERE ss_sold_date_sk > 2451911; 
+```
+   谓词重写为ss_sold_date_sk >= 2451912为合并连续谓词做准备。
+   由于谓词被重写，他们使用ss_sold_date_sk > 2451911谓词查询将与Cube谓词不匹配，因此不会使用Cube来优化查询。
+   这同样适用于带有<=运算符的谓词，例如，ss_sold_date_sk <= 2451911改写为ss_sold_date_sk < 2451912。
+
+```sql   
+   SELECT ss_sold_date_sk, .... FROM hive.tpcds_sf1.store_sales WHERE ss_sold_date_sk > 2451911
+```   
+3. 只能合并单列谓词。
+
+## 未解决的问题和限制
+1. StarTree Cube仅在按基数分组的数量远小于源表中的行数时有效。
+2. 维护大型数据集的Cubes需要大量的用户工作。
+3. 仅支持增量插入Cube。无法从Cube中删除特定行。
+4. 即使源表尚未更新，在事务表上创建的Cubes也可能会自动过期。
+   这是由于压缩策略将delta文件合并为单个大型ORC文件，这反过来又更改了表的最后修改时间。
+   Cube状态是通过比较创建Cube时表的最后修改时间戳与执行查询时表的最后修改时间来确定的。
+5. OpenLooKeng CLI已经过修改，以简化为更大的数据集创建Cubes的过程。 
+   但是这种实现仍然存在局限性，因为该过程涉及将多个Cube谓词合并为一个。
+   只有定义在Integer、Long和Date类型上的Cube谓词才能正确合并。 对Char、String类型的支持仍需实现。
--- a/hetu-docs/zh/preagg/statements.md
+++ b/hetu-docs/zh/preagg/statements.md
@ -0,0 +1,175 @@
+# 用法
+可以使用任何受支持的客户端管理Cubes，例如位于安装中`bin`目录下的hetu-cli。
+
+## CREATE CUBE
+### 概要
+
+``` sql
+CREATE CUBE [ IF NOT EXISTS ]
+cube_name ON table_name WITH (
+   AGGREGATIONS = ( expression [, ...] ),
+   GROUP = ( column_name [, ...])
+   [, FILTER = (expression)]
+   [, ( property_name = expression [, ...] ) ] 
+)
+[WHERE predicate]
+```
+### 描述
+使用指定的组和聚合创建一个新的空Cube。使用`INSERT INTO CUBE (see below)`来插入数据。
+
+如果Cube已经存在，可选的`IF NOT EXISTS`子句会导致错误被抑制。
+可选的`property_name`部分可用于在新创建的Cube上设置属性。
+
+要列出所有可用的表属性，请运行以下查询：
+
+    SELECT * FROM system.metadata.table_properties
+
+**注意：** 这些属性仅限于为其创建Cube的连接器。
+
+### 例子
+在`orders`上创建一个新的Cube`orders_cube`：
+
+    CREATE CUBE orders_cube ON orders WITH (
+      AGGREGATIONS = ( SUM(totalprice), AVG(totalprice) ),
+      GROUP = ( orderstatus, orderdate ),
+      format = 'ORC'
+    )
+
+创建一个新的分区Cube`orders_cube`：
+
+    CREATE CUBE orders_cube ON orders WITH (
+      AGGREGATIONS = ( SUM(totalprice), AVG(totalprice) ),
+      GROUP = ( orderstatus, orderdate ),
+      format = 'ORC',
+      partitioned_by = ARRAY['orderdate']
+    )
+
+使用一些源数据过滤器创建一个新的Cube`orders_cube`：
+
+    CREATE CUBE orders_cube ON orders WITH (
+      AGGREGATIONS = ( SUM(totalprice), COUNT DISTINCT(orderid) ),
+      GROUP = ( orderstatus ),
+      FILTER = (orderdate BETWEEN 2512450 AND 2512460)
+    )
+
+创建一个新的Cube`orders_cube`，并在Cube列上添加一些额外的谓词：
+
+    CREATE CUBE orders_cube ON orders WITH (
+      AGGREGATIONS = ( SUM(totalprice), COUNT DISTINCT(orderid) ),
+      GROUP = ( orderstatus ),
+      FILTER = (orderdate BETWEEN 2512450 AND 2512460)
+    ) WHERE orderstatus = 'PENDING';
+
+这与以下内容相同：
+    
+    CREATE CUBE orders_cube ON orders WITH (
+      AGGREGATIONS = ( SUM(totalprice), COUNT DISTINCT(orderid) ),
+      GROUP = ( orderstatus ),
+      FILTER = (orderdate BETWEEN 2512450 AND 2512460)
+    );
+    INSERT INTO CUBE orders_cube WHERE orderstatus = 'PENDING';
+
+`FILTER`属性可用于在构建Cube时从源表中过滤掉数据。
+在对源表应用`orderdate BETWEEN 2512450 AND 2512460`谓词后，Cube建立在数据上。过滤谓词中使用的列不得属于Cube。
+
+### 限制
+- 可以仅使用以下聚合函数创建Cubes。
+  换句话说，使用以下函数的查询只能使用Cubes进行优化。
+  **COUNT, COUNT DISTINCT, MIN, MAX, SUM, AVG**
+- 不同的连接器可能支持不同的数据类型和不同的表/列属性。
+
+## INSERT INTO CUBE
+
+### 概要
+``` sql
+INSERT INTO CUBE cube_name [WHERE condition]
+```
+
+### 描述
+`CREATE CUBE`语句创建没有任何数据的Cube。要将数据插入Cube，请使用`INSERT INTO CUBE`SQL。
+`WHERE`子句是可选的。如果提供了谓词，则只有与给定谓词匹配的数据才会从源表中处理并插入到Cube中。
+否则，源表中的整个数据将被处理并插入到Cube中。
+
+### 例子
+将数据插入`orders_cube`Cube:
+
+    INSERT INTO CUBE orders_cube WHERE orderdate > date '1999-01-01';
+    INSERT INTO CUBE order_all_cube;
+
+### 限制
+1. 对同一个Cube的后续插入需要使用相同的列集
+
+```sql
+   CREATE CUBE orders_cube ON orders WITH (AGGREGATIONS = (count(*)), GROUP = (orderdate));
+   
+   INSERT INTO CUBE orders_cube WHERE orderdate BETWEEN date '1999-01-01' AND date '1999-01-05';
+   
+   -- This statement would fail because its possible the Cube already contain rows matching the given predicate.
+   INSERT INTO CUBE orders_cube WHERE location = 'Canada';
+```
+**注意：** 这意味着在第一个插入中使用的列必须在第一个插入后的每个插入谓词中使用，以避免插入重复数据。
+
+## INSERT OVERWRITE CUBE
+
+### 概要
+``` sql
+INSERT OVERWRITE CUBE cube_name [WHERE condition]
+```
+
+### 描述
+类似于INSERT INTO CUBE语句，但使用此语句覆盖现有数据。
+谓词是可选的。
+
+### 例子
+根据条件插入数据到`orders_cube`Cube：
+
+    INSERT OVERWRITE CUBE orders_cube WHERE orderdate > date '1999-01-01';
+    INSERT OVERWRITE CUBE orders_cube;
+
+## SHOW CUBES
+
+### 概要
+```sql
+SHOW CUBES [ FOR table_name ];
+```
+
+### 描述
+`SHOW CUBES`列出所有立方体。添加可选的`table_name`仅列出该表的Cubes。
+
+### 例子
+
+显示所有Cubes:
+```sql
+    SHOW CUBES;
+```
+
+显示`orders`表的Cubes:
+
+```sql
+    SHOW CUBES FOR orders;
+```
+
+## DROP CUBE
+
+### 概要
+
+``` sql
+DROP CUBE  [ IF EXISTS ] cube_name
+```
+
+### 描述
+删除存在的Cube.
+
+如果Cube不存在，可选的`IF EXISTS`子句会抑制报错。
+
+### 例子
+
+删除Cube`orders_cube`:
+
+    DROP CUBE orders_cube
+
+如果存在，则删除Cube`orders_cube`：
+
+    DROP CUBE IF EXISTS orders_cube
+
+