DEBUG: org.apache.hadoop.conf.Configuration - java.io.IOException: config()

Hadoop 0.20.x 버전의 Configuration 객체를 생성할 때 다음 생성자로 생성하면 


        Configuration conf = new Configuration(false);


디버깅 메시지에 다음 메시지가 나온다.

DEBUG: org.apache.hadoop.conf.Configuration - java.io.IOException: config()

...  stack trace ...



찾아보니 실제 Configuration의 생성자의 코드가 다음과 같아서 나는 메시지란다.

public Configuration(boolean loadDefaults) {
  if (LOG.isDebugEnabled()) {
    LOG.debug(StringUtils.stringifyException(new IOException("config()")));
  }
  // ...
}


누가 위에 현상을  HADOOP-2851 로 등록해서 패치까지 올렸지만 Won't fix로 이슈가 닫혔는데..

하둡 버전을 1.1.2로 올리니 위에 디버깅 메시지가 안나온다. 그 이후에 수정되었나보네 하고 넘기려고 했으나.


찝찝해서 깃헙 가서 코드 찾아봄


디버깅 메시지 출력하는 코드는 없어졌네...

이슈를 찾아보고 싶으나 귀찮아서 패스. (별것도 아닌데 이건 오바 같다)


어쟀든 괜히 식겁했네.


참고


Posted by 김민우 julingks

Hadoop version 1.2.0 released


약간 뒷북이지만 지난 5월 13일에 하둡 버전 1.2.0 출시되었다.

1.1.2와 비교할때 200여개의 기능 향상과 버스 수정되었음


주요 향상된 기능은 다음

  • DistCp v2 backported
  • Web services for JobTracker
  • WebHDFS enhancements
  • Extensions of task placement and replica placement policy interfaces
  • Offline Image Viewer backported
  • Namenode more robust in case of edit log corruption
  • Add NodeGroups level to NetworkTopology
  • Add “unset” to Configuration API


릴리즈 노트는 여기


다운로드는 여기


1.1.2 버전 이후 3개월만이고 1.1.0 이후 7개월만에 두 번째 자릿수 버전이 올라갔다.

Posted by 김민우 julingks

HBaseCon 2013 : The Session Schedule has been published


2013년 6월 13일, 센프란시스코

자세한 내용은 컨퍼런스 홈페이지를 참조

5월 13일에 스케줄이 공시 되었다


하루짜리 컨퍼런스라서 기대는 안했는데 의외로 건질만한 것들이 보인다.


HBaseCon 2012 내용은 여기 http://hbasecon.com/2012


컨퍼런스 트랙은 다음 세션들을 포함한다

  • Operations
  • Internals
  • Ecosystem
  • Case Studies


HBaseCon 2013 프로그램 커미티는 다음과 같다.

  • Gary Helmling, Twitter
  • Lars Hofhansl, Salesforce
  • Jonathan Hsieh, Cloudera
  • Doug Meil, Explorys
  • Andrew Purtell, Intel
  • Enis Söztutar, Hortonworks
  • Michael Stack, Cloudera (Chair)
  • Liyin Tang, Facebook



HBase는 기술적으로 deep하게 몰라서 동기부여 차원에서 가기로 했다. (점점 얇아지는 지갑..)

혹시 이 컨퍼런스 참석 하시는 분은 메일을 주세요. julingks_at_gmail_dot_com

혼자 들으면 외로울것 같아요.

Posted by 김민우 julingks

Voting Hadoop 1.2.0 RC1

Hadoop 2013.05.16 12:47

Voting Hadoop 1.2.0 RC1


하둡 1.2.0 도 RC1 투표중.

투표 현황을 보아하니 한달 내로 출시할 것 같아 보인다.


하둡은 이슈는 follow-up 못하고 있는데, HDFS라도 하루 날잡아서 쭉 훝어 봐야겠다.

Posted by 김민우 julingks

Cloudera Impala 1.0 has been released


지난 4월 30일 클라우데라 임팔라 1.0 GA 버전이 릴리즈했다.

2010년에 구글에서 낸 dremel 논문에서 영감을 받아서 시작했다고 한다.

리서치를 하고 있어서 정리가 되면 dremel과 impala에 대해서 다시 포스팅하기로 하고.

릴리즈 관한 내용은 여기서 확인

추가적인 리소스들

여담이지만 Gigaom 리포트(Sector RoadMap: SQL-on-Hadoop platforms in 2013)에서는 impala가 제일 낫다고.

Posted by 김민우 julingks

2011년 6월 그리스 아테나에서 열린 SIGMOD 학회에 페이스북에서 HBase를 실제 서비스에 적용한 후 그에 관한 논문을 냈다. http://borthakur.com/ftp/RealtimeHadoopSigmod2011.pdf

올해 6월에 처음으로 열린 SDEC 2011 (Seoul Data Engineering Camp)에서 페이스북의 Jonathan Gray가 이와 관련된 발표를 했었다. http://www.sdec.kr/schedule#hbase

ACM에는 구체적인 연구 분야마다 특화분야그룹 (Special Interest Groups, SIGs)가 있는데 현재 30여개로 각 분야별로 SIGCOMM, SIGGRAPH, SIGMOD, SIGOPS. SIGCHI  등이 있다. SIG그룹은 CS 각 분야별로 최고 수준의 학회들이라고 볼 수 있다.  CS 박사과정 중에 있는 학생이라면 SIG 그룹에 논문을 내는 것이 꿈(?)이라고 할 수 있겠다. (졸업과 취직에 지름길? ㅎㅎ )
SIGMOD(Special Interest Group on Management of Data)는 데이터베이스 관련 역사와 전통이 있는 최고 수준의 학회 중 하나다. 그 밖에 데이타베이스 관련 최고 수준 학회로는 VLDB,  IEEE의 ICDE가 있다.

7월 회사에서 이 논문을 읽고 발표를 했었는데, Hadoop과 Hbase에 대한 깊은 기술적 이해가 필요해서 애를 먹었던 기억이 난다. 발표자료는 거의 논문 직역 수준으로 되어서 이제까지 회사에서 발표한 자료 중에는 최악이었던 것으로 기억된다. :-(  그래도 몇일 고생하면서 Hbase에 대한 기술적인 이해가 높아졌다는 것으로 만족한다. 당시 그루터에 김형준 수석님의 도움을 많이 받았다. 시간이 나면 내용을 좀 다듬으려고 했으나, 역시나 시간이 없다;

요약하면,

페이스북에서 기존 RDB 클러스터로 운영하던 시스템 Hadoop/HBase 기반으로 마이그레이션을 했고 적용한 워크로드는 다음 세가지이다.

  • Facebook Messages
  • Facebook Insights
  • Facebook Metric System (ODS)

위의 3가지 워크로드는 다음과 같은 공통점이 있다.

  • 대량의 쓰기 부하 (High Write Throughput)
  • 명시적으로 수행하지 않는 한 지워지지 않는다.
  • 최근에 쓰여진 것만 몇 번 읽고 아주 가끔 다시 본다.
  • 대부분 데이터는 읽혀지지 않지만 최소 지연시간으로 언제든지 사용 가능 해야 된다

위의 3가지 워크로드로 부터 시스템의 요구사항은 다음과 같다

  • 탄력성 (Elasticity)
  • 높은 쓰기 처리량 (High Write Throughput)
  • 한 데이터 센터 안에서 효율적인 Low-latency 강한 일관성 시멘틱
  • 효율적인 랜덤 디스크 읽기
  • 고가용성과 재난 극복 (High Availability and Disaster Recovery)
  • 내고장성 (Fault Isolation)
  • 원자적 읽기-수정-쓰기원시적인 지원
  • 범위 스캔 (Range Scan)

페이스북에서는 오프라인 배치 분석작업을 Hadoop과 Hive를 통해서 이미 수행하고 있기 때문에 Hadoop기반 오픈소스를 사용하는 것에 대한 거부감이 없으며 하둡에 대한 신뢰도 높은 편이다.  물론 프로덕션 환경에서 사용하기에 Hadoop과 HBase는 부족한 부분이 있지만 In-house 엔지니어링을 통해서 충분히 해결할 수 있는 자신감 또한 Hadoop/HBase를 선택하는 데 반영되었다.

이후 내용은 Hadoop과 HBase을 프로덕션 수준으로 높이기 위해서 그동안 페이스북에서 오픈소스에 기여한 내용에 대한 내용들이다.  Hadoop과 HBase에 대한 기술적인 이해가 필요해서 애를 먹었던 부분이다. 마지막 챕터는 개발 및 운영 경험에 대한 내용도 나온다.  자세한 내용은 논문과 발표자료를 참고하길 바란다.

---

HBase는 아직 엔터프라이즈에서 사용하기에 부족한 부분이 많다는 것이 세간의 평가지만, 페이스북에서 그 부분을 향상시키고 성공적으로 도입하므로서 다시 관심의 중심이 되었다.페이스북은 서비스 론칭 후 6억명의 사용자가 사용해야한다. 페이스북에서 검증 되었다는 것은 큰 의미가 있다고 볼 수 있겠다.
혹시나 필요한 사람을 위해서 발표자료를 공개한다.

 

 

Posted by 김민우 julingks

This page is translated from http://www.informationweek.com/news/software/info_management/229500154?pgno=2

2011년 5월 12일자 기사

하둡 핼퍼 회사들은 빠른 빅 데이터 분석을 약속한다.

아파치 하둡은 가장 빠르게 성장하고 있는 오픈소스 프로젝트 중 하나이다. 따라서 상용 벤더들이 한 몫챙길 것을 찾는 것도 놀랄일이 아니다. 유명한 Data-integration 벤더들 (Informatica, Pervasive Software, SnapLogic, Syncsort)의 잇다른 최근의 발표들을 보고 있자면,  모두들 매우 어린 빅 데이터 처리 플랫폼과의 작업을 더 빠르고 더 쉽게 만드는 것을 목표로 한다.

하둡은 큰 볼륨의 비정형 데이터를 분석하기 위한 분산 데이터 처리 컴포넌트의 집합이다. 
페이스북의 댓글이나 트위터의 트윗이나, 이메일, 인스턴트 메시지들, 보안 로그, 애플리케이션 로그가 그 대상이다
IBM DB2, Oracle, Microsoft SQL Server, MySQL 같은 관계형 데이터베이스는 이런 데이터를 다룰수가 없다.  컬럼과 로우에 깔끔하게 맞지 않기 때문이다
이런 상용 데이터베이스들이 큰 볼륨의 비정형 데이터를 처리 할 수 있다고 해도,  라이센스 비용은 데이터의 스케일로 인한 문제 때문에 엄두도 못낼 정도로 비싸다 . 우리는 보통 수백 테라바이트에 대해 말하던 것이 페타바이트로 가고 있다.

오픈소스 프로젝트인 하둡 소프트웨어 버전은 공짜로 다운받을 수 있다. 하둡은  저비용 커머디티 서버 위에서 스케일 아웃 할 수 있도록 설계되었다.  AOL, eHarmony, eBay, Facebook, JP Morgan Chase, LikedIN, Netflix, The New York Times, Twitter  같은 회사들은 하둡에 매력을 느껴왔다.

하둡은 상용 벤더들을 끌어 당기는 자석이 되고 있다.
Cloudera는 가장 인기있는 하둡 배포 버전을 제공한다. 그리고 엔터프라이즈 서포트와 서비스를 제공하는 선도 주자다. Datameer는 Data-integration, Storage, Analytics와 visualization software 지원을 제공한다. Karmasphere는 하둡 잡들의 모니터링과 디버깅, 개발을 위한 그래픽한 환경울 추가했다.

EMC는 자신만의 하둡 소프트웨어 버전 제공할 것이라고 발표했다.  또한 EMC는 싱글 하드웨어 플래폼 위에서  EMC  Greenplum 관계 데이터베이스와 하둡을 실행시킬 수 있는 어플라이언스를 발표했다.

Informatica과 SnapLogic

Data-integration 벤더인 informatica와 SnapLogic 모두 EMC와의 파트너쉽을 발표했다. Informatica는 EMC 하둡 배포판과  Data-Integration-platform이 통합될 것이라고 말했다. 이것은 3분기 릴리즈가 정해졌다. 이전에도 Informatica는 비슷한 방식의 통합으로 Cloudera와 파트너 관계 였다.

Informatica는 4,200 이상의 고객 회사를 가지는 가장 큰 독립적인 data-integration 벤더이다.
그래서 EMC와 Cloudera는 Informatica가 빅데이터를 씹어먹는 하둡 사용자들을 원하는 만큼  Informatica가 필요하다.

SnapLogic은 데이터를 MapReduce로 연결할 SnapLogic 플랫폼의 모듈인 SnapReduce를 발표했다. 이것은 Core Hadoop data-filtering 알고리즘이다. 또한 SnapLogic은 그들의 HDFS 버전을 소개했다. 이것은 하둡 사용자들이 SnapLogic 플래폼이 다루는  많은 소스들로 부터 데이터를 당겨오게 할 것이다.

오픈소스 Data-integration 벤더인 Talend와 Quest Software의 의 Hadoop-supporing tool도 있다. 대부분의 Integration 파트너쉽들은 하둡으로의 데이터 입출력을 더 쉽게 하는것을 목표로한다. Syncsort 와 Pervasive의 경우에는 상용 add-on 제품들이 하둡안에서의 빠른 처리를 목표로한다.

Syncsort 와 Pervasive

Syncsort는 DMExpress data integration 소프트웨어의 하둡 에디션을 위한 계획을 발표했다. 이 에디션은 앞서 언급한 HDFS와의 연결을 포함한다. 또한 DMExpress을 이용하는 고객들이 하둡이  오름차순, 내림차순, 역순, 특정 키 범위 정렬을  할 수 있도록 하는  고급 기능 위한 플러그인도 포함한다. Syncsort에 따르면 더 나아진 정렬은 하둡에서 2배 성능을 향상 시킬 수 있다록 한다. Informatica, SnapLogic, Talend Integrations와 마찬가지로, Syncsort는 DMExpress Hadoop Edition이 사용하기 쉽운 그래픽 유저 인터페이스 지향 데이터 통합 환경을 제공할 것이라고 말한다.  이 하둡 버전은 올해가 지나서 릴리즈 될 것이다.

Pervasive의 하둡 제품은 Data Rush다. 이 도구는 하둡안에서 concurrent, parallel  처리를 최적화한다.  Pervasive의 전통적인 data-integration 소프트웨어에서 오래전에  마스터한 data-flow parallel 프로그래밍을 소개한다. Pervasive는 MapReduce 잡의 성능을 4배에서 9배까지 높일 수 있다고 말한다. 이것은 Hive와 Pig data-flow 프로그래밍 언어를 위해서 개발중인 애플리케이션이다.

 

Forecaster의 분석가 James Kobielus는 하둡 시장이 몇년동안  수조원으로 성장할 것이라고 확신한다고 말했다. 
eBay, Facebook, NetFlix, Twitter가 화려한 예시들이다. 그러나 JPMorgan Chase 같은 거대 금융회사가 하둡 도입을 시도했다는 것이 더 흥분되는 일이다.

----

의역도 하고 생략한 부분도 있다. 오역도 물론 있다;;
전통적인 Data-Integration 벤더들은 모두 하둡 시장을 새로운 기회로 보고 있다.
기존 EDW 벤더도 변신을 꾀하지 않으면 앞으로의 성장을 보장할 수 없는 시기가 왔음은 분명한것 같다. (물론 망하지는 않겠지만..  )

Posted by 김민우 julingks

Hadoop World 2011, NYC

Hadoop 2011.09.16 23:35

올해도 어김 없이 Cloudera 주최의 Hadoop World 컨퍼런스가 열린다.
11월 8일~9일, 이틀 동안이고 장소는 뉴욕이다.
세션도 대폭 늘어나 40여개나 된다.

비정형 빅데이터 플랫폼 강자로 떠오른 하둡에 대한 관심과 열기를 느낄 수 있는 컨퍼런스라 할 수 있겠다.
앞으로 수년 내로  하둡 시장이 수조원 규모로 성장한다는 이야기도 나오고 있고, JP Mongan Chase 같은 보수적인 금융회사에서 하둡을 도입하고 있다.
가트너에서 내년 BI 시장을 15조원 정도로 예상하고(하드웨어와 하둡을 제외한), 데이터 분석 시장 또한 10~15% 정도 성장할 것으로 내다 보고 있다. 
비정형 빅데이터 분석 시장도 같이 커질 것으로 예상된다.
빅데이터 키워드도 가트너 하이프 싸이클에 추가가 되어 1~2년 사이에 큰 관심을 받는 분야가 될 것이라는 예측이 지배적이다. 
(지금 하이프 싸이클의 정점은 클라우드 컴퓨팅이다)
전통적인 BI 빅 플레이어들 (SAP, Oracle, IBM, Microsoft 등)도 빅데이터 플랫폼의 패권을 차지하기 위한 경쟁에 뛰어 들었다. 
그 중심에 있는 키워드는 단연 하둡이라고 할 수 있겠다. 물론 넥스트 하둡 플랫폼의 대한 경쟁도 이미 막이 올랐다.
하둡은 강력한 오픈소스 커뮤니티의 힘으로 성장했다고 볼 수 있는데, 구글의 GFS 논문의 클론 프로젝트가 이만큼 성정한 것을 보니, 오히려 베일 속에 감춰진 구글의 저력이 궁금하면서 무섭기도 하다.  그런 의미에서 Mapreduce, GFS, BigTable 논문은 CS 학계의 패러다임을 전환시킨 대단한 논문이라고 할 수 있겠다. 이미 MapReduce 논문은 인용 횟수가 수천회가 넘었다. (2004년에 나온 논문이 벌써 3천여회라니.. )

화제를 다시 Hadoop World로 돌리면, 2009년에 이어 올해 우리 회사의 proposal이 통과했다. 
올해는 Jason Han(한재선 대표)이 "Replacing RDB/DW with Hadoop and Hive for Telco Big Data" 주제로 발표한다. 
꾸준히 해외 컨퍼런스에 한 세션을 차지하고 있다는 것은 뿌듯한 일이다. (국내 기업은 유일하다)
Hbase도 페이스북의 Contribution으로 다시 뜨겁게 관심을 받고 있고, 하둡 에코 시스템의 힘이 대단 하다고 볼 수 있겠다.

다가올 빅데이터 시대의 하둡에 대한 관심과 위상을 느낄 수 있는 컨퍼런스임에는 분명하다.
뉴욕에서 열리기 때문에 가는 비용이 만만치 않지만 다양해진 세션과 높아진 관심을 생각하면 빅데이터 대한 관심이 있는 회사라면 올해 만큼은 참가할 만하다. (작년에는 미국에 날아가는 정성에 비해서는 별로 건질게 없었다)

Related Links

Posted by 김민우 julingks

Oozie instsall

Hadoop 2011.03.09 18:03

Oozie 설치하기

시스템 요구 사항

  • 유닉스
  • 자바 1.6 +
  • 하둡 (0.20.x)
  • 톰켓 6.x

Oozie 다운로드

https://github.com/yahoo/oozie/downloads 에서 최신 버전을 다운 받는다.  (예, 2.2.2)

Ooozie 배포판의 gz.tar 압축을 푼다.

환경변수 설정

자바 JRE 는 PATH에 있어야 한다.
OOZIE_HOME 환경 변수를 설정하고 ${OOZIE_HOME}/bin 을 PATH에 추가한다

Oozie WAR 설치

Oozie WAR 는 하둡 JAR 파일과 ExtjJS 라이브러리가 없이 묶여있다. 하둡 JAR 는 Oozie를 실행하는데 필요하고. ExtJS 라이브러리는 선택사항이다.  (웹 콘솔을 위해서 필요하다)

ExtJS 라이브러리를 다운 받는다. http://extjs.com/deploy/ext-2.2.zip (2.2버전이어야 한다)
ExtJS는 다른 라이센스를 사용하기 때문에 함께 묶이지 않았다.

${OOZIE_HOME}/bin/addtowar.sh 스크립트를 이용하여 하둡 JAR와 ExtJS 라이브러리를 Oozie WAR 파일에 추가한다.

사용법:

 Usage  : addtowar 
 Options: -inputwar INPUT_OOZIE_WAR
          -outputwar OUTPUT_OOZIE_WAR
          [-hadoop HADOOP_VERSION HADOOP_PATH]
          [-extjs EXTJS_PATH]
          [-jars JARS_PATH] (multiple JAR path separated by ':')

오리지널 Oozie WAR 파일은 ${OOZIE_HOME}/oozie.war 에 있다.

예:

${OOZIE_HOME}/bin/addtowar.sh -inputwar ${OOZIE_HOME}/oozie.war -outputwar oozie.war -hadoop 0.20.2 ${HADOOP_HOME} -extjs EXTJS_PATH -jars ${HADOOP_HOME}/*.jar

새롭게 생성된 WAR 파일을 톰켓의 webapps 디렉토리로 복사한다.

데이터베이스 설정

Oozie는 HSQL, MySQL, Oracle 데이터베이스에서 작동한다.

HSQL을 사용하면, oozie는 HSQL JDBC 드라이버를 묶는다. HSQL 은 임베디드 인-메모리 데이터베이스이다. 모든 데이터는 Oozie가 실행을 멈추면 없어진다.

MySQL 또는 Oracle을 사용하면,  알맞는 JDBC 드라이버 JAR 파일들을 Oozie classpath에 위치 시켜야 한다. (Oozie WAR에 추가하거나 톰캐의 common/lib 디렉토리에 추가한다.) Oozie를 위한 데이터베이스가 생성되어야 한다. Oozie는 테이블을 자동적으로 생성한다.

bin/addtowar.sh 스크립트의 -jars 옵션을 이용하여 Oracle 또는 MySQL JDBC 드라이버 JAR 를 Oozie WAR파일에 추가할 수 있다.

Oozie 설정

설정은 ${OOZIE_HOME}/conf 디렉토리로 부터 읽는다.

Oozie 설정은 3가지 다른 파일로 분배된다.

  • oozie-site,xml : Oozie 서버 설정
  • oozie-log4j.properties : Oozie 로깅 설정
  • adminusers.txt : Oozie 관리 유저 리스트

참고

Posted by 김민우 julingks

Overview

  • 하둡 Map/Reduce와 Pig job을 실행하는 Action들로 구성된 워크플로우를 실행하는 데 특화된 워크플로우 엔짂 기반 서버
  • 자바 서블릾 컨테이너에서 실행되는 자바 웹 애플리케이션이다
  • 워크플로우란 control dependency DAG 로 배열된 액션들의 집합
  • 워크플로우 정의는 hPDL 로 쓰인다
  • Oozie 워크플로우 액션들은 웎격 시스템에서 job을 시작한다
  • Oozie 워크플로우는 Control flow 노드들과 액션 노드를 포함한다
  • Control flow 노드는 워크플로우의 시작과 끝(start, end, fail 노드)을 정의한다. 워크플로우 실행 결로을 제어하는 매커니즘(decision, fork, join 노드) 도 제공한다.
  • 액션 노드는 계산/처리 작업의 실행을 유발하는 매커니즘이다.
  • Oozie는 다른 종류의 액션들을 지웎한다 : 하둡 map-reduce, 핟부 파일 시스템, Pig, SSh, HTTP, eMail, Oozie sub-workflow.
  • Oozie 워크플로우는 워크플로우 정의 안에 파라미터를 넣는다. ( ${inputDir} 같은 변수를 사용하여 ) 워크플로우 job이 제출될 때, 파라메터의 값은 제공된다.

Workflow Diagram

p1

hPDL

<workflow-app name='wordcount-wf' xmlns="uri:oozie:workflow:0.1">
    <start to='wordcount'/>
    <action name='wordcount'>
        <map-reduce>
            <job-tracker>${jobTracker}</job-tracker>
            <name-node>${nameNode}</name-node>
            <configuration>
                <property>
                    <name>mapred.mapper.class</name>
                    <value>org.myorg.WordCount.Map</value>
                </property>
                <property>
                    <name>mapred.reducer.class</name>
                    <value>org.myorg.WordCount.Reduce</value>
                </property>
                <property>
                    <name>mapred.input.dir</name>
                    <value>${inputDir}</value>
                </property>
                <property>
                    <name>mapred.output.dir</name>
                    <value>${outputDir}</value>
                </property>
            </configuration>
        </map-reduce>
        <ok to='end'/>
        <error to='end'/>
    </action>
    <kill name='kill'>
        <message>Something went wrong: ${wf:errorCode('wordcount')}</message>
    </kill/>
    <end name='end'/>
</workflow-app>

Definition

Action

– 실행과 처리 task (Map-Reduce job, Pig job, a shell command)
– Action node 또는 task라고 부름

Workflow

– control dependency DAG(Directed Acyclic Graph)로 배열된 액션들의 집합
– control dependency란 첫 번째 액션이 완료되지 않으면 두 번째 액션은 실행될 수 없다.

Workflow Definition

– 실행될 workflow의 programmatic description

Workflow Definition Language

– Workflow Definition를 정의 하는 데 사용되는 언어

Workflow Job

– workflow definition의 실행 가능한 instance

Workflow Engine

– DAG 엔진으로서 참조된다. workflow들의 job들을 실행하는 시스템

Specification Highlight

  • 워크플로우 애플리케이션은 Hadoop, Pig, sub-workflow들의 액션을 coodinate 하는 DAG 이다.
  • 워크플로우 애플리케이션에서 Flow control 명령은 decision, fork, join node 사용한다.
  • Cycle은 지원 안됨
  • Action과 Decision은 job properties, 액션의 결과 (예, 하둡 counters), 파일 정보(파일 유무, 파일 크기 등) 을 파라메터로 받을 수 있다
  • 공식 파라메터는 workflow definition에서 ${VAR} 변수로 표현된다
  • 워크플로우 애플리케이션은 workflow definition, 모든 액션 실행에 필요한 모든 파일들 (JAR, Map/Reduce job, streaming Map/Reduce job을 위한 shell, 라이브러리, Pig 스크립트, 리소스 파일들)을 포함한 ZIP 파일이다.
  • 워크플로우 애플리케이션은 Oozie에 deploy 되고 나서야 workflow job이 실행된다.
  • 웹 콘솔, 커맨드라인, WS API, Java API를 통해 시스템과 workflow 잡을 모니터링 할 수 있다.
  • workflow job을 제출할 때, 모든 공식 파라메터들을 가지는 프로프터들의 집합은 제공 되어야 한다. 이 파라메터들의 집합은 Hadoop Configuration이다.

가능한 job의 상태

  • PREP, RUNNING, SUSPENDED, SUCCEEDED, KILLED, FAILED

액션 시작 실패의 경우에서 실패의 종류에 따라서

  • 자동적으로 재시도
  • manual 재시도
  • workflow 실패

Oozie는 액션의 start/end/failure 이벤트 , workflow의 end/failure 이벤트의 Http callback notification을 만든다.

Workflow Definition

Workflow Definition은 control flow 노드(start, end, decision, fork, join, kill) 또는 액션 노드(map-reduce, pig 등)들이 화살표로 연결된 DAG이다.
워크플로우 정의 언어는 hPDL (hadoop Process Definition Language)로 XML 기반 언어

 

Cycles in Workflow Definition

  • Oozie는 워크플로우 정의에서 cycle을 지원하지 않는다.
  • 반드시 엄격한 DAG이어야 한다.
  • 워크플로우 애플리케이션 deployment 중에 워크플로우 정의에서 cycle을 탐지하면 deploy가 실패한다.

Workflow Nodes

흐름 제어 노드 (Control Flow Nodes)

  • Start Control Node
  • End Control Node
  • Kill Control Node
  • Decision Control Node
  • Fork and Join Control Nodes

액션 노드 (Action Nodes)

  • Map-Reduce Action
  • Pig Action
  • Fs (HDFS) Action
  • Ssh Action
  • Sub-workflow Action
  • Java Action

p2

 

Control Flow Node

Start Control Node

  • workflow job의 시작 노드. 처음으로 시작되는 노드를 가리킨다.
<workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <start to="firstHadoopJob"/>
    ...
</workflow-app>

End Control Node

  • workflow job의 끝 노드
  • 워크플로우 job이 성공적으로 완료되었음을 가리킨다.
  • workflow job이 end에 도달하면, 성공적으로 완료된다. (SUCCEDED)
  • 실행되고 있는 workflow에 의해 하나 이상의 액션이 실행되고, end 노드에 도달하면, 모든 액션은 kill 된다. 워크플로우는 여전히 공식적으로 실행되었다고 간주된다.
<workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <end name="end"/>
</workflow-app>

Kill Control Node

  • 워크플로우 자신을 죽인다
  • 워크플로우 job이 kill 에 도달하면 에러로 끝나게 된다. (KILLED)
  • 워크플로우 job에 의해 하나 이상의 액션이 시작되었다면, kill 노드에 도달하면 액션들은 모두 kill 된다.
<workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <kill name="killBecauseNoInput">
        <message>Input unavailable</message>
    </kill>
    ...
</workflow-app>

Decision Control Node

  • 이 노드는 워크플로우가 따라가는 실행 경로 위에서 선택을 할 수 있도록 한다.
  • switch-case 문장 처럼 보인다.
  • decision 노드는 Predicate와 Transition의 쌍의 리스트와 default transition로 구성된다.
  • Predicate이 차례대로 평가되어 true가 되면 해당 Transition을 취한다.
  • Predicate은 true 또는 false 값을 내는 JSP Expression Language 이다.
    <workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
        ...
        <decision name="mydecision">
            <switch>
                <case to="reconsolidatejob">
                  ${fs:size(secondjobOutputDir) gt 10 * GB}
                </case>
                <case to="rexpandjob">
                  ${fs:size(secondjobOutputDir) lt 100 * MB}
                </case>
                <case to="recomputejob">
                  ${ hadoop:counters('secondjob')[RECORDS][REDUCE_OUT] lt 1000000 }
                </case>
                <default to="end"/>
            </switch>
        </decision>
        ...
    </workflow-app>

    Fork 와 Join

  • fork 노드는 하나의 실행 경로를 여러 개의 동시 실행 경로로 분리한다.
  • join 노드는 이전 fork 노드의 동시 실행 경로가 모두 도착할 때까지 기다린다.
<workflow-app name="sample-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <fork name="forking">
        <path start="firstparalleljob"/>
        <path start="secondparalleljob"/>
    </fork>
    <action name="firstparallejob">
        <map-reduce>
	 ...
        </map-reduce>
        <ok to="joining"/>
        <error to="kill"/>
    </action>
    <action name="secondparalleljob">
        <map-reduce>
	 ...
        </map-reduce>
        <ok to="joining"/>
        <error to="kill"/>
    </action>
    <join name="joining" to="nextaction"/>
    ...
</workflow-app>

Workflow Action Nodes

  • 계산/처리 작업의 실행하는 노드들
  • 계산/처리 액션은 모두 원격 실행이다. (Oozie 안에서 실행되는 작업은 없다)
  •  

  • 액션은 Asynchronous(비동기적)하다
    – Oozie는 모든 계산/처리 작업을 비동기적으로 실행시킨다.

     


    – 워크플로우는 계산/처리 작업이 완료될 때까지 기다린다. 그리고 나서 다음 노드로 전환된다.


    – Oozie는 callback과 polling으로 계산/처리 작업의 완료를 감지한다.


    – Oozie에 의해 계산/처리 작업이 시작되면, Oozie는 작업에 대한 유일한 callback URL을 제공한다. 작업이 완료되었음을 주어진 URL로 알린다


    – 어떤 이유에 의해서 callback URL 발생이 실패한 작업에 경우, Oozie는 완료된 계산/처리 작업을 poll하는 매커니즘을 가지고 있다.
  •  

  • Action은 =ok=, =error= 두 가지 Transition을 가진다.
    – 계산/처리 작업이 성공적으로 완료되었다면, ok 로 전환된다.

     


    – 계산/처리 작업이 성공적으로 완료되는 것이 실패했다면 error로 전환된다.


    – 계산/처리 작업이 에러로 종료되면, 계산/처리 작업은 Oozie에 error-code와 error-message 정보를 제공해야 한다. 이 정보는 워크플로우 애플리케이션 수준에서 fine grain error handling을 구현하기 위해서 decision 노드에서 사용될 수 있다.


    – 각각 액션 타입은 생성할 수 있는 모든 에러코드를 명확히 정의 해야 한다.
<workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <action name="myfirstHadoopJob">
        <map-reduce>
          ...
        </map-reduce>
        <ok to="myNextAction"/>
        <error to="errorCleanup"/>
    </action>
    ...
</workflow-app>

Action Recovery

  • Oozie는 액션이 시작하고 끝날 때 recovery 기능을 제공한다.
  • 액션이 성공적으로 시작되고 나면, Oozie는 실행 중에 액션이 실패하더라도 액션 시작을 재시도 하지 않는다.
  • 액션이 실행되는 외부 시스템(예, 하둡)은 액션이 한번 시작되고 나면 job을 회복하는데 충분히 신속하다고 가정한다.
  •  

  • Transition 실패의 경우, (네트웍 문제나 원격 시스템이 일시적으로 사용하지 못하는 경우)
    - Oozie는 미리 정해진 시간 간격 후에 재시도를 수행 한다.

     


    - 액션 종류에 따른 재시도 수와 시간 간격은 Oozie 수준에서 미리 설정되어야 한다.


    - Workflow Jobs은 이 설정을 덮어 쓸 수 없다.
  •  

  • Transition 실패가 아닌 경우
    - Oozie는 손으로 직접, 또는 프로그램적으로 다시 시작시킬 때까지 workflow job을 중단시킨다.

     


    - 워크플로우 job을 다시 시작하기 전에 필요한 cleanup 수행은 관리자 또는 외부 관리 시스템에 책임이 있다.
  • 에러에 의한 실패인 경우, 재시도는 수행되지 않으며, 액션에 대한 에러Transition을 수행한다.

Map-Reduce Action

  • 이 액션은 하둡 map/reduce job을 시작한다.
  • map-reduce job을 시작하기 전에 파일 시스템을 cleanup하거나 디렉토리 생성 수행을 설정할 수 있다.
    - 이 기능은 Oozie가 Transition 실패 상황에서 Hadoop job을 재시도 할 수 있게 한다.
  • 워크플로우 job은 하둡 Map/Reduce job이 완료될 때까지 기다린다. 그리고 나서 다음 액션을 계속한다.
  • 하둡 job의 counter와 job exit status (FAILED, KILLED, SUCCEEDED)는 하둡 job이 끝난 후에 워크플로우 job에서 사용가능 해야 한다. 이 정보는 decision 노드나 다른 액션 설정에서 사용 될 수 있다.
  • map-reduce 액션은 필요한 모든 하둡 JobConf 프로퍼티들을 설정해야 한다.
  • 하둡 JobConf 프로퍼티는 워크플로우 애플리케이션과 함께 묶인 JobConf XML 을 지정할 수 있다. 또는 inline map-reduce 액션 설정을 지정할 수 있다.
<workflow-app name="foo-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <action name="myfirstHadoopJob">
        <map-reduce>
            <job-traker>foo:9001</job-tracker>
            <name-node>bar:9000</name-node>
            <prepare>
                <delete path="hdfs://foo:9000/usr/tucu/output-data"/>
            </prepare>
            <job-xml>/myfirstjob.xml</job-xml>
            <configuration>
                <property>
                    <name>mapred.input.dir</name>
                    <value>/usr/tucu/input-data</value>
                </property>
                <property>
                    <name>mapred.output.dir</name>
                    <value>/usr/tucu/input-data</value>
                </property>
                <property>
                    <name>mapred.reduce.tasks</name>
                    <value>${firstJobReducers}</value>
                </property>
            </configuration>
        </map-reduce>
        <ok to="myNextAction"/>
        <error to="errorCleanup"/>
    </action>
    ...
</workflow-app>

Pig Action

  • 이 액션은 Pig job을 시작한다
  • pig jobd이 완료 되고 나서야 다음 액션으로 넘어간다.
  • job-tracker, name-node, pig-script, 파라메터들과 configuration을 설정 할 수 있다.
  • 하둡 JobConf 프로퍼티는 JobConf XML 파일에 지정될 수 있다.
<workflow-app name="sample-wf" xmlns="uri:oozie:workflow:0.2">
    ...
    <action name="myfirstpigjob">
        <pig>
            <job-traker>foo:9001</job-tracker>
            <name-node>bar:9000</name-node>
            <prepare>
                <delete path="${jobOutput}"/>
            </prepare>
            <configuration>
                <property>
                    <name>mapred.compress.map.output</name>
                    <value>true</value>
                </property>
            </configuration>
            <script>/mypigscript.pig</script>
            <argument>-param</argument>
            <argument>INPUT=${inputDir}</argument>
            <argument>-param</argument>
            <argument>OUTPUT=${outputDir}/pig-output3</argument>
        </pig>
        <ok to="myotherjob"/>
        <error to="errorcleanup"/>
    </action>
    ...
</workflow-app>

Fs (HDFS) Action

  • HDFS의 디렉토리와 파일들을 조작할 수 있게 한다.
  • move, delete, mkdir, chmod 을 지원한다.
  • 중요 : fs 액션의 모든 커맨드는 원자적으로 수행되지 않는다. 커맨드가 실행 중간에 fs 액션이 실패한다면 성공적으로 실행된 커맨드는 roll back 되지 않는다. fs 액션은 커맨드가 수행되기 전에 source 경로와 target 경로의 존재와 비존재를 검사해야 한다. 하나의 fs 액션에서 지정된 모든 경로의 유효성이 평가되고 나서야 파일 오퍼레이션이 수행된다. 따라서 fs 액션 실행을 사용하면 에러 발생의 기회가 적다.
<workflow-app name="sample-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <action name="hdfscommands">
         <fs>
            <delete path='hdfs://foo:9000/usr/tucu/temp-data'/>
            <mkdir path='archives/${wf146()}'/>
            <move source='${jobInput}' target='archives/${wf146()}/processed-input'/>
            <chmod path='${jobOutput}' permissions='-rwxrw-rw-'>
                <dir-files>true</dir-files>
            </chmod>
        </fs>
        <ok to="myotherjob"/>
        <error to="errorcleanup"/>
    </action>
    ...
</workflow-app>

Ssh Action

  • 원격 머신에 쉘 커맨드를 시작한다.
  • 원격 쉘 커맨드가 완료도리 때까지 기다린다.
  •  

  • ssh job의 출력 결과(stdout)는 Decision 노드에서 사용 될 수 있다.
    – 출력 결과의 포멧이 유효한 자바 프로퍼티 파일이어야 한다.

     


    – 결과의 크기가 2KB를 초과하면 안 된다
<workflow-app name="sample-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <action name="myssjob">
        <ssh>
            <host>foo@bar.com<host>
            <command>uploaddata</command>
            <args>jdbc:derby://bar.com:1527/myDB</args>
            <args>hdfs://foobar.com:9000/usr/tucu/myData</args>
        </ssh>
        <ok to="myotherjob"/>
        <error to="errorcleanup"/>
    </action>
    ...
</workflow-app>

Sub-workflow Action

  • sub-workflow 액션은 자식 워크플로우 job을 실행한다.
  • 자식 워크플로우는 같은 Oozie 시스템에 있을 수도 있고 다른 Oozie 시스템에 있을 수도 있다.
<workflow-app name="sample-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <action name="a">
        <sub-workflow>
            <app-path>child-wf</app-path>
            <configuration>
                <property>
                    <name>input.dir</name>
                    <value>${wf146()}/second-mr-output</value>
                </property>
            </configuration>
        </sub-workflow>
        <ok to="end"/>
        <error to="kill"/>
    </action>
    ...
</workflow-app>

Java Action

  • 지정한 main java class의 public static void main(String[] args) 메서드를 실행시킨다.
  • 자바 애플리케이션은 하나의 Mapper task 와 함께 map-reduce 처럼 Hadoop Cluster에서 실행된다.
  • 자바 액션은 job-tracker, name-node, main Java class, JVM 옵션과 arguments를 설정할 수 있다
  • main 메서드 실행이 우아하게 완료되면 ok의 액션으로 전환한다
  • Java class가 exception을 던지면 error의 액션으로 전환한다.
  • System.exit(int n)을 호출 해서는 안 된다. 이 것은 exit code에 상관없이 error 전환을 하게 된다.
  • 자바 애플리케이션 시작 전에 HDFS 파일/디렉토리 cleanup을 설정할 수 있다. 이 기능은 transient 또는 non-transient 실패가 발생할 경우 재시도를 할 수 있게 해준다.
  • 파일이나 archive를 추가하는 것이 가능하다.
  • Queue 이름을 설정 프로퍼티로 지정해야 한다.
<workflow-app name="sample-wf" xmlns="uri:oozie:workflow:0.1">
    ...
    <action name="myfirstjavajob">
        <java>
            <job-traker>foo:9001</job-tracker>
            <name-node>bar:9000</name-node>
            <prepare>
                <delete path="${jobOutput}"/>
            </prepare>
            <configuration>
                <property>
                    <name>mapred.queue.name</name>
                    <value>default</value>
                </property>
            </configuration>
            <main-class>org.apache.oozie.MyFirstMainClass</main-class>
            <java-opts>-Dblah</java-opts>
	   <arg>argument1</arg>
	   <arg>argument2</arg>
        </java>
        <ok to="myotherjob"/>
        <error to="errorcleanup"/>
    </action>
    ...
</workflow-app>

Parameterization of Workflows

  • 워크플로우 정의는 파라메터를 받을 수 있다.
  • JSP 2.0 스펙에 JSP Expression Language syntax 를 사용해서 워크플로우 정의에서 파라메터를 지정한다. 파라메터로서 변수 뿐 아니라 복잡한 표현과 함수 또한 지원한다.
  • EL 표현은 액션과 decision 노드들의 설정 값으로 사용된다.
  • Oozie가 워크플로우 노드를 실행 할 때, 모든 EL은 구체적인 값으로 변환된다.
  • 워크플로우 애플리케이션 아카이브와 함께 묶인 config-default.xml 파일에 지정한다.

Workflow Job Properties

  • 하둡 JobConf 프로퍼티와 비슷하게 필요한 job 프로퍼티를 지정할 수 있다.
  • 디폴트는 config-default.xml에서 정의되어 있다. 워크플로우 job 프로퍼티는 디폴트 값을 덮어쓴다.
<workflow-app name='hello-wf' xmlns="uri:oozie:workflow:0.1">
    ...
    <action name='firstjob'>
        <map-reduce>
            <job-tracker>${jobTracker}</job-tracker>
            <name-node>${nameNode}</name-node>
            <configuration>
	      <property>
                    <name>mapred.input.dir</name>
                    <value>${inputDir}</value>
                </property>
                <property>
                    <name>mapred.output.dir</name>
                    <value>${outputDir}</value>
                </property>
                ...
            </configuration>
        </map-reduce>
         ...
     </action>
     ...
</workflow-app>

Expression Language Functions

기본 EL 상수들

  • KB: 1024, one kilobyte.
  • MB: 1024 * KB, one megabyte.
  • GB: 1024 * MB, one gigabyte.
  • TB: 1024 * GB, one terabyte.
  • PB: 1024 * TG, one petabyte.

기본 EL 함수들

  • String firstNotNull(String value1, String value2)
  • String concat(String s1, String s2)
  • String trim(String s)
  • String urlEncode(String s)
  • String timestamp()

워크플로우 EL 함수들

  • String wf146()
  • String wf:name()
  • String wf:appPath()
  • String wf:conf(String name)
  • String wf:user()
  • String wf:group()
  • String wf:callback(String stateVar)
  • String wf:transition(String node)
  • String wf:lastErrorNode()
  • String wf:errorCode(String node)
  • String wf:errorMessage(String messageint wf:run()
  • Map wf:actionData(String node)
  • int wf:actionExternalId(String node)
  • int wf:actionTrackerUri(String node)
  • int wf:actionExternalStatus(String node)

하둡 EL 상수

  • RECORDS: Hadoop record counters group name.
  • MAP_IN: Hadoop mapper input records counter name.
  • MAP_OUT: Hadoop mapper output records counter name.
  • REDUCE_IN: Hadoop reducer input records counter name.
  • REDUCE_OUT: Hadoop reducer input record counter name.
  • GROUPS: 1024 * Hadoop mapper/reducer record groups counter name.

하둡 EL 함수

  • Map <String, Map <String, Long>> hadoop:counters(String node)

HDFS EL 함수들

  • boolean fs:exists(String path)
  • boolean fs:isDir(String path)
  • boolean fs:dirSize(String path)
  • boolean fs:fileSize(String path)
  • boolean fs:blockSize(String path)

Oozie Notification

워크플로우 job은 워크플로우 액션 노드의 시작과 끝과 워크플로우 job의 완료에 대한 HTTP GET 알림을 만들기 위한 설정을 할 수 있다.

Oozie는 알림을 전달하기 위한 최선의 노력을 한다. 실패할 경우에 미리 설정된 횟수와 미리 설정된 간격에서 알림을 재시도 하게 된다.

Workflow Job Status Notification

  • 워크플로우 job 프로퍼티에 oozie.wf.workflow.notification.url 이 설정되어 있다면 job 상태가 변할 때 제공된 URL로 notification을 만든다.
  • URL이 $jobid 와 $status 토큰을 포함하면 실제 값으로 치환 된 후 notification을 만든다.

Node Start and End Notification

  • 워크플로우 job 프로퍼티에 oozie.wf.action.notification.url 이 설정되어 있다면 액션 노드가 시작하고 끝날 때 제공된 URL로 알림을 만든다
  • URL 이 $jobid, $nodeName, $status 토큰을 포함하면 실제 값으로 치환 된 후 알림을 만든다.

Workflow Application Deployment

 

Oozie는 self-contained 애플리케이션의 사용을 장려하지만, 강요하지는 않는다
워크플로우 애플리케이션은 HDFS 디렉토리에 설치된다.


워크플로우 애플리케이션의 job을 submit 하기 위해서 애플리케이션이 있는 HDFS 디렉토리 경로를 지정해야 된다.


애플리케이션 디렉토리의 윤곽은 다음과 같다


/workflow.xml


/config-default.xml


/lib/ (*.jar; *.so)

 

 

워크플로우 애플리케이션은 최소한 워크플로우 정의, workflow.xml 파일은 포함되어야 한다.
워크플로우 액션 노드에서 필요한 모든 설정 파일과 스크립트 (pig 와 shell) 은 애플리케이션 HDFS 디렉토리 밑에 있어야 한다


config-default.xml은 워크플로우 job 파라메터의 기본 값을 정의한다.


– 이 파일은 하둡 설정 XML 포맷이어야 한다.


– EL 표현은 지원되지 않는다.

 

Workflow Jobs Lifecylce

Workflow job 상태의 유효한 전환

 

–--> PREP
PREP --> RUNNING | KILLED


RUNNING --> SUSPENDED | SUCCEEDED | KILLED | FAILED


SUSPENDED --> RUNNING | KILLED

 

Workflow Jobs Recovery (re-run)

 

Oozie는 실패한 워크플로우 job이 resubmit되어 실행이 완료된 어떤 액션 노드 이후로 부터 시작하면서 실행되도록 할 수 있다. 이것은 이미 실행된 액션이 다시 실행하기에는 너무 시간이 많이 들 때 유용하다. 워크플로우 job을 다시 제출 할 때 이전 실행에서의 데이터를 지우지 않아서 실패하는 경우의 책음은 사용자에게 있다.
recovery 모드로 workflow job을 시작할 때, 사용자는 워크플로우에서 어떤 노드를 건너뛰어야 하는지 지정해야 한다.


oozie.wf.rerun.skip.nodes job 설정 프로퍼티에 지정한다. (콤마 구분)


지정된 노드는 이전 실행에서 완료된 것들이어야 한다. 그러지 않으면 재실행이 실패한다.


회복 워크플로우 job은 기존과 동일한 Job ID를 가진다.


회복 워크플로우 job을 실행하기 위해서는 목표 워크플로우 job 이 종료 상태이어야 한다 ( SUCCEEDED, FAILED, KILLED)


회복 실행시 다른 job 파라메터를 사용할 수 있다.

 

Oozie Web Services API, V0

 

Oozie 웹 서비스 API는 HTTP REST JSON API 이다.
시스템의 상태, 운영체제 환경, 시스템 프로퍼티, 설정, 계측정보를 제공한다.


job에 대한 정보, 로그, 정의 정보를 제공


job 제출, 관리(시작, 중단, 재시작, kill) request 제공한다.

 

Request:

POST /oozie/v0/jobs
Content-Type: application/xml;charset=UTF-8
.
<?xml version="1.0" encoding="UTF-8"?>

    
        user.name
        tucu
    
    
        oozie.wf.application.path
        hdfs://foo:9000/user/tucu/myapp/
    
    ...
Response:

HTTP/1.1 201 CREATED
Content-Type: application/json;charset=UTF-8
.
{
  id: "job-3"
}

Reference

Posted by 김민우 julingks

Pig Latin Menual

Hadoop 2011.03.02 21:04

Pig Latin Statements

Pig Latin 구문은 입력으로 relation를 취해 출력으로 또 다른 relation을 생성하기 위한 구문이다.
이 정의는 모든 Pig Latin Operator에 적용된다. (파일시스템에 데이터를 읽거나 쓰는 LOAD 와 STORE Operator는 제외)
Pig Lain 구문은 일반적으로 다음 방법으로 구성된다.

  • LOAD 구문은 파일 시스템에서 데이터를 읽는다.
  • “변형” 구문의 시리즈는 데이터를 처리한다
  • STORE 구문은 파일 시스템에 출력결과를 쓴다. 또는 DUMP 구문은 결과를 화면에 출력한다.

Pig Latin 실행하기

GruntShell - 인터렉티브, 맵리듀스 모드 (맵리듀스 모드가 default)

$ pig
… - Connectiong to …
grunt> A = load ‘data’;
grunt> B = …;

grunt Shell – 배치, 로컬 모드

$ pig -x local
grunt> exec myscript.pig;
or
grunt> run myscript.pig;

커맨드 라인 배치, MapReduce 모드

$ pig myscript.pig

커맨드 라인 – 배치, 로컬 모드

$ pig -x local myscript.pig

주석 사용하기

만약 스크립트에서 Pig Latin 구문에 주석을 넣고 싶다면,

  • 여러 줄을 주석 처리하기 위해서 /* ... */ 를 사용한다
  • 한 줄을 주석처리 하기 위해서 – 을 사용한다
/* myscript.pig My script includes three simple Pig Latin Statements. */
A = LOAD 'student' USING PigStorage() AS (name:chararray, age:int, gpa:float); -- load statement
B = FOREACH A GENERATE name; -- foreach statement 
DUMP B; --dump statement

Pig Latin 결과 가져오기

Pig Latin은 결과를 가져올 수 있는 명령을 포함한다.

  • DUMP 명령은 화면에 결과를 보여준다
  • STORE 명령은 파일 시스템 위 파일에 결과를 쓴다

중간 데이터 저장

Pig는 MapReduce Job들 사이에서 생성된 중간 데이터를 HDFS 위에 임시 위치에 저장한다.
위치는 사용하기 전에 미리 HDFS에 존재해야 한다.
위치는 pig.temp.dir 프로퍼티로 설정할 수 있고, 기본값은 /tmp이다. 0.7.0 이전 버전에서는 하드코딩 되어 있다.

Pig Latin 디버깅 하기

Pig Latin은 디버깅을 도와주는 명령을 포함한다

  • DESCRIBE 명령으로 relation의 스키마를 볼 수 있다.
  • EXPLAIN 명령으로 relation를 계산하는데 논리적, 물리적, 맵리듀스의 execution plan을 볼 수 있다.
  • ILLUSTRATE 명령을 사용하면 구문의 시리즈를 단계적(step-by-step)으로 볼 수 있다.

복잡한 Pig 스크립트는 종종 많은 MapReduce Job을 만들어 낸다. 스크립트를 디버깅 하는데 도움을 주기 위해, Pig는 어느 relation(alias)들이 각각 MapReduce Job에 맵핑 되었는지를 보여주는 실행 요약을 출력한다.

JobId Maps Reduces MaxMapTime MinMapTIme AvgMapTime MaxReduceTime MinReduceTime AvgReduceTime  Alias Feature Outputs
job_201004271216_12712 1 1 3 3 3 12 12 12 B,C GROUP_BY,COMBINER 
job_201004271216_12713 1 1 3 3 3 12 12 12 D SAMPLER 
job_201004271216_12714 1 1 3 3 3 12 12 12 D ORDER_BY,COMBINER hdfs://wilbur20.labs.corp.sp1.yahoo. com:9020/tmp/temp743703298/tmp-2019944040

데이터 작업하기

Pig Latin은 많은 방식으로 데이터 작업을 할 수 있게 해준다.
FILTER 데이터의 tuple과 row 작업을 하는 명령어다. FOREACH 명령어를 사용해 데이터의 컬럼 작업을 한다.
GROUP은 하나의 relation 에서 데이터를 Grouping하기 위한 명령이다. 두 개 이상의 relations을 조인하거나 grouping 하기 위해서 COGROUP과 JOIN 명령을 이용한다.
두 개 이상의 relation의 내용을 병합할 때 UNION 명령을 사용한다

대소문자 구별

Relation의 이름(alias)와 필드는 대소문자를 구별한다. (case sensitive)
Pig Lain 함수의 이름들은 대소문자를 구별한다.
파라메터의 이름과 Pig Latin의 모든 다른 키워드들은 case insensitive하다

grunt> A = LOAD 'data' USING PigStorage() AS (f1:int, f2:int, f3:int); 
grunt> B = GROUP A BY f1; 
grunt> C = FOREACH B GENERATE COUNT ($0);
grunt> DUMP C; 
  1. Relation A, B, C의 이름은 case sensitive
  2. 필드 f1, f2, f3 의 이름은 case sensitive
  3. 함수 이름  PigStorage 와 COUNT 는 case sensitive
  4. 키워드 LOAD, USING, AS, GROUP, BY, FOREACH, GENERATE, DUMP 는 case insensitive
  5. FOREACH 구문에서 relation B의 필드는 위치 notation인 ($0)에 의해 참조된다.

다중 쿼리 실행

다중 쿼리 실행에서 Pig는 전체 스크립트 또는 구문의 batch를 한 번에 처리한다

켜고 끄기 (Turning it On or Off)

다중 쿼리 실행은 default로 켜져 있다.
기능을 끄기거나 Pig의 “execute-on-dump/store” 행동 되돌리기 위해서는 –M 또는 –no_multiquery 옵션을 사용한다.
최적화 없이 myscript.pig를 실행하기 위해서는, 다음과 같이 pig를 실행시킨다

$ pig -M myscript.pig
or
$ pig -no_multiquery myscript.pig

어떻게 동작하나?

다중 쿼리 실행은 몇 가지 다른 점을 소개한다

  1. 배치 실행 모드에서, 전체 스크립트는 작업이 완료되어야 하는 전체의 일의 양을 줄이기 위해서 중간 태스크들은 조합 될 수 있는지를 결정하기 위해 첫 번째로 parsing을 한다. 실행은 오직 parsing이 완전히 끝난 후에야 시작된다.
  2. “Explicit and Implicit Splits” “중간결과 저장 하기” 에 의해 최적화된다

Explicit and Implicit Splits

같은 데이터 스트림의 분리된 부분이 각각 다른 처리를 원할 경우

예시1

A = LOAD ...
...
SPLIT A' INTO B IF ..., C IF ...
...
STORE B‘ ...
STORE C' ...

예시2

A = LOAD ...
...
B = FILTER A' ...
C = FILTER A' ... 
...
STORE B' ...
STORE C' ...

이전 Pig 버전에서, 예시1 은 A를 디스크에 dump하고 B와 C를 위한 job을 시작했다. 예시2는 B의 종속된 모든 것들을 실행하고, 저장한다. 그리고 나서 C의 모든 종속된 것을 실행하고 저장한다. 둘 다 모두 동일하다. 그러나 성능은 다르다.
다중 쿼리실행이 성능을 증가시키기 위해 하는 것들

 

  1. 예시2 에서 implicit split을 추가하여 예시1 의 쿼리로 변형한다. A’ 다중 처리를 제거한다.
  2. split non-blocking 을 만들고, 처리를 계속하도록 한다. 이것은 split에 오른쪽에 저장되어야 하는 데이터의 양을 줄이는 데 도움이 된다.
  3. job들로 부터 다중 출력을 허용한다. 이 방식은 메인 job의 side-effect 로 약간의 결과가 저장될 수 있다. 이것은 이전 아이템을 작동하게 하는데 또한 필요하다.
  4. 여러 개의 split이 combiner/reducer로 옮겨지도록 branch를 허용한다. 이것은 combiner에서 이익을 얻을 수 있는 split에 있는 여러 개의 branch가 실행하는 경우에 IO의 양을 줄인다.

중간 결과 저장하기

때로는 중간 결과를 저장하는 것이 필요하다

A = LOAD ...
...
STORE A‘
...
STORE A''

만약 스크립트가 A의 처를 위해서 A’를 re-load하지 않는다면, A’  이후의 단계는 중복되게 된다. 이것은 전에 예시2의 특별한 경우이다. 그래서 동일한 단계 추천된다. 다중 쿼리 실행에서 스크립트는 A을 처리하고 side-effect로서 A’를 dump하게 될 것이다.

Error Handling

다중-쿼리 실행에서 Pig는 전체 스크립트 또는 구문의 배치를 한 번에 처리한다.
default로 Pig는 실행 중에 몇몇 job들이 실패했는지에 상관없이 모든 job들을 실행을 시도한다.
job들이 성공했는지, 실패했는지 검사하기 위해서, 다음 옵션들을 중 하나를 사용한다.

 

  1. 첫 번째, Pig 그는 모든 성공하거나 실패한 store 명령의 로그를 남긴다.  Store 명령들은 output path에 의해 식별된다. 실행의 끝에서 store명령의 summary line이 성공, 부분 실패, 모두 실패를 가리킨다.
  2. 두 번째, Pig는 다음 시나리오들을 위해서 완료 코드를 return 한다

         - Return code 0 : 모든 job들이 성공
         - Return code 1 : 다시 시도 할 수 있는 에러들에 사용됨
         - Return code 2 : 모든 job들이 실패
        - Return code 3 : 일부 job들이 실패

첫 번째 실패한 job을 감지했을 때 전체 스크립트를 실패시켜야 바람직할 때가 있다.

이 경우 커맨드 라인에 –F 나 –stop_on_failure 를 사용한다. 이를 사용하면 pig는 첫 번째 실패한 job을 감지하면 남은 처리를 계속하지 않고 실행을 중지 시킨다. 

최적화 규칙

Pig는 다양한 최적화 규칙을 지원한다.
Default 로 모든 최적화 규칙이 켜져 있다. 최적화를 크기 위해서는 다음을 사용한다.

pig –optimizer_off  [ opt_rule | all ]

ImplicitSplitInserter

필수
Split는 Pig에서 여러 개의 결과를 모형화 하는 유일한 operator이다. logicl plan을 만드는 처리를 쉽게 하기 위해, 모든 operator들은 다중 출력 가지도록 허용한다.
최적화의 부분으로서, 다중 출력을 가지는 모든 non-split operator들은 SPLIT operator를 가지도록 변경한다

A = LOAD 'input';
B = FILTER A BY $1 == 1;
C = COGROUP A BY $0, B BY $0

위에서, LOAD 다음에 split을 삽입한다. split의 결과는 FILTER와 COGROUP을 연결한다

LogicalExpressionSimplifier

1) 상수를 미리 계산
B = FILTER A BY a0 > 5+7;
B = FILTER A BY a0 > 12;

2) 부정 제거
B = FILTER A BY NOT (NOT(a0 > 5) OR a > 10);
B = FILTER A BY a0 > 5 AND a <= 10; 3)

3) AND에서 논리적 implied 표현 제거
B = FILTER A BY (a0 > 5 AND a0 > 7);
B = FILTER A BY a0 > 7; 4)

4) OR에서 논리적 implied 표현 제거
B = FILTER A BY ((a0 > 5) OR (a0 > 6 AND a1 > 15);
B = FILTER C BY a0 > 5;

5) 동등 제거
B = FILTER A BY (a0 v 5 AND a0 > 5);
B = FILTER A BY a0 > 5; 

6) OR에서  보수 표현 제거
B = FILTER A BY (a0 > 5 OR a0 <= 5); 는 실행 되지 않음

7) 순수 TRUE 표현 제거
B = FILTER A BY 1==1; 는 실행되지 않음

MergeForEach

이 규칙의 목적은 두 개의 foreach 구문이 다음 선행조건이면 함께 병합 하는데 있다.

  • foreach 구문이 연속적이다
  • 첫 번째 foreach 구문이 flatten을 포함하지 않는다.
  • 두 번째 foreach 가 nested 하지 않다.
-- 오리지널 코드:
A = LOAD 'file.txt' AS (a, b, c);
B = FOREACH A GENERATE a+b AS u, c-b AS v;
C = FOREACH B GENERATE $0+5, v;

-- 최적화된 코드:
A = LOAD 'file.txt' AS (a, b, c);
C = FOREACH A GENERATE a+b+5, c-b;

OpLimitOptimizer

이 규칙의 목적은 LIMIT operator를 데이터 플로 그래프에 밀어 올린다.
ORDER BY 다음에 LIMIT 가 오면, LIMIT를 ORDER BY로 밀어 올린다

A = LOAD 'input';
B = ORDER A BY $0;
C = LIMIT B 10;

PushUpFilters

이 규칙의 목적은 FILTER 오퍼레이터를 데이터 플로 그래프에서 밀어 올린다.
결과적으로, 파이프라인을 통해 흐르는 레코드의 수를 줄인다.

A = LOAD 'input';
B = GROUP A BY $0;
C = FILTER B BY $0 < 10;

PushDownExplodes

이 규칙의 목적은 FLATTEN과 함께 있는 FOREACH 오퍼레이터ㄹ,ㄹ 데이터 플로 그래프 밑으로 움직여 파이프라인을 통해서 흐르는 레코드의 수를 줄이는데 있다.
밑에 예제에서 보이는 것처럼, foreach를 join 다음으로 이동하면, join 오퍼레이터의 비용을 줄이는 데 좀 더 효과적이다

A = LOAD 'input' AS (a, b, c);
B = LOAD 'input2' AS (x, y, z);
C = FOREACH A GENERATE FLATTEN($0), B, C;
D = JOIN C BY $1, B BY $1

TypeCastInserter

필수
만약 LOAD구문에서 스키마를 지정한다면, Optimizer는 컬럼들의 미리 수정된 projection을 수행한다. 그리고 컬럼을 적절한 타입으로 캐스팅한다.

A = LOAD 'input' AS (name: chararray, age: int, gpa: float);
B = FILER A BY $1 == 1;
C = GROUP A By $0;

예제에서, LOAD구문은 스키마를 가진다. Optimizer는 0,1,2번째 컬럼을 Project하는 FOREACH 오퍼레이터를 삽입할 것이다. 또한 컬럼은 chararray, int, float로 각각 캐스팅 한다.

Specailized Joins

inner 조인과 outer 조인의 성능은 은 replicated, skewed, merge 조인을 사용하여 최적화 될 수 있다.


Replicated Joins

Fragment replicate join은 조인의 특별한 타입이다. 하나 이상의 관계들이 메인 메모리에 들어갈 정도로 충분히 작다면 잘 작동한다. 어떤 경우에서, Pig는 매우 효율적인 조인을 수행한다. 모든 하둡 작업이 맵쪽에서 끝나기 때문에. 조인의 이런 타입에서, 매우 큰 relation은 하나이상의 작은 relation 이 따라온다. 작은 relation은 메인 메모리에 들어갈 정도로 충분히 작아야 한다. 그러지 않으면 처리는 실패하거나 에러가 발생한다.

big = LOAD 'big_data' AS (b1,b2,b3);
tiny = LOAD 'tiny_data' AS (t1,t2,t3);
mini = LOAD 'mini_data' AS (m1,m2,m3);
C = JOIN big BY b1, tiny BY t1, mini BY m1 USING 'replicated';

USING 절을 이용하여 replicated join을 수행한다. 예제에서 큰 relation은 두 개의 작은 relation과 join된다. 큰 relation은 첫 번째로 오고 다음으로 작은 relation들이 온다. 작은 relation 모두 메인 메모리에 들어갈 정도여야 한다. 아니면 에러가 발생한다.

이 조인은 실험적이다. 얼마나 작은 relation이 얼마나 작아야 메모리에 들어가는지에 대한 직감은 없다. 처리에 전체 1GB 메모리가 필요하다면 100M 까지 relation 이 JOIN에 포함된다.

Skewed joins

parallel 조인은 기반 데이터에서 skew의 존재의 취약하다. 기반 데이터가 충분히 skew하다면, load 불균형은 parallelism의 이득의 어떤 것이든 수렁에 빠트린다.
이런 문제에 대응하기 위해서, skewed join은 키 스페이스의 히스토그램을 계산한다. 이 데이터를 이용하여 주어진 키에 대해서 reducer들을 할당한다. skewed join은 입력 키의 크기에 제한을 두지 않는다. 조인 predicate의 왼쪽 입력을 쪼개고 오른쪽 입력에 흘려보내서 조인을 완수 한다. 왼쪽 입력은 히스토그램을 만들기 위해서 샘플링 된다.
Skewed join은 기반 데이터가 충분히 skewed하거나 skew 에 대응하기 위해서 reducer들의 할당의 미세한 조종을 원할 때 사용된다.
주어진 키와 연관된 데이터가 메모리에 넣기에 너무 클 때 사용 해야 한다.
USING 절을 이용하여 skewed join을 수행한다.

big = LOAD 'big_data' AS (b1,b2,b3);
massive = LOAD 'massive_data' AS (m1,m2,m3);
C = JOIN big BY b1, massive BY m1 USING 'skewed';

두 개의 테이블을 inner join 할 경우. 현재 두 이상의 테이블 join을 지원하지 않는다. 3-wy 조인은 validation에서 실패한다. 이 경우 2-way 조인으로 분해해야 한다.

pig.skewedjoin.reduce.memusage 자바 파라메터는 조인 수행을 위한 reducer의 가능한 heap의 fraction을 지정한다. 낮은 fraction은 pig가 더 많은 reducer를 사용하게 해서 복사 비용을 증가시킨다. 우리는 0.1 – 0.4 범위의 값을 했을 때 좋은 성능을 보여졌지만 이것은 거의 정확한 범위가 아니다. 기본작ㅄ은 0.5이다. 실험을 통해서 좋은 성능에 도달하는 값을 얻어야 한다.

Merge Joins

사용자 데이터는 두 입력 모두가 조인 키로 이미 정렬된 상태로 저장되는 경우가 종종 있다.
이 경우에 MapReduce job의 map 단계에서 데이터를 조인하는 게 가능하다.

Pig는 merge join 알고리즘을 구현했다. (이미 정렬이 되어 있다고 가정한 경우에서)
Pig는 조인의 왼쪽 입력을 map 단계에서 입력 파일로 선택하고 조인의 오른쪽 입력은 side 파일로 선택하는 merge join 알고리즘을 구현했다. 각각 샘플링 된 레코드에 키, 파일이름, offset , 시작 레코드를 포함하는 인덱스를 만들기 위해서 오른쪽 입력으로 부터 레코드를 샘플링 한다. 이 샘플링은 첫 번째 MapReduce job에서 끝난다. 두 번째 MapReduce job은에서 왼쪽 입력이 시작 된다. 각각 map은 오른쪽 입력에서 적절한 레코드를 찾기 위해서 인덱스를 사용한다. 그리고 조인을 시작한다.

C = JOIN A BY a1, B BY b1, C BY c1 USING 'merge';

Inner Merge 조인은 다음 조건에서 작동한다

  • 정렬된 입력과 merge join 구문 사이에서 filter 구문 과 foreach 구문이 있을 수 있다. foreach 구문은 다음 조건을 만족해야 한다
        – foreach 구문에서 UDF가 없어야 한다
        –  foreach구문은 조인 키의 위치를 변경하지 말아야 한다
       – 정렬 순서를 변경하는 조인 키의 변형이 없어야 한다
  • 데이터는 양 족 모두 조인 키가 오름차순으로 정렬되어야 한다
  • 오른쪽 loader는 {OrderedLoadFunc} 인터페이스, {indexableLoadFunc} 인터페이스 모두 구현해야 한다
    타입 정보는 스키마에서 조인 키에 제공되어야 한다.
Posted by 김민우 julingks

Apache pig install

Hadoop 2011.02.24 18:05

Requirements

유닉스 또는 윈도우즈 사용자는 다음이 필요하다

윈도우즈 사용자는 Cygwin과 Perl Package 설치가 필요하다.

Pig를 다운 받는다.

Pig 배포판을 얻기 위해서 아파치 다운로드 미러 중에서 최신의 안저된 버전을 다운로드 한다.
압축을 푼다. Pig 스크립트는 bin 디렉토리에 있다.  (/pig-x.x.x/bin/pig)
/pig-x.x.x/bin 을 path 에 추가한다

$ export PIG_HOME=/path-to-pig/pig-0.8.0
$ export PATH=$PIG_HOME/bin/:$PATH

다음 명령어로 pig 커맨드의 리스트를 보자

$ pig -help

다음 커맨드로 Grunt shell을 시작할 수 있다.

$ pig

 

Run Modes

Pig는 두 가지 실행 모드가 있다

  • 로컬 모드 - 로컬 모드로 pig를 실행하기 위해서는 하나의 머신에 접속이 필요하다.
  • Mapreduce 모드 - mapreduce 모드로 pig를 실행하기 위해서는 하둡 클러스터와 HDFS 설치에 접긴이 필요하다

이제 Grunt shell, Pig 스크립트, 두 모드를 사용하는 임베디드 프로그램을 실행시킬 수 있다.

Grunt Shell

pig 커맨드를 직접 입력하고 싶다면 Pig의 인터렉티브한 쉘 Grunt 를 사용해라.

Local Mode

$ pig -x local

Mapreduce Mode

$ pig
or
$ pig -x mapreduce

두가지 모두에서, Grunt shell 이 실행되면 프롬프트에서 커맨드를 입력할 수 있다. 결과는 터미널 화면(DUMP 사용시)이나 파일(STORE 사용시)에 출력된다.

grunt> A = load ‘passwd’ using PigStorage(‘:’);
grunt> B = foreach A generate $0 as id;
grunt> dump B;
grunt> store B;

Script Files

배치 job들을 pig 커맨드로 실행할 때는 스크립트 파일을 이용해라.

Local mode

$pig -x local id.pig

 

Mapreduce Mode

$ pig id.pig
or
$ pig -x mapreduce id.pig

두가지 모드에서  Pig Latin 문이 실행되고 결과는 터미널 화면(DUMP 사용시)이나 파일(STORE 사용시)로 출력된다.

Reference
Posted by 김민우 julingks
TAG install, Pig

Apache Pig는 데이터 분석 프로그램을 표현하기 위한 high-level 언어로 구성된  대용량 데이터 셋 분석을 위한 플랫폼이다. 또 이들 프로그램을 평가하기 위한 infrastructure 와 짝을 이룬다. Pig 프로그램의 두드러지는 특성은  튼튼한 병렬화를 위한 구조가  의무적이다. 이것은 매우 큰 데이터 셋을 다룰 수 있도록 한다.

현재에는 Pig의 infrastruture 레이어는 이미 존재하는 대용량 병령 구현물들의 Map-Reduce 프로그램의 순서를 실행하는 컴파일러로 구성된다. Pig의 언어 레이어는 Pig Latin으로 불리는 본문 언어로 구성된다. 이 언어는 다음 핵심 특성을 가진다.

  • 프로그래밍 하기 쉽다. 간단한 “놀랍게도 병렬” 데이터 분석 테스크의 병렬 실행을 달성하는 것은 평범한 일이다. 여러 개의 밀접한 관계의 데이터 변환으로 구성된 복잡한 태스크도 명쾌하게 데이터 플로우 시퀀스로 인코드 된다. 이 데이터 플로우는 복잡한 테스크를  쓰고, 이해하고, 유지하기 쉽게 만든다.
  • 최적화 기회. 테스크를 인코드하는 방법은 시스템이 자동적으로 실행을 최적화하도록 허가한다. 이는 용자는 효율성 보다는 시멘틱에 집중하도록 한다.
  • 확장성. 사용자는 특별한 목적의 처리를 하기 위한 자신 만의 함수를 작성할 수 있다.

Reference

Posted by 김민우 julingks

Bigtable

Hadoop 2011.02.14 13:02

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

데이터 모델은 분산돼 있는 다차원으로 정렬된 맵이다. 모든 데이터는 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 -> 루트 테블릿 - > 메타 테블릿 순으로 찾는다.

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

Posted by 김민우 julingks