「みんなのDWH」のためのSnowflake設計

Transcript

1. 「みんなのDWH」のための Snowflake設計 Shuichiro MAKIGAKI 2020-07-28@CA.io #2 Snowflake 1
2. 自己紹介 2 職歴：新卒→某EC社→CyberAgent 主務：全社システム本部 サイバーエージェントグループが展開する各種事業、期間システムの技術支援必要な社内システムを、提案 からグランドデザイン、設計・開発 業務内容システムの技術的な問題の発見・解決デプロイやサーバー構築等の各種自動化のための開発要 件に応じたプラットフォーム、アーキテクチャの選定・構築 その他の属性：AI事業本部 以前はOpenStackやKubernetesをいじる仕事を、最近は機械学習基盤を開発中 その他の属性：博士課程の学生 12月学位取得……予定……予定 ……
3. アジェンダ 1. はじめに 2. ユーザー管理 3. アクセスコントロール 4. データカタログ 5. データ入力ガイドライン 6. 利用量制限 7. 始めてもらうために 8. まとめ 3
4. 1 ｜ はじめに 4
5. 本日話すこと 5 Snowflakeを新規導入するにあたり、 あまり嫌われないような、 みんなのデータウェアハウス（DWH）にするために、 考えたこと・作ったもの・作っているもの・作る予定のもの を話します。
6. と、ここまで喋っていて、アレですが 6 が、実は……
7. 私はDWHというものを 触ったことがありません 7
8. DWHﾅﾆﾓﾜｶﾗﾅｲﾖ... 8 経歴：新卒→某EC社→CyberAgent いずれも、DWHがあったとしても知らな かった。使う必要もなかった。 これは問題です。同じ轍を踏んではいけ ない。 https://ja.wikipedia.org/wiki/三猿
9. そもそもDWHとは 9 "Data warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management's decision making process." W. H. Inmon, "What is a Data Warehouse?" Prism Tech Topic, Vol. 1, No. 1, 1995. https://twitter.com/inmonbill
10. なぜDWHを触ることなく生きてこれたのか 10 （言い訳） 1. 統合DBといったモノが「あると思っていない」 2. 部署やグループごとにサイロ化された管理状態にあり、 データを「見れると思っていない」 「あると思っていない」し「見れると思っていない」ものは、「見たいと思わない」から「見 るわけがない」 ※個人の感想です でもみなさんそうですよね ……？
11. DWHの（技術）担当になるにあたって 11 サービスのビジョン：みんなのDWH >「組織的な準備なども行い、 TSUBAMEの設計を本格的にスタートさせたのは 2004年頃。そこで『圧倒的な計算能力』と共に重視したのが、『 みんなのスパコ ン』というコンセプトです。従来のスパコンは少数のエリートが運用するものでした。私たちはそれを変えたいと思いました。スパコンを使える人材を数多く養成 し、活用領域の裾野も広げたかったのです」 スパコン「TSUBAME」 | 最先端研究のパートナー | 研究を極める https://admissions.titech.ac.jp/research/equipment/tsubame.html
12. DWHのスマートフォン化改革（？） 12 ほんとうは高価だが、雑に扱われる 便利だし、ないと困る ほんとうはできないことが多くあるが、 できないことに気付かない DWHもかくあるべきでは https://unsplash.com/photos/iuU2aZdzp_M
13. 目的 13 使いはじめるための申請は不要 システムが壊れない、壊せない データをカタログから探すことができる データの「責任者」が明瞭 見てはいけないものは見えない これらを以下の問題に帰着させます • ユーザー管理 • アクセスコントロール • データカタログ • データガイドライン • 利用量制限 • モチベーション
14. 注意 14 設計中・開発中のトピックを含みます
15. 2 ｜ ユーザー管理 15
16. 既にログインできますよ 16 SAML 2.0によるSingle Sign On 社員DBをもとにしたユーザー作成 USERのJITプロビジョニングをしてくれないので、事 前に作成しておく必要がある 「工夫」なし！ 常にログインできる状態に
17. 3 ｜ アクセスコントロール 17
18. DatabaseとTableとViewのAC 18 全員が可視のPUBLIC_DB 社員番号・名前・メールアドレス・電話番号・ Linux/AD UIDなどの「公開」情報 他のTABLEとのJOINに便利 PRIVATE系DB：機密情報を含むTABLE 部署単位DB：AWS料金など 共有やPUBLIC化する場合はVIEWを作成
19. DatabaseとTableとView、とColumnのAC 19 ……という作戦を考えていましたが、 今月に入って Column-level Securityに対応 https://www.snowflake.com/blog/column-level-security-in-snowflake/ VIEW作成はこれで代替可能かも？
20. USERとしてのROLE 20 Snowflake基礎： PRIVILEGEのGRANT対象はROLE USERではない バッチによるUSER作成時（前述）に USER固有のROLEを同時に作成 https://docs.snowflake.com/en/user-guide/security-access-control-overview.html
21. USERグループとしてのROLE 21 社内ROLE管理基盤から情報を取得 ですが、基盤は同じ部署＋ αで目下開発中 画面ポチポチでアクセスコントロール、になる予定 GUI化にともなって、権限の可視化が必要に 木構造なので木構造として可視化、が良い筋か？（コメントください）
22. 外部とのデータ共有 22 複数のSnowflakeアカウントが存在し、 相互にデータを参照する必要がある場合 お金の問題、組織の「分割方法」の問題、など まさにSecure Data Shareのユースケー スそのもの https://docs.snowflake.com/en/user-guide/data-sharing-intro.html
23. TL;DR; 23 アクセスコントロールに「銀の弾丸」なし！ 「誰が誰に何を見せるか」を決めるしかない。 あたりまえですが。 Snowflakeはデータのアクセスコントロールに関しては「注意し て」設計してある（ように感じる）ので、アクセスコントロールは 愚直に実装することにしました。 https://unsplash.com/photos/dEXFa9qJeRM
24. 誰がROLEを付けるか 24 アクセスコントロールの最大の問題は「誰がやるか」 我々はやらない 安直な理由：問い合わせ対応がスケールしない 本当の理由：我々は「判断ができない」 判断できる人＝データ「オーナー」のような人物 オーナーは決めれば決まるが、それが誰かを知るにはデータ の「カタログ」が必要 詠み人知らず
25. 4 ｜ データカタログ 25
26. データカタログとは 26 • どのようなデータが保管されているのか • どうやってそこにアクセスすればいいのか • 注意すべき点はあるか • 責任者は誰か を「検索可能な状態に」したもの
27. Azure Data Catalog 27 Azure Data Catalogを検証中 AWS GlueやGCPにも似たサービスはあるが、多くのデータソースに対応できたのは Azure SnowflakeにはODBCで接続し、TABLEやVIEWの情報を自動で抽出し、カタログアイテム化 カタログの各アイテムに「Expert」を指定することができる データカタログを検索 →「アクセス権がほしい」 →「Expertに聞こう」 カタログ上では検索可能だが、実際にアクセス可能かは別問題で、各データのExpert が判断する データのプレビュー機能で見えてはマズいデータをどうするかという問題がありましたが、 Column-level Secutiryで上手く隠せそうです。
30. 個人的なお気に入り機能：用語集 30 例：スーパー電プチ
31. 5 ｜ データ入ガイドライン 31
32. ACLは判断せず、やりたいことを可能にするサポートに注力 32
33. 6 ｜ 利用量制限 33
34. Quota 34 Snowflake基礎：Quota＝Resource Monitor Quotaはリソーススケジューリングの問題ではなく、WH課金の問題 ユーザー数制限なし、ストレージは S3、WHはマネージドで、チューニングする場所がない 現状のスタイル：「どんどん使ってください！」 まずは「とりあえずためておけばいいですよ。あとは Tableauでかっこよくしましょう。」 「お金ですか？実際そんなにかからないので、あんまり気にしなくていいですよ。」
35. とはいえ、お金の配分的な話はあるので 35 あまりに特定グループの使用クレジットが多い場合は分離 データ容量が多い場合：データストアから配賦タグを付与して分離 DWH使用量が多い場合： DWHの分離、アカウントの分離 →外部ユーザー化
36. Quotaなしは、さすがに…… 36 その不安の本質はおそらく 「誰かが勝手にものすごい使ってしまったらどうするのか？」 ではないでしょうか。 個人単位でQuotaをかけましょう。
37. 「ユーザー単位の」Quota 37 ……実は不可能 想像上の理由： WHはクエリが並列に処理され、利用率も処理ごとに異なり、合計も 100％にならないことが 多い。そのうえ、WH自体は時間課金。ユーザー単位での使用量にあまり意味がない。 システムテーブルをクエリすれば概算は取得でき るので、定期バッチによるおおよその監視は可能 SELECT user_name, warehouse_size, sum(total_elapsed_time) FROM "SNOWFLAKE"."ACCOUNT_USAGE"."QUERY_HISTORY" WHERE warehouse_size IS NOT NULL AND start_time BETWEEN '2020-07-01' AND '2020-07-31' GROUP BY user_name, warehouse_size;
38. 仕事の目的などを考えてしまうと、 38 データのアクセスコントロールこそが真の注意点であって、 計算資源の利用制限はあまりかけたくないですよね。犯人捜しが定常運用化するのもイヤですし ……。 まずは始めてみてほしい。
39. 7 ｜ 始めてもらうために 39
40. 「初回プレイ無料」 40 「まずは無料体験」を、どう実装するか？ https://abema.tv/about/premium
41. 「初回プレイ無料」実装 41 「応募された方全員にX円分のクレジットをプレゼント」として実装 1. 応募サイト作成：社内ポータル 2. ユーザー固有のWarehouseの作成 3. Resource MonitorでQuotaを設定 なぜなら、WHにしかQuotaがかからないから RESOURCE_USAGEテーブルを作る案もあったが、リアルタイム性に欠けることと、利用と課金の相関が弱 いことから、「WHをつくってしまう」という思い切りで実装。計算資源の分離により他の人の迷惑になる心配も ない。WH作るだけならタダなので……。
42. 8 ｜ まとめ 42
43. 本日話したこと 43 Snowflakeを新規導入するにあたり、 あまり嫌われないような、みんなのDWHにするために、 考えたこと・作ったもの・作っているもの・作る予定のもの を話しました。 • ユーザー作成・アクセスコントロール：銀の弾丸なし。シンプルに。 • データカタログとガイドラインで人に優しく • 利用制限は（ほぼ）なし！いったんは後で考えましょう。 • 初回プレイ無料
44. DWHが生み出す価値とは 44 An Inside Look at Google BigQuery (https://cloud.google.com/files/BigQueryTechnicalWP.pdf) Can you imagine how Google handles this kind of Big Data during daily operations? Just to give you an idea, consider the following scenarios: • What if a director suddenly asks, “Hey, can you give me yesterday’s number of impressions for AdWords display ads – but only in the Tokyo region?”. • Or, “Can you quickly draw a graph of AdWords traffic trends for this particular region and for this specific time interval in a day?” What kind of technology would you use to scan Big Data at blazing speeds so you could answer the director’s questions within a few minutes? If you worked at Google, the answer would be Dremel. Dremel is a query service that allows you to run SQL-like queries against very, very large data sets and get accurate results in mere seconds. You just need a basic knowledge of SQL to query extremely large datasets in an ad hoc manner. At Google, engineers and non-engineers alike, including analysts, tech support staff and technical account managers, use this technology many times a day.