Snowflake

snowpipeによる分析基盤

terraform
snowflakeの構成管理

テーブル利用状況

pros cons
snow pipe or workflow engine

cost
Snowflake — Cost Saving

dbt

Data Load
snowflake task

stream
stageとかtableのイベントを通知受け取れる
AppendOnlyとかで回せばよさそう

snowpipe backfill

copy intoの変数化。やろうと思えばできる。というか、頑張ればなんでも出来る・

snowpipe copy into実装パターン

AWS_SNS_TOPIC = '<SNSトピックARN>'で指定すれば、いちいちサブスクライブしなくてよさそう。あとは権限管理をいい感じにすればいい。

Redshift vs Snoflake
Snowflakeのが簡単でメンテナンスフリーという印象。Redshiftだと多少メンテ頑張る必要がある。特にスケーリング周りなど。あとはクエリがアドホックに比較的重めなやつが適当に投げられると全体が重くなるとか。
あとはJSON系の扱いやすさはSnowflake

COPY vs Snowpipe
Overview Snowpipe

Snowflake 開発環境
Multiple Env

Access Controll

Blue green deploy

Snowflake x dbt x streming

大量データ処理のためのincremental

An overview of data loading options in Snowflake

A deep dive into Snowflake’s alerting and notification features

A deep dive into Snowflake storage costs

Our Top 7 Snowflake RBAC Best Practices
ヒント1. 最小特権の原則から始める
わかる。
ヒント2. アクセス、機能、サービスの役割
Access Roles: データベースへのアクセスを制御するために使用されます;
Functional Roles: 社内のSnowflakeユーザに付与され、必要なアクセスロールを付与することでアクセスレベルが制御されます(最小特権の原則に従います);
Service Roles: Functional Rolesと全く同じように機能しますが、唯一の違いはサービス向けであり、エンド(人間)ユーザー向けではないということです。
DRYな役割階層を作る
企業で必要とされる機能的役割とサービス的役割を定義する。
DATA_ANALYSTとかそういう粒度でまとめる。
アクセス ロールを作成する。
機能ロールとサービスロールを作成する(そしてそれらにアクセスロールを付与する)。
ユーザーには機能ロールを、サービスアカウントにはサービスロールを付与する。
わかる
⛔ アクセス ロールをエンド ユーザー/サービス アカウントに直接付与しない。
わかる。
Accessロールの作成時にFutureのGrantを活用する
大事
Grant Functional Roles to SYSADMIN
大事
Tip 7. You probably don't need ACCOUNTADMIN for that…
Or in other words, use appropriate roles for all administrative operations you perform. Remember the Principle of Least Privilege!
The ACCOUNTADMIN role by default has way more privileges than the ones needed for your daily operations/chores, so you should avoid using it unless there is a good reason. Here is what you can use instead for common operations:
ユーザやロールを作成する必要がある場合は、USERADMIN を使用してください!
グラントを管理する (例えば、ユーザーにロールを付与する) 必要がある場合は、SECURITYADMINを使用してください!
データベース、スキーマ、仮想ウェアハウスなどのオブジェクトを作成する必要がある場合は、SYSADMINを使用してください!
テーブルやビューなどのデータベースやデータベースオブジェクトを作成する必要がある場合は、SYSADMINを使用できます!
与えられたテーブル上でアドホックなデータ操作を行いたい場合(SELECTやINSERTのように)、適切なFunctionalロールを使用してください!
最後に、サードパーティのサービスをSnowflakeに接続する場合、ACCOUNTADMIN は絶対に使用しないでください! 代わりに、適切なサービス・ロールを作成して使用してください :)

Snowflake Roles 101: Comprehensive Guide to Access Control
Snowflake は、Role-Based Access Control (RBAC) アプローチに従って、ユーザーや他のシステムがアクセスできること、できることを管理します。 RBAC では、特定の role を持つことは、特定の権限を付与されることを意味します。
- User - 人(またはサービス)が Snowflake に接続するためのエンティティ。
Object - ユーザーが適切な権限を持っていればアクセスできるエンティティ(テーブル、ビュー、データベースなど)。
Privilege - ユーザがオブジェクトに対して実行できる操作。
Role - ユーザーとプリビレッジの橋渡しをするエンティティ。 特権はロールに付与され、ロールはユーザに付与されます。
PrivilegeはRoleに付与され、RoleはUserに付与され、Userがシステム内のObjectに対して実行できる操作を指定します。
この説明かなり分かりやすいな。
Ownership Privilege
Discretionary Access Control (DAC).
各オブジェクトはそのオブジェクトの作成に使用された Role によって所有されます。 Role がオブジェクトを所有するということは、OWNERSHIP権限を持つことを意味します。
Role
SnowflakeのRoleは鍵だと考えることができます。 あなたは自宅の鍵、車の鍵、オフィスの鍵を持っています。 もし近所に親しい人がいれば、その人があなたの家のスペアキーを持っているかもしれません(緊急時に備えて)。 あなたの家の鍵は、あなたとあなたの隣人の両方にアクセスを許可します。
Role Types
- account roles
- database roles
- instance roles
Role Hierarchy
Default Snowflake Account Roles

SnowflakeでCTEを使うべきか?