Mais conteúdo relacionado Semelhante a 利用者主体で行う分析のための分析基盤 (20) 利用者主体で行う分析のための分析基盤2. 自己紹介
• Kimura, Sotaro(@kimutansk)
– ドワンゴでデータエンジニアやってます
• データ分析基盤の管理
• データ分析に必要な各種ETLパイプライン構築
• 生データを集計したデータマートの設計構築
• データフォーマット、内容等の設計 etc...
– 好きな技術分野
• ストリーム処理(主にJVM上)
• 分散システム
• 実装言語:Scala, Go
– 好きなOSSプロダクト
• Apache Kafka
• Apache Beam
• Apache NiFi etc...
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体系の上で行われる。
9. 増大するデータに対するチーム
• しかしながら、
データ分析基盤チームの人数は現状一桁
• 担当している業務範囲
– Hadoopクラスタのインフラ・リソース管理
– Hadoopクラスタ上で実行するETL構築
– Hadoopクラスタの利用者・サービスの認証認可管理
– サービスからデータを収集するパイプライン構築
– データの異常検知機構構築
– サービスと打ち合わせてデータ構成と種類の調整・設計
– 利用者と打ち合わせてデータマートの設計・構築
– 新規要素の開発・構築(下記は最近の例)
• Impalaによる探索的分析のためのデータクラスタ
• Kafkaによる耐障害性を持ったリアルタイムクラスタ
• KinesisファミリーでAWS上サービスのデータ収集機構構築
10. 増大するデータに対するチーム
• しかしながら、
データ分析基盤チームの人数は現状一桁
• 担当している業務範囲
– Hadoopクラスタのインフラ・リソース管理
– Hadoopクラスタ上で実行するETL構築
– Hadoopクラスタの利用者・権限管理
– サービスからデータを収集するパイプライン構築
– データの異常検知機構構築
– サービスと打ち合わせてデータ構成と種類の調整・設計
– 利用者と打ち合わせてデータマートの設計・構築
– 新規要素の開発・構築(下記は最近の例)
• Impalaによるデータクラスタ
• Kafkaによる耐障害性を持ったリアルタイムクラスタ
• KinesisファミリーでAWS上サービスのデータ収集機構構築
個別サービスに対して分析を提供するには
あまりにも人的リソースが足りない。
そのため、
必要な全社員が自前でデータ集計・分析を行う
「利用者主体の分析」を行う組織である必要がある。
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で
ジョブを記述
分析用スクリプトを書き、問題対処をするという
本来分析自体とは関係ないことに時間が取られ、
分析を深めることが出来ない問題があった。
27. 現状有効な対処がない問題
• 管理対象の増大への対処
– データの種別や集計データの種類の増大
• 管理コスト・メンテコストがチームの工数を圧迫
• 利用者に聞いて徐々に減らそうとはしているものの、
増えるペースの方が多い
• リソース使用量の増大への対処
– ユーザが増えてきて、分析のジョブも増える
– データの保存期間も長くなるため、
「サービス開始から今」の分析のリソース使用量が増える
– ハードを増やせば解決なのではあるが、
オンプレかつ、クラスタの配置場所の関係上
そうすんなりは行かない。
• ファイルのカラムナー化、Spark化等推し進めているが、
現状焼け石に水の状態
32. まとめ
• 発表の流れのまとめ
– 利用者主体で分析を行う前提を説明
– 利用者主体の分析での問題の一例を説明
– 上記の問題への対処や今後の展望を説明
• これまでの発表から言えること・実感したこと
– データ分析の構造は、組織の構造に依る
• システム開発ではなく、
データ分析にもコンウェイの法則は成り立つ
• 開発を行うのも、分析を行うのも、組織・人間であるため
• 私達のケースも単なる一例でしかない
– 最適解が見えない問題は、大体組織構造や人間系の問題
33. Thank you for your attention!
https://www.flickr.com/photos/simon__syon/8705867109/