http://pixabay.com/en/elephants-bathing-wildlife-addo-379477/
Hadoop Confence Japan 2014 参加レポートエントリ、2発目は #hcj2014 Keynote の次に参加してきたリクルートさんの Hadoop 事例。
こちらでは「とりかかり中の技術紹介」の部分が聞き甲斐ありました。
またビジネスでの利用を常に念頭に新技術に取り組んでいる*1というのは、どこの研究開発職も見習わないといけないところだなと思います。当たり前といえば当たり前のことですが、肝に銘じておきたいことだな、と。
では、以降にわたしのとってきたメモを公開しておきます。
13:00- リクルート式Hadoopの使い方 3rd Edition 石川 信行氏（リクルートテクノロジーズ）
最近のデータ活用状況紹介
- 本番 98 台、開発 24 台
- MapR
- 543TB
- mahout, hive, ZK, sqoop, HBase
- 2 万8千 Job/day
- 295 hive query/day
- データ解析案件 200/year
- 従事人数 155 名
データ利活用案件紹介
- 社内の既存アセットの利用
- リクルートエージェント
- 求人紹介レコメンド
- CA 300 名の成果と同等の成果をシステムで実現
- 求人紹介レコメンド
- リクナビネクスト
- スカウトが検索する求職者のアクティブ度を16段階で判定
- 過去に送ったメールのログ
- スカウト時の求職応募率 2.3% 上昇
- 求職者検索システム
- スカウトが検索する求職者のアクティブ度を16段階で判定
- リクルートエージェント
- 社内システムの展開
- 他デバイスとの連携
- ゼクシィ
- SiteCatalyst
- Pusna
- ゼクシィ
- HBase を用いたオンライン対応
- リクルートエージェント
- 求人志向チェック
- スマホリアルタイムレコメンド
- 相関原稿スコア
- 求人志向チェック
- ポンパレモールパーソナライズレコメンデーション
- Hadoop, mahout, HBase
- 事業データ、行動ログ
- HBase の構造
- ユーザIDに対してレコメンドデータをリストで保存
- 商品 API からとってきたデータを JSON 形式でそのままキャッシュ
- Highcharts JS
- ログ蓄積
- HBase を活用したい
- リアルタイムに蓄積されたデータをロジックにFBする
- もっと非構造データを蓄積
- ストリーム処理
- リクルートエージェント
ビッグデータ基盤構成概要
- それぞれみている人間が違う
- BI
- DWH
- Hadoop
- アドホック分析基盤
- Fluentd etc...
技術導入の過程 (今後は？の話)
- いつもの体制図
- コンサル型、エンジニア型、マーケターの三位一体
- マーケターのリテラシーが向上してきたことで、より高度な分析をするように
- 一個一個の案件の質が向上
- リクルートの開発ステージ
- R-Stage
- Dev-Stage
- Beta-Stage
- 運用-Stage
- 既存のシステムを使いつつ新しいものにチャレンジするアプローチ
- 今使えるものを活用しつつ、安く速く
とりかかり中の技術紹介 (5つ)
- 社内に眠るデータの可能性
- Hadoop に格納されている情報はまだわずか
- ただ貯めるというだけでもコスト
- Hadoop に格納されている情報はまだわずか
- 画像解析
- 一般物体認識
- HBase
- スパースコーディング
- 画像の中で最も特徴的なものを選ぶ処理
- エンコードのモデルをつくる
- 特徴抽出を一段階、二段階にわたり行う
- 画像に自動でタグをつけたり
- 類似検索
- カラーヒストグラム
- 一般物体認識
- テキスト解析
- TF-IDF
- 係り受け分析
- 文章要約
- Skip-Gram の利用
- 単語をベクトル表現できるところが面白い
- クラスタリングや距離計算できる
- グラフ
- 人同士のつながり、店舗同士のつながり、単語間のちかさ
- Titan の利用
- Gremlin
- Blueprints
- ...
- 類似、相関を探すのに使う
- メリット・デメリット
- あるノードを選ぶだけで近傍探索で他のノードを随時表示できる
- ただし用途が限定的
- SQL on Hadoop
- リクルート, Hive 利用多し
- 以下のみっつを検証中
- Presto
- Drill
- Impala
- Hive vs Presto
- 最大で Presto 8.8 倍速い、平均 3 倍速い
- 検証したけど封印したもの
- Azkaban
- 今年の Hadoop Summit ではホットになっていた
- Phoenix
- そのときは Join が使えなかった
- H2O
- Azkaban
まとめ
- 目的しっかり持つ
- 新技術に関してはビジネス適応イメージを持った上で検証
- ムダな工数削減、チューニング高速化のために共通化、型化する
Data Lake 構造
- Hadoop に逐次データ蓄積
QA
基盤運営でつらいところは？
- 自身は運用はガッツリしてないが
- 新技術との折り合い
- バージョンUp についていく
障害対応 (検知、リカバリプラン)
- 案件が増えてきて、流しなおせばいいは通じなくなってきてる
- 監視の仕組みは自己実装
- 流れっぱなしのクエリとか
- バッチは営業時間内におわるようにする、とか
メモは以上です。 では、また次のエントリで。
あわせて読まれたい
#hcj2014 の個人参加レポート
各セッションの個人メモ
- 10:00- Hadoop Conference Japan 2014 Keynote.
- 13:50- SQLによるバッチ処理とストリーム処理 田籠 聡氏 (LINE)
- 14:40- A Deeper Understanding of Spark Internals Patrick Wendell 氏（Databricks）
- 15:40- Apache Drill: Building Highly Flexible, High Performance Query Engines M.C. Srivas 氏 （MapR）
- 16:30- Evolution of Impala - Hadoop 上の高速SQLエンジン、最新情報 嶋内 翔氏（Cloudera）
- 17:20- 並列SQLエンジンPresto - 大規模データセットを高速にグラフ化する方法 古橋 貞之氏（Treasure Data）
*1:そうはいいつつも多くのプロダクトを試しているようでしたし。
