利用者主体で行う分析のための分析基盤
•
1 like•1,074 views
D&S Data Night vol.05 (分析環境)での発表資料 https://yahoo-ds-event.connpass.com/event/51247/
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 利用者主体で行う分析のための分析基盤
Similar to 利用者主体で行う分析のための分析基盤 (20)
利用者主体で行う分析のための分析基盤
- 1. 利用者主体で行う分析のための 分析基盤 2017/03/14 D&S Data Night vol.05 (分析環境) Kimura, Sotaro（@kimutansk） https://www.flickr.com/photos/wwworks/8693876413/
- 2. 自己紹介 • Kimura, Sotaro(@kimutansk) – ドワンゴでデータエンジニアやってます • データ分析基盤の管理 • データ分析に必要な各種ETLパイプライン構築 • 生データを集計したデータマートの設計構築 • データフォーマット、内容等の設計 etc... – 好きな技術分野 • ストリーム処理（主にJVM上） • 分散システム • 実装言語：Scala, Go – 好きなOSSプロダクト • Apache Kafka • Apache Beam • Apache NiFi etc...
- 3. アジェンダ • 何故利用者主体の分析が必要？ • 前提となる分析基盤と問題点 • 利用者主体の分析のための対応 – 使いやすく統一された、可視化されたデータ形式 – お手軽に分析を行うための中間データ整備 – 高度な分析を行うためのツールの提供 – ツールの使用方法の展開 • 未だ有効な対処がない問題 • 今後の展開
- 4. 私の立場 • データ分析基盤チームに所属するデータエンジニア • チームのミッション – 分析のための数値の調査を行うための基盤の提供 – その先の段階として上記を用いて組織が サービス戦略として高度な分析や予測が可能な組織となる • 上記の立場のため、その視点からの話となります • 基盤・ツールと利用者の関係に主眼が置かれ、 分析手法や手法の是非については触れません
- 6. 前提：niconicoの概要 MAU 約919万 ID発行数 約6210万 有料会員 約252万 ユーザアクション - コンテンツ視聴 - コンテンツ投稿 - コメント - マイリスト - お気に入り - タグ編集 ユーザ アクション ファミリー サービス アクセス デバイス 動画 静画 マンガ 電子書籍 生放送 チャンネル アプリ ブロマガ 立体 大百科 市場 ニコニ広告 実況 コモンズ コミュニティ ニュース ニコナレ RPGｱﾂﾏｰﾙ PC iOS Android SPモード Xbox One 3DS PS4 Vii U PS Vita 光Box+ PS Vita TV ビエラ TV Box Fire TV LG TV Gear VR
- 7. 前提：niconicoの概要 MAU 約919万 ID発行数 約6210万 有料会員 約252万 ユーザアクション - コンテンツ視聴 - コンテンツ投稿 - コメント - マイリスト - お気に入り - タグ編集 ユーザ アクション ファミリー サービス アクセス デバイス 動画 静画 マンガ 電子書籍 生放送 チャンネル アプリ ブロマガ 立体 大百科 市場 ニコニ広告 実況 コモンズ コミュニティ ニュース ニコナレ RPGｱﾂﾏｰﾙ PC iOS Android SPモード Xbox One 3DS PS4 Vii U PS Vita 光Box+ PS Vita TV ビエラ TV Box Fire TV LG TV Gear VR - 多様なユーザアクション - 多様なファミリーサービス - 多様なアクセスデバイス これらが同一ユーザID体系の上で行われる。
- 8. その結果・・・ • 管理するべきデータは下記の乗算で膨れ上がる。 – ユーザアクション – ファミリーサービス – アクセスデバイス – （※当然、単純な乗算ではないです。） • 結果、管理対象は3桁に達し、今後も増大 • ユーザの行動を捉えるために両方の分析が必要 – 個別サービス毎・個別アクション毎の分析 – ユーザIDやデバイス情報を用いた横断的な分析
- 9. 増大するデータに対するチーム • しかしながら、 データ分析基盤チームの人数は現状一桁 • 担当している業務範囲 – Hadoopクラスタのインフラ・リソース管理 – Hadoopクラスタ上で実行するETL構築 – Hadoopクラスタの利用者・サービスの認証認可管理 – サービスからデータを収集するパイプライン構築 – データの異常検知機構構築 – サービスと打ち合わせてデータ構成と種類の調整・設計 – 利用者と打ち合わせてデータマートの設計・構築 – 新規要素の開発・構築（下記は最近の例） • Impalaによる探索的分析のためのデータクラスタ • Kafkaによる耐障害性を持ったリアルタイムクラスタ • KinesisファミリーでAWS上サービスのデータ収集機構構築
- 10. 増大するデータに対するチーム • しかしながら、 データ分析基盤チームの人数は現状一桁 • 担当している業務範囲 – Hadoopクラスタのインフラ・リソース管理 – Hadoopクラスタ上で実行するETL構築 – Hadoopクラスタの利用者・権限管理 – サービスからデータを収集するパイプライン構築 – データの異常検知機構構築 – サービスと打ち合わせてデータ構成と種類の調整・設計 – 利用者と打ち合わせてデータマートの設計・構築 – 新規要素の開発・構築（下記は最近の例） • Impalaによるデータクラスタ • Kafkaによる耐障害性を持ったリアルタイムクラスタ • KinesisファミリーでAWS上サービスのデータ収集機構構築 個別サービスに対して分析を提供するには あまりにも人的リソースが足りない。 そのため、 必要な全社員が自前でデータ集計・分析を行う 「利用者主体の分析」を行う組織である必要がある。
- 11. 前提となる分析基盤と問題点
- 13. 分析基盤の各部詳細 • Hadoop Cluster – CDH5.10.0 + Pig0.16.0 on Tez0.8.3 + Spark2.0.2 • 直近でSparkは2.1.0系にアップデート予定 • ジョブ構成（チーム内） – Spark(SQL) + Hive + Pig + MapReduce（古いジョブ） • ジョブは設定で様々なパターンに対応可能な構成 – Azkaban + Jenkinsでジョブフローを定義し、実行 – Slack連携で各種データやジョブの状況を監視 • データ収集経路 – SCP（古いシステムとの連結部） – fluentd（末端＋集約サーバの多段構成、Kafkaに連結） – Kafka（導入移行中） – Amazon Kinesis（AWS上からの収集、fluentdに連結）
- 14. 利用者の構成 • 連携システム 5+ • 社内ユーザ（WebUIから利用） 200+ – 技術者 約20% – 非技術者 約80% • 導入時はMapReduceを利用者が書くのは無理、 スクリプトでギリギリ許容範囲という状況。 – その中の落とし所としてPigを選択。 • だが、非技術者（企画・営業職等）が多いため、 しばしば非効率・改修しにくいジョブとなる。 – かつ、先人から引き継いだ「秘伝のタレ」ジョブが 使用され続ける・・・ ほとんどがPigで ジョブを記述
- 15. 利用者の構成 • 連携システム 5+ • 社内ユーザ（WebUIから利用） 200+ – 技術者 約20% – 非技術者 約80% • 導入時はMapReduceを利用者が書くのは無理、 スクリプトでギリギリ許容範囲という状況。 – その中の落とし所としてPigを選択。 • だが、非技術者（企画・営業職等）が多いため、 しばしば非効率・改修しにくいジョブとなる。 – かつ、先人から引き継いだ「秘伝のタレ」ジョブが 使用され続ける・・・ ほとんどがPigで ジョブを記述 分析用スクリプトを書き、問題対処をするという 本来分析自体とは関係ないことに時間が取られ、 分析を深めることが出来ない問題があった。
- 16. 利用者主体の分析のための対応
- 19. 統一データとドキュメント整備 • 単一のユーザIDを用いてファミリーサービスを 展開する関係上、サービス横断的な分析が必要 • 横断分析する対象のデータは 同じ手段で分析可能である必要がある • 社内で共通的に使用される指標の基データは カテゴリ毎に統一スキーマで提供 – 当然、提供元の各種システムに対応いただく必要がある – そのために地道に打ち合わせ交渉等重ねてます • 統一スキーマのデータについては 補助ツールの整備も含めて管理レベルを上げる
- 20. 統一データとドキュメント整備 • 特定のカラムについて、 整形時にどう扱われているかがソースにしかない • 各サービスを横断し、用途も広い用語があり、 同じ用語を使っても利用者の理解がぶれる • 重要度の高いカラムについて、 整形仕様も含めてドキュメント化し、提供 • データのスキーマだけでなく用語集も整備し、 開発者利用者で理解のぶれを防止 – データ分析チームだとドメイン知識不足のため、 各サービスに確認して回って補足中
- 21. 手軽な分析のための中間データ整備 • いわゆるよく使用される指標 – 一般的な例：ヒット数、コンテンツ視聴数、DAU etc... • これらは項目によってはジョブは簡単ではなく、 かつ異なる利用者が別個実行しがち • 組織横断のKPIを戦略部署と連携して策定 – 他、各部署の定義KPIもインタビューして集約 • 重要度の高い・利用者の多いKPIについて、 集計データと中間データを整備し、提供 – 利用者にもよるが、中間データの充実によって 違う軸の集計をそこから実施可能となっている
- 22. 高度な分析のためのツール提供 • 問題点 – Hadoopのジョブは実行に時間がかかり、 探索的な分析には向かず、深まらない。 • 加えて、１つの軸で見る度にジョブを別個実行が必要 – バッチ処理の常として「データが完全」でないと 実行できないため、「今どうなのか？」が見えない • バッチ処理が完了した時には既に手遅れということも多い
- 23. 高度な分析のためのツール提供 • 探索的な分析のためにTableauを提供 – 集計データを定期的に抽出して取り込み、 データマートに対して素早くアクセス可能な環境を構築 – 利用者の生成する集計データも取り込み、提供 – Impalaクラスタの整備により、大規模データも直接分析 • HiveではTableauと接続するには性能不足 • １つのデータマートの生成によって 複数の可視化・分析が可能となり、集計が効率化 • より詳細な分析レポートの出力が可能となった • ワークシートの共有により、 分析者間の数値管理基準のずれを補正
- 24. 高度な分析のためのツール提供 • リアルタイムな分析・傾向把握のために、 Norikra/Grafanaのコンテナ環境を提供 – コンテナ単位で分離して提供するため、 他ユーザから影響を受けず、提供も素早く可能 – コンテナ自体はデータ分析チーム上で稼働 • fluentdクラスタから必要なデータを取り込み、 リアルタイムに可視化・把握可能になった – サービスの規模次第ではデータを間引いて利用 • サービスの傾向把握の他にも、 システムの稼働状況の把握にも用いられ、活用中
- 25. ツールの使用方法の展開 • Pigに加えてTableau、Norikra/Grafanaの導入を 行ったが、どのツールも使用方法は難しい。 – 特に、Tableauについては機能は多いものの、 操作に癖があり、一筋縄で使いこなせるものではない。 • 入門用ドキュメント、ビデオを準備し、 講習会も適宜実施 – ドキュメントはユースケースベースで引けるよう整備 – 入門用ビデオ「ニコニコ Tableau講座」で検索 • 質問に対してSlackでチームメンバが回答
- 26. 未だ有効な対処がない問題
- 27. 現状有効な対処がない問題 • 管理対象の増大への対処 – データの種別や集計データの種類の増大 • 管理コスト・メンテコストがチームの工数を圧迫 • 利用者に聞いて徐々に減らそうとはしているものの、 増えるペースの方が多い • リソース使用量の増大への対処 – ユーザが増えてきて、分析のジョブも増える – データの保存期間も長くなるため、 「サービス開始から今」の分析のリソース使用量が増える – ハードを増やせば解決なのではあるが、 オンプレかつ、クラスタの配置場所の関係上 そうすんなりは行かない。 • ファイルのカラムナー化、Spark化等推し進めているが、 現状焼け石に水の状態
- 28. 未だ有効な対処がない問題 • サービスの機能追加・改修に伴う 集計データへの影響範囲の事前把握 – 統一データ形式により、スキーマは保証されたが、 その中身の詳細まで常時把握することは出来ない • サービスの改修でアクセスモデルが変わり、 結果集計データの傾向が変わってから問い合わせることに • 結果整形や集計を過去にさかのぼってやり直し・・・ • 基盤チームとしてどこまで関わるかの切り分け – 個別の分析に踏み込む余裕はない ただ、踏み込まないとドメイン知識不足で 統一のスキーマやKPIの策定に支障をきたす • 加えて、個別で分析を行うと、 基準や軸などもずれるので、結局やらざるを得ない。
- 29. 未だ有効な対処がない問題 • ツールや業務の移行に対する対応 – ユーザが多いため、下記の移行に対する対応が どうしても人海戦術的になってしまう • ツールの移行 • データスキーマの移行 • 古いデータから新しいデータへの移行依頼 – ただ、データも分析ニーズも増えるため、 移行を行わないとチームとしてもたない
- 30. 今後の展開
- 31. 今後基盤として提供したいこと • ユーザのデータ利用状況の定量的な把握 – ゴミではなく、宝の基を管理したい • ドキュメント・ツールの自動生成 – コアとなる定義からドキュメントや各種ツールを自動生成 • データの異常検知機構の高度化 – スキーマチェックだけでなく、 内容チェックも学習させて自動検知させたい • 大規模なリアルタイム分析基盤の構築 – Norikraではできない大規模なデータへの適用
- 32. まとめ • 発表の流れのまとめ – 利用者主体で分析を行う前提を説明 – 利用者主体の分析での問題の一例を説明 – 上記の問題への対処や今後の展望を説明 • これまでの発表から言えること・実感したこと – データ分析の構造は、組織の構造に依る • システム開発ではなく、 データ分析にもコンウェイの法則は成り立つ • 開発を行うのも、分析を行うのも、組織・人間であるため • 私達のケースも単なる一例でしかない – 最適解が見えない問題は、大体組織構造や人間系の問題
- 33. Thank you for your attention! https://www.flickr.com/photos/simon__syon/8705867109/