MySQL InnoDB Buffer Pool Resizing Online

 

·       Version : MySQL 5.7.5, 8.0

 

MySQL 5.7.5 부터 InnoDB 버퍼풀의 크기를 서비스 가동중에도 동적으로 조절할 있다. 동적으로 버퍼풀 확대 또는 축소를 제공하기 위해 청크 크기를 정의하는 새로운 변수인 innodb_buffer_pool_chunk_size 도입되었으며, 변수는 동적이 아니며 잘못 구성되면 원하지 않는 상황이 발생할 수도 있다.

아래 그림은 innodb_buffer_pool_size, innodb_buffer_pool_instances , innodb_buffer_pool_chunk_size 상호작용하는 방식을 나타낸것이다.

 

버퍼풀은 여러 인스턴스를 보유할 있으며 인스턴스는 청크로 분할된다. 인스턴스의 수는 1 ~ 64 까지 있으며 청크의 양은 1000개를 초과하지 않도록 해야한다. 따라서 3GB RAM 있는 서버에서, 8개의 인스턴스가 있는 2GB 버퍼 기본값(128M) 청크를 가지고 있는 경우 인스턴스당 2개의 청크를 얻게 된다. 뜻은 16개의 청크가 있음을 의미한다.

 

현재 설정되어있는 버퍼풀 크기를 확인하는 방법은 아래 스크립트를 사용한다.

mysql> show global variables like 'innodb_buffer_pool_size';

+-------------------------+------------+

| Variable_name           | Value      |

+-------------------------+------------+

| innodb_buffer_pool_size | 1073741824 |

+-------------------------+------------+

 

버퍼 크기를 조절하는 방법은 아래 스크립트를 실행한다.  이때 파라메터는 바이트 값이므로 설정시 주의 한다.

mysql> set global innodb_buffer_pool_size=1610612736;

 

 

 

[참고자료]

·       InnoDB Buffer Pool Resizing: Chunk Change : https://www.percona.com/blog/2018/06/19/chunk-change-innodb-buffer-pool-resizing/

 

 

 

 

2020-10-20 / Sungwook Kang / http://sungwookkang.com

 

MySQL, Buffer Pool, innodb_buffer_pool_size, innodb_buffer_pool_instances , innodb_buffer_pool_chunk_size, 버퍼풀 사이즈 조절

Hive 투기적 실행(Speculative execution)

 

·       Version : Hive

 

Hive에서 투기적 실행(Speculative execution)이라 불리는 기능은 하나의 잡을 중복된 태스크로 구성하여 동시에 수행 시키는 하둡의 기능이다. 같은 데이터를 중복하여 복사하기 때문에 많은 리소스를 사용하며, 대부분의 데이터는 버려진다. 기능의 목적은 느리게 동직하는 태스크 트래커를 제거함으로써 개별 태스크의 결과가 빨리 도출되고 결과적으로 전체 수행을 향상시키는데 있다.

, 동일한 태스크를 여러노드에서 실행함으로써, 특정 노드가 느리더라도 (장비 노후 또는 기타 문제로) 다른 노드에서 먼저 끝나면 해당 결과를 사용하고 나머지 노드는 중지 시킨다. 그래서 전체적으로는 수행시간이 단축된다.

Speculative execution 기능 활성화는 mapred-site.xml에서 아래 속성을 true 설정한다.

mapreduce.map.speculative

mapreduce.reduce.speculative

 

Speculative execution 기능은 실시간성이 중요한 잡의 경우 활성화 하여 사용하는 것이 전체적인 응답시간 향상에 이득이 있다. 하지만 입력 데이터 때문에 오래 걸리는 또는 리듀스 태스크에는 높은 오버헤드로 인해서 사용하지 않는것을 추천한다.

 

 

[참고자료]

·       https://community.cloudera.com/t5/Support-Questions/what-is-speculative-execution/td-p/241741

·       https://www.slideshare.net/Hadoop_Summit/t-325p210-cnoguchi

 

 

2020-10-19 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, Hive tunning, 하이브 튜닝, MapReduce최적화, Map태스크, Reduce 태스크, 하이브 최적화, 투기적 실행, mapreduce.map.speculative, mapreduce.reduce.speculative, Speculative Execution

Hive 자바 가상 머신 재사용

 

·       Version : Hive

 

하둡에서 맵리듀스 태스크를 실행하면 기본적으로 자바 가상 머신이 실행되고 위에서 또는 리듀서 태스크를 실행한다. 하둡의 기본 설정은 일반적으로 포크(forked) 자바 가상 머신을 사용한다. 자바 가상 머신은 가동할 오버헤드가 있기 때문에, 가상 머신의 재사용은 하이브 성능과 매우 밀접한 관계가 있다. 특히 작은 파일을 처리해야하는 경우나 태스크 수행시간이 짧은 작업의 경우 자바 가상 머신을 재사용하면 매우 효율이 좋다. 만약 수십, 수백번의 태스크를 가진 잡을 수행할때 자바 가상 머신 인스턴스를 재사용한다면 동일한 잡에 N 재사용된다. 가상 머신의 재사용 설정은 하둡의 mapred-site.xml에서 설정할 있다.

mapred.job.reuse.jvm.num.tasks= 10

자바 가상 머신 하나당 번의 태스크를 수행할지 설정 -1 설정할 경우 제한이 없음.

 

자바 가상 머신을 재사용할 경우, 잡을 실행할때마다  가상 머신이 새로 가동되는 오버헤드를 줄일 있지만, 예약된 태스크 슬롯을 잡이 완료할 때까지 점유하고 있는 단점이 있다. 예를들어 잡이  병렬로 실행될때, 먼저 끝난 가상 머신은 유휴 상태로 대기하게 되고 마지막 작업이 완료되기 전까지다른 잡이 사용하지 못하는 상태가 된다. 물론 다른 잡은 다른 자바 가상 머신을 생성해서 사용하지만, 이러한 불균형이 지속적으로 발생한다면 리소스 병목이 발생할 있다.  

 

 

 

2020-10-14 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, Hive tunning, 하이브 튜닝, MapReduce최적화, Map태스크, Reduce 태스크, 하이브 최적화, 자바 가상 머신, JVM

Hive Mapper, Reduce 개수 최적화

 

·       Version : Hive

 

하이브는 쿼리를 이상의 맵리듀스 잡으로 나누어 병렬로 처리한다. 맵리듀스는 다수의 맵퍼와 리듀서 태스크로 실행되는데 맵퍼와 리듀서의 수는 입력하는 데이터 크기, 데이터 수행 연산 종류 다양한 변수에 의존적이다. 너무 많은 맵퍼와 리듀서 태스크는 잡을 초기화 하고, 스케줄링하고 실행하기 위해 많은 오버헤드를 유발한다. 반대로 너무 적은 태스크는 클러스터가 가진 병렬처리의 장점을 활용하지 못하게 된다.

 

리듀스 단계가 있는 하이브 쿼리를 실행하면 리듀서 수를 출력한다. GROUP BY 항상 리듀서 단계가 필요하기 때문에 해당 구문이 포함한스크립트를 실행하면 사용된 맵퍼와 리듀서의 개수를 확인할 있다.

INFO  : Hadoop job information for Stage-1: number of mappers: 5; number of reducers: 1

INFO  : 2020-09-29 22:31:55,395 Stage-1 map = 0%,  reduce = 0%

INFO  : 2020-09-29 22:32:04,712 Stage-1 map = 20%,  reduce = 0%, Cumulative CPU 5.03 sec

INFO  : 2020-09-29 22:32:05,749 Stage-1 map = 60%,  reduce = 0%, Cumulative CPU 12.13 sec

INFO  : 2020-09-29 22:32:09,885 Stage-1 map = 100%,  reduce = 0%, Cumulative CPU 19.8 sec

INFO  : 2020-09-29 22:32:16,080 Stage-1 map = 100%,  reduce = 100%, Cumulative CPU 25.89 sec

INFO  : MapReduce Total cumulative CPU time: 25 seconds 890 msec

INFO  : Ended Job = job_1591911716086_1525

INFO  : MapReduce Jobs Launched:

INFO  : Stage-Stage-1: Map: 5  Reduce: 1   Cumulative CPU: 25.89 sec   HDFS Read: 610485 HDFS Write: 775295 HDFS EC Read: 0 SUCCESS

INFO  : Total MapReduce CPU Time Spent: 25 seconds 890 msec

INFO  : Completed executing command(queryId=hive_20200929223144_877a1f4b-329b-4418-831d-89bcdc466f30); Time taken: 33.485 seconds

INFO  : OK

 

하이브는 입력 크기에 따라 리듀서 개수를 정한다. fs -count 명령을 사용하여 하둡에서 사용하려는 파일을 지정하여 예상 리듀서의 개수를 확인할 있다.

hadoop fs -count /user/data/nclick/file.txt

 

결과

0            1           12469765 /user/data/nclick/file.txt

 

리듀서의 개수는 하이브 속성중  hive.exec.reducers.bytes.per.reducer 설정된 수자를 파일 크기와 나눈값으로 계산할 있다. 설정 값은 사용자마다 다를 있다. 아래 스크립트는 hive.exec.reducers.bytes.per.reducer 속성값을 수정하는 명령이다. 단위가 바이트임을 주의한다.

set hive.exec.reducers.bytes.per.reducer=75000000

 

쿼리의 단계에서 입력 데이터 크기보다 훨씬 많은 데이터를 만들어내는 경우가 있다. 단계에서 과도한 데이터를 만들어내면 입력 데이터로 추정한 기본 리듀서의 수는 부족할 있으며 비슷하게 함수가 입력 데이터의 많은 부분을 필터링 수도 있다. 그러면 기본값보다 적은 리듀서만 있어도 된다.리듀서의 태스크 수는 mapred.reduce.tasks 설정값으로 조절할 있다.

 

하둡 클러스터에는 태스크를 할당하는 고정된 크기의 슬롯이 있다. 개의큰 잡이 하둡의 모든 슬롯을 점유하면 다른 잡이 시작되지 못할 있다. hive.exec.reducers.max 설정 값을 조절하여 쿼리가 너무 많은 리듀서 자원을 사용하는 것을 예방할 있다.

 

하둡은 맵과 리듀스 태스크를 기동하고 스케줄링하는데 정도 오버헤드가 발생한다. 성능 테스트를 수행할때 이러한 요인을 염두해 두어야 하며 특히 잡의 크기가 작을수록 이러한 부분을 염두해서 테스트를 진행해야한다.

 

 

 

2020-09-29 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, Hive tunning, 하이브 튜닝, MapReduce최적화, Map태스크, Reduce 태스크, 하이브 최적화

HDFS Cluster Balancing(데이터 블록 분포의 불균형 해소)

 

·       Version : HDFS

 

HDFS 시스템은 여러대의 노드가 클러스터로 동작하기 때문에 시간이 지날수록 데이터 노드의 블록 분포에 대한 불균형이 발생할 있다. 불균형 상태의 클러스터는 맵리듀스의 로컬리티에 영향을 주기 때문에 자주 사용되는 데이터노드에 많은 부하를 주게 된다. 따라서 이러한 블록의 불균형 분포를 해결하기 위해 밸런서 작업으로 블록을 재분배 하여 전체적으로 블록을 고르게 유지할 있도록 다른 노드로 블록을 이동한다. 이때 데이터 유실을 방지하기 위해 데이터 블록 복제본의 배치전략은 유지된다. 밸런서를 실행하는 명령은 아래와 같다.

sudo -u hdfs hdfs balancer

 

 

노드의 균형은 노드들의 이용률(노드에서 사용중인 공간 비율과 저장공간의 비율), 클러스터의 이용률(클러스터에서 사용중인 공간과 저장공간의 비율) 비교하여 임계치 보다 적을때 까지 실행된다. 임계치는 기본 10% 이며 클러스터에는 오직 하나의 밸런서만이 실행될 있다. 임계치 변경은 아래 명령으로 변경할 있다.

sudo -u hdfs hdfs balancer -threshold 5

 

밸런서 작업중 노드 이동에 대한 기본 대역폭은 1MB/s 이지만 hdfs-site.xml에서 dfs.balance.bandwidthPerSec 속성에서 대역폭을 설정 있으며 단위는 byte이다. 아래 명령으로도 설정이 가능하다.

dfsadmin -setBalancerBandwidth  newbandwidth

 

 

 

[참고자료]

·       How-to: Use the New HDFS Intra-DataNode Disk Balancer in Apache Hadoop : https://blog.cloudera.com/how-to-use-the-new-hdfs-intra-datanode-disk-balancer-in-apache-hadoop/

·       HDFS Balancers : https://docs.cloudera.com/documentation/enterprise/5-12-x/topics/admin_hdfs_balancer.html

 

 

 

 

2020-09-25 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, 데이터 블록 불균형, 노드 밸런서, 하둡 밸런서, Hadoop Balancer, Cluster Balancing, 하둡 튜닝, 하둡 관리, HDFS 관리

Hive LIMIT 튜닝 (데이터 샘플링으로 빠르게 응답하기)

 

·       Version : Hive

 

하이브에서 현재 저장되어 있는 데이터의 일부분을 확인하려고 LIMIT 절을 자주 사용한다. RDB 경우 데이터를 ROW단위로 읽기때문에(정확히는 페이지 단위) ROW단위로 처리하면서LIMIT 결과를 (Sort, Group 연산을 하지 않았을 경우) 빠르게 응답할 있다.  하지만 하이브의 경우 데이터 전체에 대해 쿼리를 수행하고 일부 결과만을 반환하기 때문에 불필요한 리소스 낭비가 크다. 그래서 최대한 LIMIT 명령을 피하는 것이 좋다.

만약 limit 자주 사용할 경우 hive-site.xml 파일에서 hive.limit.optimize.enable설정을 통해서  LIMIT 사용할 경우 원본 데이터를 샘플링 있다.

<property>

       <name>hive.limit.optimize.enable</name>

       <value>false</value>

       <description>Whether to enable to optimization to trying a smaller subset of data for simple LIMIT first.</description>

</property>

 

hive.limit.optimize.enable 옵션을 True 설정하면 hive.limit.row.max.size hive.limit.optimize.limit.file 제어할 있다.

<property>

       <name>hive.limit.row.max.size</name>

       <value>100000</value>

       <description>When trying a smaller subset of data for simple LIMIT, how much size we need to guarantee each row to have at least.</description>

</property>

 

<property>

       <name>hive.limit.optimize.limit.file</name>

       <value>10</value>

       <description>When trying a smaller subset of data for simple LIMIT, maximum number of files we can sample.</description>

</property>

 

하지만 기능은 JOIN이나 GRPUP BY 같이 리듀스 과정이 필요한 모든 쿼리에서는 결과 값이 달라지기 때문에 주의해야 한다.

 

 

 

2020-09-22 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, Hive tunning, 하이브 튜닝, limit tunning, Limit Optimize, limit sampling

HDFS 데이터노드 블록 스캐너 (손상된 블록을 검색하여 수정)

 

·       Version : HDFS

 

HDFS 에서 데이터를 쓰거나 읽을때 체크섬을 사용하여 데이터 손상을 확인하고 수정한다. 이러한 작업으로 데이터 손상을 감지 있지만 해당 작업은 데이터를 쓰거나 읽을때만 발생하므로 클라이언트가 데이터를 요청하기 전에는 손상된 부분을 찾는것이 쉽지 않다. 이러한 손상된 부분을 찾기 위해 모든 데이터노드는 블록스캐너를 실행하여 데이터노드에 저장된 모든 블록을 주기적으로 점검한다. 작업으로 문제 있는 블록은 클라이언트가 읽기 전에 삭제하거나 수정한다.

데이터 블록 스캐너는 점검할 블록 리스트를 관리하며 체크섬 오류를 찾기 위해 모든 블록들을 점검한다. 스캐너는 데이터노드의 디스크 대역폭을 보존하기 위한 조절 메커니즘을 사용한다. 데이터 블록 스캔 주기는 hdfs-site.xml 파일에 dfs.datanode.scan.period.hours 속성 값으로 제어할 있며 단위는 시간(hour)이다. 속성값을 0 으로 설정시 데이터 블록 스캔 작업을 비활성화 한다.

블록 스캐너가 실행될때마다 보고서가 생성되며 데이터 노드의 인터페이스 URL에서 보고서를 확인할 있다.

http://datanode:50075/blockScannerReport

 

 

 

2020-09-22 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, 체크섬 오류, 하둡 데이터 복구, 데이트 블록 스캔, Data block scan, Corrupted blocks, Block Scanner report

Hive EXPLAIN (실행계획) 사용

 

·       Version : Hive

 

하이브에서 EXPLAIN 명령을 사용하면 실행계획을 확인할 있다. , 쿼리를 어떻게 맵리듀스 잡으로 변환하지를 살펴 있다. 실행계획을 사용하는 방법은 아래 스크립트 처럼 쿼리문 앞에 EXPLAIN 명령을 함께 실행한다.

EXPLAIN

SELECT

       col_1, date_local, count(*) as cnt

FROM tbl_a

where col_1 = 'aaa.com'

group by date_local, col_1;

 

아래 실행 계획은 쿼리를 실행하였을때 반환된 결과이다.

1      STAGE DEPENDENCIES:

2        Stage-1 is a root stage

3        Stage-0 depends on stages: Stage-1

4     

5      STAGE PLANS:

6        Stage: Stage-1

7          Map Reduce

8            Map Operator Tree:

9                TableScan

10                 alias: tbl_a

11                 filterExpr: (col_1 = 'aaa.com') (type: boolean)

12                 Statistics: Num rows: 5275084 Data size: 1039193932 Basic stats: COMPLETE Column stats: PARTIAL

13                 Filter Operator

14                   predicate: (col_1 = 'aaa.com') (type: boolean)

15                   Statistics: Num rows: 2637542 Data size: 485307728 Basic stats: COMPLETE Column stats: PARTIAL

16                   Select Operator

17                     expressions: date_local (type: string)

18                     outputColumnNames: date_local

19                     Statistics: Num rows: 2637542 Data size: 485307728 Basic stats: COMPLETE Column stats: PARTIAL

20                     Group By Operator

21                       aggregations: count()

22                       keys: date_local (type: string), 'aaa.com' (type: string)

23                       mode: hash

24                       outputColumnNames: _col0, _col1, _col2

25                       Statistics: Num rows: 1010 Data size: 291890 Basic stats: COMPLETE Column stats: PARTIAL

26                       Reduce Output Operator

27                         key expressions: _col0 (type: string), 'aaa.com' (type: string)

28                         sort order: ++

29                         Map-reduce partition columns: _col0 (type: string), 'aaa.com' (type: string)

30                         Statistics: Num rows: 1010 Data size: 291890 Basic stats: COMPLETE Column stats: PARTIAL

31                         value expressions: _col2 (type: bigint)

32           Reduce Operator Tree:

33             Group By Operator

34              aggregations: count(VALUE._col0)

35               keys: KEY._col0 (type: string), 'aaa.com' (type: string)

36               mode: mergepartial

37               outputColumnNames: _col0, _col1, _col2

38               Statistics: Num rows: 202 Data size: 58378 Basic stats: COMPLETE Column stats: PARTIAL

39               Select Operator

40                 expressions: 'aaa.com' (type: string), _col0 (type: string), _col2 (type: bigint)

41                 outputColumnNames: _col0, _col1, _col2

42                 Statistics: Num rows: 202 Data size: 58378 Basic stats: COMPLETE Column stats: PARTIAL

43                 File Output Operator

44                   compressed: false

45                   Statistics: Num rows: 202 Data size: 58378 Basic stats: COMPLETE Column stats: PARTIAL

46                   table:

47                       input format: org.apache.hadoop.mapred.SequenceFileInputFormat

48                       output format: org.apache.hadoop.hive.ql.io.HiveSequenceFileOutputFormat

49                       serde: org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe

50    

51       Stage: Stage-0

52         Fetch Operator

53           limit: -1

54           Processor Tree:

55             ListSink

56    

 

·       1 ~ 2 : 하이브 잡은 하나 이상의 스테이지(stage) 구성된다. 스테이지 사이에는 의존관계가 있으며 복잡한 쿼리는 많은 스테이지로 구성되며 많은 시간이 소요된다. 스테이지는 맵리듀스 스테이지, 샘플링(sampling) 스테이지, 병합 스테이지, limit 스테이지 하이브가 필요한 일을 하는 스테이지로 구성된다. 하이브는 스테이지를 하나씩 실행한다.

·       5 : STAGE PLANS 절은 매우 길고 복잡하다.

·       6 : 잡을 위한 처리 묶음이고 맵리듀스를 통해 실행된다.

·       7 : Map Operator Tree: 이후의 모든 부분은 잡의 부분에서 실행한다.

·       9 : TableScan 태스크는 테이블을 입력으로 받아 결과 컬럼을 만든다.

·       13 : Filter Operator에서 조회 조건을 필터 한다

·       16 : Select Operator에서 출력할 대상을 선정한다.

·       20 : Group By Operator에서 쿼리에서 요청한 카운트 작업을 한다.

·       32 : Reduce Operator Tree : 이후의 부분은 모두 리듀스 부분에서 실행한다.

·       33 : Reduce에서도 Group By Operator 확인하 있는데, 맵에서 전달받은 값을 count 한다.

·       43, 48 : 마지막으로 파일을 출력하며, 해당 문자열 출력 포맷을 사용한다.

·       51 : 쿼리에서 limit 절이 없기 때문에 Stage-0 no-op 스테이지 이다.

 

2020-09-21 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, Hive, 쿼리 실행계획, Hive 쿼리, Hive Query execution plan

Hive 인덱스(index)

 

·       Version : Hive

 

하이브 인덱스는 연산 속도를 향상시키기 위해 컬럼에 인덱스를 생성할 있으나, RDBMS 인덱스랑 다르게 기능이 많이 제한적이다. 하이브는 인덱스 데이터를 원본 테이블이 아닌 별도 테이블에 저장한다. 그래서 인덱스 생성시 별도의 디스크 공간이 필요하고 생성에 따른 비용이 발생한다. 그래서 인덱스를 생성할때 사용 유무 효율을 고려해서 생성해야 한다.

하지만 하이브에서 인덱스는 논리적 파티션의 크기가 작고 개수가 많은 경우 파티셔닝을 대신해서 사용할 있으며, 맵리듀스의 잡의 입력으로 사용할 테이블 블록을 푸루닝(pruning)하는데 도움을 있다. 위에서 언급했듯이 모든 쿼리가 인덱스로 효율적인 것은 아니므로 실행계획을 분석하여 쿼리가 어떤 인덱스를 사용하는지 확인이 필요하다.

 

아래 스크립트는 인덱스를 생성하는 예제이다. AS 절은 인덱스를 구현한 자바 클래스를 인덱스 핸들러로 지정한다.

CREATE INDEX ix_tbl_a

ON TABLE tbl_a (col_1)

AS 'org.apache.hadoop.hive.ql.index.compact.CompactIndexHandler'

WITH DEFERRED REBUILD;

 

인덱스 핸들러는 인덱스 데이터를 무조건 테이블에 저장하지 않는다. 테이블에 저장하려면 IN TABLE 절을 함께 명시한다.

CREATE INDEX ix_tbl_a

ON TABLE tbl_a (col_1)

AS 'org.apache.hadoop.hive.ql.index.compact.CompactIndexHandler'

WITH DEFERRED REBUILD

IN TABLE tbl_a_index_table

PARTITION BY (par = 'XX');

 

WITH DEFERRED REBUILD 인덱스가 비어있는 상태에서 시작한다. ALTER INDEX 구문을 사용하여 언제든지 리빌드가 가능하다. 만약 파티션을 생략하면 모든 파티션에 대해서 인덱스 리빌드가 발생한다.

ALTER INDEX ix_tbl_a

ON TABLE tbl_a

PARTITION (par = 'XX')

REBUILD;

 

인덱스 삭제는 아래 명령을 사용한다.

DROP INDEX IF EXISTS ix_tbl_a ON TABLE tbl_a;

 

아래 명령은 테이블에 생성된 모든 인덱스 정보를 나타낸다.

SHOW FORMATTED INDEX ON tbl_a;

 

 

 

 

2020-08-27 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, HIVE Index, Hive 인덱스, 하이브 인덱스, 하이브 튜닝

Hive View

 

·       Version : Hive

 

하이브에서 (View) 일반 RDBMS 뷰와 동일하게 데이터를 저장하지 않는 논리적 테이블 구조이다. 뷰는 테이블과 같은 데이터베이스에 저장되기 때문에 이름은 데이터베이스 내에서 유니크해야한다.  아래 스크립트는 하이브에서 뷰를 생성하는 예제이다.

create view vw_a

as

select

       col_1, col_2, col_3

from tbl_a

where col_1 = 'a';

 

뷰를 생성할때 새로운 컬럼 이름 전체나 일부분에 COMMENT 추가할 수도 있다. 뷰는 원본 테이블로 부터 주석을 상속받지 않는다. 뷰는 INSERT LOAD 명령의 대상으로 사용할 없으며 읽기 전용이다.

 

하이브는 뷰를 먼저 수행한 후에 쿼리를 수행한다. 그러나 옵티마이저는 뷰와 쿼리절을 하나의 실제 쿼리로 결합하여 실행할 수도 있다. 하지만 하나의 쿼리로 실행되었다고 하더라도 뷰와 뷰를 사용하는 쿼리 둘다 ORDER BY 절이나 LIMIT 절을 가지고 있으면 뷰의 개념이 적용되어 절을 먼저 수행한다.

 

 

 

2020-08-24 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, HIVE view, 하이브 , Hive , 하이브 테이블

Hive에서 샘플 데이터 추출

 

·       Version : Hive

 

하이브에서 데이터 테이블이 있을때, 일부 데이터 샘플을 추출하는 방법에 대해서 알아본다. 하이브는 테이블을 버킷으로 구성하여 샘플을 만드는 쿼리로 아래와 같은 방식으로 사용할 있으며, 예제 스크립트는 1에서 10까지 값을 가진 컬럼에서 난수를 발생시키는 rand() 함수를 사용하여 샘플 데이터를 추출한다.

select * from tbl TABLESAMPLE (BUCKET 3 OUT OF 10 ON rand());

 

 BUCKET절에서 분모는 데이터가 해시될 있는 버킷 개수를 표현하며, 분자는 선택되는 버킷 숫자이다.

 

아래 스크립트는 PERCENT 함수를 사용하여 테이블 블록의 백분율로 샘플 데이터를 추출한다.

select * from tbl TABLESAMPLE (0.1 PERCENTS);

 

 

 

2020-08-13 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, TABLESAMPLE, 샘플데이터, 랜덤데이터추출

Hive ORDER BY, SORT BY, DISTRIBUTE BY, CLUSTER BY

 

·       Version : Hive

 

하이브 또는 RDBMS에서 ORDER BY 쿼리 결과 집합에 대해서 전체 정렬을 수행한다. 하이브에서 ORDER BY 모든 데이터가 하나의 리듀서로 처리되기 때문에 데이터 셋이 클수록 시간이 오래 걸린다. ORDER BY 오랜 시간을 수행될 있기 때문에 하이브는 hive.mapred.node strict 설정되었을 경우 ORDER BY절에 대해서 LIMIT 요구한다. 기본값은 nonstrict 이다.

 

 

하이브에서 ORDER BY 대신 SORT BY 사용하면 리듀서에서 지역 정렬하여 출력한다. ORDERSORT 사용할 경우 어떠한 컬럼이라도 지정할 수도 있고 ASC(기본값), DESC 사용하여 정렬할 수도 있다.  SORT BY 사용하는 경우 하나 이상의 리듀서로 처리될 경우 리듀서의 파일이 정렬되어 있더라도 전체적으로는 다른 리듀서의 출력된 정렬 결과가 겹치기 때문에 전체 정렬순서는 보장되지 않는다.

 

DISTRIBUTE BY 맵의 출력을 리듀서로 어떻게 나누어 보내는지를 제어한다. 하이브는 쿼리를 맵리듀스 잡으로 변환할때 내부적으로 기능을 사용하기도 한다. 기본적으로 맵리듀스는 맵퍼가 출력하는 키에 대해서 해시값을 계산하고 해시값을 이용하여 - 쌍을 가용한 리듀서로 균등하게 분산하려고 노력한다. 이때 SORT BY 사용할때 하나의 리듀서 출력이 다른 리듀서의 출력과 정렬 결과가 겹칠수 있다. 하지만 리듀서 출력 내에서는 정렬되어 있다. 하둡이 같은 데이터 레코드는 같은 리듀서로 보내는 것을 보장하기 위해서 DISTRIBUTE BY 사용할 있다. 그리고 리듀서 별로 데이터를 정렬하기 위해 SORT BY 사용한다.

 

 

SORT BY 리듀서 안에서 데이터 정렬을 제어하는 반면 DISTRIBUTE BY 리듀서가 처리할 로우를 어떻게 받는지 제어한다는 점에서는 GROUP BY처럼 동작한다. 하이브는 SORT BY 전에 DISTRIBUTE BY 절을 사용할 것을 요구하므로 주의해야한다.

 

CLUSTER BY 같은 쿼리를 표현하는 간단한 방법이다.

 

 

2020-08-03 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, 하이브 정렬,  ORDER BY, SORT BY, DISTRIBUTE BY, CLUSTER BY

Hive Map-Side-Join,  Bucket-Map-Join, Sort-Merge-Join

 

·       Version : Hive

 

Hive에서 조인 명령을 실행할때, 크기가 작은 테이블은 메모리에 캐시하고 크기가 테이블은 맵퍼로 흘려 보낼 있다. 하이브는 메모리에 캐시한 작은 테이블로 부터 일치하는 모든 것을 찾아 있기 때문에 맵에서 모든 조인을 있다. 이렇게 하면 일반 조인 시나리오에서 필요한 리듀스 단계를 제거할 있다.

 

데이터가 작을 수록 사이드 조인은 일반 조인보다 효율이 좋다. 리듀스 단계를 제거할 뿐만 아니라 단계 역시 줄어들기 때문이다. 사이드 조인을 활성화 하기 위해서는 hive.auto.convert.join 속성을 true 설정해야한다. 기본값은 false 이다. 사이드 조인을 사용하기 위한 테이블 크기 임계치는 hive.mapjoin.smalltable.filesize 속성값을 설정한다. 단위는 바이트 이다.

hive> set hive.auto.convert.join=true;

hive> set hive.auto.convert.join.noconditionaltask=true;

hive> set hive.auto.convert.join.noconditionaltask.size=20971520

hive> set hive.auto.convert.join.use.nonstaged=true;

hive> set hive.mapjoin.smalltable.filesize = 30000000;

 

 

사이드 조인은 특정 조건에서는 테이블에서도 사용할 있다. 이러한 조건은 ON 절에서 사용할 키에 대해서 버킷팅이 되어 있어야 하고, 테이블의 버킷 수가 다른 테이블 버킷 수의 배수이어야 한다. 이러한 조건이 충족되면 하이브는 다른 테이블의 버킷을 매칭하기 위해 모든 테이블의 내용을 가져올 필요 없이 테이블 간의 버킷에 대해 사이드 조인을 있다.   옵션을 사용하기 위해서는 hive.optimize.bucketmapjoin 속성값을 ture 설정해야 한다.

hive> set hive.optimize.bucketmapjoin=true;

 

만약 버킷팅되어 있는 테이블이 같은 수의 버킷을 가지고 있고, 데이터는 조인/버킷 키로 정렬되어 있다면 하이브는 정렬-병합 조인(Sort Merge Join) 수행하여 빠르게 조인할 있다.

 

옵션을 사용하기 위해서는 아래 설정을 활성화 해야 한다.

hive> set hive.input.format=org.apache.hadoop.hive.ql.io.BucketizedHiveInputFormat;

hive> set hive.optimize.bucketmapjoin=true;

hive> set hive.optimize.bucketmapjoin.sortedmerge=true;

 

 

 

참고자료

·       Map Join in Hive | Map Side Join : https://data-flair.training/blogs/map-join-in-hive/

·       Bucket Map Join in Hive – Tips & Working : https://data-flair.training/blogs/bucket-map-join/

·       Sort Merge Bucket Join in Hive – SMB Join : https://data-flair.training/blogs/hive-sort-merge-bucket-join/

 

 

 

2020-07-28 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, JOIN, Hive Map Join, Hive Bucket Join, Hive Sort Merge Join, 조인 최적화, 하이브 튜닝

Hive Left Semi Join (세미 조인) Cartesian Product Join (카테시안 프로덕트 조인)

 

·       Version : Hive

 

Hive에서 Left Semi Join (왼쪽 세미 조인) 오른쪽 테이블에서 ON 조건을 만족하는 레코드를 찾을 경우 왼쪽 테이블의 레코드를 반환한다.

 

일반적인 RDBMS SQL 조건을 만족하기 위해 IN 또는 EXISTS 구문을 지원하지만, 하이브에서는 동작하지 않는다. 하이브는 기본적으로 Right Semi Join (오른쪽 세미 조인) 지원하지 않으며 SELECT WHERE절에서 오른쪽 테이블의 컬럼을 참조 없음에 주의해야 한다.  아래 스크립트는 하이브에서 사용할 있는 Left  Semi Join 예시이다.

select

       a.col_1, a.col_2

from tbl_a as a

       left semi join tbl_b as b on a.col_1 = b.col_1 and a.col_2 = b.col_2

 

하이브에서 세미 조인이 일반 내부 조인보다 효율적인 이유는 왼쪽 테이의 레코드에 대해서 오른쪽 테이블에서 일치하는 레코드를 찾으면 이상 일치하는 레코드를 찾지 않고 바로 데이터를 반환하고 멈추기 때문이다.

 

카테시안 프로덕트 조인(Cartesian Product Join) 조인의 왼쪽 테이블에 있는 튜플(tuple) 오른쪽에 있는 튜플이 모든 쌍을 맺는다. 다른 조인 유형과 달리 하이브에서는 카테시안 프로덕트를 병렬로 실행하지 않는다. 또한 맵리듀스에서 최적화되어 있지도 않다. 아래 스크립트는 하이브에서 전체 카테시안 프로덕트(Full Cartesian Product) 실행한다.

select

       a.*, b.*

from tbl_a as a

       join tbl_b as b

where a.col_1 = b.col_1

 

일반적인 RDBMS에서는 위와 같은 쿼리에 대해서 내부 조인에 최적화되어 있으나, 하이브에서 이런 종류의 쿼리는 WHERE 절을 적용하기 전에 전체 카테시안 프로덕트를 실행한다. 그래서 쿼리가 아주 오래 걸릴 있다. 사용자 부주의로 카테시안 프로덕트를 방지하기 위해 hive.mapred.mode 속성이 strict 되어 있으면 카테시안 프로덕트의 실행을 방지 있다.

 

 

2020-07-27 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, JOIN, HIVE LEFT SEMI JOIN, 하이브 최적화, 하이브 튜닝, Hive Tuning, Hive Query Hint, CartesianProductJoin, 카테시안조인

Hive JOIN 조인 최적화

 

·       Version : Hive

 

Hive RDBMS 같은 JOIN(조인) 구문을 제공하며 기능도 거의 유사하지만 동등조인(EQUI-JOIN) 제공한다.

 

내부조인(INNER JOIN) 경우 조인하는 모든 테이블에서 일치하는 레코드만 반환한다. ON 절은 테이블에서 조인할 레코드의 조건을명시한다.

select

       a.col_1, b.col_2

from tbl_a

       inner join tbl_b on a.col_1 = b.col_1

 

RDBMS 표준 SQL 경우 조인 키에 대해서 비동등 조인(NON-EQUI-JOIN) 허용하지만 하이브에서는 제공하지 않는다. 또한 하이브에서는 ON절에서 OR 조건의 사용을 허용하지 않는다. 만약 ON 절에 OR 사용하려고 한다면 아래 스크립트와 같이 UNION ALL으로 쿼리를 풀어서 사용할 있다.

select

       *

from test1 as t1

       join test2 as t2 on (t1.col1 = t2.col1 and t1.col1 = 1) or (t1.col1 = t2.col2 and t1.col1 = 2);

 

/* OR 대신 UNION ALL 사용 */

select

       *

from test1 as t1

       join test2 as t2 on (t1.col1 = t2.col1 and t1.col1 = 1)

 

union all

 

select

       *

from test1 as t1

       join test2 as t2  on (t1.col1 = t2.col2 and t1.col1 = 2);

 

 

대부분의 하이브는 조인할 각각의 쌍에 대해서 별도의 맵리듀스 잡을 사용한다. 또한 하이브는 왼쪽에서 오른쪽으로 쿼리를 처리하며 조인 순서 또한 왼쪽에서 오른쪽(from 순서)으로 처리한다. 3 이상의 테이블을 조인할 , 모든 ON 절에서 같은 조인키를 사용한다면 하나의 맵리듀스 잡을 사용한다.

 

하이브에서 조인을 처리할때, 마지막 테이블을 가장 크다고 가정한다. 다른 테이블을 버퍼링하려고 시도하고, 레코드에 대해서 조인을 수행하면서 마지막 테이블을 흘려보낸다. 그러므로 조인쿼리를 구성할때, 가장 테이블을 가장 마지막에 위치하도록 해야한다. 가장 테이블을 쿼리의 마지막에 위치하지 못하였더라도 힌트를 사용하면 마지막에 처리할 있다. 아래 스크립트는 힌트를 사용하여 from 테이블을 마지막에 처리할 있도록 한다.

SELECT

       /*+ STREAMTABLE(s) */ s.*, b.*

from tbl_s   

       inner join tbl_b ON s.col_1 = b.col_1

where s.col_1 = ?

 

 

데이터 조회시 검색 최적화를 위해 파티션 필터를 사용하는데 OUTER JOIN (외부조인) 경우 파티션 필터를 무시한다. 하지만 내부 조인의 ON절에 파티션 필터를 사용하면 동작한다. 따라서 모든 조인에서 파티션 필터를 사용하기 위해 중첩 SELECT 사용하여 해결할 있다.

select

       a.col_1, b.col_1

from (select * from tbl_a where partition_filter = ? and col_1 = ?) as a

       left outer join (select * from tbl_b where partition_filter = ? and col_1 = ?) as b on a.col_1 = b.col_1

 

중첩 SELECT 문은 데이터 조인 전에 파티션 필더를 적용하는데 필요한 푸시다운(push down) 수행한다. 하이브는 조인을 수행한 후에 WHERE 절을 평가한다. 따라서 WHERE 절은 NULL 되지 않는 컬럼값에 대해서만 필터를 적용할 있도록 해야한다.

 

 

2020-07-22 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, HiveSQL, JOIN, INNER JOIN, 하이브 최적화, 하이브 튜닝, Hive Tuning, Hive Query Hint

Hive LIKE RLIKE

 

·       Version : Hive

 

Hive에서 LIKE 구문은 RDBMS LIKE 구문과 동일한 동작으로, 어떤 서브 문자열(substring) 문자열의 시작이나 , 혹은 문자열 내에서 일치하는지 확인할 있다.

 

아래 스크립트는 LIKE 구문으로 검색한 것이며, OR 절을 사용하여 여러개의 LIKE 구문을 사용하였다.

DROP TABLE IF EXISTS TBL_A;

CREATE TABLE TBL_A(

COL_1 STRING

);

 

INSERT INTO TBL_A(COL_1) VALUES ('CHICAGO'), ('NEWYORK');

 

SELECT * FROM TBL_A WHERE COL_1 LIKE '%CA%' OR COL_1 LIKE '%YO%';

 

 

 

하이브는 LIKE 절을 자바 정규표현식으로 사용할 있는 RLIKE 절로 확장하여 LIKE 조합으로 검색하기 어려운 문자열을 표현할 있다. 아래 스크립트는 RLIKE 예제이다.

select * from tbl_a where col_1 RLIKE '.*(ca|Yo).*';

 

 

예제에서 마침표(.) 어떤 문자와 일치하고 (*) 왼쪽에 있는 것이 0번에서 여러 반복되는 것을 의미한다. 따라서 , 뒤에서 마침표가 반복된다. (x|y)  표현식은 x또는  y 문자열이 일치하는 것을 의미한다.

 

2020-07-21 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브쿼리, Hive SQL, LIKE, RLIKE

HDFS fsimage 에디트 로그

 

·       Version : HDFS

 

HDFS 에서 클라이언트가 파일을 생성하거나 이동할때 에디트 로그에 먼저 기록한다. 네임노드는 파일시스템 메타데이터를 메모리로 로드하여 -메모리 자료구조로 관리하며 에디트 로그가 수정된 업데이트를 진행한다. -메모리 메타데이터는 읽기 요청을 수행하는데 사용되며 디렉터리에 쓰기 동작이 끝나고 나서 성공했다는 결과가 클라이언트로 반환 되기전에 에디트 로그를 플러시하여 동기화한다. 이렇게 함으로서 장애가 발생해도 데이터 유실을 방지할 있다.

 

fsimage 파일시스템 데이터의 영속적인 체크포인트 파일이다. 하지만 개별 쓰기 동작 때마다 갱신되지는 않는다. fsimage 파일 시스템에서 존재하는 모든 디렉터리와 파일 아이노드(inode) 정보를 바이트로 직렬화 한다. 아이노드는 파일의 복제 단위, 변경 접근시간, 접근권한, 블록 크기와 파일을 구성하는 블록 조합들 같은 정보를 가진다. 디렉터리는 변경 시간, 권한 할당, 크기 같은 메타데이터가 저장된다. fsimage 파일은 블록이 저장되는 데이터노드 정보를 기록하지는 않는다. 대신 네임노드는 메모리상에 블록과 데이터 노드 매핑정보를 유지한다. 네임노드는 데이터 노드가 클러스터에 참여할 블록 리스트를 요청하여 매핑정보를 구성하며 주기적으로 정보를 받아 매핑정보를 최신상태로 유지한다.

 

에디트 파일은 크기 제한없이 증가할 있다. 네임노드가 구동 중일 때에는 에디트 파일이 커지더라도 특별한 영향을 주지는 않지만 네임노드가 재시작될 경우, 많은 에디트 로그의 개별 동작들을 메모리에 반영하기 위해 상당한 시간이 소요된다. 시간 동안은 파일 시스템을 사용하지 못하는 상황이 발생한다. 이와 같은 문제를 방지하기 위해 보조 네임노드를 구성한다. 보조 네임노드는 네임노드의 -메모리 메타데이터에 체크포인트를 생성하는 것이다. 체크포인트는 아래와 같은 순서로 진행된다.

1.       보조 네임노드는 네임노드에 edits 파일을 순환 사용하도록 요청하고 네임 노드에서 새로운 edits 로그는 새로운 파일에 저장된다.

2.       보노 네임노드는 HTTP GET 이용해서 네임노드의 fsimage edits 가져온다.

3.       보조 네임노드는 fsimage 메모리에 로드하고 edits 동작을 반영한다. 그리고 나서 새롭게 통합된 fsimage 파일을 생성한다.

4.       보조 네임노드는 HTTP POST 이용하여 새로운 fsimage 파일을 네임노드에 전송한다.

5.       네임노드는 이전 fsimage 보조 네임노드로부터 받은 새로운 이미지로 교체하며, 이전 edits 파일을 1단계에서 시작한 새로운 edits 교체한다. fsimage 파일도 체크포인트가 발생한 시간을 기록하기 위해 변경된다.

 

아래 그림은 체크포인트 과정을 이해하기 쉽도록 그림으로 표현한 것이다.

 

 

2020-07-14 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, edit log, fsimage, 체크포인트, checkpoint, namenode, 네임노드

Hive 무조건 MapReduce 사용할까

 

·       Version : Hive

 

Hive에서 쿼리를 실행할때, 무조건 맵리듀스(MapReduce) 사용할까?  하이브에서 대부분의 쿼리를 실행할 경우 맵리듀스가 사용된다. 하지만 일부 쿼리의 경우 로컬 모드 환경에서 맵리듀스를 사용하지 않고도 쿼리가 동작 할수도 있다. 예를 들어 아래 스크립트 처럼 단순히 테이블을 조회하는 쿼리는 맵리듀스를 사용하지 않는다.

select * from tbl_a;

 

단순히 SELECT 같은 쿼리는 하이브가 테이블로 부터 레코드를 읽고 형식에 맞춰서 콘솔로 출력한다. 경우 맵리듀스 작업대신 파일에서 Fetch Task 전체 데이터를 가져온다. 마치 아래 하둡 명령과 유사하다.

hadoop fs -cat $ file_name

 

일반적으로 min / max / count 같은 모든 종류의 집계에는 맵리듀스 작업이 필요하다.  또한 컬럼을 사용하게 되면 하이브는 파일에서 구문을 분석하여 행에서 컬럼을 추출해야 하므로 맵리듀스 작업이 필요하다.

 

hive.exec.mode.local.auto 속성을 true 설정하면 다른 연산도 로컬 모드로 실행을 시도한다.

hive.exec.mode.local.auto = true;

 

 

 

 

2020-07-14 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 테이블, Hive table, 하이브쿼리, Hive SQL, 맵리듀스, MapReduce

Hive에서 SELECT 결과를 테이블로 INSERT 하기

 

·       Version : Hive

 

Hive에서 쿼리 결과를 테이블에 입력할때, 이미 존재하는 테이블에 데이터를 입력할수도 있으며, 새로운 테이블을 생성하며 데이터를 입력할 수도 있다. 이미 존재하는 테이블에 SELECT 결과를 저장할 때는 INSERT 구문을 사용한다. OVERWRITE 예약어를 사용하여 해당 파티션의 데이터를 교체할 있다. OVERWRITE 예약어를 INTO 변경하면 하이브는 데이터를 교체하지 않고 원래 데이터에 추가한다.

INSERT OVERWRITE TABLE tbl_new PARTITION (month = '1', day = '1')

select * from tbl_origin as origin

where origin.month = '1' and origin.day = '1';

 

만약 여러 파티션 데이터를 만들때, 파티션별로 INSERT 구문을 만들면 반복해서 데이터를 읽어야 하는 비효율적인 부분이 발생한다. 하이브는 입력 데이터를 한번 읽어서 이를 다수의 테이블로 분산하는 문법을 제공한다.

from tbl_origin as origin

INSERT OVERWRITE TABLE tbl_new PARTITION (month = '1', day = '1')

       select * where origin.month = '1' and origin.day = '1'

INSERT OVERWRITE TABLE tbl_new PARTITION (month = '2', day = '1')

       select * where origin.month = '2' and origin.day = '1'

INSERT OVERWRITE TABLE tbl_new PARTITION (month = '3', day = '1')

       select * where origin.month = '3' and origin.day = '1';

 

 

SELECT 결과물을 새로운 테이블을 생성하면서 저장하는 방법은 CREATE 구문을 사용할 있다.

CREATE TABLE tbl_create

AS SELECT col1, col2, col3

from tbl_origin

where month = '1' and day = '1';

 

 

 

2020-07-13 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 테이블, Hive table, 하이브쿼리, Hive SQL, 데이터 저장, INSERT SELECT

Hive 테이블 삭제, 수정

 

·       Version : Hive

 

하이브에서 테이블을 삭제하는 명령은 DROP TABLE 명령어를 사용한다.

DROP TABLE IF EXISTS table_name;

 

테이블을 삭제할때, 하둡의 휴지통기능이 활성화되어 있으면 데이터는 분산 파일 시스템의 .Trash 디렉터리로 이동된다. 휴지통 기능에 설정된 시간이후 데이터가 완전히 삭제 된다. 휴지통 기능이 비활성화 되어 있는 경우 즉시 삭제된다. 또한 삭제하려는 테이블이 외부 테이블인경우, 테이블의 메타데이터만 삭제되며 데이터는 그대로 남아있다.

 

테이블 수정은 ALTER TABLE 명령을 사용하여 변경한다. 테이블 수정은 메타데이터만 변경할 데이터 자체는 변경시키지 않는다.

[테이블명 변경]

Table_name 테이블명을 table_name_new 테이블명으로 변경한다.

ALTER TABLE table_name TO table_name_new

 

[파티션 추가/변경/삭제]

파티션 추가는 ADD PARTITION 명령을 사용한다.

ALTER TABLE table_name ADD IF NOT EXISTS

PARTITION(year = 2020, month = 1, day = 1) LOCATION '/user/data/20200101'

PARTITION(year = 2020, month = 1, day = 2) LOCATION '/user/data/20200102'

PARTITION(year = 2020, month = 1, day = 3) LOCATION '/user/data/20200103';

 

파티션 위치 변경은 SET LOCATION 명령을 사용한다.

ALTER TABLE table_name PARTIOTN(year = 2020, month = 1, day = 1)

SET LOCATION '/user/data/…';

 

파티션 삭제는 DROP PARTITION 명령을 사용한다.

ALTER TABEL table_name DROP IF EXISTS PARTITION (year = 2020, month = 1, day = 1);

 

 

[컬럼 변경]

컬럼명, 컬럼 위치, 주석 데이터 타입을 변경할 있다. old_column 컬럼명을 new_column 이름으로 변경하고 데이터 타입은 INT, 컬럼의 위치는 col2 뒤에 위치한다.

ALTER TABLE table_name

CHANGE COLUMN old_column new_column INT

COMMENT 'Input comment'

AFTER col2;

 

컬럼 이름이나 데이터 타입을 변경하지 않더라도, 컬럼의 예전이름과 새이름, 데이터 타입을 지정해야 한다.컬럼을 이동하지 않는다면 AFTER 명령은 필요하지 않으며, 컬럼을 앞으로 위치할 경우 FIRST 사용할 있다.

 

[컬럼 추가 / 삭제   교체]

컬럼 추가는 이미 존재하는 컬럼의 마지막과 파티셔닝 컬럼 앞에 추가된다.

ALTER TABLE table_name ADD COLUMNS (

add_col1 STRING COMMENT 'Input Comments',

add_cpl2 LONG COMMENT 'Input Comments');

 

이미 존재하는 모든 컬럼을 삭제하고 새로운 컬럼으로 교체한다. 메타 데이터만 변경된다.

ALTER TABLE table_name REPLACE COLUMNS(

col1 INT COMMENT 'Input Comments',

col2 STRING COMMENT 'Input Comments',

col3 LONG COMMENT 'Input Comments');

 

 

 

 

2020-07-07 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 테이블, Hive table, 하이브쿼리, Hive SQL, 하이브파티션, 테이블삭제, 테이블수정

+ Recent posts