Python Snowpark ストアドプロシージャおよび UDFs: イベントテーブルのトレース改善¶
Pythonストアドプロシージャが別のPythonストアドプロシージャを呼び出したり、PythonストアドプロシージャがPython UDF を呼び出したりするときに、チェーンされた呼び出しからのクエリがどのようにリンクされるかを確認できるようになりました。この機能を使用するには、イベントテーブルを設定し、トレースを有効にする必要があります。イベントテーブルの TRACE:"trace_id" 列と RECORD:"parent_span_id" 列に表示される値は以下のとおりです。
- 変更前:
チェーンされたPythonストアドプロシージャまたは UDFs によって作成された各スパンの
trace_idは一意です。イベントテーブルの RECORD 列にはparent_span_idフィールドが存在しません。Native Appsのプロバイダーとコンシューマーには、共有イベントの異なるtrace_idsが表示されます。プロバイダーにはハッシュ化されたバージョンが表示されます。- 変更後:
チェーンされたPythonストアドプロシージャまたは UDFs によって生成されたスパンには、同じ
trace_idがあります。チェーンされたPythonストアドプロシージャまたは UDFs によって生成されたスパンには、
span_idとparent_span_idの間に親子関係があります。Pythonストアドプロシージャは任意の長さのチェーンで他のストアドプロシージャを呼び出すことができますが、 UDFs は SQL ステートメントを実行できないため、 UDF を呼び出すとチェーンが終了します。しかし、トレース情報は引き続き UDF のスパンに伝達されます。Pythonストアドプロシージャまたは UDF がユーザーによって直接呼び出された場合（ルート）、
trace_idはランダムな ID になり、parent_span_idはありません。ストアドプロシージャのトレースが無効で、そのストアドプロシージャが別のストアドプロシージャまたは UDF を呼び出す場合、子のスパンのtrace_idはランダムになり、parent_span_idはありません。つまり、トレースは子から再起動されます。Native Appsのプロバイダーとコンシューマーには、共有されたPythonストアドプロシージャや UDF イベントに対して同じ
trace_idが表示されるため、デバッグが容易になります。
他のPythonストアドプロシージャまたは UDFs を呼び出すPythonストアドプロシージャを含んだアプリケーションを共有するNative Appsプロバイダーは、ストアドプロシージャのコールスタックと親子関係をコンシューマーに公開します。これを避けるには、トレースを無効にします。
参照: 1520