勉強会メモ - Hadoop Conference Japan 2014

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データ）

Hadoop Conference Japan 2014 ご挨拶・Hadoopを取り巻く環境 from hamaken

参加登録者数：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 の安定性、下位互換性を提供する
開発者にやさしいリリースサイクル。マイナーリリースは３ヶ月に一回、更に小さい修正は適宜。
Spark SQL / MLLib / GraphX / Spark Streaming
Spark の未来はライブラリにある
Spark SQL
他のコンポーネントよりも急速に成長
SQL言語と型月スキーマRDDの考えをサポート
Spark1.1上のバージョンでは、JDBC/ODBC接続用のサーバーを用意する
MLLib
２番めに成長の速いコンポーネント -MLLib 1.0 には15の機械学習あアルゴリズムが同梱されているが，MLLib1.1 のリリース時には倍近い機械学習アルゴリズムへと拡張していく予定
SparkR を production ready にする
Databrics Cloud はすぐに Spark クラスタを提供する

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

太田一樹氏 (Treasure Data CTO)

本当に Hadoop である必要があるのか？本質的な価値とは？
１．どんなタイプのデータを集められる
２．経済的に保存できる。
３．高速に扱うことができる
４．うまくデータを扱う
集める：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

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

Hadoopカンファレンス20140707 from Recruit Technologies

利用状況
- 本番 98台開発 24台
- 543TB
- Job数 28,344/day
紹介案件の分類
- 社内の既存アセットの利用
- 社内システムへの展開
- 他デバイスとの連携
- HBASE を用いたオンライン連携システム
リクルートエージェントの求人レコメンド
- キャリアアドバイザーを擬似的に作成
- キャリアアドバイザーによる紹介での求人応募が10%でそれと同等の応募を実現
リクナビNEXT
- 求職者検索システム、求職者のアクティブ率を１６段階で評価
- 求人の関連に合わせて返信があった結果を元にレコメンド
ゼクシイ
- レコメンドをプッシュ通知
リクルートエージェント：求人志向チェック
- 選択状況に応じてレコメンドする内容を変更。
ポンパレモール
- レコメンドロジックを中央化し、jsp組み込みで簡単にレコメンドを導入できるように仕組み化
- レコメンドするデータを HBase に保管
- APIから取得したデータを HBase にキャッシュして高速化。オフローディング
- HBase の格納したデータをグラフ描画（js）し、反応をリアルタイムでみる。
データ解析基盤について
- 一番下に Hadoop があり、そこからDWHなどに移動し、可視化・活用
- 今後はアドホックの分析基盤を導入したい
- 第三世代の Hadoop の導入
技術導入の過程
- いつもの体制は、コンサル＋エンジニア＋マーケター（事業主体）
- マーケターの知識が向上、データドリブン施策の重要性が認識・拡散
- 質と量の２点で進化
技術開発
- 自然言語解析、画像解析を進めている
画像解析
- HBaseに保存、特徴量抽出をスパースコーディングの手法で実現
- デジタル化したデータから特徴量を抽出する
- 自動タグ付け、類似が総検索、カラーヒストグラムなどのベクトル演算、色や形での検索
テキスト解析
- TF-IDF→SVMやRandomForestによる分類、係り受け分析、文書要約
- Skip-Gram : work2vec の改造版
- 単語をベクトル表現で洗わず、ベクトル計算によるクラスタリングや距離計算、単語のたし引きによる気付き
グラフ
- 人同士のつながりや、クライアント店舗同士の近さ・・・
- Tital : Hbase をバックエンドに使用したグラフエンジン。HBase に乗せるだけなのでとても安い。
SQL-on-Hadoop
- presto 検証中
- Drill ベータプログラム参加予定
- Impala 検証中
presto のパフォーマンス比較
- Hive の８倍速いが、一部 Hive より遅いものもある
DataLake構造
- Hadoop になんでもデータを貯めるようにしたい
QA
- 運用で辛いところは、バージョンや進化が速いのでキャッチアップが大変
- バッチ処理がこけた場合の対応方法は、監視ツール(oss)を使っていたり、独自で job の専有時間などを監視している。失敗した場合は、再度流し直している。間に合わない場合はあきらめている。

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

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

Hdj2014 myui from myui

スライド：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 データセット
- 検索エンジン広告の広告クリックスルー率
- 確率的更改勾配法：オプションが若干それぞれ異なる。
- 実行時間、精度ともに１位

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

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

Mahoutによるアルツハイマー診断支援へ向けた取り組み (Hadoop Confernce Japan 2014) from Hadoop Conference Japan

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

ライトニングトーク

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

Shib: WebUI provides cross-over between Hive and MPP

田籠聡氏 (LINE株式会社)

Shib: WebUI tool provides crossover of Hive and MPP from SATOSHI TAGOMORI

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

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

嶋内翔氏 (Cloudera 株式会社)

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

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

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

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

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

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

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

FluentdやNorikraを使ったデータ集約基盤への取り組み紹介 from Recruit Technologies

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)

Treasure Data on The YARN - Hadoop Conference Japan 2014 from Ryu Kobayashi

スキーマレス
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 のようなツールは使うか？細かい設定をしたい場合はあまり向かない。