メインコンテンツまでスキップ
メインコンテンツまでスキップ

クエリ実行の理解 - アナライザーを使用して

ClickHouseはクエリを非常に迅速に処理しますが、クエリの実行は単純なものではありません。SELECT クエリがどのように実行されるのかを理解してみましょう。これを示すために、ClickHouseのテーブルにデータを追加しましょう:

ClickHouseにデータが追加されたので、クエリを実行してその実行を理解したいと思います。クエリの実行は多くのステップに分解されます。クエリの実行の各ステップは、対応する EXPLAIN クエリを使用して分析およびトラブルシューティングすることができます。これらのステップは、以下のチャートに要約されています:

Explain query steps

クエリ実行中の各エンティティを見てみましょう。いくつかのクエリを実行し、それらを EXPLAIN ステートメントを使用して調べてみます。

パーサー

パーサーの目標は、クエリテキストをAST(抽象構文木)に変換することです。このステップは EXPLAIN AST を使用して可視化することができます:

出力は以下のように可視化された抽象構文木です:

AST output

各ノードには対応する子供があり、全体の木はクエリの構造を表しています。これはクエリを処理するための論理的な構造です。エンドユーザーの立場から見ると(クエリの実行に興味がない限り)、あまり役に立たないかもしれません。このツールは主に開発者によって使用されます。

アナライザー

現時点でClickHouseにはアナライザーの2つのアーキテクチャがあります。古いアーキテクチャを使用するには、enable_analyzer=0 を設定します。新しいアーキテクチャはデフォルトで有効になっています。ここでは新しいアーキテクチャのみを説明します。古いアーキテクチャは、新しいアナライザーが一般的に利用可能になり次第、非推奨となります。

注記

新しいアーキテクチャは、ClickHouseのパフォーマンスを改善するためのより良いフレームワークを提供するはずです。しかし、クエリ処理ステップの基本的なコンポーネントであるため、一部のクエリに悪影響を及ぼす可能性もあり、既知の非互換性もあります。クエリまたはユーザーのレベルで enable_analyzer 設定を変更することで、古いアナライザーに戻ることができます。

アナライザーはクエリ実行の重要なステップです。ASTをクエリツリーに変換します。ASTに対するクエリツリーの主な利点は、多くのコンポーネントが解決される点です。たとえば、どのテーブルから読み取るかやエイリアスも解決され、異なるデータ型が使用されていることが知られています。これらの利点により、アナライザーは最適化を適用できます。これらの最適化の方法は「パス」を通じて行われます。各パスは異なる最適化を探します。すべてのパスはこちらで見ることができます。次のクエリで確認しましょう:

二つの実行の間で、エイリアスとプロジェクションの解決を確認できます。

プランナー

プランナーはクエリツリーを取り、それからクエリプランを構築します。クエリツリーは、特定のクエリで何をするかを教え、クエリプランはそれをどのようにするかを示します。クエリプランの一部として追加の最適化が行われます。EXPLAIN PLAN または EXPLAIN を使用してクエリプランを表示できます(EXPLAINEXPLAIN PLAN を実行します)。

この出力は一部の情報を提供しますが、例えば、プロジェクションの上に必要なカラム名を知りたい場合もあります。クエリにヘッダーを追加できます:

これで、最後のプロジェクション(minimum_datemaximum_datepercentage)を作成するために必要なカラム名がわかりますが、実行する必要があるすべてのアクションの詳細も知りたい場合があります。そのためには actions=1 を設定できます。

これで、使用されているすべての入力、関数、エイリアス、データ型が確認できます。プランナーが適用しようとしているいくつかの最適化はこちらで確認できます。

クエリパイプライン

クエリパイプラインはクエリプランから生成されます。クエリパイプラインはクエリプランに非常に似ていますが、ツリーではなくグラフです。ClickHouseがクエリをどのように実行し、どのリソースが使用されるかを強調します。クエリパイプラインを分析することは、入力/出力のボトルネックを確認するのに非常に有用です。前のクエリをとり、クエリパイプラインの実行を見てみましょう:

括弧の中には、クエリプランステップが含まれ、次にプロセッサが示されています。これは素晴らしい情報ですが、これはグラフであるため、そのように可視化できると良いでしょう。設定 graph を1に設定し、出力形式をTSVに指定できます:

この出力をコピーしてこちらに貼り付けると、次のグラフが生成されます:

Graph output

白い長方形はパイプラインノードに対応し、灰色の長方形はクエリプランステップに対応し、x の後に数字が続くものは使用されている入力/出力の数に対応します。コンパクトではない形式で表示したい場合は、compact=0を追加できます:

Compact graph output

ClickHouseはなぜテーブルから複数のスレッドを使用して読み込まないのでしょうか?テーブルにさらにデータを追加してみましょう:

再度 EXPLAIN クエリを実行しましょう:

Parallel graph output

したがって、エグゼキュータはデータの量が十分多くないため、操作を並列化しないことを決定しました。行を追加することで、エグゼキュータはグラフに示されているように複数のスレッドを使用することを選択しました。

エグゼキュータ

最後に、クエリ実行の最終ステップはエグゼキュータによって行われます。エグゼキュータはクエリパイプラインを取り、それを実行します。SELECTINSERT、または INSERT SELECT に応じて異なるタイプのエグゼキュータがあります。