View
SETUP
Non-transactional mutable 인덱스는 region server 와 master server에 특별한 설정을 함으로써 phoenix가 해당 테이블에 대해 mutable 인덱싱을 수행하는 것을 보장한다.
만약 올바르게 설정이 되어 있지 않다면 세컨더리 인덱싱을 사용할 수 없다. 아래의 값들을 hbase-site.xml 에 추가하고 난뒤 클러스터를 rolling restart 수행해야 한다.
각 region 서버에 다음 설정을 추가해야 한다.
<property> |
위의 properties는 커스텀 WAL edits을 쓰게 설정하고 인덱스 업데이트가 적절히 쓰여지고 다시 수행될 수 있도록 한다. 이 코덱은 일반적으로 WAL edit 옵션의 호스트를 지원하는데, 가장 대표적인 기능은 WAL edit 압축이다.
<property> <property> |
위의 properties들은 인덱스가 업데이트 되면서 global index를 위한 인덱스 유지관리 중 dead-lock이 발생하는 것을 막아주는데, date update보다 높은 우선순위를 가지고 처리된다. 이 설정은 또한 metadata rpc call 이 data rpc call 보다 높은 우선순위로 처리되는 것을 보장함으로써, dead-lock을 막아준다.
피닉스 4.8.0 부터 로컬 인덱싱을 위한 설정 변경이 필요하지 않게 되었다. 피닉스 4.7에서는 아래와 같이 server-side의 hbase-site.xml 의 master node와 region server node에 다음 설정을 추가해야 한다.
<property> <property> <property> |
4.8.0 버전 이전의 로컬 인덱스 업데이트
phoenix 4.8.0 이상의 버전으로 업그레이드 하는 동안에 서버는 위의 세가지 local indexing 관련 설정이 존재한다면 hbase-site.xml 에서 제거한다.
client로터 local index에 대한 온라인과 오프라인 업그레이드를 모두 지원한다. 업그레이드의 절차로 우리는 local index를 비동기적으로 다시 생성한다.
업그레이드 후에 'IndexTool' 을 사용하여 인덱스를 빌드할 필요가 있다. 다음은 업그레이드에 사용되는 client-side 의 설정값이다.
phoenix.client.localIndexUpgrade |
true : 온라인 업그레이드 수행 |
오프라인 업그레이들를 수행하는 경우 psql 툴을 사용한다.
$ psql [zookeeper] -l |
Tuning
Indexing 작업은 매우 빠르다. 하지만 특정 환경과 부하에서 최적화 작업을 수행하기 위해서 몇가지 조정해야 하는 properties들이 존재한다.
다음의 모든 parameter들은 hbase-site.xml 에 설정되어야 한다. 이것들은 전체 클러스터와 모든 인덱스 테이블에 true로 설정되어야 하며 같은 서버에 존재하는 region server들도 마찬가지다.
이렇게 설정을 하면 하나의 서버에 너무 많은 인덱스들 테이블을 쓰지 않는다.
1) index.builder.threads.max (default : 10 )
: Primary table 업데이트부터 Index update 빌드까지 사용될 쓰레드 개수. 이 값을 늘리는 것은 Hregion의 각 row 상태를 읽어들이는 것에 대한 병목현상을 해결할 수 있다.
하지만 이 값을 너무 높게 설정한다면 너무 많은 스캔 요청이 동시에 발생되어 HRegion에서 처리하지 못하므로, 일반적으로 thread-swap 현상이 발생한다.
2) index.builder.threads.keepalivetime (default : 60 )
: 빌더 쓰레드 풀에 존재하는 쓰레드가 만료되어 종료되는 시간(s). 사용하지 않는 쓰레드는 즉시 해당 시간이 지나고 릴리즈되며, 작업이 수행되지 않는 스레드라고 하더라도 코어 스레드가 남아있다고 한다면 비록 write load가 지속되는 동안은 해당 쓰레드가 남아있게된다.
3) index.writer.threads.max (default : 10)
: 타겟 인덱스 테이블에 write 하는 스레드의 갯수. 테이블당 병렬처리되는 수준을 의미하며 대략적으로 인덱스 테이블의 갯수와 동일하게 설정한다.
4) index.writer.threads.keepalivetime (default : 60)
: writer 스레드 풀에 있는 스레드가 만기되는데 걸리는 시간(s).
사용하지 않는 쓰레드는 즉시 해당 시간이 지나고 릴리즈되며, 작업이 수행되지 않는 스레드라고 하더라도 코어 스레드가 남아있다고 한다면 비록 write load가 지속되는 동안은 해당 쓰레드가 남아있게된다.
5) hbase.htable.threads.max (default : 2,147,483,647)
: 각 인덱스의 HTable에 write 작업 수행할 때 사용할 수 있는 스레드 갯수.
이 값을 높이게 되면 동시성이 좀 더 좋아진다.
6) hbase.htable.threads.keepalivetime (default : 60)
: HTable 스레드 풀 안의 스레드가 만료된 후 지나야할 시간(s).
'direct handoff' 접근을 사용하여 새로운 스레드가 오직 필요할 때만 생성되고, 제한 없이 생성될 수 있다. 이것은 안좋을 수 있는데 HTable은 오직 region server의 수 만큼 Runnable(thread)를 생성할 수 있다. 결국 새로운 region server가 추가될 때 사이즈가 증가될 수 있다.
7) index.tablefactory.cache.size (default : 60)
: 인덱스 HTable 이 유지해야할 캐시의 수. 이 값을 증가시키게 되면 인덱스 테이블에 쓰기 작업을 수행하기 위해 생성해야 하는 HTable 수가 줄어들게 된다. 하지만 너무 높게 설정하게 되면 메모리 사용에 대한 압박을 느낄 수 있다.
8) org.apache.phoenix.regionserver.index.priority.min (default : 1000)
: 인덱스 우선순위 범위의 가장 낮은 값을 설정한다.
9) org.apache.phoenix.regionserver.index.priority.max (default : 1050)
: 이 값은 특정한 범위 안에서 제외해 하고 설정할 수 있다. 높은 우선순위를 인덱스에 설정할 수록
10) org.apache.phoenix.regionserver.index.handler.count (default : 30)
: 글로벌 인덱스에 쓰기작업을 요청하는데 사용할 스레드의 수. 실제 스레드의 수는 최대값으로 나타나는데 call 큐의 수가 스탠다드 hbase 설정에 결정된 것의 최대값.
큐를 튜닝하고 싶다면 스탠다드 rpc 큐 크기 파라미터를 조절하면된다. (현재 인덱스 큐를 조절하는 방법은 없다)
> ipc.server.max.callqueue.length
> ipc.server.callqueue.handler.factor
Performance
Secondary index의 성능은 phoenix performance framework를 통해 확인한다. 이것은 일반적인 성능 테스트로 H/W Spec과 설정에 따라 결과가 다양하게 나오게 된다.
일반적으로 secondary index를 사용하게 되면 20배 이상으로 성능이 빨라진다. 이것은 실제로 꽤 합리적인데 여러 테이블과 인덱스를 업데이트하는것에 비해서 합리적이다.
Index Scrutiny Tool
피닉스 4.12 부터, mapreduce작업을 통해 데이터 테이블과 비교하여 인덱스 테이블이 유효한지 확인하는 도구가 생겼다. 이것은 테이블에 쌍이 없는 rows 들을 찾고 다른 테이블에 상응하는 row가 있는지 찾는 방법이다.
이러한 이유로 이 도구는 데이터와 인덱스 테이블을 모두 소스 테이블로 생각하고 다른 하나를 타겟테이블로 수행된다. 이것은 모든 유효하지 안흔ㄴ rowㄴ들을 파일이나 output 테이블 PHOENIX_INDEX_SCRUTINY 에 쓴다
유효하지 않은 row들은 타겟테이블에서 상응하는 row 값이 없는 것 이거나 타겟 테이블에 잘못된 값을 가지고 있는 것이다 . ( covered column value)
이 툴은 상태값을 저장하기 위해서 잡 카운터를 가지고 있다. (VALID_ROW_COUNT, INVALID_ROW_COUNT, BAD_COVERED_COL_VAL_COUNT)
유효하지 않는 row 수 - 잘못된 칼럼 값의 row 수 = 쌍이 없는 rows 이다. 이러한 카운터 값은 다른 작업의 메타데이터와 함께 PHOENIX_INDEX_SCRUTINY_METADATA 테이블에 쓰여진다.
Index scrutiny tool은 hbase 커멘드를 통해 다음과 같이 수행된다.
hbase org.apache.phoenix.mapreduce.index.IndexScrutinyTool -dt my_table -it my_index -o |
이것은 또한 phoenix-core , phoenix-server jar 파일을 통해 아래와 같이 수행될 수도 있다.
HADOOP_CLASSPATH=$(hbase mapredcp) hadoop jar phoenix-<version>-server.jar org.apache.phoenix.mapreduce.index.IndexScrutinyTool -dt my_table -it my_index -o |
기본적으로 두개의 맵리듀스 작업이 실행되며, 하나는 데이터 테이블을 소스 테이블로 사용하는 것이고 하나는 인덱스 테이블을 소스 테이블로 사용하는 것이다.
다음은 Index Secrutiny Tool 이 사용할 수 있는 parameter 값이다.
| Parameter | Description |
|---|---|
| -dt,–data-table | Data table name (mandatory) |
| -it,–index-table | Index table name (mandatory) |
| -s,–schema | Phoenix schema name (optional) |
| -src,–source | DATA_TABLE_SOURCE, INDEX_TABLE_SOURCE, or BOTH. Defaults to BOTH |
| -o,–output | Whether to output invalid rows. Off by default |
| -of,–output-format | TABLE or FILE output format. Defaults to TABLE |
| -om,–output-max | Maximum number of invalid rows to output per mapper. Defaults to 1M |
| -op,–output-path | For FILE output format, the HDFS directory where files are written |
| -t,–time | Timestamp in millis at which to run the scrutiny. This is important so that incoming writes don’t throw off the scrutiny. Defaults to current time minus 60 seconds |
제한사항
만약 row 가 업데이트 되거나 삭제되고 있는 중에 scrutiny를 수행한다면, inconsistencies로 인해 잘못된 결과를 줄 수 있다. (phoenix-4277)
스냅샷을 읽는 것은 scrutiny tool로 지원되지 않는다. (phoenix-4270)
Resources
세컨더리 인덱스가 어떻게 수행되는지에 대한 참고자료들이 아래와 같다
| Title | Resources | Where | When |
|---|---|---|---|
| Drillix: Apache Phoenix + Apache Drill | Slides | Salesforce.com | 2016 |
| Apache Phoenix: Past, Present and Future of SQL over HBase | Slides, Video | HadoopSummit - Dublin | 2016 |
| High Performance Clickstream Analytics with Apache HBase/Phoenix | Slides | Strata + Hadoop World | 2016 |
| Apache Phoenix: The Evolution of a Relational Database Layer over HBase | Slides | Apache Big Data EU | 2015 |
| Lightning Talk for Apache Phoenix | Slides | HPTS | 2015 |
| Tuning Phoenix and HBase for OLTP | Slides | Tuning Presentation | 2015 |
| Apache Phoenix: The Evolution of a Relational Database Layer over HBase | Slides, Video | Hadoop Summit | 2015 |
| Apache Phoenix: The Evolution of a Relational Database Layer over HBase | Slides | HBaseCon | 2015 |
| Apache Phoenix: Transforming HBase into a Relational Database | Slides | OC Hadoop User Group | 2014 |
| Apache Phoenix: Transforming HBase into a SQL database | Slides, Video | Hadoop Summit | 2014 |
| Taming HBase with Apache Phoenix and SQL | Slides, Video | HBaseCon | 2014 |
| How Apache Phoenix enables interactive, low latency applications over HBase | Slides, Video | ApacheCon | 2014 |
| How (and why) Phoenix puts the SQL back into NoSQL | Slides, Video | Hadoop Summit | 2013 |
| How (and why) Phoenix puts the SQL back into NoSQL | Slides, Video | HBaseCon | 2013 |
'02.IT공부(간헐적취미) > 빅데이터' 카테고리의 다른 글
| [Hive] Hive LLAP 메모리 설정 가이드 (0) | 2018.08.21 |
|---|---|
| [HBase] WAL(Write Ahead Log)를 이용한 region 복구 (0) | 2018.07.11 |
| [Phoenix] Feature#2 - Secondary Indexing (1) (0) | 2018.05.27 |
| [Phoenix] Feature#1 - Transaction (0) | 2018.05.20 |
| [HBase] hbase shell command, HBase 명령어 (0) | 2018.01.10 |
