Hadoop Conference Japan 2016 の発表資料 前半のCloudera嶋内さん発表パートはこちら http://www.slideshare.net/Cloudera_jp/hcj2016-hadoopetl-20160208

1. データドリブン企業における
Hadoop基盤とETL
-niconicoでの実践例-
株式会社ドワンゴ
共通基盤開発部
志村 誠

2. 自己紹介
> 志村誠
– 株式会社ドワンゴ
開発本部 共通基盤開発部 数値基盤セクション
– 2011年にドワンゴ入社
以来ログ解析基盤の開発/運用，データ活用を担当

3. 会社紹介

4. 会社概要

5. 会社概要

6. niconicoの概要
動画
生放送
静画
電子書籍
マンガ
チャンネル
アプリ
ブロマガ
立体
コミュニティ
ニコニ広告
ニュース
ニコナレ
nicobox
ファミリーサービ
ス
PC
SP web
iOSアプリ
Androidアプリ
FP web
PS Vita
3DS
WiiU
PS4
Xbox One
Viera
Bravia
LGテレビ
Amazon Fire TV
Windowsアプリ
GearVR
対応デバイスサービス概要
2006/12開始
MAU 約895万
登録会員 約5,124万
有料会員 約253万
- コンテンツ投稿
- コメント
- マイリスト
- タグ編集

7. niconicoの概要
動画
生放送
静画
電子書籍
マンガ
チャンネル
アプリ
ブロマガ
立体
コミュニティ
ニコニ広告
ニュース
ニコナレ
nicobox
ファミリーサービ
ス
PC
SP web
iOSアプリ
Androidアプリ
FP web
PS Vita
3DS
WiiU
PS4
Xbox One
Viera
Bravia
LGテレビ
Amazon Fire TV
Windowsアプリ
GearVR
対応デバイスサービス概要
2006/12開始
MAU 約895万
登録会員 約5,124万
有料会員 約253万
- コンテンツ投稿
- コメント
- マイリスト
- タグ編集
単一のniconicoユーザIDに紐づいて
- 10個以上のファミリーサービス
- 15個以上の対応デバイス
- コンテンツ投稿，コメント，マイリスト，タグ編集，
お気に入り登録などのユーザアクション

8. B2C大規模Webサービスの
特徴とETLの要件

9. B2C大規模Webサービスの特徴
> 事業の成長が速い
> 事業の変化が速い
> 施策の実施サイクルが速い

10. 事業の成長が速い
> 巨大データへの対応
> 高速な分析を実施
> 分析者の育成
データ活用の要件

11. 事業の成長が速い
> 巨大データへの対応
> 高速な分析を実施
> 分析者の育成
> 全行程でスケールアウト
> 高速なジョブ実行エンジン
> 使いやすいデータ形式
– テーブルの非正規化
– データフォーマットの統一
データ活用の要件 ETLの要件

12. 事業の変化が速い
> 仕様変更に対する追従の
容易性を担保
> KPIの整合性担保
データ活用の要件

13. 事業の変化が速い
> 仕様変更に対する追従の
容易性を担保
> KPIの整合性担保
> 仕様変更を前提とした
ETLプロセス
> 仕様変更をETLで吸収
– さまざまな前処理を実施
– 処理のコンポーネント化
データ活用の要件 ETLの要件

14. 施策の実施サイクルが速い
> 適材適所の分析手段
– ABテストツール
– 主要指標のダッシュボード
– ストリームデータへのクエ
リ
– BIツールで深堀
– ストアデータへバッチ
データ活用の要件

15. 施策の実施サイクルが速い
> 適材適所の分析手段
– ABテストツール
– 主要指標のダッシュボード
– ストリームデータへのクエ
リ
– BIツールで深堀
– ストアデータへバッチ
> データフローの各所で利用を
想定
> 利用可能までのリードタイム
短縮
> 適切なSLAの設定
– 提供タイミング
– 精度
データ活用の要件 ETLの要件

16. B2C大規模Webサービスの特徴
> 事業の成長が速い
> 事業の変化が速い
> 施策の実施サイクルが速い

17. B2C大規模Webサービスの特徴
> 事業の成長が速い
> 事業の変化が速い
> 施策の実施サイクルが速い
これが10年続くと…
- 複数回の大きなフロント/バックの変更
- 根幹部分に初期の負債が未だに残存
- サービス・デバイスの拡大による集計軸の多様化

18. B2C大規模Webサービスの特徴
> 事業の成長が速い
> 事業の変化が速い
> 施策の実施サイクルが速い
これが10年続くと…
- 複数回の大きなフロント/バックの変更
- 根幹部分に初期の負債が未だに残存
- サービス・デバイスの拡大による集計軸の多様化
ETLもこうした課題に対応しながら進化して
いかないといけない

19. niconicoにおける
データ活用とETL

20. niconicoのデータ活用指針
> 業務で必要な全社員が，自分自
身でデータ集計・分析する
> 分析部署だけで，社内の全部署
のニーズをすべて満たすことは
不可能
> 手軽に分析できる環境の提供と，
教育体制の拡充
> 多くのファミリーサービスと多デ
バイス展開
> さまざまなユーザアクション
> ユーザ行動をとらえるためには
横断的な分析が必要
> あらゆるデータが分析基盤上に
誰もがデータ分析データを1カ所に集約

21. ETLで考慮する範囲
Extract
Transform
Load
Service
User

22. ETLで考慮する範囲
Extract
Transform
Load
Service
User
設計の流れ

23. ETLで考慮する範囲
Extract
Transform
Load
Service
User
設計の流れ
> ETL前後の要素
– User:
• どんなユーザがどう利用するか
• 逆算的にServiceまで影響
– Service:
• 仕様の把握とIFの定義
• 仕様変更への追従
> 考慮する範囲
– 分析手法のどこまで介入するか
– サービス側にどこまで仕様を強制するか

25. Norikra
fluentd
Pig / Hive
MapReduce
Hive / Impala
scp
内製バッチジョブフレームワーク
MapReduce → Spark

26. niconicoのETLにおける問題
> ETLの品質をどうやって継続的に担保するか
> システムの刷新サイクルをどう担保するか
> サービス側の独自仕様をどう吸収するか
> 過去データとの整合性をどう担保するか

27. ETLの品質をどうやって継続的に担保するか
> 属人性の排除
– 人員の入替の激しさを吸
収
– 保守性よく腐りにくい言語
> ビジネスロジックとコード
の分離
– モジュール化できる作業
ポイント

28. ETLの品質をどうやって継続的に担保するか
> 属人性の排除
– 人員の入替の激しさを吸
収
– 保守性よく腐りにくい言語
> ビジネスロジックとコード
の分離
– モジュール化できる作業
> 初期のMRが未だに現役
– 3段→7段の素のMR
– テーブルの非正規化
> 作り直し
– MR /Sparkのモジュール
– ドキュメント整備
ポイント 実際

29. システムの刷新サイクルをどう担保するか
> 技術的負債の解消
– 言語やフレームワークの陳腐
化の早さ
> 解消のコストの高さ
– リプレースは価値を生まない
– バックエンドの分析基盤
– 数値整合性を担保する困難
ポイント

30. システムの刷新サイクルをどう担保するか
> 技術的負債の解消
– 言語やフレームワークの陳腐
化の早さ
> 解消のコストの高さ
– リプレースは価値を生まない
– バックエンドの分析基盤
– 数値整合性を担保する困難
> 内向けにきちんと説明
> 標準化とフレームワーク
– ログフォーマットの標準化
– ログ整形処理の標準化とモ
ジュール化
• 例外処理への対応も必須
– バッチ実行フレームワークの
再開発
ポイント 実際

31. サービスの独自仕様をどう吸収するか
> 独自仕様はなくならない
– パフォーマンス優先
– システムの制約
– リリースまでの期日
> ミドルウェア導入ができな
い場合もままある
ポイント

32. サービスの独自仕様をどう吸収するか
> 独自仕様はなくならない
– パフォーマンス優先
– システムの制約
– リリースまでの期日
> ミドルウェア導入ができな
い場合もままある
> コメントサーバ
– パフォーマンス優先
– 標準化に載せられない
– ユーザIDの中身
> オンプレ/クラウド
– 別DC/AWS/Azure/CDNから
– フォーマットやタイムゾーン
– ストリームでのデータ転送
ポイント 実際

33. 過去データとの整合性(1) 仕様変更
> 大きなサービス側システ
ム構成の変更
– 複数サービスの統合
– サービスを複数に分割
– バックエンド基盤の置換
> 集計・分析を考慮した設
計を求める
ポイント

34. 過去データとの整合性(1) 仕様変更
> 大きなサービス側システ
ム構成の変更
– 複数サービスの統合
– サービスを複数に分割
– バックエンド基盤の置換
> 集計・分析を考慮した設
計を求める
> 具体例
– niconico動画/生放送iOS →
niconico iOS
– システム構成の変更による
PKの変更，追加
– KPIに関わる基盤置換
> 開発プロセスにKPI設計と
数値評価が含まれる組織
体制
ポイント 実際

35. 過去データとの整合性(2) 過去データ取込
> ストアデータとログデータ
のフォーマット差異
– サービス開始の後から
データ取り込みを行う場合
> 外部サービスの統合や買
収，企業統合など
ポイント

36. 過去データとの整合性(2) 過去データ取込
> ストアデータとログデータ
のフォーマット差異
– サービス開始の後から
データ取り込みを行う場合
> 外部サービスの統合や買
収，企業統合など
> コメントデータ
– 一定レコード毎にファイル
に直書き
– ファイルをディレクトリ階層
で管理
– ログとしては，レコード更新
毎に1行吐き出す
ポイント 実際

37. まとめ

38. まとめ
> ETLはそれ単体ではなく，以下の点を併せて考慮す
る必要がある
– データ活用の方針
– 各システムの仕様と変更可能性
> WebサービスのETLは，サービス自体や用いる技術
が時間とともに大きく変化する
– 標準化 + モジュール化 + 例外処理の余地
– 仕様変更を事前に考慮 & 仕様変更時の仕様強制

39. 以上