* Source : http://www.readwriteweb.com/enterprise/2011/08/gartner-adds-big-data-gamifica.php

2011 가트너  "하이프 싸이클"에 작년에는 없던  키워드인 Big Data, Gamification, internet of Things, Consumerization 가 추가 됐다.

가트너의 하이프 싸이클은 시장의 기술 수용 단계(가로)와 관심도(세로)의 그래프라고 할 수 있다.

시장의 기술 관심도는 점점 높아져 Peak of Inflated Expections 지점에 가게 된다.
하지만  기대에 대한 거품이 빠지면 Trough of Disillusionment 단계로 넘어간다.  언론과 시장의 관심이 줄어드는 이 단계에 접어 들었다고 기술이 한 물 갔다고 생각하면 안된다. 그 중에 가능성 있는 기술은 다시 재조명 받게 되고 이전에 이 기술에 투자한 회사들은 매출이 증가하게 된다.
하지만 실상 기술의 관심이 절정일 때에는 관심도의 비해서 도입 비율과 매출은 미비하다. 사람들은 기술이 모든걸 해결 해줄 거라는 기대를 하지만 거품이 껴있다. ( 그래서 사람들은 새로운 기술에 반드시 실망한다. 그렇다고 모두 내팽개치면 안된다.)

올해는 어떠한가 Private Cloud 가 관심의 정점에 있다.  Cloud/Web Platfroms은 환멸의 골(Trough of Disillusionment)을 향하고 있다.

엔지니어라면 하이프 싸이클은 앞으로 어떤 기술이 시장의 관심을 많이 받을 것인가를 보는데 집중하는 것이 좋다.
경험상 한국은 미국에 비해서 경우에 따라 1,2년 정도의 격차가 있지만, 그 간격도 점점 좁혀지고 있다.

이번에 4가지에 키워드가 추가되었는데 그 중에 "빅 데이터"에 주목 하자. 기사에서는 빅데이터가 빠르게 성숙할 것 이라고 예상한다.
빠르게 이동하고 있지만 매우 적은 실망을 보여주고 있다는 것이 고무적이라고 할 수 있다.
지금의 속도라면 1~2년 후에 시장의 큰 관심을 받게 될 것이다.
이미 올해부터 빅데이터에 대한 기사와 시장 조사 기관의 보고서들 나오고 있다.

엔지니어의 기술 포트폴리오는 금융 포트폴리오와 비슷한 면이 많다. (from 실용주의 프로그래머)
경험상 3,4년전 한창 웹 2.0 열풍이 불었을 때 별다른 관심을 받지 않던 클라우드 컴퓨팅과 하둡에  대한 주제를 선점한 사람들은 지금 전문가가 되어 가치가 상승했다.  나의 기술 포트폴리오에 어떤 종목을 추가할 것인가?  누군가 묻는다면 "빅 데이터"를 눈여겨 보라고 하고 싶다.

Reference

Posted by 김민우 julingks

댓글을 달아 주세요

Coc(Convention over Configuration)는 간단한 개념이다.
시스템들과 라이브러리, 프레임워크는 별도의 설정 시스템 없이 '바로 실행' 될 수 있어야 한다는 요구샇아이 없더라도, 기본적으로 이러한 사항이 당연하다고 가정한다.
CoC의 실증으로, EJB3 영속성(Persistence)이 있다.
개별적인 영속성있는 빈을 만들기 위해서는 클래스에 @Entity라고 어노테이션을 명기하는 것이 전부이다. 프레임웍에서는 테이블 명을 클래스 명, 컬럼을 프로퍼티 명으로 가정할 것이다. 필요한 경우 제공된 이름들을 재정의 할 수 있도록 제공하는데, 대부분 불필요하다.
급하게 진행되는 프로젝트의 경우 프레임워크에서 제공하는 기본적인 정의들을 활용하는 게 낫다.

메이븐은 프로젝트에 관한 상식적인 기본 정의들을 CoC를 바탕으로 구체화 한다.
소스코드는 ${basedir}/src/main/java
리소스는 ${basedir}/src/main/resources
테스트 코드는 ${basedir}/src/test
컴파일 하면 ${basedir}/target/classes 에 바이트 코드가 생성되고
배포할 수 있는 JAR 파일은 ${basedir}/target에 생성될 것이라고 가정한다.

이런 가정이 하찮게 보일지도 모르겠지만, 대부분의 앤트 기반 빌드에서는 각 서브 프로젝트에서 이러한 디렉토리의 위치를 각기 정의한다.
메이븐은 단지 디렉토리 위치를 간단한게 하려는 것보다 소스 코드의 컴파일, 배포를 위한 패키징, 웹 사이트의 생성과 많은 다른 프로세스들을 위한 일반적인 관례들을 메이븐의 핵심 플러그인들에 적용하기 위해 CoC를 채용하였다. 이런 관례는 사용자가 선택할 수 있지만 관례를 따른다면 메이븐이 알아서 해주기 때문에 해야할 일들이 없다.
이것은 또한 사용자가 특수한 관례에 구속되어 있다고 느낄수 있다. 하지만 대부분은 사용자가 직접 정의 할 수 있다. 메이븐은 요구사항들에 적합하게 기본적인 것들을 사용자가 정의할 수 있도록 허용한다.

현대적인 프레임웍에서는 CoC적인 접근 방벙을 사용하고 있다.

  • Ruby on Rails
  • Zend Framework
  • Grails
  • Spring
  • Castle MonoRail
  • Junit
  • JBoss Seam
  • CakePHP
  • symfony
  • kohana

전통적으로, 프레임워크는 여러 다중 설정 파일들을 필요로 한다. 설정 파일은 많은 설정을 포함한다.
애플리케이션의 복잡도에 따라 이러한 설정 파일들읠 수와 크기는 매우 쉽게 늘어난다. 이에 따라 설정의 방법도 복잡해지며, 개발자가 일일이 이러한 설정을 해야 하기 때문에 개발의 속도는 감소되고, 개발의 복잡도는 증가한다. 따라서 개발자는 애플리케이션에서 관습적이지 않은 면 (unconventional aspects of the application)만 정의할 필요가 있다는 개념이다.

Reference

  • Maven sonatype이 만든 Maven 핵심가이드 / 팀 오브라이언 지음, 장선진 옮김/ 지앤선
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

댓글을 달아 주세요

CentOs는 서버용으로 쓰이기 때문에 기본 Repository의 대부분의 패키지들이 버전이 낮다.
높은 버전을 사용하기 위해서는 rpm으로 직접 설치를 해야 해서 불편하다.
yum repository에 CentOS-Test Repository를 추가해서 최신 버전의 패키지들을 쉽게 설치하자.
(물론 안정성이 떨어질 수 있다는 것에 유의)

# cd /etc/yum.repos.d
# wget http://dev.centos.org/centos/5/CentOS-Testing.repo

설치를  할 때는 --enablerepo 옵션을 이용한다

# yum install php --enablerepo=c5-test

Reference

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

댓글을 달아 주세요

추상 클래스인 Generic Hibernate Doa를 상속받아 DAO를 구현하면 시간이 절약된다.

public abstract class GenericDaoHibernate <E,PK extends Serializable> extends HibernateDaoSupport implements GenericDao<E,PK>{
	
	@Autowired
	public void init(SessionFactory sessionFactory){
		this.setSessionFactory(sessionFactory);
	}
	
	@SuppressWarnings("unchecked")
	protected Class<E> getEntityClass(){
		Class<E> persistentClass = (Class<E>)((ParameterizedType)getClass().getGenericSuperclass()).getActualTypeArguments()[0];
		  return persistentClass;
	}
	
	protected DetachedCriteria createDetachedCriteria(){
		return DetachedCriteria.forClass(getEntityClass()); 
	}
	
	@SuppressWarnings("unchecked")
	public PK save(E newInstance) {
		return (PK)getHibernateTemplate().save(newInstance);
	}

	public void update(E transientObject) {
		getHibernateTemplate().update(transientObject);
	}

	public void saveOrUpdate(E transientObject) {
		getHibernateTemplate().saveOrUpdate(transientObject);
	}

	public void delete(E persistentObject) {
		getHibernateTemplate().delete(persistentObject);
	}
	
	public void deleteById(PK id){
		getHibernateTemplate().delete(findById(id));
	}
	
    public void deleteByProperty(String entityName, Object entity) {
        getHibernateTemplate().delete(entityName,entity);
    }

	public E findById(PK id) {
		return (E)getHibernateTemplate().get(getEntityClass(), id);
	}
	
	@SuppressWarnings("unchecked")
	public List<E> findByExample(E object) {
        List<E> resultList = getHibernateTemplate().findByExample(object, 0, 1);
        return resultList;
	}
	@SuppressWarnings("unchecked")
	public List<E> findByExample(E object, int firstResult, int maxResults) {
        List<E> resultList = getHibernateTemplate().findByExample(object,firstResult, maxResults);
        return resultList;
	}

	@SuppressWarnings("unchecked")
	public List<E> findAll() {
		return getHibernateTemplate().findByCriteria(createDetachedCriteria());
	}

	@SuppressWarnings("unchecked")
	public List<E> findAllByProperty(String propertyName, Object value) {
		DetachedCriteria criteria = createDetachedCriteria();
		criteria.add(Restrictions.eq(propertyName, value));
		return getHibernateTemplate().findByCriteria(criteria);
	}
	
}

인터페이스

public interface GenericDao <E,PK extends Serializable> {
	PK save(E newInstance);
	void update(E transientObject);
	void saveOrUpdate(E transientObject);
	void delete(E persistentObject);
	void deleteById(PK id);
    void deleteByProperty(String entityName, Object entity);
	E findById(PK id);
	List<E> findByExample(E object);
	List<E> findByExample(E object, int firstResult, int maxResults);
	List<E> findAll();
	List<E> findAllByProperty(String propertyName, Object value);
}

실제 DAO는 GenericHibernateDao를 상속 받아서 Entity 클래스와 Primary Key의 타입을 넘겨주면 된다.

@Repository
public class UserDaoHibernate extends GenericDaoHibernate<User,Long>{
	
	
}

필요한 커스텀 메서드는 DAO 마다 구현하면 된다.

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

댓글을 달아 주세요

  1. 신현우 2012.07.12 09:09  댓글주소  수정/삭제  댓글쓰기

    잘 보았습니다. 많은 도움이 됐어요! 감사합니다 ~

RPMforge는 CentOS를 위해 wine, vlc, mplayer, xmms-mp3 등 유명한 미디어 도구를 포함해서 5000 이상의 패키지를 제공한다.

rpmforge-release 패키지를 다운 받는다. 다음 밑에 두 링크 중에 자신의 아키텍처와 맞는 것을 선택한다. 아키텍처를 모른다면 uname -i 명령으로 자신의 아키텍처를 확인한다.

DAG’s GPG 키를 설치한다

rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt

다운로드 받은 패키지를 검증한다

rpm -K rpmforge-release-0.5.2-2.el5.rf.*.rpm

패키지를 설치한다.

rpm -i rpmforge-release-0.5.2-2.el5.rf.*.rpm

이제 yum repository config 파일이 추가되고 적절한 GPG 키들이 import 된다

Reference

Posted by 김민우 julingks

댓글을 달아 주세요

BI 플랫폼 제품 조사 하다가 ETL에서 Talend 의 Data integration 도구들의 Feature 리스트들 뽑아봤다.

Talend’Prodcuts

Data Integration

  • Talend Open Studio
  • Talend Integration Suite

Data Quality

  • Talend Open Profiler
  • Talend Data Quality

Master Data Management

  • Talend MDM CE
  • Talend MDM EE

Lifecycle Platform

Talend Express

  • Talend Integration Express

SOA Framework

  • Talend ASF

ESB (Enterprice Service Bus)

  • Talend ESB
  • Talend Service Factory
  • Talend Integration Factory

What is Data Integration ?

데이터 통합은 소스 시스템과 목적 시스템 사이의 데이터를 변환 이동하기
위해서 사용되는 도구와 처리과정을 가리킨다.

이 들 소스와 목적 시스템은 다양한 데이터베이스, 패키지 된 애플리케이션
(CRM, ERP 또는 accounting 소프트웨어), SaaS 애플리케이션, 파일, legacy
시스템, 웹 서비스 등을 포함한다.

조직은 중요한 데이터의 관리를 합리화하고 프로세스를 최적화하기 위해서
데이터 통합을 사용한다. 전체 사업에서 정보의 유동성을 보장하고 비용 최적화하고 운영 효율 증가
시킨다.

Talend 오픈 소스 데이터 통합 솔루션은 전형적으로 BI, 데이터 migration,
이터 synchronization 를 위한 ETL에 사용된다.

이 솔루션들은 통일된 데이터 관리 플랫폼 안에서 완전히 통합 된다.

Data Integration Features

  • Business Modeler
  • Job Designer
  • Components
  • ETL support
  • ELT support
  • Versioning
  • Shared Repository
  • Data Viewer
  • Wizards
  • Dynamic Schema
  • Impart Analysis
  • Data Lineage
  • Job compare
  • Joblets
  • Reference Projects
  • Change Data capture
  • Context Management
  • Distant Run
  • Talend Administration Center
  • Job Conductor
  • Command Line
  • Time Scheduler
  • Event Scheduler
  • Execution Plan
  • SOA Manager / Webservices
  • Load Balancing
  • High Availability
  • Failover
  • FileScale
  • Hadoop
  • AMC
  • Dashboard

     

    Feature Description
    Business Modeler

    데이터 통합 처리를 지원하는 모든 관련된 문서와 기술적 요소를 다이어그램으로 구조화 한다.

    Job Designer

    Job Designer는 그래픽 팔레트의 Component와 Connector 를 사용해서 통합 처리의 그래픽적이고 기능적인 화면 모두 제공한다. 모든 타입의 소스와 목적 시스템의 컴포넌트 라이브러리를 제공한다.
    Connector는 데이터 소스와 목적 시스템의 read/write 와 access를 도와준다. 각각 컴포넌트를 선택하면 파라메터를 설정할 수 있다. 복잡한 컴포넌트는 dedicated 한 그래픽 인터페이스가 장착되어 있다.
    Job을 만드는 것을 도와주는 built-in Wizard가 있다.
    Job design의 가독성을 위해서 Job Diagram 은 Subjob으로 나눠진다.
    콘솔 화면을 통해서 빠르게 실행을 모니터 할 수 있다.

    Components

    모든 IT 환경에 접근하는 Connector를 제공한다. 550가지 사용 가능한 connector와 component들이 있다.

    ETL support

    ETL (Extract, Transform & Load) 관련된 다양한 컴포넌트 제공

    ELT support

    ELT (Extract, Load & Transform) 지원

    Versioning

    비지니스 모델, Job, Routine, Metadata, Documentation 등이 버전관리 된다.

    Shared Repository

    (or Metadata Manager) 모든 프로젝트 정보와 기업 메타데이터를 중앙 repository에서 공유된다. Talend Administration Center에서 사용자의 role과 permission 등이 관리 된다.
    자동 locking 시스템은 동시에 같은 job이 다른 사용자에 의해서 변경되지 않도록 한다.
    Subversion을 이용하여 branch, check-in/ check-out, aotomatic commit, comments 등을 지원한다.

    Data Viewer

    Talend는 다양한 소스와 목적 시스템(files, DB 등) 의 내용을 볼 수 있도록 도와주는 Data Viewer를 제공한다. ( txt, csv 파일, SQL 쿼리, XLS, html 등..)

    Wizards  

    Dynamic Schema

    다이나믹 스키마는 컬럼의 구조나 숫자를 모르는 job을 설계할 수 있도록 한다. 개발자의 선택에 따라서, 다이나믹 컬럼은 Pass-trhogh 모드를 이용하여 직접 target에 연결될 수 있다.

    replication 시나리오에서 단순히 많은 컬럼이 1:1 맵핑 될 수 있다. 이 feature는 이런 종류의 job 설계를 쉽게 만든다.

    Impact Analysis

     

    Data Lineage

    메타 데이타 메니저를 통해서 사용 가능하다. 메타데이터(DB, files.. )의 컬럼에 수행된다. data lineage의 결과는 소스 컴포넌트부터 목표 컴포넌트까지의 변화를 추적하는 리포트를 보여준다.

    리포트는 HTML 파일로 export 될 수 있다.

    Job compare

    두 가지 버전의 job 또는 다른 job들의 차이점을 식별 할 수 있도록 도와준다.

    Job Compare의 결과는 시각적이고 interactive 한 리포트를 작성한다. 다른 부분이 하이라이트된 html 또는 xml 로 export 된다.

    Joblets

    Job 또는 Subjob을 부분으로 분해하여 Joblet 컴포넌트로 만든다. Joblet 컴포넌트는 정해진 joblet 폴더를 통해서 공유가 가능 하다.

    Reference Projects

    프로젝트 사이에서 아이템 (Jobs, Routines, Documentation, Metadata 등) 중복을 피하도록 도와 준다.

    Slave 프로젝트들은 하나의 Master 프로젝트에 참조에 의해서 연결된다. 자식 프로젝트는 부모 프로젝트로 부터 아이템들을 상속받는다. 하지만 read-only 모드 이기 때문에 재사용은 가능하지만 수정은 불가능 하다.

    Change Data capture

    Data Warehousing은 분석을 위해 하나 이상의 DB로 부터 하나 이상의 목표 시스템으로 데이터를 추출, 전송을 포함한다. 데이터가 큰 경우 많은 시간과 자원을 소비하게 된다.

    실시간으로 변화된 데이터를 capture하는 능력을 Change Data Capture(CDC)라고 부른다. CDC는 ETL 시간을 줄인다. Talend의 CDC 아키텍처는 publisher/subscriber 모델이다.

    실시간으로 데이터 변화를 감지해서 Subscriber job에게 즉시 변화된 데이터를 전송 함으로서 ETL과 데이터 통합 중에 데이터를 로드 하거나 업데이트할 때 필요한 시간을 줄인다.

    Business Rules

    비지니스 룰은 일반적으로 기술 staff에 의해 구현되거나 번역되기 보다 명세 문서를 통해서 비지니스 사용자에 의해서 정의된다.

    Talend Integration Suite는 사용자의 비지니스 룰을 설정을 도와주는 비지니스 룰 엔진을 탑재했다. 사용자는 시장 분할 기준과 비지니스 룰을 엑실 또는 웹-베이스 Talend Administration Center를 통해서 설정할 수 있다.

    Context Management

    Context는 컴포넌트와 job들의 파라메터를 밖으로 꺼낼 수 있게 한다. 이것은 테스팅과 프로덕션을 위해서 다른 세팅을 사용할 경우 파라메터 정의로 부터 벗어날 수 있게 해준다. 사용자는 언제든지 Context를 전환 할 수 있다.

    Distant Run

    이 기능은 다른 서버에 job의 원격 실행을 가능하게 한다.
    다음 경우에 유용하다
    -생산 환경과 비슷한 설정에서
    -다양한 운영체제 위에서
    -특정 시스템에 요청해야 될 때

    Talend Administration Center

    Web-Based 과리 화면을 제공한다.
    프로젝트, 사용자 권한, 라이센스, 사용자 관리하는 통합 프로젝트 매니저에게 도움을 준다.
    사용자별 프로젝트 권한이 부여된다. (LADP 지원) 사용자은 정해진 역할에 의해서 프로젝트에 접근할 수 있다. (No permission, Read Only, Read & Write ..)
    사용자는 아이템(Jobs, Business Models, DB connection metadata ..) 들을 다른 사용자에게 공유할 수 있다.

    Job Conductor

    Job conductor는 데이터 통합 job들의 실행을 조정한다.

    이것은 중앙 집중된 실행 인터페이스를 제공한다. 모든 job들은 요청 또는 시간 기반 스케쥴이나 이벤트 기반 스케쥴에 의해서 시작 될 수 있다.

    Job Conductor 모듈은 JobServer와 실행될 job들이 있는 서버에 설치되는 작은 애플리케이션인 Agent에 의존 한다.

    Agent가 설치되면, Job Conductor 는 실시간으로 하드웨어 자원 ( CPU, RAM, HD ..) 을 감시할 수 있게 한다.

    JMX 지원 40개 이상의 모니터를 가능하게 한다. 어떤 Job이든 한 번의 클릭으로 다른 서버에 Deploy 할 수 있다.

    Command Line

    커맨드 라인 모듈을 제공한다.

    Talend Studio와 Administration Center 통해 제공하는 거의 모든 Job 관리 기능이 커멘드 라인으로 사용 가능하다

    Time Scheduler

    정해진 시간, 날짜에 job을 실행하거나, 정해진 주기로 job을 실행 시킨다.

    Task는 job 실행을 위해서 필요한 모든 정보(프로젝트 이름, job 이름, 버전, 서버 등)를 모으는 데 사용 된다. Task는 스케쥴에 의해 실행된다. job은 정해진 시간 정해진 서버위에서 자동적으로 배치 & 실행 된다. 편리한 상태 시스템은 상태와 실행의 성공 실패를 모니터를 하는데 도움을 준다.

    Event Scheduler

    이벤트 리스너는 특정 이벤트 발생시 job 실행을 유발한다.
    이벤트는 파일 기반과 SQL 기반이 있다

    Execution Plan

    Execution Plan은 다양한 Job 실행을 지휘(orchestrate)하거나 연결하는 것을 도와준다. 또 에러 복구도 쉽게 한다.

    Execution Plan은 Task-based feature 이다. 다른 task들의 실행 순서를 지위하는 종속관계의 윤곽을 그린다. Task 종속성은 계층 구조를 통해서 정의 된다.

    SOA Manager / Webservices

    SOA Manager는 하나 이상의 데이터 통합 job을 Web Services 로 노출 하기 위해서 Web-based 환경을 제공한다. 자동적으로 SOAP 바인딩을 사용하는 시스템과 이종 애플리케이션 사이에서 자동 deployment를 가능하게 한다.

    WSDL Wizard는 WSDL descriptor를 만들고 UDDI 엔트리에 노출시킨다.

    Load Balancing

    Grid Conductor 모듈이 실행 grid의 최적 사용을 보장 함으로서 통합 과정에 scalability 와 availability 를 최적화한다.

    High Availability

    고 가용성

    Failover

    장애극복

    FileScale

     

    Hadoop

    하둡관련 지원
    ETL과 SQL template을 포함하는 HDFS와 HIVE read/write 관련 컴포넌트들을 지원한다.

    AMC

    Talend Activity Monitoring Console은 그래픽 인터페이스의 중앙 집중형 supervisioning 도구이다.
    수집된 로그 정보를 취합하기 위해서 사용된다.
    Job event (성공, 실패, 경고 등) 에 대한 감시를 한다.

    Dashboard

    AMC 을 웹 브라우저를 통해서 쉽게 접근할 수 있는 Web-based 버전을 제공한다.
    상태를 가리키는 performance 다이어그램을 제공하고 , 어느 stakeholder든지 현재와 과거 상태 모두를 볼 수 있다.
    시간 주기에 task 실행 정보를 제공한다.
    예기치 못한 실패를 방지하고, 시스템 관리 결정을 지원한다.

    Error Recovery

    Job 실행은 백업과 recovery 때문에 많은 시간이 소비된다.
    채크 포인트를 설정해서, 실패가 날 경우에 프로세스는 채크 포인트에서 다시 시작할 수 있다. 개발자는 특정 에러 조건을 지정하여 반응하는 특정 에러 관리를 설계 통합 할 수 있다.

     

    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

    댓글을 달아 주세요

    견습과정 패턴

    잔을 비우다

    • 첫 번째 언어 Your First Language: 당신은 몇몇 언어에 익숙하지만, 그 어느 것에도 능통하지는 않다.
    • 흰 띠를 매라 The White Belt : 당신이 가진 경험이 새로운 기술의 습득을 더 어렵게 하는 것 같아서 학습에 애를 먹고 있다.
    • 열정을 드러내라 Unleash Your Enthusiasm : 당신은 팀에 맞추기 위해서 소프트웨어 개발에 대한 흥분과 호기심을 숨기고 지내게 되었다.
    • 구체적인 기술 Concrete Skills : 뛰어난 개발 팀에서 일하고 싶지만, 당신에게는 아주 적은 실무 경험밖에 없다.
    • 무지를 드러내라 Expose Your Ignorance : 당신의 지식에 큰 틈이 있음을 발견했고, 당신이 하고 있는 일에 대해서 잘 모른다고 사람들이 생각할까봐 두렵다.
    • 무지에 맞서라 Confront Your Ignorance : 당신의 지식에 큰 틈이 있음을 발견했고, 당신이 하는 일은 이런 주제에 대한 이해를 요구하고 있다.
    • 깊은 쪽 The Deep End: 당신은 자신의 경력이 안정 상태에 접어든 것이 아니라 실은 틀에 박힌 듯 정체된 것이 아닌가 두려워지기 시작한다
    • 한발 물러서라 Retreat into Competence : 너무나 광대한 자신의 무지에 직면하면서 당신은 압도됨을 느낀다.

    긴 여정을 걷다

    • 긴 여정 The Long Road : 당신에게는 소프트웨어의 명장이 되고자 하는 포부가 있다. 비록 사람들이 당신에게 기대하는 것은 그게 아닌 것 같지만.
    • 예술보다 기예 Craft over Art : 고객에 해결책을 주기로 했는데, 단순하고 검증된 해법을 선택할 수도 있고 뭔가 새롭고 환상적인 것을 마들 기회로 삼을 수도 있다.
    • 지속적인 동기 부여 Sustainable Motivations: 당신은 계속 바뀌고 상충되는 요구사항을 가져오는 고객을 위해 아리송하게 명세된 프로젝트라는 좌절스러운 현실에서 일하고 있음을 깨닫는다.
    • 열정을 키워라 nurture Your Passion : 당신은 기예에 대한 열정을 질식시키는 환경에서 일하고 있다.
    • 자신만의 지도를 그려라  Draw Your Own Map: 고용주가 제시하는 어떤 경력 경로도 당신에게 맞지 않는 것 같다.
    • 직위를 지표로 이용하라Use Your Title: 공식적인 자리에서 자신을 소개할 때면 왠지 사과를 하거나 당신의 실제 기술 수준과 직무 내용간의 격차에 대해 변명을 해야 할 것 같은 생각이 든다.
    • 전장에 머물러라 Stay in the Trenches: 승진 제안을 받았지만, 그 자리로 가면 프로그래밍과는 멀어지게 된다.
    • 또 다른 길 A different Road : 당신이 가려는 방향은 소프트웨어 장인정신으로 향하는 기로가 다르다는 것을 알게 되었다.

    정확한 자기 평가

    • 가장 뛰떨어진 이가 되라 Be the Worst : 주변의 모든 이들을 일찌감치 앞서버리면서 당신의 학습은 더디어졌다.
    • 멘토를 찾아라 Find Mentors : 당신은 이미 있는 것을 다시 만들고 장애물에 부딪히느라 많은 시간을 소비하고 있지만, 어디쯤에서 안내를 받기 위해 방향을 틀어야 할지 확신하지 못한다.
    • 마음에 맞는 사람들 Kindred Spirits : 당신은 멘토도 없이 궁지에 빠져 있으며 당신의 포부와는 어울리지 않는 분위기 속에 놓여 있음을 알게 되었다.
    • 팔꿈치를 맞대고 Rubbing Elbows: 뭔지 알 수는 없지만 더 상급의 테크닉과 접근 방식이 있을 것이란 느낌을 갖고 있다.
      바닥을 쓸어라 Sweep the Floor : 당신은 미숙한 개발자이며 팀으로부터 신뢰를 얻고자 한다.

    끊임 없는 학습

    • 능력의 폭을 넓혀라 Expand Your Bandwidth: 소프트웨어 개발에 대한 당신의 이해는 좁으며 일상 작업에 관련된 저수준의 세부 사항에 맞춰져 있다.
    • 연습, 연습, 또 연습, Practice, Practice, Practice : 당신의 일상적인 프로그래밍 작업은 실패하면서 배울 수 있는 여지를 제공해 주지 않는다.
    • 부숴도 괜찮은 장난감 Breakable Toys : 실패가 허용되지 않는 환경에서 일하지만, 당신에게는 여전히 안전하게 학습할 데가 필요하다.
    • 소스를 활용해라 Use the Source: 주변에 좋은 코드와 나쁜 코드를 구별할 만한 사람이 없다면, 당신이 짜 놓은 것이 좋은지 어떤지 어떻게 알 수 있을까?
    • 일하면서 성찰하라 Reflect as You Work : 지금의 지위에서 보낸 햇수와 수행 한 프로젝트 개수가 늘어가면서, 당신은 마치 마법처럼 ‘경험이 쌓이게’ 만들어 줄 계시의 순간을 기다리고 있음을 깨닫는다.
    • 배운 것을 기록하라 Record What You Learn : 당신은 같은 교훈을 계속 되풀이 해서 배우지만, 도무지 몸에 붙지를 않는 것 같다.
    • 배운 것을 공유하라 Share What You Learn : 주변 사람들이 당신처럼 빠르게 학습하지 못하는 것 같아서 좌절하고 있다.
    • 피드백 루프를 만들어라 Create Feedback Loops: 당신은 자신이 ‘인식하지 못한 무능력’으로 고통 받고 있는지 알 수가 없다.
    • 실패하는 법을 배워라 Learn How You Fail : 당신의 학습 역량은 성공적인 부분을 향상시켰지만, 실패와 약점은 그대로 남아 있다.

    학습 과정의 구성

    • 독서목록 Reading List : 읽어야 할 책의 권수가 당신의 책 읽는 속도보다도 더 빠르게 늘어만 간다
    • 꾸준히 읽어라 Read Constantly : 신속하게 숙련도를 끌어올렸지만, 당신에게 보이지 않는 심오하고 더욱 근본적인 개념들이 어디선가 끝없이 흘러가고 있는 것 같다
    • 고전을 공부하라 Study the Classics : 당신과 함께 일하는 경험 많은 사람들은, 당신이 이미 읽었을 것이라고 여기는 책에 나오는 개념들을 계속 언급한다.
    • 더 깊이 파고들어라 Dig Deeper : 당신은 많은 도구와 기술이나 기법에 대해 피상적인 지식밖에 가지지 못했고, 좀 더 어려운 문제들과 씨름하면서 계속 장애물에 부딪히고 있다.
    • 익숙한 도구들 Familiar Tools : 당신이 사용하는 도구와 기술들이 너무 급속히 바뀌어서, 작업을 추산하는 데 어려움을 느낀다.

     

    Reference

    • 프로그래머의 길, 멘토에게 묻다, 데이브 후버, 에디웨일 오시나이 지음, 강중빈 옮김, 인사이트
    Posted by 김민우 julingks

    댓글을 달아 주세요

    1. www.vim.org/scripts 에서 스크립트 파일을 다운 받는다. (예, csv.vim)
    2. /path-to-vim/syntax 또는 ~/.vim/ 디렉토리에 파일을 복사 한다. (예, /usr/share/vim/syntax)
    3. 파일 타입을 인식할 수 있도록 vimrc 파일을 적절히 수정한다.
    augroup filetypedetect
       au! BufRead,BufNewFile *.csv,*.dat setfiletype csv
    augroup END
    Posted by 김민우 julingks
    TAG syntax, vim

    댓글을 달아 주세요

    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

    댓글을 달아 주세요