https://cwiki.apache.org/confluence/display/Hive/LanguageManual+SortBy



하이브에서 사용되는 정렬 키워드를 소개한다.


* ORDER BY (ASC|DESC): RDMBS의 ORDER BY 문과 비슷하다. ORDER BY 문을 실행 시, 하나의 리듀서만 사용해 전역 정렬을 수행하면, 리턴 시간이 더 소요된다. ORDER BY 뒤에 LIMIT 사용하는 것을 강력 추천한다. 그래서, hive.mapred.mode = strict (hive.mapred.mode= nonstrict은 기본값이다.)로 설정하고 LIMIT을 명세하지 않으면, 에러가 발생한다. 



jdbc:hive2://> SELECT name FROM employee ORDER BY NAME DESC;

+----------+

|   name   |

+----------+

| Will     |

| Shelley  |

| Michael  |

| Lucy     |

+----------+



* SORT BY (ASC|DESC): 어떤 레코드의 컬럼으로 정렬할지 가리킨다. 데이터를 리듀서에 보내기 전에 정렬을 완료한다는 것을 의미한다. mapred.reduce.tasks=1을 설정하지 않는다면, SORT BY 문은 전역으로 정렬을 수행하지 않고, 각 리듀서에서 내부적으로 정렬된 데이터인지 확인한다. 이 경우에 ORDER BY 결과와 동일하다. 


--2 개의 리듀서를 사용하면 리듀서마다 정렬(sorting)하기 때문에 정렬 결과가 다르다.

jdbc:hive2://> SET mapred.reduce.tasks = 2;

No rows affected (0.001 seconds)


jdbc:hive2://> SELECT name FROM employee SORT BY NAME DESC;

+----------+

|   name   |

+----------+

| Shelley  |

| Michael  |

| Lucy     |

| Will     |

+----------+

4 rows selected (54.386 seconds)


--리듀서 한 개만 사용하면 order by 와 동일한 효과를 제공한다.

jdbc:hive2://> SET mapred.reduce.tasks = 1;

No rows affected (0.002 seconds)


jdbc:hive2://> SELECT name FROM employee SORT BY NAME DESC;

+----------+

|   name   |

+----------+

| Will     |

| Shelley  |

| Michael  |

| Lucy     |

+----------+

4 rows selected (46.03 seconds)



* DISTRIBUTE BY:  컬럼값이 일치하는 로우는 동일한 리듀서로 파티션 된다. 하나의 리듀서만 사용하면, 리듀스는 정렬된 입력을 보장하지 않는다. 매퍼 결과를 분배하기 위해 어느 리듀서로 결정할지 여부의 관점에서 보면, DISTRIBUTE BY는 RDBMS의 GROUP BY와 비슷하다. SORT BY를 사용할 때, SORT BY 앞에 DISTRIBUTE BY를 명세해야 한다. 그리고, 분배하기 위해 사용된 컬럼은 SELECT 뒤에 컬럼 이름이 나타나야 한다. 



- SQL의 GROUP BY와 같은 형태이기 때문에 select 뒤에 컬럼 이름이 나와야 한다.

jdbc:hive2://> SELECT name 

. . . . . . .> FROM employee_hr DISTRIBUTE BY employee_id; 

Error: Error while compiling statement: FAILED: SemanticException [Error 10004]: Line 1:44 Invalid table alias or column reference 'employee_id': (possible column names are: name) (state=42000,code=10004)


jdbc:hive2://> SELECT name, employee_id 

. . . . . . .> FROM employee_hr DISTRIBUTE BY employee_id; 

+----------+--------------+

|   name   | employee_id  |

+----------+--------------+

| Lucy     | 103          |

| Steven   | 102          |

| Will     | 101          |

| Michael  | 100          |

+----------+--------------+

4 rows selected (38.92 seconds)


--SORT BY로 사용하기 

jdbc:hive2://> SELECT name, employee_id  

. . . . . . .> FROM employee_hr 

. . . . . . .> DISTRIBUTE BY employee_id SORT BY name; 

+----------+--------------+

|   name   | employee_id  |

+----------+--------------+

| Lucy     | 103          |

| Michael  | 100          |

| Steven   | 102          |

| Will     | 101          |

+----------+--------------+

4 rows selected (38.01 seconds)



* CLUSTER BY: 동일한 그룹의 컬럼에 대해 DISTRIBUTE BY와 SORT BY 명령을 동시에 수행하는 명령어다. 그리고 내부적으로 각 리듀서에서 정렬된다. CLUSTER BY 문은 아직 ASC 또는 DESC를 지원하지 않는다. 전역으로 정렬되는 ORDER BY와 비교해, CLUSTER BY 명령은 각 분배된 그룹에서 정렬이 이루어진다. 전역 정렬을 실행할 때 사용할 수 있는 모든 리듀서를 작동시키려면, CLUSTER BY를 먼저 사용하고 뒤에 ORDER BY를 사용한다. 



jdbc:hive2://> SELECT name, employee_id 

. . . . . . .> FROM employee_hr CLUSTER BY name;  

+----------+--------------+

|   name   | employee_id  |

+----------+--------------+

| Lucy     | 103          |

| Michael  | 100          |

| Steven   | 102          |

| Will     | 101          |

+----------+--------------+

4 rows selected (39.791 seconds)



'hadoop' 카테고리의 다른 글

hive 와 hadoop 버전 확인하기  (0) 2016.10.21
[hive] hive의 윈도우 표현식(파티션 범위)  (0) 2016.05.11
[hive] collect_set  (0) 2016.04.30
[hadoop] getmerge 명령어  (0) 2016.04.21
[hive] count와 distinct 이슈  (0) 2016.04.20
Posted by '김용환'
,



'get to grips with something'은 대처하다. 다루다, 이해하다 라는 뜻을 가진다. 



예)

You can get to grips with the task of server maintenance.

서버 유지보수 작업을 이해하고 다룰 수 있다.


Excuse my ignorance, I can't get to grips with is 'kernel task' and 'kernel panic'

저의 무식함을 용서해주세요. '커널 태스크'와 '커널 패닉'이라는 단어를 이해할 수 없어요.

Posted by '김용환'
,


This is not advisable이란 뜻은 바람직하지 않다. 추천하지 않는다라는 의미를 가진다.

(it is not recommended you)



This is not advisable, and for this reason ~


이런 이유로, 추천하지 않는다.


Posted by '김용환'
,

[cassandra] history 보기

nosql 2016. 5. 6. 18:31


cassandra에서 cli, cqlsh, nodetool에 대한 히스토리 정보를 보는 방법을 설명한다.


~/.cassandra 디렉토리 밑에 3 개의 파일이 있다.


$ ls  .cassandra/

cli.history  cqlsh_history  nodetool.history



cli(https://wiki.apache.org/cassandra/CassandraCli)는 cqlsh의 전신이었으며, cli.history 파일에 히스토리 로그를 쌓는다.


cqlsh는 cqlsh.history 파일에서 히스토리 로그를 확인한다. cqlsh에서 화살표 위,아래로 확인할 수도 있지만, 오래 전부터 쌓인 많은 정보를 확인하고 싶다면 cql.history을 확인한다.


nodetool 툴에서 사용한 히스토리 로그를 확인하려면 nodetool.history를 확인한다.




Posted by '김용환'
,



realpath 명령어는 centos7부터 내장된 명령어로서 파일의 절대 위치를 알려준다. 

특히 심볼링 링크가 가르키는 디렉토리를 보고 싶을 때 확인할 수 있다. 



centos 7부터 /bin 디렉토리가 /usr/bin/으로 이동했다.


$ ls -l /bin

lrwxrwxrwx. 1 root root 7  7월 28  2015 /bin -> usr/bin



$ realpath /bin

/usr/bin






'unix and linux' 카테고리의 다른 글

dstat 툴  (0) 2016.05.23
[centos7] systemctl 맛보기  (0) 2016.05.11
센트OS 7 다운로드 URL 설명  (0) 2016.05.02
setuid 동작 결과를 ps로 확인하기(ruser, euser)  (0) 2016.04.28
[nginx] echo > sudo 파일 권한  (0) 2016.04.25
Posted by '김용환'
,


nginx에서 파일을 이용하여 L7 health check (10초 동안 x번 200 리턴 값이 아닌 값이 나오면 l7 binding이 빠지게 하는 방법)하는 방법을 소개한다. 



1. -f을 이용하여 파일을 체크하는 방식이 있다. 

(사실 if가 evil이긴 하지만, 이 방법만큼 심플한 방법이 없었다..)


location = /l7.html {

  if (!-f /usr/local/nginx/off_health_check) {

    return 404; 

  }

  access_log  off;

  allow       all;


  proxy_pass http://service

}



/usr/local/nginx/off_health_check이 파일이 존재하지 않으면, 404을 리턴하여 l7 health check에 실패로 인식하게 한다.

만약 해당 파일이 존재하지 않으면 service 포트로 전달하도록 proxy_pass를 이용한다.


elasticsearch 라면, proxy_pass http://es/_cluster/health; 를 추가하여 elasticsearch의 클러스터 헬쓰 체크를 할 수 있도록 변경할 수 있다. 



참고 #1


nginx 공식 문서에, if (-f 파일명)에 대해서 좋지 않는 것 같다. 대신 try-files를 쓰라고 권고하고 있다.

https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#check-if-file-exists



Check (If) File Exists


Using if to ensure a file exists is horrible. It’s mean. If you have any recent version of NGINX you should look at try_files which just made life much easier.


BAD:


server {

    root /var/www/example.com;

    location / {

        if (!-f $request_filename) {

            break;

        }

    }

    

    






2. 설정 파일에서 읽어 l7 health check를 제어하는 방법이다.

if is evil!(https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/)이 찜찜하지만, 너무 좋은 기능이라 쓸 수 밖에 없다. 



설정 


<conf/l7.conf>

$ cat /usr/local/nginx/conf/l7.conf

set $l7 down;



<conf/vhost.conf 파일>


location /health_check.html {

include l7.conf;

if ($l7 = "down") {

return 404;

}


access_log  off;

        allow       all;


        default_type text/html;

        return 200 "OK";

        }





스크립트를 다음처럼 사용할 수 있다.


$ cat > l7.sh

#!/bin/sh


COMMAND=$1


if [ -z "${COMMAND}" ]; then

  echo 1>&2 "$0: no given command."

  exit 2

fi


echo "set \$l7 ${COMMAND};" > /usr/local/nginx/conf/l7.conf && sudo ./sbin/nginx -s reload && echo "${COMMAND}"




다음처럼 스크립트를 실행하면 l7 health check를 제어할 수 있다.


$ l7.sh up 

up

$ curl -v -XGET http://localhost/health_check.html

..HTTP/1.1 200 OK


$l7.sh down

down

.. HTTP/1.1 404 Not Found

    





* 노트 1

keepalive 모드를 사용하면서, l7.conf를 사용하여 변수 값을 이용하여 l7 health check하는 방법을 사용할 때, 이슈가 발생할 수 있다. nginx -s reload는 graceful하게 할 수 있다고 알려져 있지만, keepalive 모드에서는 tcp 데이터가 전달되면서 동시에 잠깐의 재시작이 일어나면서 패킷 드롭 현상이 발생될 수 있다.

no host exception과 같은 에러를 발견할 수 있다. 


이 문제를 해결하려면, keepalive를 쓰지 않거나, -f을 이용한 파일 체크를 사용하는 방법이 나을 것 같다. 





* 노트 2


keepalive 상태에서 파일을 이용한 l7 health check 방법은 약간의 한계가 있다. 

keepalive이기 때문에 대용량 서비스일 때, tcp 패킷이 계속 들어올 수 있기 때문에 l7 health check에서 200이 아닌 값, 즉 400 에러를 내보내도 계속 tcp 패킷이 들어와서 l7 스위치 바인딩에서 빠지지 않게 된다.


요청량이 아주 많지 않으면 keepalive를 쓰지 않는다. 그러면 파일을 이용한 l7 health check가 아주 유용할 것이다.

keepalive를 사용중이라면, client 쪽에서 여러 번 retry 구조로 변경해야 한다. 



* 노트 3

if (!-f 파일명) 


-f는 파일이 존재하면,

!-f는 파일이 존재하지 않으면 이라는 의미를 가진다.


!-f를 주로 사용하는 것이 추천하고 싶은 이유는 좀 더 유연하게 대처할 수 있을 것 같다. 

nginx를 재시작하기 전에 파일이 없으면 404라는 의미를 주는 것이 더 명쾌하는 것 같다. 



Posted by '김용환'
,


센트OS 를 버전별로 다운받을 수 있는 사이트이다.

http://centos.mirror.cdnetworks.com/



2016년 5월 현재, 다음과 같은 센트OS 7를 다운받을 수 있다. 





7.x.yyyy 형태를 가지고 있는데, 7.x는 버전을 의미하고, yyyy는 연과 월단위로 표현한다.

7.2.1511은 센트OS 7.2이고, 15년 11월에 출시도었음을 의미한다.



센트OS는 x86의 64비트만 지원하기 때문에 x86_64 버전만 다운받을 수 있다 .


http://centos.mirror.cdnetworks.com/7.2.1511/ 를 보면, cloud,iso등과 같은 형태로 배포된다.



작은 규모의(minimal) iso를 다운받으려면, 브라우져에 다음 url을 접속하고, 

http://centos.mirror.cdnetworks.com/7.2.1511/isos/x86_64/


아래 링크를 클릭해서 다운받는다.


정상적인 파일인지 확인하기 위해서 md5로 체크섬을 확인한다.



$ md5 CentOS-7-x86_64-Minimal-1511.iso

MD5 (CentOS-7-x86_64-Minimal-1511.iso) = 88c0437f0a14c6e2c94426df9d43cd67



$ cat md5sum.txt

c875b0f1dabda14f00a3e261d241f63e  CentOS-7-x86_64-DVD-1511.iso

dba29c59117400b111633be2bf2aaf0e  CentOS-7-x86_64-Everything-1511.iso

7e46208ba6c5fe817a3ce981aa122f54  CentOS-7-x86_64-LiveGNOME-1511.iso

d9f8e2ae2148d0abdf55a2a9eef42f00  CentOS-7-x86_64-LiveKDE-1511.iso

88c0437f0a14c6e2c94426df9d43cd67  CentOS-7-x86_64-Minimal-1511.iso

99d305fa40ec9e28ef8450c3bcc45f85  CentOS-7-x86_64-NetInstall-1511.iso




md5sum.txt의 값과 md5의 값이 같으면 문제없다는 뜻이다.


Posted by '김용환'
,