You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: data-explorer/kusto/management/data-export/create-alter-continuous.md
+7-3Lines changed: 7 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: .create or alter continuous-export
3
3
description: This article describes how to create or alter continuous data export.
4
4
ms.reviewer: yifats
5
5
ms.topic: reference
6
-
ms.date: 07/30/2025
6
+
ms.date: 08/18/2025
7
7
---
8
8
# .create or alter continuous-export
9
9
@@ -45,7 +45,9 @@ You must have at least [Database Admin](../../access-control/role-based-access-c
45
45
|`intervalBetweenRuns`|`Timespan`| The time span between continuous export executions. Must be greater than 1 minute. |
46
46
|`forcedLatency`|`Timespan`| An optional period of time to limit the query to records ingested before a specified period relative to the current time. This property is useful if, for example, the query performs some aggregations or joins, and you want to make sure all relevant records have been ingested before running the export. |
47
47
|`sizeLimit`|`long`| The size limit in bytes of a single storage artifact written before compression. Valid range: 100 MB (default) to 1 GB. |
48
-
|`distributed`|`bool`| Disable or enable distributed export. Setting to false is equivalent to `single` distribution hint. Default is true. |
48
+
|`distributed`|`bool`| Disable or enable distributed export. Setting to false is equivalent to `single` distribution hint. Default is `true`. |
49
+
|`distribution`|`string`| Distribution hint (`single`, `per_node`, `per_shard`). See more details in [Distribution settings](export-data-to-an-external-table.md#distribution-settings). Default is `per_node`|
50
+
|`distributionKind`|`string`| Optionally switches to uniform distribution when the external table is partitioned by string partition. Valid values are `uniform` or `default`. See more details in [Distribution settings](export-data-to-an-external-table.md#distribution-settings)|
49
51
|`parquetRowGroupSize`|`int`| Relevant only when data format is Parquet. Controls the row group size in the exported files. Default row group size is 100,000 records. |
50
52
|`managedIdentity`|`string`| The managed identity for which the continuous export job runs. The managed identity can be an object ID, or the `system` reserved word. For more information, see [Use a managed identity to run a continuous export job](continuous-export-with-managed-identity.md#use-a-managed-identity-to-run-a-continuous-export-job). |
51
53
|`isDisabled`|`bool`| Disable or enable the continuous export. Default is false. |
@@ -58,7 +60,9 @@ You must have at least [Database Admin](../../access-control/role-based-access-c
58
60
|`intervalBetweenRuns`|`Timespan`| The time span between continuous export executions. Must be greater than 1 minute. |
59
61
|`forcedLatency`|`Timespan`| An optional period of time to limit the query to records ingested before a specified period relative to the current time. This property is useful if, for example, the query performs some aggregations or joins, and you want to make sure all relevant records have been ingested before running the export. |
60
62
|`sizeLimit`|`long`| The size limit in bytes of a single storage artifact written before compression. Valid range: 100 MB (default) to 1 GB. |
61
-
|`distributed`|`bool`| Disable or enable distributed export. Setting to false is equivalent to `single` distribution hint. Default is true. |
63
+
|`distributed`|`bool`| Disable or enable distributed export. Setting to false is equivalent to `single` distribution hint. Default is `true`. |
64
+
|`distribution`|`string`| Distribution hint (`single`, `per_node`, `per_shard`). See more details in [Distribution settings](export-data-to-an-external-table.md#distribution-settings). Default is `per_node`|
65
+
|`distributionKind`|`string`| Optionally switches to uniform distribution when the external table is partitioned by string partition. Valid values are `uniform` or `default`. See more details in [Distribution settings](export-data-to-an-external-table.md#distribution-settings)|
62
66
|`parquetRowGroupSize`|`int`| Relevant only when data format is Parquet. Controls the row group size in the exported files. Default row group size is 100,000 records. |
63
67
|`isDisabled`|`bool`| Disable or enable the continuous export. Default is false. |
Copy file name to clipboardExpand all lines: data-explorer/kusto/management/materialized-views/materialized-view-create.md
+6-8Lines changed: 6 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: Create materialized view
3
3
description: This article describes how to create materialized views.
4
4
ms.reviewer: yifats
5
5
ms.topic: reference
6
-
ms.date: 02/11/2025
6
+
ms.date: 08/18/2025
7
7
---
8
8
9
9
# .create materialized-view
@@ -99,12 +99,10 @@ The lookback period is always relative to a `datetime` column in the materialize
99
99
***Default:** Relative to the record's [ingestion_time()](../../query/ingestion-time-function.md) in the source table. Records are deduplicated only against records which are ingested to the source table after a lookback period relative to the current records. This kind of lookback is valid only for `arg_max`, `arg_min`, or `take_any` materialized views, and only for views that preserve ingestion time. For more information, see [Materialized views limitations and known issues](materialized-views-limitations.md).
100
100
You can configure the default option by setting the `lookback` property without the `lookback_column` property.
101
101
102
-
***lookback_column (preview):** Relative to a `datetime` column in the materialized view. The lookback is explicitly specified in the materialized view definition, using the `lookback_column` property. For more information, see [Known limitations](#known-limitations). You can configure the lookback column option by setting both the `lookback` and the `lookback_column` properties.
103
-
104
-
#### Known limitations
105
-
106
-
* Once a `lookback_column` is defined, you can't change its value.
107
-
* Using a `lookback_column` can lead to duplicates if the column has `datetime(null)` values. In such cases, for a given combination of group-by keys, the view might end up with one record having a `datetime(null)` value and another with a non-null value.
102
+
***lookback_column:** Relative to a `datetime` column in the materialized view. The lookback is explicitly specified in the materialized view definition, using the `lookback_column` property. You can configure the lookback column option by setting both the `lookback` and the `lookback_column` properties.
103
+
* There is no need to define a `lookback_column` on a `datetime` column, which is one of the group-by keys of the materialized view aggregation. A `lookback_column` is only helpful if it references another `datetime` column, which is not part of group-by keys.
104
+
* Once a `lookback_column` is defined, you can't change its value.
105
+
* Using a `lookback_column` can lead to duplicates if the column has `datetime(null)` values. In such cases, for a given combination of group-by keys, the view might end up with one record having a `datetime(null)` value and another with a non-null value.
108
106
109
107
### Create materialized view over materialized view
110
108
@@ -309,7 +307,7 @@ The following aggregation functions are supported:
309
307
>
310
308
> If such late arriving records aren't expected, we recommend that in the materialized view query. Either filter these records out or normalize their timestamp values to the current time.
311
309
312
-
***Define a lookback period**: If applicable to your scenario, adding a `lookback` property can significantly improve query performance. For details, see [Supported properties](#supported-properties).
310
+
***Define a lookback period**: If applicable to your scenario, adding a `lookback` property can significantly improve query performance. For details, see [Lookback period](#lookback-period).
313
311
314
312
***Add columns frequently used for filtering as group-by keys**: Materialized view queries are optimized when they're filtered by one of the materialized view's group-by keys. If you know that your query pattern will often filter by a column that's immutable according to a unique entity in the materialized view, include it in the materialized view's group-by keys.
0 commit comments