【要約】Snowflake で先読み後読み正規表現を諦めない - RLIKEへの分解アプローチ [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
マッピングチームは、決済データのブランド推定において、Snowflakeの正規表現制約による性能低下に直面した。
- ・AthenaからSnowflakeへの移行に伴い、高度な正規表現（先読み・後読み）が使用不能となった。
- ・既存資産を維持するためPython UDFを採用したが、実行時のオーバーヘッドが甚大であった。
- ・キーワード数とデータ量の増加に伴い、処理コストと時間が線形に増大する技術的負債を抱えた。
// Approach
チームは、複雑な正規表現を「分解可能」か「不可能」かで分類し、ネイティブ関数へ寄せる設計を採用した。
- ・位置情報に依存しない否定先読みを、REGEXP_LIKEとNOT REGEXP_LIKEのAND条件へ分解した。
- ・先頭・末尾境界のパターンも、独立した条件式として再構成するロジックを実装した。
- ・分解不可能なパターンのみをPython UDFへフォールバックさせる三層構造を構築した。
- ・新旧方式を並行稼働させ、差分をSlack通知する検証プロセスを経て段階的に移行した。
// Result
エンジニアリングチームは、計算リソースの最適化と業務効率の向上を同時に実現した。
- ・月次バッチの実行時間を6時間（xlarge）から3時間20分（medium）へ短縮した。
- ・Snowflakeのクレジット消費量を約4割削減することに成功した。
- ・オペレーターの作業におけるタイムアウト問題を解消し、作業効率を大幅に改善した。
Senior Engineer Insight
> プラットフォームの制約を「コードの書き換え」ではなく「論理的な分解」で解決した点が極めて実践的である。既存の膨大な正規表現資産を維持しつつ、高コストなUDFを最小化する設計は、スケーラビリティの観点から非常に優れている。ただし、分解ロジックの複雑性が新たな負債になるリスクがあるため、厳密なテストが不可欠だ。