Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

データドリブン企業におけるHadoop基盤とETL -niconicoでの実践例-

10,914 views

Published on

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

Published in: Technology
  • Be the first to comment

データドリブン企業におけるHadoop基盤とETL -niconicoでの実践例-

  1. 1. データドリブン企業における Hadoop基盤とETL -niconicoでの実践例- 株式会社ドワンゴ 共通基盤開発部 志村 誠
  2. 2. 自己紹介 > 志村誠 – 株式会社ドワンゴ 開発本部 共通基盤開発部 数値基盤セクション – 2011年にドワンゴ入社 以来ログ解析基盤の開発/運用,データ活用を担当
  3. 3. 会社紹介
  4. 4. 会社概要
  5. 5. 会社概要
  6. 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. 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. 8. B2C大規模Webサービスの 特徴とETLの要件
  9. 9. B2C大規模Webサービスの特徴 > 事業の成長が速い > 事業の変化が速い > 施策の実施サイクルが速い
  10. 10. 事業の成長が速い > 巨大データへの対応 > 高速な分析を実施 > 分析者の育成 データ活用の要件
  11. 11. 事業の成長が速い > 巨大データへの対応 > 高速な分析を実施 > 分析者の育成 > 全行程でスケールアウト > 高速なジョブ実行エンジン > 使いやすいデータ形式 – テーブルの非正規化 – データフォーマットの統一 データ活用の要件 ETLの要件
  12. 12. 事業の変化が速い > 仕様変更に対する追従の 容易性を担保 > KPIの整合性担保 データ活用の要件
  13. 13. 事業の変化が速い > 仕様変更に対する追従の 容易性を担保 > KPIの整合性担保 > 仕様変更を前提とした ETLプロセス > 仕様変更をETLで吸収 – さまざまな前処理を実施 – 処理のコンポーネント化 データ活用の要件 ETLの要件
  14. 14. 施策の実施サイクルが速い > 適材適所の分析手段 – ABテストツール – 主要指標のダッシュボード – ストリームデータへのクエ リ – BIツールで深堀 – ストアデータへバッチ データ活用の要件
  15. 15. 施策の実施サイクルが速い > 適材適所の分析手段 – ABテストツール – 主要指標のダッシュボード – ストリームデータへのクエ リ – BIツールで深堀 – ストアデータへバッチ > データフローの各所で利用を 想定 > 利用可能までのリードタイム 短縮 > 適切なSLAの設定 – 提供タイミング – 精度 データ活用の要件 ETLの要件
  16. 16. B2C大規模Webサービスの特徴 > 事業の成長が速い > 事業の変化が速い > 施策の実施サイクルが速い
  17. 17. B2C大規模Webサービスの特徴 > 事業の成長が速い > 事業の変化が速い > 施策の実施サイクルが速い これが10年続くと… - 複数回の大きなフロント/バックの変更 - 根幹部分に初期の負債が未だに残存 - サービス・デバイスの拡大による集計軸の多様化
  18. 18. B2C大規模Webサービスの特徴 > 事業の成長が速い > 事業の変化が速い > 施策の実施サイクルが速い これが10年続くと… - 複数回の大きなフロント/バックの変更 - 根幹部分に初期の負債が未だに残存 - サービス・デバイスの拡大による集計軸の多様化 ETLもこうした課題に対応しながら進化して いかないといけない
  19. 19. niconicoにおける データ活用とETL
  20. 20. niconicoのデータ活用指針 > 業務で必要な全社員が,自分自 身でデータ集計・分析する > 分析部署だけで,社内の全部署 のニーズをすべて満たすことは 不可能 > 手軽に分析できる環境の提供と, 教育体制の拡充 > 多くのファミリーサービスと多デ バイス展開 > さまざまなユーザアクション > ユーザ行動をとらえるためには 横断的な分析が必要 > あらゆるデータが分析基盤上に 誰もがデータ分析データを1カ所に集約
  21. 21. ETLで考慮する範囲 Extract Transform Load Service User
  22. 22. ETLで考慮する範囲 Extract Transform Load Service User 設計の流れ
  23. 23. ETLで考慮する範囲 Extract Transform Load Service User 設計の流れ > ETL前後の要素 – User: • どんなユーザがどう利用するか • 逆算的にServiceまで影響 – Service: • 仕様の把握とIFの定義 • 仕様変更への追従 > 考慮する範囲 – 分析手法のどこまで介入するか – サービス側にどこまで仕様を強制するか
  24. 24. Norikra fluentd Pig / Hive MapReduce Hive / Impala scp 内製バッチジョブフレームワーク MapReduce → Spark
  25. 25. niconicoのETLにおける問題 > ETLの品質をどうやって継続的に担保するか > システムの刷新サイクルをどう担保するか > サービス側の独自仕様をどう吸収するか > 過去データとの整合性をどう担保するか
  26. 26. ETLの品質をどうやって継続的に担保するか > 属人性の排除 – 人員の入替の激しさを吸 収 – 保守性よく腐りにくい言語 > ビジネスロジックとコード の分離 – モジュール化できる作業 ポイント
  27. 27. ETLの品質をどうやって継続的に担保するか > 属人性の排除 – 人員の入替の激しさを吸 収 – 保守性よく腐りにくい言語 > ビジネスロジックとコード の分離 – モジュール化できる作業 > 初期のMRが未だに現役 – 3段→7段の素のMR – テーブルの非正規化 > 作り直し – MR /Sparkのモジュール – ドキュメント整備 ポイント 実際
  28. 28. システムの刷新サイクルをどう担保するか > 技術的負債の解消 – 言語やフレームワークの陳腐 化の早さ > 解消のコストの高さ – リプレースは価値を生まない – バックエンドの分析基盤 – 数値整合性を担保する困難 ポイント
  29. 29. システムの刷新サイクルをどう担保するか > 技術的負債の解消 – 言語やフレームワークの陳腐 化の早さ > 解消のコストの高さ – リプレースは価値を生まない – バックエンドの分析基盤 – 数値整合性を担保する困難 > 内向けにきちんと説明 > 標準化とフレームワーク – ログフォーマットの標準化 – ログ整形処理の標準化とモ ジュール化 • 例外処理への対応も必須 – バッチ実行フレームワークの 再開発 ポイント 実際
  30. 30. サービスの独自仕様をどう吸収するか > 独自仕様はなくならない – パフォーマンス優先 – システムの制約 – リリースまでの期日 > ミドルウェア導入ができな い場合もままある ポイント
  31. 31. サービスの独自仕様をどう吸収するか > 独自仕様はなくならない – パフォーマンス優先 – システムの制約 – リリースまでの期日 > ミドルウェア導入ができな い場合もままある > コメントサーバ – パフォーマンス優先 – 標準化に載せられない – ユーザIDの中身 > オンプレ/クラウド – 別DC/AWS/Azure/CDNから – フォーマットやタイムゾーン – ストリームでのデータ転送 ポイント 実際
  32. 32. 過去データとの整合性(1) 仕様変更 > 大きなサービス側システ ム構成の変更 – 複数サービスの統合 – サービスを複数に分割 – バックエンド基盤の置換 > 集計・分析を考慮した設 計を求める ポイント
  33. 33. 過去データとの整合性(1) 仕様変更 > 大きなサービス側システ ム構成の変更 – 複数サービスの統合 – サービスを複数に分割 – バックエンド基盤の置換 > 集計・分析を考慮した設 計を求める > 具体例 – niconico動画/生放送iOS → niconico iOS – システム構成の変更による PKの変更,追加 – KPIに関わる基盤置換 > 開発プロセスにKPI設計と 数値評価が含まれる組織 体制 ポイント 実際
  34. 34. 過去データとの整合性(2) 過去データ取込 > ストアデータとログデータ のフォーマット差異 – サービス開始の後から データ取り込みを行う場合 > 外部サービスの統合や買 収,企業統合など ポイント
  35. 35. 過去データとの整合性(2) 過去データ取込 > ストアデータとログデータ のフォーマット差異 – サービス開始の後から データ取り込みを行う場合 > 外部サービスの統合や買 収,企業統合など > コメントデータ – 一定レコード毎にファイル に直書き – ファイルをディレクトリ階層 で管理 – ログとしては,レコード更新 毎に1行吐き出す ポイント 実際
  36. 36. まとめ
  37. 37. まとめ > ETLはそれ単体ではなく,以下の点を併せて考慮す る必要がある – データ活用の方針 – 各システムの仕様と変更可能性 > WebサービスのETLは,サービス自体や用いる技術 が時間とともに大きく変化する – 標準化 + モジュール化 + 例外処理の余地 – 仕様変更を事前に考慮 & 仕様変更時の仕様強制
  38. 38. 以上

×