Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

12.358 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Sex in your area is here: ❤❤❤ http://bit.ly/39mQKz3 ❤❤❤
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Dating for everyone is here: ❤❤❤ http://bit.ly/39mQKz3 ❤❤❤
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

データドリブン企業における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. 以上

×