Snowflake×dbt×Terraformでモダンなデータ基盤開発してみた

by Kosaku Ono

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© Nowcast, Inc. ⾃⼰紹介⼤野巧作 ● けびんと呼ばれています ● 2020年ナウキャスト新卒⼊社 ● データエンジニア・データサイエンティスト ○ POSデータのパイプライン作成・運⽤ ○ 社内の新規データ分析基盤構築 ● Twitter等はKevinrobot34 ● 略歴 ○ 東京⼤学⼤学院理学系研究科にて、素粒⼦理論を専攻。在学中いくつかのITベンチャーでインターンを経験し、機械学習を⽤いたプロジェクトに従事。2020年3⽉に⼤学院修了後、ナウキャストへ⼊社。POSデータを取り扱うパイプラインの作成・運⽤と、全社のデータ分析基盤の作成に取り組んでいる。趣味はAtCoderやKaggleのコンペ参加。KaggleではCompetition Masterを獲得したほか、複数のコンペで受賞歴あり。 3

Slide 4

Slide 4 text

© Nowcast, Inc. 会社紹介ナウキャストはAlternative Dataを利活⽤を進めている会社 4 オルタナティブデータとは、元々は⾦融領域の⽤語で、伝統的に使われてきた財務情報や経済統計のようなデータ（Traditional Data）に対して、これまで利活⽤の進んでこなかったビッグデータのことを指します。データ利活⽤が活発なアメリカでは、様々な種類のオルタナティブデータがサービスとして実際に提供されています。参考) オルタナティブデータとは

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© Nowcast, Inc. 背景ナウキャストでは新しい基盤システムを構築中既存のシステムやチーム体制にある課題を解決するために、ナウキャストでは最近プラットフォームチームを⽴ち上げ、新たなデータ分析基盤システムを構築中 ● 細かな論点は過去の弊社のイベント (DataOpsNight) でも発表しているので是⾮ご覧ください︕ ● 分析基盤として Snowflake を中⼼に、 dbt などのモダンデータスタックを使うことにしている ○ 今⽇はこちらについて紹介します 6

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© Nowcast, Inc. Snowflake関係 Snowflake のリソースの切り分け ● Database は環境（dev / stg / prod）ごとに分ける ● データソースごとに以下を作成 ○ Schema と stage などのその他 schema objects ○ Role ○ Warehouse ○ Role も Warehouse も Schemaに紐づく粒度で切り分けるイメージ Snowflake では Warehouse (計算資源) とストレージが分離されているのでリソースの⾷い合いなどが起きない設計が可能︕ 9

Slide 10

Slide 10 text

© Nowcast, Inc. Terraform関係 Terraform の⽤語 ● Terraform ○ IaC (Infrastructure as Code) ツール ○ AWS や GCP のリソースを Terraform で管理している⼈は多いと思うが、 Snowflake のリソースも Terraform で宣⾔的に管理することが可能 ● Terraform module ○ 複数のリソースのセットのこと ○ 例えば dev / stg / prod で同じ設定を再利⽤したい時に便利 ● Atlantis ○ Terraform の plan / apply を Github の PR ベースで実現する OSSのツール ○ 要は GitOps な Terraform の CI / CD 10

Slide 11

Slide 11 text

© Nowcast, Inc. Terraform関係 Terraform moduleで50以上のリソースを簡単に作成 ● 先ほど紹介した、 Schema / Role / Warehouse はもちろんのこと、これらのリソースごとに Grant の設定もしなければならない ○ 右図のように様々なリソース（少なくとも50個）が必要 ● また命名規則も作り、リソース名から⽤途が判別しやすくしたい → まさに Terraform module が使いやすい 11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© Nowcast, Inc. Terraform関係 Atlantis による誰でも簡単に Terraform が使える環境 ● Platformチームしかインフラを触れないという状況だとスケールしない ● Atlantis を使えば Github で PR を作成し、 Approve をもらわないと apply できないといった機能がある → 権限の追加や、新規データソース⽤のリソース作成など多くのエンジニアが⾃律的に動ける状況を実現 13

Slide 14

Slide 14 text

© Nowcast, Inc. Terraform関係 Snowflake Provider を使う際の Tips ● depends_on で明⽰的に依存関係を指定 ● prevent_destroy = true で⼤切なリソースは守る ● grant 関係のオプションはうまく活⽤ ○ enable_multiple_grants ○ on_future / on_all ● Provider のバージョンが⽐較的頻繁に上がるので Github repo を定期的に確認する 14

Slide 15

Slide 15 text

© Nowcast, Inc. 背景元々の環境・問題点② ● データカタログやデータのリネージュが整備されてない ● AWSアカウントに構築されてきたパイプラインはS3とAthenaをベースとしたものが多い ○ 以下の繰り返し ■ S3 に parquet でデータを配置し、Athena テーブルを作成しておく ■ ECSからAthenaにクエリを投げて適宜 S3 に置く ○ Athena がパフォーマンス的に遅くて困ることが度々あった ● 上記以外にも、PythonでガッツリETLしているパイプラインももちろんある 15

Slide 16

Slide 16 text

© Nowcast, Inc. dbt関係 External Table の設定 ● Athena テーブルが作られているので、その S3 バケットを外部ステージとして設定することで、簡単に Snowflake の世界にデータを取り込める ● またそれをどこからでもスタートできる ○ パイプラインによって全てをいきなり Snowflake へ移⾏するのは⼤変、という場合には下流の処理から順次対応が可能 16

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© Nowcast, Inc. 今後の展望 ● dbt docs をそのままホスティングするのではなく、 Notion などに載せる ○ Github Action の dbt-docs-to-notion 的なイメージ ● dbt python モデルを便利に使える環境を作ることで、PythonでガッツリETLしてるようなパイプラインもSnowflakeの世界へ移⾏しやすくする ● Quicksight等のBIツールと繋ぎ込みやすくする ● … などなど、Snowflake と terraform そして dbt をフル活⽤して分析基盤を進化させていく予定です︕ 18