하둡 3.1.2 설치 2편 - 독립실행모드(Standalone), 가상분산모드(Pseudo-distributed), 완전분산모드(Fully distributed)

1. 독립실행모드편
-> 하둡 3.1.2 설치 1편 - 독립실행모드(Standalone), 가상분산모드(Pseudo-distributed), 완전분산모드(Fully distributed)

2. 가상분산모드편
-> 하둡 3.1.2 설치 2편 - 독립실행모드(Standalone), 가상분산모드(Pseudo-distributed), 완전분산모드(Fully distributed)

3. 완전분산모드편
-> 하둡 3.1.2 설치 3편 - 독립실행모드(Standalone), 가상분산모드(Pseudo-distributed), 완전분산모드(Fully distributed)

저번에는 Hadoop을 Standalone Mode로 설치하였다.
이어서 Pseude-distributed Mode로 설치해보자. 
Single이지만 Cluster이기 때문에 Single Node Cluster라고도 부른다.

가상분산모드는 장비 1대를 가지고 흉내만 내는 것이지만 설치할 때는 분산처리를 할 수 있도록 해야하기 때문에 ssh도 설치해야한다.

저번 편에서 설치한 독립실행모드에 그대로 설치해도되고 아니면 리눅스를 새로 설치하고 jdk와 하둡만 설치해서 따로 설치해도된다. 설치내용은 100% 똑같기때문에 이어서 설치하도록 한다.

먼저 yum install openssh*를 설치한다.

공개키와 비밀키를 생성한다.
ssh-keygen -t rsa -P ""를 수행하여 디폴트로 생성을 한다.

수행하면 아래에 SHA256으로 암호화된 것이 fingerprint(지문)이다.

인증기로 등록한다.

ssh 접속이 되는지 확인을 한다.
최초에만 연결하겠냐고 물어보고 이후에는 물어보지 않는다.

이제 하둡 설정파일을 세팅해야한다.
먼저 hadoop-env.sh에 자바 홈을 알려준다.
vi로 편집하다가 gedit으로 열어서 line number 표시를 하니까 편하다.

3.1.2 버전기준으로 54번째 line에 위치한다.(위치는 버전마다 다르다.)

core-site.xml에 네임노드(마스터노드) 위치를 알려준다.

configuration이 비어있는데 여기에 네임노드 위치를 알려준다.

hdfs-site.xml에 각 파일을 몇 개로 복제할 것인지 설정한다.
기본 3개인줄 알았는데 1개로도 설정이 가능하다.

아래처럼 configuration을 수정해준다.

이제 네임노드를 포맷하고 하둡 클러스터를 시작해보자.
먼저 네임노드를 포맷한다. (hdfs namenode -format)

그리고 하둡 클러스터를 다시 수행해보면 노드들이 하나씩 올라온다.

jps명령어를 수행해보면 jvm위에 올라가있는 프로세스를 확인할 수 있다.

NameNode, SecondaryNameNode, DataNode가 올라와있는 것을 확인할 수 있다.

참고로 start-dfs.sh는 hdfs를 실행하는 명령어이고 끄는 것은 stop-dfs.sh이다.

HDFS만 실행 : start-dfs.sh
HDFS만 중단 : stop-dfs.sh
맵리듀스만 실행 : start-mapred.sh
맵리듀스만 중단 : stop-mapred.sh

HDFS와 맵리듀스 모두 실행 : start-all.sh
HDFS와 맵리듀스 모두 중단 : stop-all.sh

웹상에서 확인하는 방법은 http://localhost:9870에 들어가보면 확인할 수 있다.

2.9대 버전까지는 port가 50070이었으나 3.대 알파버전부터 바뀌었다.(링크)

다음으로 리소스매니저를 수행해본다.

jps로 확인해보면 NodeManger, ResourceManager가 구동된 것을 확인할 수 있다.

웹상에서 보려면 port 8088로 확인할 수 있다.

테스트 겸 독립실행모드에서 수행했던 wordcount를 수행해보자.

먼저 hdfs에 디렉토리를 생성한다.(centos7 로컬이 아니라 하둡에 만드는 것이다.)

localhost:9870에서 /user, /user/root, /user/root/conf, /input을 생성된 것을 확인할 수 있다.

테스트를 위해 로컬에 있는 파일을 hdfs로 올려보자.

localhost:9870에서 README.txt가 올라온 것을 확인할 수 있다.

또는 명령어로도 확인이 가능하다.

독립실행모드에서 수행했던 명령어의 인풋과 아웃풋을 바꿔서 수행해보자.

hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.2.jar wordcount /input/README.txt ~/wordcount-output

hdfs dfs -ls ~/wordcount-output로 _SUCCESS가 된 것을 확인할 수 있다.

아래 명령어를 통해 결과를 확인해보자.

단어의 갯수가 세어진 것을 확인할 수 있다.

또는 localhost:9870에 /root/wordcount-output에서 결과를 확인할 수 있다.

전편 포스팅에서 독립실행모드를 설치하였고 이번 포스팅에서 가상분산모드를 설치하였다.
다음 포스팅에서는 실제 운영할 수 있는 완전분산모드를 설치해보도록 하자.

전편 포스팅(독립실행모드 설치)
-> 하둡 3.1.2 설치 1편 - 독립실행모드(Standalone), 가상분산모드(Pseudo-distributed), 완전분산모드(Fully distributed)

이번 포스팅(가상분산모드 설치)
-> 하둡 3.1.2 설치 2편 - 독립실행모드(Standalone), 가상분산모드(Pseudo-distributed), 완전분산모드(Fully distributed)

다음 포스팅(완전분산모드 설치)
-> 하둡 3.1.2 설치 3편 - 독립실행모드(Standalone), 가상분산모드(Pseudo-distributed), 완전분산모드(Fully distributed)

하둡 3.1.2 설치 1편 - 독립실행모드(Standalone), 가상분산모드(Pseudo-distributed), 완전분산모드(Fully distributed)

하둡설치 방식에는 3가지가 존재한다. 독립실행모드, 가상분산모드, 완전분산모드이다.

실제 운영환경에서는 성능을 위해 완전분산모드로 설치해야할 것이고 기본 실행모드는 독립실행모드이다. 각 모드를 모두 설치해볼 것이다.

독립실행모드는 하둡이 설치된 로컬에서만 실행되기 때문에 로컬모드라고도 부르는데 하둡에서 제공하는 데몬을 구동하지 않기 때문에 분산 환경에서 맵리듀스를 하지 않는다.

가상분산모드는 하나의 장비만 필요하긴 하지만 그 장비에 모든 하둡 환경설정을 한다. 모조분산모드(의사분산모드)라고도 불리는데 하나의 장비지만 완전분사모드 형태로 돌아간다.

마지막으로 완전분산모드는 여러 대의 장비에 하둡을 설치하고 각 장비가 맵리듀스를 수행하게 되는 경우이다. 실제 운영환경에서 성능을 내기 위해서 완전분산모드로 세팅을 해야한다.

포스팅을 총 3편으로 나눠서 독립실행모드, 가상분산모드, 완전분산모드를 모두 설치해볼 것이다.

1. 독립실행모드편

-> 하둡 3.1.2 설치 1편 - 독립실행모드(Standalone), 가상분산모드(Pseudo-distributed), 완전분산모드(Fully distributed)

2. 가상분산모드편
-> 하둡 3.1.2 설치 2편 - 독립실행모드(Standalone), 가상분산모드(Pseudo-distributed), 완전분산모드(Fully distributed)

3. 완전분산모드편
-> 하둡 3.1.2 설치 3편 - 독립실행모드(Standalone), 가상분산모드(Pseudo-distributed), 완전분산모드(Fully distributed)


먼저 독립실행모드 설치부터 하나씩 알아볼 것이다.
이후 가상분산모드, 완전분산모드로 설치하는 방법을 포스팅할 예정이다.

Centos 7으로 각 노드를 구성할 것이고 각 노드당 최소 용량은 25G는 확보하도록 하자.

Centos 7이 설치된 환경을 1개 준비한다.

먼저 자바를 설치하기 전에 java가 설치되어 있는지 확인한다.

현재 OpenJDK가 설치되어 있고 OpenJDK가 아닌 오라클 JDK를 설치할 것이다.
rpm -qa | grep jdk를 해보면 jdk 관련된 것이 몇 설치되어 있고 이를 다 삭제한다.

yum remove java*를 사용해서 모두 삭제한다.

다시 rpm -qa | grep jdk로 확인해보면 모두 제거되었다.

이제 자바를 다운받아서 설치한다.(링크)
현재 버전이 11까지 나왔는데 하둡3.1.2버전에서 11을 제대로 지원하는지 몰라서 일단 안전하게 8버전을 설치하려고 한다.

Linux x64 tar버전을 다운받고 압축을 풀었다.
현재는 /root/다운로드에 풀었다.

jdk1.8.0_201로 압축이 풀렸고 이걸 /usr/local/ 하위로 옮기면서 디렉토리 명을 jdk1.8로 수정했다.

이제 환경변수 설정을 해줘야한다.
리눅스는 자동으로 시작되는 스크립트 파일들이 있다.
(순서 : /etc/profile -> /etc/bashrc -> ~/.bashrc -> ~/.bash_profile)
뒤에 2개의 경우 ~/.은 로그인 사용자에게만 적용되는 스크립트 이므로 전체 사용자에게 적용을 시키려면 앞에 실행되는 두개 중에 하나에 스크립트를 추가해주면 된다.

따라서 /etc/profile을 편집해주자.
vi 편집기를 통해 /etc/profile 파일 맨 하위에 4줄을 추가해준다.

export JAVA_HOME=/usr/local/jdk1.8
export PATH=$JAVA_HOME/bin
export JAVA_OPTS="-Dfile.encoding=UTF-8"
export CLASSPATH="."

수정을 다 했으면 source /etc/profile을 통해 적용을 해주고 재부팅을 하자.

java -version을 통해 자바가 설치된 것을 확인할 수 있다.

이제 하둡을 설치해보자.
하둡은 현재 3.2.0까지 나왔다.
필자는 맨 위에(가장 최근에 나온) 하둡 3.1.2버전을 설치할 것이다.
hadoop.apache.org에 가서 binary 버전으로 다운로드를 하자.

처음에 리눅스를 설치할 때 centos계정을 만들어서 현재 /home/centos 디렉토리가 존재한다. 여기로 옮겨서 압축을 푼다.

이후 하둡 설정을 해줘야한다.
vi /etc/profile을 통해 자바 경로를 설정해준 것처럼 하둡도 똑같이 해준다.

최종 모양은 다음과 같다.

내용은 하둡 홈을 설정해주고 경로에 하둡홈/bin과 하둡홈/sbin을 설정했다.
그리고 각 노드의 유저를 기본값으로 root를 설정해줬다.

이후 source /etc/profile을 통해 변경내용을 시스템에 반영하고 재부팅을 한다.

하둡 버전을 확인해보면 3.1.2 버전이 나오는 것을 보아 제대로 설치되었다.

잘 돌아가는지 테스트를 해보자.
하둡에 내장된 예제jar 파일(hadoop-mapreduce-examples-3.1.2.jar)을 통해 hadoop_env.sh 파일 단어 갯수를 세본다. wordcount라는 클래스가 있어서 단어의 갯수를 셀 수 있다.

참고로 /home/centos/hadoop-3.1.2/etc/hadoop/hadoop-env.sh 파일의 내용은 다음과 같다.

이 문서를 분석해서 각 단어가 몇번 나오는지 세보고 wordcount_ouput에 출력한다.

hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.2.jar wordcount $HADOOP_HOME/etc/hadoop/hadoop-env.sh wordcount_output

그 결과 _SUCCESS와 part-r-00000 파일이 생성되었다.

_SUCCESS는 정상적으로 수행이 되어서 떨어진 파일이고 수행 part-r-00000에 수행 결과가 출력되어있다.

따라서 cat wordcount_output/part-r-00000를 통해 파일 내용을 보면 다음과 같다.

대략 setting이 4번나오고 some이 2번 등 단어 출현 횟수가 세어져있다.

위의 테스트 결과 파일을 지우고 다음 포스팅에서 가상분산모드 세팅을 해보도록 하자.

MSSQL Polybase CETAS 배치 생성할 때 팁 - 약속된 파일을 하나 더 내린다.

시나리오 : 하둡 데이터를 MSSQL로 매일 특정 시간에 가져오는 배치를 짠다고 가정한다.
예를 들어 하둡 경로가 다음처럼 떨궈진다.
/app/hadoop/korea/visit/20190101
/app/hadoop/korea/visit/20190102
/app/hadoop/korea/visit/20190103
/app/hadoop/korea/visit/20190104
....
위와 같은 방식으로 날짜를 바꾸면서 하둡 데이터를 떨구고 있다고 가정한다.

그리고 이후 다른 시스템으로 해당 하둡 데이터를 가져가는 배치가 있다고 생각한다.

가령 SSIS를 활용해서 MSSQL로 하둡 데이터를 가져간다고 가정한다.

보통 MSSQL문법으로 하둡 경로를 알고 있을 때 우리는 다음과 같은 문법으로 외부테이블을 생성할 수 있다.
CREATE EXTERNAL TABLE ~
LOCATION ~
하지만 특정 상황이 발생하여 데이터를 못 떨궜을 경우 해당 경로가 없어서 저 CREATE(일명 CETAS) 문을 실행할 수가 없다.


이때 우리는 배치에서 주기적으로 하둡 경로를 반복적으로 체크하면서 생성된 이후에 데이터를 가져오면 된다.


하둡 명령어 중에 fs -test -e /app/hadoop/korea/visit/20190101 (-s는 file, -d는 디렉토리이면.. 등 여러 옵션이 있다.)를 먼저 날리고 0을 반환하면 경로가 있다는 의미이다.

즉 아래 명령어를 먼저 날려보고

경로가 존재하지 않으면 1을 return 한다.

경로가 존재하면 0을 return 한다.

이걸 활용하면 다음과 같은 방법이 가능하다.
1. 하둡 데이터를 떨굴 때 원하는 것을 다 떨구면 해당 경로에 success라는 크기가 0인 파일을 하나 더 떨구게 한다.
2. 가져가는 배치쪽에서 loop를 만들고 반복문 안에서 데이터를 가져오기 전에 fs -test -s /app/hadoop/korea/visit/20190101/success 를 날린다
3. 리턴값이 0이면 루프를 탈출하고 1이면 10분에 한번씩 저 명령어를 하둡에 찔러본다.
4. 루프를 탈출하면 mssql에서 create external table 문 실행한다.

이런식으로 데이터가 생성될때까지 기다리고 일정 횟수 이상이되면 그냥 skip하도록 배치를 짜면 나름(?) 방어로직이 될 것이다.

MSSQL SHRINK online? offline? - shrink test 후기, 방법 및 주의할 점

요즘같이 디스크 용량 걱정이 없는 세상에서는 MSSQL Shrink를 볼 일이 없을 것 같았는데 얼마 전 회사에서 SHRINK를 할 일이 생겨서 진행했었다.

디스크 용량이 약 4테라이고 해당 디스크는 db file만 존재하여 딱히 지울 파일이 없었다.
그래서 db 자체적으로 용량을 확보하는 방법밖에 없었다.

크게 궁금했던 부분은 다음과 같다.
1. mssql table truncate를 했을 때 바로 db size(.ndf, .mdf)가 줄어드는가?
2. shrink를 한다면 어떻게 진행해야 하는가?

1. table truncate 직후 db size(.ndf, .mdf)가 줄어드는가?

먼저 1번의 경우에 과연 mssql에서 table을 truncate를 했을 때 바로 DB FILE SIZE가 줄어들어 공간을 확보할 수 있을까? 작업 전 예측하기로는 이미 늘어난 상태의 DB가 쪼그라들(축소)것 같지는 않았다. 그래서 테스트를 해봤다.

먼저 테스트용 DB를 생성했다.

초기 사이즈는 약 8MB, 증분은 64MB씩 되도록 하였다.

현재 깡통 DB이기 때문에 테스트 데이터를 밀어넣고자 랜덤데이터를 생성하였다.
증분 쿼리는 msdb에 sys.objects끼리 3번이상 cross join을 하면 DISK 공간이 부족해서 다음과 적당히 UNION ALL 해서 생성하였다.


ROW 18,819,504건, SIZE 2.54 GB 짜리 TABLE이고 DB FILE SIZE는 약 2.57GB가 되었다.

이후 TABLE TRUNCATE 후에 DB FILE SIZE는 변함이 없었다.

실제로 exec sp_spaceused를 날려보면 database_size는 그대로 2712MB를 사용하고 있었다(비할당 공간이 2637.30MB)

1번 궁금증이었던 mssql table truncate를 했을 때 바로 db size(.ndf, .mdf)가 줄어드는가?
는 해결되었다.

그럼 비할당된 공간은 어떻게 반환할 수 있을까?

DBCC SHRINKDATABASE 혹은 DBCC SHRINKFILE을 통해 비할당 공간을 줄여줄 수 있다.

반환 후 exec sp_spaceused 호출한 결과이다.

실제 DB file size도 줄어든 것을 확인할 수 있다.

2. shrink를 한다면 어떻게 진행해야 하는가?

사실 위의 경우에는 shrink를 해도 문제없는 DB였지만 실제 운영중에는 사용할 일이 없는 것이 좋다. 가장 큰 이유는 언제 끝날지 모르는 일이기 때문이다.

실제 운영 db에는 수백~수천개의 table이 존재하고 이들에게 insert/delete 등이 빈번하게 발생할 수 있기 때문에 물리적인 조각화(Fragment)가 생길 수 있다.

조각화는 DBCC SHRINKDATABASE 혹은 DBCC SHRINKFILE를 사용하여 없앨 수 있는데 굳이 SHRINKDATABASE를 하여 db 전체의 조각화를 없애기에는 부담이 가기때문에 file별로 shrinkfile을 해주는 것이 좋다.

shrink를 할 때 online? offline? singlemode?
1. 찾아보면 대부분이 offline을 권장했지만 결론은 온라인으로 진행했다. 이유는 rollback이 필요없기때문에 cancel이 바로되고 루프를 돌며 조금씩 파일 size를 줄였기때문이다.

즉 DBCC SHRINKFILE (N'SHRINK_DB' , 0)가 아닌 DBCC SHRINKFILE (N'SHRINK_DB' , 타겟사이즈)를 계속 줄여가는 방법을 택했다.

아래와 같은 방법으로 진행했다.

필자의 경우엔 온라인 상태에서 진행을 했었고 전체 DB SIZE는 약 3.5TB이고 Disk 공간부족으로 약 600GB를 확보하였다. loop를 한번 돌때마다 1GB씩 줄이는데 1분이 걸릴때도 있고 15분이 걸릴때도 있는데 약 24시간에 300회 정도 loop를 돌았다. 즉 600GB를 확보하는데 48시간이 걸렸는데 이건 사용자에 따라 다르겠지만 언제 끝날지 모른다는 것을 꼭 알아둬야한다.

한가지 조금 걱정스러웠던 것은 온라인 상태에서 진행을 할때 클러스터드 INDEX도 물리적인 저장공간을 옮겨서 저장할 것같은데 이런 경우 운영중인 DB에서 쿼리가 INDEX를 잘 타는지, 아니면 INDEX도 옮겨지는 도중이라서 random I/O가 일어나는지 궁금하다. 후자라면 위험해보인다.

MSSQL(PDW)에서 ORC 타입으로 하둡에 데이터를 내리고 하이브 테이블 생성하기

MSSQL및 PDW(parallel data warehouse)에는 하둡과 연결고리가 잘 되어있다.
이들이 지원하는 PolyBase라는 기능은 RDBMS의 데이터와 하둡에 저장된 데이터를 조인할 수 있도록 하는데 예를 들어 하둡에 저장되어 있는 데이터를 RDBMS로 가져오고 둘을 조인해서 원하는 측정값을 뽑아내기에 매우 유용하다.

위 처럼 HDFS -> MSSQL(PDW) 로의 데이터 이동이 아닌 MSSQL(PDW) -> HDFS로 데이터를 내리는 것도 가능하며 예제는 다음과 같다. (PDW 기준으로 예제를 작성하였다.)

다음 예제는 ORC 타입으로 데이터를 내리는 방법이고 파케이(parquet)나 텍스트 등 다양한 타입 및 압축(Gzip, Snappy 등)으로 데이터 포맷을 생성할 수 있다.

먼저 데이터 소스랑 파일 포맷을 생성한다. (각 DB별로 생성할 수 있다.)


USE TEST_DB;
-- 데이터 소스 생성
IF EXISTS (SELECT * FROM sys.external_data_sources WHERE name = 'HDFS_DS_SNAPSHOT')
   DROP EXTERNAL DATA SOURCE HDFS_DS_SNAPSHOT

CREATE EXTERNAL DATA SOURCE HDFS_DS_SNAPSHOT
WITH (TYPE = HADOOP
, LOCATION = N'hdfs://XXX.XXX.XXX.XXX:8020'
, RESOURCE_MANAGER_LOCATION = N'XXX.XXX.XXX.XXX:8050')
GO

-- 파일 포맷 생성
IF EXISTS (SELECT * FROM sys.external_file_formats WHERE name = 'HDFS_FF_ORC')
   DROP EXTERNAL FILE FORMAT HDFS_FF_ORC

CREATE EXTERNAL FILE FORMAT HDFS_FF_ORC
WITH (
    FORMAT_TYPE = ORC,
    DATA_COMPRESSION = 'org.apache.hadoop.io.compress.SnappyCodec'
);

-- 생성된 데이터 소스 및 파일 포맷 확인

SELECT * FROM sys.external_data_sources

SELECT * FROM sys.external_file_formats

-- 하둡에 월 파티션으로 데이터 내리기

DECLARE @DT VARCHAR(8) = '20170101'
DECLARE @SQL NVARCHAR(4000);

WHILE(1=1)
BEGIN
      SET @SQL  = N' IF  OBJECT_ID(''TEST_DB..HDFS_TEST_TABLE_'+@DT+''') IS NOT NULL
                       DROP EXTERNAL TABLE HDFS_TEST_TABLE_' + @DT + '

      CREATE EXTERNAL TABLE HDFS_TEST_TABLE_' + @DT + '
      WITH (LOCATION=' + '''/apps/hive/xxxxxxxx/yyyyyyyy/zzzzzzzzz/TEST_TABLE/yyyymmdd=' + @DT + ''',
           DATA_SOURCE = HDFS_DS_SNAPSHOT,
           FILE_FORMAT = HDFS_FF_ORC,
           REJECT_TYPE = PERCENTAGE,
           REJECT_SAMPLE_VALUE = 10000,
           REJECT_VALUE = 0.1
      ) AS
      SELECT *
      FROM TEST_TABLE
      WHERE ' + N'DT' + ' >= ''' + @DT +  ''' AND ' + N'DT' +  ' < CONVERT(VARCHAR(8),DATEADD(MM,1,''' + @DT + '''),112) '

      --PRINT @SQL
      SET @DT = CONVERT(VARCHAR(8),DATEADD(MM,1,@DT),112)
      IF(@DT > '20180101')
        BREAK;
END

다음부터는 하이브에서 진행하며 위에서 생성한 HDFS를 사용한다.

-- 하이브에서 테이블 만들기

 CREATE EXTERNAL TABLE HDFS_TEST_TABLE

(

    `COL1` bigint ,

    `COL2` bigint ,

    `COL3` bigint ,

)

PARTITIONED BY (YYYYMMDD STRING)

ROW FORMAT DELIMITED

FIELDS TERMINATED BY ','

STORED AS ORC

LOCATION '/apps/hive/xxxxxxxx/yyyyyyyy/zzzzzzzzz/TEST_TABLE';

-- 파티션 적용하기
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20170101');
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20170201');
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20170301');
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20170401');
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20170501');
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20170601');
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20170701');
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20170801');
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20170901');
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20171001');
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20171101');
ALTER TABLE database_name.HDFS_TEST_TABLE ADD PARTITION (YYYYMMDD='20171201');


정리하면 MSSQL(PDW)에서 데이터 소스와 파일 포맷을 만들어주고 이를 활용해서 HDFS로 데이터를 내린다. 그리고 하이브에서 내린 데이터를 가지고 외부 테이블을 생성하면 된다.