Hive : DDL, DML, SQL Operations

2011/02/23 Leave a comment

DDL Operation

하이브 테이블을 만들고 결과를 보여준다.

hive> CREATE TABLE pokes (foo INt, bar STRING);

두 개의 컬럼이 있는 pokes 테읍ㄹ을 생성한다. 첫 번째는 정수, 두 번째는 문자열이다.

hive> CREATE TABLE invites (foo INT, bar STRING) PARTITIONED BY (ds STRING);

두개의 컬럼을 가지고 한 개의 파티션 컬럼을 가지는 invites 테이블은 생성한다. 파티션 걸럼은 가상 컬럼이다. 이것은 데이타 자체의 일부분이 아니다. 특별한 데이터 셋이 로드되는 파티션으로 부터 유래한다.
디폴트로 테이블들은 text input format이고 구분자는 ^A(crt-a)라고 가정한다.

hive> SHOW TABLES;

테이블의 목록을 보여준다.

hive> SHOW TABLES ‘.*s’;

‘s’로 끝나는 테이블의 모든 목록을 보여준다. 이 패턴 매칭은 Java regular expressions을 따른다.

hive> DESCRIBE invites;

컬럼의 목록을 보여준다.

테이블 변경에서 테이블 이름은 변경될 수 있다. 그리고 추가 컬럼도 drop 될 수 있다.

hive> ALTER TABLE pokes ADD COLUMNS (new_col INT);
hive> ALTER TABLE invites ADD COLUMNS (new_col2 INT COMMENT ‘a comment’);
hive> ALTER TABLE events RENAME TO 3koobecaf;

테이블 drop

hive> DROP TABLE pokes;

 

Metadata Store

메타데이터는 javax.jdo.option.ConnectionURL 의 이름의 하이브 설정 변수에 의해 디스크 스토리의 위치 결정되는  임베디드 더비 데이터베이스이다.  초기 값은 ./metasore_db 이다.

메타스토어는  JPOX를 지원하는 어떤 데이타베이스에도 저장될 수 있다. 위치와 RDBMS의 타입은 javax.jdo.option.ConnectionURL 과 javax.jdo.option.ConnectionDriverName 두 변수에 의해서 조정된다.
지원하는 데이터베이스들의 좀 더 자세항 사항은 JDO(또는 JPOX) 문서를 참조해라 테이터베이스 스키마는  src/contrib/hive/metasore/src/model에 있는 JDO 메타데이터 어노테이션 파일 package.jdo 에 정의 되어 있다.

향후에는 메타스토어 자체가 stand-alone 서버가 될 것이다.

DML Operation

flat 파일의 데이타를 Hive로 로드한다.

hive> LOAD DATA LOCAL INPATH ‘./examples/files/kv1.txt’ OVERWRITE INTO TABLE pokes;

ctrl-a 로 나눠진 두 컬럼 포함하는 파일을 pkes 테이블로 로드한다.  ‘local’ 이라고 명시하는 것은 입력파일이 로컬 파일 시스템에 있다는 것이다. ‘local’을 빼면 HDFS 에 있는 파일을 찾는다. ‘overwrite’ 키워드는 테이블의 기존의 데이타는 삭제됨을 명시한다. ‘overwrite’ 키워드가 빠지면 데이터 파일은 기존 데이터 셋에 추가된다.

알아야 할 점

  • 로드 커맨드에 수행되는 스키마에 대한 데이터 검증(verification)은 없다
  • 만약 HDFS에 파일이 있다면 그것은 Hive-controlled 파일 시스템 네임스페이스로 이동한다.
    하이브 디렉토리의 루트는 hive-default.xml 파일에 hive.metastore.warehouse.dir 옵션에 의해 지정된다. 하이브에서 테이블을 생성하기 전에 이 디렉토리를 만들 것을 사용자에게 충고한다
hive> LOAD DATA LOCAL INPATH ‘./examples/files/kv2.txt’ OVERWRITE INTO TABLE invites PARTITION (ds=’2008-08-15)’;
hive> LOAD DATA LOCAL INPATH ‘./.examples/files/kv3.txt’ OVERWRiTE INTO TABLE invites PARTITION  (ds=’2008-08-08’);

위에 두 개의 LOAD 명령은 invites 테이블의 두 개의 다른 파티션으로 데이터를 로드한다. invites 테이블은 ds 키에 의해서 파티션되어 생성된다.

hive> LOAD DATA INPATH ‘/user/myname/kv2.txt’ OVERWRITE INTO TABLE invites PARTITION (ds=’2008-08-15)’;

위에 커맨드는 HDFS 파일/디렉토리로 부터 데이터를 읽어 table에 로드한다. HDFS로 부터 데이터를 로드하는 것의 결과는 파일/디렉토리로 이동되는 것이다. operation은 거의 즉시 수행된다.

SQL Operation

Example Queries

예제 쿼리는 build/dist/examples/queries에 있다. 더 많은 쿼리는 ql/src/test/queries/positive 에 있다

SELECTS and FILTERS

hive> SELECT a.foo FROM invites a WHERE a.ds=’2008-08-15’;

invites 테이블의 파티션 ds=2008-08-15의 모든 로우에서 foo 컬럼을 선택한다. 결과는 어디에도 저장되지 않는다. 그러나 콘솔 화면에 디스플레이 된다.
다음 예제들에서 INSERT(하이브 테이블이나, 로컬 디렉토리, HDFS 디렉토리)는 선택적이다.

hive> INSERT OVERWRITE DIRECTORY ‘/tm/hdfs_out’ SELECT a.* FROM invites a WHERE a.ds=’2008-08-15’;

쿼리의 결과를  HDFS 디렉토리에 저장한다. 결과 데이터는 디렉토리 파일 안에 있다. (mapper의 개수의 의존한다)
파티션된 테이블은 항상 WHERE 절에 파티션 선택해야 한다.

hive> INSERT OVERWRITE LOCAL DIRECTORY ‘/tmp/local_out’ SELECT a.* FROM pokes a;

pokes 테이블의 모든 로우를 선택하여 로컬 디렉토리로 로드한다.

hive> INSERT OVERWRITE TABLE events SELECT a.* FROM profiles a;
hive> INSERT OVERWRITE TABLE events SELECT a.* FROM profiles a WHERE a.key < 100;
hive> INSERT OVERWRITE LOCAL DIRECTORY ‘/tmp/reg_3’ SELECT a.* FROM events a;
hive> INSERT OVERWRITE DIRECTORY ‘/tmp/reg_4’ select a.invites, a.pokes FROM profiles a;
hive> INSERT OVERWRITE DIRECTORY ‘/tmp/reg_5′ SELECT COUNT(*) FROM invites a WHERE a.ds=’2008-08-15’;
hive> INSERT OVERWRITE DIRECTORY ‘/tmp/reg_5’ SELECT a.foo, a.bar FROM invites a;
hive> INSERT OVERWRITE LOCAL DIRECTORY ‘/tmp/sum’ SELECT SUM(a.pc) FROM pc1 a;

컬럼의 합(SUM), 평균(arg), 최소값(min), 최대값(max)이 사용 될 수 있다.

GROUP BY

hive> FROM invites a INSERT OVERWRITE TABLE events ELECT a.bar, count**) WHERE a.foo > 0 GROUP BY a.bar
hive> INSERT OVERWRITE TABLE events SELECT a.bar, count(*) FROM invites a WHERE a.foo > 0 GROUP BY a.bar;

MULTITABLE INSERT

FROM src
INSERT OVERWRITE TABLE dest1 SELECT src.* WHERE src.key < 100
INSERT OVERWRITE TABLE dest2 SELECT src.key, src.value WHERE src.key >= 100 and src.key < 200
INSERT OVERWRITE TABLE dest3 PARTITION(ds=’2008-04-08′, hr=’12’) SELECT src.key WHERE src.key >= 200 and src.key < 300
INSERT OVERWRITE LOCAL DIRECTORY ‘/tmp/dest4.out’ SELECT src.value WHERE src.key >= 300;

JOIN

hive> FROM pokes t1 JOIN ivites t2 ON (t1.bar=t2.bar) INSERT OVERWRITE TABLE evners SELECt t1.bar, t2.bar,t2.foo;

 

STREAMING

hive> FROM invites a INSERT OVERWRITE TABLE event SELECT TRANSFORM (a.foo, b.bar) AS (off,rb) USING ‘/bin/cat’ WHERE a.ds>’2008-0809

 

Reference

Filed under DB / SQL Tagged with , , , , ,

Bigtable

2011/02/14 Leave a comment

빅테이블은 구글에서 개발한 분산 데이터 관리 시스템으로, 수백 내지 수천 대의 값싼 하드웨어 장비를 이용해 페타 바이트 이상의 구조화된 데잍터를 저장할 수 있다. 빅케이블은 범용성, 확장성, 고성능, 고가용성의 목표를 가지고 만들어진 시스템이다.

데이터 모델은 분산돼 있는 다차원으로 정렬된 맵이다. 모든 데이터는 row key. column key, timestamp로 정렬돼 있으며, value에는 바이트 배열을 저장할 수 있다. 데이터 모델을 구성하는 주요 엘리먼트는 row, column family, timestamp 등이 있다

하나의 테이블에 저장된 데이터는 row key로 유일하게 식별된다. 읽기/쓰기 연산은 하나의 열 단위로 원자적으로 처리된다. 빅ㅌ이블은 하나의 아주 큰 테이블을 row key의 영역을 이용해 파티셔닝하며, 파티셔닝된 단위를 테블릿tablet이라고 부른다. 하나의 테블릿은 특정 서버에 의해 서비스되며, 하나의 서버는 수 천개의 테블릿을 서비스 한다.

파티셔닝 범위, 서비스 서버 등과 같은 파티셔닝에 대한 정보는 하나의 루트 테블릿과 다수의 메타 테블릿에 저장된다. 루트 테블릿을 서비스하는 서버의 정보는 zookeeper 와 같은 역할을 하는 chuby (distributed lock service)에 저장되며, 루트 테블릿에서 하나의 열에는 하나의 메타 tablet에 대한 정보 (tablet 이름, 최대 row key, 서버 정보)를 저장한다. 메타 테블릿에서 하나의 열에는 사용자 테이블에 있는 하나의 테블릿에 대한 정보를 저장한다. 특정 row key를 서비스하는 사용자 테이블의 테블릿과 테블릿 서버를 찾기 위해 chuby -> 루트 테블릿 – > 메타 테블릿 순으로 찾는다.

bigtable_architecture

하나의 빅테이블 클러스터는 하나의 마스터 서버와 다수의 테블릿 서버로 구성된다. 마스터 서버는 마타 정보 같이 클러스터 관리에 필요한 정보를 갖고 있지 않기 때문에 마스터 장애 시에도 데이터 서비스는 영향을 받지 않는다. 마서터 서버는 테블릿을 할당하거나, 테블릿 서버가 클러스터에 추가/제거되는 것을 감지하고, 테블릿 서버의 부하 분산과 구글 파일 시스템에 저장된 파일에 대한 가비지 컬렉션을 수행한다. 테블릿 서버는 테블릿을 관리하고 클라이언트로부터 데이터 읽기/쓰기 요청을 받아 처리한다. 하나의 테블릿 서버는 수천 개까지 ㅌ에블릿을 서비스하고, 하나 테블릿 크기는 100~200MB이다.

빅테이블은 구글 파일 시스템, 맵리듀스(MapReduce), 처비(chuby) 등과 같은 구글 내부의 여러 분산 플랫폼을 이용한다. 빅테이블은 구글 파일 시스템을 데이터 파일이나 커밋 로그 저장용으로 사용한다. 구글 파일 시스템에서 하나의 파일은 3개의 복제본을 갖고 있기 때문에 추가적인 백업이 필요 없으며, 수천 노드 이상으로 확장할 수 있는 확장성과 복제본 간의 정합성을 제공한다.

구글 파일 시스템은 하둡 파일 시스템의 기본 설계를 제공한 파일 시스템이다. 구글 파일 시스템 역시 파일의 랜덤쓰기 기능을 제공하지 않기 때문에 이미 저장된 파일을 수정하는 것이 불가능하다. 파일 시스템의 이런 제약 때문에 빅테이블은 메모리 기반In-Memonry, 디스크기반On-Disk 데이터 관리 시스템의 속성을 모두 갖고 있다. 빅테이블의 쓰기 연산은 데이터 파일을 직접 수정하지 않고 메모리에만 쓰기 연산의 내용을 기록한다. 메모리가 일정 크기에 도달하면 메모리의 내용을 파일 시스템으로 저장한다. 쓰기 연산을 메모리에만 저장하기 때문에 테블릿 서버에 장애가 발생한 경우 데이터 복구를 위해 모든 쓰기 연산 처리시 구글 파일 시스템에 커밋 로그를 저장한 후 메모리에 저장한다.

빅테이블에 저장된 데이터에 대해 대규모의 분석 작업이 필요한 경우 맵리듀스 플랫폼을 이용하며, 분산 처리되는 단위는 하나의 테블릿이다. 처비는 분산 락 서비스를 제공하는 시스템으로, 빅테이블에서는 루트 메타 정보를 서비스하는 테블릿 서버의 위치 정보, 테이블의 스키마 정보 등을 저장하거나 여러 마스터 서버가 동시에 실행 중일 때 유요한 마스터 서버를 선출하거나, 테블릿 서버의 장애 상황을 발생을 감지하는 등에 사용한다. 하나의 처비 셀은 5개의 노드로 구성되며, 노드 간의 모든 정보는 동기화돼 마스터 정보에 대한 SPOF(Single Point Of Failure) 지점을 없애는 역할을 수행한다. 빅테이블은 구글 파일 시스템을 이용함으로써 데이터의 정합성은 보장하지만 네트워크 단절 상황에서 가용성을 지원하지 않는다.

빅테이블은 웹 페이지 인덱싱, Google Earth, Google Finance, Google Analytics, personalized Search 등 이미 구글의 많은 서비스에 적용 중이다.

아파치 같은 오픈소스 진영이나 인터넷 서비스 업체들이 빅테이블의 개념을 도입한 시스템을 발표하고 있으며, 이들 대부분은 공개 소프트웨어다.

Source

Related Links

Filed under DB / SQL Tagged with , , , , ,