Snowflakeアプリにおける観測可能性¶

テレメトリーデータのタイプ¶

収集したテレメトリーデータが広く役立つように、Snowflakeテレメトリは、Cloud Native Compute Foundationのインキュベートプロジェクトである標準 OpenTelemetry （時折 OTel と呼ばれる）フレームワーク上に構築されています。このフレームワーク（およびそのために設計された APIs とツール）を通じて、収集したデータを Snowflake以外のツール で再利用することができます。OpenTelemetry を通して、アプリケーション・コードにインスツルメンテーションを行い、必要な箇所に観測可能性を追加することができます。

Snowflakeイベントテーブルは、ログ、スパン、およびメトリックデータを OpenTelemetry データモデリングで収集します。以下に、イベント・テーブルで収集されるテレメトリー・データの各タイプについて説明します。

ログ	ログはコードによって実行された個々の演算子を記録します。各ログメッセージは、コードの実行中の個別の時点で生成されます。 コードのインスツルメンテーション ハンドラコードからのログ記録 にリストされているように、使用している言語に標準的なライブラリを使って、コードからログを取ることができます。 データの表示 イベントテーブルをクエリするか、 |sf-web-interface| で提供されるデータ可視化を表示することによって、分析のためにログメッセージ を見ることができます。 Snowsight の次の画像は、1つのデータベースにおける2時間の期間に収集されたログメッセージのリストを示しています。
メトリクス	メトリクスとは、ある期間にわたって計算された測定値のことです。これらの値には、 CPU、メモリ測定値が含まれます。 コードのインスツルメンテーション Snowflakeはコードの実行時に自動的にメトリクスデータを出力するため、コードのインスツルメンテーションは不要です。 データを表示する メトリクスのデータを表示することができ、イベント・テーブルをクエリするか、 Snowsight で提供される可視化を見て、分析することができます。 Snowsight の次の画像は、ユーザー定義関数の実行に対する、収集されたメトリクス・データの変化を示しています。
トレース	トレースは、データがシステム内を流れる際の分散イベントを表示します。トレースでは、コンポーネントからコンポーネントへ処理が流れるときに、どこに時間が費やされるかを見ることができます。 トレースイベントは、Snowflake が作成するデフォルトのスパン内でも、作成したカスタムスパンからでも、 ハンドラコードからのログ記録 にリストされているような、使用している言語の標準ライブラリを使用して発行することができます。 コードのインスツルメンテーション ハンドラーコードからのイベントトレース にリストされているように、使用している言語の標準的なライブラリを使って、コードからトレースイベントを発することができます。 データの表示 トレースイベントを表示することができ イベントテーブルをクエリするか、 Snowsight で提供される可視化データを見ることで、分析することができます。 Snowsight の次の画像は、 UDF の実行によって生じるスパンを示しています。

必要な前に遠隔測定データを取得するための環境セットアップ¶

収集していないデータを分析することはできないので、テレメトリーデータを収集し始め、必要なときに入手できるようにしておくのがベストです。デプロイが大きくなるにつれて、コードのパフォーマンスを理解する必要性が高まります。

以下のベストプラクティスを参考にしてください。

• Snowflake環境のテレメトリーデータ収集。

  必要なデータを収集するには、イベントテーブルがアクティブであることを確認します。

• 必要なテレメトリーデータを確実に収集するために、 有用な閾値に テレメトリーレベルをセットします。

  最初は、データを確実に収集するために、これらのレベルを設定します。例えば、本番ジョブやビジネスクリティカルなジョブでは、ログレベルを少なくとも WARN にセットします。時間が経てば、ニーズの変化に合わせてレベルを調整することもできます。

  プロダクションのストアドプロシージャ、 UDFs 、およびその他のオブジェクトをデータベースまたはスキーマの下に整理し、そのデータベースまたはスキーマの警告ログを簡単に有効にできるようにします。これにより、別々のオブジェクトの設定を管理する手間が省けます。

• トラブルシューティング用のデータを生成するには、 ログステートメント または トレースイベント を本番ジョブに追加します。

  Java の SLF4J や Python のロギングライブラリなど、 標準ロギングライブラリ を使用する場合、Snowflake はこれらのパッケージからのログを自動的にイベントテーブルにルーティングします。

  トレースには、Snowflakeに含まれる テレメトリーライブラリ を使用できます。

• 測定したいハンドラーの処理の一部をトレースデータに含めるには、ストアドプロシージャ ハンドラー コードに カスタムスパン を追加してください。

  Snowflakeオブジェクトからの組み込みスパンとともに、Snowflakeはトレースダイアグラムで作成したカスタムスパンを表示します。カスタムスパンを使用すると、コード処理の任意の部分に関するデータを取得し、それらの部分の実行時間を確認することができます。また、カスタムスパンに任意のメタデータを添付して、トラブルシューティングや最適化のためにデータに説明を追加することもできます。

クエリ・テレメトリーによるプロシージャの最適化¶

クエリテレメトリートレースダイアグラムでは、クエリから発行されたすべてのスパンに関するデータを見ることができます。

• 横軸は継続時間。水平方向に長く見えるスパンは、短いスパンよりも完成までに時間がかかります。

• 縦軸はコール階層。この階層では、他のスパンの直接の基になるスパンは、その上の「親」スパンの「子」です。

このダイアグラムを使用して、ストアドプロシージャの最適化の機会を見つけることができます。図にあることを出発点として、コードを最適化するためのステップを踏むことができます。

例えば、joblibのようなライブラリを使って、逐次処理を並列実行するように整理することができます。 Joblib は Python コードにパイプラインを追加するためのツールセットです。これを使えば、より簡単に並列コードを書くことができます。

キャッシュ冗長性 DataFrame 操作¶

複数回使用される DataFrame 操作のチェーンがある場合、トレースダイアグラムでは、各 DataFrame アクションのスパンとして表示されます。クエリの複雑さによっては、このスパンがかなり長くなることもあります。

例えば、以下のコードでは、同じ DataFrame チェーンが複数のコンテキストで呼び出されています：

count = session.table(...).select().filter().join().count()

if count > 0:
  session.table(...).select().filter().join().write.save_as_table(...) # same query as the count, this will execute again
else:
  session.table(...).select().filter('other criteria').join() # nearly same query as the count

キャッシュを使用すると、中間 DataFrame を仮テーブルとしてキャッシュし、冗長なクエリを減らすことでパフォーマンスが向上します：

cached_df = session.table(...).select().filter().join().cache_result()
count = df.count()

if count > 0:
  cached_df.write.save_as_table() # reuses the cached DF
else:
  cached_df

UDFs のために受信したテレメトリーデータの量を管理します。¶

UDFs でテレメトリーデータを収集するコードを追加する場合、 UDF 実行モデルは、プロシージャの場合よりもイベントテーブルの行数が多くなる可能性があることを忘れないでください。

入力行ごとに UDF が呼び出されると、ハンドラーコードは入力データセットの行ごとにログステートメントやスパンイベントを発行します。例えば、 UDF に渡された1000万行のデータセットは、1000万件のログを出力します。

UDFs にログやスパンイベントを追加する際には、以下のパターンの使用を検討してください。

• 最初は、記録されるエントリー数を減らすように設計された ログレベル を使用してください。

  DEBUG-または INFO-levelログステートメントを使用し、本番環境ではログレベルを WARN にセットしてください。問題が見つかった場合、デバッグセッションの間、ログレベルを DEBUG または INFO に下げることができます。

• try/catchブロックを使って、ログデータを出力したいコードを分離します。

  try/catchを使用すると、予期しない UDF 入力をキャッチし、 WARN-レベルのログとして記録し、認識できるようにし、デフォルト値を返すのに便利です。

• 条件ステートメントを使用して、あなたにとって意味のあるシナリオだけをログに記録します。

  if/elseステートメントやその他の制約を使って、ログ出力の量を制御することができます。

クエリ・テレメトリーによるユーザー定義関数の最適化¶

UDF が呼び出されると、Snowflake は入力行ごとにハンドラーコードのインスタンスを作成して並列実行します。トレースダイアグラムでは、これらのインスタンスがそれぞれ独自のスパンとして表現されています。

これらのスパンを使用して、遅いクエリのトラブルシューティングを行い、パフォーマンスを改善する機会を見つけることができます。例えば、以下のようなシナリオが考えられます。

• UDF のコードの1つまたは複数のインスタンスが、他のデータよりかなり大きい、または他のデータとは異なるデータを持つ行を受け取る可能性があります。このような場合、そのインスタンスは完了するまでにかなり時間がかかる可能性があり、したがってそのスパンはかなり長くなります。

• クエリの入力パーティショニングと先行句によっては、少数のインスタンスが大量の入力データを受け取る可能性があります。

次の画像は、 UDF に渡された各行に対するスパンを示しています。スパンの1つが長いことから、その行は他の行よりも大きなデータを持っている可能性があります。

アラートと通知のベストプラクティス¶

システムから受け取る情報を絞り込み、その量を増やすことで、観測可能性を向上させるために、以下のプラクティスを活用してください。

• イベント評価の重複を避けることができます。

  アラートスケジュールと実行の間のレイテンシーをアカウントすることにより、イベントに対する評価の重複を避けることができます。このためには、 CURRENT_TIMESTAMP を使用する代わりに、 SCHEDULED_TIME と LAST_SUCCESSFUL_SCHEDULED_TIME を使用してアラートタイムスタンプを指定します。

  詳細については、 アラートスケジュールに基づくタイムスタンプの指定 をご参照ください。

• アラートアクションや通知をクエリ結果で充実させます。

  アラート条件によって指定された SQL ステートメントの結果を確認できます。クエリ結果を得るには、次のようにします。

  1. GET_CONDITION_QUERY_UUID を呼び出して、警告条件の SQL ステートメントのためにクエリ ID を取得します。

  2. RESULT_SCAN にクエリ ID を渡してクエリ結果を取得します。

• 通知を送信するだけでなく、結果をログに記録したり、自動アクションを実行したりできます。

  アラートアクションは、アラート条件が満たされるたびに、 タスクを実行 したり、新しい行をテーブルにログ記録するように指定できます。例えば、アラート条件が満たされるたびにSnowflakeでアクションを実行する場合、このようにします。

  条件が満たされた後に複雑なアクションを実行する場合は、ウェアハウスが適切なサイズであることを確認してください。