読者です 読者をやめる 読者になる 読者になる

よしだのブログ

サブタイトルはありません。

勉強会メモ - Hadoop Conference Japan 2014

IT、プログラミング 機械学習、ビッグデータ

f:id:yoshi0309:20140708095610j:plain

今日は Hadoop Conference Japan 2014 に参戦しました!おもに、機械学習関連のセッションを中心に参加しましたが、参考になること、勉強になることが盛りだくさんでした。あと、神様にも会えましたよ!

登壇者の皆様、スポンサーのリクルートテクノロジーズの皆様、出展企業の皆様、ありがとうございました!

というわけで以下、メモです。

参加したセッション

参加したセッションの一覧です。以下のメモを記載しています。*1

  • キーノート
  • リクルート式Hadoopの使い方 3rd Edition
  • Hivemall: Apache Hive を用いたスケーラブルな機械学習基盤
  • Mahoutによるアルツハイマー診断支援へ向けた取り組み
  • ライトニングトーク
  • Treasure data on the YARN
  • 実践機械学習 - Mahout とSolr を活用したレコメンデーションによるイノベーション

その他の資料はこちらからどうぞ。

Hadoop Conference Japan 2014- Eventbrite

キーノート

まずは、キーノートです。

概観

濱野 賢一朗 氏(日本Hadoopユーザー会, NTTデータ)

  • 参加登録者数:1296人、65%初参加(朝時点)
  • はじめて普及した並列分散処理
  • データ読み込みのスループットの最大化
  • シンプルなモデル (MapReduce)
  • Hadoop を取り巻くバージョンは更に複雑になりつつある。。
  • YARN
  • MRv1 は手堅いが、パフォーマンスなど課題がある。
  • 複数の並列分散処理エンジンを併用できる環境
  • メモリの大容量化、10Gbpsネットワークの普及、インメモリ処理の実現性向上
  • Hive が利用者 No.1、Zookeeper、HBase・・ (fluentd、Impala、Spark などもランクイン)
  • Hadoop JIRA のチケットによく日本人の名前も見るようになってきた

Ther Future of Data

Doug Cutting 氏 (Hadoopの生みの親、現Cloudera所属)

  • 未来は分からないが、予測はできる。
  • ハードウェアの価格は更に安く
  • データの価値は更に高まる(よりハイレゾリューションに)、そのためのソフトウェアが必要になる
  • そしてオープンソースが勝ち残る (luceneは 1999 から開発開始しているが、事実生き残っている)
  • オープンソースは使う側から見ても開発上のリスクを低減する。とくにプラットフォーム技術はOSSであることが「要求」される
  • Hadoop機能はさらに向上し、Hadoopが当たり前になる
  • Hadoopがビックデータ界を席巻
  • トランザクション処理でさえHadoop上での実行が可能に
  • Google Spanner みたいなのもやるかも
  • エンタープライズデータハブ
  • 様々なデータの種類やバージョンも保持するようになる
  • http://www.slideshare.net/cloudera/enterprise-data-hub-the-next-big-thing-in-big-data

The Future of Spark

Patrick Wendell 氏 (Spark主要開発者、Databricks)

  • 500 patch 200update issue 140 user list
  • ゴール
  • データサイエンティストやエンジニアの能力の拡張
  • 表現力のある API
  • API の安定性、下位互換性を提供する
  • 開発者にやさしいリリースサイクル。マイナーリリースは3ヶ月に一回、更に小さい修正は適宜。
  • Spark SQL / MLLib / GraphX / Spark Streaming
  • Spark の未来はライブラリにある
  • Spark SQL
  • 他のコンポーネントよりも急速に成長
  • SQL言語と型月スキーマRDDの考えをサポート
  • Spark1.1上のバージョンでは、JDBC/ODBC接続用のサーバーを用意する
  • MLLib
  • 2番めに成長の速いコンポーネント -MLLib 1.0 には15の機械学習あアルゴリズムが同梱されているが,MLLib1.1 のリリース時には倍近い機械学習アルゴリズムへと拡張していく予定
  • SparkR を production ready にする
  • Databrics Cloud は すぐに Spark クラスタを提供する

Hadoopエコシステムの変遷と、見えてきた使いドコロ

太田 一樹 氏 (Treasure Data CTO)

  • 本当に Hadoop である必要があるのか?本質的な価値とは?
  • 1.どんなタイプのデータを集められる
  • 2.経済的に保存できる。
  • 3.高速に扱うことができる
  • 4.うまくデータを扱う
  • 集める:fluentd や Flume 、Kafka、Sqoop などソフトウェアが発展してきている
  • 保存:テキストだけでなく、効率的なフォーマットで保持できる、圧縮など。KVSなど。
  • 高速:Spark/DAG型、データ処理フレームワーク External DSL/Internal DSL、
  • うまく:SQL-on-Hadoop、機械学習

  • データベースの進化

    • MPP (Teradataなどなど)
    • 複雑なことができる、安定性
    • 多くのベンダーが Hadoop 対応を発表している、進んだクエリオプティマイザを武器に
    • スキーマ管理・・
  • データをわかっている人が、Hadoopを通して、直接データにアクセス・分析できる時代がくる

  • 現在のトレンド、hadoop で集計したデータを MPP データベースに保存して、BIツールで分析する
    • 技術の成熟度が低いからこういうアーキテクチャになっている
  • Hadoopは、より構造化データとの境界線へと突入。Hadoopベンダーのコンソリデーションも進むかも
  • MPPデータベースは、非構造化データの領域に踏み込む
  • 3大ベンダーがバイアウトされると予測される
  • さらに混沌の時代へ、トレンドを読みながら技術を選択することが必要。

リクルート式Hadoopの使い方 3rd Edition

石川信行 氏 (リクルートテクノロジーズ)

  • 利用状況

    • 本番 98台 開発 24台
    • 543TB
    • Job数 28,344/day
  • 紹介案件の分類

    • 社内の既存アセットの利用
    • 社内システムへの展開
    • 他デバイスとの連携
    • HBASE を用いたオンライン連携システム
  • リクルートエージェントの求人レコメンド

    • キャリアアドバイザーを擬似的に作成
    • キャリアアドバイザーによる紹介での求人応募が10%でそれと同等の応募を実現
  • リクナビNEXT
    • 求職者検索システム、求職者のアクティブ率を16段階で評価
    • 求人の関連に合わせて返信があった結果を元にレコメンド
  • ゼクシイ
    • レコメンドをプッシュ通知
  • リクルートエージェント:求人志向チェック
    • 選択状況に応じてレコメンドする内容を変更。
  • ポンパレモール

    • レコメンドロジックを中央化し、jsp組み込みで簡単にレコメンドを導入できるように仕組み化
    • レコメンドするデータを HBase に保管
    • APIから取得したデータを HBase にキャッシュして高速化。オフローディング
    • HBase の格納したデータをグラフ描画(js)し、反応をリアルタイムでみる。
  • データ解析基盤について

    • 一番下に Hadoop があり、そこからDWHなどに移動し、可視化・活用
    • 今後はアドホックの分析基盤を導入したい
    • 第三世代の Hadoop の導入
  • 技術導入の過程

    • いつもの体制は、コンサル+エンジニア+マーケター(事業主体)
    • マーケターの知識が向上、データドリブン施策の重要性が認識・拡散
    • 質と量の2点で進化
  • 技術開発

    • 自然言語解析、画像解析を進めている
  • 画像解析
    • HBaseに保存、特徴量抽出をスパースコーディングの手法で実現
    • デジタル化したデータから特徴量を抽出する
    • 自動タグ付け、類似が総検索、カラーヒストグラムなどのベクトル演算、色や形での検索
  • テキスト解析
    • TF-IDF→SVMやRandomForestによる分類、係り受け分析、文書要約
    • Skip-Gram : work2vec の改造版
    • 単語をベクトル表現で洗わず、ベクトル計算によるクラスタリングや距離計算、単語のたし引きによる気付き
  • グラフ

    • 人同士のつながりや、クライアント店舗同士の近さ・・・
    • Tital : Hbase をバックエンドに使用したグラフエンジン。HBase に乗せるだけなのでとても安い。
  • SQL-on-Hadoop

    • presto 検証中
    • Drill ベータプログラム参加予定
    • Impala 検証中
  • presto のパフォーマンス比較

    • Hive の8倍速いが、一部 Hive より遅いものもある
  • DataLake構造

    • Hadoop になんでもデータを貯めるようにしたい
  • QA

    • 運用で辛いところは、バージョンや進化が速いのでキャッチアップが大変
    • バッチ処理がこけた場合の対応方法は、監視ツール(oss)を使っていたり、独自で job の専有時間などを監視している。失敗した場合は、再度流し直している。間に合わない場合はあきらめている。

Hivemall: Apache Hive を用いたスケーラブルな機械学習基盤

油井 誠 氏 (産業技術総合研究所)

スライド:bit.ly/hjc14-hivemall

  • Hivemall とは
    • Hiveを使った機械学習ライブラリ -クラス分類と回帰分析
    • 推薦
    • k近傍探索
    • LGPL
    • Github
  • なぜ新しい機械学習基盤か?
    • Mahout / Vowpal Wabbit / Spark MLlib / Oxdata H2O / Cloudera Oryx (Vowpal Wabbit は海外で人気)
    • 既存のフレーームワークは利用するのにプログラミングが必要で敷居が高い
    • 例えば、Mahout を用いたクラス分類には 60行 以上書く必要がある。
  • Hivemall
    • プログラミング不要、コンパイル、パッケージングが不要、既存Hiveユーザーにフレンドリー
    • データ量に対してスケーラブル
    • 計算資源に対してスケーラブル (EMRのbootstrapを用意している)
    • 最新のオンライン学習アルゴリズムをサポート、Confidence Weighted(クラス分類)
  • 機械学習を集約関数として実行するアプローチ
  • 性能比較 (Vowpal Wabbit / Bismrck Spark 1.0 MLlib)
    • テストデータ:KDD Cup 2012 Track2 データセット
    • 検索エンジン広告の広告クリックスルー率
    • 確率的更改勾配法:オプションが若干それぞれ異なる。
    • 実行時間、精度ともに1位

Mahoutによるアルツハイマー診断支援へ向けた取り組み

髙田 正彬 氏(新日鉄住金ソリューションズ)

  • 取り組みの背景
    • NEDOのプロジェクトの一環。アルツハイマー病の超早期診断
    • 1:臨床研究クラウドサービスの構築
    • 2:超早期診断支援のための検証
  • 臨床研究クラウドサービスの構築
    • 5~10TBのデータが格納される見込みのため、分析ツールとして Hadoop を検討
    • データの利活用のターゲットとして超早期診断を選択
  • 超早期診断支援のための検証
    • 機械学習により超早期診断の支援を検証
    • 大量データ・多変量に対応できる手法を利用
  • アルツハイマー病は患者数も多く社外的費用も10兆円と大きい
  • 不可逆的に神経細胞が変性するため、超早期診断が必要
  • Random Forest を採用(精度が高く出やすいと言われている)
  • 利用したデータは MRI と PET (いずれも画像データ)
  • 健常者と患者をそれぞれ30人ずつ
  • 複数モダリティの機械学習
    • 次元縮約 + Random Forest の場合、次元縮約が原因で精度が落ちると考えられた
  • Random Forest を使う理由う
    • 精度が一般的に高い。平均的に RF が最も精度が高い (2008 比較論文 より。見逃した。。)
    • 分散処理可能で、処理時間を短縮できる
  • Random Forest とは
    • 多数の決定木を構築する手法、ここの決定木にランダム性を組み込み、高い汎化性能を実現
    • 主要なパラメータは2つだけ:データをいくつに分割するか、決定木の本数
  • 複数モダリティの場合(Frayらの手法 [Gray et al., 2012])
    • 案1:2つの特徴点をくっつけて1つのデータとして扱う(複数扱っているのに個別と精度はそれほどかわらない)
    • 案2:個別に次元縮約して、そのあと結合し RandomForest を実行 (精度が上がる!)
    • 前述のとおり、次元縮約に精度を落としている理由があると考えた
    • 新手法:個別にモデルを作成し、そのモデルを結合してあつかう
  • 精度検証
    • 個別では80%+、決定木200本で精度が安定、データ分割数は影響しない。
    • データ合成させる手法:90.8%
    • モデル合成させる手法:91.7%
    • Gray の手法よりも精度が良い
  • RF による特徴部位の抽出
    • RF により特徴部位の抽出が可能。決定木の上位。
    • プロットすることで大事なところがわかる

ライトニングトーク

ライトニングトークの部です!

Shib: WebUI provides cross-over between Hive and MPP

田籠 聡 氏 (LINE株式会社)

  • クライアントは色々ある hive cli /beeline /hue /Shiv /WebHive などなど
  • 必ず自動的に結果が保存されるようにしてあげること
  • 管理者向けのクエリを実行するのと通常のクエリを実行するクライアントを分ける
  • よく実行するクエリは実行できる塊で管理しておきたい
  • クエリはすぐに結果が取り出せる形で共有する
  • Shibおすすめ select しか実行できない。データベース/テーブルアクセスコントロール。
  • MPP? UI でクエリを投げる先のエンジンを切り替えられる。presto など

Cloudera サポートの現場から、YARNの最新事情

嶋内 翔 氏 (Cloudera 株式会社)

  • YARN:リソース管理のフレームワーク
  • ジョブが失敗する→メモリが不足→メモリはちゃんと確保しましょう
  • VMで動かしてたらそもそもジョブが起動しない。リソースが不足していると起動すらしない。ちゃんと用意しましょう。
  • バグもまだある

SparkとMLlibで実現するかんたん高速機械学習

山下 勝司 氏 (株式会社マーズフラッグ R&D部)

  • Hadoopは繰り返し処理が遅い→Sparkへ
  • 繰り返し処理=機械学習
  • 機械学習は実装が困難。アルゴリズム、テストが困難、実装しちゃダメ。
  • MLLib Spark1.1 で機能が増えるらしい。
  • 簡単に書ける、速い。が、実際にどのぐらい速いかはデータやパラメータにも依存するのでケースbyケース。概ね hadoop よりも速い。
  • サンプリングでデータを減らす、リソースの追加でパフォーマンスを更に高速化

FluentdやNorikraを使ったデータ集約基盤への取り組み紹介

添田 健輔 氏 (リクルートテクノロジーズ ITソリューション統括部 ビッグデータインフラG)

  • Fluentd、自動復旧に monit、データ可視化に es + kibana、異常値検知に Norikura 、Docker
  • Beaconログを集めて保管、RedshiftやS3、elasticserch など
  • サービスの起動時に設定ファイルをダウンロードして起動
  • monit、サービスやプロセスを監視し、自動復旧
  • es + kibana
  • td-agent は安定していて運用ができる。es + kibana が楽ちん。Norikuraは他にも色々使えそう。docker 超便利
  • td-agent2 への置き換え、bigquery、Treasure Agent Monitoring Service、Norikraはリアルタイム用途で使いたい。docker は引き続き。

Apache Flume 1.5を活用したAmebaにおけるログのシステム連携

飯島 賢志 氏 (株式会社サイバーエージェント)

  • 転送の分岐など柔軟なルーティング、信頼性、HDFS/HBaseへの書き込みが充実、独自のものを開発しやすい、Avroでの圧縮転送
  • 各サービスから Aggregator を経由して、ストアに転送
  • 1600ホスト、14万行/sec、一日2TB、トラフィック 80Mbps(圧縮後)
  • 複数のチャネルに同じものを転送できる、フェイルオーバー、ロードバランシング
  • ここ一年は特に安定して使えている。

5分でわかる Apache HBase 最新版

嶋内 翔, Cloudera 株式会社

  • HBaseはもはや死火山。 -復旧時間が改善
  • 0.92 分散ログ分割により改善
  • ログ分割がマスタでしか出来なかったものを分散して行うことができるようになった。
  • 分散ログリプレイ
  • 書き込みを先に復旧する大幅に改善
  • 名前空間とマルチテナント

Treasure data on the YARN

小林 隆 氏 (Treasure Data)

  • スキーマレス
  • hive pig impala presto サポート
  • HDFSは使っていない 自前の plazmaDB に格納している S3上にかどう
  • 色々カスタムしていたが、YARN対応後に大幅に変更されていて辛い
  • hadoop 4 クラスタ、全てプロダクション。ユーザーの場所やデータ量に応じて配分   - 独自のスケジューラーとキューを実装しており実現
  • YARN クラスタを作って確認中
  • 5000ユーザー、6 トリリオンのレコード数

  • YARN

    • リソースマネージャーとノードマネージャー、application manager、job history server
    • job history server を起動しておかないと過去実行したログが見れなくなる
    • 注意 2.4.0 以降を必ず使うこと。 2.2.0 / 2.3.0 には重大なバグがある。
    • 設定ファイルも結構変わっているので注意が必要。対応表もある。移行する場合は要確認
    • pseudo は結構バグがあるので使ってはいけない。動かなくなることがある。
  • mapper と reducer だったのが、container という概念に統一された

  • リソースの見積もりは hotonworks の hdp-configuration-resouce.py もしくは Ambari で大まかな値を出す。

  • QA

    • Ambari のようなツールは使うか?細かい設定をしたい場合はあまり向かない。

実践機械学習 - Mahout とSolr を活用したレコメンデーションによるイノベーション

草薙 昭彦 氏 (MapR)

  • I want a pony とは、無茶ぶりのことw
  • 群衆の行動は、個人の行動を推測するのを助けてくれる
  • 欲しいのは例外的な組み合わせ
  • ディザリング、長期でやると質が上がってくる

関連エントリ。

書評 - 実践 機械学習 レコメンデーションにおけるイノベーション - よしだのブログ

*1:ページ内アンカーの貼り方がわからん・・・