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は1秒ごとにデータをフラッシュします。 MAX_CLIENT_LAG
設定では、上書きし、1秒から10分の間で希望のフラッシュレイテンシーに設定することができます。
データがあまり生成されない低スループットのシナリオでは、毎秒1行または1 KB しかデータを送信しない可能性があります。特に、移行プロセスがパーティションをコンパクト化する前にクエリがトリガーされた場合、クエリ結果を返すためにたくさんの小さなパーティションを解決しなければならず、クエリのコンパイル時間が長くなる可能性があります。 MAX_CLIENT_LAG
を高く設定することで、Snowpipe Streamingは挿入された行を設定された時間バッファリングし、より適切なサイズのパーティションを作成することができます。これにより、クエリのパフォーマンスと移行が大幅に向上します。
したがって、 MAX_CLIENT_LAG
は、目標とするレイテンシで可能な限り高く設定してください。たとえば、ストリームデータをマージまたは変換するために1分ごとに実行するタスクがある場合、 MAX_CLIENT_LAG
を50秒または55秒に設定するのが最適です。