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

事業に貢献するデータ基盤を作ろう・考え方編 / data_engineering_study_2

ShinU
August 19, 2020

事業に貢献するデータ基盤を作ろう・考え方編 / data_engineering_study_2

Data Engineering Study #2「データ収集基盤とデータ整備のこれまでとこれから」https://forkwell.connpass.com/event/182769/

作成者 :しんゆう@データ分析とインテリジェンス
Twitter:https://twitter.com/data_analyst_

ShinU

August 19, 2020
Tweet

More Decks by ShinU

Other Decks in Business

Transcript

  1. 自己紹介 • しんゆう @data_analyst_ • フリーランスでデータに関する仕事をあれこれ • 最近主にやっていること:データを使いやすくする人 • ブログ『データ分析とインテリジェンス』

    noteに移行:https://note.com/shinu • 『データアーキテクト(データ整備人)を”前向きに”考える会』 主催 #前向きデータ整備人
  2. 本日のお話 • 何のためにデータ基盤を作るのか • 価値のない基盤を作らないようにしよう • 基盤と利用のバランスをとろう • 基盤と利用の間にはどんな役割があるか •

    整備は別の役割として認識しよう • もし整備をしなかったらどうなるか • まとめ:データ基盤と整備のこれからの論点
  3. 本日のお話 • 何のためにデータ基盤を作るのか • 価値のない基盤を作らないようにしよう • 基盤と利用のバランスをとろう • 基盤と利用の間にはどんな役割があるか •

    整備は別の役割として認識しよう • もし整備をしなかったらどうなるか • まとめ:データ基盤と整備のこれからの論点
  4. • その中で「収集」フェーズで行うこと 収集は必要なデータを集めるフェーズ 目的の 決定 要求 収集 処理 洞察 伝達

    決定と 実行 フィード バック • 知りたいことのために必要なデータを集めるフェーズ • 欲しいと思ってからでは間に合わない(例えばログ)こともあるので、事前 に準備をしておく必要がある • 準備とは具体的にはタグやセンサーなどを設置してデータを生成したり、 集めて保管しておくための仕組み作り
  5. • その中で「収集」フェーズで行うこと 収集は必要なデータを集めるフェーズ 目的の 決定 要求 収集 処理 洞察 伝達

    決定と 実行 フィード バック • 知りたいことのために必要なデータを集めるフェーズ • 欲しいと思ってからでは間に合わない(例えばログ)こともあるので、事前 に準備をしておく必要がある • 準備とは具体的にはタグやセンサーなどを設置してデータを生成したり、 集めて保管しておくための仕組み作り = データ基盤
  6. 本日のお話 • 何のためにデータ基盤を作るのか • 価値のない基盤を作らないようにしよう • 基盤と利用のバランスをとろう • 基盤と利用の間にはどんな役割があるか •

    整備は別の役割として認識しよう • もし整備をしなかったらどうなるか • まとめ:データ基盤と整備のこれからの論点
  7. 本日のお話 • 何のためにデータ基盤を作るのか • 価値のない基盤を作らないようにしよう • 基盤と利用のバランスをとろう • 基盤と利用の間にはどんな役割があるか •

    整備は別の役割として認識しよう • もし整備をしなかったらどうなるか • まとめ:データ基盤と整備のこれからの論点
  8. • バランス型 • 解決するには基盤と利用をバランスよくやっていくこと • 基盤と利用が個別に扱われがちなので広い視野を持つ • 概念としてはそうなのだが、都合よく人が集まるわけでもなけれ ば両方適度にできる人はもっといない •

    こうすればいい、という明確な答えは無くともどういったモデルが 考えられるかは組織含めて今後の大きな課題の1つ 基盤と活用はバランスよく 利 用 基 盤
  9. 本日のお話 • 何のためにデータ基盤を作るのか • 価値のない基盤を作らないようにしよう • 基盤と利用のバランスをとろう • 基盤と利用の間にはどんな役割があるか •

    整備は別の役割として認識しよう • もし整備をしなかったらどうなるか • まとめ:データ基盤と整備のこれからの論点
  10. 収集されたデータはこの3つのどこかにある データレイク データウェアハウス データマート データの3層構造 • 収集されたデータは3層構造のど こかに格納されている • データレイクは生データ

    • データウェアハウスは統合して整 理したもの • データマートは特定の目的のため ということにはなっているが線引き はわりとあいまい(特に後者2つ)
  11. 基盤作りはデータレイクに入れるまでが中心 データレイク データウェアハウス データマート 処理 洞察 基盤はデータレイクに入れるところ • 基盤を作るという話はデータレイ クに入れるところまでが中心

    • タグやセンサーを設置してデータ を生成したり、集めたデータをバッ チ処理・ETLで処理する • ちゃんと動いているかの監視や権 限・コスト周りの運用 • アーキテクチャにはDWHやDMも 含まれるがあまり踏み込まない 意思決定
  12. 利用とはすでにあるデータを扱うこと データレイク データウェアハウス データマート 処理 洞察 利用とはすでにあるデータを扱う • データを集計したりモデリングした り、なぜそうなるかを考えたりする

    プロセスの処理・洞察フェーズ • 「分析」というとここだけを指すこ ともよくある • すでにデータが存在していてそこ からどうするかが主題 意思決定
  13. 間にある役割は大きく分けて3種類 データレイク データウェアハウス データマート 処理 洞察 間にある役割は3種類 • 基盤と利用の間にある役割を拾っ てみると大きく分けて次の3種類

    • ① 必要なデータを作って利用す る人へ渡す • ② ①が速やかに出来るように DWHやDMを設計・作成して整理 • ③ データの追加や修正の企画・ 設計。基盤を作る人とのコミュニ ケーション 意思決定 ① ② ③
  14. 「データ整備」と命名 データレイク データウェアハウス データマート 処理 洞察 「データ整備」と呼ぶことにする • 名前が無いと何かと不便なのでこ のあたりの役割を「データ整備」と

    呼ぶことにする • 基盤作りや利用との境目は明確 にできない(例えばメタデータ・集 計) • 「整備」は「基盤」と同様にどこま でを指しているかお互いの認識を 合わせること 意思決定
  15. 本日のお話 • 何のためにデータ基盤を作るのか • 価値のない基盤を作らないようにしよう • 基盤と利用のバランスをとろう • 基盤と利用の間にはどんな役割があるか •

    整備は別の役割として認識しよう • もし整備をしなかったらどうなるか • まとめ:データ基盤と整備のこれからの論点
  16. データ整備は何となくできる人がやっている データレイク データウェアハウス データマート 処理 洞察 基盤+整備か整備+利用が多い • 分担があいまいなので、できる人 が何となくやっている

    • 整備は技術よりも段取りとコミュ ニケーションの比重が高く、エンジ ニアは避ける傾向 • 利用する側がやると整備ばかりに なって不満が溜まりがち • マネージャーやマーケターなどが やるとスキル不足で大変 意思決定
  17. データ整備は貧乏くじになってはいけない データレイク データウェアハウス データマート 処理 洞察 やらないわけにはいかない • 整備を誰もやらないとまともにデ ータが使えなくなるのでやらない

    わけにはいかない • しかし基盤や利用とはやることも スキルも違う上にろくに評価もさ れず貧乏くじ扱いで押し付け合い • この状態が続くのはデータ活用に とって不幸でしかない 意思決定
  18. データ整備は1つの別の役割として認識しよう データレイク データウェアハウス データマート 処理 洞察 主張:他とは違う役割と認識しよう • そこでデータ整備は別の役割とし て認識するのがよい

    • 兼任することはありえるとしても、 別の役割として認識することで違 うことをやっていることが伝わる • 求人などでも利用〇割、整備〇割 のように伝えることでギャップをか なり埋められる 意思決定
  19. 本日のお話 • 何のためにデータ基盤を作るのか • 価値のない基盤を作らないようにしよう • 基盤と利用のバランスをとろう • 基盤と利用の間にはどんな役割があるか •

    整備は別の役割として認識しよう • もし整備をしなかったらどうなるか • まとめ:データ基盤と整備のこれからの論点
  20. データの流れ(再掲) データレイク データウェアハウス データマート 処理 洞察 データの流れを料理に例えてみる • 直接関係している人以外にも整備 が何をしているのか知っておいて

    もらった方がいい • ただし「整備をやらないと大変な ことになる」だけだと伝わりづらい • 料理の流れに例えるのがよさそう 意思決定
  21. 基盤作りは生産者 データレイク データウェアハウス データマート 処理 洞察 意思決定 倉庫 卸売 小売店

    下ごしらえと調理 味付 食べる 基盤作りは苗を植 えて育てたり魚を捕 ったりすること
  22. 利用は調理すること データレイク データウェアハウス データマート 処理 洞察 意思決定 倉庫 卸売 小売店

    下ごしらえと調理 味付 食べる 利用とは調理をする ことにあたる。自分 で食べる場合もあれ ば料理人が提供す る場合もある
  23. データ整備は中間業者 データレイク データウェアハウス データマート 処理 洞察 意思決定 倉庫 卸売 小売店

    下ごしらえと調理 味付 食べる 「データを整備」とは 物流や中間事業者 担っているのと同じ
  24. 物流や中間加工業が無かったら料理は大変 データレイク 処理 洞察 意思決定 倉庫 下ごしらえと調理 味付 食べる もし物流や中間加工業が存在しない

    と必要になったら農家や漁港まで出 かけて食材を手に入れて、まったくの 生の素材から加工も全部自分でやら なければならない
  25. 整備しなかったら毎回生データを扱うことになる データレイク 処理 洞察 意思決定 倉庫 下ごしらえと調理 味付 食べる データの整備をやらないと、使おうと

    するたびに毎回生データを加工しな がらデータを作っていく。クエリも長く 複雑になるし、元データが変更され るとその都度改修が必要になる
  26. 本日のお話 • 何のためにデータ基盤を作るのか • 価値のない基盤を作らないようにしよう • 基盤と利用のバランスをとろう • 基盤と利用の間にはどんな役割があるか •

    整備は別の役割として認識しよう • もし整備をしなかったらどうなるか • まとめ:データ基盤と整備のこれからの論点
  27. • 成長に柔軟に対応できる基盤の作り方 プロダクトの改修、成長で頻繁に変化していくのを見越したデータ基盤をどう作っていくか。特に初期段階におい て最低限必要なデータ基盤は何か • 基盤を統合するのか、個別に作って整備でまとめるのか 自社他プロダクトの新規開発、他サービスとの統合などが起きた時に1つの基盤に統合するのがよいのか、プロ ダクトなどの単位で別に持っておいて整備で取りまとめるのが良いのか、あるいはプロダクトごとで切り離してお いて共通ルールの適用を徹底させるのが良いのか •

    組織と役割分担 基盤・整備・利用の組織を1つにまとめるのかいくつかに分けるのか。データアーキテクト(データ整備人)は別の 役割として認識するのが良いのか、わけないでエンジニアやアナリストのどちらかの仕事に組み込むべきか • データ基盤・整備の重要性の啓蒙 少ない関係者の中だけでとどまらず、あらゆる人(特に経営者層)には基盤や整備の重要性を理解してもらう必 要がある データ基盤と整備のこれからの論点
  28. • データ基盤・整備の貢献を説明する 事業の中で基盤や整備がどれだけ貢献しているのかを説明する努力はしなければならないが、いくらの利益を 生んだのかを数値にすることができるのか、できなければどう説明するか • 人材の育成、採用、キャリア 長期的に考えた場合企業はどのようなキャリアを提示できるか。マネジメントなのか特定分野のスペシャリスト か他領域との組み合わせなのか。この分野で仕事をしていこうとする側にはどういった選択肢があるのか • 収集フェーズの中での位置付け

    実は収集フェーズはもっと広い領域で 〇 データマネジメント特にガバナンスや情報セキュリティ領域も合わせて考えるべき 〇 Webやデジタルだけなく紙・画像・音声・動画なども対象であり特性に合わせた収集や管理が必要 〇 情報・データを読み解くメディアリテラシーを持ち認知バイアスを回避しないと収集は失敗する 〇 収集や保管の際の法的、倫理的な制約と解決方法の考案 といったことまで基盤作りや整備を行う上では考えていかねばならない データ基盤と整備のこれからの論点