Snowpipe Streaming Classicのベストプラクティス

コスト最適化

ベストプラクティスとして、1秒あたりにより多くのデータを書き込む少数のSnowpipe Streamingクライアントで API を呼び出すことをお勧めします。JavaまたはScalaアプリケーションを使用して IoT デバイスやセンサーなどの複数のソースからデータを集計し、次にSnowflake Ingest SDK を使用して API を呼び出して、より高いフローレートでデータをロードします。API は、アカウント内の複数のターゲットテーブルにまたがるデータを効率的に集計します。

単一のSnowpipe Streamingクライアントは複数のチャネルを開いてデータを送信することができますが、クライアントコストはアクティブなクライアントごとにのみ課金されます。チャネル数はクライアントコストには影響しません。したがって、パフォーマンスとコストの最適化のために、クライアントごとに複数のチャネルを使用することをお勧めします。

バッチとストリーミングの両方のインジェスチョンに同じテーブルを使用すると、ファイル移行が操作済みであるため、Snowpipe Streamingのコンピューティングコストを削減することもできます。 自動クラスタリング がSnowpipe Streamingが挿入する同じテーブルでも有効になっている場合、ファイル移行のコンピューティングコストが削減される可能性があります。クラスタリング操作は、同じトランザクションでデータの最適化と移行を行います。

パフォーマンスの推奨事項

高スループットのデプロイで最適なパフォーマンスを得るには、次のアクションをお勧めします。

  • 複数行をロードする場合、 insertRow を複数回呼び出すよりも、 insertRows を使用した方がロックに費やす時間が短くなるため、効率的でコスト効率が高くなります。

    • insertRows に渡される各行バッチのサイズは16 MB 以下に圧縮します。

    • 行バッチの最適サイズは10～16 MB です。

  • TIME 、 DATE 、およびすべての TIMESTAMP 列の値を、 java.time パッケージから サポートされている型 の1つとして渡します。

  • OpenChannelRequest.builder を使用してチャネルを作成する場合、 OnErrorOption を OnErrorOption.CONTINUE にセットし、 insertRows からの返り値を手動でチェックして、取り込みエラーの可能性がないか確認します。現在、このアプローチは OnErrorOption.ABORT が使用されたときにスローされる例外に依存するよりも優れたパフォーマンスをもたらします。

  • デフォルトのログレベルを DEBUG にセットする場合、以下のロガーが INFO でログを取り続けることを確認してください。 DEBUG の出力は非常に冗長であり、パフォーマンスの大幅な低下につながる可能性があります。

    • net.snowflake.ingest.internal.apache.parquet

    • org.apache.parquet

  • チャネルは、クライアントが活発にデータを挿入していると長い間維持されるべきであり、オフセットトークン情報が保持されるため再利用されるべきです。チャンネル内のデータは MAX_CLIENT_LAG で構成された時間に基づいて自動的にフラッシュされるため、データ挿入後にチャンネルを閉じないでください。

レイテンシの推奨事項

Snowpipe Streamingを使用する場合、レイテンシとは、チャネルに書き込まれたデータがSnowflakeでクエリ可能になるまでの時間を指します。Snowpipe Streamingは、チャンネル内のデータを1秒ごとに自動的にフラッシュします。つまり、データをフラッシュするためにチャンネルを明示的に閉じる必要はありません。

Snowflake Ingest SDK バージョン 2.0.4 以降の MAX_CLIENT_LAGを使用したレイテンシの構成 では、 MAX_CLIENT_LAG オプションを使用してデータフラッシュのレイテンシを微調整できます。

  • 標準 Snowflake テーブル（Iceberg 以外）: デフォルトの MAX_CLIENT_LAG は 1 秒です。これをオーバーライドすることで、1秒から最大10分までの任意のフラッシュ・レイテンシをセットすることができます。

  • Snowflake が管理する Iceberg テーブル：Snowflake Ingest SDK バージョン3.0.0以降でサポートされ、デフォルトの MAX_CLIENT_LAG は30秒です。このデフォルトでは、最適化された Parquet ファイルが作成され、クエリのパフォーマンスに役立ちます。これより低い値をセットすることもできますが、スループットが非常に高い場合を除き、一般的には推奨されません。

パフォーマンスを最適化するためのレイテンシに関する推奨事項 MAX_CLIENT_LAG を効果的にセットすることで、クエリのパフォーマンスや内部マイグレーション処理（Snowflakeが小さなパーティションをコンパクト化する処理）に大きな影響を与えます。

スループットの低いシナリオでは、毎秒少量のデータ (例えば1行や1 KB) しか送信しないかもしれませんが、頻繁なフラッシュは多数の小容量パーティションにつながる可能性があります。これは、Snowflakeが多数の小さなパーティションを解決する必要があるため、クエリのコンパイル時間が増加する可能性があります。

従って、 MAX_CLIENT_LAG はターゲットとするレイテンシ要件が許す限り高くセットする必要があります。挿入された行をより長い時間バッファリングすることで、Snowpipeストリームはより良いサイズのパーティションを作成し、クエリのパフォーマンスを向上させ、マイグレーションのオーバーヘッドを削減します。たとえば、ストリームデータをマージまたは変換するタスクを1分ごとに実行する場合、最適な MAX_CLIENT_LAG は50秒から55秒の間です。これにより、ダウンストリームプロセスが実行される直前に、データがより大きなチャンクでフラッシュされるようになります。

Snowpipe Streaming 用 Kafka コネクタ Snowpipe Streaming 用 Kafka コネクタには独自の内部バッファがあることに注意しましょう。Kafkaバッファのフラッシュ時間に達すると、データはSnowpipe Streamingを通じて標準の1秒のレイテンシでSnowflakeに送信されます。詳細情報については、 buffer.flush.time設定 をご覧ください。

言語: 日本語