「Hadoop Conference Japan 2014」へ行ってきました

Event Hadoop Apache

休暇中なので「Hadoop Conference Japan 2014」へ遊びに行ってきました。

使ったことない技術の話をいろいろ聞いてみよ〜〜という軽いノリで、14:40のセッションから参加しました。

以下にメモをアップしておきます。

「Taming YARN: how can we tune it?」 小沢さん

  • YARNが提供するレイヤーの概要
  • ResourceManager、NodeManager、ApplicationManagerの役割
  • 設定ファイルに何をどう書くか
  • Mesos（http://mesos.apache.org/） TODO: あとで概要みる
  • Tez（http://tez.incubator.apache.org/） TODO: あとで概要みる
  • RMが落ちたらどうなるか
感想

YARNのアーキテクチャの話がすごく面白かった。

JVMのPermSizeのチューニングの話をしていたのであれっと思ったら、YARNはJava 1.6対応なんですね。

https://github.com/apache/hadoop-common/blob/trunk/hadoop-yarn-project/hadoop-yarn/README

「Spark1.0での動作検証 - Hadoopユーザ・デベロッパから見たSparkへの期待」 土橋さん

最初は、スペシャルゲストの田中聡さん（NTTドコモ）による「社会の頭脳システムの構築と運用」の話。

  • 2009年からプラットフォームの運用開始
    • 遠隔地にサーバを置いて、いい感じに運用保守した
      • 停まったサーバが出ても放置しておいて月1回修理に行けばOK
    • ツールは全部OSSを利用
  • 課題1: スループットとレイテンシへの要求
    • 対策としてマイクロバッチ化
    • しかし、1000台もVMがあると起動に時間がかかる
    • 今は高密度クラスタと最新Hadoopで評価中
    • 大規模クラスタでも小さいフットプリントで計算できるものに期待
      • Spark, Storm
  • 課題2: Hadoop進化への追従
    • データが大規模になると他に移すのが大変
    • 2つのクラスタを構築して片方で新しいHadoopを評価
      • しかし、クラスタ間で計算結果データの維持が必要
    • 同一クラスタ内でデータを共有しながら使うモデルに期待
      • YARN

今後は、インメモリ、ストリーム、バッチ処理をYARNの上でやる感じとのこと。

ここで土橋さんにバトンタッチして、巨大Hadoopクラスタの上でのSPARKのお話。

  • なぜSparkに着目したか
    • 過去
      • 6年前は自作のデータローダでHDFSにデータを突っ込んでいた
      • 取り出しも同じく
      • 時間のかかる処理を短く実行できるようになってうれしかった
    • 現在
    • 分析系のフレームワークを動かしたいという要求が出てきた(Cythonなどですでにやってる場面も）
    • SparkのようにHadoopの上で動いてスループットとレイテンシを両立してくれるものが登場
    • 分析に便利に使えそうな高度なAPIもある
  • 昔のHadoopはスケーラビリティに限界があるといわれていた
    • データ管理がオーバヘッドに
  • 大釜のようなクラスタを立てて，その上でデータをシェアしたり分析したりしたい
  • YARNが成熟してきたので使いものになるか確認したかった
  • 今日はSoark内部の仕組みの話はしない
  • SparkにはMesosモードとYARNモードがある
    • 今回は後者の話

今回の検証で確認したかったポイント4つの説明。

  1. 数十TBのデータをSparkに突っ込んでもちゃんと動くかどうか
    • おなじみwordcountのプログラムで
  2. ユーザ定義のオブジェクトをSparkのキャッシュに明示的にのせることができる
    • ロジスティック回帰のプログラムで
  3. シャッフルプロセスのパフォーマンス
    • GroupByTestというプログラムで
  4. multi-stageジョブにSparkを使うとどうなるか
    • とあるプロジェクトで（詳細は公表できないらしい）

検証環境の紹介。

  • 4k core
  • 10TB RAM
  • full 10G接続
  • Spark on (YARN, HDFS) on CentOS
  1. 線形にスケールした
    • データローカリティが効いた？
  2. キャッシュにデータをのせた結果を確認
    • 3回の学習データの読み込み
      • 1回目はHDFSから。2、3回目は一部キャッシュから、一部HDFSから。
    • キャッシュに乗り切らないサイズになると、乗った分については処理時間を短縮してくれる
    • ユーザ定義のオブジェクトをぽんぽん載せるとメモリを有効活用できない
      • キャッシュにのせるデータをできるだけシンプルにするべき（シンプルとは？については後述）
  3. 大きなシャッフルを投げた結果
    • データサイズが大きくなっても大きな変化はなし。ほぼ線形に推移
    • スループットは、NW I/OとおなじくらいディスクI/Oによって制限される
    • 大きなデータをシャッフルしようとするとメモリのチューニングに苦労する
  4. フィジビリティテストに成功？

最後にTipsについて。

  • キャッシュメカニズムを効率的に使おう
    • シンプルなデータフォーマットでキャッシュにのせよう
    • 取り出すときにリッチに変換しよう
  • YARNとの組み合わせで考慮すべきことがまだいろいろある
    • ここ半年くらいで改善されていくのでは


「Evolution of Impala - Hadoop 上の高速SQLエンジン、最新情報」 嶋内さん

Impara凄く速いから皆使えという話。

  • HDFSやHBase上のデータに対して仮想ビューとしてテーブルを作成できる
  • クライアントがSQLリクエストを投げる
  • Impaladがフラグメントプランを作る
  • QueyCodinatorがデータ読み込み（？）
  • Query Exec Engineで計算
  • QueryCordinatorに結果を返す
  • インメモリでの実行
    • 実際に使われるメモリはクエリによる（どれくらいのサイズのテーブルの何割の行を使うのか？）

新しめの機能の紹介。

  • LLVMでJITコンパイル
    • このおかげで5〜6倍高速化
  • コストベースのJOIN最適化を導入
  • メタデータの伝搬を助けるcatalogd
    • リフレッシュとか明示的に実行する必要はもうない
    • テーブルを指定しての実行も可能
  • ユーザ定義関数の導入
    • C++, Java, Pythonで書ける
    • 外部システム　-> HBase <- Impala、という組み合わせも可能
  • アドミッションコントロール
    • リソースプールに対してあれこれ設定できる
    • 制限は「ソフトリミット」
  • YARNとLlama（Low Latency Application MAster）のお話
  • Apache Sentry
    • テーブル、ビュー、行、列の粒度でアクセス制御ができる
  • Parquet
    • 圧縮効率がよく、スキャン効率もよい
    • c.f. ファイルフォーマットごとにクエリ速度をテストしたグラフ（in スライド）
  • Compute Stats
    • 統計情報の収集と保存
  • TPC-DSでのベンチマーク結果紹介
    • 一番重要といわれるCPUの使用効率でも良成績
  • EDW（=Enterprise Data Warehouse？）ワークロードにおける評価指標

計測の注意点の話。

  • クラスタだけでなく、データセットとクエリも2倍のものを用意して、同じ結果が出るかを確認
  • 実際のデータを個々のワークロードで確認してね
  • 評価データとしては1TB以上はないとダメ
    • 今回は15TBでテストした

あと、今年の今後のリリースについて。

  • SQL 2003準拠の関数（LEAD, LAG）の導入
感想

性能を決めるのはどんなクエリを発行するかなので、クエリの書き方やデータの持ち方を考えるのが大事なんだろうなぁと。

「実践機械学習 ―MahoutとSolrを活用したレコメンデーションにおけるイノベーション」 草薙（@nagix）さん

  • NS-SHAFTというゲームを開発したのでダウンロードして欲しいとのことw
  • レコメンデーションは「かかった時間とお金」対「効果」重要
  • 強力だけどシンプルなレコメンデーションが欲しい
  • 今日はその例を紹介
  • データ（ユーザとアイテムのインタラクション）
  • “I want a pony!”
  • 他の人がどういう行動をとったかをベースにレコメンドする
    • 皆が同じものを買っていたらそれ以上の情報を出せない問題
    • 素の共起データの問題: 本当に欲しいのは「例外的な共起」
  1. 人×アイテムのマトリクスを作る
  2. アイテム×アイテムマトリクスを作る
  3. LLR検定をして役に立つインジケータを見つける
  4. インジケータマトリクスを作る
  • 共起バイナリマトリクス
  • どんなデータを「例外的な組み合わせ」と見なすか
    • Aの有無に関わらずBが出現 →意味がない
    • サンプル数が少なすぎる →意味がない
    • 極端で、そこそこサンプル数がある組み合わせが望ましい（LLRは標準偏差に近い）
  • MahoutのRowSimilarityJobがLLRを使っている
  • Lucene: 検索のコア機能
  • Solr: Luceneのラッパー
  • LucidWorksを今回は使った

なぜこれらの検索エンジンを使うかというと、クエリのモデルとレコメンデーションのモデルとが似通っているので、効率的に検索エンジンに表示できる、というアイデアによる。らしい。

ここからサンプルアプリケーションを使って説明。

  • 「曲を聴く」という行動をベースにレコメンデーションを表示
  • MusicBrainz（https://musicbrainz.org/）というフリーのデータセットを利用
  • ログファイルをMahoutで分析してインジケータを作り、検索エンジンに突っ込む
  • それをアイテムメタデータと突き合わせる（？ スライド参照）
  • MapRはNFSで他のシステムと連携できるのが特徴
  • ユーザ中心レコメンデーション: リアルタイム計算が必要。非効率で低速
  • アイテム中心レコメンデーション: 事前計算可能。応答が速い
  • マルチモーダルレコメンデーションとは
  • ユーザのサイト上の行動は複数ある
    • 入力したクエリ、視聴したビデオ、購入した商品・・・
  • これらを結果に反映するのがMMR
  • クロスレコメンデーションのほうがユーザにとって有益
    • 例）クエリを元にクエリを補完、動画から動画をレコメンド → クエリをもとに動画をレコメンド
    • 単なるクエリの部分一致によるレコメンデーションではなく、関連がありそうな多様なレコメンデーションができる
  • 重要な問題
    1. 閲覧範囲: ユーザはトップページしか見ない
    2. 多様性: いつも同じレコメンデーションだと飽きられる
    3. 学習速度: それ以上学習しなくなる（飽きられた結果、ユーザ行動に基づく学習がそれ以上できなくなる）
  • 解決策として結果のディザリング
    • 結果をいじって予期せぬ結果を入れる
    • オフライン性能は悪化するが、長期に行うと、何もやらないよりも格段にレコメンデーションの結果が上がる
  • なぜディザリングが必要？
    • ユーザはTOPから3ページ目以降はほとんど見ないから、それらのアイテムに関して学習できなくなってしまう
    • 結果として、ロングテール部分が有用かどうか、指標が得られない
    • 品質を多少損ねても、ロングテール部分のトレーニングを積極的にやらせる
    • ランクの対数にガウス分布を加えた合成スコアを使う
感想

結果のディザリングの話が面白かったです。amazon.comのオススメ商品が毎回ちょっとずつ違うのは、そういうわけなのかな。目的に納得でした。

NS-SHAFTやってみました（買ったばかりのiPhoneで初めて遊んだ記念すべきゲームになりました）。なんというか、Terrariaで縦穴に落ちていく時の感じを思い出しましたw

というわけで

はじめてのHadoop Conference楽しかったです。

運営の皆さま、発表者の皆さまありがとうございました。扇子もこの夏活用させていただきます。