전체 글 (312)

반응형

Random walk model

아래와 같이 정의되는 X_t 를 random walk 이라고 한다. X_t 는 이전 time step 에서의 값 X_t-1 에 noise Z가 더해진 값이다. random sampling 과 다른점은 현재값이 이전값에 더해진다는것이다. 이는 랜덤하게 어떤 한 방향으로 걷는것과 비슷하다. 매번 시작점에서 한발짝 걷는 것이 아니라 한발짝 걸어서 도착한 곳에서 다시 한발짝을 간다. 

 

$$ X_t = X_{t-1} + Z_t $$

$$ Z_t \sim Normal(\mu, \sigma) $$

 

이러한 random walk 모델에서 X_t 는 이전 time step 에서의 값 X_t-1 과 매우 큰 연관성을 갖는다. 따라서 non-stationary time series 데이터이다. 

 

Random walk model simulation in R

R 로 random walk 모델을 만들어보자. 아래는 1000개의 random walk 데이터를 생성하는 예제이다. 시계열 그래프를 그려보면, 이 데이터는 non-stationary time series 데이터라는 것을 확인할 수 있다. 구간을 나눠서보면 트렌드를 보이기 때문이다. 

x <- NULL
x[1] <- 0
for(i in 2:1000){
  x[i] <- x[i-1]+rnorm(1)
}

random_walk <- ts(x)
plot(random_walk, main="A random walk", ylab="", xlab=" Days", col="black")

위 그림은 전형적인 random walk 그래프이다.

 

random walk 데이터에서 correlogram 을 그려보자. 인접한 time step 에서 auto correlation coefficient 가 큰 패턴을 보이기 때문에 non-stationary time series 라는 것을 다시 확인할 수 있다. 

acf_result <- acf(random_walk)

random walk 모델에서 noise Z는 stationary time series 라고 볼 수 있다. 

 

$$ Z_t \sim Normal(\mu, \sigma) $$

 

noise 가 stationary time series 라는 것을 데이터로 실제로 확인해보자. 

random_walk_diff <- diff(random_walk)
plot(random_walk_diff, main="A random walk diff", ylab="", xlab=" Days", col="black")

 

 

참고자료

https://people.duke.edu/~rnau/411rand.htm

반응형
반응형

Auto correlation coefficient 

앞선 포스팅에서 auto covariance coefficient 에 대해 설명하였다. auto covariance coefficient 은 time series 데이터에서의 각각의 time point 간 연관성을 의미하는데, stationary time series 에서는 k 라고하는 parameter 에 의해 달라진다. auto covariance coefficient 의 추정값 c_k 는 아래와 같이 계산된다. 

 

$$ c_k = \frac{\sum^{N-k}_{t=1}(x_t - \bar{x})(x_{t+k}-\bar{x})} {N-k} $$

 

이번에는 auto correlation coefficient 에 대해 정리해보려고 한다. auto correlation coefficient 도 auto covariance coefficient 와 마찬가지로 time series 데이터에서 time step 별 값의 연관성을 의미하는데 범위를 -1~1로 조정한 것으로 이해할 수 있다. 마치 공분산과 상관계수의 관계와 같다.

 

auto correlation coefficient 의 계산식은 아래와 같다. 

 

$$ -1 \leq \rho_k = \frac{\gamma_k}{\gamma_0} \leq 1 $$

 

이 때, rho_k 의 추정값 r_k 는 아래와 같다. c0 는 time step (=lag) 이 0일 때의 auto covariance coefficient 로 이는 분산과 같다.  

 

$$ \rho_k \sim r_k = \frac{c_k}{c_0} $$

$$ c_0 = \frac{\sum^{N}_{t=1}(x_t-\bar{x})^2}{N}  $$

 

Correlogram

rho_k 의 추정값을 k 에 따라 구한 뒤, 이를 시각화해서 표현한 것을 correlogram 이라고 한다. 이 때, rho_0 은 항상 1이다. (자기 자신과의 연관성이기 때문이다.) 

 

$$ r_0 = \frac{c_0}{c_0} , r_1 = \frac{c_1}{c_0} ... $$ 

 

R 에서 correlogram 은 acf 함수를 통해 쉽게 그려볼 수 있다.

 

예제 1)

아래 R 코드는 100개의 표준정규분포를 따르는 데이터를 만든 후, correlogram 을 그리는 코드이다. 파란선은 연관성이 유의한지에 대한 임계치를 의미한다. 유의한 데이터 포인트가 하나 밖에 없고, lag 에 따른 패턴이 보이지 않으므로, 전체적으로 시계열 데이터가 자기상관성이 없다고 결론 내릴 수 있다.  

 

purely_random_process <- ts(rnorm(100))
print(purely_random_process)
plot(purely_random_process)

auto_correlation_coef_by_lags <- acf(purely_random_process)
print(auto_correlation_coef_by_lags)

예제 2)

실제 데이터를 correlogram 을 그려보자. 다음은 모 어플리케이션의 월간 활성 이용자수 (MAU, monthly active user) 추이이다. 이 서비스는 점점 성장하는 추이를 보여주고 있다. 시계열 데이터의 관점에서는 시간에 따른 평균의 변화 (trend) 를 보이는 non-stationary time series 이다. 

위 데이터에서 correlogram 을 그리면 아래와 같이 나타난다. lag 에 따른 auto correlation coef 의 패턴이 보이며 (점점 감소), 인접한 데이터 포인트에서는 유의한 상관성을 보이고 있는 것을 확인할 수 있다. 

반응형
반응형

Time series data (시계열 데이터) 

어떤 종류의 데이터이든 상관 없으며, 그저 시간에 따라 수집된 데이터를 시계열 데이터 (timeseries data) 라고 한다. 

한국의 일별 코로나19 신규 확진자수 추이

예를 들어, 일별 코로나 확진자수는 1일이라고 하는 time step 으로 수집된 시계열 데이터의 한 종류이다. 

 

Week stationary time series 

week stationary time series 란 다음의 조건을 만족한다. 

 

1) 시간에 따른 평균 (mean) 에 변화가 없다. 

2) 시간에 따른 분산 (variance) 의 변화가 없다. 

3) 주기적인 등락 (flucation) 이 없다.

 

이러한 조건을 만족하긴 위해서는 time series 의 한 섹션 (A 섹션) 고른 후, 다른 섹션 (B 섹션) 을 골랐을 때, A, B 섹션이 비슷하면 된다. 

 

Stochastic process

random variable 의 collection - X1,X2,X3 .. 가 있다고 하자. 이들이 각각 다른 모수를 가진 분포를 따를 때, 이를 stochastic process 라고 한다. stochastic process 의 반대개념은 deterministic process 이다. deterministic process 는 모든 step (t) 에 대해서 예측 가능하다. 예를 들어, 어떤 함수에 대한 미분함수는 특정 X 에서의 Y 값을 정확하게 알 수 있다. 이와 반대로 stochastic process 는 매 step 이 random 이기 때문에 어떤 확률 분포에서 왔다는 것만을 알 수 있을 뿐, 값을 정확하게 예측할 수 없다.

 

$$ X_t \sim distribution(\mu_t, \sigma_t) $$

 

예를 들어, 다음과 같은 시계열 데이터가 있다고 해보자. 

 

$$ X_1 = 30, X_2 = 29, X_3 = 57 ... $$ 

 

시계열 데이터를 바라보는 한 가지 관점은 stochastic process 의 실현 (realization) 으로 보는것이다. 매 timestep 별로 어떤 확률 변수가 정해지고 우리는 그 확률변수에서 나온 하나의 샘플값을 관찰하는 것이다. 

 

Autocovariance function

stationary time series 라는 가정을 하자. 두 가지 timestep s,t 에서의 covariance 를 정의해볼 수 있다. (확률 변수이기 때문)

 

$$ \gamma(s,t) = Cov(X_s, X_t) $$

$$ \gamma(s,s) = Var(X_s)   $$  

 

또한 아래처럼 covariance function 을 정의할 수 있는데, 이 함수는 stationary time series 라는 가정 하에 t 에 따라서는 값이 바뀌지 않으며, k가 결정하는 함수가 된다. (아래 식에서 c 는 추정값이다.) 이러한 time step (k) 에 따른 공분산의 식을  autocovariance function  이라고 한다. 

 

$$ \gamma_k = \gamma(t, t+k) \sim c_k $$ 

 

즉, stationary time series 에서는 Cov(X1, X2) 나 Cov(X10,X11) 이나 기댓값은 같다고 할 수 있다. 그 이유는 데이터에서 두 가지 섹션을 선택했을 때, 그 모습이 똑같다고 기대하는것이 stationary time series 이기 때문이다.  

 

또한 gamma(t_k, t) 는 autocovariance coefficient 라고 하며, stochastic process 에서의 실제 autocovariance 값이다. 데이터를 통해 구한 c_k 를 통해 autocovariance coefficient 를 추정한다. 

 

Autocovariance coefficient

그러면 Autocovariance coefficient 의 추정값은 어떻게 구할까? timestep 을 k 라고 할 때, 추정값은 아래와 같다. 

 

$$ c_k = \frac{\sum^{N-k}_{t=1}(x_t - \bar{x})(x_{t+k}-\bar{x})} {N} $$

 

이는 time series 데이터에서 k time step 만큼 차이나는 점들의 묶음 (x_t, x) 을 확률 변수의 관찰값으로 놓고 추정한 covariance 와 같다.

 

참고로 확률 변수 X,Y 의 covariance 의 추정값은 아래와 같이 구할 수 있다. 

 

$$ s_{xy} =  \frac{\sum^{N}_{t=1}(x_t - \bar{x})(y_t-\bar{y})} {N-1} $$

 

R 에서는 acf 함수를 통해 auto covariance coefficient 추정값을 계산할 수 있다. 

purely_random_process <- ts(rnorm(100))
print(purely_random_process)
plot(purely_random_process)

auto_covariance_coef_by_lags <- acf(purely_random_process, type = "covariance")
print(auto_covariance_coef_by_lags)
반응형
반응형

theme_bw(base_size = 12, base_family = "Kakao Regular") 또는

par("Kakao Regular") 를 적용해도 한글이 나오지 않는 이슈가 발생

library(showtext)
showtext_auto()

위 블록을 통해 해결할 수 있었음

반응형
반응형

하둡과 응용 프레임워크 3) 하둡 기반 응용 프로그램 

http://ricksnursery.com/software-configuration-management-tools/

 

하둡기반 응용프로그램의 분류 

1) Databases/Stores

Avro : 하둡 맵리듀스 컨텍스트에서의 데이터 구조 => 효율적인 데이터 프로세싱 가능

HBase : 분산 비관계형 데이터베이스 (non-relational DB)

Cassandra : 분산 데이터 관리 시스템 (data management system)

 

2) Querying

Pig : HDFS 위의 큰 데이터셋을 분석하는 플랫폼

Hive : 큰 데이터셋 관리 및 querying

Impala : Hadoop file format 에 querying (고성능, low-latency) 

Spark : General processing engine fof streaming, SQL, machine learning, graph processing

 

3) Machine Learning, Graph Processing

Graph : Iterative graph processing using Hadoop framework

Mahout: Framework for machine learning applications using Hadoop, Spark

Spark : General processing engine fof streaming, SQL, machine learning, graph processing

 

응용 프로그램 예

1) Apache Pig

Apache Pig 는 data processing 을 위한 플랫폼으로 Pig Latin 이라는 high-level language 를 통해 HDFS 데이터에 접근한다. 이 때, execution environment 로 Map Reduce, Tez 등을 가질 수 있다. 또한 in built operation (minimum, average 와 같은) 을 다양하게 지원한다. 이러한 다양한 function 을 지원하면, 여러가지를 Pig 환경에서 실행할 수 있기 때문에 더욱 효율적이라고 할 수 있다. Pig 의 활용분야는 다음과 같다.

 

1) Extract, Transform, Load (ETL)

2) Manipulating, analyzing "raw" data 

 

예제 코드

hdfs dfs -put /etc/passwd /user/cloudera
pig -x mapreduce

cloudera VM 에서 다음과 같은 명령어를 입력하면 pig 의 interactive shell 인 grunt 로 접속하게 된다. 위 커맨드는 /etc/passwd 폴더를 hdfs 에 저장하고, map reduce 를 execution engine (back-end) 으로 해서 pig 를 실행한다는 뜻이다. 

grunt > A = load '/user/cloudera/passwd' using PigStorage(':');
grunt > B = foreach A generate $0, $4, $5 ; 
grunt > dump B;

load 명령어를 통해 해당 file 을 hdfs 에서 load gkrh, foreach 에서 subset 을 extract 한다 (각 line 마다, 1,5,6번째 컬럼을 가져옴). 

결과는 /user/cloudera/passwd 에 저장된 정보의 일부를 위 그림처럼 출력하게된다. 결과를 파일형태로 저장하기 위해서는 아래와 같은 명령어를 수행할 수 있다. 

grunt > store B into 'userinfo.out'

 

2) Apache Hive

Apache Hive 는 HDFS 에 대한 SQL interface 인 HiveQL 을 통해 데이터를 manage, query 하는 플랫폼이다. 이러한 과정을 beeline 이라는 command line interface 를 통해 interactive 하게 수행할 수 있다. Hive 는 기본적으로 Data warehouse software 이다. execution environment 로는 Map reduce, Tez, Spark 를 가질 수 있다. HDFS, HBase 에 저장된 데이터를 다룰 수 있고, mapper, reduce 를 customization 할 수 있다. 

 

Hive 의 활용분야는 아래와 같다.

 

1) Data mining, Analytics

2) Machine Learning

3) Ad hoc analysis

 

예제 코드

hdfs dfs -put /etc/passwd /tmp/
beeline -u jdbc:hive://

앞선 pig 예제와 마찬가지로 /etc/passwd 를 hdfs 에 저장하고 beeline 커맨드를 실행한다. 

CREATE Table userinfo (uname STRING, paswd STRING, uid INT, gid INT, fullname STRING, hdir STRING, shell STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY ':' STORED AS TEXTFILE;

LOAD DATA INPATH '/tmp/passwd' OVERWRITE INTO TABLE userinfo;

SELECT uname, fullname, hdir FROM userinfo ORDER BY uname;

위 커맨드는 userinfo 라는 table 을 생성하고, 파일로부터 데이터를 읽어들여 select 문을 통해 출력하는 예제이다. 

 

본 예제에서는 beeline command 를 사용했지만 이외에도 Hive command line interface, Hcatalog, WebHcat 도 있다. 

 

3) Apache HBASE

Hbase 는 scalable data store 이며 non-relational distributed databased 이다. HDFS 위에서 동작하며 In-memory operation 을 제공한다. 이는 cache 와 같은 개념이기 때문에 더 빠르게 같은 일을 처리할 수 있다. Hbase 의 특징은 1) replication 2) security 3) SQL like access 이다. 

 

예제 코드

- 테이블 생성

create 'usertableinfo', {NAME=>'username'}, {NAME=>'fullname'}, {NAME=>'homedir'}

- 데이터 삽입

put 'userinfotable', 'r1', 'username','vcsa'

- 데이터 조회 : 모든 컬럼, 특정 컬럼 조회

scan 'userinfotable'
scan 'userinfotable' , {COLUMNS=>'fullname'}

 이 예제는 Hbase Shell 을 이용할 때이지만, Hbase map reduce, Hbase api, Hbase external API 등을 이용할 수도 있다. 

반응형
반응형

MAC OS 환경변수 설정하기

 

텍스트 파일이 자동으로 실행됨MAC Os에서 터미널이 실행될 때, ~/.zshrc 라는 텍스트 파일이 자동으로 실행됨

예를들어, 홈폴더 아래 anaconda/bin 폴더를 PATH 환경변수에 추가하고 싶은 경우, 아래 문구를 ~/.zshrc 에 넣어주면된다.

export PATH="/Users/username/anaconda3/bin:$PATH"

 

또는 Linux 와 같이 /etc/profile 또는 ~/.bash_profile 에 환경 변수를 넣는것도 좋은 방법이다. 이후에 ~/.zshrc 파일을 열고

source /etc/profile
source ~/.bash_profile 

 

문구를 쓰면 위 텍스트 파일을 터미널을 열면 자동으로 명령 실행하기 때문에 환경변수로 반영된다.

반응형
반응형

하둡과 응용 프레임워크 2) 하둡 실행 환경 (YARN, Tez, Spark)

이전 포스팅에서 Map reduce 프레임워크의 한계에 대해 설명하고, 이를 보완하기 위하여 YARN, Tez, Spark 등이 사용된다는 것에 대해 간단하게 언급하였다. 하둡 아키텍쳐에 대해 다시 remind 를 해보자. 

 

Hadoop architecture

위 그림과 같이 데이터가 node 에 분산되어 저장되어있고, task 가 data node 에 할당되어 처리를 한 후에, 이 결과를 merge 하는 것이 하둡이 어떤 job 을 실행하는 방법이다. 이것이 이전 포스팅에서 언급한 '계산을 데이터로 보내는 것' (computation to data) 의 개념이라고 볼 수 있다. 이러한 방법은 불가능한 것을 가능할 수 있고, 무엇보다 더욱 효율적으로 (빠르게) job 을 처리할 수 있다. 병렬적으로 수행할 수 있고, 데이터의 이동이 최소화되기 때문이다. 하지만 문제는, MapReduce execution framwork 는 Map reduce paradigm 을 구현할 수 있는 application 에만 유용하다. 어떤 application 이 map reduce 를 통해 구현할 수 없는 경우에 문제가 생긴다. 이를 보완하기 위하여 YARN, Tez, Spark 등이 사용된다. 

 

Next Generation Execution Framworks

 

 

YARN 은 기본적인 Hadoop 의 execution engine 이다. 이 위에 YARN 위에서 동작하는 HBase 와 같은 application 이 있다. 또한 YARN 위에서는 Tez 와 Spark 와 같은 다른 framework가 올라갈 수도 있다. Pig 나 Hive 같은 application 은 TEZ 와 Spark (Hive 의 경우 TEZ와 Spark 모두 이용) 위에서 동작한다. 또한 Spark 는 YARN 없이도 동작할 수 있는 execution framework 이다. 

 

Tez 의 특징은 dataflow graph 를 지원하고, custom data type 을 지원한다. 따라서 맵 리듀스 프레임워크에서 처럼 모든 데이터의 입출력이 key-value pair 로 이루어져야하는 제약이 없다. Tez 를 활용하는 것의 장점은 자원을 효율적으로 관리하고 복잡한 태스크를 DAG (directed acyclic graph) 를 활용해서 실행할 수 있다는 것이다.  

 

Hive on Tez example 

Hive 는 backend execution engine 으로 Tez 를 이용하는 것을 지원한다. 예를 들어 아래 코드를 보자.

SELECT a.vendor, COUNT(*), AVG(c.cost) FROM a 
JOIN b ON (a.id = b.id)
JOIN c ON (a.itemid = c.itemid)
GROUP BY a.vendor

1) Original Hadoop MapReduce 를 사용한 해법

위의 쿼리는 여러개의 map reduce job 으로 나뉘어진다. 하나의 map reduce job 이 다른 job 의 인풋이 되고, 이것들이 조합이 되어 최종적인 쿼리의 결과를 가져올 수 있다. 

 

2) Tez 를 사용한 해법

Tez 를 사용하면 조금 더 간단하게 같은 작업을 수행할 수 있다. original map reduce 만을 사용했을 때와의 차이점은 intermediate map task 가 없다는 것이다. map reduce 의 경우 원래는 결과를 hdfs 에 저장하도록 되어있는데, 그러지 않고 데이터를 재사용함으로써 graph 를 간편화할 수 있고 이를 통해 효율적으로 같은 job을 수행할 수 있는 것이다. 

 

Spark 의 경우 advanced DAG execution engine 이며 cyclic data flow 를 지원한다. 또한 in-memory computing 을 지원한다. 우선 데이터 처리를 memory 위에서 할 수 있기 때문에 매우 빠르고, DAG 사이에 데이터 공유도 가능하다는 장점이 있다. 또한 Java, Scala, Python, R 언어를 지원하기 때문에 범용성이 높은 execution engine 이라고할 수 있다. 예를 들어 Spark python interface 를 통해 Logistic regression 을 수행하는 코드를 확인해보자. 

points = spark.textFile(...).map(parsePoint).cache()
w = numpy.random.ranf(size = D) # current separating plane 
for i in range(ITERATIONS):
  gradient = points.map(
  	lambda p: (1 / (1 + exp(-p.y*(w.dot(p.x)))) - 1) * p.y * p.x 
    ).reduce(lambda a, b: a + b)
  w -= gradient
print "Final separating plane: %s" % w

original map reduce 는 iterative data process 에 적용하기 매우 힘들다는 단점이 있었다. 바로 위 코드에서 iteration 이 등장하는데, 같은 데이터셋을 이용해서 gradient 를 여러번 반복해서 구해서 weight 를 업데이트하는 logistic regression 의 training 과정이다. 우선 같은 데이터셋을 여러번 반복해서 사용하기 때문에 .cache() 함수를 통해 데이터를 RAM 에 저장시킨다.  위 코드는 spark 공식 홈페이지의 예제 (http://spark.apache.org/examples.html)인데 original map reduce 와 100배 정도의 속도차이가 난다고 한다. 이러한 이유로 in-memory computing 이 가능한 경우 선호된다. 이 링크에서는 다양한 Spark 예제를 확인할 수 있다. 또한 spakr 는 Machine learning 을 위한 라이브러리도 제공하기 때문에 이를 직접 구현하지 않고도, high-level interface 를 사용할 수도 있다 (https://spark.apache.org/docs/2.1.0/ml-classification-regression.html).

 

References

코세라 - Hadoop Platform and Application Framework 강의를 참고하였습니다. 

반응형
반응형

Docker 를 통한 Hive 실습환경 구축 및 간단 예제

 

본 포스팅에서는 Hive 핵심정리 (다융 두 저, 에이콘 출판사) 의 3장 예제를 Docker 를 이용해 실습해 보았다. 

 

1. Docker 설치 

2. Apache Hive 2.3.2 docker container 다운로드 (https://github.com/big-data-europe/docker-hive)

3. "docker-compose.yml" 파일에서 코드 샘플 경로 마운팅 (C:\workspace\HiveBook\HiveEssentials-master\scripts 을 container 의 /HiveBook 폴더로 마운트) 샘플 코드는 Hive 핵심정리 (에이콘 출판사) 샘플코드 (https://github.com/willddy/HiveEssentials)를 활용하였음.

 

- 샘플코드를 container 에 mount 하기 위해서는 아래 hive-server 에서 volumes 으로 경로를지정하면됨

version: "3" 

services: 
  namenode: 
    image: bde2020/hadoop-namenode:2.0.0-hadoop2.7.4-java8 
    volumes: 
      - namenode:/hadoop/dfs/name 
    environment: 
      - CLUSTER_NAME=test 
    env_file: 
      - ./hadoop-hive.env 
    ports: 
      - "50070:50070" 
  datanode: 
    image: bde2020/hadoop-datanode:2.0.0-hadoop2.7.4-java8 
    volumes: 
      - datanode:/hadoop/dfs/data 
    env_file: 
      - ./hadoop-hive.env 
    environment: 
      SERVICE_PRECONDITION: "namenode:50070" 
    ports: 
      - "50075:50075" 
  hive-server: 
    image: bde2020/hive:2.3.2-postgresql-metastore 
    env_file: 
      - ./hadoop-hive.env 
    environment: 
      HIVE_CORE_CONF_javax_jdo_option_ConnectionURL: "jdbc:postgresql://hive-metastore/metastore" 
      SERVICE_PRECONDITION: "hive-metastore:9083" 
    ports: 
      - "10000:10000" 
    volumes: 
      - C:\workspace\HiveBook\HiveEssentials-master\scripts:/HiveBook 
  hive-metastore: 
    image: bde2020/hive:2.3.2-postgresql-metastore 
    env_file: 
      - ./hadoop-hive.env 
    command: /opt/hive/bin/hive --service metastore 
    environment: 
      SERVICE_PRECONDITION: "namenode:50070 datanode:50075 hive-metastore-postgresql:5432" 
    ports: 
      - "9083:9083" 
  hive-metastore-postgresql: 
    image: bde2020/hive-metastore-postgresql:2.3.0 
  presto-coordinator: 
    image: shawnzhu/prestodb:0.181 
    ports: 
      - "8080:8080" 

volumes: 
  namenode: 
  datanode:

 

4. hive-server 실행

docker-compose up -d
docker-compose exec hive-server bash

 

docker-compose up -d 는 각각의 docker-compose.yml 에 위치한 container 를 background 실행하는 명령어

 

The docker-compose up command aggregates the output of each container (essentially running docker-compose logs -f). When the command exits, all containers are stopped. Running docker-compose up -d starts the containers in the background and leaves them running.

 

Command Line Interface (cli) 에서 실행

 

1. beeline으로 실행하기

 

/opt/hive/bin/beeline -u jdbc:hive2://localhost:10000

 

2. hive 로 실행하기

hive

 

Hive cli 의 경우 하이브 클라이언트는 하이브가 설치된 동일한 장비여야한다. 하지만 비라인의 경우 하이브 서버를 JDBC 커넥션으로 연결하고 클라이언트와 동일 장비에 하이브 라이브러리를 설치할 필요가 없다. 따라서 비라인은 하둡 클러스터 바깥에서 원격으로 실행할 수 있다. 이외의 다양한 hive client 들에 대한 설명은 https://cwiki.apache.org/confluence/display/Hive/HiveServer2+Clients에서 찾아볼 수 있다. 

 

예를 들어, beeline 으로 실행하면 아래와 같은 명령어와 함께 beeline 커맨드가 실행된다.

 

Connecting to jdbc:hive2://localhost:10000 
Connected to: Apache Hive (version 2.3.2) 
Driver: Hive JDBC (version 2.3.2) 
Transaction isolation: TRANSACTION_REPEATABLE_READ 
Beeline version 2.3.2 by Apache Hive 
0: jdbc:hive2://localhost:10000>

 

sample code 를 mounting 했기 때문에 아래 경로에서 파일을 확인할 수 있다.

 

/HiveBook/Chapter_03/employee.txt

더보기

Michael|Montreal,Toronto|Male,30|DB:80|Product:DeveloperLead
Will|Montreal|Male,35|Perl:85|Product:Lead,Test:Lead
Shelley|New York|Female,27|Python:80|Test:Lead,COE:Architect
Lucy|Vancouver|Female,57|Sales:89,HR:94|Sales:Lead

Table 생성 및 데이터 삽입

CREATE TABLE employee
(
  name string,
  work_place ARRAY<string>,
  sex_age STRUCT<sex:string,age:int>,
  skills_score MAP<string,int>,
  depart_title MAP<STRING,ARRAY<STRING>>
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '|'
COLLECTION ITEMS TERMINATED BY ','
MAP KEYS TERMINATED BY ':';

--Verify tables creations run in Beeline
!table employee

--Load data
LOAD DATA LOCAL INPATH '/HiveBook/Chapter_03/employee.txt' OVERWRITE INTO TABLE employee;

--Query the whole table
SELECT * FROM employee;

반응형
반응형

하둡  플랫폼과 응용 프레임워크 - Hadoop Basic module

 

하둡은 Doug Cutting and Mike Cafarella 에 의해 2005 년에 만들어졌다. 하둡의 핵심 아이디어는 '데이터를 계산하는 것' (data to computation)이 아니라 '계산을 데이터로 보내는 것' (computation to data) 이다.  Hadoop 의 핵심은 다음과 같다. 

 

Scalability : 어떠한 클러스터 환경에서도 적용 가능하다. 

Reliability : 분산 환경에서의 근본적인 가정은 Hardware 의 고장이 자주 생긴다는 것이다.  이것은 당연한 것이고, Hadoop 은 이를 핸들링하는 방법을 제공한다. (이를 Resilence 라고 부르기도한다.)

 

Hadoop distributed file system (HDFS) 와 Map reduce framework 는 기존의 google 의 computing system 과 file system 을 기반으로 만들어졌다. 

 

Hadoop 의 기본 모듈

 

1. Hadoop Common : 다른 module 이필요한 library, utility 를 갖고 있다. 

2. Hadoop Distributed File system : big data 를 클러스터에 분산해서 저장할 수 있는 파일 시스템이다. 

3. Hadoop YARN : 클러스의 resource management platform 이다. 

4. Hadoop MapReduce :  hadoop 의 분산 컴퓨팅 프레임워크다. 

 

HDFS

: Distributed, scalable, and portable file system written in Java for the Hadoop framework. 

 

일반적인 window, linux file system 은 C나 C++ 로 쓰여져있는데, HDFS 는 hadoop framework 를 위해 Java 로 만들어진 file system 이다. 각각의 HDFS 는 GB 에서 PB 에 이르는 매우 큰 파일을 저장한다. Data node 를 Replication 함으로써 reliability 를 확보한다. 

 

Hadoop 1.0 vs Hadoop 2.0

 

 

 

Hadoop 2.0 에서 바뀐 점은 YARN 이라는 cluster resource management 모듈이 생긴 것이다. 또한 Global manager 가 아니라 per application manager 로 바뀌었다.YARN 은 Map reduce 에 한정되지 않게 hadoop cluster 을 강화시키기 위한 목적으로 scalability 와 관련이 있다. YARN 은 cluster의 resource 를 capacity, guarantees, fairness 와를 기준으로 활용도를 향상시키도록 만든다. Hadoop 2.0에서는 Map reduce 뿐 아니라 graph process 나 iterative modeling 과 같은 다양한 프로그래밍 방법을 적용할 수 있다. 

 

 

 

Hadoop "Zoo" 

 

 

HDFS 와 Map reduce 에 대해서는 어떤것인지 다루었다. 그런데 그 위에서 작동하는 Oozie, Pig, Hive 는 무엇인가? 이러한 Hadoop eco system 은 Google 의 기술 스택에서 출발했다. Chubby, MapREduce, MySQL Gateway, Bigtable 과 같은 구글의 original 기술 스택을 기반으로 hadoop eco system 이 발전했다. 아래는 구글과 페이스북의 데이터 관련 기술 Stack 의 예시이다. 

 

 

 

맵리듀스와 하둡 execution environment

 

맵리듀스는 Job tracker, task tracker 로 나뉘며, Job tracker 는 master node (name node) 에 task tracker 는 data node 에서 실행된다. HDFS 환경에서 맵리듀스의 한 가지 장점은 실제 computation 이 각각의 data node 에서 그 node 에 있는 data 를 통해서 처리되기 때문에 data 이동을 최소화할 수 있다는 것이다. 또한 하나의 노드에 fitting 이 되지 않는 데이터를 처리할 수 있다. (맵리듀스 관련 이전 포스팅 보기) 하지만 맵리듀스는 Java 를 기반으로 규약에 맞게 프로그래밍을 한 후에 job 을 submission 하는 방식으로 구동되기 때문에 매번 이러한 프로그램을 만들어야한다는 부담이 있다. 따라서 맵 리듀스를 내부적으로 구현한 어플리케이션이 등장했다. 하지만 또 문제는 맵리듀스 만으로 해결할 수 없는 문제가 있을 수 있다는 것이다. 대부분의 데이터 프로세싱이 맵리듀스 방법을 통해 해결 가능했으나, 아닌 문제도 많았다. 

 

예를 들어 다음과 같다. 

 

1) Interactive data exploration : 탐험적 데이터 분석을 하는 경우 데이터로부터 결과를 구하는 작업을 여러분 수행한다. 그때마다 Map reduce 방법을 이용해서 데이터를 불러오는 것은 비효율적이다.  

2) Iterative data processing : 데이터 프로세싱을 반복적으로 수행하는 경우도 마찬가지로 맵리듀스 방법이 적절하지 못하다. 이와 같은 상황에서 메모리에 데이터를 불러온 후에 이를 통해 프로세싱을 하는 편이 더욱 효율적일 것이다. 

 

이러한 문제점을 해결하고자 나온 것이 YARN, Tez, Spark 와 같은 next generation execution framework 이다. 이러한 프레임워크에서는 task 의 복잡한 Directed acyclic graph (DAG) 를 지원하고, data 의 in memory processing 을 지원한다. 다음 포스팅에서는 YARN, Tez, Spark 를 다루어보려고한다.

 

References

코세라 - Hadoop Platform and Application Framework 강의를 참고하였습니다. 

반응형
반응형

[딥러닝강의] GPU 와 딥러닝 소프트웨어

Deep Learning Frameworks (https://analyticsindiamag.com/evaluation-of-major-deep-learning-frameworks/)

CPU vs. GPU

 

왜 딥러닝에서 CPU 가 아닌 GPU 를 사용할까? GPU 의 원래 목적은 그래픽을 rendering 하는 것이다. GPU 를 만드는 회사는 크게 NVIDIA 와 AMD 로 나뉜다. 여러 커뮤니티에서 NVIDIA 와 AMD 중에 무엇이 더 나은지 논쟁을 한다. 하지만 딥러닝 측면에서는 NVIDIA 의 GPU 가 더욱 좋다. AMD GPU 는 딥러닝 목적으로 사용하기 힘들다. 따라서 딥러닝에서 GPU 를 말하면 대부분 하나의 회사 NVIDIA 의 GPU 를 의미한다. 

 

Rendering 이란?

평면인 그림에 형태·위치·조명 등 외부의 정보에 따라 다르게 나타나는 그림자 색상 농도 등을 고려하면서 실감나는 3차원 화상을 만들어내는 과정 또는 그러한 기법을 일컫는다. 즉, 평면적으로 보이는 물체에 그림자나 농도의 변화 등을 주어 입체감이 들게 함으로써 사실감을 추가하는 컴퓨터그래픽상의 과정이 곧 렌더링이다. [네이버 지식백과] 렌더링 [rendering] 

 

CPU 와 GPU 의 차이

CPU 와 GPU 의 차이

1) 코어의 종류와 숫자

 

CPU 는 GPU 보다 더 적은 코어를 갖고 있지만 각각의 코어가 GPU 보다 더 강력한 컴퓨팅 파워를 갖고 있다. 따라서 CPU 는 순차적인 작업 (Sequential task) 에 더 강점이 있다. 반면 GPU 는 CPU 보다 코어수는 많지만 각각의 코어가 GPU 보다 더 성능이 낮기 때문에 병렬적인 작업 (Paralell task) 에 더 강점이 있다. 현재 PC 에서 사용되는 CPU 의 코어는 보통 4~10개 정도이며 hyperthreading 기술을 통해 thread 를 2배 정도 늘릴 수 있다. 예를 들어 8 코어 16 threads CPU 의 경우, 병렬적으로 16개의 task 를 수행할 수 있다는 뜻이다. 반면, 예를 들어 NVIDIA 의 Tital XP GPU 의 경우 3840 코어를 갖고 있다. 또 최근 출시된 2080 TI 의 경우 4,352 개의 코어를 갖고 있다. threading 을 감안하더라도 CPU와 GPU 의 코어 수의 차이는 200 배 이상이다. 

 

2) 메모리

 

CPU 와 GPU 의 중요한 차이 중 하나는 바로 메모리를 어떻게 사용하는지에 관한 것이다. CPU 는 캐시 메모리가 있지만 대부분의 시스템과 공유된 메모리를 사용한다. PC 의 경우 8GB, 16GB RAM 이 일반적인 메모리의 종류이다. GPU 의 경우 시스템과 메모리를 공유할 수도 있지, 이 경우 GPU 와 메모리 사이의 Bottleneck 이 생기기 때문에 성능이 낮아진다. 따라서 GPU 는 GPU card 내에 자체의 메모리가 존재한다. 예를 들어 Tital XP GPU 의 경우 12 GB 의 메모리를 갖고 있다. 

 

CPU 의 강점은 갖는 것은 여러가지 일 (음악 감상, 영화 감상, 딥러닝, 게임 등)을 할 수 있으며, 순차적인 처리를 빠르게 할 수 있다는 것이다. 반면, GPU 는 여러가지 일을 다 잘하진 못해도 병렬화를 할 수 있다면, 이를 빠르게 처리할 수 있다. 병렬화 가능한 일 중 하나가 바로 행렬 곱 (Matrix multiplication) 이다. 

 

병렬화 가능한 행렬곱

행과 열의 곱을 각각의 GPU 코어에서 처리 후 이를 합친다면 순차적으로 처리하는 것보다 더 빠르게 수행할 수 있을 것이다. GPU 를 이용한 프로그래밍을 하는 방법은 NVIDIA 의 CUDA 라이브러리를 사용하는 것이다. CUDA 를 이용하면 C, C++ 등의 언어로 GPU 프로그래밍을 할 수 있다. 또한 CUDA 보다 high-level API 로 cuBLAS, cuDNN 등 이 있다. high-level API 의 경우 CUDA 를 기반으로 행렬 연산, 딥러닝 등을 구현하는 것에 초점을 맞추어져 있기 때문에 이러한 작업들에 GPU 를 더욱 쉽게 이용할 수 있다. 하지만 CUDA 를 사용한 프로그래밍은 구현하기가 쉽지 않다. 예를 들어 캐시 메모리와 같은 메모리 계층 구조를 잘 이용하지 않으면 효율적인 코드를 작성하기 어렵다. 

 

따라서 딥러닝을 위해서 CUDA 코드를 처음부터 작성해서 이용하지 않는다. 먼저 NVIDIA 에서 CUDA 를 활용하기 위한 high-level API (cuDNN) 를 만들어 놓았기 때문에 이를 이용하면 되기 때문이고, 또한 cuDNN 을 활용한 다양한 딥러닝 프레임워크들이 이미 나와있기 때문이다. 

 

딥러닝 프레임워크

이름 단체
Caffe2 Facebook
PyTorch Facebook
TensorFlow Google
CNTK Microsoft
Paddle Baidu
MXNet Amazon

최근 딥러닝 프레임워크는 빠르게 생겨나고 있다. Tensorflow (Keras) 와 PyTorch 가 최근 가장 많이 사용되는 딥러닝 라이브러리가 볼 수 있다. 최근 MXNet 기반 Computer Vision toolkit 인 GluonCV 도 ICCV 에서 발표되는 등 많은 발전이 있는듯하다. GluonCV 는 컴퓨터 비전 분야의 State-of-the-art 를 사용하기 쉽게 만든 MXnet 의 high-level 라이브러리로 볼 수 있다. 

 

딥러닝 프레임워크를 사용하면 우리는 딥러닝을 효율적으로 구현할 수 있다. 상세하게는 아래와 같은 장점이 있다. 

 

1) 딥러닝 모델을 쉽게 만들 수 있다

2) Gradient 를 빠르게 구할 수 있다.

3) GPU 이용을 쉽게하고 효율적으로 동작할 수 있다 (cuDNN, cuBLAS 를 wrapping 해서 구현 → 효율 좋음). 

 


파이토치 (Pytorch)

 

파이토치 (https://pytorch.org/) 도 위와 같은 이유로 사용되는 대표적인 딥러닝 프레임워크 중 하나이며 최근 많은 인기를 얻고 있다. 파이토치가 인기를 얻게 된 이유는 기술을 단순화 시켜서 사용하도록 만든 사용 편리성과 함께, '동적 계산 그래프 (Dynamic computational graph)' 를 사용한다는 점이다. 텐서플로우의 경우 정적 계산 그래프 (Static computational graph) 으로 한 번 모델을 만든 후, 여러번 돌리는 방식인 반면, 동적 계산 그래프트는 한 번의 forward path 마다 새로운 그래프를 다시 그린다. 

 

cs231n lecture 8. Deep Learning Software

 

동적 계산 그래프 (Dynamic computational graph)

 

동적 계산 그래프는 어떤 장점을 가질까? 동적 계산 그래프는 복잡한 아키텍쳐를 구축할 때 더욱 유연하다. 예를 들어, RNN 을 활용한 Image captioning 의 경우 input 에 따라 output sequence (텍스트) 의 길이가 달라진다. 따라서 computational graph 가 input 이미지에 따라 동적으로 변한다는 것이다. 이 경우 forward path 마다 구조가 바뀌는 것이 더 효율적이므로 동적 계산 그래프가 더욱 적합하다. 

 

image captioning (https://towardsdatascience.com/image-captioning-in-deep-learning-9cd23fb4d8d2)

이와 비슷한 Visual Question Answering (VQS) 분야에 Neuromodule 도 동적 계산 그래프가 적합한 예이다. Neuromodule 은 "이미지" 와 "질문" 두 가지를 입력하면 답변을 위한 custom architecture 를 만들고 답을 출력하고자 하는 모델이다. 예를 들어, 고양이 사진을 주고 "고양이의 색깔은?" 과 같은 질문을 던지는 것이다. 이 경우에도 마찬가지로 네트워크가 동적으로 구성되어야 할 것이다. 어떤 사진을 주고 "이 이미지에서 고양이의 수가 강아지의 수보다 많은가?" 라는 질문을 던지면 앞선 네트워크와는 다르게 구성되어야 한다. 이처럼 동적 계산 그래프를 활용하면 다양한 네트워크를 구성할 수 있다. 

 

파이토치는 연구를 위한 목적으로 만들어진 라이브러리이다. 그래서 요청에 따라 빠르게 응답해야하는 프로덕트 용으로는 적합하지 않을 수 있다. 하지만 Open Neural Network Exchange (https://onnx.ai/) 라는 새로운 프로젝트가 나오면서 이런 제약이 줄어들고 있다. onnx 는 머신러닝 모델의 interoperability 를 위한 프로젝트로 모델을 ONNX Format 로 export 한 후 다른 환경에서 import 할 수 있도록 한다. 이를 활용하면 파이토치 모델을 프로덕션용 Caffe2 모델로 변환해서 배포할 수 있다. ONNX Format 은 파이토치 외에도 CNTK, MXNet, 텐서플로, 케라스, Scikit-Learn 에도 활용할 수 있다. 

 

파이토치의 설치

 

환경 : Ubuntu 16.04, Jupyter Lab (with JupyterHub), Python 3.8, Cuda 

 

1) 파이썬 가상 환경 (virtual environment) 생성 & Jupyter Lab 등록

 

 

conda create --name pytorch python==3.8
source activate pytorch
pip install ipykernel
python -m ipykernel install --name pytorch

 

2) CUDA version check 

 

nvcc --version 


nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2017 NVIDIA Corporation
Built on Fri_Sep__1_21:08:03_CDT_2017
Cuda compilation tools, release 9.0, V9.0.176

 

3) Install Pytorch 

 

pytorch 홈페이지에서 환경을 클릭하면 설치할 수 있는 커맨드를 출력해준다. CUDA 9.0 을 사용하고 있는데, CUDA 9.2 를 선택해서 나온 커맨드로 설치해도 무방한듯 하다. 

 

https://pytorch.org/

 

conda install pytorch torchvision cudatoolkit=9.2 -c pytorch

 

설치 완료 후 주피터 랩에서 pytorch kernel 을 실행 후, import pytorch 로 임포트가 잘 되는 것을 확인하자. 

 

Reference

 

반응형
반응형