先日 草津に行ったのですが、草津のあたりでは花豆が名産品と知りました。そら豆ぐらいの大きさの、大きい豆です。
料理が好きで豆をたまに煮たりもするので、生の花豆を買おうとしたところ、お店の人に「豆は煮たことがあるのか」と聞かれました。「黒豆ならたまに煮ます」と答えると、それでは売れないと言われ、なんと購入させてもらえませんでした。まだまだ修行が足りません。
今日は Snowflake のアップデート情報を見かけたので、そちらを中心にまとめました。
Snowflake の Query Acceleration
Snowflake のバーチャルウェアハウスに Query Acceleration の機能が追加されました：
Query Accelerationサービスの使用 | Snowflake Documentation
ユーザ管理のバーチャルウェアハウスではなく、Snowflake が管理するサーバーレスコンピューティングリソースを使用して、対象となるクエリの一部を実行します。Query Acceleration がどの程度効くかを調べるための様々な方法が上のページで紹介されており、例えば実行済みクエリのクエリID（ただし14日以内）に対して estimate_query_acceleration 関数を適用することで、Query Acceleration の適用範囲が確認できます：
select parse_json(system$estimate_query_acceleration('8cd54bf0-1651-5b1c-ac9c-6a9582ebd20f')); { "estimatedQueryTimes": { "1": 171, "10": 115, "2": 152, "4": 133, "8": 120 }, "originalQueryTime": 300.291, "queryUUID": "8cd54bf0-1651-5b1c-ac9c-6a9582ebd20f", "status": "eligible", "upperLimitScaleFactor": 10 }
estimatedQueryTimes の見方ですが、左の数字がスケールファクターと呼ばれるもので、クエリ実行に利用したバーチャルウェアハウスの何倍のリソースを利用したかを表しています。右の数字が実行時間なので、元の 300.291 秒に対して、スケールファクター1でも倍近い速度でクエリ実行が完了しています。
なお、バーチャルウェアハウスにはスケールファクターの制限を掛けることができ、0で無制限、最大100まで設定できます（デフォルトは8）。
複雑なクエリの実行速度を早めるためには、ウェアハウスのサイズを大きくする必要がありました。公式ページでもアドホッククエリに対する速度向上が見込めると記載があるため、この問題に対する解決策として ウェアハウスサイズはそのままにしてコストを抑えつつ、複雑なクエリに対しては Query Acceleration を利用して実行速度向上が見込めそうです。
簡単に設定できる反面、常時複雑なクエリが実行される状態だとコストが大きく跳ね上がってしまう可能性があります。まだ新しい機能なのでスケールファクターを小さめにしながら様子見で使うのが良いかもしれません。
3 Big Updates in Snowflake in February
その他、2023年2月のアップデートについていくつか取り上げられていました：
Feature 1: Access History with Track Masking & Row Access Policy References
行アクセスポリシーや列のマスキングポリシーへのクエリ参照が ACCESS_HISTORY ビューにて確認できるようになったとのこと。
Feature 2: Error Notifications for Snowpipe and Tasks
Snowpipe や Task のエラーを各クラウドサービスのメッセージングサービスに通知することができるようになりました。今までは AWS のみだったのが、Google Cloud, Microsoft Azure も対応し、GAとなりました。
Feature 3: Snowflake Alerts: a Preview
これはとても嬉しい機能です。Snowflakeのリソースが一定数を超えたり、不正アクセスがあった場合など、さらには独自のビジネスルールを利用してアラートを上げることができます。公式ドキュメントから、アラートを設定するクエリの例を紹介します：
Setting Up Alerts Based on Data in Snowflake | Snowflake Documentation
CREATE OR REPLACE ALERT myalert WAREHOUSE = mywarehouse SCHEDULE = '1 minute' IF( EXISTS( SELECT gauge_value FROM gauge WHERE gauge_value>200)) THEN INSERT INTO gauge_value_exceeded_history VALUES (current_timestamp());
SQL 文でもあまり違和感なく、実行間隔とアラート条件が記述できています。上記 SQL では INSERT を実行しますが、メール送信することも可能なようです（公式ドキュメント: CREATE ALERT）。Slack 通知などにも対応して欲しいですが、SQL 文で記述するには少し複雑になりすぎるでしょうか…。
Lakehouse Data Modeling using dbt, Amazon Redshift, Redshift Spectrum, and AWS Glue
AWS Glue, Redshift と dbt Cloud を組み合わせたサンプルの紹介です。あまり Redshift 固有の話はないと言うか、ツール非依存にデータ変換処理が記述できるのが dbt の良さなので、詳しい方には目新しい内容はないかもしれません。私は普段業務で使っていないので、復習がてらによい内容でした。
dbt Cloud なら実行環境を自分で用意せずともジョブ登録・実行ができるので便利ですね。
dbt はリアルタイムでのユースケースにも対応できるのかを少し調べましたが、Lambda View （最新のデータをビューで、一定期間後のデータをテーブルに保存し、組み合わせて表示すること）であれば dbt でも構築できそうです：
余談ですが Lambda ナントカって検索しづらいですね…。Lambda View について深掘りしたかったのですが AWS Lambda ばかり引っ掛かり、検索できませんでした。ラムダアーキテクチャのサービスレイヤをどう作るかというだけにも見えるので、上記発表において分かりやすい名前を付けたかったのかもしれません。
AWS Publishes Reference Architecture and Implementations for Deployment Pipelines
AWS上でアプリケーションを実装する上で、CI/CDとしてどんなパイプラインが必要かをまとめたドキュメントがAWSから公開されました。
図だけ見ると当たり前のような気がしますが、Account Fleet (terraformなど？) のパイプライン、イメージをビルド・プッシュするパイプライン、実際にアプリケーションをデプロイするパイプラインなどが分けて記載されていてとても分かりやすいです。一から環境構築する際には役に立ちそうです。
