次世代データ基盤として始めたSnowflake検証について

1. © Chatwork
次世代データ基盤としての
Snowflakeの可能性
プロダクト本部CTO室 三ツ橋和宏
2021年12月08日

2. 発表者について
2
○業務経験
前職では長年に渡ってアドテクノロジーのデータ処理を担当。
オンプレHadoop, EMR, Redshift, Spark, BigQuery, Beam...etc
○住まい
埼玉県比企郡。森、山、田んぼ緑多い。
近くに吉見百穴という古代の遺跡あり。
○趣味
平日プチ断食(オートファジー)
週末ランニング。

3. おことわり。
3
● 本セッションの内容は、個人の見解であり、所属する組織の見解ではありません。
● この資料で提示する評価は、当社の特定状況における問題解決に対する評価であり、
製品の優劣を示すものではありません。
● 本セッションにある実装は、検証段階のものであり実用に適しない可能性があります。

4. 4
数年先を見据えた次世代データ基盤
Snowflakeの可能性
point1：無限拡張可能なコンピュートリソース
point2：開発と運用を省力化
さらに使いこなしたい機能
まとめ
1
2
3
4
5
6
AGENDA
アジェンダ

5. 数年先を見据えた次世代データ基盤
5
SECTION
TITLE １
セクションタイトル

6. 現行データ基盤について
6
データ連携
◆ETL
・各種データソースから必要なデータを
ETLで取得
分析・可視化
◆可視化
・各部署、各自で使いやすいツー
ルを使って可視化。
・GoogleSheet, Redashがよく使
われている。
◆DWH、データレイク
・分析・可視化したいデータは
TreasureDataへ集まる
・ワークフロー(digdag)によって各
種中間データ生成

7. 数年後までに必要なことと、現行のボトルネック。
7
◎Chatworkビジネス版スーパーアプリ構想によるデータ基盤への影響。
・データ連携(データソース)が増える。
・DWHのデータ量が加速度的に増える。
・分析・可視化要望が 加速度的に増える。(データドリブン開発・データ民主化 )
◆データ連携
都度の個別対応。
- 必要に応じて個別の
ETL実装。
- 重い処理では結果書き出しに数時間かかる処理も
出てきた。
- 管理者不明なETLが散見される。
◆DWH(データレイク)
リソース不足が顕著。
- コンピュートリソース不足。
- ストレージ容量逼迫。
- 処理にリソース不足を避けるための実装
- 多数の中間テーブル。
◆分析・可視化
データ同期、DWH制約のダブルパンチ。
- バッチ処理が終わらないとデータが見れない。
- クエリ実行時間が不安定。
- 先ずETLがないと始まらず、開発エンジニア不足による
分析実現の遅延。
赤：クリティカルなボトルネック
緑：解消したいボトルネック
黄：解消できたら嬉しい問題
青：問題なし

8. 数年先を見据えた次世代データ基盤の評価
8
シンプルに見通しをコストで比較できる指針
利用料金、開発コスト、運用コスト、技術的負債の蓄積、精神的負荷...
全ての負荷を合わせてコストとしてグラフを描く。
現行基盤コスト
次世代データ基盤コスト
(横軸：時間。仮定：経過時間に対して同じ機能を提供)
=>損益分岐点への到達の早さで優劣を評価。
コスト曲線がなだらかなほど早く到達できるイメージ。

9. Snowflakeの可能性
9
SECTION
TITLE 2
セクションタイトル

10. Snowflakeの可能性
10
最初は世界で注目を浴びる新進気鋭のDWHとして着目。
下記４つの特性を標榜。
特に赤丸の特性は、まずは対応必須のクリティカルなボトルネック解消に有効なのでは？
無制限かつ瞬時の
パフォーマンスと
スケール
メンテナンスを
極限まで削減
as a Service
すべてのデータが
セキュアに管理
アクセス可能
一つのプラットフォーム
唯一のデータ
たくさんのワークロード

11. Snowflakeの可能性
11
特性を以下２つに言い換え&再編成したポイントで検証。
(前項の言葉は直訳っぽくてシックリ来ないので...)
point1: 無限拡張可能なコンピュートリソース
point2: 開発と運用を省力化

12. point1: 無限拡張可能なコンピュートリソース
12
SECTION
TITLE 3
セクションタイトル

13. 無限拡張可能なコンピュートリソース
13
・データはクラウドストレージ(s3, gcs)に置かれる。
・分けたウェアハウスは、相互影響なく動く。
データサイエンス用 WH
Virtual
Warehouse
Large バッチ用WH
Virtual
Warehouse
Large
Virtual
Warehouse
2X-Large
BI用WH
高頻度更新ダッシュボード用 WH
Virtual Warehouse
Auto Scale – X-Large x 5
Prod DB
=>いくらでも拡張可能(料金さえ払えば)
=>WH分ければ、他WHの影響受けずに同時クエリ実行可能。

14. 無限拡張可能なコンピュートリソース
14
Virtual
warehouse
Cache
Virtual
warehouse
Cache
Virtual
warehouse
Cache
Cache
Virtual
warehouse
Authentication & access control
Infrastructure
Manager
Optimizer
Metadata
Manager
Security
Cloud
Services
Persistent
Data
Store
○WHの仕組み(VirtualWareHouse)
Snowflakeにより管理されたec2インスタンス群で構成される(AWS)。
クエリ実行時に使用。必要に応じて、Cacheや永続データ層（マイクロパーティション）からデータを取得して処理。

15. 無限拡張可能なコンピュートリソース
15
○WHって実用的？
● 課金は時間制。XS・S・M・L・XL・２XL...etc(tシャツサイズ)と用意されていて、倍づつ強くなっていく(課金も)。
● 自動停止、自動再開に対応していて運用手間はかからない。
● クエリ実行性能は、他のDWHと比べて遜色ない。
参照：SnowVillage第３回(https://www.youtube.com/watch?v=StW4ffZZn7w)
=>100億行フルスキャンで1分程度(4XL)

16. 無限拡張可能なコンピュートリソース
16
○WHの運用面
WHを分けると、WH毎にロール制限や予算制限も付けられる。
部単位、チーム単位に分ければ、使い方をそれぞれのチームに任せられる。
=>中央集権的な管理の必要なくなる。
データサイエンス用 WH
(参照・更新、1,000cr/月)
Virtual
Warehouse
Large バッチ用WH
(参照・更新・シェア、無制限 /月)
Virtual
Warehouse
Large
Virtual
Warehouse
2X-Large
BI用WH
(参照のみ、50cr/月)
高頻度更新ダッシュボード用 WH
(参照のみ、100cr/月)
Virtual Warehouse
Auto Scale – X-Large x 5
Prod DB

17. ChatworkIDサービス(ビジネス版スーパーアプリ)での活用
17
ChatworkIDを軸に様々なサービスを利用、管理できるようにするサービス。
実現には多数のデータソース、多数のデータ連携。
それに関わる多数の部署やチームがデータを使う。
=>WHの相互に影響しない性質だけでなく、中央管理がいらない仕組みがよくフィット。

18. 無限拡張可能なコンピュートリソース
18
○効果
コンピュートリソースの奪い合いが無くなり、
ストレージ節約・やりくりも不要となる。
赤：クリティカルなボトルネック
緑：解消したいボトルネック
黄：解消できたら嬉しい問題
青：問題なし
◆データ連携
都度の個別対応。
- 必要に応じて個別の
ETL実装。
- 重い処理では結果書き出しに数時間かかる処理も
出てきた。
- 管理者不明なETLも散見される。
◆DWH(データレイク)
リソース不足が顕著。
- コンピュートリソース取り合い。
- ストレージ容量逼迫。
- リソース不足を避けるための実装
- 多数の中間テーブル。
◆分析・可視化
データ同期、DWH制約のダブルパンチ。
- バッチ処理が終わらないとデータが見れない。
- クエリ実行時間が不安定。
- 先ずETLがないと始まらず、開発エンジニア不足による
分析実現の遅延。
=>ボトルネックは解消効果あり、赤が減り青、緑が増えた。

19. 無限拡張可能なコンピュートリソース
19
現行基盤コスト
Snowflakeデータ基盤コスト
(横軸：時間。仮定：経過時間に対して同じ機能を提供)
○評価
コンピュートリソース競合問題から開放される。
=>コスト増加率が穏やかになり、数年内に損益分岐点に到達しそう。

20. point2: 開発と運用を省力化
20
SECTION
TITLE 4
セクションタイトル

21. 開発と運用を省力化(イメージ)
21
OLTP
Databases
Enterprise
Applications
Third-Party
Web/Log
Data
IoT
Data
Integration
Data
Transformation
Data
Analytics
DWH
Ad Hoc
Analysis
Real-time
Analytics
Operational
Reporting
Streaming
Data Warehouses
Backups
File Sharing
Cubes
Data Lake
Data Science
DATA
SOURCES
DATA
CONSUMERS
CDC Data Marts
省力化とは、当たり前のように実装されているロード前の変換・整形が無くなるイメージ。
=>ELT(ExtractLoadTransfer)という。

22. 開発と運用を省力化
22
Snowflakeは基本的なアプローチとして、ETL(ExtractTransferLoad)よりも、ELT(ExtractLoadTransfer)を推奨。
具体的には下記のような実装で、開発と運用の省力化(ELT)を実現。
● (従来)Json形式の生ログ(半構造化ログ)を入れやすい形へ整えてから、table(DWH)へロード。
=>(Snowflake)生ログのまま自動でtableロード。必要な情報はクエリで抽出。
● (従来)データを予め事前処理で集計してから、DWHへロード。
=>(Snowflake)集計前の元データをtableロード。必要に応じてクエリ集計。
● (従来)個人情報等の情報は全員に見せられないため、保護用のマスク済みtable(DWH)を作る。
=>(Snowflake)クエリ時に動的にマスク（マスク済みtableを別途作る必要なし）。

23. 開発と運用を省力化
23
SnowflakeでELTを実現する機能。
● 外部ステージ。
● Snowpipe
● 半構造化データのネイティブ対応
● UDFs(独自定義関数)
● 動的データマスキング
● 外部データ連携(周辺エコシステム)
ここからはサーバログ分析データの実装を通して検証。

24. 外部ステージ
24
一言でいうと、クラウドストレージ(s3, gcs)をマウントするようなイメージ。
外部ステージ設定するとSQLでクラウドストレージを見れるように。(lsというクエリも用意されてる)
ロード(copy、Snowpipe)、アンロード(データ書き出し)をサクッと実行できる。
スキーマ：PUBLIC
ステージ：S3_TRAINING
=>クラウドストレージのファイルを直接ロードでき、
別途の開発と運用の設計必要なし。
○外部ステージを設定してクエリ(ls)
○AWS上のファイル(awsコマンドでls)
=

25. Snowpipe
25
クラウドストレージからニアリアルタイムでデータロードする仕組み。
最頻1分間隔で追加されたファイルを自動ロードする。(現状はファイル名のみ)
サーバレスローダ
Snowpipeサービス
ファイル追加
イベント通知
外部ステージ
Snowflake
テーブル
追加ファイルを順次ロード
=>定期ロード機能の開発・運用が不要。
AWSではS3通知機能を使った仕組みで動く。
一度パスを指定すれば、更新を自動検知してロードしてくれる。
(WHは使わずSnowflakeクラウドサービス層の動作)
○サーバログ(AWS)をSnowpipe設定後クエリ。

26. 半構造化データのネイティブ対応
26
半構造化データを扱うVARIANT型が用意され、半構造化フォーマット(JSON, XML, Avro, Parquet, ORC)をそのままテーブル
へロード可能。
そこから、クエリで要素を指定してデータを抽出できる。(LATERAL結合, FLATTENでネスト構造にも対処可能)
=>ELTの要といっても過言ではない機能。
DWHロード前処理(開発)不要へ。
Snowpipeでロードしたログ(jsonl、１レコード)
○前項Snowpipeでロードされた半構造化データを、
特定の要素データのみ抽出。

27. UDFs(独自定義関数)
27
JavaScript(もしくはJava)で記述可能。既定SQL関数は処理できない独自関数を作れる機能。
=>半構造化データ抽出に突破力もたらす。
半構造化クエリとの合わせ技でELTを実用的に。
○前項までのSnowpipeロードデータから、nginxログ要素を取り出して分析用データへ変換するUDFを作成
1.nginx標準フォーマット(スペース区切り)を、要素名付きJsonへ変換するJavascriptUDFを作成(赤枠)。
2.1を使って、分析に必要な要素を抽出(select文)。

28. 動的データマスキング
28
アカウント権限によりクエリ結果のマスク状態を動的に切り替える機能。
=>閲覧制限テーブルの撲滅、データ量削減、情報鮮度保つ。
○前項までに作った分析用テーブルに対して、役割(ロール)によってデータの見え方をコントロールする。
・分析用テーブルのIP,UAに対してデータマスキングを設定。
=> 同じクエリを実行してもロールにより見える情報が違う(赤枠)
●DEVELOPERロール ●PUBLICロール
<>
関数を使った、一部マスク化や外部トークン化も可能。

29. 開発と運用を省力化
29
○実装検証まとめ
・SnowflakeのELT機能を使うと、前処理や特殊テーブル生成をスキップできる。
・生データロード済みのため、分析要件変更にもSQL修正で対応可能。
外部ステージ
（生データ）
特殊テーブル

30. 外部データ同期(周辺エコシステム)
30
Snowflakeの外側データのELTを強力にサポートする周辺エコシステムも充実している。
パートナー
接続

31. =>データ取り込み開発なし&極小運用可能。
個別API対応は地雷原なので避けたいところ...
外部データ同期(Fivetran)
31
DataIntegrationの一角のFivetranで、Salesforce(sandbox)同期設定してみるとあっさり完了。
Salesforce以外にも数多くのデータソースに対応(RDS, Hubspot, Market, Zendesk...)
○Salesforce(sandbox)設定
パートナー
接続

32. 開発と運用を省力化
32
◆データ連携
都度の個別対応。
- 必要に応じて個別の
ETL実装。
- 重い処理では結果書き出しに数時間かかる処理も
出てきた。
- 管理者不明なETLも散見される。
◆DWH(データレイク)
リソース不足が顕著。
- コンピュートリソース取り合い。
- ストレージ容量逼迫。
- リソース不足を避けるための実装
- 多数の中間テーブル。
◆分析・可視化
データ同期、DWH制約のダブルパンチ。
- バッチ処理が終わらないとデータが見れない。
- クエリ実行時間が不安定。
- 先ずETLがないと始まらず、開発エンジニア不足による
分析実現の遅延。
赤：クリティカルなボトルネック
緑：解消したいボトルネック
黄：解消できたら嬉しい問題
青：問題なし
○効果
SnowflakeのELT機能により、開発と運用労力を大幅に削減できる。
=>ボトルネックはクリティカルが解消される見通し。赤が無くなった。

33. 開発と運用を省力化
33
現行基盤コスト
Snowflakeデータ基盤コスト
(横軸：時間。仮定：経過時間に対して同じ機能を提供)
○評価
コンピュートリソース逼迫問題からの開放に加え、
開発と運用も省力化され、
=>コスト増加率が明確に穏やかになり、より早く確実に損益分岐点に到達見込み。

34. さらに使いこなしたい機能
34
SECTION
TITLE ５
セクションタイトル

35. Data Consumer
View, Query,
Join
Tables
SHARE
さらに使いこなしたい機能
35
○データシェアリング
データクラウドの真髄。
自社だけに閉じないデータ利活用へ。
DATA MARKETPLACE
SHARE
Snowflakeユーザ
(マーケットプレイス )
1
Reader
Account
BI, Query
Tools
Request
List
BI, Query
Tools
Snowflake外のユーザ
2

36. まとめ
36
SECTION
TITLE 6
セクションタイトル

37. 次世代データ基盤としてのSnowflakeの可能性
37
◎結論
Snowflakeの「無限拡張可能なコンピュートリソース」「開発と運用を省力化」特性により下記効果が得られ、
・コンピュートリソース逼迫問題からの開放
・開発と運用を省力化
Chatworkビジネス版スーパーアプリ構想 に必要な、
より柔軟で強い次世代データ基盤実現の可能性を感じられた。
37
参照：
◎Chatworkビジネス版スーパーアプリ構想によるデータ基盤への影響。
・データ連携(データソース)が増える。
・DWHのデータ量が加速度的に増える。
・分析・可視化要望が 加速度的に増える。(データドリブン開発・データ民主化 )

38. 参考資料
38
● 公式ドキュメント
https://docs.snowflake.com/ja/
● SnowVillage(youtube)
https://www.youtube.com/channel/UC-FKvkAWBegvxZF4jkP7sLA
● Snowflake Advent Calendar 2020
https://adventar.org/calendars/5085

39. 39
働くをもっと楽しく、創造的に