VerticaからSnowflakeへのSQL非互換対応と移行難易度について
記事の目的
VerticaからSnowflakeへの移行事例は公開されている情報が限られているのが現状です。
そこで、2020年に実施したVerticaからSnowflakeへの移行PoCで得られた知見、特にSQL非互換とその対応方法について共有させていただきます。
結論として、調査の結果、VerticaからSnowflakeへの移行における技術的な障壁は比較的低いことが確認できました。
以下では、その具体的な内容について説明いたします。
なお、私が経験した移行プロジェクト全体の概要については、以下の記事もご参照ください：
検証範囲について
本検証は、既存の分析システムで使用していたプログラムやDDL/DMLを対象として実施しました。
大規模な分析サービスでの検証であったため、一般的なSQLパターンについては一定の網羅性があると考えられます。
ただし、すべてのケースに対する完全な網羅性や妥当性を保証するものではない点にご留意ください。
性能面の評価について
性能評価は、クエリパターンやシステム規模、Snowflakeの構成によって大きく異なるため、導入を検討される際は必ず自社環境での検証をお勧めします。
当時の検証環境では、以下のVerticaオンプレミス環境をベースにSnowflakeのLサイズ相当で評価を行いました：
検証時のVertica環境
HP ProLiant GL380：9台構成 CPU：432コア、メモリ：2,304GB
検証の結果、全体的な処理時間は従来の半分以下になりましたが、ショートクエリや単件のInsert処理については、Verticaの方が優位なケースも確認されました。
上記の見落としで本番移行後にパフォーマンス課題が発生した経験から、処理方式のパターンを整理してしっかり評価するのが重要です。
そのパフォーマンス課題の事例は以下の記事をご参照ください：
Snowflakeに移行したらロック待機でパフォーマンス出なかった話
SQL非互換一覧
さて本題の非互換一覧のまとめです
| # | 分類 | 非互換内容 | 対応方針 |
|---|---|---|---|
| 1 | DDL | パーティションや分散キー、プロジェクションが無い。 | クラスタリングキー（XXX_DATE など）を指定し、Verticaのオプション類は削除する。 |
| 2 | 構文 | 時刻に整数値を加減算できない。 | DATEADD関数を使用する。 |
| 3 | 構文 | 結果が小数点になる列を、Java側で整数として受け取ると、暗黙変換されずにエラーになる。 | TRUNC関数を利用して小数点を切り捨てる。※デシル分析のVALUE_FROM列で発生。 |
| 4 | 構文 | select for updateが無い。 | for updateを削除する。実装ケースより、デッドロックする懸念があるので、更新順を調整するか、ダミーのupdateを入れる（同じ値で更新する）必要がある。 |
| 5 | 構文 | 旧ヒント句が原因でエラーになる。 | Exadataからの移行時に残っていたヒント句（コメント）が書式の都合でエラーになるケースがある。→旧ヒント句は全て除去する。 |
| 6 | 関数非互換 | ROWNUM() OVER() のOVER句にOrder byが必要。 | ROWNUM() OVER(ORDER BY 1)の様にダミーのOrder byを入れる |
| 7 | 関数非互換 | CURRENT_TIMESTAMPそのまま使えない。 | CURRENT_TIMESTAMP()にする（カッコが必要） |
| 8 | 関数非互換 | CURRENT_TIMESTAMP()のタイムゾーンを考慮する必要がある。 | 9時間ずらすか、TIMEZONEセッションパラメータの考慮が必要。 |
以上の結果から、VerticaからSnowflakeへのSQL移行に関する技術的なハードルは比較的低いと考えられます。
これは、VerticaがANSI SQLに準拠していることと、Snowflakeの柔軟な方言対応によるものと考えられます。
最後に、Snowflakeのユーザーコミュニティには、より豊富な知見や経験をお持ちの方々が多くいらっしゃいます。
導入をご検討の際は、ぜひコミュニティへの参加もご検討ください。
私自身、様々なレガシーシステムからSnowflakeへの移行経験があり、導入検討に関するご相談やレビュー依頼を様々な方からお受けしています。
システム構成や投資対効果、移行に当たっての悩みなど、お困りの点がございましたら、少しでも貢献出来ることがあると思いますので、以下までお気軽にご連絡ください。
Discussion