に参戦してきた
- アジェンダ
- @okachimachiorzさんによるHadoopトレーニング2日目 -ここからが本番編-
- @ryu_kobayashiさんによるMapReduce障害がおきたときのフロー
- @fujibeeさんによる--cacheFileオプションからジョブ実行時のファイル分散の仕組みをコード読み
- @tatsuya6502さんによるHBase入門
- LT
- @yamiuraさんによるWiki解析
- @ryu_kobayashiさんによるHadoop+Cassandra
- @hamburger_kidさんによるHive vs Pig
Hadoopトレーニング2日目
MapReduce障害が起きたときのフロー
--cacheFileオプションからジョブ実行時のファイル分散の仕組みをコード読み
--cacheFileオプション
- 別ファイルシステムにあるときに使う
- cacheFileオプション=fileを共有する仕組み
Apache HBase入門
HBaseとは
- Hadoopデータベース
- ランダムアクセス、シーケンシャルアクセスともに低レイテンシで行えるデータストア
- Hadoop分散ファイルシステム上に構築
- Google BigTableを参考に設計された
- 柔軟なテーブル構造、カラムファミリー指向
- BigTableとHBaseの主なターゲットはbig data
- 数十億、数百億
- リアルタイムのウェブとMap Reduce処理の両方に対応可能、HBaseでは、これらを同時に扱える
mysqlで1億件になってしまった!
- 大量read - memcachedを採用、データの一貫性を失った
- 大量write - 二次インデックスを廃止した
- クエリプランの改善を試みるが、いうことを聞かず
- テーブルの結合(join)に負荷が集中。非正規化を行い、リレーションを廃止した
- なんとか乗り切ることが出いた、しかし、もし、10億件(もとの100倍)に達したら?
100倍 - シャーディング
- そして最後は、5倍の大きさ(もとの500倍)に達した
もうお手上げかも…
- 50億件のテーブルでカラム追加・削除・変更をしたい?ダウンタイムは?
- 100ノードあると故障の頻度は?
HBaseの出番
自動シャーディング
- テーブルは、リージョンという単位で自動分割される
- 1台のRSに数十〜数百のリージョンが載る
- リージョンが大きくなると自動的に細分割される
- RSを何台か追加することでさらに性能があがる
柔軟性のあるテーブル構造
- カラムのデータ型はByte配列
- 非成果したテーブルの格納に最適
- 本当の意味のインデックスを持たない
単純なクエリ
強い一貫性
- 行に関する操作はアトミック
- 更新前の古いデータが見えることはない
- CAS操作
- checkAndPut
- ユニーク値制約
- 楽観的ロック
- incrementColumnValue
- カウンタや連番
- checkAndPut
HBaseクライアントAPI
パフォーマンス特性
- Random Write: 驚異的
- Sequential Read: 優秀
- Sequential Write: いまいち
- 負荷が1台に集中してしまっている
- 追加の時にシャッフルするか、行キーに適当なランダムな値を追加する
- Random Read: 悪い (特にベンチマーク)
- ディスクドライブを追加する
- LRUロックキャッシュのサイズを大きくする
ユースケース
- 巨大データベースでオンラインアクセス
- MRバッチをブチかます
- キーワードインデックスや全文検索用インデックスを作成
- リコメンデーションを算出
- 様々なレポートや、OLAP Cubeなどを作成
- Big Dataに対するMRバッチ
- MRバッチの実行時に、ウェブクライアントのレスポンスを悪化させる心配をあまりしなくてもよい
- 夜間バッチに制限しなくて良い
- 頻度を増やして、ほぼリアルタイムな処理も可能
- 十分な台数のディスクが必要(1ノード、4〜12台)
- I/Oが非常にヘビーなMRバッチではウェブクライアントのレイテンシが低下
- MRバッチの実行時に、ウェブクライアントのレスポンスを悪化させる心配をあまりしなくてもよい
StumbleUpon(su.pr)
- コンテンツのレコメンデーションエンジンを備えた唯一のURL短縮サービス
- リアルタイムの分析処理はウェブからのデータ更新時に実行
- 深い分析ではCascadingとMR処理
- Thriftゲートウェイを使用して、PHPからHBaseにアクセス
- HBaseの組み込みキャッシュを使うことで強い一貫性を保持
- 90億行、1.3TBのデータをHBaseに格納
- 700GBのテーブルを20分でMRできる(毎秒600万行)
Socorro: Mozillaのクラッシュレポート
MRバッチの能力を拡張する
- HBaseをデータソースに設定し、HDFSでは不可能な処理を実現
- HDFSファイルでは、書き込みは一度切り、ファイルの一部を書き換えたりできない
- HBaseでは!
- TwitterではPeople Searchの下準備としてHBaseのデータソースのカウンター値を更新しながらMRを実行
- Yahooでは、文書の重複検出を行うためにHBaseとMRを活用 ほぼリアルタイムで検出
PigやHiveとの統合
そのたのユーザ
- Adobe Systems
- Meetup
- Ning SNS SaaS
- Karooga, Photo Album Discovery
なぜBig Dataなのか?
- 自分たちには大げさじゃない?
- いやいや、コストの面で保存してないデータはないですか?
- 過去10年の小売情報
- Hadoopの登場で、データを保存したり、Pig や Hive によるアドホックな分析が実現できる時代になった
- まず、データを貯めることから初めて見る
- MRで分析して、その結果を HBase で社内提供しても良い
- 去年じゃなくて過去10年、に予測の意味がある!