Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

E43a47bb90476a0bf6fd7fd5ab61b094?s=128

Shuichiro MAKIGAKI

July 28, 2020
Tweet

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で上手く隠せそうです。
  28. 28

  29. 29

  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.