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

heki1224の適当な日記

技術知識を忘れないように書き留めておくブログ

Hadoop Conference Japan 2013 Winterに行ってきました その2

Hadoop HBase 勉強会

昨日、東京ビッグサイトで行われた「Hadoop Conference Japan 2013 Winter」に行ってきました。
その2です。
その1はこちら

当日メモ(午後)

リクルート式Hadoopの使い方 2ndEdition:石川 信行(リクルートテクノロジーズ)

2011年から2012年までどう進化したか
●体制
・データアナリストは2種類
 1. コンサル型データアナリスト
  →分析力、論理的思考力
 2. エンジニア型データアナリスト
  →データマイニング機械学習
・ビックデータGが出来た
 事業担当者(マーケター)+データアナリスト

●事例
・失敗しまくり
 →分析しっぱなし
 →予算がとれない
 →データを信用しない
  →泥臭い普及活動したから、認知度上がった

・ビックデータの定義
 たくさんのデータ
 いろんな種類のデータ
 すぐ使えるデータ

・システム構成
 第1世代
  CDH

 第2世代
  MapR + Greenplum

・エコシステム
 Hive
 HBase
 Mahout

・規模
 13事業で120データ利活用事例

・分類
 1. 大量集計
  →モニタリング、資料作成
 2. スコア計算/アルゴリズム
  →メール、WEB、リコメンド
 3. 分析前集計(分析用の変数を作る)
  →ロジック作成、シナリオ作成

(事例1)
リクナビ 行動履歴による100件レコメンド

(事例2)
リクナビネクスト 転職仲間機能
属性の近いユーザを対象にアクティブユーザをレコメンドする

(事例3)
リクナビ リクともLiteメール版
転職仲間のロジックをリクナビに移植。
就活仲間をメールで配信

(事例4)
オファー施策の改善
 →転職エージェントがどのタイミングで利用者にアクセスしているのか?
 ・オファーのタイミング分析など
 →1日ごとのデータをHadoopに流し込んでMapReduceで処理する

・導入から得られた効果
Hadoop事務局を作って、案件の集中化
 →無駄の排除。
案件検討スキームを作った
 →使いやすくした

・今後
 シナリオマーケティング
 テキスト解析

●技術
・はたらいくテキストマッチング
 →テキスト解析から属性を分類する(クラスタ
 →クラスタリングしたものへの推薦記事のレコメンド

・HBaseの活用
 社内資源の活用 すでにあるアルゴリズムの適用
 行動履歴を保存する→アルゴリズム適用→リアルタイムレコメンド
  →HBase、Hadoopで実装

・これから
 コプロセッサ使いたいです

・利用率向上のための施策
 1. ユーザビリティ強化
  →webhive
 2. 機能追加
  →マスタデータのインサート、デリミタ変更
 3. Tips集
 →TIPS集にメッセージ機能を追加してみた

introduction to Impala:小林大輔(Cloudera)

http://www.slideshare.net/Cloudera_jp/hcj2013winter-introduction-toimpala20130121

●Impalaとは
低レイテンシ・分析特化型クエリ実行基盤
Google Dremel, Google F1などにインスパイアされた
データサイエンティストが使うことを想定
Hadoop内部で直接実行されるSQLクエリエンジン
高パフォーマンス
C++で開発してます
→MapReduce非依存

●Impalaまでの軌跡
MapReduce
→分散バッチ処理
 →問題点
  ・書くのが大変、Javaでかかないと・・・。
   →だからHiveやPigなどが生まれた
Hive
SQLライクなMapReduce用クエリ原稿
 →HiveQLをMapReduceに置き換えて、動作する仕組み
  →問題点
   ・高レイテンシ、すぐに結果が出てこない
    →MapReduceを使ってるから、そこに依存するよ・・・。
そこでImpalaですよ!

●Impalaのアーキテクチャ
・Impalaデーモン
 →クエリを実行する場所
  plannerはJava
  coordinatorはC++
  executorはC++

・Impalaステートストア
 →ネームサービスを提供する場所

メタデータの処理
・Hiveのメタストアを利用

実行エンジン
C++
 LLVMによるコード生成
ステートストア
 ネームサービスを提供
 
SQL
 現時点ではSELECT、INSERTのDMLのみ対応
 →HiveQLでDDL
 ハッシュJOINのみサポート
 FROM句に記述した順番でJOINする
 
●デモ
Hive vs Impala
CDHサイトにあるデモを使うよ
 Hive 207秒
 Impala 3秒

●今後の予定
GA(Q1リリース)
JDBCドライバ対応
・ファイルフォーマットとして、Trevni
DDL対応
SQLパフォーマンス

GAリリース後の計画
・UDF
・コストベースオプティマイザ

●まとめ
データサイエンティスト用のツール
バッチ処理や業務処理には向きません。

Hadoop上の多種多様な処理でPigの活きる道:山下 真一(NTTデータ

●hadoopのよくある光景
1. 独自実装が増えるよ・・・
2. データが増える、クラスタが増える
3. スピード感がなくなる・・・

●pigの存在
開発の中心は米国Yahoo!出身者
pigLatainという言語で定義
データの流れで処理を定義
→データ型やジョブ定義などは意識しなくてもOK
→データ操作関数も充実してるよ
→業務処理はUDFで実装している

●pigを飼い慣らすと
1. 処理構文書くときは最後まで全部書く
→構文評価して、MapReduceに変換するところが最適化される

2. 分散キャッシュを使いましょう
ディストリビュートキャッシュを使いましょう

3. カウンターも使いましょう
UDF内でカウンター情報を記述可能
warnメソッドでカウンター使える

4. テストはどうする?
デバッグ用構文がpigにはあります。
DESCRIBE
DUMP
EXPLAIN
ILLUSTRATE

テストツールあります。
PigUnit

統計情報ツールあります。
PigStats

チューニングは公式ドキュメントに載ってます

●hiveとの組み合わせ
分析用データ作成まではpig
分析はHiveで処理

スケーラブルなシステムのためのHBaseスキーマ設計:嶋内 翔(Cloudera)

http://www.slideshare.net/Cloudera_jp/hbase-hcj13w/

Apache HBaseとは
・HDFS上で動作するNoSQL
GoogleBigTableを参考に作られている
・シャーディングをサポートしている
・書き込みが高速で、しかもスケールアウト可能
・データの耐障害性も確保されている

スキーマ設計の話の前に
必要がない限り、HBaseを使わない

無い機能がいっぱいある
・JOINがなり
・インデックスがない
・セカンダリインデックスがない
トランザクションがない
etc…

じゃ、どんな時にHBaseを使えばいいの?
「大量のデータがあるとき」
→これからもデータが増える事がわかっているとき。

RDBとHBaseにおけるスキーマ設計の違い
「論理設計まではほぼ同じ」
→物理表現レベルの話が違うだけ

しかし、設計段階で物理表現を知ることは重要

●HBaseのアーキテクチャ
・HBaseテーブル
 行と列によるテーブル構造
  列は列ファミリでグループ化されている
  行は行キーで引く
 バージョンを持っている

・リージョンと列ファミリ
 テーブルは、複数のリージョンで構成されている
 列は、列ファミリと列が存在する
 
・テーブルでは、辞書順に行をソートしている
・テーブルのスキーマは列ファミリのみ定義している
 列自体は何個でもつくれます
 セルでNullは物理ファイルが作られないので、コストゼロ。
 テーブル名以外は全てbyte[]として格納される

スキーマ設計のポイント
・論理設計までは同じ
ユースケースはしっかり設計しておく

設計の指標 DDI
・非正規化
・複製
インテリジェントキー

・非正規化
HBaseにはJOINがない
→非正規化=2つの論理エンティティを1つの物理エンティティで定義する
 メリット
  速い
 デメリット
  更新が大変

・パフォーマンスとカーディナリティ
行キーのみで検索するのがパフォーマンスが出る
列ファミリの選択はスキャン対象のデータの数を減らす
値だけのフィルタはフルスキャンと同じ →やめましょう

・値のシフト
値を行キーに入れてしまう。
で、値はnullにする

・Tall vs Wide

・キー設計
シーケンシャルリードなのか?書き込みパフォーマンスなのか?
アクセスパターンに基づいて、シーケンシャル or ランダム キーを決める

具体的なキー設計手法
・リバースドメイン
・ハッシュ付与
・ソルト
・リバースタイムスタンプ

名前
・列ファミリ・列の名前は短い方がいい

ホットスポット
・特定のリージョンサーバにデータアクセスが集中してしまう現象

●まとめ
ユースケース
アクセスパターン
HBaseの内部構造

馬本
第1章、第8章、第9章
このあたりを読む