これは「AprilKnights Advent Calendar 2024」の5日目の記事です。
https://adventar.org/calendars/10571
はじめに
今年も年末と共にアドベントカレンダーの季節がやってきました。
私個人がなるべく仕事で使った技術に関する記事を書こうと勝手に決めており、去年はOktaについて記事を書いたので、今年は仕事で使っているもう一つのテーマともいえるSnowflakeについて書いて行こうと思います。
Snowflakeのテナントが利用可能になったばかりの状態で一からデータウェアハウスを立ち上げ、整備をしようと悪戦苦闘した際に学んだことを中心にまとめて、少しでも誰かの参考になれば幸いです。
Snowflakeとは？
去年記事を書いたOktaとは違い、Snowflakeと聞いてもピンとこない方もいるのではないでしょうか？(私もそうでした)
Snowflakeとはいわゆるクラウドデータプラットフォームの一つで構造化、半構造化、非構造化データを扱えるデータウェアハウス、データレイクのサービスです。
知らない人向けに簡単な言い方をすると巨大なDBを管理できるWEBサービスみたいなものです。
Snowflakeの構成要素
Oktaの時もそうでしたが、Snowflakeについてもサービスの構成要素を知ることで理解が深まります。
一般的なDBと同じ構成要素もありますが、私が業務で理解した内容を見ていきたいと思います。
アカウント
利用しているSnowflake環境名、公式ドキュメントではアカウント識別子と記載される。
ウェブ上からSnowflakeコンソールを使用する際はアカウントを基に下記のようにSnowflake環境のURLが決定される。
<アカウント>.snowflakecomputing.com
データベース(Database)
一般的なRDBシステムにおけるデータベースと同義、アカウント上で複数のデータベースを管理でき、データベースの配下に複数のスキーマを作成、管理できる。
スキーマ(Shcema)
一般的なRDBシステムにおけるスキーマと同義、スキーマの配下にテーブル、ビューといったRDBシステムでお馴染みのオブジェクトからパイプ、ステージといったSnowflake特有のオブジェクトまでを作成、管理できる。
テーブル(Table)
一般的なRDBシステムにおけるテーブルと同義、ここで注意したいのは主キー制約や外部キー制約をサポートはしていますが、強制はされないという仕様があります。
公式ドキュメントによると他のDBシステムからの移行をサポートするために主キー制約等を定義はできますが、実際に強制されるのはNotNull制約だけのようです。
ステージ(Stage)
スキーマ配下に作られるフォルダのこと、内部的にはクラウド環境にステージに対応したフォルダが作成され、ファイルの管理ができるようになっている。
これを利用してフォルダ内にあるcsvやJSON形式のデータファイルをテーブルにロードしたりできる。
また、テーブルが作成された際に自動的にテーブルステージというテーブルに対応したステージが作成されるので、テーブル単位のデータロードに利用できるようになっている。
ウェアハウス(Warehouse)
いわゆる仮想マシンのようなもの、small,large等のようにサイズを指定でき、SQLの発行やファイルをテーブルにロードする処理等の演算が必要になる様々な操作で使用される。
Snowflakeの料金体系はテーブルの数や規模による課金は発生せず、代わりにウェアハウスをどれだけ稼働させたかという時間に対して課金が発生するようになっている。
ウェアハウスのサイズが大きくなればその分使用できるメモリ量が大きくなるので、大規模データに対応できるようになるが、お試しで使用する分にはX-Smallでも特に困らない。
ロール(Role)
Snowflakeのユーザにはロールが付与されており、AWS等と同様にロールによってできる操作が制御されている。
また、ユーザ側で独自のロールを作成することもできるので、ユーザ部門向け、API経由でアクセスする際に使用する用途等のロールを用意することで、アクセス制御ができるようになっている。
その他
この他にもパイプ(PIPE)やストリーム(Stream)といったSnowflakeにデータを連携するための機能が色々ありますが、こちらは勉強中なので、ここでは割愛します。
Snowflakeを扱っていて感じたこと
Snowflake環境の立ち上げ作業で主に権限周りの設定を行っていたので、スキーマやテーブルに設定できるFUTURE系の権限周りが便利に感じました。
従来のRDBとかでテーブルを作成するとそのテーブルへのアクセス権限を手動で設定する必要があるので、手間になっていましたが、その手間をFUTURE系の権限設定を行うだけで自動化できるのはとても助かります。
例えば、あるスキーマAに対してロールBに"SELECT - FUTURE TABLE"という権限を付与するとスキーマAでテーブルが新規作成されて際に自動的にロールBが"SELECT TABLE"の権限を獲得できるようになります。
この機能があったので、Snowflakeの立ち上げの際にレガシーシステムのDB構成をそのまま移植するのではなく、データ領域とそこにアクセスできるユーザグループを整理して作業を進めることができたので、権限設定周りの作業がかなり省力化できていると感じます。
今後も挙がってくる要望に対してSnowflakeの機能を活用してなるべく手のかからないデータウェアハウスを構築していきたいです。
最後に
自分がSnowflakeの立ち上げを進める際に得た知識を簡単にまとめてみましたが、いかがだったでしょうか？
データ分析基盤は現代のIT業界では一般的な概念になってきていますし、自社でSnowflakeやその他のデータウェアハウスを導入している方も多いのではないかと思います。
Snowflakeって何？というから始めて約一年くらいSnowflakeを触ってきましたが、基本はOracleやSQL ServerのRDBMSと同じ感覚で使えますし、公式ドキュメントも整備されているので、ある程度使いこなせるようになるまでのハードルは思ったよりも低かった印象でした。
Snowflake関連の要望は来年以降も順次出てくる見込みなので、現在の環境の設計思想を忘れないようにしながら柔軟に対応していきたいです。
それでは、今年も一年お世話になった方々への感謝を述べて、この記事を締めたいと思います。
ここまで記事を読んで頂きありがとうございました。
