Slide 1
Slide 1 text
© 2025 Snowflake Inc. All Rights Reserved
初期段階で検討しておきたいこと
Snowflakeでデータ基盤を
もう一度作り直すなら
近森 淳平 pei
Data Superhero
Slide 2
Slide 2 text
https://speakerdeck.com/pei0804/strongest-data-architecture-discussion
Slide 3
Slide 3 text
Snowflakeベースのデータ基盤を構築してから、
ちょうど3年が経ちました。
この間、弊社の株主、経営体制、開発体制、肩書。
Snowflake自体の進化やChatGPTの登場など、
会社、業界、私自身にも目まぐるしい変化がありました。
それらの変化を超えてきたからこそ、
普遍的に重要だったと思える設計判断がいくつかあります。
ぼくの最高を構築してから3年
Slide 4
Slide 4 text
今日話すこと
私自身の3年間のデータ基盤運用経験と、
SnowVillageで共有された『あるある』から見えてきた、
初期から考慮すべき設計の勘所についてです。
これから基盤を作る皆さんのヒントになれば幸いです。
また、既に構築済みの方にとっては、
いまの辛さの原因を知る手がかりになるかもしれません。
Slide 5
Slide 5 text
アジェンダ
● 自己紹介
● アカウントはどう分けるべきか？
● どのツールを選ぶか？
● Functional Roleをどう設計するか？
● データベースをどう分けるか
● おまけ：細かいけど重要
Slide 6
Slide 6 text
アジェンダ
● 自己紹介
● アカウントはどう分けるべきか？
● どのツールを選ぶか？
● Functional Roleをどう設計するか？
● データベースをどう分けるか
● おまけ：細かいけど重要
Slide 7
Slide 7 text
自己紹介
ぺい
@pei0804
近森淳平(チカモリ ジュンペイ)
VP of Data @ CARTA ZERO / CARTA HOLDINGS
2024, 2025 Snowflake Data Superheroes
Slide 8
Slide 8 text
アジェンダ
● 自己紹介
● アカウントはどう分けるべきか？
● どのツールを選ぶか？
● Functional Roleをどう設計するか？
● データベースをどう分けるか
● おまけ：細かいけど重要
Slide 9
Slide 9 text
アカウントはどう分けるべきか？
アカウントの粒度は、早い段階で決める必要があります。
そして後から変更が困難なため、重要な判断です。
結論から言うと、「分けることで何が得られるのか？」に
明確に答えられないなら、分割は避けるべきです。
Slide 10
Slide 10 text
分かれすぎたアカウントの苦労話
ありがちなのが、プロダクトごとにアカウントを分けるパターンです。
立ち上げ期はうまく回りますが、活用が進むと課題が出てきます。
例えば、複数プロダクトのデータを組み合わせて新しい
インサイトを得たいケース。アカウントが分かれていると、
まずシェアリングの設定から始めなければならず、
ちょっとした調査でも一苦労です。かといって後から統合しようにも、
別々に育ったものを1つにまとめるのは容易ではありません。
Slide 11
Slide 11 text
アカウントを分ける観点
では、アカウントを分けるべきケースは？
判断の軸は以下の3点です。
● 機密レベル
● データレジデンシー
● エディション
Slide 12
Slide 12 text
機密レベル
同じアカウント内で、機密性が違うデータが共存する場合、
ロールの権限設定ミスが事故に直結する構造になります。
一方、機密性の高いデータを別アカウントに分離すれば、
「誰がアクセスできるか」という判断そのものが単純になります。
ただし、アカウント管理の手間は増えるため、
漏洩リスクと管理コストを天秤にかけて判断しましょう。
Slide 13
Slide 13 text
データレジデンシー
データの保存場所に関する法的・契約的な要件です。
仮に特定の地域にデータを置く必要がある場合、
Snowflakeは、リージョンやクラウドプロバイダーごとに
アカウントを作成する仕組み上、分割が事実上必須となります。
Slide 14
Slide 14 text
エディション
Snowflakeのエディションによって機能と価格が異なるため、
用途に応じて使い分けることがあります。
例えば、データ変換を行うアカウントはStandardで、
機密データを扱うアカウントはBusiness Criticalといった具合。
ですが、分けることによる管理コストもあるので、
そこも考慮しつつ、どこまで分けるか考えましょう。
Slide 15
Slide 15 text
基本、理由がないなら、
アカウントは、１つで良い！
Slide 16
Slide 16 text
アジェンダ
● 自己紹介
● アカウントはどう分けるべきか？
● どのツールを選ぶか？
● Functional Roleをどう設計するか？
● データベースをどう分けるか
● おまけ：細かいけど重要
Slide 17
Slide 17 text
どのツールを選ぶか？
Snowflakeを効果的に活用するには、
Snowflake単体で完結しない領域が必ず出てきます。
初期段階から「どのツールを採用するか」という判断が
求められますし、運用が進む中でも選定の局面は繰り返し訪れます。
ただし、ツールは導入より撤退の方がはるかに難しい。
これを念頭に置いておく必要があります。
Slide 18
Slide 18 text
導入したツールが全く使われなければ、消すだけで済みます。
厄介なのは、中途半端に業務へ浸透してしまったケースです。
特にオーナー不在の状態になると、年単位で放置されることも
珍しくありません。誰かが決断するまで、残り続けます。
だからこそ、「このツールがないと本当に問題は解決しないのか？」
見極めるコストは、導入前に必ず払うべきです。
ツールの撤退は大変
Slide 19
Slide 19 text
無闇にツールを増やさない。
導入するなら、ちゃんとやり切る。
Slide 20
Slide 20 text
https://speakerdeck.com/pei0804/selecting-the-right-data-technology
Slide 21
Slide 21 text
https://findy-tools.io/companies/cartazero/145/36
Slide 22
Slide 22 text
多くのユーザーが抱える課題を、
Snowflakeがネイティブ機能で解決するケースは
珍しくありません。
今すぐ解決すべき課題でなければ、
待つことも有効な選択肢の一つです。
待てば、Snowflakeが
解決してくれることもある
参考：https://www.snowflake.com/en/blog/snowflake-acquire-select-star/
Slide 23
Slide 23 text
アジェンダ
● 自己紹介
● アカウントはどう分けるべきか？
● どのツールを選ぶか？
● Functional Roleをどう設計するか？
● データベースをどう分けるか
● おまけ：細かいけど重要
Slide 24
Slide 24 text
ロール設計の全体像
● Access Role
○ データベース、オブジェクトへのアクセス権限を定義する。
○ このロールで直接操作はしない。
● Functional Role
○ 人間のユーザーが使う。
○ Access Roleを組み合わせて構成。
● Service Role
○ ツール、アプリケーションが使う。
○ Access Roleを組み合わせて構成。
Slide 25
Slide 25 text
ロール設計の全体像
https://select.dev/posts/snowflake-rbac-best-practices
Slide 26
Slide 26 text
Functional Roleをどう設計するか？
Access Roleは対象と操作の組み合わせで機械的に決められます。
Service Roleは多くの場合、最小権限の原則に従えば問題ありません。
一方、Functional Roleは誰にどの権限を与えるかの判断が伴います。
この判断は組織構造やビジネス要件に依存するため、
普遍的に使える設計パターンがありません。
● 部署で分ける？
● 職種で分ける？
● 兼務者はどうする？
Slide 27
Slide 27 text
Functional Roleの設計方針
Who（誰であるか）ではなく、What（何をするか）で設計する。
組織構造は変わりやすい。
データへのアクセスパターンは変わりにくい。
変わりにくいものに依存した設計の方が安定します。
Slide 28
Slide 28 text
Who設計の落とし穴
ENGINEERやANALYSTのように役割ごとにロールを分けがちですが、
クロスファンクショナルな協業が始まると破綻します。
例えば、ANALYSTがENGINEERのダッシュボードを見たい時。
回避策は、ANALYSTにENGINEERロールも付与することになります。
しかし、当然逆のケースも出てきて、
最終的には全員が両方のロールを持ち、分けた意味がなくなっていく。
Slide 29
Slide 29 text
Whatで設計するとは
Whatで設計するとは、「データを見る」のような行為で
ロールを分けることです。
ENGINEERやANALYSTのような役割ではなく、
何をするかを軸にロールを設計します。
では、実際どのくらいの粒度で作ると良いのか？
Slide 30
Slide 30 text
「データを見る」ロールの設計例
「データを見る」ためのロールは1つだけ作る。
このロールは基本的にすべてのデータを閲覧でき、
NotebookやStreamlitも作成できます。
機微データへのアクセス制御が必要な場合にのみ、別途ロールを追加する。
狙いもなしに「このデータを見る」のように対象で分けると、
データのサイロをデータ基盤上に再現することになります。
見せてはいけないデータがないなら、
全員が同じデータを見れる状態の方が管理も活用もスムーズです。
Slide 31
Slide 31 text
TIPS: READONLYという名前は実態に合わない
「データを見る」ロールにREADONLYと名付けると、
実態に合わないケースがよくあります。
例えば、StreamlitやNotebookでデータを見る場合、
オブジェクトを「作る」行為が伴います。
READONLYなのに書き込み権限が必要になるのです。
私は「データを見る」ロールにDATA_EXPLORERと名付けました。
「データを探索する」という行為を表現した名前です。
Slide 32
Slide 32 text
アジェンダ
● 自己紹介
● アカウントはどう分けるべきか？
● どのツールを選ぶか？
● Functional Roleをどう設計するか？
● データベースをどう分けるか
● おまけ：細かいけど重要
Slide 33
Slide 33 text
データベースをどの粒度で切るか
データパイプライン（dbtなど）が扱うデータベースは、
初期段階では3つあれば十分です。よく見かけるのは以下の構成です。
● RAW / PREP / PROD（当スライドはこれを前提に話します）
● RAW / STAGING / MART
● Bronze / Silver / Gold
Slide 34
Slide 34 text
各層の役割例
● RAW
○ 全てのデータが最初に到着する場所。加工は行わない。
● PREP
○ データの変換と品質担保を行う場所。分析可能な状態に整える。
● PROD
○ エンドユーザーに提供するデータを置く場所。
BIツールやアプリケーションはここを参照する。
Slide 35
Slide 35 text
https://speakerdeck.com/pei0804/churadata-event-dbt-2022
Slide 36
Slide 36 text
RAWデータベースを分けるパターン
● RAW_{NAMESPACE}_{LOADER}
○ RAW_NETSUITE_LOADMAN, RAW_NETSUITE_FIVETRAN
ローダー名を含めるのは、一見アンチパターンに見えますが、
実運用上のメリットがあります。
ローダー専用のデータベースであれば、
他ツールとの設定競合を気にせずデフォルト設定で運用できます。
また、不具合時の影響範囲を限定でき、
ローダー切り替え時の移行も容易です。
Slide 37
Slide 37 text
PRODデータベースを分けるパターン
● PROD_{NAMESPACE}
○ PROD_PARTNER_A, PROD_PRODUCT_B
PROD層を分けるのは、主にデータの公開範囲を制御したい場合です。
データを外部に提供する。機密レベルで分離したいケースで有効です。
スキーマレベルで細かく権限管理するより、運用が簡単です。
Slide 38
Slide 38 text
専用データベース
AlertやStreamlitなどのオブジェクトは、必ずどこかのスキーマに属します
ただし、先程の3層のデータベースとは独立して管理したいことがあります。
そのような場合に、用途に特化したデータベースを作ります。
私はこれを「専用データベース」と呼んでいます。
命名ルールは特にありませんが、
オーナーチーム名と、本番か実験用かを区別する命名が多いです。
Slide 39
Slide 39 text
アジェンダ
● 自己紹介
● アカウントはどう分けるべきか？
● どのツールを選ぶか？
● Functional Roleをどう設計するか？
● データベースをどう分けるか
● おまけ：細かいけど重要
Slide 40
Slide 40 text
Terraformで全てのリソースを管理しない
Terraformは変更頻度が低く、再利用したい土台の管理に集中させます。
全てを管理することは本質ではなく、仮に大量のオブジェクトを管理すると
Planに1時間かかる状態に陥ります。
具体的には、アカウントオブジェクト（Warehouse、Database、Role、User）、アク
セス制御（GRANT）、インテグレーション（Snowpipe、External Table）などは
Terraformで管理するのがおすすめです。
Slide 41
Slide 41 text
PoCという名前でリソースを作らない
PoCと名付けたリソースは一時的なものとして作られますが、
実際には削除されずに一生残り続けます。
特に「これ便利じゃん」って使われ始めると消せなくなります。
最初から本番運用を想定した命名規則で作成するか、
削除期限を明確にして問答無用で削除しましょう。
Slide 42
Slide 42 text
Access Roleに `_` Prefixつける
_READ_RAW_DATABASEのように先頭にアンダースコアをつけることで、
Functional Roleと視覚的に区別できます。
機能的な違いはありませんが、ロール一覧画面ではAccess Roleと
Functional Roleを見分ける手段が提供されていないため、
命名規則による区別が効果的です。
また、アルファベット順でソートされた際に
Access Roleがまとまって表示されるため、一覧性も向上します。
Slide 43
Slide 43 text
ロールの階層は深くしすぎない
ロール階層はUser → Functional Role → Access Roleというシンプルな
一方向の流れに留めます。逆にAccess Role同士やFunctional Role同士
で階層化すると、権限のデバッグが困難になるためです。
例えば、Functional Roleをネストさせた場合、
「このユーザーはなぜこのテーブルにアクセスできるのか」を
特定するために複数のロールを順に辿る必要が生じ、
トラブルシューティングの時間が大幅に増加します。
Slide 44
Slide 44 text
PREPはUTCのTIMESTAMP_TZに統一する
RAWレイヤーではソースシステムの形式をそのまま保持しますが、
PREPは全てUTCのTIMESTAMP_TZ型に統一します。
データを見るたびに「これはどのタイムゾーンか」を確認する手間が
発生するため、統一することが重要です。
TIMESTAMP_NTZでUTCを保存することも可能ですが、
TIMESTAMP_TZはタイムゾーンオフセットが明示されるため、
データの可読性が向上します。オフセット情報による追加のストレージ
コストは、一般的なデータ量であれば無視できる範囲です。
Slide 45
Slide 45 text
STATEMENT_TIMEOUT_IN_SECONDSを設定
クエリの最大実行時間
デフォルトは2日間ですが、実運用では長すぎることがほとんどです。
終わらないクエリが何時間も動き続け、
想定外のコストが発生するリスクがあります。
例えば、アカウントレベルで3600秒（1時間）程度に設定しておけば、
問題のあるクエリを自動的に停止できます。
適切な値は用途によって異なりますが、
デフォルトのまま運用することはおすすめしません。
Slide 46
Slide 46 text
DATA_RETENTION_TIME_IN_DAYSは7日
Time Travel（履歴データ保持）の日数
デフォルトは1日ですが、誤削除やバグによるデータ破壊に気づくまでには数日
かかることがあります。特に週末を挟んだ場合、
1日の保持期間では復旧が間に合いません。
初期段階で7日程度に設定しておくことを推奨します。
期間は後から延ばすことができますが、過去に遡って適用することは
できません。ストレージコストは増加しますが、
重要なデータを失うリスクと比較すれば許容できる範囲です。
Slide 47
Slide 47 text
ウェアハウスのAUTO_SUSPENDは60秒
非アクティブ時の自動停止までの待機時間
初期値は10分（600秒）ですが、この設定は多くの場合、長すぎます。
基本的には60秒でサスペンドするように設定しておきましょう。
ただし、ワークロードによっては頻繁な停止と起動が
最小課金時間60秒と相性が悪く、
かえってコストが増えるケースもあります。
Slide 48
Slide 48 text
まとめ
Slide 49
Slide 49 text
本当に必要か？を足す前に考えよう。
消す方が大変。
Slide 50
Slide 50 text
どれだけ考えても、間違える時はある。
けど、続けてさえいれば、やり直せる。
Slide 51
Slide 51 text
© 2025 Snowflake Inc. All Rights Reserved
THANK
YOU