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をBQにマイグレしようとしてる話

2.788 Aufrufe

Veröffentlicht am

2017/03/29 Google Cloud はやわかりセミナー in 名古屋での、松田の講演資料になります

Veröffentlicht in: Technologie
  • Login to see the comments

HadoopをBQにマイグレしようとしてる話

  1. 1. HadoopをBQに マイグレしようとしてる話 Mar 29 2017 リクルートテクノロジーズ ビッグデータ部 松田徹也
  2. 2. 自己紹介 松田 徹也 まつだ てつや 2011.4 某通信キャリア入社 2011.6 新人研修で東海支店(名古屋 伏見)で1.5ヶ月営業OJT 2011.8 R&D組織配属 2015.8 リクルートテクノロジーズ入社 ・ビッグデータクラウド基盤開発 ・Hadoop運用 ・A3RT開発 NEXTでもらいました!
  3. 3. リクルートのビジネスモデル Matching Business HR Bridal Group Buying Used Cars Travel Real Estate Beauty Gourmet Social Games E-Commerce Ad Network New Business Consumers Enterprise
  4. 4. リクルートの事業領域 「選択」をサポートするような情報サービスを展開 Life event area 斡旋領域 結婚領域 就職・転職領域 住宅領域 中古車領域 出産・育児領域 学習領域 Lifestyle Area Travel IT/ TrendLifestyle Health & Beauty
  5. 5. リクルートテクノロジーズの立位置 Infrastructure /Security Big Data Solutions Technology R&D Systems Development Recruit Holdings Recruit Career Recruit Sumai Company Recruit Lifestyle Recruit Jobs Recruit Staffing Recruit Marketing Partners Staff service Holdings Recruit Administration Recruit Communications Business/ Service Function/ Support Project Management UXD/SEO Internet Marketing Recruit Technologies
  6. 6. リクルートHadoopのイメージ
  7. 7. リクルートHadoop クラスタを用途(サービス)毎に作って個別運用 ● 大量(規模+数)クラスタの運用 ● リソース量の綿密なコントロール
  8. 8. Hadoop課題感 ● 同時並列実行 ● バージョンアップ ● 処理リソースとデータ量のバランス ● 運用労力
  9. 9. 課題1:同時並列実行 ● バッチとアドホックの制御 ○ 施策系のバッチ(レコメンドリスト作成・メール配信)が最優先 ○ データサイエンティストはアドホックに常に分析したい ● バッチウインドウの調整 ○ 新しい施策を回したいけど、差し込める幅が無い ● 利用用途・利用ユーザーの拡大 ○ 非エンジニアの利用 ○ 期末などに集計祭り
  10. 10. 課題2:バージョンアップ ● EOSL ○ ディストリベンダーのサポート期限 ○ 新しい機能は欲しくなくても強制的にバージョンアップ ● クラスタ ○ 全クラスタを順番にバージョンアップ ○ 検証環境を同時には用意できない ● 運用チームは常にバージョンアップしている ○ 全てのバージョンが上がった頃には、すでに次の計画・・・
  11. 11. 課題3:処理リソースとデータ量のバランス ● クラスタ毎にHadoop用途が異なる ● データをどんどん溜めたいクラスタ ○ 処理リソースのお代わりはいらないのに・・・ ● 処理リソースが欲しいクラスタ ○ データ量はいらなくても、処理能力だけ欲しい ○ 一時的(夜間・期末etc)に処理リソースを増やしたい
  12. 12. 課題4:運用労力 ● パッチを1ヶ月がかりで全クラスタに適用・・・ ● どのクラスタも余裕なくてカツカツ ● 構成管理 ● 増減計画・発注
  13. 13. BQで解決できそう ※BQ = BigQuery   https://cloud.google.com/bigquery/
  14. 14. Hadoop課題感 ● 同時並列実行 ● バージョンアップ ● 処理リソースとデータ量のバランス ● 運用労力
  15. 15. Hadoop課題感 ● 同時並列実行  クラスタ・リソース確保という概念がない ● バージョンアップ ● 処理リソースとデータ量のバランス ● 運用労力
  16. 16. Hadoop課題感 ● 同時並列実行  クラスタ・リソース確保という概念がない ● バージョンアップ  バージョンアップ不要のはず!(Legacy SQL…) ● 処理リソースとデータ量のバランス ● 運用労力
  17. 17. Hadoop課題感 ● 同時並列実行  クラスタ・リソース確保という概念がない ● バージョンアップ  バージョンアップ不要のはず!(Legacy SQL…) ● 処理リソースとデータ量のバランス  完全分離・どちらも無限 ● 運用労力
  18. 18. Hadoop課題感 ● 同時並列実行  クラスタ・リソース確保という概念がない ● バージョンアップ  バージョンアップ不要のはず!(Legacy SQL…) ● 処理リソースとデータ量のバランス  完全分離・どちらも無限 ● 運用労力  フルマネージド
  19. 19. 試しに少しやってみた HIVE文化の中 そもそもBQ自体が受け入れられるのか?
  20. 20. 試しに少しやってみた HIVE文化の中 そもそもBQ自体が受け入れられるのか? 分析に使っているデータを一部BQに入れて BQで分析をしてもらう
  21. 21. 試しに少しやってみた “ ” もうHiveには戻れないっす 某データサイエンティスト “ さんざん甘い汁吸わしといて やっぱりやめます とか言わないでくださいよ 某データサイエンティスト
  22. 22. オンプレ 現状の構成 バッチ サーバ JP1 共有Storage FTP サーバ OracleDB Hive load I/F files ssh ・HQL ・MapReduce ・bash script メールレポート
  23. 23. GCP 移行後の構成 オンプレ 共有Storage OracleDB BQサービス バッチ サーバ JP1 loadI/F files ssh BigQuery バッチサー バ ・SQL ・bash script ・メール送信 ・データ連携 FTP サーバ Nessie (データ連携) メールレポート FTP サーバ
  24. 24. GCP 移行後の構成 オンプレ 共有Storage OracleDB BQサービス バッチ サーバ JP1 loadI/F files ssh BigQuery バッチサー バ ・SQL ・bash script ・メール送信 ・データ連携 FTP サーバ Nessie (データ連携) メールレポート FTP サーバ
  25. 25. Nessie ロゴ作成中 データ連携API ● データ連携用ワーカーのコントロール ● データ連携ジョブ管理 実装済連携 ● Hiveテーブル→BQ連携 ● Oracleテーブル→BQ連携
  26. 26. Nessieアーキテクチャー概要 Frontend API Worker Queue Worker Monitor Job Statut Manager Worker Operator DataTransfer Worker Nessie https://www.flickr.com/photos/josek/2616023190
  27. 27. Nessieアーキテクチャー概要 Frontend API Worker Queue Worker Monitor Job Statut Manager Worker Operator DataTransfer Worker Nessie https://www.flickr.com/photos/josek/2616023190
  28. 28. やってみた アプリケーション(HQL, UDF, JAR)の移行 HQL→Standard SQL UDF→UDF MapReduce→クエリ化 Nessie・その他周辺機能 特に問題なし Nessie性能 問題発生!
  29. 29. Nessieの性能 データ転送速度が遅すぎて、業務性能要件を満たさない 現状 Sqoop Nessie Embluk 性能差 tableA 12秒 54秒 22% tableB 366秒 908秒 40% tableC 1011秒 7264秒 14% tableD 1841秒 ??? ???
  30. 30. What’s Next? ● Nessie高速化 ○ Sqoop方式で検証 ■ 高速化できることを確認済み(3.31) ● BQダッシュボード ○ 各テーブル毎諸々(データ量・最終アクセス日etc) ○ slot利用状況 ● バックアップ機能 ○ オペミス対策

×