Hadoopの話聞いてきた

勉強会 hadoop

「Hadoopを技術とサービスの両面から学ぶ勉強会」でHadoopの話を聞いてきました！*1

大規模分散処理基盤Hadoop活用のカンドコロ(猿田さん)

  • Hadoopって？
    • OSSによる大規模分散処理フレームワーク
      • Google基盤ソフトウェアGFSのOSS実装
    • 集中管理型のクラスタ構成
      • データはブロックに分割して複数のサーバに分散配置
      • 処理を分割し複数のサーバで分散処理
    • バッチ処理に威力を発揮
      • 数時間〜数日の処理を短時間で処理
    • 高スループットなシーケンシャルI/O
      • 大きなブロックサイズ、デフォルト64MB
      • データローカリティ(処理に必要なデータを持っているサーバに処理を割り当てる)
    • NameNode/JobTracker(マスター)
      • ブロック管理、監視
      • DataNode状態監視
      • メタ情報管理
      • DataNodeとは違ってSPOF
    • DataNode/TaskTracker(スレーブ)
      • 1つのブロックを複数のDataNodeで保存。どれかが壊れてもデータを失わない
  • よくある誤解
    • 誤解1
      • × 高速なRDBMS/分散ファイルサーバ
      • ○ 大容量に特化したバッチシステム
        • オンライン処理(低レイテンシ処理)は不向き
        • 小さなデータやランダムアクセスには不向き
    • 誤解2
      • RDB ： データは正規化される
        • データを管理するという観点から、データ重複を避けるため
      • Hadoop ： データあえて正規化されない場合が多い
  • 可用性向上の仕組みがいっぱい…だけど
    • MapReduce
      • JobTrackerがSPOF
      • Hadoop2.0の新たな分散処理フレームワーク「YARN」ではZookeeperでマスターの可用性を向上
    • HDFS
      • NameNodeがSPOF
      • Hadoop2.0ではNameNode HAという可用性向上のしくみが導入されている
    • 枯れた技術を駆使するという解決案
  • 数百台以上規模のHadoopクラスタの運用上の課題
    • 初期構築、設定変更が大変
    • 台数が多くなれば当然「どれかが故障している」率は高くなる
    • オペレーションのパターンを最小限に抑えるようにする
      • 統一された運用設計でオペミスを排除
      • 障害発生時の例外対応を最小化
      • 対応への所要時間の最悪値を制御
        • 初期構築、設定変更、増設、障害回復
          • → OSの自動インストール
        • 複数台のサーバに同時インストール
          • → 構成管理
      • 運用の簡素化のための割り切り
        • 細かい障害原因の切り分けはしない
        • 壊れたら引っこ抜いて新しいのに変える
  • 大規模データの低レンテンシアクセスを達成する技術
    • HBase
  • 最新動向
    • Hadoop2.0系(alpha)
      • NameNode HA
        • ZooKeeperを利用したActive-Standby構成
        • NameNodeのメタ情報を分割して保持
        • NameNode1台あたりの必要リソース量も下がる
      • YARN
        • リソース管理とジョブのライフサイクル管理を分離することで1万台ぐらいまでスケールするようになる
        • (MapReduceだと4000台程度)
    • CHDH4
      • Hadoop2.0ベースのディストリ
  • まとめ
    • HadoopはHDFSとM/Rで構成される大規模分散処理基盤
    • Hadoop自体は低レイテンシ処理は苦手、バッチによる高スループット処理が得意
      • ただし周辺のエコシステム(HBase)により達成できる
    • 運用も視野に入れたインフラ設計が大事

ソーシャルゲームにおけるHadoop活用事例(Gloops 井澤さん・滝さん)

  • 解析の流れ
    • Hadoopはデータを蓄積しておく場所
    • データを蓄積するためにユーザのアクション時のデータをログに出力
    • 蓄積されたデータの整形集計
    • 定期的にBIツールに取り込んで分析
  • HadoopとRDBMSの解析の違い
    • RDBMはデータ量が多いと処理が困難
    • HadoopならM/Rで分散処理可能
    • RDBMSは1つのテーブルに過去現在未来のデータが混在
    • Hadoopはログの分け方によるが日付ごとにデータを分けたりが簡単。アクティブな(だった)データが取れる。
    • RDBMSは更新可能、過去のデータが残らない場合も
    • Hadoopは挿入型。過去のデータが残る。
      • 画面遷移に掛かる解析とか。RDBMSで全URL遷移とかは残しておけない
    • RDBMSではアクティブユーザのみの解析が困難な場合がある
      • 過去現在のデータが混在しているので結合したり再集計したりして死ぬ
    • 巨大なデータが蓄積、処理できるのでこんなデータを入れておくと良い
      • URLの遷移などのRDBに保存しないような細かいデータ
      • レベルや所持アイテムなど更新してなくなってしまう系のデータ
      • ただしログ書き込みで遅くなったら死ぬので書きだすタイミングは考える
  • Hadoopログの集計
    • Pigを使えばM/Rを直接書くよりは楽
      • とはいえSQLとは概念が違うのでそのままと言う訳にはいかない
      • Pig
        • 実行時に定義できるがオプション(スキーマレス)
        • トランザクションもインデックスもなし
        • 遅い(裏でM/R動くので低レンテンシ処理は無理)
        • UDF(ユーザ定義関数)を作れてカスタマイズ性が高い
      • Hive
        • SQLに似ているので学習コストは低い
        • 簡単なデータ抽出に向いてる
  • Hadoop導入苦労あるある
    • ログ埋め込むの面倒
      • そのデータこの画面に持ってないよ
      • 出力するデータ項目を取得するのに無駄なDBアクセスが必要になるとソシャゲーは死ぬ
      • 本当にそのタイミングで出力すべきものか考える
    • Pig分かりづらい
      • プログラム覚えるよりは楽だけど癖が強い
      • エラー文言がモロにJava
      • 慣れれば複雑なSQLよりは楽
  • ソシャゲーにおけるデータマイニング
    • マイニングとは鉱山から鉱石などを採掘すること
    • データという鉱山の中から金脈を見つけ出し宝を掘り出すこと
    • データはお客様の声を語る
    • データ分析はお客様サポートと同じ
    • 様々な問題の答えはお客様の声の中にある
    • Hadoop導入の目的
      • データの中に答えがある
      • 出来るかぎり大量のデータを保持したい
      • Hadoopなら分析を効果的に効率的に実施可能に
  • gloopsにおけるHadoopの活用事例(マジゲを題材に)
    • ゲームの柱
      • 自分オリジナルの最強デッキを創りあげたい
      • カードを取得したい欲求
        • ガチャなど
        • トレード
      • 強化欲求
        • デッキ設定
        • カード強化
      • 腕試し、試合、イベント
        • ユーザバトル
        • モンスター討伐
    • 決定木を活用した分析
      • 決定木 ： 機械学習における予測モデルの構築
        • 決定に対して関連性の高いパラメータの抽出
        • 継続と離脱の分析に活用
    • 大型PR前に初期ユーザ離脱要因を改善したい
      • ある期間にアクティブかつLv5-10のユーザを対象にアクティブとスリープを1000件ずつランダム抽出
      • ある期間の各種パラメータや行動履歴を比較
        • レベル、友達の人数、ガチャの回数、などなど
    • 決定木分析ならSQLでもできるんじゃね？
      • できるけどHadoopならすべてのデータを蓄積(更新じゃなくて)できる
      • その時々の状況を抽出できる
      • より分析の精度が高まる
    • 大規模データを簡単に分析出来れば爆速PDCAが可能になる
  • データマイニング業務を実施する上で重視すべきこと
    1. what
      • 解決すべき問題は何なのか
    2. where
      • 問題はどこで起こっているのか
      • データから特定できるのはここまで
    3. why
      • 問題は何故起こっているのか
    4. How
      • 解決するために何をすべきか
      • 問題解決のために、いきなりHow(解決手段)にむかって当てずっぽな対策を打たない事が大事

まとめとか

Hadoop単体ではあくまでビッグデータ用の高スループット分散処理基盤…いわゆるバッチ用のシステムで低レイテンシ処理には向かないし、加えてMapReduce自体が柔軟なアルゴリズムではないので、何にでも適用できるというわけではない感じ。*2
ログ解析分野においては、やっぱり「容量気にせず何でもかんでも残しておける」というのは強いと思う。
ただし、運用設計やインフラ設計はマジ大事。なにせ数十台のクラスタリング環境で運用するのでその辺で下手すると運用で死人が出る。

*1:もう1ヶ月も前の勉強会のエントリを今更書く図太さ

*2:低レイテンシ処理におけるHBaseとか、周辺のエコシステムで実現可能な問題もある