データドリブン企業におけるHadoop基盤とETL -niconicoでの実践例-
?Download as PPTX, PDF?
5 likes?13,769 views
Hadoop Conference Japan 2016 の発表資料 前半のCloudera嶋内さん発表パートはこちら http://www.slideshare.net/Cloudera_jp/hcj2016-hadoopetl-20160208
データドリブン企業における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個以上の対応デバイス - コンテンツ投稿，コメント，マイリスト，タグ編集， お気に入り登録などのユーザアクション
- 9. B2C大規模Webサービスの特徴 > 事業の成長が速い > 事業の変化が速い > 施策の実施サイクルが速い
- 10. 事業の成長が速い > 巨大データへの対応 > 高速な分析を実施 > 分析者の育成 データ活用の要件
- 11. 事業の成長が速い > 巨大データへの対応 > 高速な分析を実施 > 分析者の育成 > 全行程でスケールアウト > 高速なジョブ実行エンジン > 使いやすいデータ形式 – テーブルの非正規化 – データフォーマットの統一 データ活用の要件 ETLの要件
- 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もこうした課題に対応しながら進化して いかないといけない
- 20. niconicoのデータ活用指針 > 業務で必要な全社員が，自分自 身でデータ集計?分析する > 分析部署だけで，社内の全部署 のニーズをすべて満たすことは 不可能 > 手軽に分析できる環境の提供と， 教育体制の拡充 > 多くのファミリーサービスと多デ バイス展開 > さまざまなユーザアクション > ユーザ行動をとらえるためには 横断的な分析が必要 > あらゆるデータが分析基盤上に 誰もがデータ分析データを1カ所に集約
- 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. 以上