Recommended
More Related Content
What's hot
What's hot (20)
Similar to 初めてのデータ分析基盤構築をまかされた、その時何を考えておくと良いのか
Similar to 初めてのデータ分析基盤構築をまかされた、その時何を考えておくと良いのか (20)
More from Techon Organization
More from Techon Organization (20)
初めてのデータ分析基盤構築をまかされた、その時何を考えておくと良いのか
- 1. 初めてのデータ分析基盤構築をまかされた、 その時何を考えておくと良いのか 2020/07/27 Tech-on MeetUp Online #2 「もしエンタープライズのエンジニアがデータ分析をやることになったら」 @yutah_3
- 2. 自己紹介 普段のお仕事 ● データ分析や DB 周りで困っているお客様への技術的ご支援を しております ● チームを動きやすく、データドリブン／データインスパイアな意思 決定をするべく社内 DWH のデータマートの整備やデータ分析 を日常的にやっています ● BigQuery ユーザーでもあり、コンサルでもあります ● 日経 xTech Learning 等に寄稿したりしています ” Googleエンジニアと学ぶ GCP［ビッグデータ］” https://xtech.nikkei.com/atcl/learning/lecture/19/00089/ ＃本日は個人としての登壇であり、所属する企業、 団体を代表する意見ではありませんが、 私の経験上 GCP (Google Cloud) の話が多くなります。 寳野 雄太 | Yuta Hono Head of Specialist Customer Engineering (Analytics & DB) Google Cloud Twitter : @yutah_3
- 3. 本日のお話 ● 気をつけたいデータ分析プロジェクト ● そもそも、「データ分析をするぞ！」って・・・？ ● あるある注意点とその解決例
- 5. こんな経験、ありませんか？ DX※ に力入れたくて、データ 分析、始めたいんだよね、い い感じにしてよ！ あ、はい、わかりました 何をすればいいん だろう・・・ ※ Digital Transformation の略 以下、いらすとや さんのイラストを利用させていただき、 ゆるーくいきます。
- 8. そもそも何をしたいのか掘り下げ なぜデータ分析するんでしょうか？ いまはやっていないのでしょうか？ 進捗把握をしたい ● 定形ダッシュボード 原因見つけたい ● アドホック分析 ● データマイニング ● BIツールのドリルダウン 売上をあげたい ● レコメンド（ML） ● セグメンテーション (ML) データ分析の例(MECEではない) 意思決定したい （データインスパイア、データドリブン） ● カスタマイズしたレポート （含む、データの裏側の理由）
- 9. そもそも何をしたいのか掘り下げ なぜデータ分析するんでしょうか？ いまはやっていないのでしょうか？ 進捗把握をしたい ● 定形ダッシュボード 原因見つけたい ● アドホック分析 ● データマイニング ● BIツールのドリルダウン 売上をあげたい ● レコメンド（ML） ● セグメンテーション (ML) データ分析の例(MECEではない) 意思決定したい （データインスパイア、データドリブン） ● カスタマイズしたレポート （含む、データの裏側の理由） 本日は時間の都合上割愛 データ分析ではドメイン知識や ビジネス課題の発見、設定がとても重要ですが 今日はエンジニア向けなので、基盤の話に振ります。
- 11. 課題1 . 初期投資できない アプリ DB アプリ サーバーログ その他 (IoT, 非構造, 半構造 データ ) データレイク 将来的には 10 PiB でもまずは 1 GiB / 月 10 PiBはサービスがあたったときの試算 データソースは徐々に増やしていく 総インフラ XX 億円の 稟議、取れますか？
- 12. 解決例 1 . クラウドを利用する データレイク オブジェクトストレージ等、 クラスタを作らず利用できるもの が相性良 例 : Google Cloud Storage データ分析基盤と 従量課金のクラウドは相性が良い。 大抵の場合、 データ分析基盤自体は お金を直接産まない。 ビジネス成果を 見せて投資を増やしてもらう。 アプリ DB アプリ サーバーログ その他 (IoT, 非構造, 半構造 データ )
- 13. 課題2 . （狭義の）データレイクにデータ入れっぱなし アプリ DB アプリ サーバーログ その他 (IoT, 非構造, 半構造 データ ) データレイク 分析できない / しない ？
- 14. 解決例 2. DWH にデータを入れる データは DWH に格納 あるいはデータレイクとしている ストレージに 分析クエリをかけられる技術を利用 (トレードオフ : パフォーマンス) 理想的な アーキテクチャでは こうだが・・・ ※ETL : Extract, Transform, Load の略 データを取り出し、変換し整形しながら DB などにロードをすることを指す。 アプリ DB アプリ サーバーログ その他 (IoT, 非構造, 半構造 データ ) データレイク DWH ※ETL
- 15. 課題3. DWH が用途・部署ごとに乱立（サイロ化） アプリ DB アプリ サーバーログ その他 (IoT, 非構造, 半構造 データ ) データレイク (例：物理ストレージが 異なる、バケットやアカ ウントが異なる) 実態は： ● 用途・責任別に乱立 各 DWH がクラスタやアカウントが異な る ● 隣の DWH に欲しいデータがあるの で、DWH から DWH へのデータコピー も発生、二重持ち ● 同じデータが気づかず隣りにあって、同 じ ETL を隣でしていることも ● どこにどのデータがコピーされたのか 管理が難しく、混乱 / 高コストへ DWH （例：クラスタが異なる） ETL
- 16. 解決例 3. 組織を超えてデータの全社最適化 DWH マルチテナントの DWH を活用： （例 : BigQuery 等 - Google 社内でもよく使ってます。） ● リージョンで１つの仮想的な「箱」 ● 権限で制御、社内でデータシェアしたい場合には 権限を付与するだけ 外部漏洩防止機能は要確認 ● データコピーなしにデータ共有、 JOIN ができる ● データを社外から買い付けて即時利用可能 （商用データセット, トムソン・ロイターとCitibank の市場データ事例） ● 副次的に、規模の経済が活きる 自分だけで大きな DWHクラスタを構築する必要なく 十分なパフォーマンスを得られる. コストもクエリ・ストレージとも に従量課金。(!= クラスタ課金) アプリ A ログ アプリ B ログ 基幹 DB データ 課金データ デバイスログ IAMや 追加の制御機構 ※ 経済産業省の DX推進指標とそのガイダンス でも「データを、部門を超えて全社最適で活用できる か」というテーマが入ってますね ※追加の制御機構には BigQuery の場合、データ持ち出しや IP 制限などを実現する VPC Service Controls や列レベルアクセス 、テーブル ACL などがあります
- 18. このデータどこから来てる？ 信用できるデータ？ 課題4. データマート責任者不在、効率低下 BI ツール スプレッドシート Jupyter Notebooks クエリ DWH ビジネスユーザー/ データアナリスト データ サイエンティスト 情報系アプリ もっとこういうデータが欲しいけど・・・ 自分で交渉しないとだめ？ もっとこういう集計形式にしてほしいけ ど、BI ツール側の計算フィールド追加 するの嫌だなぁ・・・ トランザクション日だけでなく、四半期 とかのカラムもほしい。 このデータどういう意味だっけ？
- 19. 解決例 4. データのイテレーションを回す データ追加、フォーマット整備、マート整備、カタログ、リネージュ etc. ビジネスユーザー/ データアナリスト データサイエンティスト データアーキテクト/ データエンジニア ELT/ETL を見直し要望に答える データマート整備を実現＆ データソース交渉は任せろ！ データカタログやリネージュも 整備してくけど、ドメインナレッジは手伝ってね！ よりビジネスの貢献に つかう時間が増えた！ もっと X できる？ データから知見を 発見する部分やモデルの開 発に専念できる！ もっと Y できる？ BI ツール スプレッドシート Jupyter Notebooks クエリ DWH 情報系アプリ ※データガバナンスの世界ではデータ スチュワードと呼びます。エンジニアが 兼務するのか業務側がやるのか別途 悩ましい。
- 20. 課題5. データ分析する人のスキルとツールが合わない BI ツール スプレッドシート クエリ DWH ビジネスユーザー 情報系アプリ データ基盤を整えた後、 よくある声： ● やっぱりスプレッドシートで ダウンロードしたい （ダウンロードした時期が違うデータを VLOOKUP とか、あ りますよね・・・） ● BI ツールの使い方覚えるの難しい ● クエリ書くのに黒い画面（コンソール） 見るの嫌だ ● クエリ書くときにデータセットをselect * (snip) LIMIT 10 とかして 中身みるのは面倒・・・ アナリスト IT 部門 基盤・ツール整備したのに データ抽出依頼が減らない ・・・
- 21. 解決例 5. ユーザーフレンドリーなツールをつかいながら ユーザー教育する（外部の力もつかうことを検討） ※G Suite Update ブログから引用 例. Connected Sheets ※： Spreadsheet の関数やピボットテーブルを BigQuery のクエリにして実行し、描写や使い勝手は Spreadsheet だが、最新の情報を取り出せる。 ＝使い勝手 Spreadsheet そのまま ＝ローカル取り出しでデータが stale しない ＝スケーラビリティは BigQuery が担保 例. BigQuery コンソール : データセットが UI から探せる。テーブルの中身をプレ ビューしながらクエリをかけるのはイメージが湧きやす い。テーブルのカラムに説明を加えることもできる。 メタ データ管理の Data Catalog とも連動。 ＝スキーマ設計書と行き来しなくてよい ＝こんなデータあるかな？を検索できる
- 22. 課題6. データの活用による新しい課題 従来： ● 限られたユーザーが限られたデータ活用しかし ないので、 インデックスチューニングを頑張るOR DWH を ユーザーごとにわける データ活用が進むと： ● 全データ、一箇所にあってほしい ● アドホックが増えるので、パターンが読めず、イ ンデックスチューニングできない ● セルフサービスBI などにより、クエリ数が増え るので、クエリづまりが起きる ● データアーキテクトの仕事も増えるので、定期 的な DWH のメンテなども時間をかけられない DWH ビジネスユーザー アナリスト IT 部門 気合でインデックスチューニング しようとしたけど次々と新しいユース ケースが。もう無理なので、新しい データ入れるのやめてください！ 重いクエリ投げた 人が一人いて DWH が動いてい ません・・・
- 23. 解決例 6a. 力技 ※ BigQuery ドキュメント「スロット」より引用。 データセンターレベルのスケーラビリティを利用すると インデックスを持たずともあらゆるクエリパターンに高速な分析可能に（力技） 例. BigQuery のクエリ処理の様子： ● 基本的にクエリを複数のワーカーで分散して処理 する ● 複数のワーカーの単位を「スロット」とよぶ ● 場合によっては普通に1 万以上つかうこともある ● 最速で終わるように自動で分散処理を最適化 ● 力技でクエリを実行するのでインデックスを持た ず、基本は対象データのフルスキャンをする ＝ インデックスを持たなくても高速 マスタ ワーカー 分散ディスク ワーカー ワーカー... ... 分散 インメモリ シャッフル 横にスケールさせる （スケールアウトの思想）
- 24. 解決例 6b. 動的なクエリプラン ※ BigQuery ドキュメント「スロット」より引用。 ※ 優先順位はBigQuery Reservations で設定する 先に実行されたクエリが DB のリソースを 食いつぶしたまま居残り、後続をブロックしない 例. BigQuery のクエリ処理の様子： ● クエリプランは全て動的 ● 全クエリでのパフォーマンス最適化を行うために、 後続の並列クエリが来たら、実行中のクエリの割 当リソースを最適化して後続のクエリも実行できる ようにする ● （実行優先順位、割当優先も設定できる） ● よくいう「クエリづまり」が起きづらい
- 25. 解決例 6c. サーバーレス DWH をつかう ハードウェア クラウド上の DWH インデックス、 クラスタ管理、高可用 性担保 データの整理 データマートの管理 メタデータ管理 データ活用 BI, MLデータ サイエンティスト, サービス企画 データアーキテクト クラウドエンジニア よりよいデータ活用には、 データアーキテクトが必要 クラウド管理から、データ活用にフォーカス サーバーレス DWH に 任せる 例 : BigQuery よりビジネス付加価値の高い 技術にフォーカス より使いやすいデータ、 でデータ活用を推進
- 26. まとめ データ基盤を考える際には、データ要件に対応できるイテレーションを回せるような体制づくりが重要 ● データ整備にフォーカスできるようなリソースのかけ方を目指す ● 新しいスキル習得が必要な場合もある、ギャップを小さくするツールからまず慣れる データ活用がエンタープライズで進むと、アドホックなクエリが増える（あるいは BI ツールを通したアドホッ ク） ● インデックスチューニングは諦めて、並列分散処理するような DWH で力技を検討 ● クエリの並列性に対応しやすい、動的なクエリプランで実行できる DWH を考慮に入れる ● マルチテナントだと規模の経済が生きる！ ビジネス成果を出すことにフォーカスできるような 基盤を考えて段々と作っていきましょう！
- 28. さいごに データエンジニアの戦いはまだまだ続く！ で、今度はリアルタイムに 指標見たいな！ あと、売上着地予想出してほし いな！AI ってやつで！ 投資とセットなら 喜んで！ データガバナンスとか Trusted Data ってやつをね。やっていこ うと思うんですよ。 この間のアレ（ダッシュボード）す ごい良かったよ！ etc. （データ基盤はビジネス要求と密接に関わります。こういうことを言われなくても、常にビジネス要求を 先取りして進化させる必要があります。一緒に頑張りましょう。）