ひつじのにっき

mhidakaのにっきです。たまに長文、気が向いたとき更新。

デブサミ 【17-E-3】 Hadoop：黄色い象使いへの道 〜「Hadoop徹底入門」より〜 下垣徹 氏

Developers Summit 2011(2月17日/東京目黒)に行ってきました。
いくつかセッションのメモをとったので備忘録代わりに。

まとめ

HadoopはGoogleのMapReduceの論文をベースに作られた大規模な分散処理フレームワーク。
高いスケーラビリティ、I/O性能を持つがRDBMSと競合するものではない。組み合わせて使うもの。
検索Indexの作成などバッチ処理に向いている。

以下、セッションメモです。

Hadoop：黄色い象使いへの道 〜「Hadoop徹底入門」より

スピーカー：下垣徹さん
もともとはDB屋さん。PostgreSQL使い。

Hadoop徹底入門はオライリー「象本」との棲み分けを目指して執筆開始

12月末日Amazonにてひっそりと発売告知。目次も公開されていない段階でランキング1位に。

Hadoop

Hadoop

こちらが象本。
Hadoop徹底入門

Hadoop徹底入門

Hadoop徹底入門：書きたいことはたくさんあったが、尺に収まらず、入らないものがでてきた。
FairScheduler Mahout などなど…次があれば入れてみたい。

本日のアジェンダ

  • Hadoopの概要
  • 適用事例
  • 「Hadoop徹底入門」の読み方
  • 黄色い象（Hadoopのキャラクター）使いへの道
  • Hadoop利用時のよく聞かれる質問

技術背景：Google

Google独自の基盤技術を用いて、大規模データを対象としたサービスを展開。自ら「クラウドコンピューティングを持ってサービスを展開」
Hadoopはオープンソースの大規模分散処理フレームワークで、Googleの基盤ソフトウェアのOSSクローン。
巨大なデータを並列で呼んで、データのローカリティを生かしてデータ処理する

  • 高いスケーラビリティ、小さくはじめて大きく活用
  • 大きな企業での活用事例が増えてきている

Hadoopクラスタの全体像

Hadoopは集中管理型の分散システム。全体を管理するマスターサーバが1つある。

  • 分散処理、ジョブ、データ管理はマスターサーバー
  • スレーブサーバーにはデータの実行処理がある

HDFSとMapReduceフレームワーク

HDFS：低価格のサーバーを大量に使用するのが前提。

データの多重化で可用性を担保する。故障の発生が前提の設計
サーバーが死んでも、ラックが死んでも、大丈夫なようにデータ配置を考えてくれる

MapReduce：分散処理のフレームワーク

Googleが検索インデックス作成のために公安
Map：ある一行のレコードを変換させるなど、1行分の処理
Reduce：集約処理

Hadoopの特徴

プログラム個別に分散ロジックを用意する必要がない(プログラムごとに分散処理を設計しなくてもよい)
高いスケーラビリティ。I/O性能を柔軟に拡張できる。コモディティサーバーが前提

Hadoopの適応領域

数十Gバイト〜テラバイト、ペタバイトのデータを扱うシステム（数十Gは小さいかな）
バッチ処理的な処理に向いている。オンライン処理的なところは適応できない。
リアルタイム性が求められるところの前処理に使える（検索インデックスを作るなど）

一般的にログ解析、レコメンテーション、検索、データマイニング、機械学習、データ変換の分野。

利用事例

  • facebook
    • 4TBのデータが毎日新規に生成、135TBのデータを毎日管理。Hadoopで処理したデータをOracleRACに、など棲み分けている

  • 楽天
    • 広告のインプレッションログ解析、レコメンテーション、ランキング集計。Perlスクリプトによる処理からHadoopに移行して26時間→4.5時間に短縮。20台ぐらいのクラスタを利用

適用領域の大事なポイント


RDBMSと競合するものではない。組み合わせて使うもの。

徹底入門の読み方

まずは1章から5章・6章まで通して読む。（204ページぐらい/全437ページ）
導入からはじまり、3章、4章は前半が理論、後半が使い方。
5章はプログラミング入門、開発したときのテストMRUnitまで解説
6章はSQL的インターフェイスHive。JavaでMapReduceを書きたくない・かけない場合はこちら。

残りの章は必要に応じて読みたいところを。
たとえば10章は性能向上のための性能チューニング、実践的な内容
7，8，9章は次のステップ。
7章：自動構築、高可用性
8章：可視化。台数が増えてくると、監視するための負荷が馬鹿にならない。
9章：マスターサーバーの信頼性を確保するなど（単一障害点の排除）
11章以降はHadoopと連携する周辺ツールの紹介

黄色い象使いになるためには

SQLがそのまま使えるわけではなくちょっと変更が必要だったりする
HadoopはRDBMSではない。トランザクション、1レコードの更新・削除、B-Treeインデックス、これらは存在しない。
RDBの常識を捨てて、大量のデータ処理に特化していると認識すること。
癖のあるシステムなので適材適所の観点で大量のデータの前処理をHadoop→検索はRDBMSにもっていくなど役割分担が必要


Hadoopへのマイグレーションってどう？

    • それなりに工数がかかることが多い。※OracleからPostgraSQLなどと一緒でHadoopに限った話ではない。
    • 別のメリットを見つけることが大事。スケーラビリティの確保など。
「何かの壁をぶち破るために」

何かとは処理時間であったり、大量のデータ(テラバイト)かもしれない。
マイグレーション前と全く同じ品質・機能・SLAを求められるとつらい
機能差違がつきもの。割り切って、メリットを享受したほうが幸せ。既存の処理は1行引っ張ってきて、どうこうする、というRDBMS前提の処理が書かれていることが多い。

そのままHadoopにもってくるのではなく、処理をまとめる(ジョブを減らす)と性能向上が顕著

ジョブ、クエリを減らす。

どのバージョンがいい？

コミュニティから提供されているのは0.21系。周辺プロダクトは0.21系を未サポート。安定性重視の場合はCDH(クラウディア社)