Snowflake 学習/受講メモ (Architect)

# これは何？

Snowfalke認定の資格試験「[Snowflake SnowPro Advanced Architect](https://learn.snowflake.com/en/certifications/snowpro-adv-jpn/)」に関して、全体感の大雑把メモ。
2024年になって日本語版がリリースされたので、早速やってみての振り返りを兼ねて。

## 試験情報

- 試験について : [公式情報(Study Guide)](https://learn.snowflake.com/courses/course-v1:snowflake+SPSG-ARA+A/about)
- 問題数 : 65問
- 合格ライン : 75%
    - 全部同じ配点だとすると49問以上正解する必要がある
    - 実際は重み付きの点数とのこと
    - 55問くらいは正解しておきたい気持ち

## 問題の振り返り

以下、思い出しながらのメモ。

### エディション差分

エディションの`機能差分`を理解しておく。
`エディションを跨いだシェア方法`を理解しておく。

- <https://docs.snowflake.com/ja/user-guide/intro-editions>
    - 例 : 次の要件を満たすようなエディション選択する
        - Tri-Secret Secure
        - プライベート接続
        - PCI DSS / PHI
    - ビジネスクリティカルを選んでいれば正解になる雰囲気はあるが、何でもかんでもビジネスクリティカルだと思っているとコケる
        - 特に`Snowflake 外部トークン化と統合`、これはエンタープライズで実現できる
- <https://docs.snowflake.com/ja/user-guide/override_share_restrictions>
    - 例 : 以下のようなエディションまたぎのシェア方法を答える
        - ビジネスクリティカル ↔️ スタンダードのシェア
        - ビジネスクリティカル ↔️ エンタープライズのシェア

### シェア

シェアされたテーブルに対する操作の制限とかを理解しておく。

- <https://docs.snowflake.com/ja/sql-reference/sql/create-database#general-usage-notes>
    - リージョン違い、クラウドベンダー違いのシェア
- <https://docs.snowflake.com/ja/user-guide/data-share-consumers>
    - マーケットプレイスから取得するのに必要な権限
- シェアされたものを取り込む時は`IMPORT SHARE`権限を使う
- シェアはコピーされないことにも注目する
    - 企業間のデータ共有をGDPR等を考慮してどう実現するか、等のソリューションで効いてくる
    - シェア、レプリケーション、この組み合わせは超重要
- シェアできるオブジェクトは？
    - 通常のビューはシェア`できない`
    - ストアドプロシージャはシェア`できない`
    - 外部テーブルはシェア`できる`
- シェアのパターンと対応策を押さえておく
    - 自社内、顧客間で複数クラウドやリージョンに跨ぐ
        - バラバラのリージョンやクラウドの場合
        - ほとんど同じリージョンやクラウドを利用している場合
    - 自社内、顧客間で同じクラウドベンダーとリージョン
    - シェア相手がSnowflakeを持っていない顧客
    - 自社 or シェア相手がEU拠点(GCPRに絡む)
    - シェア相手のSnowflakeエディションが異なる

### マルチクラウド/クロスリージョン

リージョンやクラウドベンダーまたぎでのシェア方法についても押さえておく。

- <https://docs.snowflake.com/ja/user-guide/secure-data-sharing-across-regions-platforms>
    - AWS - Azure
    - Azure - GCP
    - 等
- 必ずしもシェアをすることを考えなくてもいい
    - Snowflakeアカウントが1つしかなく、各リージョンやクラウドベンダー毎のSnowflakeアカウントを持っていない場合で、マルチクラウド・リージョンで点カウする各種サイト・サービスのデータを収集したいケース
    - 例えばストレージ統合を活用して外部ストレージとして連携すれば、各拠点に合わせたSnowflakeアカウントを都度作成することなく、今ある1つのSnowflakeアカウントに集約することもできる

### レプリケーション

レプリケーションの特徴、用途、制限を抑えておく。

- <https://docs.snowflake.com/ja/user-guide/account-replication-intro#region-support-for-replication-and-failover-failback>
    - リージョン違いのレプリケーション
    - クラウドベンダー違いのレプリケーション
    - 制限
        - 共有から作成されたデータベースは複製できません
        - プライマリデータベースに以下のいずれかが含まれている場合、リフレッシュ操作は失敗します
        - イベントテーブル
        - `外部テーブル`
    - 特に`外部テーブル`はレプリケーション時のエラーの元としてよく出てきがちなので、対策はよくみておく
- レプリケーションは単にバックアップ、障害復旧のための用途だけではない
    - クラウドベンダーやリージョンを跨いだシェアでもよく使う

### パフォーマンスチューニング

パフォーマンスの改善方法、劣化状況を把握してそれの解決策がわかるようにしておく。
今までは順調だったのに何かを境にパフォーマンスが劣化したとき、その劣化の原因も答えられるようにしておくこと。
データの形式(特に半構造)の考慮点も押さえておく。

- <https://docs.snowflake.com/ja/guides-overview-performance>
    - パフォーマンス改善
- <https://docs.snowflake.com/ja/user-guide/semistructured-considerations>
    - 要素が列に抽出された場合、エンジンは抽出された列のみをスキャンします
    - 要素が列に抽出されなかった場合、実行エンジンは JSON 構造全体をスキャンし、各行で構造を走査して値を出力する必要があります。これはパフォーマンスに影響します
    - 例 : jsonを読み込んでいるテーブルで、急にパフォーマンスが落ちた。なぜか？
        - jsonのvalueにnullが含まれている？
        - jsonのvalueの文字列長が長い？
        - jsonのkeyの順番が違った？
        - jsonのkeyが一部存在しない？ -> 上記に基づくと多分これ
- マテビューを使って代替クラスターキーを作って改善とか
- クエリプロファイルからの読み取りで解決策を考える問題もある
    - コンパイルに時間がかかっていて、ウェアハウスのサイズを変えても改善しないものはクエリを改善するとか
    - スピル対策とか
- 最新データ反映やクエリ時間等、総合的に低レイテンシーを実現するための対策とか
    - 外部テーブルの扱い
    - マテリアライズドビューの活用
    - snowpipeでリアルタイムに取り込む
    - 他

###  外部テーブル

- <https://docs.snowflake.com/ja/user-guide/account-replication-intro#region-support-for-replication-and-failover-failback>
    - 外部テーブルを含むDBをレプリケーション(別リージョン)する際の考慮点とか
        - 外部テーブルの複製は現在サポートされていません
        - その結果、外部テーブルに対する権限の付与も複製されません
    - 要は、レプリケーションする時は外部テーブルが邪魔になるので削除しておく必要がある
    - 原本テーブルには手を出したくないなら、クローンを作って外部テーブルがないようにしておき、クローンしたものをレプリケーションする感じ
- 仮想列
    - 外部テーブルの仮想列
        - <https://docs.snowflake.com/ja/user-guide/tables-external-intro#virtual-columns>
            - `VALUE` : 外部ファイルの単一の行を表す VARIANT 型の列。
            - `METADATA$FILENAME` : 外部テーブルに含まれるステージングされた各データファイルの名前を識別する疑似列。ステージ内のパスも含まれます。
            - `METADATA$FILE_ROW_NUMBER` : ステージングされたデータファイルの各記録の行番号を表示する疑似列。
            - 多分、選択肢には`外部テーブルの仮想列`と`ストリームの列`が出てきてややこしいので、問いに合わせて正しい列名を選べるようにしておくこと
    - 仮想列のマスキング
        - <https://docs.snowflake.com/ja/user-guide/security-column-intro>
- 例 : 外部テーブルに行アクセスポリシーを適用できる？
    - VALUE列に適用できる
        - `CREATE EXTERNAL TABLE`または`ALTER TABLE`
    - 仮想列には直接適用できない
        - 外部テーブルのビューを作って、そのビューの列に行アクセスポリシーを当てることで間接的に適用することはできる
- 外部テーブル x マテリアライズドビューのユースケースも押さえておく

### 認証/セキュリティ

- Okta
    - <https://docs.snowflake.com/ja/user-guide/scim-okta>
    - アプリからSnowflakeに認証を通したいときに考慮する優先順位
        - OAuth
        - 外部ブラウザ
        - Oktaネイティブ認証
        - キーペア認証
        - パスワード認証
- 暗号化キーのローテーション
    - <https://docs.snowflake.com/ja/user-guide/security-encryption-manage#encryption-key-rotation>
- キーの階層
    - <https://docs.snowflake.com/ja/user-guide/security-encryption-manage#hardware-security-module>
        - アカウント or データベース or テーブル or マイクロパーティション
- Tri-Secret Secure
    - <https://docs.snowflake.com/ja/user-guide/security-encryption-manage#tri-secret-secure>
        - Snowflakeアカウントをホストするクラウドベンダーのキー管理サービス(AWSならKMS)を使って、Snowflakeが管理するキーと顧客が管理するキーを組み合わせて、Snowflakeデータを保護するための複合マスターキーを作成する
        - 複合マスターキーはアカウントマスターキーの扱いになる
        - 有効にするには、 Snowflakeサポートに問い合わせが必要

### stream

- <https://docs.snowflake.com/ja/user-guide/streams-intro>
    - 例 : streamの動き
        - 1つのテーブルに対して2種類のstreamを作る
        - そのテーブルにデータのinsert, truncate, insert, deleteを行う
        - 2つのstreamをそれぞれ select count(*) した結果、出力される値はどうなるか？
    - オプション `INSERT_ONLY = TRUE | FALSE` は外部テーブルに対してのみ指定できる
        - 一方で、通常のテーブルには `APPEND_ONLY` が指定できる
        - ニュアンスが似てるので見間違えに注意
- ステージのstream
    - ステージに対するディレクトリテーブルを有効にして、ディレクトリテーブルに対してストリームを設定する必要がある
    - 外部ステージに入ったファイルをニアリアルタイムで取り込みたいような構成で、「タスク + ストリーム」という解決策が選択肢にあるとしたら、もう一手間としてディレクトリテーブルの考慮が必要になるので、文脈次第ではひっかけになるかも

###  クローン

- どのテーブルからどのテーブルをクローンできるか？を知った上でソリューションが問われる
    - 永続テーブルのクローンを、トランジエントテーブルまたはテンポラリーテーブルに作成できる
    - できる組み合わせ
        - テンポラリー -> テンポラリー
        - テンポラリー <-> トランジエント
        - トランジエント -> トランジエント
    - できないのは、テンポラリー/トランジエント -> 永続テーブル
- <https://docs.snowflake.com/ja/sql-reference/sql/create-clone>
- <https://docs.snowflake.com/ja/user-guide/object-clone>
- <https://docs.snowflake.com/ja/user-guide/tables-temp-transient#comparison-of-table-types>
- <https://docs.snowflake.com/ja/user-guide/tables-temp-transient#transient-tables-created-as-clones-of-permanent-tables>
    - 「スナップショット」としての活用方法もお忘れ無く
        - その時点でのテーブルをcloneして持っておく、みたいな
        - clone元テーブルは常に最新の状態に更新されるのでそちらを見る
- ゼロコピーというところもポイント
    - ストレージの節約とかの文脈で、クローンしてもストレージサイズに影響がないことを意識しておくとよい

### タイムトラベル
- <https://docs.snowflake.com/ja/sql-reference/sql/create-clone>
- クローンとタイムトラベルをセットで使うソリューションも重要
    - `CREATE TABLE ... CLONE ... AT(OFFSET => -???)`
        - 何分前とか何時間前とかのデータをクローンしてテーブル作成
    - `CREATE TABLE ... CLONE ... AT(timestamp => ???)`
        - 特定の時間を指定してその時のデータをクローンしてテーブル作成
- タイムトラベルを活用した、破損テーブルの復旧とか
    - 同じ名前の新しいテーブルがすでに存在する場合に、タイムトラベルしようとしたときに注意する点とかも知っておくこと
    - 本番(PROD)環境に誤ってデプロイして壊れてしまったテーブルを元に戻すにはどうすればいいか？とか
        - 独自に復旧用スクリプトを作る？
        - タイムトラベルで戻す？

### マテリアライズドビュー

- 制限/特徴
    - <https://docs.snowflake.com/ja/user-guide/views-materialized>
    - 複数選択するのではなく「複数特徴が列挙されていて全て正しいもの」を1つ選択するものが出た
        - これはほぼ全ての特徴を押さえてないと回答が難しい気がする
            - 自己結合を含めてはいけない
            - UDF使えない
            - ウィンドウ関数使えない
            - HAVING使えない
            - ORDER BY使えない
            - LIMIT使えない
            - GROUP BY使えない
            - ネストされたサブクエリ
            - 一部の集計関数は使える(MIN,MAX等)
            - 決定的な関数(結果が固定)は使える
              - 可変値を返すものは使えない (CURRENT_TIME、CURRENT_TIMESTAMPとか)
- どんなケースに向いているか(ソリューション系問題でマテビューが最適解なら選ぶ)
    - ベーステーブルが頻繁に更新されない、とか
- マテビューのクラスタリングについて
    - <https://docs.snowflake.com/ja/user-guide/views-materialized#label-clustering-base-table-and-materialized-view>
        - 元テーブルをクラスタリングするのではなく、マテビューを作ってそれに対してクラスタリングを設定するといいケースが問われる
        - 代替クラスターキーを作る時の選択肢になる

### クラスタリング

- <https://docs.snowflake.com/ja/user-guide/tables-clustering-keys#what-is-a-clustering-key>
    - クラスタリングキーの優先順位
        - 選択フィルターで最も頻繁に使用される列
            - ただし、カーディナリティが低すぎる or 高すぎる場合は適さない
        - 結合述語で頻繁に使用される列
            - join on とかに指定するID列とか
        - 列の選択順は、カーディナリティが低いものから順に選ぶといい
- <https://docs.snowflake.com/ja/sql-reference/functions/system_clustering_information>
    - SYSTEM$CLUSTERING_INFORMATION
    - これで示される情報についての意味が問われる
- キーワードは「深さ」
    - クラスタリングを検討する際の指標になる

### 統合

- 特にストレージ統合
    - <https://docs.snowflake.com/ja/sql-reference/sql/create-storage-integration>
    - アクセス管理(IAM)のエンティティ
    - Snowflakeからアクセスを許可するストレージの場所(S3ならバケット名(URL)、その配下のディレクトリ)を保持しておくもの
        - このとき複数のバケットを指定可能
    - 外部ステージ作成時にストレージ統合を指定することができる
        - 指定しない場合は直接認証情報(CREDENTIALS)を定義する
    - 例 : データのエクスポート先を制限するには、どの統合を使うか
        - セキュリティ統合？
        - API統合？
        - 通知統合？
        - ストレージ統合?

### セキュリティ保護可能なオブジェクト / オブジェクトの階層

- アカウント直下のオブジェクトを選ぶ問題
    - データベース
    - ウェアハウス
    - ロール
    - 等
- オブジェクトの階層関係が正しいものを選ぶ問題
    - データベース -> スキーマ -> テーブル/ビュー/UDF等
    - 組織 -> アカウント等
- セキュリティ保護可能なオブジェクトとは？
    - アクセスを許可できるエンティティを指す
    - 逆に保護できないのは権限

### クエリの実行結果

- 次のクエリを実行しました。どんな結果になりますか？系の問題
    - キャッシュを使ってコンピュートのコストなしに実行できるのかとか
    - 5分前に実行した同じクエリを使ってctasでテーブルを作成しようとするとどうなるかとか
        - selectにはキャッシュを使うが、insertにコストがかかる点に注意するとか
- 単にクエリ結果を求められるものだけでなく、何らかのソリューションを解決するための選択肢として複数のクエリ文が表示される問題も出るので、正しいものを選択できる様にしておくこと
    - そもそもエラーになりうるクエリ(構文ミス、文章問題と条件があっていないとか)
    - 実行はできるが問いにある様な結果、解決策にはならないもの

### 権限

- グローバル権限
    - <https://docs.snowflake.com/ja/sql-reference/sql/grant-privilege>
- RBACについて
    - `MANAGE GRANTS`権限を持つロールのみがスキーマ内のオブジェクトに対する権限を付与できる
    - <https://www.snowflake.com/wp-content/uploads/2021/10/Design-Patterns-for-Building-Multi-Tenant-Applications-on-Snowflake.pdf>
    - 例えば、テナント分離(テナントごとに見せるデータを変えたい等)を行いたい時、1案として行アクセスポリシー等でデータの見せ方をコントロールできる
    - それをしたくない(できない)場合の別案としては、テナントごとにオブジェクトを作成して、RBACで制御すれば実現できる
- DB/スキーマ配下のオブジェクトについて、allとfutureを付与した時、どちらが優先されるか？みたいなのが問わたような
    - <https://docs.snowflake.com/ja/user-guide/security-access-control-configure>
    - <https://docs.snowflake.com/ja/user-guide/security-access-control-configure#assigning-future-grants-on-objects>
    - DBが無視されてスキーマ優先？かつエラーなし？
    - スキーマが無視されてDB優先？かつエラーなし？
    - 範囲の広い方が適用される？
    - 範囲の狭い方が適用される？
- スキーマオブジェクトにアクセスするためにどんな権限をつけておく必要があるか
    - DBのUSAGE、スキーマのUSAGEが必要
    - その上で、スキーマ配下のオブジェクトに権限をつける
        - テーブルならSELECT
        - プロシージャならUSAGE
        - ステージならREADあるいはUSAGE
            - 外部ステージの時はUSAGE
        - 等

### 管理アクセススキーマ

- <https://docs.snowflake.com/ja/user-guide/security-access-control-configure#creating-managed-access-schemas>
    - 通常のアクセススキーマと管理アクセススキーマの違い
    - 管理アクセススキーマを使用するとどうなるか

### ウェアハウス / クラスタリング

- 最大化モード or 自動スケールモード
    - <https://docs.snowflake.com/ja/user-guide/warehouses-multicluster>
        - クラスターの数を増やしたい時は`MAX_CLUSTER_COUNT`を編集する
        - 同時実行数がある程度決まっている時は最大化モード
        - デフォルトでは1クラスターあたり8クエリ同時にさばける
            - 8以上にしたい時は`MAX_CONCURRENCY_LEVEL`で設定できる
- スタンダード or エコノミー
    - <https://docs.snowflake.com/ja/user-guide/warehouses-multicluster#setting-the-scaling-policy-for-a-multi-cluster-warehouse>
    - マルチクラスターウェアハウスのスケーリングポリシーの設定
- ウェアハウスのサイズを大きくすると、ローカルストレージも大きくなる点もポイント
    - リモートストレージにスピルする時の解決策として

### キャッシュ

- 結果キャッシュ
    - <https://docs.snowflake.com/ja/user-guide/querying-persisted-results>
        - 24時間有効
        - 24時間以内に使われると、そこから24時間延命される
        - なんだかんだ延命され続けた結果、最大で31日間までは保持される
    - このクエリを数分前に実行したが、再実行しようとしたときにコストがかかるか？とか問われる
- ダッシュボードと絡めた問題とかも出る
    - ダッシュボードには常に最新のデータを表示する
    - 新しいデータがある場合のみウェアハウスが動作する
    - 表示するデータに差分がない場合はキャッシュを使って結果を返す

### ORGADMIN

- ORGADMINでできること
    - <https://docs.snowflake.com/ja/user-guide/organizations#orgadmin-role>
    - <https://docs.snowflake.com/ja/user-guide/organizations-manage-accounts#changing-account-name>
    - アカウント作成
    - アカウント一覧表示
    - アカウント名の変更
    - レプリケーションの有効化
    - できないこと
        - 組織名変更
        - アカウント削除
            - ただし今となってはアカウント削除ができるようになっているのでは？

### パラメータ

- <https://docs.snowflake.com/ja/sql-reference/parameters>
- <https://docs.snowflake.com/ja/sql-reference/parameters#parameter-hierarchy-and-types>
    - パラメータのオーバーライド
        - どのパラメータが優先されるか
            - アカウント、ユーザー、ウェアハウス、テーブル、セッション
    - パラメータの更新は、ACCOUNTADMINと権限のあるユーザで

### 半構造データ

- 非構造化データの扱い
    - <https://docs.snowflake.com/ja/sql-reference/data-types-semistructured>
    - <https://docs.snowflake.com/ja/user-guide/querying-semistructured>
    - <https://docs.snowflake.com/ja/user-guide/semistructured-considerations>
    - variant
    - array
    - object
    - FLATTEN
    - OBJECT_CONSTRUCT
    - PARSE_JSON

### 行アクセスポリシー

- <https://docs.snowflake.com/ja/user-guide/security-row-intro>
    - グローバル権限
        - APPLY ROW ACCESS POLICY

### ダイナミックマスキングポリシー

- <https://docs.snowflake.com/ja/user-guide/security-column-intro>
    - 設定する際に記述する有効なSQL文は？
        - return number に対して else のreturnが正しいかどうかとか
            - else 0 : 正しい
            - else sha2(value) : 正しくない
            - else null : 正しくない？
    - グローバル権限
        - APPLY MASKING POLICY
        - APPLY SESSION POLICY
    - 注意点とか
        - マスキングポリシーが設定されて「いる」ソース列から、マスキングポリシーが設定されて「いない」ターゲット列に値を挿入する場合
            - マスクされていない列のデータを表示するロールは、マスクされていないデータを別の列に挿入できる
        - ポリシーの作成者(所有者)でも、マスクされた値が表示される
            - ポリシーの所有者は常に元の値が返る、みたいな選択肢があったらそれは間違い
    - 行アクセスポリシーよりも、こちらの列に注目したポリシーが試験問題としてよく出てくるような印象がある

### kafka

kafkaって音の響きだけ聞くと過負荷のことだと思ってたけど全然違った

- <https://docs.snowflake.com/ja/user-guide/kafka-connector-overview>
    - kafkaコネクタはトピックごとに次のオブジェクトを作成する
        - 各トピックのデータファイルを一時的に保存する1つの内部ステージ
        - 各トピックパーティションのデータファイルを取り込むための1つのパイプ
        - トピックごとに 1 つのテーブル
    - 各Kafkaメッセージは、JSON 形式またはAvro形式でSnowflakeに渡される
- <https://docs.snowflake.com/ja/user-guide/kafka-connector-ts>
    - Kafkaコネクタを使ってロード中、何らかの理由でロードできなかったファイルはターゲットテーブルに関連付けられたステージに退避される

### snowpipe

- <https://docs.snowflake.com/ja/sql-reference/sql/create-pipe>
- <https://aws.amazon.com/es/blogs/apn/using-amazon-comprehend-medical-with-the-snowflake-data-cloud/>
- <https://docs.snowflake.com/ja/user-guide/data-load-snowpipe-auto-s3#step-3-configure-security>
- CREATE PIPEで求められる権限に注意
    - スキーマの`USAGE`
    - パイプ定義のステージへの`READ`か`USAGE`
    - テーブルの`SELECT`と`INSERT`
- <https://docs.snowflake.com/ja/user-guide/data-load-snowpipe-rest-apis>
    - apiの制限の件
        - 429エラー関連
        - 実行制限があるということで、とりあえずこれだけ押さえておけばわかりやすい問題
    - `insertFiles`が実行された結果は何を意味するか、とか

### Snowflakeデータベース

- account_usageとかのSnowflakeデータベース、information_schemaの使い分け
    - <https://docs.snowflake.com/ja/sql-reference/functions/login_history>
        - 特にログが反映される時間が違う点
        - ソリューション系の問題で、何らかの不正アクセスがあったことを「すぐに確認したい」というニュアンスで問われていればinformation_schemaを見るしかない
- [WAREHOUSE_LOAD_HISTORY](https://docs.snowflake.com/ja/sql-reference/account-usage/warehouse_load_history)
    - これを使ってウェアハウスのワークロードを分析するとか
- とあるビューやテーブル関数を使って何ができる(何がわかる)、とか
- とあるビュー名が問題で与えられて、選択肢として「information_schemaにある」とか「account_usageにある」とかが問われることも

### メタデータ

- <https://docs.snowflake.com/ja/sql-reference/metadata>
    - 変更追跡メタデータを使う例
        - ストリーム(stream)
            - <https://docs.snowflake.com/ja/user-guide/streams-intro>
        - changes句を用いたクエリ
            - <https://docs.snowflake.com/ja/sql-reference/constructs/changes>

###  copy into

- <https://docs.snowflake.com/ja/sql-reference/sql/copy-into-table>
    - VALIDATION_MODEとか特に注意
        - VALIDATION_MODE は、ロード中にデータを変換する COPY ステートメントをサポートしません。パラメーターが指定されている場合、 COPY ステートメントはエラーを返します。
        - RETURN_n_ROWS、RETURN_ERRORS、RETURN_ALL_ERRORS
    - 既存環境にある`大量のデータファイル`をSnowflakeに移行するにあたってsnowpipeで取り込むときに、`コスト効率を考えたオプション`は何か？とか
        - `ON_ERROR`をどうするかとか
            - `CONTINUE` : エラーが見つかった場合は、ファイルのロードを続行します。COPY ステートメントは、データファイルごとに見つかった最大1つのエラーのエラーメッセージを返します。
            - `SKIP_FILE` : SKIP_FILE アクションは、エラーが見つかったかどうかに関係なく、`ファイル全体をバッファーすることに注意`してください。このため、 SKIP_FILE は CONTINUE または ABORT_STATEMENT よりも低速です。`少数のエラーで大型のファイルをスキップすると、遅延が発生し、クレジットが無駄になる`可能性があります。
    - 取り込みに失敗したファイルだけを再読み込みしたいときにどうするか
        - ファイル名を指定してロード
        - 何も指定せずにロード -> すでに取り込んだファイルは記録されるのでその仕組みを使用して特に意識せず、ロード時と同じコマンドを打てば取り込まれる
            - ただしFORCEを指定してしまうとロード済みのファイルまで対象になるので注意
- <https://docs.snowflake.com/ja/sql-reference/sql/copy-into-location>
    - アンロード可能なファイルの種類やエンコーディングとか
    - [出力データファイルの詳細](https://docs.snowflake.com/ja/user-guide/intro-summary-unloading#output-data-file-details)
        - UTF-8
        - csv/tsv, json, parquet

### 検索最適化

- <https://docs.snowflake.com/ja/user-guide/search-optimization-service>
- <https://docs.snowflake.com/ja/user-guide/search-optimization/enabling>
- <https://docs.snowflake.com/ja/user-guide/search-optimization/working-with-tables>
    - スキーマに対するADD SEARCH OPTIMIZATION
    - テーブルに対するOWNERSHIP

### 外部関数

- <https://docs.snowflake.com/ja/sql-reference/external-functions-introduction>
- <https://docs.snowflake.com/ja/sql-reference/external-functions-best-practices>

### ソリューション

要は文章問題。
状況が説明されてそれを解決したりその原因について、適切な回答を選択する。

- 効率系
    - コスト効率
        - <https://docs.snowflake.com/ja/guides-overview-cost>
        - 〜を実現するのに最もコストが小さく済むものはどれかを回答する
    - 効率の良いやり方、手順が少なくて済む実現方法
        - <https://www.snowflake.com/blog/best-practices-for-data-ingestion/?lang=ja>
            - 〜を実現するのに最も早く実現できる効率的な方法を回答する
            - よくありそうなのは、snowpipeかtaskでcopy intoか、みたいな
            - snowpipeはデータが取り込まれたときにのみ料金が発生するため、スケーラビリティとコスト効率がいい的な話
            - 定期的なデータのコピーはtaskでcopy into
            - 外部ストレージにあるデータを使った例では、外部テーブル+マテリアライズドビューの構成もありだが、導入が大変(手順等が多い)ので、少ない手順で導入できるかどうかという点で問われると選択肢から外れそう
 
- 復旧系
    - 破損したデータを戻したい時とか
        - 各種テーブルの使い分け
            - <https://docs.snowflake.com/ja/user-guide/tables-temp-transient>
        -  time travelの理解
            -  <https://docs.snowflake.com/ja/user-guide/data-time-travel>
        - 例 : 破損した永続テーブルを復旧するには？
            - time travelを使って破損直前の状態をcloneする
                - 最初に思いつきそうなのはこれ
                - 破損前をもとに復元したら良さそう
            - 復元の過程でtemporaryを使う？
                - セッションをまたがないならこれでも
                - セッションを跨ぎそうな手順や条件になっていると注意
                - temporaryをcloneしようとしている手順なら、そもそもできないので注意
            - 復元の過程でtransientを使う？
                - 後で明示的に削除することを考慮でこれ
                - 「最小の手順」等の観点で問われていると、こちらは後で削除する必要があるので注意
                - 「最小の手順+最小のコスト」という点では、cloneが可能で1日のtime travelのみ、かつfail-safeがないので、通常のテーブル程のストレージコストを取らない、という点では最適解と言える
            - 永続化テーブルを別名で作成 -> 破損している元テーブル削除 -> 永続かテーブルをリネームして本来の名前にする？
                - 細かい流れを問われるので、それで正しい挙動なのか、解決したい要件を満たせるのかを読み解く必要がある
                - fail-safeが有効になるのとやtime travelが1日になるため、コスト面で無駄になっていないか、余計な手順が入っていないか、とかにも注意
        - 例 : タイムトラベル x クローン x undrop
            - undropが失敗する条件も考慮しておく
                - https://docs.snowflake.com/ja/sql-reference/sql/undrop-table
                    - 同じ名前のスキーマが既に存在する場合、エラーが返されます
            - dropされたスキーマと同じ名前の新しいスキーマが存在する時に要注意
                - drop後の復活はtime travelを使ってできるので、同名の新しいテーブルが邪魔になっている時は一旦名前を変えてundropのエラーを回避しておいて、以前のデータ復元を使用する、みたいな活用もできる(そういう発想も求められる)
- 接続環境/ネットワーク系
    - 接続環境が厳しい(VPN、VDIとか)なら、プライベート接続をつかう
    - この場合、ログイン管理も楽にしたいので、すでに社内で使っている何らかのIdPを活用してSSO認証もセットになる感じか
    - Azure ADSSO
        - プライベートリンクURLを使用するように設定する
        - 接続元IPをネットワークポリシーの許可リストに追加する

### クエリプロファイルからの読み取り

- <https://docs.snowflake.com/ja/user-guide/ui-query-profile>
    - 結合爆発の発生とか
    - spillしている状態とか
    - 非効率なプルーニングとか

### セカンダリロール

- <https://docs.snowflake.com/ja/user-guide/security-access-control-overview#enforcement-model-with-primary-role-and-secondary-roles>
    - セカンダリロールを有効にして、どのクエリがOK/NGになるかを考える
        - ロールA : DB_Aのusage, SCHEMA_Aのusage, 配下のVIEWのselectとcreate
        - ロールB : DB_Bのusage, SCHEMA_Bのusage, 配下のVIEWのselectとcreate
        - ロールAをプライマリ、ロールBをセカンダリとする
        - use db_b ... とコンテキストを変えて、create view ... ができるか？
        - use db_a ... とコンテキストを変えて select * db_b.schema_b.ビュー名 ができるか？ 

### ETL/ELTについて

- <https://www.snowflake.com/wp-content/uploads/2022/06/%E3%82%AA%E3%83%B3%E3%83%95%E3%82%9A%E3%83%AC%E3%83%9F%E3%82%B9%E3%81%AEETL%E3%81%8B%E3%82%89%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%88%E3%82%99%E3%83%88%E3%82%99%E3%83%AA%E3%83%95%E3%82%99%E3%83%B3%E3%81%AEELT%E3%81%B8.pdf>
- <https://www.snowflake.com/ja/guides/etl-vs-elt/>
    - SnowflakeではELT
        - 先にL(ロード)しておき、後でT(変換)する、という方針
    - 仮想ウェアハウスを使うことの恩恵(特にスケーラブル)があるということ
    - ETLは変換->ロードの流れなので、ELTではロードと変換が分離できる
        - ETLは変換中のエラーがあるとまたロードし直しといったことも気にしないといけない

### スタースキーマ

- <https://www.integrate.io/jp/blog/snowflake-schemas-vs-star-schemas-what-are-they-and-how-are-they-different-ja/>
- <https://www.guru99.com/ja/star-snowflake-data-warehousing.html>

### Data Vault

- <https://www.snowflake.com/data-cloud-glossary/data-vault/?lang=ja>
- <https://www.snowflake.com/blog/data-vault-technique-immutable-storage/?lang=ja>
- <https://www.snowflake.com/blog/data-vault-techinques-hub-locking/?lang=ja>
- <https://dev.classmethod.jp/articles/data-vault-modelling-on-snowflake/>

## 出なかった / 思ったよりあまり出なかったもの

- True/False選択 (でなかった)
- ウェアハウスの実行時間 (でなかった)
- コスト試算 (でなかった)
- クエリアクセラレーション (選択肢にはいた)
- 半構造化データのクエリ (少しでた)
    - 指定方法の複数選択
    - ドット指定、[]で要素指定とか

## その他

- UdemyやFullCertifiedの模擬試験から似たものが出たっぽい
  - 特にUdemyのやつ
  - 選択肢の位置(番号)が異なるバージョンとか
  - ちょっとだけ記述違いな感じとかもあった