Data Science Lab

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

·       Version : HDFS

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

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

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

[참고자료]

·       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 관리

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

·       Version : HDFS

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

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

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

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

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

Hive 인덱스(index)

·       Version : Hive

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

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

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

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

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

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

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

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

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

Hive View

·       Version : Hive

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

뷰를 생성할때 새로운 컬럼 이름 전체나 일부분에 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() 함수를 사용하여 샘플 데이터를 추출한다.

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

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

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를 사용하면 각 리듀서에서 지역 정렬하여 출력한다. ORDER와SORT를 사용할 경우 어떠한 컬럼이라도 지정할 수도 있고 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 속성값을 설정한다. 단위는 바이트 이다.

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

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

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

참고자료

·       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의 예시이다.

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

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

일반적인 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 절은 두 테이블에서 조인할 레코드의 조건을명시한다.

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

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

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

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

중첩 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 구문을 사용하였다.

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

위 예제에서 마침표(.)는 어떤 한 문자와 일치하고 별(*)은 왼쪽에 있는 것이 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와 같은 쿼리는 하이브가 테이블로 부터 레코드를 읽고 형식에 맞춰서 콘솔로 출력한다. 이 경우 맵리듀스 작업대신 파일에서 Fetch Task로 전체 데이터를 가져온다. 마치 아래 하둡 명령과 유사하다.

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

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 구문을 만들면 반복해서 데이터를 읽어야 하는 비효율적인 부분이 발생한다. 하이브는 입력 데이터를 한번 읽어서 이를 다수의 테이블로 분산하는 문법을 제공한다.

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

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

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

Hive 테이블 삭제, 수정

·       Version : Hive

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

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

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

[테이블명 변경]

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

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

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

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

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

[컬럼 변경]

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

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

[컬럼 추가 / 삭제  및 교체]

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

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

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

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

Hive 파티션 테이블에서 where  없는 쿼리 실행 방지

·       Version : Hive

하이브에서 테이블 파티셔닝을 하는 가장 큰 이유는 빠르게 데이터를 검색하기 위해서이다. 아주 큰 데이터가 있더라도 파티션 스키마가 검색하려는 범위 필터링을 반영한다면 파티셔닝 테이블은 쿼리의 성능을 극적으로 올려준다. 그래서 특정값을 필터하는 WHERE 절에 파티션 조건을 포함하는데 이러한 조건을 “파티션 필터”라고 부른다.

그러나 파티셔닝이 잘 되어 있다고 하더라도, 테이블 데이터가 많거나 파티션 개수가 많다면 거대한 맵리듀스 작업을 유발할 수 있다. 이러한 맵리듀스의 부하를 방지하기 위해 WHERE 절에  파티션 필터가 없는경우 쿼리 실행이 되지 않도록 옵션을 설정할 수 있다.

아래 스크립트는 WHERE절에 파티션 필터가 없는경우 쿼리가 실행되지 않도록 적용한 예시이다.

아래 스크립트는 WHERE 절에 파티션 필터가 없을 경우에도 쿼리가 실행된다.

현재 테이블에 생성되어 있는 파티션키 정보를 확인하려면 아래 명령을 실행한다.

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

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

Hive 매니지드 테이블 및 외부 테이블

·       Version : Hive

하이브에는 매니지드 테이블과 외부 테이블이라고 불리는 테이블 저장 방식이 있다. 이 둘의 차이점은 데이터 소유자가 하이브이냐, 아니냐로 크게 구분할 수 있다.

매지니드 테이블 (Managed Table)은 내부 테이블이라고도 불리며 하이브 속성(hive.metastore.warehouse.dir)에서 정의한 디렉터리의 하위 디렉터리를 만들어서 데이터를 저장한다. 하이브에서 매니지드 테이블을 삭제할때 테이블내의 데이터가 삭제된다.

외부 테이블은 테이블을 생성할때, EXTERNAL 키워드를 사용하며, LOCATION절에서 지정한 위치에 데이터가 존재한다는것을 하이브에게 알려준다. 하이브에서 외부 테이블을 삭제하면, 하이브 내에서 스키마만 삭제될 뿐 데이터는그대로 존재한다. 그래서 중요한 데이터의 경우 실수를 방지하기 위해 외부 테이블로 만드는것을 권장한다.

테이블의 속성이 매니지드 또는 외부인지 확인할 수 있는 방법은 DESCRIBE EXTENDED 명령을 사용한다.

아래 스크립트는 매니지드 테이블처럼 스키마만 복사하여 외부 테이블로 생성한다.

스키마를 복사하려는 원본 테이블이 외부 테이블인 경우 EXTERNAL 명령을 생략하여도 외부 테이블로 생성된다.

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

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

HDFS 저장소에 데이터를 압축해서 저장하면 더 좋을까?

·       Version : HDFS

HDFS 클러스터에서 데이터를 저장할때, 압축을 해서 보관하는것이 더 좋을까? 그냥 저장하는 것이 좋을까? 결론부터 말하면 반은 맞고 반은 틀리다. 즉, 압축의 특성을 잘 이해하고 사용하면 좋지만, 그렇지 못할경우 오히려 HDFS의 장점을 활용하지 못할 수도 있다.

맵리듀스가 처리할 데이터를 압축하는 방법을 고려할때, 압축 포맷이 분할을 지원하는지 여부를 이해하는것이 중요하다. 예를들어 HDFS에 1GB의 데이터 파일을 저장한다고 가정한다.  64MB 블록으로 처리할 경우 16개의 블록으로 나뉘어 HDFS에 저장된다. 맵 리듀스에서 이 파일을 입력 데이터로 사용할 경우 16개의 독립적으로 처리되는 입력 분할을 생성할 것이다.