LoginSignup
2
3
@changkuhu(chang)

Snowflake 学習/受講メモ (Architect)

Last updated at Posted at 2024-03-17

これは何？

Snowfalke認定の資格試験「Snowflake SnowPro Advanced Architect」に関して、全体感の大雑把メモ。
2024年になって日本語版がリリースされたので、早速やってみての振り返りを兼ねて。

試験情報

  • 試験について : 公式情報(Study Guide)
  • 問題数 : 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 : ステージングされたデータファイルの各記録の行番号を表示する疑似列。
        • 多分、選択肢には外部テーブルの仮想列とストリームの列が出てきてややこしいので、問いに合わせて正しい列名を選べるようにしておくこと
    • 仮想列のマスキング
  • 例 : 外部テーブルに行アクセスポリシーを適用できる？
    • VALUE列に適用できる
      • CREATE EXTERNAL TABLEまたはALTER TABLE
    • 仮想列には直接適用できない
      • 外部テーブルのビューを作って、そのビューの列に行アクセスポリシーを当てることで間接的に適用することはできる
  • 外部テーブル x マテリアライズドビューのユースケースも押さえておく

認証/セキュリティ

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

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

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

クエリの実行結果

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

権限

管理アクセススキーマ

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

キャッシュ

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

ORGADMIN

パラメータ

半構造データ

行アクセスポリシー

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

  • 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

Snowflakeデータベース

  • account_usageとかのSnowflakeデータベース、information_schemaの使い分け
  • WAREHOUSE_LOAD_HISTORY
    • これを使ってウェアハウスのワークロードを分析するとか
  • とあるビューやテーブル関数を使って何ができる(何がわかる)、とか
  • とあるビュー名が問題で与えられて、選択肢として「information_schemaにある」とか「account_usageにある」とかが問われることも

メタデータ

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://www.snowflake.com/blog/best-practices-for-data-ingestion/?lang=ja
        • 〜を実現するのに最も早く実現できる効率的な方法を回答する
        • よくありそうなのは、snowpipeかtaskでcopy intoか、みたいな
        • snowpipeはデータが取り込まれたときにのみ料金が発生するため、スケーラビリティとコスト効率がいい的な話
        • 定期的なデータのコピーはtaskでcopy into
        • 外部ストレージにあるデータを使った例では、外部テーブル+マテリアライズドビューの構成もありだが、導入が大変(手順等が多い)ので、少ない手順で導入できるかどうかという点で問われると選択肢から外れそう

  • 復旧系

    • 破損したデータを戻したい時とか
      • 各種テーブルの使い分け
      • time travelの理解
      • 例 : 破損した永続テーブルを復旧するには？
        • time travelを使って破損直前の状態をcloneする
          • 最初に思いつきそうなのはこれ
          • 破損前をもとに復元したら良さそう
        • 復元の過程でtemporaryを使う？
          • セッションをまたがないならこれでも
          • セッションを跨ぎそうな手順や条件になっていると注意
          • temporaryをcloneしようとしている手順なら、そもそもできないので注意
        • 復元の過程でtransientを使う？
          • 後で明示的に削除することを考慮でこれ
          • 「最小の手順」等の観点で問われていると、こちらは後で削除する必要があるので注意
          • 「最小の手順+最小のコスト」という点では、cloneが可能で1日のtime travelのみ、かつfail-safeがないので、通常のテーブル程のストレージコストを取らない、という点では最適解と言える
        • 永続化テーブルを別名で作成 -> 破損している元テーブル削除 -> 永続かテーブルをリネームして本来の名前にする？
          • 細かい流れを問われるので、それで正しい挙動なのか、解決したい要件を満たせるのかを読み解く必要がある
          • fail-safeが有効になるのとやtime travelが1日になるため、コスト面で無駄になっていないか、余計な手順が入っていないか、とかにも注意
      • 例 : タイムトラベル x クローン x undrop
        • undropが失敗する条件も考慮しておく
        • dropされたスキーマと同じ名前の新しいスキーマが存在する時に要注意
          • drop後の復活はtime travelを使ってできるので、同名の新しいテーブルが邪魔になっている時は一旦名前を変えてundropのエラーを回避しておいて、以前のデータ復元を使用する、みたいな活用もできる(そういう発想も求められる)

  • 接続環境/ネットワーク系

    • 接続環境が厳しい(VPN、VDIとか)なら、プライベート接続をつかう
    • この場合、ログイン管理も楽にしたいので、すでに社内で使っている何らかのIdPを活用してSSO認証もセットになる感じか
    • Azure ADSSO
      • プライベートリンクURLを使用するように設定する
      • 接続元IPをネットワークポリシーの許可リストに追加する

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

セカンダリロール

ETL/ELTについて

スタースキーマ

Data Vault

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

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

その他

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
3