に参戦してきた

プログラム hadoop seminor http://atnd.org/events/4558:title
  • アジェンダ
    1. @okachimachiorzさんによるHadoopトレーニング2日目 -ここからが本番編-
    2. @ryu_kobayashiさんによるMapReduce障害がおきたときのフロー
    3. @fujibeeさんによる--cacheFileオプションからジョブ実行時のファイル分散の仕組みをコード読み
    4. @tatsuya6502さんによるHBase入門
    5. LT
      1. @yamiuraさんによるWiki解析
      2. @ryu_kobayashiさんによるHadoop+Cassandra
      3. @hamburger_kidさんによるHive vs Pig

Hadoopトレーニング2日目

MapReduce障害が起きたときのフロー

--cacheFileオプションからジョブ実行時のファイル分散の仕組みをコード読み

自己紹介
--cacheFileオプション

Apache HBase入門

  • @tatsuya6502さん
  • 5月：特徴、ユースケース
  • 6月：HBaseとCassandra - トレードオフを理解する
  • 7月：はまりやすい落とし穴
  • 7月：ロードマップ
HBaseとは
  • Hadoopデータベース
  • ランダムアクセス、シーケンシャルアクセスともに低レイテンシで行えるデータストア
  • Hadoop分散ファイルシステム上に構築
  • Google BigTableを参考に設計された
    • 柔軟なテーブル構造、カラムファミリー指向
    • BigTableとHBaseの主なターゲットはbig data
      • 数十億、数百億
  • リアルタイムのウェブとMap Reduce処理の両方に対応可能、HBaseでは、これらを同時に扱える
mysqlで1億件になってしまった！
  • 大量read - memcachedを採用、データの一貫性を失った
  • 大量write - 二次インデックスを廃止した
  • クエリプランの改善を試みるが、いうことを聞かず
  • テーブルの結合(join)に負荷が集中。非正規化を行い、リレーションを廃止した
  • なんとか乗り切ることが出いた、しかし、もし、10億件(もとの100倍)に達したら？
100倍 - シャーディング
  • データベースサーバを増やして対応する
  • テーブルをN個に分割
  • N x 2どのMySQLクラスタを構築。ここのパーティションをそれぞれのノードに割り当てる
  • これによりACID特性が失われた
  • そして最後は、5倍の大きさ(もとの500倍)に達した
500倍 - [再]シャーディング
もうお手上げかも…
  • 50億件のテーブルでカラム追加・削除・変更をしたい？ダウンタイムは？
  • 100ノードあると故障の頻度は？
HBaseの出番
  • 自動シャーディング
  • 柔軟性のあるテーブル構造
  • インデックスを持たない。行はキー順に格納される
  • 単純化されたクエリ。SQLはサポートしない
  • Hadoop Map Reduce をネイティブにサポート
  • 強い一貫性(strong consistency)とCAS操作
  • 高可用性(HA) - 故障を優雅に扱う
  • クラスタのモニタリングと管理機能
自動シャーディング
  • テーブルは、リージョンという単位で自動分割される
  • 1台のRSに数十〜数百のリージョンが載る
  • リージョンが大きくなると自動的に細分割される
  • RSを何台か追加することでさらに性能があがる
柔軟性のあるテーブル構造
  • カラムのデータ型はByte配列
  • 非成果したテーブルの格納に最適
  • 本当の意味のインデックスを持たない
単純なクエリ
  • HBaseはSQLに対応していない
    • Put: 行の追加または更新
    • Get: 行の取得
    • Scanner: サーバ側Filter 指定した範囲の一連の行を取得
    • Delete: 行の削除
  • 結合やgroup byは用意されていない
    • DIY：テーブルの非正規化で対応できる。MapReduceとCascadingで対応
強い一貫性
  • 行に関する操作はアトミック
  • 更新前の古いデータが見えることはない
  • CAS操作
    • checkAndPut
      • ユニーク値制約
      • 楽観的ロック
    • incrementColumnValue
      • カウンタや連番
クラスタのモニタリング
  • Ganglianadonado
  • JMX
HBaseクライアントAPI
  • Native Java API
  • GateWay
    • Thrift
    • REST
  • ゲートウェイアクセスによるレイテンシの低下は見られないが、大量にするのはやめた方がいい(サーバが一枚かむから)
パフォーマンス特性
  • Random Write: 驚異的
  • Sequential Read: 優秀
  • Sequential Write: いまいち
    • 負荷が1台に集中してしまっている
    • 追加の時にシャッフルするか、行キーに適当なランダムな値を追加する
  • Random Read: 悪い (特にベンチマーク)
    • ディスクドライブを追加する
    • LRUロックキャッシュのサイズを大きくする
ユースケース
  • 巨大データベースでオンラインアクセス
  • MRバッチをブチかます
    • キーワードインデックスや全文検索用インデックスを作成
    • リコメンデーションを算出
    • 様々なレポートや、OLAP Cubeなどを作成
  • Big Dataに対するMRバッチ
    • MRバッチの実行時に、ウェブクライアントのレスポンスを悪化させる心配をあまりしなくてもよい
      • 夜間バッチに制限しなくて良い
      • 頻度を増やして、ほぼリアルタイムな処理も可能
      • 十分な台数のディスクが必要(1ノード、4〜12台)
      • I/Oが非常にヘビーなMRバッチではウェブクライアントのレイテンシが低下
StumbleUpon(su.pr)
  • コンテンツのレコメンデーションエンジンを備えた唯一のURL短縮サービス
  • リアルタイムの分析処理はウェブからのデータ更新時に実行
  • 深い分析ではCascadingとMR処理
  • Thriftゲートウェイを使用して、PHPからHBaseにアクセス
  • HBaseの組み込みキャッシュを使うことで強い一貫性を保持
  • 90億行、1.3TBのデータをHBaseに格納
  • 700GBのテーブルを20分でMRできる(毎秒600万行)
Socorro: Mozillaのクラッシュレポート
  • 週250万件のFirefoxクラッシュレポートを受信
  • 1日あたりの平均350GBのデータが登録される
  • 現行システムでは、そのうちの15%しか処理できない
    • NFS: 単一ノードであることがボトルネックになり、バッチ処理がスケールしない
    • RDB: この規模のデータを格納することは非現実的
  • HBase & MRへ移行
    • 送られてきたクラッシュレポートは、すでにHBaseに格納
    • 2010年の第二四半期までにクラッシュレポートのMRによるん分析処理を開始
  • これによりすべてのクラッシュが分析可能に
  • 将来はさらに複雑な分析をする方向で検討中
MRバッチの能力を拡張する
  • HBaseをデータソースに設定し、HDFSでは不可能な処理を実現
  • HDFSファイルでは、書き込みは一度切り、ファイルの一部を書き換えたりできない
  • HBaseでは！
    • TwitterではPeople Searchの下準備としてHBaseのデータソースのカウンター値を更新しながらMRを実行
    • Yahooでは、文書の重複検出を行うためにHBaseとMRを活用 ほぼリアルタイムで検出
PigやHiveとの統合
  • HBaseを直接使うのではなく、PigやHiveの性能を向上させる
  • Twitter PigとHBaseの統合を開発中
    • 1日に7TBのデータが発生
    • 1日あたり20000ジョブを実行
    • ちなみに全データでツイートが占める割合は0.5%
    • すでにMRからHBaseを利用しているが、現在、Pigから使えるよう開発中
  • FaceBook
    • 現状は2000台のHadoop MR/HDFSクラスタ
    • 1日に12TBのデータが発生
    • 1日あたり7500女部を実行
      • 200人を超えるユーザ/ 最新データがすぐ結果が欲しい
    • Hive + HBaseの統合機能を20ノードクラスタ6TBのデータでテスト中
      • 低レイテンシなウェアハウスの実現へ！
そのたのユーザ
なぜBig Dataなのか？
  • 自分たちには大げさじゃない？
  • いやいや、コストの面で保存してないデータはないですか？
    • 過去10年の小売情報
  • Hadoopの登場で、データを保存したり、Pig や Hive によるアドホックな分析が実現できる時代になった
  • まず、データを貯めることから初めて見る
  • MRで分析して、その結果を HBase で社内提供しても良い
  • 去年じゃなくて過去10年、に予測の意味がある！

Wiki解析

Hadoop+Cassandra

Hive vs. Pig