etc2011. 7. 6. 13:21

 미국 독립기념일 이벤트로 해외사이트에서 여러가지 상품을 세일판매하게 된다는 정보를 알게되었습니다.
회사 형님도움으로 해외결제 / 배송을 진행하게 되었습니다.
간단하게 정리차 안내해 드립니다.

제가 이용한 사이트는 ej 라는 해외배송업체. (http://www.endless-jackpot.co.kr)

(구매시, ej 사용하여 진행하는 방법은 pass. 자세한 내용은 '이용방법' 참고~)
- 배송대행 < 'NJ배송신청'


- 'NJ 배송신청'
: 배송신청하는 방법입니다. 중요한것은 보라색 네모칸은 '주문 email' 을 활용해서 작성하셔야 합니다.
(단가 부분이 구매사이트에서는 실제 할인된 금액등을 표시하지 못할수 있어서, 관세를 지불하는 경우가
생길수 있습니다. 관세에 대한 정보는 검색하시고. 개인상품은 15불.)


- 주문 email 에서 참고할 내용은 빨간색 네모칸 입니다.


- 구입처 URL 이나, 이미지 URL 등은 아래내용을 참고하세요.

(view large image 를 눌러서, 속성)

(이미지 URL 을 복사해서 넣습니다.)


- 그리고 같이 구매한 상품들이 있다면 '+입력창추가' 를 눌러서 추가 등록합니다.
: 혹시, 상품이 모두 도착하지 않았다면.. 트래킹 부분을 비워서 입력합니다.


- 그리고, 하단에 예상파운드 를 1 lbs 로 작게 선택하시고(어차피 변경됨), 미국센터요청사항 내용에
'상품이 모두 도착하면 예상 배송비 알려주세요~' 작성합니다.
(임시저장, 배송대행신청을 눌러서 등록완료합니다.)


- 신청내역 확인 (View)


- 상품이 모두 도착안해서 이후에 상품이 도착한 후 '트래킹 등록' 이 가능합니다.


- 등록이 완료되면, * 진행단계 및 메모 부분에 실제배송비용이 나오게 되고, 해당금액을 입금하면 완료!
(해당금액 입금 등. 좀더 상세한 내용은 다시 작성하겠습니다.)


 해외배송이 좀 귀찮고, 기간이 많이 걸리긴하지만.. 해보니 크게 어렵지도 않고. 실수만하지 않으면
할만할것 같습니다. ^ㅁ^

Posted by 깜장눈썹
etc2011. 6. 29. 10:09
- 맵리듀스는 데이터 처리를 위한 프로그래밍 모델이다.
- 기상 데이터셋 (설명 p.43~44)
- 처리 속도를 높이기 위하여, 프로그램의 각 부분을 병렬로 수행할 필요가 있다.
: 하나의 서버에서 이용할수 있는 모든 하드웨어 스레드별로 다른 프로세스를 실행시켜 다른 연도별 파일을 처리할 수 있다.
몇가지 문제점이 있는데,
  • 동일한 크기로 잡을 나눈다는것이 항상 쉽고 명백한 것만은 아니다.
    : 연도별 파일크기가 일반적으로 다양하기 때문에 몇몇 프로세스들은 다른 것들보다 훨씬 먼저 끝날것이다. 결국 전체 수행결과는 가장 긴 파일에 의해 좌우 될것이다.
    (하나의 대안은 입력 파일들을 고정크기의 데이터 청크 들로 나우고 프로세스별로 각 덩어리를 할당하는 방식)
  • 독립적인 프로세스로부터 결과를 조합하는데 더 많은 처리가 필요할 수 있다.
    : 연도별 결과는 다른 연도별 결과와는 무관하기때문에 모든 결과를 갖다 붙이고 연도별로 정렬함으로써 조합될수 있다. 고정크기의 데이터 청크 방식을 사용한다면 특정연도에 대한 데이터는 전형적으로 몇개의 데이터 청크들로 나누어질것이고, 각각 독립적으로 처리. 그리고 각데이터 청크 단위로 최고기온을 얻을것이며, 연도별 최고기온은 마지막 단계에서 찾게 될것이다.
  • 단일 서버의 처리능력은 여전히 한정되어 있다.
    : 처리할수 있는 최적의 수행시간의 제한, 단일 서버의 용량 등.

- 결과적으로 처리과정을 병렬화하는것이 그럴듯 해 보일지라도, 실제로는 엄청 복잡. 이러한 이슈들을 처리하기 위해 하둡과 같은 프로임워크를 사용하는것은 대단한 이득이다.

[ 하둡으로 데이터 분석하기 ]
- 맵과 리듀스
- 맵리듀스는 맵 단계와 리듀스 단계로 처리과정을 나누어 작업한다.
- 맵 단계에서 입력은(기상청) 원본데이터.
- 맵 함수는 분석 대상(인 연도와 기온)을 추출한다.
: 연도별로 최고기온을 찾아주는 리듀스 함수의 준비단계에 불과하다. 또한 잘못된 레코드를 제거하는 역할도 수행한다.
-  맵 함수 (설명 p.48)
: 키들은 파일 내에서 몇 번째 라인인지 나타내는 오프셋. 맵 함수에서는 무시된다.
맵 함수는 연도와 기온을 추출.
맵 함수의 출력은 리듀스 함수로 보내지기 전에 맵리듀스 프레임워크에서 처리한다.
프레임워크는 키를 중심으로 키/값 쌍들을 정렬하고 그룹을만든다.
따라서 리듀스 함수는 다음과 같은 입력을 받게 된다.
연도별로 그 해 측정한 모든 기온값이 리스트로 출력. 이제 모든 리듀스 함수는 리스트 전체를 순환하며 최고 측정값을 추출.


- 자바 맵리듀스 (설명 p.49)
- 예제 2-3 최고기온을 구하는 Mapper 예제
: 맵 함수는 map() 메소드를 선언하는 Mapper 인터페이스로 구현한다.
Mapper 인터페이스는 map 함수에 네 개의 정규 타입 매개변수들(입력키, 입력값, 출력키, 출력값)을 가지는 제네릭 타입.
입력키는 long integer 타입의 오프셋,
입력값은 한라인을 나타내는 내용,
출력키는 연도,
출력값은 기온(정수) 이다.

(하둡은 최적화된 네트워크 직렬화를 위해 자체적으로 기본 타입 셋을 제공한다.)

- 예제 2-4 최고기온을 구하는 Reducer 예제
: 리듀스 함수의 출력타입들은 지금까지 찾아진 가장 높은 기온과 입력된 각 기온을 반복해서 비교함으로써 구해진 각 연도와 해당 연도의 최고기온을 구한다.

- 예제 2-5 기상청 데이터셋으로부터 최고기온을 찾는 응용프로그램
: 맵리듀스 잡 
잡 명세서는 어떻게 잡을 수행 할지를 결정.
하둡 클러스터에서 잡을 실행할 때에는 소스 코드를 JAR 파일로 묶어야 한다(하둡은 클러스터에 JAR 파일을 배치할 것이다).
명시적으로 JAR 파일의 이름을 정하기 보다는 JobConf 생성자에 클래스 하나를 할당할 수 있으며, 하둡은 그 클래스를 포함하는 JAR 파일을 찾아서 클러스터에 배치할 수 있다.
addInputPath(): 입력경로
setOutputPath(): 출력파일 저장할 디렉터리 (해당 디렉터리는 잡을 수행하기 전에는 존재하지 않아야 함)

setMapperClass(): 맵 타입 설정
setReducerClass(): 리듀스 타입 설정
setOutputKeyClass(): 맵 함수 출력타입 지정
setOutputValueClass(): 리듀스 함수 출력타입 지정
JobClient.runJob(): 잡 실행
출력은 output 디렉터리로 쓰였고, 리듀스당 하나의 출력 파일을 생성.


- 새로운 자바 맵리듀스 API (하둡 릴리즈 0.20.0)

  • 새로운 API 에서는 인터페이스였던 Mapper 와 Reducer 가 이제는 추상 클래스로 바뀌었다.
  • 새로운 API 는 org.apache.hadoop.mapreduce 패키지(그리고 서브패키지) 안에 있다. 이전 API 는 org.apache.hadoop.mapred 에서 찾을수 있다.
  • 새로운 API 는 MapContext 는 기본적으로 JobConf, OutputCollecter, Reporter 의 역할을 통합
  • 새로운 API 는 'push', 와 'pull' 방식의 반복자를 모두 지원한다. 순차적 처리보다는 배치성 레코드를 처리할 때, 'pull' 방식이 더 유용하다.
  • 환경 설정 파일이 통합되었다. 잡 설정은 Configuration 을 통해 처리.
  • 새로운 API 에서 잡 제어는 더는 존재하지 않는 JobClient 보다 Job 클래스를 통해 수행된다.

: 맵 출력을 위해서는 part-m-nnnn, 리듀스 출력을 위해서는 part-r-nnnn 으로 생성
새로운 API 를 사용하기 위해 재작성된 MaxTemperature 응용프로그램. 차이점 ( p.57~58)

[ 분산형으로 확장하기 ]
: 단순화를 위해 로컬 파일시스템의 파일들을 사용. 확장을 위하여 데이터를 HDFS 에 저장해야 한다.
- 데이터 흐름
- 맵리듀스 잡: 클라이언트가 수행하려는 작업단위. 이것은 입력 데이터, 맵리듀스 프로그램, 설정 정보로 구성. 하둡은 잡을 맵 태스크와 리듀스 태스크로 나뉘어 실행
- 잡 실행
: 하나의 잡 트래커와 다수의 태스크 트래커. 두가지 유형의 노드가 존재.
- 잡 트래커: 태스크 트래커들이 수행할 태스크들을 스케쥴링함으로써 시스템 전체에서 모든 잡들이 수행되도록 조절.
- 태스크 트래커: 태스크들을 수행하고 각 잡의 전체 경과를 하나의 레코드로 유지하는 경과보고서를 잡 트래커에 보낸다. (실패시 다른 태스크 트래커에 다시 스케쥴 한다)
- 하둡은 맵리듀스 잡의 입력을 입력 스플릿이라는 고정크기 조각들로 나눈다. 하둡은 각 스플릿마다 하나의 맵 태스크를 생성하고, 그 스플릿에 있는 각 레코드를 사용자 정의맵 함수로 정의한다.
(전체입력을 통째로 처리하는 시간보다, 많은 스플릿을 통하여 분할된 조각을 처리하는 시간이 더 짧게 걸린다. 스플릿 크기가 작을 수록 부하분산에 더 좋은 효과가 난다. 같은 성능의 서버에서도 프로세스들이 실패하거나 여러잡이 동시에 실행되기 때문에 부하 분산은 바람직하다. 부하 분산 효과는 스플릿들이 세분화 될수록 커진다. 분할크기를 너무 작게하면, 분할 관리와 맵 태스크 생성을 위한 오버헤드가 전체 잡 실행시간을 압도하기 시작한다. 기본적으로 64MB 의 HDFS 블록을 사용하는 추세. 하둡은 HDFS 내의 입력 데이터가 있는 노드에서 맵 태스크를 실행할 때에 가장 잘 작동. 최적의 스플릿 크기가 HDFS 블록크기와 같아야 하는 이유는, 그 블록 크기가 단일 노드에 저장된다고 확신할 수 있는 가장 큰 입력 크기이기 때문.)
- 맵 태스크의 결과는 HDFS 가 아닌 로컬 디스크에 저장된다. 이유는 맵의 결과는 리듀스가 최종결과를 생성하기 위해 사용하는 중간결과물, 잡이 완료되면 맵의 결과는 버려도 되기 때문이다.
- 단일 리듀스 태스크의 맵리듀스 데이터 흐름 (p. 60)
: 리듀스 태스크의 개수는 입력크기에 따라 결정되지 않고 독립적으로 지정. (p.268 잡에 대한 리듀스 태스크의 개수를 어떻게 선택하는지)
- 다중 리듀스 태스크의 맵리듀스 데이터 흐름 (p.61)
: 리듀스가 여럿일 때, 맵 태스크는 각 리듀스 태스크만큼 파티션을 생성하고 맵의 결과를 그 파티션으로 분배시킨다. (파티셔닝 알고리즘은 일반적으로 해시 함수를 이용해 버켓에 분배해주는 기본적인 파티셔너를 사용하지만 사용자 정의 파티셔닝 함수도 사용할 수 있다.)
맵과 리듀스 태스크들의 사이의 데이터흐름을 비공식적으로 '셔플' 이라하는지 이유를 보여준다. 튜닝을 통해서 잡 실행 시간에 상당한 영향을 줄수 있다. (p.251 '셔플과 정렬')
- 리듀스 태스크 없는 맵리듀스 데이터 흐름 (p.62)
: 처리 과정을 완전히 병렬로 수행할 수 있기 때문에 셔플이 필요 없는 경우에 적합. 이 경우 유일한 외부 노드 간 데이터 전송은 맵 태스크가 HDFS 에 결과를 저장할 때다.

- 컴바이너 함수
: 맵의 결과를 입력으로 처리(컴바이너 함수의 출력이 결국 리듀스 함수의 입력이 된다.)
많은 맵리듀스 잡들은 클러스터 내에서 이용할 수 있는 대역폭이 제한적이기 때문에 맵과 리듀스 태스크 간 데이터 전송을 최소화 할 필요가 있다. 컴바이너 함수가 최적화에 관련되어 있기 때문에 하둡은 특정 맵의 결과 레코드에 컴바이너를 얼마나 호출해야 할지에 대한 기능을 제공하지 않는다.
- 컴바이너 함수규약은 사용할 수 있는 함수형을 제한한다.
첫번째 맵의 결과
(1950, 0)
(1950, 20)
(1950, 10)
두번째 맵의 결과
(1950, 25)
(1950, 15)
하나의 리스트에 담아 리듀스 함수로 전달
(1950, [0, 20, 10, 25, 15])
리듀스 결과
(1950, 25)
각맵의 출력에서 최고기온을 찾기 위해 컴바이너 함수를 마치 리듀스 함수처럼 사용할 수 있다.
(각 맵에 대한 컴바이너의 결과값을 리스트에 담아 다음과 같이 리듀스로 전달)
(1950, [20, 25])
단순하게, 맵-컴바이너-리듀스 함수는 다음과 같은 값으로 호출
max(0, 20, 10, 25, 15) = max(max(0, 20, 10), max(25, 15)) = max(20, 25) = 25
- 컴바이너 함수가 리듀스 함수를 대체할 수 있는 것은 아니다.
: 맵과 리듀스 사이에서 셔플할 데이터의 양을 줄이는 데에 도움된다.
- 컴바이너 함수를 작성하기 (p.64)
: 컴바이너 함수는 Reducer 인터페이스를 사용하여 정의된다.
응용프로그램을 위해 MaxTemperatureReducer 에 있는 리듀서 함수와 같은 소스코드를 사용.


[ 하둡 스트리밍 ]
: 사용자 프로그램 사이의 인터페이스로 유닉스 표준 스트림을 사용한다. 표준입력으로 부터 읽고 표준출력으로 쓸 수 있는 어떠한 언어라도 맵리듀스 프로그래밍용으로 사용가능
스트리밍은 라인단위로 데이터를 처리. 맵의 출력 키/값 쌍은 하나의 탭으로 구분된 라인으로 쓰인다. 이듀스 함수의 입력도 표준입력으로 전달된 탭으로 구분된 키/값 쌍과 같은 포멧.
- 루비 (맵 함수, 리듀스 함수- 작성 설명 p.66)
- hadoop 명령으로 실행하기
: hadoop 명령어는 스트리밍 옵션을 지원하지 않는다. 스트리밍 프로그램의 옵션들은 입출력 경로, 맵과 리듀스 스크립트를 지정한다. 큰 데이터셋을 클러스터에서 실행할 때, -combiner 옵션을 사용하여 컴바이너를 설정해야한다. 버젼 0.21.0 부터, ㅋ머바이너는 어떠한 스트리밍 명령어로도 작성될 수 있다. 이전 버전에서는 컴바이너는 자바로 작성되어야 했고, 자바에 얽매이지 않는 차선책으로 매퍼에서 컴바이닝을 수작업으로 하는것이 일반적. 클러스터에서 스트리밍 프로그램을 실행할 때(?) 클러스터로 스크립트들을 전송하기 위하여 -file 옵션을 사용하는 점을 주목하라.
- 파이썬
: 스트리밍은 표준입력으로부터 읽고, 표준출력으로 쓸 수 있는 어떠한 프로그래밍 언어라도 지원이 가능.
- 하둡 파이프 (예제 p.70~71)
: 하둡 맵리듀스를 위한 C++ 인터페이스의 이름이다. 맵과 리듀스 코드사이의 통신을 위해 표준 입출력을 사용하는 스트리밍과 다르게, 파이프는 태스크 트래커가 C++ 맵 또는 리듀스 함수를 실행하는 프로세스와 직접 통산히기 위하여 소켓을 통신 채널로 사용한다. 맵과 리듀스 함수들은 HadoopPipes 네임스페이스에 속하고 각각 map(), reduce() 메소드의 인터페이스를 제공하는 Mapper 와 Reducer 클래스를 상속함으로써 정의된다. C++ 인터페이스에서의 키와 값들은 STL(Standard Template Library) 로 표현되는 바이트 버퍼다. 파이프는 HDFS 가 실행되고 있어야만 작동하는 하둡의 분산 캐시 메커니즘에 의존하기 때문에 독립 실행형(로컬) 모드로는 실행되지 않는다.
- 컴파일 및 실행 (p.72~73)

Posted by 깜장눈썹
etc2011. 6. 27. 13:41
  • SQL(관계형 데이터베이스)과 NoSQL을 비교하시나요?
    : 클라우드, 분산환경, 기존 RDB 의 제약사항 및 대용량 데이터처리
  • NoSQL 등장배경
    출발점은, 페이스북과 트위터.
    쇼셜미디어가 활성화 되고 하루에도 수천만건의 무수히 많은 데이터가 읽기 및 쓰기가 된다는 점.
    주목할것은 쓰기(update)가 많고, 데이터간의 관계성은 적은 데이터 구조의 특성상 기존 RDB 로는 미흡하다는 것이다.
    그래서 페이스북/트위터(카산드라), 구글(빅테이블), 아마존(다이나모)등의 분산 데이터 스토어가 각광받고 있습니다.
  • NoSQL은 기존 RDB 와는 달리 경량화 DB, 검색과 인덱싱이 빠른 파일시스템 기반 DB
    또한 수평적으로 확장이 용이하다는 장점이 있다고 합니다.
  • NoSQL CAP 이론
    - Consistency: 각각의 사용자가 항상 동일한 데이터를 조회한다.
    - Availabilty: 모든 사용자가 항상 읽고 쓸수 있다.
    - Partition tolerance: 물리적 네트워크 분산환경에서 시스템이 잘 동작한다.
    SNS 의 특성상 Consistency(일관성)과 Availability(가용성)을 어느정도 포기하고 분산환경에서
    보다 빠르게 저장하고 검색하는 특징을 반영하는게 결국 NoSQL 의 사용목적이 된다.

참조: http://cafe.naver.com/hermeneus.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=32&


  • 구글의 BigTable paper에 보면 구글의 BigTable이 대체 무엇인지에 대해 간단하고 명료하게 기술하고 있다.
  • A Bigtable is a sparse, distributed, persistent multidimensional sorted map.

    이 간단한 문장에 noSQL기반 기술의 거의 모든 기본이 들어있다고 보면 된다. 자 이제 하나 하나 파들어가볼까?

    Map이다

    이게 정말 핵심중의 핵심이다. 이것만 이해해도 상당히 많은 기본개념을 이해한거라 나는 생각한다. 바쁘면 이제 이 글의 나머지를 안 읽어도 된다(^^). 거의 모든 noSQL은 Map이다. 즉, 유일한 키와 그것에 관련된 하나의 값을 가진 자료형이 noSQL이 데이타를 저장하는 기본적인 방식이다. JSON방식으로 예를 들면 다음과 같은 형태로 noSQL은 자료를 저장한다.

    {
     "zzzzz" : "woot",
     "xyz" : "hello",
     "aaaab" : "world",
     "1" : "x",
     "aaaaa" : "y"
    }

    영구적이다 (Persistence)
    noSQL은 기본적으로 데이타베이스의 역할을 수행한다. 당연히 데이타는 어느 정도 이상은 영구적이어야한다. 다만 메모리기반의 noSQL의 경우 이 영구적인 특성이 조금 떨어진다고 볼수도 있겠다.

    분산기반이다 (Distribute)

    noSQL이 나온 배경중의 하나는 기존의 RDB가 데이터 확장에 따른 확장성에 제약이 심했기 때문이다. 따라서 대부분의 noSQL은 데이터 저장 및 복제에 대해 설계 초기부터 분산시스템을 기반에 두게 되었다. 구글의 BigTable의 경우 Google File System(GFS)을 기반으로 하고, HBase를 비롯한 많은 noSQL은 하둡(Hadoop)의 분산 파일 시스템(HDFS)을 사용한다.
    데이타 복제와 분산처리를 어떻게 하는지 자체에 대한 것은 사실 noSQL 기본 개념과는 큰 상관이 없는 주제이므로, 그리고 나도 사실 그쪽에는 내공이 딸리므로 넘어가자.

    정렬기능이 있다 (Sorted)

    모든 noSQL이 이 기능을 가지고 있다는 게 아니라 HBase, BigTable같은 일부가 가지고 있는 기능이다. 키와 값이 알파벳순으로 정렬이 되는 기능을 가진다. 실로 어마어마한 데이타를 처리하기 위한 용도로 만들어진게 noSQL이다보니 이런 정렬기능은, 혹은 이런 정렬기능의 성능은 너무나도 중요한 요소이다.

    다차원적이다 (Multidimentional)

    noSQL의 개념이 기존 데이타베이스에 익숙한 사람들에게 전달되기 위해 많은 noSQL기술들이 기존의 개념을 많이 차용한다. 테이블이나 칼럼 혹은 Row같은 RDB의 개념이 그대로 noSQL에서도 쓰이는 경우가 있고 이로 인해 noSQL의 이해를 어렵게 하는 경우가 있다. 새술은 새푸대에 담았으면 싶다. 그래서 다차원적인 Map을 지원하는게 noSQL의 특징이라고 강조하고 싶다. 다차원적이라는 말이 어렵다면 Map의 Map을 지원한다라고 할까? 즉,
    {
     "1" : {
     "A" : "x",
     "B" : "z"  },
     "aaaaa" : {
      "A" : "y",
      "B" : "w" 
    }
    ,
     "aaaab" : {
      "A" : "world",
      "B" : "ocean" 
    },
     "xyz" : {
       "A" : "hello",
      "B" : "there" 
    },
     "zzzzz" : {
       "A" : "woot",
       "B" : "1337" 
    }
    }

참조: http://calmglow.egloos.com/4580668

Posted by 깜장눈썹