Snowpipe Streamingのベストプラクティス¶
コスト最適化¶
ベストプラクティスとして、1秒あたりにより多くのデータを書き込む少数のSnowpipe Streamingクライアントで API を呼び出すことをお勧めします。JavaまたはScalaアプリケーションを使用して IoT デバイスやセンサーなどの複数のソースからデータを集計し、次にSnowflake Ingest SDK を使用して API を呼び出して、より高いフローレートでデータをロードします。API は、アカウント内の複数のターゲットテーブルにまたがるデータを効率的に集計します。
単一のSnowpipe Streamingクライアントは複数のチャネルを開いてデータを送信することができますが、クライアントコストはアクティブなクライアントごとにのみ課金されます。チャネル数はクライアントコストには影響しません。したがって、パフォーマンスとコストの最適化のために、クライアントごとに複数のチャネルを使用することをお勧めします。
バッチとストリーミングの両方のインジェスチョンに同じテーブルを使用すると、ファイル移行が操作済みであるため、Snowpipe Streamingのコンピューティングコストを削減することもできます。Snowpipe Streamingが挿入する先の同じテーブルでも 自動クラスタリング が有効になっている場合は、ファイル移行のコンピューティングコストが削減される可能性があります。クラスタリング操作は、同じトランザクションでデータの最適化と移行を行います。
パフォーマンスの推奨事項¶
高スループットのデプロイで最適なパフォーマンスを得るには、次のアクションをお勧めします。
TIME 、 DATE 、およびすべての TIMESTAMP 列の値を、
java.timeパッケージから サポートされている型 の1つとして渡します。OpenChannelRequest.builderを使用してチャネルを作成する場合、OnErrorOptionをOnErrorOption.CONTINUEに設定し、insertRowsからの戻り値で潜在的なインジェスチョンエラーがないか手動で確認します。現在、このアプローチはOnErrorOption.ABORTが使用されたときにスローされる例外に依存するよりも優れたパフォーマンスをもたらします。insertRowsに渡される各行バッチのサイズは16 MB 以下にします。複数の行をロードする場合、
insertRowsを使用すると、ロックに費やされる時間が少ないため、insertRowを複数回呼び出すよりもパフォーマンスと費用対効果が高くなります。デフォルトのログレベルを DEBUG に設定する場合は、以下のロガーが INFO でログし続けることを確認してください。 DEBUG 出力は非常に冗長であるため、パフォーマンスが大幅に低下する可能性があります。
net.snowflake.ingest.internal.apache.parquetorg.apache.parquet