« 2025/07 »
일	월	화	수	목	금	토
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

How to replace list elements

from 카테고리 없음 2012. 1. 7. 03:26

>>> b = [1, 2, 3, 5, 6, 8 , 5 , 2 , 5]
>>> sub = { 5: 17 }
>>> [sub.get(x, x) for x in b]
[1, 2, 3, 17, 6, 8, 17, 2, 17]

http://python.kr/viewtopic.php?p=77248

,

MapReduce: 대형 클러스터에서 단순화된 데이터 프로세싱 [Jeffrey Dean and Sanjay Ghemawat, Google]

from 카테고리 없음 2012. 1. 5. 00:18

원본 http://research.google.com/archive/mapreduce.html

초록

MapReduce은 큰 데이터 셋을 처리하고 만들기 위한 프로그래밍 모델과 시행방법이다. Map과 reduce, 두 개의 사용자 정의 함수로 이루어진 이 모델에서, map 함수는 일련의 중간과정인 키/값 짝 집합을 만들기 위한 키/값 짝을 처리하고, reduce 함수는 동일한 중간과정 키와 연결된 모든 중간과정 값들을 합한다. 이들의 실제 적용예는 논문에 소개되어 있다.

이러한 함수 중심 스타일로 쓰인 프로그램들은 자동으로 병렬화되고 대형 클러스터에서 실행된다. 런타임 시스템이 세부사항-입력 테이터를 나누고, 프로세서들의 집합을 가로지르는 프로그램의 실행을 스케쥴링하고 기계의 오류를 해결하고, 각 프로세서간의 필요한 소통을 감독-들을 처리하므로, MapReduce모델은 병렬 분산 시스템에 경험이 없는 프로그래머들도 쉽게 대형 분산 시스템의 자원을 사용하도록 한다.

MapReduce은 거대 클러스터상에서 구현되었고, 확장이 용이하다(highly scalable): 전형적인 MapReduce 계산은 수 많은 테라바이트의 데이터를 수천여대의 프로세스로된 클러스터에서 처리하는 것이다. 프로그래머는 이 시스템을 쉽게 이용할수 있슴을 발견할것이다: 구글 클러스터에서는 현재 수 백개의 MapReduce 프로그램들이 구현되었고 천 여개 이상의 MapReduce 실행이되고 있다.

색인정보:
OSDI'04: Sixth Symposium on Operating System Design and Implementation,
San Francisco, CA, December, 2004.

http://www.joinc.co.kr/modules/moniwiki//wiki.php/JCvs/Search/Document/ManReduce

http://code.google.com/edu/parallel/mapreduce-tutorial.html

추가정보

비디오 강좌

http://code.google.com/edu/submissions/mapreduce-minilecture/listing.html

출처:http://www.radiumsoftware.com/0608.html, 구글 번역기로 초벌 번역하고 정리

분명히 MapReduce는 재미있다. 이 정도까지 간단한 프로그래밍 모델이 그 거대한 클러스터를 구동한다는 말인데 재미 없을 수 없지. 단지, 그 재미에 눈을 빼앗겨 버리면, 그것이 분산 처리의 수많은 솔루션 중 하나에 불과하다는 사실도 잊지 버릴 수도있다. Joel Spolsky가 MapReduce 운운에서 Java 비판을 전개했다고해도, 그것을 걱정할 필요는 없다[ LtU ].

개요

MapReduce는 Google 사의 Jeffrey Dean에 의해 개발된 분산 처리를위한 프로그래밍 모델이다. 동명의 C + + 라이브러리로 2003 년 초부터 운용이 시작되고 논문이 집필된 2004 년 말 시점에서이 라이브러리를 사용하는 프로그램들이 900여개 정도 존재한다고 적혀있다. 그 대표적인 응용 예로는 Google News와 Froogle의 클러스터 분석, Google Zeitgeist [ Google ]의 쿼리 통계 등을들 수있다. 물론 가장 중요한 응용 예제는 회사 최대의 서비스인 웹 검색을위한 인덱스 생성 프로세스이다 틀림없다. 그때까지 전용 분산 처리에 의해 충당되었다 인덱스 생성의 공정은 현재는 MapReduce를 사용 것으로서 전면적으로 고쳐 쓸 수있다.

"MapReduce"라는 명칭은 대규모 데이터 처리를 "map 작업"과 "reduce 작업"의 2 단계로 구성하는 것에 유래한다. 그야말로 함수형 언어 팬들을 설레게하는 네이밍이다 LtU , 실제로는 "필터"와 "수집기"의 2 단계로 구성된다고하는 것이 알기 쉬울지도 모른다. 실제로 [ Pike ] 등 등은 그런 설명을하고있다.

Image from Pike et al.

map 작업은 엄청난 양의 원본 데이터를 분해하여 필요한 정보를 추출하여 유용한 형태로 변환하여 출력하는 이른바 '필터'역할을한다. reduce 작업은 추출된 정보를 집약하여 한 덩어리의 데이터로 출력하는 이른바 "수집기"의 역할을한다. 이 중 map 작업이 순수하게 필터로 행동 (부작용이없는)이면이 작업을 여러 시스템에서 분산하여 수행할 수있다. 비록 처리할 데이터가 테라 바이트 단위로 존재했다고해도 그 처리를 수백 대의 컴퓨터로 효율적 분배 수했다면, 리얼타임으로 처리하는 것이 가능하게 될 것이다 .

동작

MapReduce 동작을 설명하려면 논문의 시작 부분에 나열된 단어 개수 예제를 사용하는 것이 알기 쉽고 좋다. 여기에서는 방대한 문서 - 예를 들어 "웹상의 텍스트 모두"등 단어의 출현 빈도를 확인하고자한다.

먼저 그 방대한 문서를 수십 대에서 수백 대의 작업자 (worker)에서 움직이는 map 작업으로 분배한다. map 작업 전달된 문서를 단어 단위로 분할하고 그 단어마다 "<word,1>"라는 <키, 값> 쌍을 발행한다. 이 대 작업자의 로컬 저장소에 존재하는 중간 파일 (intermediate file)로 축적된다.

이 map 작업의 의사 코드는 다음과 같은 것이된다 ( Dean ]에서 인용).

map (String key, String value) :   / / key : 문서 이름   / / value : 문서의 내용   for each word w in value :     EmitIntermediate (w "1");

map 작업을 완료했다면 다음은 여러 작업자상에서 reduce 작업이 시작된다. reduce 작업은 작업자를 순회하고있는 키에 관련지을 수 있었던 값을 열거 집계한다. 단어 개수의 예로 말하면 키 (단어)마다 연결된 카운트 값 (내용은 모두 "1")를 열거하고 그 총계를 취해서 집계를 실행하면된다.

이 reduce 작업의 의사 코드는 다음과 같은 것이된다 ( Dean ]에서 인용).

reduce (String key, Iterator values) :   / / key : 단어   / / values : 카운트 값 목록   int result = 0;   for each v in values :     result + = ParseInt (v);   Emit (AsString (result));

이제 각 단어에 대해 출현 빈도가 도출된된다.

각 작업은 입출력으로 <키, 값> 쌍을 사용한다. 이것에 주목하면 데이터의 흐름을 간결하게 파악할 수있다.

map : <문서 이름, 문서 내용> ⇒ <낱말, "1"> <낱말, "1"> ... 
reduce : <단어, "1", "1"...]> ⇒ <단어 카운트 값>

map 작업은 입력자료를 중간 정보로 분해하고 reduce 작업은 그 중간 정보를 통합한다. 단지 그것 뿐이라고 생각하면 매우 제한적인 프로그래밍 모델처럼 느껴질지도 모른다. 그러나 이러한 프로그래밍 모델에서도 다양한 처리를 실현하는 것이 가능한지 Dean들은 제시하고있다. 예를 들면, 웹 페이지의 소위 "역방향 링크"목록을 생성하려면 다음과 같은 MapReduce를 적용하면된다.

map : <URL, 페이지 내용> ⇒ <링크, URL> <링크, URL> ...] 
reduce : <링크, URL, URL, ...]> ⇒ <링크 반대 링크 목록>

그러나 물론, 모든 처리가 단일 MapReduce을 적용해서 끝나지되는 것은 아니고 여러 MapReduce를 결합하여 작업을 달성하는 경우도 보인다. 예를 들어 웹 검색 인덱스 생성 프로세스에서는 MapReduce의 반복이 5 회에서 10 회 정도 실행한다고 한다.

효율

MapReduce에 보이는 큰 특징의 하나로서 그 확장성 높이들 수있다. 다음 그래프는 Sawzall 언어[구글에서 만든 자료 처리용 언어] 짜여진 간단한 로그 분석 작업을 다른 구성에서 실행하고 그 결과를 나타낸 것이다.

Image from Dean et al.

실선은 처리 완료 요한 시간을 나타내고 점선은 핸들링에 소요되는 총 시스템 시간 (총 처리 시간)을 나타내고있다. 이상적인 확장성 하에서 실선은 반비례 곡선을 그려, 점선은 수평선을 그리는 것이다. 실제로는 점선이 다소 한쪽으로 치우친되어 (컴퓨터가 많을수록 불필요한 처리 시간이 는다)하지만, 그 증가는 30 % 정도에 그친다. 컴퓨터 수를 50 대에서 600 대 - 즉 12 배로 늘리고 있음에도 불구하고, 시스템 시간의 증가가 이 정도로 억제되어있다는 사실은 충분한 확장성이 거기있다는 것을 실증한다.

덧붙여서, 논문이 집필된 시점에서 단일(순차) 처리에 할당된 시스템의 평균은 157 대이며, 1 개월에 소비되는 총 시스템 시간은 약 8 만 일 있었다고 기록되어있다.

특수성

MapReduce 구성 작업 중 map 작업을 병렬 실행 것은 자명하게 보인다. 한편 reduce 작업 분들은 개별 작업이 차환 (commutative) 내지 결합 법칙을 만족 (associative) 그렇다면 계층으로 병렬 실행이 가능하지만, MapReduce에서는 그 모두 가정으로 설치되고 없다. reduce를 병렬 실행하려면 단순히 출력 파일의 수를 늘려 버리는 (집계 작업을 분할한다)하거나 combiner라는 특수기구 (map 작업자에서 부분적인 집계를하는 것)를 사용해야 한다. 이러한 점을 보면은 분명히 map 작업하는 것이 병렬 실행에 특화되어 있으며, reduce 작업 병렬성이 낮음이 눈에 띄는 것이다.

이러한 map과 reduce 사이에 보이는 비대칭은 아마 Google의 취급 문제 영역의 특수성으로 인한 것일 것이다라고 생각된다. 의 단어 출현 빈도 예제 등에서는 출력을 하나로 통합해야했지만, 많은 클러스터 분석에서는 출력을 하나로 집약 필요 피할 수 것인가 아닌가 생각된다. 또한 출현 빈도의 예로 봐도 정확한 답을 요구하는 것이 아니라 대략적인 솔루션을 허용하는 경우 특수한 방법을 이용하여 통합 처리의 경량 화를 도모할 수있다 [Charikar ].

Dean의 논문 참고 문헌에 들어있는 것처럼, 결합 법칙을 만족 작업을 병렬 실행하는 일반적인 방법은 과거에도 많이 존재했다. 게다가 Dean이 한 것은 실제 대규모 클러스터에서 운용 가능한 형태로 세련된 것, 강력한 복원력을 제공하게되었음을, 그리고 병렬 처리 기술의 개념이 없는 기술자 도 쉽게 이해할 수있는 간단한 프로그래밍 모델을 제시한 것, 등이 지적된다. 그러나 그들의 개혁은 Google의 취급 특수한 문제 영역에서 처음 가능해진 것으로, 다른 영역으로 확장이 가능하다고는 할 수 없다는 것을 명심해야한다.

,

The Trouble with Multicore-칩제조사들은 대부분의 프로그래머가 감당할 수 없는 마이크로 프로세서를 만드느냐 바쁘다

from 카테고리 없음 2012. 1. 4. 03:45

http://spectrum.ieee.org/computing/software/the-trouble-with-multicore/0

,

Horizontal scale vs. vertical scale

from 카테고리 없음 2011. 12. 20. 05:39

회사에서 근 미래의 계획으로 힘을 모으는 것이 Cloud computing 이고, 실제로 시제품이 출시될 예정이라 이래저래 신경쓰인다.

http://www.planethpc.eu/index.php?option=com_content&view=article&id=60:cloud-computinh-hpc2&catid=1:articles&Itemid=3

링크의 글은 수직적 스케일과 수평적 스케일에 대한 글로, 요약한다면:

HPC와 Cloud computing은 다른 컨셉이고, HPC는 해당 문제에 모든 리소스를 집중하는 수직적 스케일이다. Cloud computing은 그에 비해 분산해서 작업하는 수평적인 스케일이다. 두 가지 개념이 섞여가는 게 요즘의 트렌드.

Cloud computing에서 가장 우려되는 것은 보안이다. 자동차 회사의 경우 해당 서버를 이용하는 트래픽만으로도 경쟁사에게 디자인 사이클등이 읽힐 수 있다.

CAE에서 Cloud computing이 경쟁력을 갖는 예는 다양하겠구. 다양한 제품군을 가지고 있다면 롱테일에서 여러가지 다양한 서비스를 제공하는 것에 승부를 건다는 전략일 것이다. 필요한 순간 그때그때 해석, 설계 툴을 사용한다면, 최소 1년이산 비싼 유지비용을 들여가며 툴을 갖는 것보다는 효과적일테니까.