정선생의 데이터 팡팡

개요 hive 는 쿼리기반으로 데이터를 분석하기 위한 도구이다. 스키마는 메타스토어의 DBMS에 저장되지만 실제 데이터는 기본적으로는 HDFS 에 저장되어 있다. 그래서 hive 에서 논리적으로 테이블, 파티션, 버킷이라고 부르지만, 물리적으로 데이터가 어떻게 저장되어있냐? 하는 관점에서 생각하면 HDFS 의 폴더와 파일로 생각할 수 있다. 하둡 패키지에 따라 root 폴더는 다르겠지만 아래와 같은 폴더 구조로 저장된다는말이다. /apps/hive/warehouse/.db//=/ 예를 들면, 이런 폴더 구조를 생각하면 쉽다 (db폴더) /apps/hive/warehouse/temp.db (table 폴더) /apps/hive/warehouse/temp.db/t_foo (파티션 없는 temp.t_foo 테..

오류내용 hive 에 STRUCT 형으로 필드가 있는 테이블을 JOIN 할 때 나타났던 문제이다. hql의 문법상 문제가 없는데 beeline 에서 뱉는 오류메시지는 다음과 같다. (tez 엔진을 사용했다) INFO : Map 1: 26(+2)/28 Map 5: 337(+33)/370 Map 6: 1(+1)/2 Reducer 3: 0(+0,-415)/377 Reducer 4: 0/208 ERROR : Status: Failed ERROR : Vertex re-running, vertexName=Map 5, vertexId=vertex_1475821062280_208694_1_01 ERROR : Vertex re-running, vertexName=Map 6, vertexId=vertex_147582106..

개요 하둡클러스터가 부서별로 여러대를 운영할 경우 rpc-address 를 기반으로 접근하는 경우가 많다. 하지만 HA구성이 되어있다면 리더를 담당하는 서버가 변경되서 동작이 안되는 경우가 존재한다. 이걸 해결하려면 rpc-address 가 아니라 nameservice 를 이용해 접근할 수 있어야 한다. 클러스터가 다른 하둡의 nameservice 를 등록하려면 어떻게 해야할까? 다음과 같은 형식으로 hdfs-site.xml 를 수정하면 여러대의 nameservice 를 사용할 수 있게 된다. NameService 설정 통합방법 보면 클러스터별 hdfs-site.xml 설정파일을 받아서, nameservice 관련된 설정을 묶어서 hdfs-site.xml 설정을 만들어 내면된다. 예를 들면 다음과 같다...

카프카의 토픽이나 그룹정보를 확인하는 기본적인 명령어 툴이 있다. 인터넷에 있는 대부분의 예시는 인증이 없는 방식이 예로 있는데, 카프카클러스터에 보안인증이 존재할때 기냥 명령을 내리면 실행이 안되고 에러가 난다. consumer 를 만들어서 실행할땐 properties 에 선언해서 큰 문제가 없는데, username 과 password 를 선언하기가 조금 애매한 상황이 발생된다. 이럴땐 --command-config 을 이용해서 파일의 설정을 읽어 내면 된다. 인증있는 카프카에 명령 하기 우선 다음과 같은 보안과 관련된 설정을 파일을 만들어 두어야 한다. 그리고 실행할때 파라미터로 제공하면 된다. 자주 쓰는 패턴의 명령어 예시는 아래에 적어두었다. kafka-auth.properties bootstra..

카프카에서 kafka-console-consumer 를 사용할 경우, JSON 이나 STRING 형태의 데이터가 잘 보이지만, AVRO 포맷으로 저장하는 데이터는 다음과 같이 깨지는 현상이 있다. 그래서 토픽의 결과를 깨지 않고 보려면 딴 명령을 사용해야 한다. 참고로 본인은 confluent 에서 제공하는 기본툴을 다운로드 받아서 사용했다. ./kafka-console-consumer \ --bootstrap-server 127.0.0.1:9092 \ --topic 토픽명 \ --from-beginning �߶�����xx-1234��吅����񑳂������my�� Ȼ ����� �¢�����xx-1234�Èă�������3�������my��� AVRO 토픽 결과 조회하기 avro 포맷은 스키마가 존재..

배치가 주기적으로 돌고 있는데, 분석을 위해 select 를 하게되면 더 골치아프다. 경험상 select 를 주기적으로 하면 락때문에 insert 는 무한히 밀려서 배치작업에 영향을 주기도 한다. 이런일이 자주 일어난다면 select 쿼리에서는 lock 정보를 사용하지 않는것이 정신건강에 좋다. hive lock 안쓰기? 하이브에서 주기적으로 배치가 돌고 있고, 쿼리가 복잡해서 오래 실행되면서 주키퍼에 lock 정보는 쌓였는데, yarn 에서는 작업을 무한대기 하는 상태인 경우가 종종 생긴다. 이럴땐 아예 lock 을 안걸고 쓰는게 안정적인 운영에 도움이 될수 있다. (hive 의 lock 체계는 우리가 주로 쓰는 dbms 의 lock 정책에 비하면 매우 초보적이다) hive> set hive.suppo..

하둡을 사용하다보면 디스크 사용량이 70%를 넘어서기 시작하면 장애가 생기는 경우가 은근히 많다. 그리고, 클러스터의 모니터링 알람같은걸 해두면 알람도 많이 오기 때문에 물리적인 디스크 공간을 확보해야 할 필요가 있다. 이때 가장 먼저 삭제시도할 폴더는 HDFS 의 휴지통 공간이다. 휴지통 용량 확인 & 비우기 다음과 같이 hdfs 의 .Trash 를 확인해보면 그 용량이 꽤 무시못한다. 참고로, "hadoop fs -rm -f " 형태로 지우면, 바로 삭제되는게 아니라 .Trash 폴더로 옮겨지고 특정 기간이 지나면 삭제되는 구조다. 그래서 보통 데이터 마이그레이션과 같이 파일을 많이 복사하고 삭제하는게 반복되면 생각보다 여기에 쌓이는 공간이 꽤 크다. 그래서 hdfs 공간이 부족하면 일단 응급처치(?..

단순히 "select * from 테이블" 형태로 조회하면 결과가 나오는데, 희안하게 "select count(*) from 테이블" 형태로 쿼리를 나오면 0으로 나오는 현상이다. 이 경우 hive 의 통계 자료가 잘못 입력되어있어서 그런 경우가 간혹 생기는 경우가 있다. 결과가 이상한 쿼리 예시 다음과 같이 단순 select 하면 결과가 분명히 나오는데, count(*) 하면 결과가 0으로 나오는것이다. --------------------------- -- 단순 조회를 하면 결과가 나옴 --------------------------- hive> select * from mig.t_my_data; -- 결과가 40 건 출력됨 -- --------------------------- -- count(*)..