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

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 인덱스(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, 하이브파티션, 테이블삭제, 테이블수정

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

 

·       Version : Hive

 

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

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

 

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

hive> set hive.mapred.mode = strict;

hive> select * from campaign;

FAILED: SemanticException [Error 10056]: Queries against partitioned tables without a partition filter are disabled for safety reasons. If you know what you are doing, please set hive.strict.checks.no.partition.filter to false and make sure that hive.mapred.mode is not set to 'strict' to proceed. Note that you may get errors or incorrect results if you make a mistake while using some of the unsafe features. No partition predicate for Alias "campaign" Table "campaign"

hive>

 

 

 

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

hive> set hive.mapred.mode = nonstrict;

hive> select * from campaign;

OK

Time taken: 0.671 seconds

hive>

 

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

hive> show partitions campaign;

OK

date_local=20200616

date_local=20200617

date_local=20200630

Time taken: 0.13 seconds, Fetched: 3 row(s)

hive>

 

 

 

 

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 명령을 사용한다.

DESCRIBE EXTENDED 테이블명;

  

 

 

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

create external table if not exists testdb.tbl_b

like testdb.tbl_a

location '/user/data/';

 

스키마를 복사하려는 원본 테이블이 외부 테이블인 경우 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개의 독립적으로 처리되는 입력 분할을 생성할 것이다.

 

 

 

그런데 압축 크기가 1GB 하나의 gzip 압축 파일이 있다고 가정한다. 기존처럼 HDFS 16개의 블록에 저장할 것이다. 그러나 블록에 대한 분할 생성은 gzip 스트림이 특정 위치에서 읽기를 지원하지 않기 때문에 동작을 하지 않을것이다.  , 맵태스크가 나머지 블록의 분할을 개별적으로 읽는것은 불가능하므로 gzip 포맷을 저장하기 위해 DEFLATE 사용하고, DEFLATE 데이터를 일련의 압축된 블록으로 저장한다. 리더가 다음 블록의 시작으로 이동하려면 스트림과 동기화되어 스트림의 특정 지점에 있을 있는 어떤 방법을 지원해야 하는데, DEPLATE 압축 방식은 블록의 시작점을 구분할 없기 때문에  gzip 분할을 지원하지 않는다. 그래서 맵리듀스는 gzip 분할을 지원하지 않는다는 것을 인식하고, 파일을 분할하려고 하지 않을것이다. 그러면 단일 지역으로 데이터가 편향되어 지역성 비용이 증가하게 된다. , 단일 맵이 16개의 HDFS 블록을 처리할 것이고, 블록은 대부분 맵의 로컬에 있지 않을 가능성이 크다. 소수의 맵과 함께 잡은 일반적인 잡보다 세분화 되지 않아 오랫동안 수행될 확률이 크다.

 

압축파일이 bzip2 어떨까? bzip2 파일은 블록 사이에서 동기화 표시가를 제공(파이의 48비트 근사치)하고 결과적으로 분할을 지원한다.

 

ZIP파일은 아카이브 포맷이기 때문에 다중 파일을 단일 ZIP 아카이브로 결합시킬 있다. 파일은 개별적으로 압축되고 아카이브에 있는 모든 파일 위치는 ZIP 파일의 끝에서 중앙 디렉터리에 저장된다. 이러한 속성은 ZIP 파일이 파일 단위로 분할을 지원한다는 것을 의미한다. 그리고 분할은 ZIP 아카이브로부터 하나 이상의 파일들을 포함한다. (zip 지원 여부는 확인이 필요하다.)

 

LZO 파일의 경우 기존의 압축 포맷의 리더가 스트림과 동기화되는 방법을 제공하지 않기 때문에 분할이 불가능하다.

 

아래표는 하둡에서 지원하는 압축 분할 여부이다.

Compression format

Tool

Algorithm

File extention

Splittable

gzip

gzip

DEFLATE

.gz

No

bzip2

bizp2

bzip2

.bz2

Yes

LZO

lzop

LZO

.lzo

Yes if indexed

Snappy

N/A

Snappy

.snappy

No

 

외에도 시퀀스 파일을 사용하거나,  청크 단위로 파일을 나누어서(이때 청크는 HDFS 블록 하나 정도 크기로 생성한다.) 개별적으로 압축을 하여 사용하면 압축 파일 분할 여부와 관계없이 어느정도 효율성을 발휘할 있다.  

 

 

[참고자료]

·       Choosing a Data Compression Format : https://docs.cloudera.com/documentation/enterprise/5-3-x/topics/admin_data_compression_performance.html

·       Data Compression in Hadoop : http://comphadoop.weebly.com/

 

 

 

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

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, 하둡 파일 압축, 분산 처리, 분산 저장

Hive 테이블

 

·       Version : Hive

 

하이브에서 테이블을 생성 할때에는 SQL 규칙을 따르지만 테이블의 데이터 파일 생성 위치나 사용할 포맷등 확장기능을 사용하여 유연성을 제공한다.

CREATE [TEMPORARY] [EXTERNAL] TABLE [IF NOT EXISTS] [db_name.]table_name    -- (Note: TEMPORARY available in Hive 0.14.0 and later)

  [(col_name data_type [column_constraint_specification] [COMMENT col_comment], ... [constraint_specification])]

  [COMMENT table_comment]

  [PARTITIONED BY (col_name data_type [COMMENT col_comment], ...)]

  [CLUSTERED BY (col_name, col_name, ...) [SORTED BY (col_name [ASC|DESC], ...)] INTO num_buckets BUCKETS]

  [SKEWED BY (col_name, col_name, ...)                  -- (Note: Available in Hive 0.10.0 and later)]

     ON ((col_value, col_value, ...), (col_value, col_value, ...), ...)

     [STORED AS DIRECTORIES]

  [

   [ROW FORMAT row_format]

   [STORED AS file_format]

     | STORED BY 'storage.handler.class.name' [WITH SERDEPROPERTIES (...)]  -- (Note: Available in Hive 0.6.0 and later)

  ]

  [LOCATION hdfs_path]

  [TBLPROPERTIES (property_name=property_value, ...)]   -- (Note: Available in Hive 0.6.0 and later)

  [AS select_statement];   -- (Note: Available in Hive 0.5.0 and later; not supported for external tables)

 

“IF NOT EXISTS” 명령은 테이블의 존재 유무를 확인하여, 테이블이 없을 경우 명령을 실행한다. 명령을 사용하면, 동일한 이름의 테이블이 있을경우 에러를 발생시키지 않고 다음 단계로 진행 있다. 하지만 이름만 확인할 스키마 구조까지 확인하는것은 아니다.

 

아래 스크립트는 Hive에서 테이블의 데이터를 제외한 스키마만 복사한다.

CREATE [TEMPORARY] [EXTERNAL] TABLE [IF NOT EXISTS] [db_name.]table_name

  LIKE existing_table_or_view_name

[LOCATION hdfs_path];

 

ex) CREATE TABLE IF NOT EXISTS testdb.mytable2 LIKE testdb.mytable;

 

테이블 정보를 확인하기 위해서는 DESCRIBE 명령을 사용한다.

describe tlb_a;

 

 

테이블의 정보를 자세히 확인할 때에는 EXTENDED 명령을 추가한다. EXTENDED 사용할 경우 자세한 정보가 출력되지만, 사람이 읽기에는 줄바꿈 등이 되지 않아 가독성이 불편하다.

describe extended tlb_a;

 

 

 

EXTENDED 대신 FROMATTED 사용하면 줄바꿈등이 적용되어 가독성이 뛰어나다.

describe formatted tlb_a;

 

 

EXTENDED 옵션을 사용한 출력에서 location 항목은 테이블의 데이터를 저장하는 HDFS 디렉터리 전체 URI 경로를 보여준다.

 

 

[참고자료]

 

 

 

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

 

 

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

 

HiveQL Hive 데이터베이스

 

·       Version : Hive

 

HiveQL Hive에서 사용하는 쿼리 언어이다. SQL 유사하지만 SQL 다르며 표준 ANSI SQL 지원하지 않는다. 하이브는 로우(ROW) 레벨의 삽입과 변경, 삭제를 지원하지 않으며, 트랜잭션 또한 지원하지 않는다. 하지만 하둡이 지원하는 범위 안에서 성능 확장을 위해 다양한 기능을 제공하며, 사용자가 정의한 확장과 외부 프로그램을 하이브와 연동할 수도 있다.

 

하이브에서 데이터베이스 개념은 단지 테이블의 카탈로그 또는 네임스페이스이다. 데이터베이스는 논리적인 그룹을 구성할 있으며 대규모 작업시 동일한 테이블명의 충돌을 방지할수도 있다. 데이터베이스를 별도로 지정하지 않으면 기본 데이터베이스(default) 사용한다. 아래 스크립트는 데이터베이스를 생성한다.

create database testdb;

 

create database if not exists testdb;

  

하이브는 데이터베이스마다 별도의 디렉터리를 생성하고 테이블을 하위 디렉터리에 저장한다. 데이터베이스 디렉터리는 “hive.metastore.warehouse.dir” 속성에 설정한 최상위 디렉터리 밑에 생성된다.  아래 스크립트는 데이터베이스 생성시 디렉터리 위치를 변경할 있다.

create database testdb

location '/user/data/testdb';

 

현재 생성되어 있는 데이터베이스의 디렉터리 경로를 확인하려면 describe 명령을 사용한다.

describe testdb;

 

데이터베이스 삭제 명령은 drop 명령을 사용한다. 하이브는 가본적으로 테이블이 있는 데이터베이스를 삭제하는것을 허용하지 않는다. 테이블을 모두 삭제 데이터베이스를 삭제 또는 cascade 명령을 사용하여 테이블이 존재하는 데이터베이스를 삭제할 있다. 데이터베이스가 삭제되면 해당 디렉터리도 같이 삭제 된다.

drop database if exists testdb cascade;

 

 

 

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

 

 

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

'SW Engineering > Hadoop' 카테고리의 다른 글

HDFS 저장소에 데이터를 압축해서 저장하면 더 좋을까?  (0) 2020.06.23
Hive 테이블  (0) 2020.06.23
Hive 텍스트파일 인코딩  (0) 2020.06.12
Impala Connection refuse Error  (0) 2020.06.12
Hive 데이터 타입  (0) 2020.06.09

Hive 텍스트파일 인코딩

 

·       Version : Hive

 

텍스트 데이터의 필드를 구분할때, (TAB) 또는 콤마(,) 많이 사용한다. 이러한 일반적인 구분 기호는 데이터안에 콤마나 탭이 포함되어 있을 경우 전체 데이터 필드가 맞지 않는문제가 발생할 있어 주의해야 한다. 하이브도 또는 콤마 같은 필드 구분자를 지원하지만 앞에서 말한 이유 때문에 일반적으로 사용하지 않는 여러 제어 문자를 기본 구분 기호로 사용한다. 아래표는 하이브에서 제공하는 구분기호이다. 만약 필드에서 탭으로 분리하려면 ‘\t’ 사용하고, 콤마의 경우 ‘,’ 사용한다.

구분기호

설명

\n

레코드 바꿈

^A

모든 컬럼을 분리한다. CREATE TABLE 문에서 명시적으로 지정할때는 8진수 코드 ‘\001’ 사용한다.

^B

ARRAY, STRUCT, MAP Key-Value 요소를 분리한다. CREATE TABLE 문에서 명시적으로 지정할때는 8진수 코드 ‘\002’ 사용한다.

^C

MAP Key-Value 에서 키를 관련된 값과 분리한다. CREATE TABLE 문에서 명시적으로 지정할때는 8진수 코드 ‘\003’ 사용한다.

 

CREATE TABLE HIVE_TABLE (

       COL1 STRING,

       COL2 FLOAT,

       COL3 ARRAY<STRING>,

       COL4 MAP<STRING, FLOAT>,

       COL5 STRUCT<C_1:STRING, C_2:STRING, C_3:STRING, C_4:INT>

)

ROW FORMAT DELIMITED

FIELDS TERMINATED BY '\001'

COLLECTION ITEMS TERMINATED BY '\002'

MAP KEYS TERMINATED BY '\003'

LINES TERMINATED BY '\n'

STORED AS TEXTFILE;

 

일반적으로 데이터베이스는 스키마 구조를 가지고 있으며, 데이터를 입력할때 스키마 구조에 맞춰서 입력한다. 이것을 ‘schema on write’라고 부른다. 하지만 하이브는 저장소에 대해 이런 쓰기 제어 구조를 가지고 있지 않으며 데이터를 읽을때 스키마를 적용한다. 이것을 ‘schema on read’라고 한다. 그래서 스키마와 파일의 내용이 일치하지 않으면 하이브는 값을 모두 null 채운다. 만약 숫자 필드가 정의되어있는데 문자열을 만나면 하이브는 null 반환한다.

 

 

 

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

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 텍스트파일 인코딩, 필드 구분, 문자열 구분

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive 테이블  (0) 2020.06.23
HiveQL과 Hive 데이터베이스  (0) 2020.06.17
Impala Connection refuse Error  (0) 2020.06.12
Hive 데이터 타입  (0) 2020.06.09
HDFS 데이터 저장소에는 RAID구성이 필요할까  (0) 2020.06.08

Impala Connection refuse Error

-          Couldn't open transport for hd-master:26000 (connect() failed: Connection refused)

 

·       Version : CDH 6.3

 

파이썬의 pyimpala 사용하여 Hadoop Impala 데이터를 입력하는 클라이언트가 있는데, 어느날부터 아래와 같은 오류를 출력하며 데이터가 입력되지 않았다.

InternalException: Error requesting prioritized load: Couldn't open transport for hd-master:26000 (connect() failed: Connection refused)

Error making an RPC call to Catalog server.

 

위와 같은 오류 메시지가 발생하였을경우,  impala 환경설정에서 Java Heap Size of Catalog Server in Bytes사이즈를 넉넉하게 할당함으로써 문제를 해결할 있다.

Java Heap Size of Catalog Server in Bytes

 

 

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

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, 임팔라, Impala, Connection refuse, 임팔라 커넥션 오류

Hive 데이터 타입

 

·       Version : Hive

 

Hive 여러 크기의 정수형과 부동소수점, 불린형과 임의의 길이를 가지는 문자열, TIMESTAMP, BINARY 타입등을 제공한다. 각각의 데이터형은 자바로 구현되어 있어 자바 데이터 타입과 동일하게 하이브에서 사용된다.

타입

크기

리터럴 문법 예제

TINYINT

1바이트 정수형

20

SMALLINT

2바이트 정수형

20

INT

4바이트 정수형

20

BGINT

8바이트 정수형

20

BOOLEAN

TRUE 또는 FALSE

TRUE

FLOAT

단정도 부동 소수점

3.14159

DOUBLE

배정도 부동 소수점

3.14159

STRING

문자의 시퀀스, 또는 문자열  설정가능. 작은 따옴표 큰따옴표 사용가능

‘Hello Hive’, “Hello Hive”

TIMESTAMP

정수형, 부동소수점, 문자열형

유닉스 TIMESTAMP, JDBC 호환 java SQL Timestamp 포맷. 소수점 9자리(nano second) 까지 가능

BINARY

바이트 배열의 형태 지원

 

 

BYNARY 데이터형은 관계형 데이터베이스의 VARBINARY 비슷하지만 관계형 데이터베이스는 BLOB 데이터 형은 별도의 저장소에 보관하는반면에, 하이브는 BINARY 데이터형의 데이터를 레코드에 모두 저장한다.

 

하이브는 다른 SQL 호환 언어처럼, 데이터형 이름의 대소문자 구분을 무시한다. 하지만 SQL 에서 일반적으로 지원하는 최대 허용 길이를 갖는 문자배열 지원하지 않는다. 관계형 데이터베이스와 목적이 다를뿐더러 다양한 파일 포맷을 지원해야 하기 때문에 필드를 구분할 있는 구분기호에 의존한다. 또한 하둡 하이브는 디스크의 읽기, 쓰기 성능 최적화를 강조하기 때문에 컬럼값이 길이를 고정하는것은 상대적으로 중요하지 않다.

 

하이브에서 단점도 부동소수점(FLOAT) 배정도 부동소수점(DOUBLE) 컬럼을 비교하거나, 정수형 값을 비교하는 쿼리를 실행하면, 묵시적으로 개의 데이터 타입중에 크기의 데이터  타입으로 변환하여, 동일한 데이터 타입으로 만든 비교한다. 문자열의 값을 숫자로 해석하려는 경우 명시적으로 다른 데이터형으로 변환하여 사용할 있다.

 

하이브는 struct, map, array 같은 컬럼을 지원한다. 또한 컬렉션 데이터 타입의 이름 대소문자 구분을 무시한다.

타입

설명

리터럴 문법 예제

STRUCT

C 구조체나 객체와 유사. 필드는 표기법으로 사용

struct(‘Sungwook’, ‘Kang’)

MAP

Key-Value 처럼 필드를 배열 표기법으로 사용

map(‘first’,’Sungwook’,’last’,’Kang’)

ARRAY

0으로 시작하는 정수로 색인할 있는 동일한 데이터형의 순차 시퀀스

array(‘Sungwook’, ’Kang’)

 

하이브는 개념을 가지고 있지 않다. 하지만 색인 테이블은 사용이 가능하다. 컬렉션 데이터 타입은 자바의 제네릭(generics) 문법 규칙을 따를 것에 유의해야한다. 예를들어 MAP<STRING, FLOAT> 모든 키는 STRING 데이터 타입을 가지고, 모든 값은 FLOAT 이다. ARRRAY <STRING> 마찬가지로 모든 아이템은 STRING 데이터 타입을 가진다. STRUCT 서로 다른 데이터 타입을 섞어 사용할 있으나 STRUCT 안에서 선언된 위치는 고정된다.

 

 

 

[참고자료]

·       Hive Data Types : https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Types

 

 

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

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, Hive, 하이브, 하이브 데이터 타입

HDFS 데이터 저장소에는 RAID구성이 필요할까

 

·       Version : HDFS

 

HDFS 클러스터에서 데이터노드 저장소 용도로 RAID(Redundant Array of Independent Disks) 사용하면 이득이 있을까?

결론부터 이야기하면 이득이 없다. HDFS 노드간에 복제하는 기능이 있어 RAID 제공하는 중복성(redundancy) 필요하지 않기 때문이다. 또한 성능 향상을 위해 흔히 사용하는 RAID 0 (Striping) 모든 디스크에 DHFS 블록을 연속적으로 배열하는 HDFS JBOD (Just a Bunch of Disks)방식보다 느리다는 것이 밝혀졌다. 이유는 RAID 0 읽기/쓰기 동작의 경우 RAID 배열에서 가장 느린 디스크의 속도에 의해 제한을 받기 때문이다. 반면 JBOD에서는 디스크 동작들이 독립적이며 이러한 동작들의 평균속도는 가장 느린 디스크보다 빠르다. 실제로 동일한 제조사의 동일 모델의 디스크여도 편차를 보이는 경우가 있다. 또한 JBOD 환경에서는 디스크 하나가 고장날 HDFS 고장난 디스크 없이도 계속해서 동작할 있지만  RAID 하나의 디스크 고장이 전체 디스크 배열을 불능 상태로 만들 있다. 뜻한 RAID 0에서 디스크 한개의 불량이 노드 하나를 통째로 불능 상태로 만들 있다는 뜻이다.

 

그렇다면  HDFS에서 RAID 정말 필요 없을까?  네임노드에는 RAID 1 (Mirroring)으로 구성하여 가용성을 높일 있다.

 

디스크 목록을 dfs.data.dir 매개변수에 전달하면 하둡은 사용 가능한 모든 디스크를 사용한다. 디스크가 오프라인 상태가 되면 사용가능 대상에서 제외한다. 그리고 제외된 디스크가 다시 사용가능한 상태가 되었는지 검사하지는 않는다.

 

Note : 하둡 시스템에 사용하는 메모리는 ECC 메모리를 사용하도록 한다. ECC 메모리가 아닌 경우 하듭 클러스터에서 체크섬 오류가 발생할 있다.

 

 

[참고자료]

 

 

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

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, 하둡 RAID, 분산 처리, 분산 저장

'SW Engineering > Hadoop' 카테고리의 다른 글

Impala Connection refuse Error  (0) 2020.06.12
Hive 데이터 타입  (0) 2020.06.09
Hive에서 하둡(dfs)명령 실행  (0) 2020.05.19
ZooKeeper 옵저버와 CLI  (0) 2020.05.19
Hive에서 쉘 명령 실행  (0) 2020.05.18

NameNode and Secondary NameNode Heap Memory Size 변경

 

·       Version : CDH 6.3

 

NameNode Master and Slave 구성하였을때, NameNode간의 힙메모리 설정이 다른 경우 경고가 발생한다. (서비스 장애가 발생하는 것은 아님) Cloudera Hadoop Manager에서는 아래와 같은 메뉴에서 Heap Memory Size 설정할 있다.

 

NameNode 핵심은 HDFS 메타 데이터 (HDFS 블록 정보) 관리하며, 파일 시스템 레이아웃은 디스크에 유지되며 블록 위치는 단독으로 메모리에 유지된다. 클라이언트가 파일을 조회하면 네임노드는 클라이언트에게 파일에 있는 모든 블록의 위치를 알려준다. 그리고 클라어인트는 데이터 전송을 위해 네임노드와 통신할 필요가 없다. 네임노드에 필요한 메모리는 많으면 많을수록 좋지만, 일반적으로 백만개의 객체(파일, 디렉토리 블록) 1GB 정로로 계산한다. 자세한 내용은 아래 링크를 참고 하여 사용자 서버환경에 적합한 메모리를 산정할 있도록 한다.

 

·       Sizing NameNode Heap Memory : https://docs.cloudera.com/documentation/enterprise/5-8-x/topics/admin_nn_memory_config.html

 

 

Cloudera Manager 실행하여 HDFS 탭으로 이동하여Configuration 메뉴를 선택한다.

 

검색창에서 “Java Heap Size” 검색하여 Java Heap Size 변경한다.

 

 

 

 

2019-11-19 / Sungwook Kang / http://sungwookkang.com

 

Hadoop, 하둡, HDFS, 하둡 파일 저장, NameNode, 네임노드, 보조네임노드, Secondary NameNode, heap memory size, heap memory

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive Architecture  (0) 2019.11.26
HBase와 Zookeeper 상호작용 관계  (0) 2019.11.21
Hadoop Name Node  (0) 2019.11.19
HDFS 블록  (0) 2019.11.16
HDFS 파일 저장(로컬 업로드)  (0) 2019.11.14

Hadoop Name Node

 

·       Version : HDFS

 

네임노드(Namenode) 파일 시스템의 네임스페이스를 관리한다. 네임노드는 파일 시스템 트리와 트리에 포함된 모든 파일과 디렉터리에 대한 메타데이터를 유지한다. 정보는 네임스페이스 이미지(namespace image) 에디트 로그(edit log)라는 종류의 파일로 로컬 디스크에 영속적으로 저장된다. 네임노드는 파일에 속한 모든 블록이 어느 데이터노드에 있는지 파악하고 있다. 하지만 블록의 위치 정보는 시스템이 시작할 모든 데이터노드로 부터 받아서 재구성하기 때문에 디스크에 영속적으로 저장하지는 않는다.

 

네임노드는 메타데이터를 관리하기 때문에 네임노드에 장애가 발생하면 파일 시스템은 동작하지 않으며 파일 시스템의 어떠한 파일도 찾을 없다. 데이터 노드에 블록이 저장되어 있지만 이러한 블록 정보를 이용하여 파일을 재구성할 없기 때문이다. 따라서 네임노드의 2중화 장애복구 전략은 필수적이다. 아래 그림은 Namenode HA 주요 컴포넌트 구성이다.

 

 

[저널노드]

·       하둡 1.0에서는 네임노드에서만 에디트 로그 저장하고, 하둡 2.0에서는 여러 서버에 에디트 로그를 복제해서 저장한다.

·       저널노드(데몬) 에디트 로그를 자신이 실행되는 서버의 로컬디스크에 저장한다.

·       네임노드는 클라이언트가 돼서 저널노드에게 접근해 저장을 요청. 액티브 네임노드만 에디트로그를 저장할 권한이 있으며 스탠바이 네임노드는 조회만 요청 가능하다.

·       저널노드는 3 이상의 서버에서 실행되어야하고 홀수 단위로만 실행가능하기 때문에, 네임노드가 저널노드의 장애에 영향을 받지 않으려면 "(전체 저널노드 설치대수/2) / +1" 만큼 노드가 필요하다. (ex : 5대에 저널 노드를 설치했으면 최소 3 이상의 저널노드가 실행)

·       리소스를 적게 사용하기 때문에 "네임노드", "잡트래커", "리소스매니저" 같은 데몬이 돌아가는 서버에서 함께 실행 가능하다.

 

[주키퍼]

·       네임노드 HA 상태 정보를 저장하는 장소이며 어떤 서버가 액티브(active) 네임노드인지 스탠바이(standby) 네임노드인지 저장한다.

·       분산시스템 코디네이터 역할을 하며 서버 간의 정보 공유한다.

·       서버 모니터링하여 새로운 노드를 추가하거나 삭제하였을때, 다른 노드들에게 알려준다.

·       주키퍼 마스터(주키퍼 앙상블에 구성된 주키퍼 한대) 홀수 단위로 실행하며 주키퍼 클라이언트는 주키퍼 마스터가 응답을 안할 경우 다른 주키퍼 마스터 에게 요청한다. (2대중 한대가 고장나면 실행 안됨)

·       주키퍼 마스터는 동일한 주키퍼 데이터를 복제하고 있기 때문에 클라이언트로부터 조회요청이 들어오면 자신이 보관한 데이터를 이용해 응답하며 쓰기 요청은은 오로지 리더로 설정된 주키퍼 마스터에게 보내진다.

·       ZNode: 주키퍼에서 저장되는 파일 하나하나를 ZNode라고

 

[ZKFC (Zookeeper Failover Controller)]

·       로컬 네임노드(자신이 위치한 네임노드) 상태를 모니터링하며 주키퍼 세션 관리한다.

·       액티브 네임노드의 상태가 정상이면 주키퍼 마스터에 대한 세션 유지하며 액티브 네임 노드에 장애가 발생하면 자동으로 ZKFC 주키퍼 마스터 간의 세션을 종료하고 스탠바이 네임 노드를 액티브 네임 노드로 전환하며, 기존의 액티브 네임 노드 제거한다.

 

[네임노드]

·       네임노드 내부에 있는 QJM(Quorum Journal Manager) 저널노드에 에디트 로그 출력하며, 반드시 절반이상의 저널노드가 실행되고 있어야 에디트 로그를 fsimage 반영할 있다. (3대중 2대는 최소 작동)

·       액티브 네임노드만 저널노드에 에디트로그 쓸수 있으며, 스탠바이 네임노드는 저널노드에서 에디트로그 조회하고 fsimage 갱신한다.

 

[데이터 노드]

·       데이터노드의 블록 정보를 액티브 네임노드, 스탠바이 네임노드로 리포트 전송

 

 

네임노드 장애 복구를 위해서는 아래와 같은 절차를 사용할 있다.

·       네임노드 로컬 디스크와 원격의 NFS 마운트 곳에 동시 백업진행한다.

·       파일 시스템의 데타데이터를 지속적인 상태로 보존하기 위해 파일로 백업한다.

·       보조 네임 노드를 운영한다. 병합 작업을 수행하기 위해 보조 네임노드는 충분한 CPU 네임노드와 비슷한 용량의 메모리가 필요하므로 별도의 물리 머신에 실행되는것이 좋다.

·       보조 네임 노드는 네임노드에 장애가 발생할 것을 대비해서 네임스페이스 이미지의 복제본을 보관하는 역할도 맡는다. 하지만 네임노드의 네임스페이스 이미지는 약간의 시간차를 두고 보노 네임 노드로 복제되기 때문에 네임노드에 장애가 발생하면 어느정도의 데이터 손실은불가피 하다. 일반적인 복구 방식은 NFS 저장된 네임노드의 메타데이터 파일을 보조 네임노드로 복사하여 새로 병합된 네임스페이스 이미지를 만들고 그것을 새로운 네임노드에 복사한 다음 실행하는 것이다.

 

 

 

 

2019-11-18 / Sungwook Kang / http://sungwookkang.com

 

Hadoop, 하둡, HDFS, 하둡 파일 저장, NameNode, 네임노드, 보조네임노드, Secondary NameNode

'SW Engineering > Hadoop' 카테고리의 다른 글

HBase와 Zookeeper 상호작용 관계  (0) 2019.11.21
NameNode and Secondary NameNode Heap Memory Size 변경  (0) 2019.11.20
HDFS 블록  (0) 2019.11.16
HDFS 파일 저장(로컬 업로드)  (0) 2019.11.14
Cloudera Hadoop 6.3.0 Install  (0) 2019.11.14

HDFS 블록

 

·       Version : HDFS

 

HDFS 파일은 지정한 크기의 블록으로 나누어지고, 블록은 독립적으로 저장된다. HDFS 블록의 기본 사이즈는 128MB이며 수정이 가능하다. 블록이 이유는 탐색 비용을 최소화 있기 때문인데, 블록이 크면 하드 디스크에서 블록의 시작점을 탐색하는데 걸리는 시간을 줄일 있고, 네트워크를 통해 데이터를 전송하는데 많은 시간을 할당할 있다. 여러개의 블록으로 구성된 대용량 파일을 전송하는 시간은 디스크 I/O 속도에 크게 영향을 받게 된다. 아래 그림은 64MB 설정된 HDFS 블록에 160MB 저장할때 블록 단위로 나누어져 저장된다.

 

블록 단위로 파일을 나누어 저장하면 파일 하나의 크기가 단일 디스크의 크기보다 크더라도 저장할 있다. 또한 스토리지 서브시스템을 단순하게 만들 있기 때문에 메타정보를 가지고 파일의 위치를 쉽게 찾을 있다. (메타정보는 네임노드에 저장되며 HDFS SPOF 이무로 HA 구성을 권장한다.) 아래 그림은 HDFS 블록을 복제하는 것으로 HDFS 기본 복제단위는 3개로 구성되어 있다.

 

데이터노드는 주기적으로 블록 스캐너를 실행하여 블록의 체크섬을 확인하고 오류가 발생하면 수정한다. 데이터노드에 저장된 데이터 자주 사용되는 블록은 블록 캐시(block cache)라는 데이터 노드의 메모리에 명시적으로 캐싱할 있다. 파일 단위로도 캐싱할 있어 조인에 사용되는 데이터들을 캐싱하여 읽기 성능을 높일 있다.

# pool 등록

$ hdfs cacheadmin -addPool pool1

Successfully added cache pool pool1.

 

# path 등록

$ hdfs cacheadmin -addDirective -path /user/hadoop/shs -pool pool1

Added cache directive 1

 

# 캐쉬 확인

 hdfs cacheadmin -listDirectives

Found 1 entry

 ID POOL    REPL EXPIRY  PATH            

  1 pool1      1 never   /user/hadoop/shs

 

 

 

 

2019-11-15 / Sungwook Kang / http://sungwookkang.com

 

Hadoop, 하둡, HDFS, 하둡 파일 저장, HDFS Block

'SW Engineering > Hadoop' 카테고리의 다른 글

NameNode and Secondary NameNode Heap Memory Size 변경  (0) 2019.11.20
Hadoop Name Node  (0) 2019.11.19
HDFS 파일 저장(로컬 업로드)  (0) 2019.11.14
Cloudera Hadoop 6.3.0 Install  (0) 2019.11.14
하둡실행  (0) 2015.07.22

HDFS 파일 저장(로컬 업로드)

 

·       Version : CDH 6.3.0, Centos 7

 

로컬에 있는 파일을 HDFS 저장하는 방법에 대해서 알아본다. 시스템에서 hadoop과의 통신은 hadoop라는 명령을 사용한다. 쉘에서 hadoop 라고 입력하면 도움말을 확인할 있다.

hadoop

 

 

HDFS 디렉터리를 조회하는 명령은 hadoop fs -ls 이며 특정 경로을 입력하지 않으면 root 디렉터리를 조회한다. 특정 디렉터리를 조회할 때에는 hadoop fs -ls /user 같이 디렉터리명을 사용한다. 디렉터리 구조는 호스트의 디렉터리 구조와는 연관성이 없다는 것을 명심한다.

hadoop fs -ls

hadoop fs -ls /user

 

 

HDFS에서 디렉터리를 생성하는 명령은 fs -mkdir 이다. 아래 스크립트는 HDFS /user/root 디렉터리를 생성한다.

hadoop fs -mkdir /user/root

 

--Permission으로 오류 발생시 아래 스크립트 사용

sudo -u hdfs hadoop fs -mkdir /user/root

sudo -u hdfs hadoop fs -chown root /user/root

 

HDFS 데이터를 저장(업로드) 하는 방법은 fs -put 명령을 사용한다. 아래 예시는 testlog라는 파일을 HDFS /user/root라는 HDFS 디렉터리에 업로드 한다. 만약 HDFS 있는 파일을 로컬로 가져오고 싶을때는 get 명령을 사용한다.

hadoop fs -put testlog /user/root/testlog

 

HDFS 데이터를 삭제 하는 명령은 fs -rm 이다.

hadoop fs -rm /user/root/testlog

 

 

 

2019-11-13 / Sungwook Kang / http://sungwookkang.com

 

Hadoop, Cloudera Hadoop, CDH, 하둡, 클라우데라 하둡, HDFS, 하둡 파일 저장, HDFS 저장

'SW Engineering > Hadoop' 카테고리의 다른 글

Hadoop Name Node  (0) 2019.11.19
HDFS 블록  (0) 2019.11.16
Cloudera Hadoop 6.3.0 Install  (0) 2019.11.14
하둡실행  (0) 2015.07.22
하둡 환경설정 파일 수정  (0) 2015.07.22

+ Recent posts