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. 本日のお話
● 気をつけたいデータ分析プロジェクト
● そもそも、「データ分析をするぞ！」って・・・？
● あるある注意点とその解決例

4. 気をつけたい
データ分析プロジェクト

5. こんな経験、ありませんか？
DX※
に力入れたくて、データ
分析、始めたいんだよね、い
い感じにしてよ！
あ、はい、わかりました
何をすればいいん
だろう・・・
※ Digital Transformation の略
以下、いらすとや さんのイラストを利用させていただき、
ゆるーくいきます。

6. 気をつけたいデータ分析プロジェクト
とりあえず箱をつくろう。
アプリ
DB
アプリ
サーバーログ
その他
(IoT, 非構造, 半
構造データ )
データレイク
完

7. そもそも、
「データ分析をするぞ！」
って・・・？

8. そもそも何をしたいのか掘り下げ
なぜデータ分析するんでしょうか？
いまはやっていないのでしょうか？
進捗把握をしたい
● 定形ダッシュボード
原因見つけたい
● アドホック分析
● データマイニング
● BIツールのドリルダウン
売上をあげたい
● レコメンド（ML）
● セグメンテーション (ML)
データ分析の例(MECEではない)
意思決定したい
（データインスパイア、データドリブン）
● カスタマイズしたレポート
（含む、データの裏側の理由）

9. そもそも何をしたいのか掘り下げ
なぜデータ分析するんでしょうか？
いまはやっていないのでしょうか？
進捗把握をしたい
● 定形ダッシュボード
原因見つけたい
● アドホック分析
● データマイニング
● BIツールのドリルダウン
売上をあげたい
● レコメンド（ML）
● セグメンテーション (ML)
データ分析の例(MECEではない)
意思決定したい
（データインスパイア、データドリブン）
● カスタマイズしたレポート
（含む、データの裏側の理由）
本日は時間の都合上割愛
データ分析ではドメイン知識や
ビジネス課題の発見、設定がとても重要ですが
今日はエンジニア向けなので、基盤の話に振ります。

10. （データ基盤の）
あるある注意点と
その解決例

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 などがあります

17. 結論？
データがかんたんにシェア
できるシステムが整った！
社内のデータ資産を活かし、
データ活用が加速！
No.
これだけではベースライン.
体制やスキルなども考慮.

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 を考慮に入れる
● マルチテナントだと規模の経済が生きる！
ビジネス成果を出すことにフォーカスできるような
基盤を考えて段々と作っていきましょう！

27. おわり？
いい感じのデータ基盤が
できた！

28. さいごに
データエンジニアの戦いはまだまだ続く！
で、今度はリアルタイムに
指標見たいな！
あと、売上着地予想出してほし
いな！AI ってやつで！
投資とセットなら
喜んで！
データガバナンスとか Trusted
Data ってやつをね。やっていこ
うと思うんですよ。
この間のアレ（ダッシュボード）す
ごい良かったよ！
etc.
（データ基盤はビジネス要求と密接に関わります。こういうことを言われなくても、常にビジネス要求を
先取りして進化させる必要があります。一緒に頑張りましょう。）