View
25.985
Download
1
Category
Preview:
DESCRIPTION
This is the Japanese translation of the presentation at Tokyo HBase Meetup (July 1, 2011) Author: Jonathan Gray Software Engineer / HBase Commiter at Facebook
Citation preview
1
Realtime Big Data at Facebookwith Hadoop and HBase
Jonathan GrayJuly !, "#!!Tokyo HBase Meetup
Hadoop と HBase によるFacebook のリアルタイム・ビッグ・データRealtime Big Data at Facebookwith Hadoop and HBase
ジョナサン・グレイ / Jonathan GrayJuly 1, 2011Tokyo HBase Meetup
2
1 なぜ Apache Hadoop / HBaseなのか？
2 HBaseの紹介
3 FacebookにおけるHBase利 事例
アジェンダ
3
▪以前は Streamy.com の共同設 者▪ リアルタイム・ソーシャルニュース・アグリゲータ▪ 当初は PostgreSQL で構築▪ ビッグデータの問題をきっかけに Hadoop/HBase に乗り換えた
▪ Facebookのソフトウェア・エンジニア▪ データインフラとオープンソースのエバンジェリスト▪ HBaseと他の技術（Hadoop、Hive、Scribe、Thrift）の開発、デプロイ、サポート
紹介 ジョナサン・グレイ
4
なぜ Hadoop / HBase を使うのか？「リアルタイム」なデータに
5
OS ウェブサーバー データベース 語
6
OS ウェブサーバー データベース 語
キャッシュ データ分析
6
▪ MySQL は安定している、しかし、▪ 分散システムとしては設計されていない▪ テーブルサイズの上限▪ 柔軟性に けるスキーマ
▪ Hadoop はスケーラブル、しかし、▪ MapReduce は遅いうえに難しい▪ ランダム書き込みに対応していない▪ ランダム読み込みの対応が貧弱
既存ソフトウェア・スタックの問題
7
▪ スループットな key-value 永続化エンジン▪ Tokyo Cabinet
▪ 規模データウェアハウス▪ Hive
▪写真の格納▪ Haystack
▪その他もろもろの 途向けの 独 C++ サーバー
個別の解決策
8
▪ Facebook メッセージの要件▪ 巨 なデータセット。その 半はcoldデータ▪ エラスティック性、 可 性▪ データセンター内の強い 貫性▪ 故障の封じ込め
▪求めなかったこと▪ データセンター内のネットワーク分断▪ データセンター同 のアクティブ~アクティブ構成
私たちがデータストアに求めていたことは？
9
▪ 2010年初頭、FBのエンジニアチームがDBを 較▪ Apache Cassandra、Apache HBase、MySQLシャーディング構成
▪性能、スケーラビリティー、機能を 較した▪ HBaseは、抜群の書き込み性能と 分な読み込み性能を発揮▪ HBaseには「あったらいいな」と思う機能が数多く含まれていた
▪ アトミックな「読み込み → 変更 → 書き込み」操作▪ 個々のサーバーに複数のシャードを割り当て▪ バルク・インポート▪ MapReduce
HBase が要件に合致
10
HBase とは？分散型、カラム指向、多次元、ソート済み、可 性、ハイパフォーマンスな永続化ストレージ・システム
11
HBaseとは？▪分散型
▪ コモディティ・サーバーによるクラスター▪列指向
▪ スプレッドシートにはめ込むのではなく、データ構造をマッピング▪多次元、ソート済み
▪ ３つの次元が全てソートされている▪ テーブルは 順、 はカラム順、カラムはバージョン順にソート
12
HBaseとは？▪ 可 性
▪ ノード故障への耐性を持つ▪ いパフォーマンス
▪ ログ形式による いスループット▪ スキャンとランダム読み込みの効率を考慮した設計
▪永続性▪ 持続性（durability）を保証
13
▪ Hadoop の 部としてスタート▪ HBase によりHDFSのランダム読み込み・書き込みが可能に
▪ FBでの利 にあたって Hadoop の変更が必要だった▪ ファイルの 追記（append）▪ 可 性版 NameNode▪ 読み込み操作の最適化
▪そして ZooKeeper！
Apache HBase
14
HBase システムの概要
. . . HBASE
. . .
データベース層
ストレージ層
Master バックアップMaster
Region Server Region Server Region Server
Namenode Secondary Namenode
Datanode
ZK Peer
ZK Peer
協調サービス
Zookeeper QuorumDatanode Datanode
HDFS
. . .
15
HBase の特徴▪ い書き込みスループット▪ 平 向のスケーラビリティー▪ 動フェイルオーバー▪リージョンの動的なシャーディング▪ HBase では HDFS と ZooKeeper を利
16
い書き込みスループット
Key val
Key val
Key val
Key val
...
...
Key val
Key val
Key val
Key val
...
コミットログ Memストア17
い書き込みスループット
Key val
Key val
Key val
Key val
...
...
Key val
Key val
Key val
Key val
...
Key Value書き込み
Key val シーケンシャルな書き込み
コミットログ Memストア17
い書き込みスループット
Key val
Key val
Key val
Key val
...
...
Key val
Key val
Key val
Key val
Key val
...
Key val
コミットログ Memストア
メモリ上に保存
17
い書き込みスループット
Key val
Key val
Key val
Key val
...
...
Key val
Key val
Key val
Key val
Key val
...
Key val
コミットログ
シーケンシャルな書き込み
Memストア17
平 向のスケーラビリティ
Region
. . . . . .
18
平 向のスケーラビリティ
Region
. . . . . .
18
平 向のスケーラビリティ
Region
. . . . . .
18
平 向のスケーラビリティ
Region
. . . . . .
18
動フェイルオーバーHBaseクライアント
19
動フェイルオーバーHBaseクライアント
サーバーダウン
19
動フェイルオーバーHBaseクライアント
19
動フェイルオーバーHBaseクライアント
METAから新しいサーバーをつける
19
リージョンを動的にシャーディング
Region. . . . . .
20
リージョンを動的にシャーディング
Region. . . . . .
サーバーが過負荷に
20
リージョンを動的にシャーディング
Region. . . . . .
20
HBase は HDFS を利 しているHDFSのストレージとしてのうま味が 緒に付いてくる▪故障への耐性▪スケーラビリティ▪チェックサムで損傷を修復▪ MapReduce▪ HDFSにはペタバイト規模での 分なテストと利 実績がある
21
Facebook における HBase アプリケーション
22
事例１
Titan(Facebook メッセージ)
23
SMSメッセージ EメールIM/チャット
Facebook 新メッセージ
24
▪ FB史上 最 規模の開発作業▪ 15 のエンジニアで１年超▪ 20を超えるインフラ技術を統合
▪ Hadoop、HBase、Haystack、ZooKeeper、etc...
▪初 から、途 もない規模のサービス▪ 数億 のアクティブ・ユーザー▪ 毎秒6000通のメッセージ、５万件のインスタントメッセージ▪ 圧縮状態で 間300TBのデータ増加
Facebook メッセージング
25
メッセージングのチャレンジ▪ い書き込み性能
▪ メッセージ、インスタント・メッセージ、SMS、Eメールを１つ残らず▪ これら全てに対する検索 インデックス▪ 正規化されたスキーマ
▪途 もない規模のクラスター▪ 量のデータと利 形態から、 規模なサーバー・フットプリントが必然に▪ サービスの利 に影響のある停 は避けたい▪ 容易にスケールアウトできなければならない
26
典型的なセルの構成▪ メッセージング向けに複数のセル▪ １ラックあたり 20サーバー、１クラスターあたり ５つ以上のラック▪ コントローラー (マスター/Zookeeper) は各ラックに分散
ラック #2 ラック #3 ラック #4 ラック #5ラック #1
Region ServerData NodeTask Tracker
Region ServerData NodeTask Tracker
Region ServerData NodeTask Tracker
Region ServerData NodeTask Tracker
Region ServerData NodeTask Tracker
19x... 19x... 19x... 19x... 19x...Region ServerData NodeTask Tracker
Region ServerData NodeTask Tracker
Region ServerData NodeTask Tracker
Region ServerData NodeTask Tracker
Region ServerData NodeTask Tracker
ZooKeeperZooKeeperZooKeeperZooKeeperZooKeeperBackup NameNodeHDFS NameNode HBase Master Backup MasterJob Tracker
27
事例２
Puma(Facebook インサイト)
28
Puma以前HadoopによるトラディショナルなETL
Web Tier HDFS Hive MySQLScribe MR SQL
SQL
15分 ~ 24時間29
PumaHBaseによるリアルタイム ETL
Web Tier HDFS Puma HBaseScribe PTail HTable
Thrift
10 ~ 30秒30
▪リアルタイムなデータ・パイプライン▪ 既存のログ・アグリゲーション・パイプライン (Scribe~HDFS) を活▪ HDFSの低レイテンシ能 を拡張 (Sync+PTail)▪ スループットの書き込み (HBase)
▪リアルタイムでの集約を実現▪ ロールアップの追跡に HBaseのアトミック・インクリメントを活▪ ユニークユーザーの算出のために複雑な HBase スキーマ▪ チェックポイント情報を HBase に直接保存
Puma
31
▪ Map フェーズは PTail▪ ログ・ストリームを N個のシャードに分割▪ 最初のバージョンではランダム・バケットのみ提供▪ 現在ではアプリケーション・レベルのバケットを提供
▪ Reduce フェーズは HBase▪ HBase の個々の +カラムが出 キーになる▪ アトミック・カウンターを いてキーの数を集計▪ キーごとのリストや他の構造を維持することも可能
Pumaでリアルタイム MapReduce
32
▪リアルタイム URL/ドメイン インサイト▪ ドメインオーナーが 分のサイトに関する掘り下げた分析を閲覧▪ クリック数、いいね（Like）の数、シェアの数、コメント数、インプレッション数
▪ 詳細にわたる 統計学的な分類 (匿名データ)▪ 地域ごと、もしくは、グローバルな観点で集計されたトップURL
▪途 もないスループット▪ 数 億のURL▪ 毎秒 百万件を超えるカウントアップ
Puma for Facebook インサイト
33
34
35
事例３
ODS(Facebook 内部メートリックス)
36
▪ Operational Data Store▪ システム・メートリックス (CPU、メモリ、IO、ネットワーク)▪ アプリケーション・メートリックス (ウェブ、DB、キャッシュ)▪ Facebook メートリックス (利 状況、収益)
▪ 時間軸に沿ったグラフを簡単に作成▪ 複雑な集計と変換をサポート
▪ MySQLではスケールしづらい▪ 数 億の計測点に対する数百万のユニークな時系列▪ イレギュラーなデータ増加パターン
ODS
37
Facebook における HBase の将来
38
ユーザーとグラフ・データを HBase で
39
▪ HBase を MySQL の増強版という観点で考える▪ MySQL では 単位のACID属性のみを使 している▪ DBの 前には、常にインメモリー・キャッシュが置かれている▪ HBase はディクショナリとリストの保存に適している
▪データベース・ティアのサイズはIOP（I/O操作の重さと回数）で決まる▪ HBase はシーケンシャル書き込みだけを う▪ 少ないIOPは低コストにつながる▪ 巨 なテーブルを、 容量、低価格なコモディティー・ノードに配置
HBase を重要な 途に
40
▪ Facebook は、リアルタイム Hadoop/HBase に注 している▪ Facebook エンジニアによる 規模なチーム作業▪ オープンソース開発者との密接なコラボレーション
▪ Apache Hadoop Goes Realtime at FacebookSIGMOD 2011▪ http://borthakur.com/ftp/RealtimeHadoopSigmod2011.pdf▪ HadoopとHBaseに加えた変更点について、技術 からの詳細▪ 本番環境での運 経験
まとめ
41
Recommended