HBase: The Definitive Guide

CHAPTER 4

Client API: Advanced Features

この章の内容

• Filters ※前回はここまで

• Counters ※今回はここから。。

• Coprocessors ※毎度すみません、、、ここの途中まで。。。

• HTablePool

• Connection Handling

Counters (p168～)• 用途

– 統計情報を収集• オンライン広告のクリック数、ビュー数、など。• ログファイル内のデータを収集して後で分析。

• カラムをカウンターとして扱う。• クライアントからの1回のRPCで、アトミックに read-and-modify できるメソッドを提供。

• CRUD Operations(p76)を用いて、複数のcounterを1回のRPC呼び出しで更新できる(multiple counters -> p172～)。

• multiple counters の更新は１つのRowに制限されている。– 複数Row の counterの更新は、Row毎にRPC呼び出しが必要。

• #batch() はIncrement instanceを未サポート。(近い将来、変わるらしい)

An example using the shell (p168)

• テーブルを作成

• 2回インクリメント(=incr)

• 現在の値を確認(=get_counter)

hbase(main):001:0> create 'counters', 'daily', 'weekly', 'monthly'0 row(s) in 1.1930 seconds

hbase(main):002:0> incr 'counters', '20110101', 'daily:hits', 1COUNTER VALUE = 1

hbase(main):003:0> incr 'counters', '20110101', 'daily:hits', 1COUNTER VALUE = 2

hbase(main):04:0> get_counter 'counters', '20110101', 'daily:hits'COUNTER VALUE = 2

increment (p169) (p170下) (p171上:Table 4-6)

(p169)• shell の incrコマンド

– incr '<table>', '<row>', '<column>', [<increment-value>]

(p170下)(p171上:Table 4-6)• インクリメント

– 引数に0より大きい数字– 与えられた引数の値をインクリメント– 引数を省略した場合は1

• 現在の値を取得– 引数に0– shell の get_counterと同じ

• デクリメント– 引数に0より小さい数字– 与えられた引数の値をデクリメント

counterの初期化 (p169)• 明示的に初期化する必要はない

– 新しいcounterを使用する時に自動で0として初期化される。

– 最初のインクリメントの呼び出しで1、または引数で指定した数字を返す。

• 型はlong型

– Bytes.toBytes(long)

• 文字列(例：‘1’)でインクリメントすると結果がおかしくなる

– 文字列の‘1’ => 文字コード49 => byte[]の先頭が49 => [49,0,0,0,0,0,0,0] で解釈されるため

getでのcounterへのアクセス (p170上)

• getでもcounterにアクセスできる。が、結果が読みづらい。

hbase(main):007:0> get 'counters', '20110101'COLUMN CELLdaily:hits timestamp=1301574412848, value=¥x00¥x00¥x00¥x00¥x00¥x00¥x00¥x161 row(s) in 0.0400 seconds

hbase(main):008:0> get_counter ‘counters’, '20110101', 'daily:hits'COUNTER VALUE = 22

Single Counters (p171)

• shell の incrコマンド。

• HTableの以下のメソッド。

– writeWALのデフォルトはtrue

• Example 4-17 (p171)– ① 1インクリメント(amount = 1)

– ② 1インクリメント(amount = 1)

– ③現在値を取得 (amount = 0)

– ④ 1デクリメント (amount = -1)

long incrementColumnValue(byte[] row, byte[] family, byte[] qualifier,long amount) throws IOException

long incrementColumnValue(byte[] row, byte[] family, byte[] qualifier, long amount, boolean writeToWAL) throws IOException

Multiple Counters (p172～)

• HTableの以下のメソッド。

• Increment クラスのコンストラクタ

– 全てのcounterを含むRowのrow keyを設定する

– rowLockを引数で渡すことで自分で排他制御できる。

– 他の書込みに対して、 1 つの行内でアトミックであるが、他の読み込みに対してはそれは当てはまらない。

Result increment(Increment increment) throws IOException

Increment() {}Increment(byte[] row)Increment(byte[] row, RowLock rowLock)

Incrementクラス(p172～p173)

• 以下のメソッドで counter のカラムを定義

• 以下のメソッドで counter のexpire を指定

• Incrementクラスのその他のメソッド (p173) Table 4-7

Increment addColumn(byte[] family, byte[] qualifier, long amount)

Increment setTimeRange (long minStamp, long maxStamp) throws IOException

Example 4-18 (p173 ～ p174)

• ① Increment#addColumn

• ② HTable#incrementを実行。

• ③②のResultをログ出力。

• ④ Increment#addColumn

• 結果

"daily:clicks" -> 1"daily:hits" -> 1"weekly:clicks" -> 10"weekly:hits" -> 10

"daily:clicks" -> 5"daily:hits" -> 1"weekly:clicks" -> 0"weekly:hits" -> -5

"daily:clicks" -> 6"daily:hits" -> 2"weekly:clicks" -> 10"weekly:hits" -> 5

Coprocessors (p175～)

• サーバからクライアントへネットワークを流れるデータ量を減らす。

• 一部の計算をデータが存在するサーバ側に移すことで結果の量が減る。

• 任意のコードを各リージョンサーバ内で実行できる

– リージョン単位

• RDBMSにおける トリガーやストアドプロシージャのようなもの

Coprocessors (p175～)• Filterとは対照的に、Coprocessors は動的にロードできる？

– 稼働中のクラスタに対して機能を拡張できる

• ユースケース

– Row の変更をフックして、セカンダリインデックスを維持する。

–参照整合性を実装する。

• 集約関数(sum, avg)

– Scan処理をデータが存在するサーバ側に移す

–結果の数字のみをクライアントに返す。

Coprocessors (p175～p176)

• アクセスコントロール

–権限チェックは version 0.92 から coprocessors を使用して、HBaseに実装された。

• ２つの主なクラス

– Observer

– Endpoint

• Coprocessorインタフェースを基底として各処理を実装する。

• Servlet API の request filters のようにchainできる。

Observer (p176)

• RDBMのトリガーと同等

–あるイベント発生時にcallback関数が実行される

• フレームワークで提供されているinterface

– RegionObserver

• テーブル内のリージョンと紐付く

– MasterObserver

• DDL操作。クラスタ全体に影響。

– WALObserver

• write-ahead ログ処理でフックする。

Endpoint (p176)

• dynamic extensions to the RPC protocol

– 呼び出し可能なリモート·プロシージャを追加

• RDBMのストアドプロシージャと同等

• Observerの実装と組み合わせて、直接、サーバー側の状態と対話する

The Coprocessor Class (p176 ～)

• 全てのcoprocessorはこのinterfaceを基底とする。

• 2つのenum

– Priority

– State

Table 4-8 Coprocessor.Priority (p177)

– SYSTEM

• 最も優先される。最初に実行される。

– USER

• SYSTEMの後に実行される。

• 各Priorityに、シーケンス番号

– 0から始まる

–ロードされて実行される順番

CoprocessorEnvironment (p177)• life cycle

– Coprocessorの開始時、廃止時に以下のメソッドが呼ばれる。

–引数のCoprocessorEnvironmentインスタンスは、Coprocessor インスタンスの存続期間にわたって状態を保持するために使用される。

• Table 4-9 (p177)

CoprocessorEnvironmentクラスのメソッド

void start(CoprocessorEnvironment env) throws IOException;void stop(CoprocessorEnvironment env) throws IOException;

#getTable (p178)

• Coprocessorから、テーブルのデータにアクセスするには、 #getTable (Table 4-9 (p177))を使用すること

–戻り値のHtableは、デフォルトのHtableをsafetyにしたもの

• 例：Rowのロックができない仕様

– Coprocessorのコードの中で、デフォルトのHtable

を作成するのは可能。しかし、将来的に禁止になる可能性がある。

Table 4-10 Coprocessor.State (p178)– UNINSTALLED

• Coprocessorは初期化状態。

– INSTALLED• Environmentにインストールされた。

– STARTING• 起動中。#start() が呼ばれようとしている。

– ACTIVE• #start () が終わった。

– STOPPING• # stop ()が呼び出される直前。

– STOPPED• # stop ()が終わった。

• #start(), #stop() は暗黙的にフレームワークから呼ばれる

CoprocessorHost class(p178)

• 全てのcoprocessorインスタンスとenvironmentを維持。

• サーバの環境に合わせてサブクラスが存在

(Table4-11 (p180下))

– MasterCoprocessorHost

– RegionCoprocessorHost

– WALCoprocessorHost

Figure 4-3. Coprocessors executed sequentially, in their environment, and per region (p179)

Coprocessor Loading (p179)• Staticロード

– Configurationファイル

–テーブルスキーマ

• Dynamicロード

–まだAPIが公開されていない？

Loading from the configuration (p180)• hbase-site.xml

• 上の設定で定義した順番で実行される。• CoprocessorHostによってロードされる (Table4-11 (p180))

– 例： hbase.coprocessor.master.classes で定義されたクラス→ MasterCoprocessorHost

<property><name>hbase.coprocessor.region.classes</name><value>coprocessor.RegionObserverExample,

coprocessor.AnotherCoprocessor</value></property><property>

<name>hbase.coprocessor.master.classes</name><value>coprocessor.MasterObserverExample</value>

</property><property>

<name>hbase.coprocessor.wal.classes</name><value>coprocessor.WALObserverExample, bar.foo.MyWALObserver</value>

</property>

hbase.coprocessor.region.classesで定義したcoprocessorクラス (p181)

• テーブルの各リージョンがopenした際にロードされる。

• 特定のテーブル、または、リージョンを指定できない。

–全てのテーブル、全てのリージョンにロードされる

Loading from the table descriptor (p181～p182)

• テーブル毎に定義可能なので、そのテーブルがあるリージョンに対してロードされる。

• 定義できるのは、リージョン用coprocessorのみ。Master用、WAL用は定義できない。

• テーブルがenableになって、リージョンがopenすると、– まずConfigurationファイルで定義したcoprocessorがロードされ、

– 次にtable descriptor定義したcoprocessorがロードされる。

• table descriptorで定義を追加するには

– HTableDescriptor#setValue(String key, String value)を使用• Keyの命名規則＝” COPROCESSOR” から始まる

• Valueのformat＝<path-to-jar>|<classname>|<priority>

Example 4-19(p181)Path path = new Path(fs.getUri() + Path.SEPARATOR + “test.jar”); // ①HTableDescriptor htd = new HTableDescriptor(“testtable”); // ②htd.addFamily(new HColumnDescriptor("colfam1"));htd.setValue("COPROCESSOR$1", path.toString() +

“|” + RegionObserverExample.class.getCanonicalName() + // ③"|" + Coprocessor.Priority.USER);

HBaseAdmin admin = new HBaseAdmin(conf); // ④admin.createTable(htd);// --------------------------------------------------------------------------------------------------------------① JAR fileの場所を設定② HTableDescriptorを生成(テーブル名= “testtable”)③ coprocessorの定義

Keyの命名規則＝” COPROCESSOR” から始まるValueのformat＝<path-to-jar>|<classname>|<priority>

④HBaseAdminを生成。次の行でテーブル作成。// --------------------------------------------------------------------------------------------------------------{NAME => 'testtable', COPROCESSOR$1 => ¥'file:/test.jar|coprocessor.RegionObserverExample|USER', FAMILIES => ¥[{NAME => 'colfam1', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', ¥COMPRESSION => 'NONE', VERSIONS => '3', TTL => '2147483647', BLOCKSIZE ¥=> '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true'}]}

The RegionObserver Class (p182)

• リージョンレベルの Observer Coprocessor。

– リージョンレベルのtriggerをフックする

• ２つのグループに分かれる

– region life-cycle changes

– client API calls

Handling region life-cycle events(p183)

• Figure 4-4(p183)

– “The Region Life Cycle”(p348)を簡略化した図

• 次の３つのstateの変更に関連する

– pending open

– Open

– pending close

State (p183～p184)

• pending open

– void preOpen(...) / void postOpen(...)

– void preWALRestore(...) / void postWALRestore(...)

• Open

– void preFlush(...) / void postFlush(...)

– void preCompact(...) / void postCompact(...)

– void preSplit(...) / void postSplit(...)

• pending close

– void preClose(..., boolean abortRequested) /

– void postClose(..., boolean abortRequested)

Handling client API events(p184～p185)

• life-cycle events とは対照的に、明示的にクライアントからリージョンサーバへ送信される。

• APIコールの前後にフックできる。– void preGet(...) / void postGet(...)

– void prePut(...) / void postPut(...)

– void preDelete(...) / void postDelete(...)

– (※中略)

– long preIncrementColumnValue(...) / long postIncrementColumnValue(...)

– void preIncrement(...) / void postIncrement(...)

– InternalScanner preScannerOpen(...) / InternalScanner postScannerOpen(...)

– boolean preScannerNext(...) / boolean postScannerNext(...)

– boolean preScannerNext(...) / boolean postScannerNext(...)

The RegionCoprocessorEnvironmentclass(p185)

• Table 4-12 (p185) RegionCoprocessorEnvironment

のメソッド

• Table 4-13 (p186) RegionServerServicesのメソッド

書きかけ。。ごめんなさい。。