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/create-function.md
+10-9Lines changed: 10 additions & 9 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 function command
3
3
description: Learn how to use the `.create function` command to create a stored function.
4
4
ms.reviewer: orspodek
5
5
ms.topic: reference
6
-
ms.date: 08/11/2024
6
+
ms.date: 12/19/2024
7
7
---
8
8
# .create function command
9
9
@@ -71,7 +71,7 @@ You must have at least [Database User](../access-control/role-based-access-contr
71
71
72
72
## Examples
73
73
74
-
### Simple demo function
74
+
### Simple function
75
75
76
76
The following example creates the `MyFunction1` function with a description (`docstring`), a folder named `Demo`, and defines the function.
77
77
@@ -86,17 +86,18 @@ MyFunction1()
86
86
|---|---|---|---|---|
87
87
|MyFunction1|()|{StormEvents | take 100}|Demo|Simple demo function|
88
88
89
-
### Demo function with parameter
89
+
### Function with a parameter
90
90
91
-
The following example creates the *MyFunction2* function with a description (`docstring`), folder named `Demo`, and defines the `MyLimit` parameter.
91
+
The following example creates the `MyFunction2` function with a description (`docstring`), folder named `Demo`, and defines the `Mytimestamp` parameter.
92
92
93
93
```kusto
94
-
.create function
95
-
with (docstring = 'Demo function with parameter', folder='Demo')
96
-
MyFunction2(myLimit: long)
97
-
{StormEvents | take myLimit}
94
+
.create function with (docstring = "Demo function with date parameter",folder = "Demo")
95
+
MyFunction2(Mytimestamp:datetime) {
96
+
StormEvents
97
+
| where EndTime <= Mytimestamp
98
+
}
98
99
```
99
100
100
101
|Name|Parameters|Body|Folder|DocString|
101
102
|---|---|---|---|---|
102
-
|MyFunction2|(myLimit:long)|{StormEvents |take myLimit}|Demo|Demo function with parameter|
103
+
|MyFunction2|(Mytimestamp:datetime)|{StormEvents |where EndTime <= Mytimestamp}|Demo|Demo function with date parameter|
Returns all failures logged as part of the continuous export. To view only a specific time range, filter the results by the **Timestamp** column.
12
+
Returns all failures logged as part of the continuous export within the past 14 days. To view only a specific time range, filter the results by the **Timestamp** column.
13
13
14
14
::: moniker range="azure-data-explorer"
15
15
The command doesn't return any results if executed on a [follower database](/azure/data-explorer/follower), it must be executed against the leader database.
Copy file name to clipboardExpand all lines: data-explorer/kusto/management/mappings.md
+58-1Lines changed: 58 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ Ingestion mappings are used during ingestion to map incoming data to columns ins
14
14
15
15
Data Explorer supports different types of mappings, both row-oriented (CSV, JSON, AVRO and W3CLOGFILE), and column-oriented (Parquet and ORC).
16
16
17
-
Ingestion mappings can be [precreated](create-ingestion-mapping-command.md) and can be referenced from the ingest command using `ingestionMappingReference` parameters. Ingestion is possible without specifying a mapping. For more information, see [identity mapping](#identity-mapping).
17
+
Ingestion mappings can be defined in the ingest command, or can be [precreated](create-ingestion-mapping-command.md) and referenced from the ingest command using `ingestionMappingReference` parameters. Ingestion is possible without specifying a mapping. For more information, see [identity mapping](#identity-mapping).
18
18
19
19
Each element in the mapping list is constructed from three fields:
20
20
@@ -47,6 +47,63 @@ The following table defines mapping types to be used when ingesting or querying
The following example shows ingestion where the mapping is defined in the ingest command. The command ingests a JSON file from a URL into the `RawEvents` table. The mapping specifies the path to each field in the JSON file.
62
+
63
+
````kusto
64
+
.ingest into table RawEvents ('https://kustosamplefiles.blob.core.windows.net/jsonsamplefiles/simple.json')
Ingest the JSON file using the `RawEventMapping` ingestion mapping reference with the following command:
98
+
99
+
```kusto
100
+
.ingest into table RawEvents ('https://kustosamplefiles.blob.core.windows.net/jsonsamplefiles/simple.json')
101
+
with (
102
+
format="json",
103
+
ingestionMappingReference="RawEventMapping"
104
+
)
105
+
```
106
+
50
107
## Identity mapping
51
108
52
109
Ingestion is possible without specifying `ingestionMapping` or `ingestionMappingReference` properties. The data is mapped using an identity data mapping derived from the table's schema. The table schema remains the same. `format` property should be specified. See [ingestion formats](../ingestion-supported-formats.md).
Copy file name to clipboardExpand all lines: data-explorer/kusto/management/request-rate-limit-policy.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -65,7 +65,7 @@ A request rate limit of kind `ResourceUtilization` includes the following proper
65
65
|--|--|--|--|
66
66
| ResourceKind |`ResourceKind`| The resource to limit.</br></br>When `ResourceKind` is `TotalCpuSeconds`, the limit is enforced based on post-execution reports of CPU utilization of completed requests. Requests that report utilization of 0.005 seconds of CPU or lower aren't counted. The limit (`MaxUtilization`) represents the total CPU seconds that can be consumed by requests within a specified time window (`TimeWindow`). For example, a user running ad-hoc queries may have a limit of 1000 CPU seconds per hour. If this limit is exceeded, subsequent queries will be throttled, even if started concurrently, as the cumulative CPU seconds have surpassed the defined limit within the sliding window period. |`RequestCount`, `TotalCpuSeconds`|
67
67
| MaxUtilization |`long`| The maximum of the resource that can be utilized. | RequestCount: [`1`, `16777215`]; TotalCpuSeconds: [`1`, `828000`]|
68
-
| TimeWindow |`timespan`| The sliding time window during which the limit is applied. |[`00:01:00`, `1.00:00:00`]|
68
+
| TimeWindow |`timespan`| The sliding time window during which the limit is applied. |[`00:00:01`, `01:00:00`]|
69
69
70
70
When a request exceeds the limit on resources utilization:
|*G*|`string`|:heavy_check_mark:| The input graph source. |
26
26
|*Pattern*|`string`|:heavy_check_mark:| One or more comma delimited sequences of graph node elements connected by graph edge elements using graph notations. See [Graph pattern notation](#graph-pattern-notation). |
27
-
|*Constraints*|`string`|:heavy_check_mark:| A Boolean expression composed of properties of named variables in the *Pattern*. Each graph element (node/edge) has a set of properties that were attached to it during the graph construction. The constraints define which elements (nodes and edges) are matched by the pattern. A property is referenced by the variable name followed by a dot (`.`) and the property name. |
28
-
|*Expression*|`string`|| The `project` clause converts each pattern to a row in a tabular result. The project expression(s) have to be scalar and reference properties of named variables defined in the *Pattern*. A property is referenced by the variable name followed by a dot (`.`) and the attribute name. |
27
+
|*Constraints*|`string`|| A Boolean expression composed of properties of named variables in the *Pattern*. Each graph element (node/edge) has a set of properties that were attached to it during the graph construction. The constraints define which elements (nodes and edges) are matched by the pattern. A property is referenced by the variable name followed by a dot (`.`) and the property name. |
28
+
|*Expression*|`string`|:heavy_check_mark:| The `project` clause converts each pattern to a row in a tabular result. The project expression(s) have to be scalar and reference properties of named variables defined in the *Pattern*. A property is referenced by the variable name followed by a dot (`.`) and the attribute name. |
29
29
|*CyclesOption*|`string`|| Controls whether cycles are matched in the *Pattern*, allowed values: `all`, `none`, `unique_edges`. If `all` is specified then all cycles are matched, if `none` is specified cycles aren't matched, if `unique_edges` (default) is specified, cycles are matched but only if the cycles don't include the same edge more than once. |
@@ -57,40 +57,31 @@ The following list explains the supported values for the *Strategy* parameter:
57
57
58
58
## How the auto strategy works
59
59
60
-
By default, the `auto` strategy determines where the cross-cluster join should be executed based on the following rules:
60
+
By default, the `auto` strategy determines where the cross-cluster join is executed based on the following rules:
61
61
62
-
* If one of the tables is hosted in the local cluster, then the join is performed on the local cluster.
63
-
* If both tables are hosted outside of the local cluster, then join is performed on the right cluster.
62
+
* If one of the tables is hosted in the local cluster, then the join is performed on the local cluster. For example, with the auto strategy, this query is executed on the local cluster:
64
63
65
-
Consider the following examples:
64
+
```kusto
65
+
T | ... | join (cluster("B").database("DB").T2 | ...) on Col1
66
+
```
66
67
67
-
```kusto
68
-
// Example 1
69
-
T | ... | join (cluster("B").database("DB").T2 | ...) on Col1
70
-
71
-
// Example 2
72
-
cluster("B").database("DB").T | ... | join (cluster("C").database("DB2").T2 | ...) on Col1
73
-
```
68
+
* If both tables are hosted outside of the local cluster, then join is performed on the right cluster. For example, assuming neither cluster is the local cluster, the join would be executed on the right cluster:
74
69
75
-
With the `auto` strategy, "Example 1" would be executed on the local cluster. In "Example 2", assuming neither cluster is the local cluster, the join would be executed on the right cluster.
70
+
```kusto
71
+
cluster("B").database("DB").T | ... | join (cluster("C").database("DB2").T2 | ...) on Col1
72
+
```
76
73
77
74
## Performance considerations
78
75
79
76
For optimal performance, we recommend running the query on the cluster that contains the largest table.
80
77
81
-
Let's consider the following examples again:
78
+
In the following example, if the dataset produced by `T | ...` is smaller than one produced by `cluster("B").database("DB").T2 | ...` then it would be more efficient to execute the join operation on cluster `B`, in this case the right cluster instead of on the local cluster.
82
79
83
80
```kusto
84
-
// Example 1
85
81
T | ... | join (cluster("B").database("DB").T2 | ...) on Col1
86
-
87
-
// Example 2
88
-
cluster("B").database("DB").T | ... | join (cluster("C").database("DB2").T2 | ...) on Col1
89
82
```
90
83
91
-
"Example 1" is set to run on the local cluster, but if the dataset produced by `T | ...` is smaller than one produced by `cluster("B").database("DB").T2 | ...` then it would be more efficient to execute the join operation on cluster `B`, in this case the right cluster, instead of on the local cluster.
92
-
93
-
The following query does this by using the `right` strategy. With the `right` strategy, the join operation is performed on the right cluster, even if left table is in the local cluster.
84
+
You can rewrite the query to use `hint.remote=right` to optimize the performance. In this way, the join operation is performed on the right cluster, even if left table is in the local cluster.
94
85
95
86
```kusto
96
87
T | ... | join hint.remote=right (cluster("B").database("DB").T2 | ...) on Col1
Copy file name to clipboardExpand all lines: data-explorer/kusto/query/join-fullouter.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,6 +31,8 @@ A `fullouter` join combines the effect of applying both left and right outer-joi
31
31
32
32
## Example
33
33
34
+
This example query combines rows from both tables X and Y, filling in missing values with NULL where there's no match in the other table. This allows you to see all possible combinations of keys from both tables.
35
+
34
36
:::moniker range="azure-data-explorer"
35
37
> [!div class="nextstepaction"]
36
38
> <ahref="https://dataexplorer.azure.com/clusters/help/databases/Samples?query=H4sIAAAAAAAAA8tJLVGIULBVSEksAcKknFQN79RKq%2BKSosy8dB2FsMSc0lRDq5z8vHRNrmguBSBQT1TXMdSBMJPUdYwQTGMoM1ldx4Qr1porB2h0JH6jjVCNBhpiaIAwxQiJbQxjpwBNNwAZH6FQo5CVn5mnkJ2Zl2KbVpqTk19akloEtDI%2FTwFoEwDuw%2F%2BW2gAAAA%3D%3D"target="_blank">Run the query</a>
0 commit comments