GitHubContribute in GitHub: オンラインでの編集

釧路照会言語 (KQL) の概要

クシト照会言語は、データを探索し、パターンを検出し、異常や異常値を特定し、統計モデリングを作成するための強力なツールです。

草の木の照会とは何ですか?

クサット照会は、データを処理して結果を返すための読み取り専用要求です。 要求は、読み取り、作成、および自動化が容易なデータ・フロー・モデルを使用して、プレーン・テキストで記述されます。 クシト照会は、1 つ以上の照会ステートメントで構成されます。

照会ステートメントとは何ですか?

ユーザー照会ステートメントには 2 種類あります。

最も一般的な種類の照会ステートメントは、表形式の ステートメントです。これは、入力と出力の両方が表または表形式のデータ・セットで構成されることを意味します。 表形式のステートメントには、ゼロ個以上の 演算子が含まれています。各演算子は表形式の入力で始まり、表形式の出力を返します。 オペレーターは、 | (パイプ) で順序付けされます。 あるオペレーターから次のオペレーターへのデータ・フロー、またはパイプ接続されているデータ・フロー。 データは、各ステップでフィルタリングまたは操作され、次のステップに送られます。

これはファネルのようなもので、データ・テーブル全体から開始します。 データが別のオペレーターを通過するたびに、フィルターに掛けられるか、再配置されるか、または要約されます。 あるオペレーターから別のオペレーターへの情報のパイプは順次であるため、照会演算子の順序は重要であり、結果とパフォーマンスの両方に影響を与える可能性があります。 ファネルの末尾には、詳細化された出力が表示されます。

照会の例を見てみましょう。 KQL では、表名、表名、演算子、関数などのすべてについて大/小文字が区別されることに注意してください。

events_all
    | project original_time, user_id
    | where original_time > ago(5m) and user_id contains "user"
    | count

結果

数
28

この照会には、単一の表形式の式ステートメントがあります。 このステートメントは、 events_allという表への参照で始まります。 この単純なステートメントは、すべてのデータを常に、制約なしでフェッチすることを意味します。 非常に役立ちますが、非常にコストがかかるため、常に追加の演算子を使用して制約を受ける必要があります。

events_all

2 番目のステートメントは、 project 演算子を適用して、関心のある列のみを指定します。 events_allの場合、400 以上の列があり、この照会を完了するために必要なのは 2 列のみです。これにより、他の列を含めると、まったくメリットのない大きなコストが発生します。 常にプロジェクト・ステートメントを含める。

| project original_time, user_id

3 番目のステートメントは、 where を適用して、述部のリストを指定することによって射影のデータを制約します。 以下では、過去 5 分間にデータ・ソースによって生成されたレコードのみが必要であること、および user_id に「user」という文字が含まれていることを示しています。

| where original_time > ago(5m) and user_id contains "user"

この照会は、論理 and ステートメントを 2 行に分割するために作成することもできます。 これは分かりやすくするために役立ち、KQL の非常に反復的な性質の強さに合わせて機能します。 複数の where 節を利用する場合の考慮事項の 1 つは、暗黙の and ステートメントです。 これら 2 つの where の例は同じです。

| where original_time > ago(5m) 
| where user_id contains "user"

最後のステートメントは countを適用します。 これにより、where 節から一致するすべてのレコードが取得され、単純な集約が実行されます。 出力は、単一の long 値を持つ表です。

| count

数
28