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

コスト最適化

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

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

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

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

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

  • 複数の行をロードする場合、 insertRows を使用すると、ロックに費やされる時間が少ないため、 insertRow を複数回呼び出すよりも効率的で費用対効果が高くなります。

    • 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 で設定された時間に基づいて自動的にフラッシュされるため、データ挿入後はチャネルを閉じないでください。

レイテンシの推奨事項

Snowflake Ingest SDK バージョン2.0.4以降では、 MAX_CLIENT_LAG を使用してデータフラッシュレイテンシを設定できます。デフォルトでは、Snowpipe Streamingは標準的なSnowflakeテーブル（Apache Iceberg™ 以外）のデータを1秒ごとにフラッシュします。 MAX_CLIENT_LAG 設定では、上書きし、1秒から10分の間で希望のフラッシュレイテンシーに設定することができます。

データがあまり生成されない低スループットのシナリオでは、毎秒1行または1 KB しかデータを送信しない可能性があります。特に、移行プロセスがパーティションをコンパクト化する前にクエリがトリガーされた場合、クエリ結果を返すためにたくさんの小さなパーティションを解決しなければならず、クエリのコンパイル時間が長くなる可能性があります。 MAX_CLIENT_LAG を高く設定することで、Snowpipe Streamingは挿入された行を設定された時間バッファリングし、より適切なサイズのパーティションを作成することができます。これにより、クエリのパフォーマンスと移行が大幅に向上します。

したがって、 MAX_CLIENT_LAG は、目標とするレイテンシで可能な限り高く設定してください。たとえば、ストリームデータをマージまたは変換するために1分ごとに実行するタスクがある場合、 MAX_CLIENT_LAG を50秒または55秒に設定するのが最適です。

Snowflakeで管理されたIcebergテーブル（Snowflake Ingest SDK バージョン3.0.0以降でサポート）へのストリームでは、最適化されたParquetファイルを確保するため、デフォルトの MAX_CLIENT_LAG は30秒です。プロパティを低い値にセットすることもできますが、スループットが著しく高い場合を除き、これを 行わない ことをお勧めします。

言語: 日本語