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

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

야후에서 분사한 하둡 빅데이터 스타트 업

This document is translated from http://www.informationweek.com/news/development/database/231000658

InformationWeek의 2011년 6월 28일자 기사

---

빅데이터 분석을 위한 오픈소스 코드 개발의 속도를 높이기 위해서 Hortonworks 스타트업은 야후에서 개발자와 투자 자본을 가져왔다. 야후의 핵심 개발자 그룹은 하둡의 더 빠른 엔터프라이즈 스타일의 개발을 위해서 벤처캐피탈로 부터 지원을 받고 야후에서 분사했다. 몇 일 안에 하둡 코드에 "20개 이상 커밋한" 핵심 커미터들과 아키텍트는 캘리포니아 Sunnyvale에 있는 야후 캠퍼스에서 독립회사인 Hortonworks 사무실로 옮길 것이라고 하둡 소프트웨어 엔지니어의 야후 VP인 Eric Baldeschwieler가 인터뷰에서 밝혔다.그는 새로운 회사의 CEO가 될 것이다.

리딩 조직들은 그들의 가장 큰 이익을 낼 수 있는 고객들과 잠재적 라이벌들을 식별하기 위해서 비지니스 애널리틱스를 받아들이고 있다.

Hortonworks의 이름은 Dr.Sesuss의 동화책에 나오는 Horton이라는 코끼리에서 따왔다. 하둡은 원래 Dave Cutting의 아이들의 코끼리 장난감의 이름이다.

하둡 상용화를 주력으로 하는 자급자족(self-sufficient) 회사를 만들기 위한 이동은 지난주 LexNexis의 High Performance Computing Cluser(HPCC) 빅데이터 시스템이 공개적으로 오픈소스로서 사용가능하게 될 것임이 공표한 후에 뒤따랐다. HPCC는 빅데이터를 다루는 무대에서 하둡의 미래 경쟁자라고 대변인은 말했다.

야후의 클라우드 플랫폼의 Senior VP인 Jay Rossiter는 Hortonworks는 야후의 축복을 받을 뿐아니라 벤치마크 캐피탈과 마찬가지로 야후가 투자자가 될 것이다.

야후를 떠나는 개발자의 수는 전체 하둡 개발자 수의 일부이다. 두 개의 그룹은 다음 하둡 릴리즈를 함께 협력 개발(co-develop)할 것이라고 인터뷰에서 Rossiter가 말했다

벤치마크에서 파트너인, Rob Bearden은 Hortonworks의  COO가 될 것이다. 그는 자바 개발자를 위한 스프링 프래임웍을 지원하는 회사인 SpringSource의 전 회장이다 SpringSource는 2009년에 VMWare에 $420 밀리언(약 495억)에 인수되었다. 그는 또한 RedHat에 팔린 오픈소스 자바 애플리케이션 서버, JBoos의 전 COO이다. 그는 현재 오픈소스 Business Intelligence 시스템 공급자인 Pentaho의 의장(chairman)이다.

"Hortonworks는 하둡의 핵심 개발을 계속할 것이다. 또 쉬운 설치와 쉬운 사용 기능을 설계할 것이다."라고 인터뷰에서 Bearden은 말했다. 모든 개발자는 아파치 소프트웨어 파운데이션의 하둡 오픈소스 프로젝트에 기여하게 된다.
하둡은  Cutting이 야후에 엔지니어였을 때, 그의 파트너, Mike Cafarella에 의해 2005년에 만들어졌다. 야후는 세계에서 가장 큰 사용자중 한명이다. 야후 개발자들은 하둡 코드의 약 70%를 기여해왔다고 믿고 있다.

Cutting은 2009년에 초기 하둡 스타트업 Cloudera를 위해서 야후를 떠났다. Cloudera는 하둡 패키저와 ease-of-implementation 벤더로서 설립되었다. Hortonworks와 Cloudera는 잠재적인 경쟁자이다. 5월에는  $9.25 밀리언(약 109억) 벤처 펀딩을 받은 또 다른  하둡 스타트업 Datameer가 나타났다. 이 숫자는 Hortonworks 뒤에서 펀딩하기 위한 것임이 드러났다.

앞선 2월에는, 야후는 자신들의 하둡 프로덕션 버전을 테스트를 했다. 테스팅과 패칭의 지식은 대부분 알려졌다. 그들의 프로덕션 버전은 야후에서 사용 가능하도록 했기 때문에 빈번히 다른 회사들에 도입되었다. 이제 아파치로 부터 발산되는 빌드와 업데이트의 가장 믿을 만한 버전들이 사용된다.

Baldeschwieler는 야후가 하둡의 향상과 변경에 대한 중요한 시험장으로 남을 것이라고 말했다. 야후는 18개의 하둡 시스템을 운영 중이다. 총 42,000대의 서버들 위에서 다음 기능등을 수행한다.

  • 웹 컨텐트 인덱싱
  • 야후 싸이트 방문자들에 대한 개인화된 컨텐트 딜리버리
  • 야후의 이메일 서비스 스팸 스크리닝
  • 하둡 검색  사용자에게 광고 제공

Rossiter는 하둡 애플리케이션을 통해 개인의 흥미와 일치되는 내용을 띄우므로서 270%까지 홈페이지 클릭율(Click-through rate)를 높일 수 있었다고 말했다.

Baldeschwieler는 벤치마크 캐피탈이 하둡에 대해서 투자 하고 싶어했고 야후가 리딩 개발자들 팀을 분리하도록 유도했다고 말했다. 야후는 하둡을 떠받치는 활발한 커뮤니티를 보기 원했고, 엔터프라이즈에 넓게 도입되는 것을 원했기 때문에 분사에 동의했다. 엔터프라이즈 소프트웨어를 만드는 노력을 할 회사는 이 목표를 진행시킬 것이다.

야후가 42,000대의 서버들 위에서 하둡을 실행할 지라도, 하나의 시스템을 실행하는 가장 많은 서버는 4,000대이다.하둡은 병렬 파일 분산 시스템이다. 파일이 어느 클러스터에 위치해 있는지 맵핑하고, 정렬과 분석작업을 데이터와 가까운 노드로 보낸다.

Baldeschwieler는 말했다. 수백만개의 작은 이미지 타일을 사용해서 미국의 지도를 만드는 복잡한 문제는 기존 야후 그래픽 처리 시스템으로는 6달이 걸렸다. 하둡을 처리에 추가했을 때 5일이 걸렸다. Hortonworks는 하둡 성능을 향상시키는데 초점을 맞출것이다. 설치하기 쉽게 만들고, 서드 파티들이 모니터링과 관리 시스템을 붙이기 위해서 사용하는 API를 제공할 것이다. 
야후는 또한 하둡 개발 그림안에 남을 것이다. 많은 수의 개발자들이 프로젝트에 커밋하는 것을 유지할 것이다.

"야후는 하둡의 선구자적인 리더쉽을 제공하는 것을 지속할 것이다. 우리는 비길 데 없는 도메인 전문가들이 있다" 라고 Rossiter는 발혔다. 야후는 하둡 변경 사항이 최대로 반영되는 테스팅과 대규모 프로덕션 환경을 제공할 것이다. 하둡은 회사 안에서 1,000명 이상의 사용자를 가지고 있다고 그는 말했다.

"우리는 5년 안에 세상의 데이터의 절반 이상은 아파치 하둡에 저장 될 것임을 고대한다"라고 Baldeshwieler는 Hortonworks 발표에서 말했다.

 

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

Hive 0.7.0 New Features

Hive 2011.06.12 23:18

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310843&version=12315150

New Features

  • [HIVE-78] - Authorization infrastructure for Hive
  • [HIVE-417] - 하이브에서 인덱스 구현
  • [HIVE-471] - 자바 메서드 reflective invocation을 위한 reflect() UDF 추가
  • [HIVE-537] - 하이브 TypeInfo/ObjectInspector 객채가 union을 지원 (struct, array, map)
  • [HIVE-842] - 사용자 권한 인프라스트럭처
  • [HIVE-1096] - 하이브 변수
  • [HIVE-1293] - 하이브를 위한 동시성 모델
  • [HIVE-1304] - row_sequence UDF 추가
  • [HIVE-1405] - 다른 SQL 커맨드 이전에 파일을 초기화 파일을 실행하는 커맨드 라인 -i 옵션
  • [HIVE-1408] - 튜닝할 수 있는 휴리스틱 기반의 로컬 모드에서 자동적으로 하이브를 실행하는 옵션 추가
  • [HIVE-1413] - 테이블/파티션을 오프라인으로 가져오기
  • [HIVE-1438] - 자연어 tokenization을 위한 sentences() UDF
  • [HIVE-1481] - 기존 top-k n-gram 빈도수를 예측하기 위한 ngrams() UDAF
  • [HIVE-1514] - 파티션의 파일포맷과 파일 위치 정보를 수정할 수 있다.
  • [HIVE-1518] - top-k econtextual n-grams 추정하기 위한 UDFA context_ngrams() 추가
  • [HIVE-1528] - json_tuple() UDTF 함수 추가
  • [HIVE-1529] - ANSI SQL covariance 집계 함수들 (covar_pop과 covar_samp 추가)
  • [HIVE-1549] - ANSI SQL 연관 집계 함수 추가 (CORR(X,Y))
  • [HIVE-1609] - 메타스토어에서 파티션 필터링 지원
  • [HIVE-1624] - S3에 위치한 스크립트 허용
  • [HIVE-1636] - SHOW TABLES {FROM | IN} db_name 구현
  • [HIVE-1659] - parse_url_tuple : parse_url의 UDTF 버젼
  • [HIVE-1661] - 파라메터들의 디폴트 값들
  • [HIVE-1779] - str_to_map의 GenericUDF 구현
  • [HIVE-1790] - Hive에서 HAVING 절 지원
  • [HIVE-1792] - 자동적으로 맵-조인으로 전환되는 조인들을 추적한다
  • [HIVE-1818] - jmx를 통해 HiveMetaSotre를 위한 빈도수와 지속시간 메트릭을 호출한다
  • [HIVE-1819] - 메타스토어에서 lastAccessTime을 유지한다
  • [HIVE-1820] - Hive 데이타베이스 데이터 센터를 알린다
  • [HIVE-1827] - 테스트에 새로운 로컬 모드 flag 추가
  • [HIVE-1835] - 하이브를 위한 더 낳은 자동 완성 기능
  • [HIVE-1840] - 데이터 프로퍼티들을 변경하기 위한 ALTER DATABASE 지원
  • [HIVE-1856] - DROP TABLE/VIEW ... IF EXISTS 구현
  • [HIVE-1858] - DROP {PARTITION, INDEX, TEMPORARY FUNCTION} IF EXISTS 구현
  • [HIVE-1881] - 메타스토어 파일시스템 인터페이스가 hive.metastore.fs.handler.class.configuration property 를 통해서 연결되도록 한다.
  • [HIVE-1889] - 인덱스 파일들에 저장된  HDFS 위치를 무시하도록하는 hive.index.compact.file.ignore.hdfs 옵션 추가
  • [HIVE-1971] - Hive CLI 를 위한 verbose(진행 메세지 표시)/echo 모드
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

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

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

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

Reference

Posted by 김민우 julingks

DDL Operation

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

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

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

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

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

hive> SHOW TABLES;

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

hive> SHOW TABLES ‘.*s’;

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

hive> DESCRIBE invites;

컬럼의 목록을 보여준다.

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

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

테이블 drop

hive> DROP TABLE pokes;

 

Metadata Store

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

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

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

DML Operation

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

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

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

알아야 할 점

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

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

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

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

SQL Operation

Example Queries

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

SELECTS and FILTERS

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

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

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

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

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

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

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

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

GROUP BY

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

MULTITABLE INSERT

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

JOIN

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

 

STREAMING

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

 

Reference

Posted by 김민우 julingks
TAG ddl, dml, Hadoop, hive, NoSQL, SQL

Hive는  하둡 위에서 돌아가는 데이터 웨어하우스 인프라 스트럭처다.   하둡에 저장된 데이터를 요약, adhoc  쿼리, 큰 데이터셋의 분석을 쉽게 만들어주는 도구를 제공한다.  Hive는 이 데이타 위의 스트럭처를 집어 넣는 매커니즘을 제공한다. 이 데이터에 쿼리 요청을 위해서 SQL과 친숙한 SQL의 기반의 Hive QL로 불리는 간단한 쿼리 언어를 제공한다. 동시에 이 언어는 내장 언어가 제공하지 않는 좀 더 정교한 분석을 하기 위해 전통적인 맵/리듀스 프로그래머가 커스텀 mapper와 reducer를 연결할 수 있게 해준다.

Installation and Configuration

Requirements

  • Java 1.6
  • Hadoop 0.17.x to 0.20.x.

Installing HIve a Stable Release

아파치 다운로드 미러에서 안정된 배포 버전을 다운 받는다.압축을 푼다.

$ tar -xzvf hive-x.y.z.tar.gz

HIVE_HOME환경변수를 설치한 디렉토리를 가리키도록 설정한다.

$ cd hive-x.y.z
$ export HIVE_HOME=`pwd`

마지막으로 $HIVE_HOME/bin 을 PATH에 추가한다

$ export PATH=$HIVE_HOME/bin:$PATH

Running Hive

하이브는 하둡을 사용한다는 것은

  • PATH에 하둡이 있어야 한다.
  • export HADOOP_HOME=<hadoop-install-dir>

추가로 /tmp 와 /user/hive/warehouse를 만들어야 한다. HDFS에서 chmod g+w 정해야 한다. 그래야 하이브가 테이블을 만들 수 있다.

$HADOOP_HOME/bin/hadoop fs -mkdir /tmp
$ $HADOOP_HOME/bin/hadoop fs -mkdir /user/hive/warehouse
$ $HADOOP_HOME/bin/hadoop fs -chmod g+w /tmp
$ $HADOOP_HOME/bin/hadoop fs -chmod g+w /user/hive/warehouse

하이브 커맨드 라인 인터페이스 사용한다

$ $HIVE_HOME/bin/hive

 

Configugration management Overview

하이브 default 설정은 <install-dir>/conf/hive-default.xml에 저장되어 있다.
설정 변수는 <install-dir>/conf/hive-site.xml 에서 정의된 것의 따라 변경될 수 있다.
하이브 설정 디렉토리의 위치는 HIVE_CONF_DIR 환경 변수 설정에 의해 변경될 수 있다.
Log4j 설정은 <install-dir>/conf/hive-log4j.properties에 저장되었다.
하이브 설정은 하둡 위에 덮어 쓴다. - 즉 하둡 설정 변수를 초기값으로 상속 받는다.
하이브 설정은 다음에 의해 조작된다.

  • hive-site.xml을 편집하기나 알맞는 변수(하둡 변수 포함)를 정의한다.
  • cli에서 set 커맨드를 사용한다.
  • 다음 syntax를 사용하여 하이브를 실행한다
    - $ bhin/hive -hiveconf x1=y1 -hiveconf x2=y2
    - HIVE_OPTS 환경변수를 위와 같이 “-hiveconf x1=y1 -hiveconf x2=y2” 로 지정한다

Runtime Configuration

  • Hive 퀄리는 map-reduce 쿼리들을 이용해서 실행된다. 따라서 그런 쿼리들은 하둡 설정 변수에 의해 control 된다.
  • cli 커맨드 ‘SET’ 은 하둡 (또는 하이브) 설정 변수를 지정하는데 사용될 수 있다. 예를 들면
hive> SET mapred.job.tracker=myhost.mycompany.com:50030;
hive> SET -v;

-v 는 현재의 모든 설정들을 보여준다. -v 옵션이 없다면 오직 기본 하둡 설정과 다른 변수만 표시된다

Hive, Map-Reduce and Local-Mode

Hive 컴파일러는 대부분의 쿼리들의 map-reduce job들을 생성한다. 이 job들은 다음 변수가 가리키는 Map-Reduce 클러스터에 제출된다.

mapred.job.tracker

보통 map-reduce 클러스터는 여러 개의 노드를 가리키지 않는 반면에, 하둡 또한 유저 워크스테이션 위에서 map-reduce job들을 로컬에서 실행하기 위한 멋진 옵션을 제공한다. 이 것은 작은 데이터 셋에 쿼리를 실행할 때 매우 유용할 수 있다. 이 경우에 로컬 모드 실행은 보통 대형 클러스터에 job을 제출하는 것 보다 상당히 빠르다. 데이터는 HDFS에서 투명하게 접근할 수 있다. 반대로 로컬 모드는 오직 하나의 reducer 만 실행하며 큰 데이터 셋 처리에서는 매우 느려진다.

0.7버전부터 하이브는 로컬 모드 실행을 완전히 지원한다. 이것을 가능하게 하기 위해 사용자는 다음 옵션을 지정해야 한다.

hive> SET mapred.job.tracker=local;

추가로, mapred.local.dir 로컬 머신 위에 유요한 경로를 가리켜야 합니다. (예를 들면 /tmp/<username>/mapred/local) (그러지 않으면, 사용자는 로컬 디스크 스페이스를 할당 받으라는 예외를 얻게 된다.)

0.7 버전부터, 하이브는 또한 자동적으로 로컬 모드에서 map-reduce job들을 실행하기 위한 모드를 제공한다. 관련된 옵션은 다음과 같습니다.

hive> SET hive.exec.mode.local.auto=false;

이 특징은 초기 값이 false임을 명심하자. 만약 ture라면, 하이브는  쿼리에서 각각 map-reduce job의 크기를 분석한다.
다음 thresholds가 만족된다면 로컬에서 실행이 될 수도 있다.

  • job의 총 입력 크기가 hive.exec.mode.local.auto.inputbytes.max  (초기값 128MB) 보다 작을 때
  • 총 map-task의 개수가 havie.exec.mode.local.auto.tasks.max( 초기값 4)
  • 총 필요한 reduce-task의 개수가 1 또는 0

따라서 작은 데이터 셋의 쿼리와 다음 job들의 입력이 실질적으로 더 작을 때 여러 개 map-reduce job들 위한 쿼리에서 job들은 로컬에서 실행될 수 있다.

하둡 서버 노드들의 runtime 환경과 하이브 클라이언트를 실행하는 머신의 차이점이 있을 수 있다는 것을 명심해라. (vm 버전이나 다른 소프트웨어 라이브러리 때문에) 이는 로컬 모드에서 실행 중 예기치 못한 행동이나 에러를 유발할 수 잇다. 또한 로컬 모든 실행은 child jvm(하이브 클라이언트의)으로 분리되어 실행된다. 사용자가 정말 원한다면, child jvm을 위한 최대 메모리 양을 hive.mapred.local.mem. 옵션을 통해서 조정할 수 있다. 초기값은 0 이다. 이 경우에 하이브는 하둡이 child jvm의 초기 메모리 한계를 정하도록 한다.

Error Logs

하이브는 로깅을 위해 log4j를 사용한다.  디폴트 로그들은 CLI에 의해 콘솔로 방출되지 않는다. 디폴트 로깅 레벨은 WARN 이다. 로그는 다음 폴더에 저장된다.

  • /tmp/{user.name}/hive.log

사용자가 원한다면 밑에 보여지는 arguments를 추가하여 콘솔로 방출하게 할 수 있다.

  • bin/hive -hiveconf hive.root.logger=INFO,console

사용자는 오직 다음을 이용해서 로깅 레벨을 변경할 수 있다.

  • bin/hive -hiveconf hive.root.logger=INFO,DRFA

set 커맨드를 이용해서 hive.root.logger를 정하는 것은 로깅의 property를 변경하지 않는다. property는 초기화 시간에 결정된다.

하둡 클러스터에서 하이브 실행 중 로깅은 하둡 설정에 의해 통제된다. 보통 하둡은 테스크가 실행되었을 때 클러스터 머신에 저장된 맵과 리듀스 테스크 당 하나의 로그파일을 생성한다, 로그 파일은 하둡의 JobTracker 웹 UI에서 Task Details 페이지를 클릭 해서 얻을 수 있다.

로컬 모드를 사용할 때, 하둡/하이브 실행 로그는 클라이언트 머신 자체에서 생성된다. 0.6 버전부터는 하이브는 디폴트로 로그가 어디에 전달될지를 결정하기 위해 hive-exec-log4j.properties 를 사용한다. 디폴트 설정은 로컬 모드에서 실행된 쿼리 당 하나의 로그 파일이 생성된다. 그리고 이것은 /tmp/{user.name} 밑에 저장된다. 설정파일을 분리하여 생성하는 의도는 관리자가 만약 바람직하다면 실행 로그 캡쳐를 집중화 할 수 있도록 하기 위함이다.  실행 로그는 runt-time 에러를 디버깅 하는 데는 가치가 없다.

Reference


Posted by 김민우 julingks