아파치 하이브 | 빅데이터 047 하이브 아키텍쳐와 데이터 모델 94 개의 정답

당신은 주제를 찾고 있습니까 “아파치 하이브 – 빅데이터 047 하이브 아키텍쳐와 데이터 모델“? 다음 카테고리의 웹사이트 ppa.maxfit.vn 에서 귀하의 모든 질문에 답변해 드립니다: https://ppa.maxfit.vn/blog. 바로 아래에서 답을 찾을 수 있습니다. 작성자 구자환 AIBigLab 이(가) 작성한 기사에는 조회수 1,949회 및 좋아요 30개 개의 좋아요가 있습니다.

아파치 하이브(Apache Hive)는 하둡에서 동작하는 데이터 웨어하우스(Data Warehouse) 인프라 구조로서 데이터 요약, 질의 및 분석 기능을 제공한다. 초기에는 페이스북에서 개발되었지만 넷플릭스등과 같은 회사에서 사용되고 있으며 개발되고 있다.

아파치 하이브 주제에 대한 동영상 보기

여기에서 이 주제에 대한 비디오를 시청하십시오. 주의 깊게 살펴보고 읽고 있는 내용에 대한 피드백을 제공하세요!

d여기에서 빅데이터 047 하이브 아키텍쳐와 데이터 모델 – 아파치 하이브 주제에 대한 세부정보를 참조하세요

빅데이터 강의 노트
https://trello.com/b/VjgDkljT/big-data-koo-lecture-notes
https://sites.google.com/site/jahwankoo

아파치 하이브 주제에 대한 자세한 내용은 여기를 참조하세요.

아파치 하이브란? (Apache Hive)

아파치 하이브는 하둡 환경에서 1) 복잡한 맵리듀스(또는 다른 엔진) 코드를 SQL과 유사한 간단한 HiveQL로 처리가 가능하도록 하고, 2) 파일시스템에 …

+ 여기에 자세히 보기

Source: kadensungbincho.tistory.com

Date Published: 2/27/2022

View: 6452

Apache Hive

Apache Hive is an open source project run by volunteers at the Apache Software Foundation. Previously it was a subproject of Apache® Hadoop®, but has now …

+ 여기에 자세히 보기

Source: hive.apache.org

Date Published: 3/16/2022

View: 3553

Apache Hive 개요 및 간단한 실습

하이브(Apache Hive). 1) 하둡 이전의 (빅)데이터 분석업무를 맡은 사람들은 SQL등을 활용하여 업무를 수행했음.

+ 여기에 표시

Source: dabingk.tistory.com

Date Published: 2/19/2021

View: 6097

[Hive] 하이브 이해하기 – 끝내주게 숨쉬기

하이브를 이용하면 HDFS(Hadoop Distributed File System)에 저장된 데이터에 SQL과 유사한 … 아파치 하이브 – 위키백과, 우리 모두의 백과사전.

+ 여기에 보기

Source: abluesnake.tistory.com

Date Published: 11/5/2021

View: 7652

1-하이브란? – 빅데이터

하이브는 하둡 에코시스템 중에서 데이터를 모델링하고 프로세싱하는 경우 가장 많이 사용하는 데이터 웨어하우징용 솔루션입니다. RDB의 데이터베이스, 테이블과 같은 …

+ 더 읽기

Source: wikidocs.net

Date Published: 9/29/2021

View: 1426

아파치 하이브 – 제타위키

Apache Hive; Hive; 아파치 하이브; 하이브. 하둡 위에 위치하는 데이터웨어하우스; Hadoop 위에 구축되는 데이터웨어하우스 구축 환경; 데이터 집약, …

+ 여기에 더 보기

Source: zetawiki.com

Date Published: 2/28/2021

View: 8772

[BIGDATA Platform] 빅데이터 탐색 기술 : 하이브(Hive)

1) 아파치 하이브는 아파치 HDFS이나 아파치 HBase와 같은 데이터 저장 시스템에 저장되어 있는 대용량 데이터 집합들을 분석합니다. 2) HiveQL 이라고 불리는 SQL같은 …

+ 더 읽기

Source: kerpect.tistory.com

Date Published: 7/23/2022

View: 3755

아파치 하이브(Hive) 튜토리얼 – (사)정보화사회실천연합

아파치 하이브(Hive) 튜토리얼. cisp 2013년 8월 22일 … 하이브로 할 수 있는것? 하이브는 하둡 기반의 데이터웨어하우스 인프라이다.

+ 자세한 내용은 여기를 클릭하십시오

Source: www.cisp.or.kr

Date Published: 10/18/2022

View: 6399

하이브 (Apache Hive) 개념 및 설치 (아파치 더비 사용)

페이스 북에서 개발한 하이브는 하둡에 저장된 데이터를 쉽게 처리할 수 있는 데이터웨어하우스(DW) 패키지 이다. 1)하이브 아키텍처. 하이브의 …

+ 자세한 내용은 여기를 클릭하십시오

Source: excelsior-cjh.tistory.com

Date Published: 6/6/2022

View: 5604

주제와 관련된 이미지 아파치 하이브

주제와 관련된 더 많은 사진을 참조하십시오 빅데이터 047 하이브 아키텍쳐와 데이터 모델. 댓글에서 더 많은 관련 이미지를 보거나 필요한 경우 더 많은 관련 기사를 볼 수 있습니다.

---

주제에 대한 기사 평가 아파치 하이브

• Author: 구자환 AIBigLab
• Views: 조회수 1,949회
• Likes: 좋아요 30개
• Date Published: 2018. 6. 28.
• Video Url link: https://www.youtube.com/watch?v=BTwLa3HrT-k

위키백과, 우리 모두의 백과사전

아파치 하이브(Apache Hive)는 하둡에서 동작하는 데이터 웨어하우스(Data Warehouse) 인프라 구조로서 데이터 요약, 질의 및 분석 기능을 제공한다.[3] 초기에는 페이스북에서 개발되었지만 넷플릭스등과 같은 회사에서 사용되고 있으며 개발되고 있다.[4][5]

아파치 하이브는 아파치 HDFS이나 아파치 HBase와 같은 데이터 저장 시스템에 저장되어 있는 대용량 데이터 집합들을 분석한다. HiveQL 이라고 불리는 SQL같은 언어를 제공하며 맵리듀스의 모든 기능을 지원한다. 쿼리를 빠르게 하기 위해 비트맵 인덱스를 포함하여 인덱스 기능을 제공한다.[6]

기본적으로 하이브는 메타데이터를 내장된 아파치 더비(Derby) 데이터 베이스안에 저장한다. 그렇지만 MySQL과 같은 다른 서버/클라이언트 데이터베이스를 사용할 수 있는 선택권을 제공한다.[7] 현재 TEXTFILE, SEQUENCEFILE, ORC 그리고 RCFILE등 4개의 파일 포맷을 지원한다.[8][9]

같이 보기 [ 편집 ]

참조 [ 편집 ]

아파치 하이브란? (Apache Hive)

반응형

아파치 하이브는 하둡 환경에서 1) 복잡한 맵리듀스(또는 다른 엔진) 코드를 SQL과 유사한 간단한 HiveQL로 처리가 가능하도록 하고, 2) 파일시스템에 저장된 데이터에 catalog와 metastore를 제공하여 논리적 데이터 베이스, 테이블, 파티션을 제공하여 데이터를 구조화할 수 있게 합니다.

이번글에서는 아파치 하이브의 구조를 중심으로 아래와 같은 내용을 살펴보도록 하겠습니다:

하이브의 탄생배경

아파치 하이브 아키텍쳐

하이브의 데이터모델과 쿼리 (Hive QL)

하이브의 탄생배경

하이브는 페이스북에서 개발이 시작되어, 넷플릭스와 같은 다른 기업도 기여하였습니다. 2000년대 초, 하둡이 탄생하여 데이터 분석은 데이터베이스 기반에서 하둡 환경을 기반으로 진행되기 시작하였습니다. 하둡은 기존의 데이터베이스 환경이 가지고 있던 한계를 넘는 기능을 제공해주었지만 복잡한 맵리듀스 코드를 작성해야 되고, 테이블과 같은 논리적인 개념이 없어서 파일 단위 또는 디렉토리 단위로 데이터를 관리하였습니다.

하이브는 이러한 하둡 환경에서 데이터 웨어하우징과 같은 SQL 기반의 접근을 통한 데이터 처리와 데이터베이스, 테이블, 파티션과 같은 논리적 레벨의 카탈로그 및 메타스토어를 제공합니다.

실례로 아래와 같은 64 라인의 워드카운트 java 맵리듀스 코드는,

package org.myorg; // … public class WordCount { public static class Map extends Mapper { // … } public static class Reduce extends Reducer { // … } public static void main(String[] args) throws Exception { Configuration conf = new Configuration(); Job job = new Job(conf, “wordcount”); job.setOutputKeyClass(Text.class); job.setOutputValueClass(IntWritable.class); job.setMapperClass(Map.class); job.setReducerClass(Reduce.class); job.setInputFormatClass(TextInputFormat.class); job.setOutputFormatClass(TextOutputFormat.class); FileInputFormat.addInputPath(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1])); job.waitForCompletion(true); } }

아래와 같은 하이브 쿼리를 통해 처리될 수 있습니다:

CREATE TABLE docs (line STRING); LOAD DATA INPATH ‘docs’ OVERWRITE INTO TABLE docs; CREATE TABLE word_counts AS SELECT word, count(1) AS count FROM (SELECT explode(split(line, ‘\s’)) AS word FROM docs) w GROUP BY word ORDER BY word;

아파치 하이브 아키텍쳐

하이브의 아키텍쳐는 아래 이미지와 같이 접근포인트들(CLI, Hive Server, Web UI), 드라이버, 컴파일러, 메타스토어로 구성됩니다:

Apache Hive Architecture – Image from Author

각 컴포넌트별로 간단하게 살펴보면 [1, 4],

접근포인트 : CLI, Hive Server, UI와 같은 접근포인트들은 외부 사용자가 하이브에 쿼리를 제출할 수 있는 사용자 인터페이스를 제공합니다. Hive Server : 하이브 서버는 하이브 쿼리문을 실행할 수 있는 API를 제공합니다. Thrift는 언어 간의 커뮤니케이션을 위한 프레임웍이기에 Hive Server는 Java로 구현되었지만 다양한 언어를 지원할 수 있습니다.

: CLI, Hive Server, UI와 같은 접근포인트들은 외부 사용자가 하이브에 쿼리를 제출할 수 있는 사용자 인터페이스를 제공합니다.

드라이버 : 드라이버는 하이브 쿼리를 받고 쿼리의 라이프사이클을 관리하는 컨트롤러 역할을 담당합니다. 세션을 생성하여 쿼리문 실행을 시작하고 진척과 라이프사이클을 모니터링합니다. 또한, 쿼리문 실행 시 생성되는 메타데이터를 저장하고, 리듀스 실행 이후의 결과물을 수집하는 포인트가 됩니다. Executor : 컴파일과 최적화 이후에 엑서큐터는 tasks를 실행합니다. 실행 엔진과 연동하여 의존성을 가진 작업이 순차적으로 실행되도록 관리합니다.

: 드라이버는 하이브 쿼리를 받고 쿼리의 라이프사이클을 관리하는 컨트롤러 역할을 담당합니다. 세션을 생성하여 쿼리문 실행을 시작하고 진척과 라이프사이클을 모니터링합니다. 또한, 쿼리문 실행 시 생성되는 메타데이터를 저장하고, 리듀스 실행 이후의 결과물을 수집하는 포인트가 됩니다.

컴파일러: 하이브 쿼리의 컴파일을 담당하여 쿼리를 실행플랜으로 변환합니다. 이러한 플랜은 결과물을 얻기 위한 실행 엔진의 tasks와 steps를 포함합니다. 컴파일러는 쿼리는 abstract synctax tree(AST)로 변환하고, 호환성과 컴파일 타임 에러 확인 후 DAG(Directed Acyclic Graph)로 다시 변환합니다. DAG은 operators를 실행 엔진의 stages와 tasks로 나누게 됩니다. 또한, 이러한 과정에 논리적, 물리적 플랜을 기초로 최적화를 진행합니다.

메타스토어: 각 테이블의 스키마, 위치와 같은 메타데이터를 관리하며 1) data abstraction 과, 2) data discovery 를 제공합니다. 또한, 파티션 메타데이터를 통해서 드라이버가 클러스터에 분산된 다양한 데이터 셋의 progress를 트래킹하도록 돕습니다. 메타스토어는 하이브 메타데이터 쿼리를 위해 Thrift 인터페이스를 제공하며, 드라이버는 MS Client를 통해 메타스토어에 접근합니다.

하이브의 데이터모델과 쿼리 (Hive QL)

하이브의 위의 내부구조는 사용자 입장에서 데이터 처리를 간단하고 명료하게 수행하도록 하는 것을 목표로 합니다. 이번 장에서는 그러한 부분에 초점을 맞추어 사용자 입장에서 많이 고려하게 될 데이터모델이나 HQL과 같은 부분을 살펴보겠습니다.

데이터모델

하이브에서 데이터는 아래와 같은 주요 객체를 통해 구조화 됩니다: 데이터베이스, 테이블, 파티션, 버킷, 뷰 그리고 데이터타입들.

데이터베이스

(실제 데이터를 포함하지 않으나) 테이블의 그룹

테이블

관계형 데이터베이스의 테이블에 상응하는 객체입니다. 각 테이블은 해당되는 HDFS 디렉토리를 가집니다 (하지만 모든 데이터가 subpath에 존재하지 않을 수 있습니다). 그리고 테이블 안에 있는 데이터는 직렬화 되어 저장됩니다. 사용자는 테이블에 데이터의 직렬화 포맷을 설정해둘 수 있습니다. 하이브는 빌트인 직렬화 포맷을 제공하여 압축이나 lazy deserializtion 등에 사용할 수 있습니다. 또한, custom SerDe를 만들어 사용할 수도 있습니다. 직렬화 포맷 설정은 테이블 카탈로그(또는 파티션에)에 설정되어 하이브 쿼리 수행 시 데이터에 접근할 때 자동적으로 사용하게 됩니다. 하이브는 HDFS, NFS, 로컬 디렉토리 등의 저장소를 지원합니다.

파티션

각 테이블은 여러 개의 파티션을 가질 수 있습니다. 이러한 파티션은 테이블 하위의 데이터의 분배와 위치를 결정하게 됩니다(주로 테이블 디렉토리의 subpath에 위치시킵니다). 테이블 T의 데이터가 /wh/T 디렉토리에 있다고 가정하고, ds와 ctry라는 컬럼이 파티션으로 사용된다면 /wh/T/ds=20090101/ctry=US 와 같은 형태로 파티션이 위치하게 됩니다.

파티션은 Data Scan을 줄여서 쿼리를 최적화하는데 큰 역할을 합니다. 위에서 SELECT * FROM T WHERE ds = 20090101 AND ctry = ‘US’ 와 같은 형태의 쿼리를 실행 시에, 해당 path의 파일만을 scan하기에 빠르게 실행될 수 있고, 리소스 사용량도 줄일 수 있게 됩니다.

버킷(Bucket)

각 파티션에 존재하는 데이터는 한 컬럼에 들어있는 값의 해쉬를 통해 버킷으로 나뉘어 질 수 있습니다. 만약 위의 파티션에서 다른 컬럼을 파티션으로 지속적으로 추가하게 된다면 너무 많은 파티션 디렉토리가 생성되게 됩니다. 그렇기에 사용자는 HQL의 ‘CLUSTER BY’ 구문을 사용해서 한 컬럼에서 같은 값을 가진 행들은 같은 버킷에 저장할 수 있습니다. 그리고 WHERE, JOIN 같은 구문에서 파티션의 최적화와 같이 해당 되는 파일만 읽어 Data Scan을 줄입니다.

뷰(View)

뷰는 논리적 데이터 구조로 쿼리의 복잡함을 줄여서 간단하게 만드는 기능을 합니다. ‘논리적’이라고 표현된 이유는 뷰는 HDFS(또는 저장소) 상에 어떠한 데이터를 추가하지 않고 오로지 metastore에만 정의되어 관리되기 때문입니다. 관계형 데이터베이스의 뷰와 달리, HQL의 뷰는 어떠한 데이터도 저장하지 않고 materialized되지 않습니다. 뷰가 생성되면, 스키마는 즉시 고정됩니다. 뷰가 기반하는 테이블의 변경은 뷰 스키마에 반영되지 않습니다. 그렇기에 의존하는 테이블이 삭제되거나 변경되고 뷰에 접근하면 뷰에 접근 시점에 실패가 발생하게 됩니다. 또한, 뷰는 Read-Only입니다.

위에서 대략적인 아파치 하이브의 개념을 이해하셨다면, 아래 글에서의 Hands-On을 통해 실제 어떻게 사용하는지 살펴보실 수 있겠습니다 🙂

Reference

[1] Hive – A Warehousing Solution Over a Map-Reduce Framework

[2] Apache hive introduction

[3] Apache Hive Essentials

[4] Wikipedia – Apache Hive

[5] Internal Hive

[6] Improving the performance of Hadoop Hive by sharing scan and computation tasks

[7] Hive Design

반응형

Apache Hive

Apache Hive

The Apache Hive ™ data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage using SQL. Structure can be projected onto data already in storage. A command line tool and JDBC driver are provided to connect users to Hive.

Getting Started With Apache Hive Software

Getting Involved With The Apache Hive Community

Apache Hive is an open source project run by volunteers at the Apache Software Foundation. Previously it was a subproject of Apache® Hadoop®, but has now graduated to become a top-level project of its own. We encourage you to learn about the project and contribute your expertise.

Apache Hive 개요 및 간단한 실습

■ 하이브(Apache Hive)

1) 하둡 이전의 (빅)데이터 분석업무를 맡은 사람들은 SQL등을 활용하여 업무를 수행했음

2) 하지만 하둡의 맵리듀스는 애플리케이션을 구현해야 처리 / 분석을 할 수 있었음

3) 그래서 기존의 데이터분석가를 위해 ‘페이스북’이 하이브를 개발

4) 현재는 하둡플랫폼으로 빅데이터를 처리하는 회사에서 다양하게 사용하였음

– 페이스북, 넷플릭스 등

■ 하이브(Apache Hive)의 개념

1) 하둡 데이터(파일)를 SQL과 비슷한 쿼리를 이용해서 다룰 수 있게 해줌

– 하이브QL 지원

2) DW(Data Warehouse) 어플리케이션에 적합

– 하둡의 기반으로 대량의 데이터를 배치 연산 가능

– 레코드 단위 갱신/삭제

– 트랜잭션 제한적인 지원(0.13 버전 이전에는 아예 지원을 안했음)

transaction = true 옵션

ORC format

– HiveQL로 분석, 데이터 작업은 용이하나 내부적으로는 Mapreduce로 변환되어 진행되기 때문에 빠른 처리는 불가능

■ 하이브 테이블

– RDBMS 테이블과 유사한 스키마를 가짐

– 파일 시스템의 파일을 테이블 데이터로 사용

– 테이블 종류

• 관리(managed)테이블 : 하이브가 관리하며 테이블 삭제 시 메타 정보와 파일 함께 삭제 됨

• 외부(external)테이블 : 테이블 생성 시 설정한 경로로 데이터를 저장하며 테이블 삭제 시 메타 정보만 삭제되고 데이터가 보존됨

– 하이브 데이터 타입

■ 예제

CentOS 7 에서 진행했으며, 당시 hive 버전은 3.1.2 입니다.

SK Big Data Hub(https://www.bigdatahub.co.kr/index.do)

– SK 텔레콤에서 수집한 데이터를 SK Big Data Hub 가입후 무료로 이용 가능

– CALL_CHICKEN_07MONTH.csv: 서울 지역 치킨집에 대한 한달 통화량을 기반으로 지역별 이용 현황 데이터를 제공

◦ 시도/시군구/읍면동: 이용자의 발신지역을 기준으로 서울지역 동단위까지 제공

◦ 연령대: 10세 단위로 6개 연령대(10대, 20대, 30대, 40대, 50대, 60대 이상)

◦ 통화건수: 이용자의 치킨집 통화건수(통화량 5건 미만은 5건으로 표시)

– 업로드한 csv파일에 따옴표와 컬럼명이 있다면 제거

#따옴표 제거

$ find . -name CALL_CHICKEN_07MONTH.csv -exec perl -pi -e ‘s/”//g’ {} \;

#맨 위 한줄 제거(컬럼명 제거)

$ sed -e ‘1d’ CALL_CHICKEN_07MONTH.csv > CALL_CHICKEN_07MONTH_new.csv

#파일 원래 이름으로 변경

$ mv CALL_CHICKEN_07MONTH_new.csv CALL_CHICKEN_07MONTH.csv

◦ find: 디스크에 저장된 파일/디렉터리 검색

◦ 문자열찾은 후 치환: find . -exec perl -pi -e ‘s/찾을문자열/바꿀문자열/g’ {} \;

◦ sed: 필터링과 텍스트를 변환하는 스트림 편집기

– 관리테이블 생성

CREATE TABLE 테이블명 (칼럼명 칼럼 타입, …)

COMMENT ‘테이블 설명’

ROW FORMAT DELIMITED

FIELDS TERMINATED BY ‘,’

LINES TERMINATED BY ‘

‘

STORED AS ‘파일 포맷형식’;

◦ CREATE TABLE 테이블명 (칼럼명 칼럼 타입, …) -> 테이블 만드는 최소 조건

◦ ROW FORMAT: 해당 테이블 내의 데이터가 어떤 형식으로 저장될지 설정

◦ 필드를 콤마 기준으로 구분(만약 필드가 탭으로 구분되어있다면: \t)

◦ 행과 행은

값으로 구분

◦ STORED AS: 데이터 저장 파일 포맷

◦ COMMENT: 테이블의 설명을 참고용으로 등록

◦ DBNAME: 데이터베이스명 -> 생략시 default DB 사용

– 하이브로 call_chicken_07month 테이블 생성

CREATE TABLE call_chicken_07month(sysdate STRING, dayOfWeek STRING, gender STRING, age STRING , city STRING , district STRING , town STRING, type STRING, calls INT) ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘,’ LINES TERMINATED BY ‘

‘ STORED AS TEXTFILE;

– 외부 테이블 생성(경로 커스텀)

CREATE EXTERNAL TABLE call_chicken_07month_ex(sysdate STRING, dayOfWeek STRING, gender STRING, age STRING , city STRING , district STRING , town STRING, type STRING, calls INT) ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘,’ LINES TERMINATED BY ‘

‘ STORED AS TEXTFILE LOCATION ‘/user/hadoop/call_chicken_07month’;

◦ EXTERNAL 키워드로 외부 테이블 생성

◦ LOCATION: 데이터를 저장할 경로 생성

◦ 외부 테이블은 Drop을 해도 데이터가 보존됨

◦ HDFS에서 외부테이블로 저장한 데이터 확인 가능

– 파티션 된 테이블

CREATE TABLE chicken_calls(sysdate STRING, dayOfWeek STRING, gender STRING, age STRING , city STRING , district STRING , town STRING, type STRING, calls INT) PARTITIONED BY (year string, month string) ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘,’ LINES TERMINATED BY ‘

‘ STORED AS TEXTFILE;

◦ PARTITIONED BY (파티션키 파티션타입): 테이블의 파티션 설정

◦ 파티션키는 해당 테이블의 새로운 칼럼으로 추가됨

◦ 하이브는 쿼리문의 수행 속도를 향상 시키기 위해 파티션 설정 가능

◦ 파티션을 설정하면 해당 테이블의 데이터를 파티션 별로 디렉터리 생성해 저장

◦ 아래의 사진은 생성된 테이블에 데이터를 로딩한 결과

■ 데이터 로드

– HDFS에서 테이터를 로딩

LOAD DATA INPATH ‘디렉터리 경로’ OVERWRITE INTO TABLE 테이블 명;

◦ LOAD DATA INPATH ‘디렉토리 경로’: 디렉토리에 포함된 모든 파일을 로딩

◦ OVERWRITE: 기존의 파일들을 삭제

– 로컬에서 데이터를 로딩

LOAD DATA LOCAL INPATH ‘디렉터리 경로’ OVERWRITE INTO TABLE 테이블 명;

◦ LOCAL: 로컬 파일을 테이블 데이터 경로에 로딩

– 파티션된 테이블에 데이터 로딩

LOAD DATA local INPATH ‘디렉토리 경로’

OVERWRITE INTO TABLE 테이블 명

PARTITION (파티션 키=’값’);

– 외부(로컬) 데이터를 하이브 테이블로 로딩하기

/home/bigdata/example_data/ 경로에 있는 CALL_CHICKEN_07MONTH.csv 업로드

LOAD DATA LOCAL INPATH ‘/home/bigdata/example_data/CALL_CHICKEN_07MONTH.csv’ OVERWRITE INTO TABLE call_chicken_07month;

– select로 call_chicken_07month 테이블의 데이터를 5개만 확인

SELECT sysdate, dayofweek, gender, age, city, district, town, type, calls FROM call_chicken_07month limit 5;

– 외부(로컬) 데이터를 하이브 파티션 테이블로 로딩하기 :

/home/bigdata/example_data/ 경로에 있는 CALL_CHICKEN_07MONTH.csv 업로드

LOAD DATA LOCAL INPATH ‘/home/bigdata/example_data/CALL_CHICKEN_07MONTH.csv’ OVERWRITE INTO TABLE chicken_calls PARTITION(year=’2019′, month=’07’);

– select로 chicken_calls 테이블의 데이터를 5개만 확인

SELECT sysdate, dayofweek, gender, age, district, calls, year, month FROM chicken_calls limit 5;

◦ 파티션 키(year, month)가 컬럼이 된 것을 확인

■ 테이블 지우기

– 테이블 구조 + HDFS에 저장된 데이터 모두 삭제

DROP TABLE [IF EXISTS] 테이블명;

[Hive] 하이브 이해하기

하이브(Hive)란 무엇인가

하둡 기반의 데이터 웨어하우스(DW, Data Warehouse) 솔루션으로 데이터 요약, 질의 및 분석 기능을 제공합니다. 하이브를 이용하면 HDFS(Hadoop Distributed File System)에 저장된 데이터에 SQL과 유사한 HiveQL이라는 쿼리를 날려 접근할 수 있습니다. 하이브는 맵리듀스(MapReduce)의 모든 기능을 지원하여 직접 맵리듀스를 작성하는 것보다 쉽게 구현할 수 있고, 쿼리를 빠르게 하는 비트맵 인덱스도 제공하고 있습니다. HDFS에 저장된 데이터를 수정할 수는 없지만 SQL에 익숙한 분석가들이 정형화된 대용량 데이터를 다루기에 유용한 솔루션이라고 합니다. 한마디로 대용량 정형화 데이터를 질의하고 그 결과를 생성하는 쿼리 엔진, “하둡의 SQL”이라고 할 수 있습니다.

하이브 로고. 벌치고는 코끼리스럽다.

+ 하둡(Hadoop)

대용량 데이터를 저장하고 분산처리하는 오픈소스 프레임워크입니다. 하나의 성능 좋은 컴퓨터를 이용하여 데이터를 처리하는 대신, 적당한 성능의 범용 컴퓨터 여러 대를 클러스터화하고, 큰 크기의 데이터를 클러스터에서 병렬로 동시에 처리하여 처리 속도를 높일 수 있습니다.

+ 맵리듀스(MapReduce)

구글에서 대용량 데이터 처리를 분산 병렬 컴퓨팅에서 처리하기 위한 목적으로 제작한 소프트웨어 프레임워크입니다. 대용량 데이터가 들어오면 적당한 크기의 블록으로 분할하고, 각 블록에 대해 Map Task와 Reduce Task를 진행합니다. 자세한 내용은 맵리듀스에 대한 좋은 포스팅이 있으니 참고 바랍니다.

하이브의 구성요소

하이브는 아래 구성요소들을 통해 쿼리를 구현합니다.

1. UI

분석가가 쿼리나 기타 작업들을 시스템에 제출하는 인터페이스

2. Driver

쿼리를 입력받고 작업을 처리하는 기능을 수행

3. Compiler

Metastore를 참고하여 쿼리 구문을 분석하고 실행계획을 생성

4. Metastore

하이브에서 사용하는 데이터베이스의 메타 정보들과 HDFS 매핑 정보를 저장

5. Execution Engine

Compiler에 의해 생성된 실행계획을 맵리듀스를 통해 구현하는 엔진

출처: https://wikidocs.net/23282 (7번과 9번이 바뀐 것 같습니다..)

하이브 실행순서

사용자가 커맨드라인을 통해 데이터베이스로 쿼리를 날립니다 드라이버가 컴파일러에게 쿼리플랜을 요청합니다 컴파일러는 메타스토어에서 쿼리를 작성하는 데에 필요한 메타정보를 받습니다 컴파일러가 메타정보를 바탕으로 쿼리를 어떻게 처리할 것인지를 쿼리플랜에 작성하고 드라이버에게 넘깁니다 드라이버는 Execution Engine에게 쿼리플랜을 전달합니다 쿼리플랜을 바탕으로 쿼리가 내부적으로 맵리듀스로 변환되어 작업을 수행합니다 Execution Engine이 맵리듀스 처리결과를 데이터 노드로부터 받고, 드라이버에게 이를 전달합니다. 드라이버는 사용자에게 결과를 전달합니다.

이상으로 하이브가 무엇인지, 어떻게 쿼리를 처리하는지 간단하게 알아보았습니다. 데이터 분석가로서 빅데이터 엔지니어링에 대한 이해 역시 필요하다는 생각에 (조금) 공부해본 내용을 기술했습니다. 저한테는 아직 어려운 개념들이라ㅎㅎ 잘못된 내용은 슬쩍 알려주시고, 궁금하신 점이 있으신 분들은 직접 서치해보시길 추천합니다. 읽어주셔서 감사합니다.🤓

참고

위키백과: 아파치 하이브

빅데이커 – 하둡, 하이브로 시작하기

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=kbh3983&logNo=220971216326

하이브 튜토리얼

1-하이브란?

하이브는 하둡 에코시스템 중에서 데이터를 모델링하고 프로세싱하는 경우 가장 많이 사용하는 데이터 웨어하우징용 솔루션입니다.

RDB의 데이터베이스, 테이블과 같은 형태로 HDFS에 저장된 데이터의 구조를 정의하는 방법을 제공하며, 이 데이터를 대상으로 SQL과 유사한 HiveQL 쿼리를 이용하여 데이터를 조회하는 방법을 제공합니다.

Hive 구성요소

하이브는 다음의 구성요소를 가지고 있습니다.

UI 사용자가 쿼리 및 기타 작업을 시스템에 제출하는 사용자 인터페이스 CLI, Beeline, JDBC 등

Driver 쿼리를 입력받고 작업을 처리 사용자 세션을 구현하고, JDBC/ODBC 인터페이스 API 제공

Compiler 메타 스토어를 참고하여 쿼리 구문을 분석하고 실행계획을 생성

Metastore 디비, 테이블, 파티션의 정보를 저장

Execution Engine 컴파일러에 의해 생성된 실행 계획을 실행

하이브 실행 순서

[BIGDATA Platform] 빅데이터 탐색 기술 : 하이브(Hive)

728×90

반응형

하이브(Hive)란?

: MapReduce는 복잡도가 높은 프로그래밍 기법이 필요했고, 이는 업무 분석가 및 관리자들에게 빅데이터에 접근하는 것을 어렵게 만들었습니다. 이를 해결하기 위해 페이스북에서 SQL과 매우 유사한 방식으로 하둡 데이터에 접근성을 높인 Hive 개발을 하게 되었습니다. 하둡에서 정형화된 데이터를 처리하기 위한 데이터 웨어하우스 인프라 입니다.

하이브 홈페이지 : hive.apache.org/

초기에는 페이스북에서 개발되었지만 넷플릭스등과 같은 회사에서 사용되고 있으며 개발되고 있으며, 오픈 소스로 공개되면서 2016년 2월 하이브 2.0이 릴리스되었습니다. (빅데이터의 가장 대표적인 SQL on Hadoop 제품으로 자리 잡음)

하이브(Hive) 수행 기능

1) 아파치 하이브는 아파치 HDFS이나 아파치 HBase와 같은 데이터 저장 시스템에 저장되어 있는 대용량 데이터 집합들을 분석합니다.

2) HiveQL 이라고 불리는 SQL같은 언어를 제공하며 맵리듀스의 모든 기능을 지원합니다.

3) 쿼리를 빠르게 하기위해 비트맵 인덱스를 포함하여 인덱스 기능을 제공합니다.

4) 하둡에서 동작하는 데이터 웨어하우스(Data Warehouse) 인프라 구조로서 데이터 요약, 질의 및 분석 기능을 제공합니다.

하이브(Hive) 주요 구성 요소

CLI : 사용자가 하이브 쿼리를 입력하고 실행할 수 있는 인터페이스 입니다.

JDBC / ODBC Driver : 하이브의 쿼리를 다양한 데이터 베이스와 연결하기 위한 드라이버를 제공 합니다.

Query Engine : 사용자가 입력한 하이브 쿼리를 분석해 실행 계획을 수립하고 하이브 QL을 맵리듀스 코드로 변환 및 실행 합니다.

MetaStore : 하이브에서 사용하는 테이블의 스키마 정보를 저장 및 관리하며, 기본적으로 더비DB(Derby DB)가 사용되나 다른 DBMS(MySQL, PostgreSQL 등)로 변경이 가능 합니다.

하이브(Hive) 의 기본 아키택처

– 하이브의 클라이언트는 CLI(Command Line interface : CLI), 하이브 서버, 웹 인터페이스로 구송됩니다. 하이브 서버의 경우 JDBC, ODBC, 쓰리프트로 개발된 클라이언트가 하이브 서비스를 이용할 수 있게 쓰리프트 서비스를 제공합니다.

– 하이브는 메타스토어(Metastore)라는 저장소를 만드어 하둡에서 처리된 메타데이터의 구조를 메타스토어에 저장합니다. 하이브는 오라클, MySQL등 JDBC를 지원하는 모든 데이터베이스를 이용하여 메타스토어를 구축할 수 있습니다.

– 드라이버는 사용자가 입력한 하이브QL 문을 해석합니다. 하둡과 연결되어 하이브QL 문을 실행하고, 하이브QL 은 하이브QL 문의 실행 계쇡을 작성하고, 최적화 작업까지 함께 수행합니다.

하둡x1 & Hive

Execute Query

– 사용자가 Hive web이나 커맨드라인을 통해 하이브 데이터베이스로 쿼리를 보냅니다. (데이터베이스와의 연결은 JDBC같은 아무런 드라이버나 사용가능)

↓

Get Plan

– 드라이버는 컴파일러에게 쿼리 플랜을 요청합니다. 쿼리 컴파일러는 쿼리를 받아서 쿼리를 어떻게 처리할 것인지 쿼리 플랜을 작성합니다.

↓

Get Metadata

– 쿼리 컴파일러는 Metastore로부터 쿼리를 처리하는데 필요한 메타정보를 받습니다.

↓

Send Plan

– 컴파일러는 쿼리 플랜을 작성해서 드라이버에게 전달합니다.

↓

Execute Plan

– 드라이버는 Execution Engine에게 쿼리 플랜을 전달합니다.

↓

Execute Job

– 이제부터는 쿼리가 내부적으로 맵리듀스 잡으로 변환되어 실행합니다. Execution Engine은 네임노드에 있는 JobTracker에게 잡을 전달하고, JobTracker는 데이터 노드에 있는 TaskTracker에게 잡을 임명합니다.

↓

Fetch Result

– Execution Engine은 맵 리듀스 처리 결과를 데이터노드로부터 받습니다.

↓

Send Results

– Execution Engine은 드라이버에게 데이터노드로 부터 받은 결과들을 전달합니다.

↓

Send Results

– 드라이버는 하이브 인터페이스에게 결과들을 전달합니다.

하둡x2 & Hive

UI : 사용자가 쿼리 및 기타 작업을 시스템에 제출하는 사용자 인터페이스 (CLI, Beeline, JDBC 등)

Driver : 쿼리를 입력받고 작업을 처리, 사용자 세션을 구현하고, JDBC/ODBC 인터페이스 API 제공

Compiler : 메타 스토어를 참고하여 쿼리 구문을 분석하고 실행계획을 생성

Metastore : 디비, 테이블, 파티션의 정보를 저장

Execution Engine : 컴파일러에 의해 생성된 실행 계획을 실행

사용자가 제출한 SQL문을 드라이버가 컴파일러에 요청하여 메타스토어의 정보를 이용해 처리에 적합한 형태로 컴파일

↓

컴파일된 SQL을 실행엔진으로 실행

↓

리소스 매니저가 클러스터의 자원을 적절히 활용하여 실행

↓

실행 중 사용하는 원천데이터는 HDFS등의 저장장치를 이용

↓

실행결과를 사용자에게 반환

728×90

반응형

아파치 하이브(Hive) 튜토리얼

하이브로 할 수 있는것?

하이브는 하둡 기반의 데이터웨어하우스 인프라이다. 하둡은 데이터 스토리지와 맵-리듀스 프로그램을 이용한 분산 처리를 위해 대량의 스케일 아웃을 제공하고 장애복구 위한 능력을 제공한다.

하이브는 데이터 요약을 좀더 쉽게 사용하기 위해서 설계 되었다. 그리고 대량의 데이터를 위한 동적 쿼리와 분석을 할 수 있다. 하이브는 Hive QL이라는 SQL 베이스의 쿼리를 제공해서 사용자가 쿼리를 좀더 쉽게 날리게 하고 데이터 분석과 요약을 좀더 쉽게 한다. 동시에 Hive QL은 전통적인 맵-리듀스 프로그래머들이 그들의 맵과 리듀스를 좀 더 쉽게 추가할 수 있게 할 수 있다. 이는 Hive QL의 기본 기능에서 제공하지 않는 좀 더 복잡한 데이터를 분석할 수 있게 끔 한다.

하이브로 할 수 없는것?

하둡은 배치 프로세스를 위한 시스템이고 하둡 잡은 많은 대기 시간이 필요하고 잡을 돌리고 스케쥴링 하는데 부가적인 오버헤드가 발생한다. 결과적으로 약간의 데이터를 가지고 온다고 해도 하이브 쿼리의 대기 시간은 몇 분 단위이다. (여기서는 몇 MB 단위이다). 결과적으로 중요하고 소량의 데이터를 보관하고 데이터를 분석하기 위해 이터레이션 도는 시간이 좀더 짧은 오라클과 같은 시스템과 비교하면 안된다. 하이브는 쿼리 시에 적절히 인내할 수 있는 시간을 제공하는 것을 목표로 한다.

하이브는 온라인 트랜젝션 프로세싱을 위해서 디자인 되지 않았다. 그리고 실시간 쿼리와 열단위 업데이터를 제공하지 않는다. 하이브는 웹로그 같은 엄청 큰 데이터이며 비정형 데이터를 배치로 수행하여 결과를 얻을 때 가장 좋다.

다음 부터는 데이터 타입과 테이블, 파티션과 같은 컨셉을 소개할 것이다. 이는 전통적인 RDBMS와 유사한 개념이다. 그리고나선 예제를 가지고 QL언어의 사용방법을 배워보도록 할 것이다.때

데이터 단위

작은단위 순서대로 하이브 데이터는 다음과 같이 구성되어 있다.

* 데이터베이스 : 네이밍 충돌을 피하기 위해서 테이블과 다른 데이터 단위들과 분리된 네임스페이스이다.

* 테이블: 같은 스키마를 가진 데이터의 동종(Homogeneous) 단위. 예를 들어 페이지 다음의 스키마를 가진 페이지 뷰 테이블을 들 수 있다.

– timestamp : 페이지를 보았을 때 유닉스 타임스탬프에 상응하는 int 형 타입이다.

– userid : 페이지를 본 유저의 식별값을 bigint 형 타입이다.

– page_url : 페이지의 위치에 대한 string 타입이다.

– referer_url : 사용자가 어는 경로를 통해사 해당 위치에 접근했는지에 대한 경로위치를 표한한 string 타입니다.

– IP : 페이지에 접속요청한 IP 주소에 대한 string 타입 문자열

* 파티션 : 각 테이블은 한개 이상의 파티션 키를 가지고 있다. 파티션 키는 어떻게 데이터가 저장되는지 결정하는 역할을 한다. 파티션 – 저장 단위와는 거리가 좀 있다 – 은 어떤 기준에 적합한 로우(rows)를 식별하는데 효율 적이다. 예를 들어 string 타입의 날짜 파티션과 string 타입의 나라 파티션이 있다고 하자. 파티션 키의 유일한 값들은 테이블의 파티션을 정의한다. 예를 들어 “2009-12-23″의 모든 “US”는 페이지 뷰 테이블의 파티션이다. 그러므로 2009-12-23일에 “US” 데이터만 검색하고 싶은 경우엔 단지 관련된 테이블만 뒤져서 쿼리를 수행하기 때문에 분석할 때 좀 더 빠른 분석을 할 수 있다. 파티션이 2009-12-23으로 되어 있다는게 해당 날짜의 모든 데이터를 가지고 있거나 한개의 데이터만 가지고 있다는 것을 의미하진 않는다. 파티션들은 편의상 날짜 뒤에 이름이 붙는다. 그러나 파티션 이름과 내용 사이에는 어떤 관계가 있다는 것만은 보장한다. 파티션 컬럼은 수직 컬럼들이다. 이 컬럼들은 데이터의 일부는 아니지만 로드 되면서 추출된다.

* 버켓(Buckets)(또는 클러스터) : 각각 파티션의 데이터는 차례로 테이블의 어떤 컬럼들의 해쉬 함수의 값에 기반하여 버켓안에 나뉘어서 들어간다. 예를 들어 페이지 뷰 테이블은 userid에 의해서 버켓팅 될수 있다. 이들은 효율적으로 데이터를 샘플링 하는데 사용된다.

파티셔닝이나 버케팅은 테이블을 위해서 필요한게 아니다. 이런 추상화 개념들은 시스템이 좀 더 빠른 쿼리 처리속도를 위해서 불필요한 데이터를 제거하기 위한 목적으로 사용된다.

* 원시 타입(Primitve Types)

타입은 테이블의 컬럼과 관련이 있다. 다음은 지원되는 원시 타입니다.

Integers

TINYINT – 1 byte integer

SAMLLINT – 2 byte integer

INT – 4 byte integer

BIGINT – 8 byte integer

Boolean type

BOOLEAN – TRUE/FALSE

Floating point numbers

FLOAT – single precision

DOUBLE – Double precision

String type

STRING – 문자열

위의 타입들은 다음 계측구조로 되어있다.

Type

Primitive Type

Number

DOUBLE

BIGINT

INT

TINYINT

FLOAT

INT

TINYINT

STRING

BOOLEAN

이 타입 계층구조는 쿼리 언어에서 어떻게 묵시적으로 변경될 수 있는지 보여준다. 자식의 타입에서 조상의 타입으로는 묵시적 컨버전이 일어난다. 그래서 쿼리문장이 type1을 호출하고 데이터가 type2를 가지고 있는 경우에 type1이 type2의 조상이면 묵시적으로 컨버전 된다. 이외에도 시스템은 묵시적으로 변환할 수 있는 방법이 있다. 하이브는 타입 변환을 위해 다음을 제공한다.

– to

* 복합 타입(Complex Type)

복합 타입(Complex Type)은 원시 타입이나 다른 복잡한 타입에서 만들어 졌다.

– Structs : 쩜(.) 기호를 이용해서 이 타입을 접근할 수 있다 예를 들어 STRUCT {a INT; b INT} c 의 a 에는 c.a 로 접근할 수 있다.

– Maps(key-value 튜플) : [‘엘리먼트 이름’] 기호로 접근할 수 있다. 예를 들어 M 맵에 ‘group’->gid 라는 gid 값에 접근해야 하는 겨우에는 M[‘group’] 으로 접근 할 수 있다.

– Arrays(인덱스된 리스트) : 이 배열의 엘리먼트는 동일한 타입을 가진다. 엘리먼트는 [n] 기호를 사용해서 접근할 수 있다. n은 (0부터 시작하는 ) 배열의 n 번째 인덱스이다. 예를 들어 [‘a’,’b’,’c’,’d’]를 가진 배열 A에서 A[1]을 호출하면 b를 리턴한다.

기본타입과 복잡타입의 생성자를 이용해서 임의의 중첩된 레벨을 타입들을 만들어 낼 수 있다.

내장 연산자와 함수

내장 연산자

관계형 연산자 – 다음표의 연산자는 인자와 비교하고 피연산자들과 비교하여 TRUE 또는 FALSE 값을 리턴한다.

관계형

연산자 피연산자타입 설명

A = B 모든기본타입 A와 B가 같으면 TRUE 아니면 FALSE

A != B 모든기본타입 A와 B가 같으면 FALSE 아니면 TRUE

A < B 모든기본타입 A가 B보다 작으면 TRUE 아니면 FALSE A <= B 모든기본타입 A가 B보다 작거나 같으면 TRUE 아니면 FALSE A > B 모든기본타입 A가 B보다 크면 TRUE 아니면 FALSE

A >= B 모든기본타입 A가 B보다 크거나 같으면 TRUE 아니면 FALSE

A IS NULL 모든타입 A가 NULL이면 TURE 아니면 FALSE

A IS NOT NULL all types A가 NULL이 아니면 TURE 아니면 FALSE

A LIKE B strings 문자열 A가 SQL 정규 표현인 B와 매치되면 TRUE, 아니면 FALSE. B문자열 안에 _ 문자를 이용하여 A의 어느 특정 문자와 비교할 수 있다. posix . 과 같고 오라클 _ 과도 같다. B에 % 문자열을 이용하여 임의의 문자를 모두 비교할 수 있다. posix의 * 와 같고 오라클의 %과 같다. 예를 들어 ‘foobar’ like ‘foo’는 FALSE 리턴하고 ‘foobar’ LIKE ‘foo___’ 는 TRUE를 리턴한다. ‘foobar’ LIKE ‘foo%’는 TRUE 리턴한다. 는 이스케이프 문자열이다. 예를 들어 ;를 문자열에 포함시켜 검색하고 싶으면 value LIKE ‘a;b’ 로 검색해야 한다.

A RLIKE B strings A가 자바 정규 표현식 B와 매칭되면 TRUE를 리턴하고 아니면 FALSE를 리턴한다.예를 들어 ‘foobar’ rlike ‘foo’ 는 FALSE를 반환한다. ‘foobar’ rlike ‘^f.*r$’은 TRUE를 리턴한다.

A REGEXP B strings RLIKE와 동일

산수 연산자 – 다음 연산자는 일반적인 산수 연산자 이다. 아래 표의 모든 연산자는 숫자를 리턴한다.

산수

연산자 연산자타입 설명

A + B 모든숫자타입 A와 B를 합한 결과를 리턴한다. float + int = float 이다.

A – B 모든숫자타입 A에서 B를 뺀 결과를 리턴한다.

A * B 모든숫자타입 A와 B를 곱한 결과를 리턴한다. 결과의 타입은 연산자의 계층 구조 상 부모와 동일 하다. 곱하기 결과 오버플로우가 나면 계층상 더 높은 것으로 타입 변환할 수 있다.

A / B 모든숫자타입 A를 B로 나눈 결과를 리턴한다. 결과의 타입은 연산자의 계층 구조 상 부모와 동일 하다. 피연산자가 integer 타입이면 결과는 나누기의 몫을(?) 리턴한다.

A % B 모든숫자타입 A를 B로 나눈 나머지를 리턴한다.

A & B 모든숫자타입 A와 B사이에 비트 AND 연산을 한다.

A | B 모든숫자타입 A와 B사이에 비트 OR 연산을 한다.

A ^ B 모든숫자타입 A와 B사이에 비트 XOR 연산을 한다.

~A 모든숫자타입 A에 비트 NOT 연산을 한다.

논리 연산자 – 이는 논리 연산을 지원한다. 모든 리턴 값은 TRUE 또는 FALSE이다.

논리연산자 연산자타입 설명

A AND B boolean A와 B가 모두 TRUE 이면 TRUE, 아니면 FALSE

A && B boolean A AND B와 동일

A OR B boolean A 또는 B 또는 모두가 TRUE 이면 TRUE, 아니면 FALSE

A | B boolean A OR B와 동일

NOT A boolean A가 FALSE이면 TRUE

!A boolean NOT A와 같다.

복잡타입의 연산자 – 다음 연산자는 복잡 타입의 엘리먼트에 접근하기 위해서 사용된다.

Operator Operand types Description

A[n] A는배열 n은인덱스 배열 A의 n번째 엘리먼트를 리턴한다. 첫번째 엘리먼트는 0이다.

M[key] M은Map key의 타입은 K 맵에 key 에 해당하는 값을 리턴한다. 만일 M이

{‘f’ -> ‘foo’, ‘b’ -> ‘bar’, ‘all’ -> ‘foobar’} 이면 M[‘all’]이라고 하면 ‘foobar’를 리턴한다.

S.x S는struct struct S의 x 필드를 리턴한다. 예를 들어 struct foobar {int

foo, int bar} 에서 S의 필드 x에 접근하려고 하면 foobar.foo 로 하면 foo 필드가 저장된 인덱스를 반환 한다.

내장 함수들

다음의 하이브에서 지원하는 내장 함수들이다.

타입 함수명(인자) 설명

-BIGINT round(double a) a 값에 대한 반올림 BIGINT를 반환한다.

-BIGINT floor(double a) a값보다 작거나 같은 최대 BIGINT 값을 반환한다.

-BIGINT ceil(double a) a 보다 크거나 같은 최소한의 BIGINT 값을 리턴한다.

-double rand(), rand(int seed) 난수를 반환한다.

-string concat(string A, string B,…) A문자열 뒤에 B 문자열을 붙여서 리턴한다. 예를 들어 concat(‘foo’,’bar’)를 수행하면 ‘foobar’를 리턴한다.

-string substr(string A, int start) 시작위치 start에서 A문자열의 끝까지 A문자열의 서브 문자열을 반환 한다. 예를 들어 substr(‘foobar’,4)는 ‘bar’를 리턴한다.

-string substr(string A, int start, int length) 시작위치 start에서 지정된 위치까지 A문자열의 서브 분자열을 반환한다. 예를 들어 substr(‘foobar’,4,2) 라고 하면 ‘ba’를 리턴한다.

-string upper(string A) 문자열 A의 모든 문자를 대문자로 리턴한다. 예를 들어 -upper(‘fOoBaR’)는 ‘FOOBAR’를 리턴한다.

-string ucase(string A) upper와 동일하다.

-string lower(string A) 문자열 A의 모든 문자열을 소문자로 반환 한다. 예를 들어 llower(‘fOoBaR’) 는 ‘foobar’를 리턴한다.

-string lcase(string A) lower와 동일하다.

-string trim(string A) 문자열 A의 양쪽에 있는 공간들을 제거한다. 예를 들어 trim(‘ foobar ‘) 은 ‘foobar’을 리턴한다.

-string ltrim(string A) 문자열 A의 왼쪽에 공백을 제거한다. 예를 들어 ltrim(‘ foobar ‘) 은 ‘foobar’을 리턴한다.

-string rtrim(string A) 문자열 A의 오른쪽의 공백을 제거한다. 예를 들어 rtrim(‘ foobar ‘) 는 ‘ foobar’를 리턴한다.

-string regexp_replace(string A, string B, string C) 정규식 C와 매칭되는 문자열 B의 모든 문자들을 대체하여 리턴한다. 예를 들어 regexp_replace(‘foobar’, ‘oo|ar’, ) 은 ‘fb’을 리턴한다.

-int size(Map) 맵 타입의 엘리먼트의 갯수를 반환한다.

-int size(Array) 배열 타입의 엘리먼트의 갯수를 반환한다.

-value of cast( as) 표현식 expr을 type으로 타입변환을 한다. 예를 들어 cast(‘1’ as BIGINT)은 ‘1’을 BIGINT로 변환하여 반환한다. 컨버전이 실패하면 null을 리턴할 것이다.

-string from_unixtime(int unixtime) 유닉스 타입의 시간(1970-01-01 00:00:00 UTC)을 현재 시스템의 시간대에 맞게 변환해 준다.

-string to_date(string timestamp) 타임스탬프 중에서 날짜만 리턴한다 예를 들어 to_date(“1970-01-01 00:00:00”) = “1970-01-01”

-int year(string date) 타임스탬프 중에서 년도만 리턴한다. 예를 들어 year(“1970-01-01 00:00:00”) = 1970, year(“1970-01-01”) = 1970

-int month(string date) 타임스탬프 중에서 월만 리턴한다. 예를 들어 month(“1970-11-01 00:00:00”) = 11, month(“1970-11-01”) = 11

-int day(string date) 타임스탬프 중에서 일만 리턴한다. 예를 들어 day(“1970-11-01 00:00:00”) = 1, day(“1970-11-01”) = 1string get_json_object(string -json_string, string path) 지정된 json 패스에서 json 문자열로부터 json 객체를 추출하고 json 스트링을 반환한다. 만약 json이 유효하지 않으면 null 을 리턴한다.

하이브 집계 함수들

리턴타입 집계함수(인자) 설명명

– BIGINT count(*), count(expr), count(DISTINCT expr[, expr_.]) -count(*) – 모든 row의 갯수를 반환한다. null 값 포함해서 리턴

count(expr) – 지정된 정규식에 맞는 row 갯수를 반환한다.

count(DISTINCT expr[, expr]) – 지정된 표현식의 row 개수들을 리턴한다. 여기서 지정된 표현식의 row는 유일해야 하면 not null이어야 한다.

– DOUBLE sum(col), sum(DISTINCT col) 그룹안의 엘리먼트의 합계를 반환하거나 그룹안에서 distinct 값으로 합계를 내어 반환한다.

– DOUBLE avg(col), avg(DISTINCT col) 그룹 내에서 값들의 평균값을 반환하거나 그룹 안에서 distinct 값으로 평균을 내어 반환한다.

– DOUBLE min(col) 그룹 내에서 최소값을 반환한다.

-DOUBLE max(col) 그룹 내에서 최대값을 반환한다.

테이블 만들기

이 예제 쿼리문은 위에서 언급한 페이지 뷰 테이블이다.

CREATE TABLE page_view(viewTime INT, userid BIGINT,

page_url STRING, referrer_url STRING,

ip STRING COMMENT ‘IP Address of the User’)

COMMENT ‘This is the page view table’

PARTITIONED BY(dt STRING, country STRING)

STORED AS SEQUENCEFILE;

이 예제에서 테이블의 컬럼들은 타입들이 지정되었다 커멘트는 오라클처럼 컬럼이나 테이블 레벨에 붙일 수 있다. 추가적으로 PARTITIONED BY 절로 파티셔닝 컬럼을 정의 하였다. 이 파티셔닝 컬럼은 데이터컬럼과 다르고 데이터와 같이 저장되지 않는다. 이렇게 파티셔닝을 지정하게 되면 파일 내의 데이터는 ASCII(ctrl-A)의 필드 구분자로, row 구분자로 n 을 사용한다.

아래의 예에서 보듯이 아래의 예처럼 필드 구분자를 파라미터로 던질 수 있다.

[snippet slug=page_view-1 lang=sql]

Hadoop에서 결정하기 때문에 row 구분자는 현재 변경할 수 없다.

또한 테이블의 어떤 컬럼들을 버켓에 담는 것은 좋은 생각이다. 이렇게 함으로써 샘플링 쿼리들을 실행 할 수 있다. 버케팅을 하지 않으면 무작위로 테이블에 대하여 샘플링하게 되고 이렇게 되면 쿼리가 모든 데이터를 스캔 하기 때문에 효율적이지 않다. 다음 예는 userid 컬럼으로 버켓팅된 page_view 테이블을 보여준다.

[snippet slug=page_view-2 lang=sql]

위의 예제에서는 테이블은 userid를 32개의 버켓으로 해쉬 함수에 의해서 클러스터 된다. 각각 버켓안에 데이터는 viewTime컬럼 정렬되서 저장된다. 이렇게 하면 사용자가 클러스터된 컬럼에서 샘플링 데이터를 뽑을 때 효율적으로 할 수 있게 한다. 이렇게 정렬하게 되면 쿼리할 때 효율적으로 할 수 있도록 좀 더 좋은 데이터 구조를 이용할 수 있게 한다.

[snippet slug=page_view-3 lang=abap]

이 예에서 테이블row를 구성하는 컬럼은 타입을 정의하는 방법과 유사하게 지정하면 된다. 커멘트는 컬럼과 테이블에 동시에 추가할 수 있고 추가적으로 partitioned by 절을 이용해서 파티셔닝 컬럼을 정의한다. 이 파티셔닝 컬럼은 데이터와 같이 저장되지 않는다. CLUSTERD BY 정을 지정함으로써 버케팅을 위한 컬럼을 지정할 수 있다. DELIMITED ROW FORMAT은 열이 hive 테이블에 어떻게 저장되는지 지정할 수 있다. 이는 필드가 어떻게 끝날지 지정하고 배열이나 맵 같은 콜렉션의 아이템이 어떻게 끝나는지 지정한다. SORTED AS SEQUENCEFILE은 Hadoop의 SequenceFile포멧으로 데이터가 바이너리 포멧으로 저장되어 있음을 의미한다. 위 예제에서 ROW FORMAT과 STORED AS의 값은 시스템의 기본값을 나타낸다.

테이블과 파티션의 탐색

SHOW TABLES;

데이터베이스에 있는 테이블의 목록을 출력한다.

SHOW TABLES ‘page.*’;

테이블이름이 page로 시작하는 모든 테이블의 목록을 출력한다. 자바의 정규 표현식을 사용하면 된다.

SHOW PARTITIONS page_view;

테이블의 파티션들을 보여준다. 테이블이 파티션되지 않았다면 에러가 던저진다.

DESCRIBE page_view;

테이블의 컬럼과 컬럼타입을 출력한다.

DESCRIBE EXTENDED page_view;

컬럼과 테이블의 다른 추가적인 속성을 보여준다. 이는 디버깅을 위해서 주로 사용된다.

DESCRIBE EXTENDED page_view PARTITION (ds=’2008-08-08′);

파티션의 컬럼의 목록과 다른 속성 모두의 목록을 출력한다. 디버깅의 목적으로 주로 사용된다.

데이터의 적재

하이브에 데이터를 올리기 위해서는 여러가지 방법이 있다. 사용자는 HDFS에 저장된 특정 위치를 지정하여 external 테이블로 만들 수 있다. 이렇게 사용함으로써 사용자는 파일을 HDFS의 put, copy 커맨드를 사용하여 특정 위치에 저장할 수 있고 관계된 row 포멧 정보를 가지고 이 위치를 지정하여 테이블을 만들 수 있다. 이렇게 하면 사용자는 데이터를 옮길 수 있고 Hive 테이블에 데이터를 입력 할 수 있다. 예를 들어 파일이 /tmp/pv_2008-06-08.txt가 , 구분자로 2008-06-08일의 페이지 뷰가 들어가 있고 page_view 테이블로 데이터를 적재하려고 할 때에 다음의 명령어로 실행하면 된다.

[snippet slug=page_view_stg-1 lang=sql]

위의 예제에서 테이블의 맵타입과 배열타입을 나중에 삽입하기 위해서 null로 넣었다. 이는 추후 외부테이블에서 적절한 row 포멧이 지정되면 사용될 것이다.

이 메소드는 HDFS의 레거시 데이터가 존재하는 경우에 유용하다. 레거시 데이터는 사용자가 메타데이터를 집어넣어 데이터가 하이브에서 쿼리될 수 있는 것을 의미하낟.

추가적으로 시스템은 로컬시스템에서 직접 파일을 하이브테이블로 직접 로드할 수 있는 문법도 같이 제공한다. 이럴 경우 파일의 row 포멧은 하이브 테이블의 포멧과 일치해야한다. 예를 들어 /tmp/pv_2008_09_08_us.tx 파일 중에서 US 데이터가 이미 있다면 이전 예제에서 보듯이 추가적으로 필터링할 필요는 없다. 다음 문법을 이용해서 그대로 업로드 하면 될 것 같다.

LOAD DATA LOCAL INPATH /tmp/pv_2008-06-08_us.txt INTO TABLE page_view PARTITION(date=’2008-06-08′, country=’US’)

INPATH에 디렉토리를 기술하면 디렉토리의 모든 파일이 로그된다. 파일 한개거나 와일드 카드를 사용하는 경우에는 매칭되는 파일만 로드된다. 디렉토리 인경우에는 서브 디렉토리는 같이 로드 되지 않는다.

/tmp/pv_2008-06-08_us.txt 파일이 너무크면, 사용자는 데이터를 병렬로 로드할 것인지를 결정할 수 있다. HDFS에 있는 파일을 로드할 때 다음의 문법을 이용해서 데이터를 로드할 수 있다.

LOAD DATA INPATH ‘/user/data/pv_2008-06-08_us.txt’ INTO TABLE page_view PARTITION(date=’2008-06-08′, country=’US’)

여기서 input.txt 파일은 배열이나 맵에는 null 필드가 들어가게된다.

간단한 쿼리

접속된 모든 사용자를 가지고 오는 쿼리이다.

[snippet slug=user_active-1 lang=sql]

SQL과 같지 않게 우리는 항상 이 결과를 테이블에 삽입한다. 이 결과를 어떻게 조회하고 로컬 파일로 내리는지는 추후 다시 배울 것이다. Hive CLI를 이용해 다음 쿼리를 실행하자.

[snippet slug=select-1 lang=sql]

이는 내부적으로 임시파일에 결과를 쓰고 Hive 클라이언트에 보여준다.

파티션 기반의 쿼리

쿼리할 때 필요한 파티션은 where 조건의 파티션 컬럼의 상태에 기본하여 자동적으로 시스템이 결정한다. 예를 들어 03/2008과 도메인 xyz.com 에서 들어온 페이지의 경우에 해당되는 page_views테이블의 모든 내용을 조회할 경우 다음 쿼리를 사용하면 된다.

[snippet slug=xyz_com_page_views-1 lang=sql]

테이블에 PARTITION BY(date DATETIME, county STRING) 으로 정의되었기 때문에 page_view.date는 여기서 사용된다.

JOINS

인구통계학적으로 분석하기 위해서 2008-03-03의 페이지뷰를 조사하는 경우, page_view 테이블과 사용자 테이블의 userid 컬럼을 조인할 필요가 있다. 이는 다음의 쿼리로 실행하면 된다.

INSERT OVERWRITE TABLE pv_users

SELECT pv.*, u.gender, u.age

FROM user u JOIN page_view pv ON (pv.userid = u.id)

WHERE pv.date = ‘2008-03-03’;

아우터 조인을 위해서 LEFT OUTER, RIGHT OUTER 또는 FULL OUTER 키워드를 사용하면 된다. 이 한정자들은 좌측 보존(preserved), 우측 보존, 전체 보존을 지정한다. 예를 들어 위의 쿼리에서 풀 아우터 조인을 하는 경우 다음의 쿼리를 참조하면 된다.

INSERT OVERWRITE TABLE pv_users

SELECT pv.*, u.gender, u.age

FROM user u FULL OUTER JOIN page_view pv ON (pv.userid = u.id)

WHERE pv.date = ‘2008-03-03’;

다른 테이블의 키의 존재여부를 체크하기 위해서는 사요자는 LEFT SEMI JOIN을 사용할 수 있다. 이는 다음의 예제에 있다.

INSERT OVERWRITE TABLE pv_users

SELECT u.*

FROM user u LEFT SEMI JOIN page_view pv ON (pv.userid = u.id)

WHERE pv.date = ‘2008-03-03’;

한개 이상을 조인하기 위해서는 다음의 예제를 살펴보면된다.

INSERT OVERWRITE TABLE pv_friends

SELECT pv.*, u.gender, u.age, f.friends

FROM page_view pv JOIN user u ON (pv.userid = u.id) JOIN friend_list f ON (u.id = f.uid)

WHERE pv.date = ‘2008-03-03’;

Hive의 경우에는 동등-조인(equijoin)만 지원한다. 또한 오른쪽 편에 큰테이블을 집어놓고 조인하는 것이 성능에 좋다.

집합(Aggregations)

성별에 의해서 구별되는 사용자 아이디의 개수를 구하기 위해서는 다음의 쿼리를 사용하면 된다.

INSERT OVERWRITE TABLE pv_gender_sum

SELECT pv_users.gender, count (DISTINCT pv_users.userid)

FROM pv_users

GROUP BY pv_users.gender;

여러개의 집합을 동시에 사용할 수 있다. 다른 DISTINCT 컬럼에 여러개의 집합 함수를 사용할 수 없다. 그러나 다음의 케이스는 가능하다.

INSERT OVERWRITE TABLE pv_gender_agg

SELECT pv_users.gender, count(DISTINCT pv_users.userid), count(*), sum(DISTINCT pv_users.userid)

FROM pv_users

GROUP BY pv_users.gender;

그러나 다음 쿼리는 허용되지 않는다.

INSERT OVERWRITE TABLE pv_gender_agg

SELECT pv_users.gender, count(DISTINCT pv_users.userid), count(DISTINCT pv_users.ip)

FROM pv_users

GROUP BY pv_users.gender;

여러 테이블/파일 삽입

집합함수의 출력물이나 간단한 select문의 출력물이나 여러개의 테이블로 보낼 수 있다. 뿐만아니라 hadoop dfs 파일로도 보낼 수 있다. 이럴 경우에는 hdfs의 유틸리트를 사용해야한다. 만약 성별 분석과 함께, 나이에 따른 페이지 뷰 분석이 필요할 경우도 있다. 이럴 경우 다음 쿼리를 사용하면 된다.

FROM pv_users

INSERT OVERWRITE TABLE pv_gender_sum

SELECT pv_users.gender, count_distinct(pv_users.userid)

GROUP BY pv_users.gender

INSERT OVERWRITE DIRECTORY ‘/user/data/tmp/pv_age_sum’

SELECT pv_users.age, count_distinct(pv_users.userid)

GROUP BY pv_users.age;

첫번째 insert 문은 Hive 테이블에 첫번째 group by의 결과를 보낸다. 반면에 두번째 group by의 결과는 hadoop dfs로 보낸다.

동적-파티셔닝 삽입

이전 예제에서 사용자는 삽입하고자 하는 파티션을 알고 있고 한개의 insert문은 한개의 파티션만 사용할 수 있다. 여러개의 파티션을 로드하기 위해서는 여러개의 insert문을 사용해야 한다.

FROM page_view_stg pvs

INSERT OVERWRITE TABLE page_view PARTITION(dt=’2008-06-08′, country=’US’)

SELECT pvs.viewTime, pvs.userid, pvs.page_url, pvs.referrer_url, null, null, pvs.ip WHERE pvs.country = ‘US’

INSERT OVERWRITE TABLE page_view PARTITION(dt=’2008-06-08′, country=’CA’)

SELECT pvs.viewTime, pvs.userid, pvs.page_url, pvs.referrer_url, null, null, pvs.ip WHERE pvs.country = ‘CA’

INSERT OVERWRITE TABLE page_view PARTITION(dt=’2008-06-08′, country=’UK’)

SELECT pvs.viewTime, pvs.userid, pvs.page_url, pvs.referrer_url, null, null, pvs.ip WHERE pvs.country = ‘UK’;

특정일에 데이터를 모든 ccountry 파티션으로 삽입하기 위해서는 입력 데이터의 각각 country의 insert문을 추가해야한다. 이는 이미 입력하는 국가의 목록을 이미 알 고 있다는 전제하에 미리 파티션을 만들어 놔야 하기 때문에 엄청 불편하다. 다른날에 국가의 리스트가 변경될 경우 insert DML을 변경해야 한다. create DDL도 바꾸어야 한다. 또한 각각의 insert 문이 MapReduce Job으로 변경되기 때문에 불편하다.

동적-파티셔닝 insert (또는 멀티 파티션 insert)는 이러한 문제를 해결하기 위해서 등장 했다. 테이블을 스캐닝하여 어느파티션을 만들고 어느 파티션을 채울지 동적으로 결정한다. 이는 0.60 버전에서 새로 추가된 기능입니다. 동적-파티셔닝 삽입에서는 값을 입력할 때 이 row가 어떤 파티셔닝에 삽입되어야 하는지 결정된다. 만약 파티셔닝이 없다면 자동적으로 파티션을 만들 것이다. 이러한 기능을 사용하기 위해서는 모든 필요한 파티션을 만들고 채우기 위해서는 한개의 insert 문만 사용해야 한다. 추가적으로 한개의 insert문이기 때문에 한개의 MapRedcue잡만 돈다. 이는 성능향상에 중요한 요소이고 여러개의 insert 문을 사용할 때에 비하여 Hadoop 클러스터의 부하를 감소시킬 수 있다.

아래에는 한개의 insert문으로 모든 나라의 파티션에 데이터를 로딩하는 예이다.

FROM page_view_stg pvs

INSERT OVERWRITE TABLE page_view PARTITION(dt=’2008-06-08′, country)

SELECT pvs.viewTime, pvs.userid, pvs.page_url, pvs.referrer_url, null, null, pvs.ip, pvs.country

다중-삽입 구문에는 몇가지 중요한 차이가 있다.

– PARTITION 명세에 country가 나타나긴 하지만 값이 할당되어 있지 않다. country는 동적 파티셔닝 컬럼이다. 다른 한편으로 ds(?)는 값이 할당되어 있다. 이는 정적 파티셔닝 컬럼을 의미한다. 컬럼이 동적 파티셔닝 컬럼이면 이 값은 입력 컬럼에서 온다. 현재 위 쿼리문 에서 동적 파티셔닝을 마지막 열에만 하라고 지시 하였다. 왜냐하면 파티션 컬럼의 순서는 계층 구조를 의미한다. 즉 dt는 루트 파티션이고 country는 그 아래 자식 파티션이다. 여기서 이 의미는 country가 ‘US’인 서브 파티션 모두를 업데이트 한다는 의미이기 때문에 우리는 파티션 절에서 dt, country=’US’로 지정할 수 없다.

– 추가적으로 select 문에 pvs.country 컬럼을 추가하였다. 이는 동적 파티셔닝 컬럼과 들어오는 데이터의 형태를 맞추기 위해서이다. 정적인 파티셔닝 컬럼에서는 PARTITION 절에서 이 값은 이미 알고 있기 때문에 동적-파티셔닝에서 처럼 구지 세팅할 필요가 없다. 동적-파티셔닝 값은 이름이 아닌 순서에 의해 선택된다. 그리고 select 절의 마지막 컬럼이 된다.

insert 문의 동적 파티셔닝 문법

-다이나믹 파티셔닝 컬럼에 비어있지 않는 파티션이 존재할 경우에(예를들어 country=’CA’ 는 ds 루트 파티션에 이미 있는 경우) 들어온 데이터 중에 동일한 값이 있으면 덮어쓸 것이다. 이는 ‘삽입은 덮어쓰기’와 유사하다는 걸 의미한다.그러니 ‘CA’가 입력 데이터 중에 없으면 덮어쓰지 않을 것이다.

-Hive 파티션은 HDFS의 디렉토리와 동일하기 때문에 파티션 값은 HDFS 경로 형식에 부합해댜 한다.(JAVA URI). URI의 특별한 의미를 갖는 문자(예:%,;,/,#) 등은 이스케이프 문자열 % 뒤에 2바이트의 아스키 문자로 표현된다.

-STRING과 다른 타입의 입력 컬럼인 경우 이 값은 STRING으로 변환된다. 이는 HDFS의 경로로 만들어진다. (?)

– 입력 컬럼의 값이 NULL이거나 빈 문자열 인경우 row는 특별한 파티션으로 이를 보낸다. 이 파티션은 hive.exec.default.partition.name에 의해서 지정된다. 이 기본 값은 _HIVE_DEFAULT_PARTITION_이다. 기본적으로 파티션은 파티션의 이름과 맞지 않는 “bad” row를 가지고 있다. 이 값들은 손실될 위험이 있고 그 값들을 HIVE로 선택하게 되면 _HIVE_DEFAULT_PARTITION_으로 대체 된다.

– 동적 파티션 입력은 잠재적인 리소스 엄청나게 잡아 먹는 돼지가 될 수도 있다. 짧은 시간에 엄청나게 많은 파티션이 만들어질 수 있다. 이런현상을 막기 위해서 3가지 파라미터를 설정할 수 있다.

* hive.exec.max.dynamic.partitions.pernode(기본 100) : 이는 각각의 매퍼 또는 리듀서가 만들어 낼 수 있는 최대 동적 파티션의 개수 이다. 한개의 매퍼나 리듀서가 임계값을 초과했드면 fatal 에러가 매퍼나 리듀어에서 발생하고 전체 잡은 죽게된다.

* hive.exec.max.dynmic.partitions(기본 1000) : 이는 한개의 DML에 의해서 만들어 질 수 있는 동적 파티션의 개수이다. 각각의 매퍼나 리듀서가 제한을 초과하지 않았지만 전체로 따졌을 경우 제한을 초과한 경우에는 중간데이터가 마지막 도착지로 이동하기 전에 잡의 마지막에 예외가 발생한다.

* hive.exec.max.create.files(기본 100000) : 이는 모든 매퍼나 리듀서가 만들 수 있는 파일의 최대 개수이다. 파일이 만들어 질 때마다 각 매퍼나 리듀서가 Hadoop 카운터에 업데이트 한다. 전체 파일 개수의 제한이 넘어갈 경우에는 잡은 죽는다.

– 동적 파티션 수행 시 고려해야하는 중요한 또다른 상황은 사용자의 원래 의도는 단지 루트 파티션 밑에 자식 파티션을 덮어쓰려고 했지만, 사용자가 고의로 모든 파티션을 동적 파티션으로 지정한 상황이다. 정적 모드에서는 반드시 최소 한개 이상의 정적 파티션을 추가해야한다. 기본적인 모드는 정적 모드이다. 이는 hive.exec.dynamic.partition=true/false로 변경 가능하다. 기본적으로는 false이다.

– Hive 0.6 에서는 동적 파티션 삽입은 hive.merge.mapfile=true 또는 hive.merge.mapredfiles=true로 설정하면 작동하지 않는다. 그래서 일부러 이 merge 파라미터는 꺼두어야 한다. 병합된 파일을 동적 파티션 삽입하는 기능은 Hive 0.7 부터 가능하다.

트러블슈팅과 베스트프렉트스

위에서 언급한바와 같이 하나의 매퍼와 리듀서에 의해 많은 동적 파티션이 만들어 지는 경우 fatal 에러가 발생하고 잡은 바로 죽는다. 이 에러 메시지는 다음과 같다.

hive> set hive.exec.dynamic.partition.mode=nonstrict;

hive> FROM page_view_stg pvs

INSERT OVERWRITE TABLE page_view PARTITION(dt, country)

SELECT pvs.viewTime, pvs.userid, pvs.page_url, pvs.referrer_url, null, null, pvs.ip,

from_unixtimestamp(pvs.viewTime, ‘yyyy-MM-dd’) ds, pvs.country;

…

2010-05-07 11:10:19,816 Stage-1 map = 0%, reduce = 0%

[Fatal Error] Operator FS_28 (id=41): fatal error. Killing the job.

Ended Job = job_201005052204_28178 with errors

위의 문제는 한개의 맵퍼가 무작위 row의 셋을 가진다는 것이다. distinct (dt,contry) 쌍이 hive.exec.max.dynamic.partitions.pernode의 값을 초과하였을 것이다. 이를 해결하기 위한 한가지 방법은 매퍼의 동적 파티셔닝 컬럼의 row들을 그룹화 하는것이다. 그리고 다이나믹 파티션이 만들어질 리듀서에 전송하는 것이다. 이러할 경우 서로 다른 동적 파티션의 개수를 크게 줄일 수 있다. 위의 쿼리문을 다시 만들어 본것이다.

ve> set hive.exec.dynamic.partition.mode=nonstrict;

hive> FROM page_view_stg pvs

INSERT OVERWRITE TABLE page_view PARTITION(dt, country)

SELECT pvs.viewTime, pvs.userid, pvs.page_url, pvs.referrer_url, null, null, pvs.ip,

from_unixtimestamp(pvs.viewTime, ‘yyyy-MM-dd’) ds, pvs.country

DISTRIBUTE BY ds, country;

이 쿼리는 맵 잡만 수행하기 보다는 맵리듀스 잡을 만든다. select 절은 매피로 바뀔 것이다. 그리고 출력은 (ds, country)의 값으로 리듀서로 배포될 것이다. 이 INSERT절은 다이나믹 파티션에 쓰기 위해서 리듀서로 변경될 것이다.

로컬 파일의 삽입

어떤 상황에서 우리는 출력파일을 로컬파일로 써야하는 상황이 발생 할 수 있다. 이는 다음 커맨드를 수행하면 가능하다.

INSERT OVERWRITE LOCAL DIRECTORY ‘/tmp/pv_gender_sum’

SELECT pv_gender_sum.*

FROM pv_gender_sum;

샘플링

샘플링 절에서는 사용자가 전체 테이블 대신에 데이터의 샘플을 위한 쿼리를 작성한다. 현재 CREATE TABLE 구문의 CLUSTED BY 절에 지정된 컬럼으로 샘플링을 수행한다. 다음 예는 pv_gender_sum 테이블의 32 버켓 중에서 3번째 버켓을 선택하여 가지고 오는 샘플이다.

INSERT OVERWRITE TABLE pv_gender_sum_sample

SELECT pv_gender_sum.*

FROM pv_gender_sum TABLESAMPLE(BUCKET 3 OUT OF 32);

일반적으로 아래와 같이 TABLESAMPLE 구문을 사용한다.

TABLESAMPLE(BUCKET x OUT OF y)

y는 테이블 생성 시점에 지정된 테이블의 버켓 개수의 갯수 또는 제수가 된다. bucket_number 모듈 y가 x와 같으면 버켓은 선택된다. 그래서 위의 예제에서 tablesample 절은

TABLESAMPLE(BUCKET 3 OUT OF 16)

19개 버켓중에서 3번째를 가지고 온다. 버켓은 0부터 시작한다.

다른한편

tablesample(bucket 3 out of 64 on userid)

는 3번째 버켓의 반을 가지고 온다.

Union all

언어는 union all을 지원한다. 비디오를 배포한 사용자와 커멘트를 배포한 사용자가 각기 다른 테이블에 있고 이를 추적해야 한다면 다음 쿼리를 이용하여 단일 스트림으로 비디오를 배포한 사용자와 커맨트를 배포한 사용자 모두를 한번에 결과로서 볼 수 있을 것이다.

INSERT OVERWRITE TABLE actions_users

SELECT u.id, actions.date

FROM (

SELECT av.uid AS uid

FROM action_video av

WHERE av.date = ‘2008-06-03’

UNION ALL

SELECT ac.uid AS uid

FROM action_comment ac

WHERE ac.date = ‘2008-06-03’

) actions JOIN users u ON(u.id = actions.uid);

배열 처리(Array Operations)

테이블에 있는 배열 컬럼들은 프로그램적으로만 만들 수 있다. 향후 이는 곳 CREATE 문으로 만들 수 있게 할 것이다. 현재 아래의 예제는 pv.friends 는 array타입이다. 즉 INT형의 배열이다. 사용자는 특정 배열을 통해서 엘리먼트의 특정 인덱스의 값을 가지고 올 수 있다.

SELECT pv.friends[2]

FROM page_views pv;

이 select 문은 pv.freinds 배열의 3번째 값을 가지고 온다.

사용자는 size 함수를 이용해서 배열의 크기도 가지고 올 수 있다.

SELECT pv.userid, size(pv.friends)

FROM page_view pv;

맵(Associative Array) 처리

맵은 연관배열(associative arrays)과 유사한 콜렉션이다. 이러한 구조는 현재에는 프로그램적으로만 만들어 진다. 이는 배열과 마찬가지로 곧 확장되어 CREATE 문에서도 사용될 것이다. 현재는 예제를 위하여 pv.properties에 저장하고 이를 사용한다. 이 파일에는 map구조를 가지고 있다고 가정한다. 이는 문자열에서 문자열로 연관된 배열이다. 다음의 쿼리를 살펴보자

INSERT OVERWRITE page_views_map

SELECT pv.userid, pv.properties[‘page type’]

FROM page_views pv;

page_views 테이블에서 ‘page_type’을 선택할 수 있다. 이와 유사하게 size 함수는 맵의 엘리먼트의 숫자를 가지고 올 수 있다.

SELECT size(pv.properties)

FROM page_view pv;

사용자 map/reduce 스크립트

사용자는 HIVE 언어에서 지원하는 기능들을 이용해서 각자 만든 사용자 지정 매퍼와 리듀서를 플러그인 할 수 있다. 사용자 지정 매퍼 스크립트는 map_script로 하고 리듀서 스크립트는 reducer_script라고 하자. 사용자는 다음 커맨드를 TRANSFORM 절에 삽입하여 매퍼와 리듀서 스크립트를 수행 할 수 있다.

사용자 스크립트가 들어가기전에 컬럼들은 string으로 변환되고 TAB 구분자로 구분될 것이다. 사용자 스크립트의 표준 출력은 TAB으로 구분된 문자열 컬럼들로 처리할 것이다. 사용자 스크립트는 하둡 페이지에서 볼 수 있는 태스크의 상세한 정보를 디버그 정보를 출력한다.

FROM (

FROM pv_users

MAP pv_users.userid, pv_users.date

USING ‘map_script’

AS dt, uid

CLUSTER BY dt) map_output

INSERT OVERWRITE TABLE pv_users_reduced

REDUCE map_output.dt, map_output.uid

USING ‘reduce_script’

AS date, count;

음은 샘플 맵 스크립트이다.(weekday_mapper.py)

import sys

import datetime

for line in sys.stdin:

line = line.strip()

userid, unixtime = line.split(‘t’)

weekday = datetime.datetime.fromtimestamp(float(unixtime)).isoweekday()

print ‘,’.join([userid, str(weekday)])

물론 맵과 리듀서 모두 좀더 일반적인 select 로 변환하기 위한 구문적 치장(“syntactic sugar”) 이다. 이너 쿼리는 다음과 같이 쓸 수 있다.

SELECT TRANSFORM(pv_users.userid, pv_users.date) USING ‘map_script’ AS dt, uid CLUSTER BY dt FROM pv_users;

스키마가 없는 맵/리듀서 : “USING map_script”뒤에 “AS”절이 있다면 Hive는 스크립트의 출력을 2개로 가지고 있다고 가정한다. 키는 첫번째 탭에 있고, 값은 첫번째 탭뒤의 나머지에 있다. 이는 “AS key, value”로 지정했을 때와 틀리다. 이러한 경우 값은 여러개의 탭이라면 첫번째 탭과 두번째 탭만 가지게 된다.

이 방법에서는 우리는 사용자에게 사용자가 맵 출력의 스미카를 알지 못하는 상태에서 이전의 맵/리듀스 스크립트를 마이그레이션 하도록 허락하는 것이다. 집어 넣을 데이터와 테이블과 매치시키기 위해서 사용자는 맵출력의 스키마를 알아야 한다.

FROM (

FROM pv_users

MAP pv_users.userid, pv_users.date

USING ‘map_script’

CLUSTER BY key) map_output

INSERT OVERWRITE TABLE pv_users_reduced

REDUCE map_output.dt, map_output.uid

USING ‘reduce_script’

AS date, count;

Distributed By와 Sorted By : cluster by를 지정하는 대신에 distributed by와 sort by를 지정할 수 있다. 그래서 파티션 컬럼과 정렬 컬럼은 다르다. 일반적인 케이스는 파티션 컬럼은 정렬 컬럼의 접두사가 된다. 그러나 반드시 이는 필수는 아니다.

FROM (

FROM pv_users

MAP pv_users.userid, pv_users.date

USING ‘map_script’

AS c1, c2, c3

DISTRIBUTE BY c2

SORT BY c2, c1) map_output

INSERT OVERWRITE TABLE pv_users_reduced

REDUCE map_output.c1, map_output.c2, map_output.c3

USING ‘reduce_script’

AS date, count;

맵/리듀스를 사용하는 사용자 커뮤니티의 사이에서 cogroup은 여러 테이블에서 보낸 데이터를 테이블의 어떤 값에 의해 group by하는 사용자 지정 리듀서에 보내는 일반적인 처리 방식이다. UNION ALL과 CLUSTER BY 지정하는 것은 다음의 방법으로 가능하다. 우리가 action_video와 action_comments 테이블의 row들을 cogroup 하여 사용자 지정 스크립트인 reduce_script 로 결과를 보내려고 한다고 가정하면 다음 문법을 이용하면 된다.

FROM (

FROM (

FROM action_video av

SELECT av.uid AS uid, av.id AS id, av.date AS date

UNION ALL

FROM action_comment ac

SELECT ac.uid AS uid, ac.id AS id, ac.date AS date

) union_actions

SELECT union_actions.uid, union_actions.id, union_actions.date

CLUSTER BY union_actions.uid) map

INSERT OVERWRITE TABLE actions_reduced

SELECT TRANSFORM(map.uid, map.id, map.date) USING ‘reduce_script’ AS (uid, id, reduced_val);

Altering Tables

기존에 있는 테이블 명칭을 새로운 이름으로 변경하려면 다음과 같이 하면된다. 새로운 테이블이름이 이미 있다면 에러를 발생시킨다.

ALTER TABLE old_table_name RENAME TO new_table_name;

기존 테이블에서 컬럼 명을 변경하기 위해선 다음과 같이 하면 된다. 같은 컬럼 타입을 사용해야 한다. 그리고

ALTER TABLE old_table_name REPLACE COLUMNS (col1 TYPE, …);

기존 테이블에 컬럼을 추가하기 위해선

ALTER TABLE tab1 ADD COLUMNS (c1 INT COMMENT ‘a new int column’, c2 STRING DEFAULT ‘def val’);

스키마의 변경(컬럼 추가 같은), 파티션된 테이블의 경우에는 테이블의 이전 파티션의 스키마는 보존된다. 이러한 컬림이나 이전 파티션에서 돌아간 모든 쿼리들은 암묵적으로 null 값이나 이 컬럼의 기본값을 반환한다.

Table과 Partitions의 Drop

테이블 드롭은 매우 쉬운일이다. 테이블 드롭은 묵시적으로 모든 인덱스도 드롭한다.

DROP TABLE pv_users;

파티션의 드롭하기 위해서는 Alter Table에 Drop Partition 옵션을 주면된다.

ALTER TABLE pv_users DROP PARTITION (ds=’2008-08-08′)

하이브 (Apache Hive) 개념 및 설치 (아파치 더비 사용)

1. 하이브

페이스 북에서 개발한 하이브는 하둡에 저장된 데이터를 쉽게 처리할 수 있는 데이터웨어하우스(DW) 패키지 이다.

1)하이브 아키텍처

하이브의 클라이언트는 커맨드 라인 인터페이스 (Command Line Interface: CLI ), 하이브 서버, 웹 인터페이스 로 구성된다. 하이브 서버의 경우 JDBC, ODBC, 쓰리프트로 개발된 클라이언트가 하이브 서비스를 이용할 수 있게 쓰리프트 서비스를 제공한다.

(Command Line Interface: ), 로 구성된다. 하이브 서버의 경우 JDBC, ODBC, 쓰리프트로 개발된 클라이언트가 하이브 서비스를 이용할 수 있게 쓰리프트 서비스를 제공한다.

하이브는 메타스토어(Metastore)라는 저장소를 만들어 하둡에서 처리된 메타데이터의 구조를 메타스토어에 저장한다. 하이브는 오라클, MySQL 등 JDBC를 지원하는 모든 데이터베이스를 이용해 메타스토어를 구축할 수 있다.

드라이버는 사용자가 입력한 하이브QL문을 해석한다. 하둡과 연결되어 하이브QL문을 실행하고, 하이브QL은 하이브QL문의 실행 계획을 작성하고, 최적화 작업까지 함께 수행한다.

[출처: www.dbguide.net]

2. 하이브 설치 및 실행

wget http://mirror.apache-kr.org/hive/hive-2.0.0/apache-hive-2.0.0-bin.tar.gz tar xvfz apache-hive.2.0.0-bin.tar.gz cd apache-hive.2.0.0-bin ls – l 합계 588 -rw-r–r– 1 root staff 26335 1월 22 2016 LICENSE -rw-r–r– 1 root staff 513 1월 22 2016 NOTICE -rw-r–r– 1 root staff 4348 2월 10 2016 README.txt -rw-r–r– 1 root staff 527063 2월 10 2016 RELEASE_NOTES.txt drwxr-xr-x 3 root root 4096 11월 14 22:24 bin drwxr-xr-x 2 root root 4096 11월 14 22:24 conf drwxr-xr-x 4 root root 4096 11월 14 22:24 examples drwxr-xr-x 7 root root 4096 11월 14 22:24 hcatalog drwxr-xr-x 4 root root 12288 11월 14 22:24 lib drwxr-xr-x 4 root root 4096 11월 14 22:24 scripts

하이브는 conf 디렉터리에 있는 hive-env.sh 파일에 기본 환경설정을 한다. 처음 하이브를 설치하면 conf 디렉터리에는 템플릿 파일만 있으므로 다음과 같이 새로운 hive-env.sh 파일을 만든 후 하둡 홈 디렉터리를 설정한다.

mv conf/hive-env.sh.template conf/hive-env.sh HADOOP_HOME=/usr/local/hadoop-2.7.3

책에서 적힌대로 아파치더비를 사용하여 hive-site.xml을 다음과 같이 설정하였다.

hive.metastore.warehouse.dir /user/hive/warehouse hive.cli.print.header true

하이브에서 업로드하는 데이터는 HDFS의 /user/hive/warehouse에 저장된다. 그리고 하이브에서 실행하는 잡의 여유 공간으로 HDFS의 “/tmp/hive-유저명” 디렉터리를 사용한다. 이 두개의 디렉터리를 다음과 같이 미리 생성한 후 실행 권한도 함께 설정한다.

bin/hdfs dfs -mkdir /tmp bin/hdfs dfs -mkdir /tmp/hive bin/hdfs dfs -mkdir /user/hive bin/hdfs dfs -mkdir /user/hive/warehouse bin/hdfs dfs -chmod g+w /tmp bin/hdfs dfs -chmod g+w /user/hive/warehouse bin/hdfs dfs -chmod 777 /tmp/hive

하이브 2.0.0 버전부터는 하이브를 실행하기 전에 하이브 메타스토어를 초기화해야한다. 다음과 같이 initSchema를 이용해 메타스토어를 초기화 한다. hive-site.xml에 별도의 메타스토어를 설정하지 않았다면 (예, MySQL, MS-SQL 등) -dbType에 derby를 사용한다.

:/usr/local/hadoop2/apache-hive-2.0.0-bin# bin/schematool -initSchema -dbType derby SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/usr/local/hadoop-2.7.3/apache-hive-2.0.0-bin/lib/hive-jdbc-2.0.0-standalone.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/usr/local/hadoop-2.7.3/apache-hive-2.0.0-bin/lib/log4j-slf4j-impl-2.4.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/usr/local/hadoop-2.7.3/share/hadoop/common/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory] Metastore connection URL: jdbc:derby:;databaseName=metastore_db;create=true Metastore Connection Driver : org.apache.derby.jdbc.EmbeddedDriver Metastore connection User: APP Starting metastore schema initialization to 2.0.0 Initialization script hive-schema-2.0.0.derby.sql Initialization script completed schemaTool completed :/usr/local/hadoop2/apache-hive-2.0.0-bin# bin/hive hive> show databases; OK database_name default Time taken: 0.209 seconds, Fetched: 1 row(s)

키워드에 대한 정보 아파치 하이브

다음은 Bing에서 아파치 하이브 주제에 대한 검색 결과입니다. 필요한 경우 더 읽을 수 있습니다.

이 기사는 인터넷의 다양한 출처에서 편집되었습니다. 이 기사가 유용했기를 바랍니다. 이 기사가 유용하다고 생각되면 공유하십시오. 매우 감사합니다!

사람들이 주제에 대해 자주 검색하는 키워드 빅데이터 047 하이브 아키텍쳐와 데이터 모델

• 동영상
• 공유
• 카메라폰
• 동영상폰
• 무료
• 올리기

빅데이터 #047 #하이브 #아키텍쳐와 #데이터 #모델

---

YouTube에서 아파치 하이브 주제의 다른 동영상 보기

주제에 대한 기사를 시청해 주셔서 감사합니다 빅데이터 047 하이브 아키텍쳐와 데이터 모델 | 아파치 하이브, 이 기사가 유용하다고 생각되면 공유하십시오, 매우 감사합니다.