이 작업을 위해 MapReduce 또는 다른 유형의 병렬화를 배우고 사용해야합니까?

Question

Google의 친구와 이야기 한 후 내 데이터 집합을 업데이트하기 위해 일종의 Job/Worker 모델을 구현하고 싶습니다.

이 데이터 세트는 타사 서비스의 데이터를 반영하므로 업데이트를 수행하려면 해당 API에 대해 여러 번의 원격 호출이 필요합니다. 이 제 3 자 서비스의 응답을 기다리는 데 많은 시간을 할애 할 것입니다. 필자는 개인의 반응을 기다리면서 이러한 요청을 병렬 처리하고 동시에 많은 사람들을 열어 놓아서 업무 시간을 단축하고 계산 시간을보다 효율적으로 활용하고자합니다.

내 특정 데이터 집합을 설명하고 문제에 들어가기 전에, 내가 무엇을 찾고 있어요 답변 명확히하고 싶습니다 :

1. 이 맵리 듀스와 병렬화에 적합 할 것 흐름인가?
2. 예 인 경우 아마존의 mapreduce 모듈 (시간당 청구서가 발행되며 작업이 완료되면 1 시간 전)에서 실행하는 것이 비용 효율적일까요? (정확하게 "직업"으로 간주되는 것이 확실하지 않으므로 정확하게 청구 할 방법을 모르겠습니다.)
3. 아니요 인 경우 사용해야하는 다른 시스템/패턴이 있습니까? 및 파이썬에서이 작업을 수행하는 데 도움이되는 라이브러리가 있습니까 (AWS, EC2 + EBS 사용)?
4. 이 작업 흐름을 설계 한 방식에 문제가 있습니까?

지금 세부 위에 좋아

:

데이터 집합은 다른 사용자에 따라 좋아하는 항목이있는 사용자로 구성되어 있습니다. 목표는 각 사용자의 대기열을 업데이트 할 수 있도록하는 것입니다. 사용자 대기열은 내가 팔로우하는 사용자가 볼 수있는 항목 목록으로, 관심 사용자의 즐겨 찾기 항목을 기반으로합니다. 그러나 데이터를 정리하고 사용자 대기열을 업데이트하기 전에 API 호출 전화가 오는 최신 데이터가 있는지 확인해야합니다.

내가 할 수있는 두 가지 호출이 있습니다 - 모든 사용자가 요청 된 사용자에 의해 미행 당하고 반환하고,

은 즐겨 찾기 항목 받기 -

• 는 사용자을 이어 받기 요청 된 사용자의 모든 즐겨 찾기 항목을 반환합니다.

내가 GET는 사용자가 업데이트되는 위해 사용자에게을 따라 전화 후, 나는 따르고 각 사용자의 즐겨 찾기 항목을 업데이트해야합니다. 관심있는 모든 사용자에 대해 즐겨 찾기가 모두 반환 된 경우에만 해당 원래 사용자의 큐 처리를 시작할 수 있습니다. 프로세스 개막을 사용자가 업데이트되고 다음에 사용자를 가져 오는으로 -

• 시작을 사용자에 대한 대기열 업데이트 :

  

  채용이 흐름에

  은 다음과 같습니다 :이 흐름은 같다 저장 한 다음 만들기 각 사용자에 대한 즐겨 찾기 작업 가져 오기.
• 즐겨 찾기 가져 오기 사용자 - 타사 서비스에서 지정된 사용자의 즐겨 찾기 목록을 요청하고 저장합니다.
• 사용자에 대해 새 대기열 계산 - 이제 모든 데이터가 반입되었으므로 새 대기열을 처리 한 다음 응용 프로그램 계층에서 사용하는 캐시에 결과를 저장합니다.

그래서 다시, 내 질문은 :

1. 이 맵리 듀스와 병렬화에 적합 할 것 흐름인가? UserX에 대한 프로세스를 시작하고 관련 데이터를 모두 가져와 UserX의 큐를 처리 한 후에 만 ​​처리 할 수 ​​있는지 여부는 알 수 없습니다.
2. 예 인 경우 아마존의 mapreduce 모듈 (시간당 청구서가 발행되며 작업이 완료되면 1 시간 전)에서 실행하는 것이 비용 효율적일까요? 모듈을 사용하면 공개 API 요청을 기다릴 수있는 "스레드"수에 제한이 있습니까?
3. 아니요 인 경우 사용해야하는 다른 시스템/패턴이 있습니까? 및 파이썬에서이 작업을 수행하는 데 도움이되는 라이브러리가 있습니까 (AWS에서는 EC2 + EBS를 사용합니까?)?
4. 이 작업 흐름을 설계 한 방식에 문제가 있습니까?

읽어 주셔서 감사합니다. JimR에 응답

편집 : 고체 회신

감사합니다. 원래의 질문을 쓴 이후의 독서에서 MapReduce 사용을 배제했습니다. 나는 이것을 어떻게 만들고 싶은지를 아직 결정하지 않았지만 MapReduce가 실제로 HTTP 요청을 병렬화하려고 할 때 컴퓨팅로드를 분산/병렬화하는 것이 더 좋다고 느끼기 시작했습니다.

가져온 데이터를 모두 가져 와서 결과로 끌어 내리는 부분 인 "감소"작업은 그다지 계산적이지 않습니다. 나는 사용자 당 2 ~ 2 번 실행되는 하나의 큰 SQL 쿼리가 될 것이라고 확신합니다.

그럼, 나는쪽으로 기울고 있어요 것은 : 파이썬 작성

• 비 맵리 듀스 작업/노동자 모델. 저의 저의 친구는 저비용이고 잘 저울 렀기 때문에 이것을 위해 파이썬을 배웠습니다.
• Amazon EC2를 컴퓨팅 계층으로 사용. 이것은 데이터베이스를 저장하기 위해 EBS 슬라이스가 필요하다는 것을 의미한다고 생각합니다.
• 아마도 Amazon의 Simple Message queue thingy를 사용합니다. 이 3 번째 아마존 위젯은 작업 대기열을 추적하고, 한 작업의 결과를 다른 작업의 입력으로 이동 시키며, 실패한 작업을 정상적으로 처리하도록 설계된 것 같습니다. 아주 싸구려. 사용자 정의 작업 큐 시스템 대신 구현할 가치가 있습니다.

Answer 1

우리는 Node.js과 Seq 흐름 제어 라이브러리를 사용할 것으로 보입니다. 프로세스의 내 맵/플로우 차트에서 코드 스텁으로 이동하는 것은 매우 쉬웠습니다. 이제 올바른 API에 연결하는 코드를 작성하는 것만으로도 충분합니다.

답 해 주셔서 감사합니다. 그 해결책은 내가 찾던 해결책을 찾는 데 많은 도움이되었습니다.

Answer 2

나는 해결해야 할 비슷한 문제로 일하고있다. MapReduce를보고 Amazon에서 Elastic MapReduce 서비스를 사용하고있었습니다.

저는 MapReduce가이 문제를 해결할 것이라고 확신합니다. 구현은 끊어지고 있습니다. 왜냐하면 감속기가 아무 것도 할 필요가 없다는 것을 확신 할 수 없기 때문입니다.

귀하의 (및 제) 문제점을 이해하고 귀하의 질문에 답변 해 드리며, 도움이되기를 바랍니다.

1. 예 잘 맞을 것 같습니다. Elastic MapReduce 서비스의 여러 단계 옵션을 활용할 수 있습니다. 1 단계를 사용하여 사용자가 팔로우하는 사람을 가져올 수 있으며, 또 다른 단계로 각 팔로어의 트랙 목록을 컴파일 할 수 있습니다. 두 번째 단계의 감속기는 아마도 캐시를 작성하는 사람이 될 것입니다.

2. 데이터 세트의 크기와 실행 빈도에 따라 다릅니다. 데이터 세트가 비용 효과적 일지 여부를 알지 못하면 말하기 어렵습니다. 처음에는, 당신은 자신의 hadoop 클러스터를 관리 할 필요가 없으므로 EC2 인스턴스 (당신이 사용하는 것으로 가정)를 항상 지불해야 할 필요가 없으므로 비용면에서 상당히 효과적 일 것입니다. 오랜 시간 동안이 데이터를 실제로 처리하고있는 지점에 도달하면 아마존의 MapReduce 서비스를 사용하는 것이 점점 더 어려워 질 것입니다. 왜냐하면 항상 모든 노드를 온라인 상태로 유지할 것이기 때문입니다.

기본적으로 작업은 MapReduce 작업입니다. 여러 단계로 구성 될 수 있습니다 (각 MapReduce 작업은 단계입니다). 데이터가 처리되고 모든 단계가 완료되면 작업이 완료됩니다. 따라서 Hadoop 클러스터의 각 노드에 대해 CPU 시간을 효과적으로 지불하고 있습니다. 그래서, T * n 여기서 T는 데이터를 처리하는 데 걸린 시간 (시간)이고, n은 아마존에 스핀 업하도록 말한 노드의 수입니다.

나는 이것이 행운을 도와주기를 바랍니다. 나는 당신이 Mappers와 Reducer를 구현하는 방법을 듣고 싶습니다. 매우 비슷한 문제를 해결하고 있으며, 내 접근법이 정말 최고인지 확신 할 수 없습니다.

Answer 3

설명하는 작업은 대기열 또는 대기열과 작업 서버의 조합에 적합 할 수 있습니다. 확실히 MapReduce 단계 세트로도 작동 할 수 있습니다.

작업 서버의 경우 Gearman을 살펴 보는 것이 좋습니다. 문서는 훌륭하지는 않지만 프레젠테이션은 문서화가 잘되어 있습니다. 파이썬 모듈도 상당히 자명합니다.

기본적으로 작업 서버에서 함수를 만들고 이러한 함수는 API를 통해 클라이언트에서 호출됩니다. 함수는 동 기적 또는 비동기 적으로 호출 할 수 있습니다. 예를 들어 비동기 적으로 "업데이트 시작"작업을 추가하려고합니다. 그러면 준비 작업을 수행 한 다음 비동기 적으로 "추적 사용자 불러 오기"작업을 호출합니다. 이 작업은 사용자를 불러오고 "사용자가 수행 한 업데이트"작업을 호출합니다. 그러면 모든 "Get Favorites for UserA"와 친구 작업을 한 번에 제출하고 모두의 결과를 동 기적으로 기다립니다. 모두 반환되면 "새 대기열 계산"작업이 호출됩니다.

이 작업 서버 전용 접근 방식은 처음에는 오류를 처리하고 다운 서버와 지속성이 올바르게 작동하도록 보장하기 때문에 약간 덜 강력합니다.

대기열의 경우 SQS가 확실한 선택입니다. 그것은 견고하고 EC2에서 접근하기가 매우 빠르고 저렴합니다. 또한 시작하기 직전에 다른 대기열보다 쉽게 ​​설정하고 유지 관리 할 수 ​​있습니다.

기본적으로 위와 같은 작업 서버에 작업을 제출하는 것처럼 메시지를 대기열에 넣습니다. 단, 동기식으로 수행하지 않는 경우는 많습니다."Get Favorites For UserA"등을 동 기적으로 호출하는 대신 비동기 적으로 호출 한 다음 모든 요청이 완료되었는지 확인하는 메시지를 표시합니다. 작업이 완료되었는지 여부를 추적하기 위해 일종의 지속성 (익숙한 SQL 데이터베이스 또는 AWS 전체로 이동하려는 경우 Amazon의 SimpleDB)이 필요합니다. SQS에서 작업 진행 상태를 확인할 수 없습니다 (다른 대기열에서도 가능). 모든 작업이 완료되었는지 확인하는 메시지는 확인 작업을 수행합니다. 작업이 모두 완료되지 않았 으면 아무 작업도 수행하지 않고 메시지가 몇 분 안에 재 시도됩니다 (visibility_timeout 기준). 그렇지 않으면 다음 메시지를 대기열에 넣을 수 있습니다.

작업을 수행하지 않고 실수로 대기열 메시지를 소비하지 않는다고 가정하면이 대기열 전용 접근법은 견고해야합니다. 그런 실수를하는 것은 SQS로하기가 어렵습니다. 실제로 시도해야합니다. 자동 소비 대기열 또는 프로토콜을 사용하지 마십시오. 오류가 발생하면 대체 메시지를 다시 대기열에 넣을 수 없습니다.

이 경우 대기열과 작업 서버의 조합이 유용 할 수 있습니다. 지속성 저장소가 없어 작업 진행 상황을 확인할 수 있으므로 작업 서버에서 작업 진행 상황을 추적 할 수 있습니다. "사용자를위한 즐겨 찾기 가져 오기"메시지는 "UserA/B/C에 대한 즐겨 찾기 가져 오기"작업을 모두 작업 서버에 배치 할 수 있습니다. 그런 다음 완료해야하는 작업 목록 (그리고 불가사의하게 사라지는 작업을 다시 시작할 수있는 충분한 정보)이 포함 된 큐에 "모든 즐겨 찾기 가져 오기 확인"메시지를 넣습니다. 보너스 포인트

하십시오 맵리 듀스로 이렇게

은 매우 쉽게해야합니다.

첫 번째 직업의 입력은 모든 사용자 목록입니다. 지도는 각 사용자를 가지고 각 사용자와 그 다음에 사용자에 대한 다음 사용자 및 출력 라인을 얻을 것이다 :

"UserX" "UserA" 
"UserX" "UserB" 
"UserX" "UserC" 

항등 단계는이 변화를 떠나 줄일 수 있습니다. 이것은 두 번째 작업의 입력을 형성합니다. 두 번째 작업에 대한 맵은 각 행에 대한 즐겨 찾기를 가져옵니다 (API를 통해 UserX/UserA 콤보 및 UserY/UserA에 대한 즐겨 찾기 가져 오기를 막기 위해 memcached를 사용하고 각 즐겨 찾기에 대한 줄을 출력 할 수 있습니다).

"UserX" "UserA" "Favourite1" 
"UserX" "UserA" "Favourite2" 
"UserX" "UserA" "Favourite3" 
"UserX" "UserB" "Favourite4" 

이 값으로 각 사용자에 대해 데이터베이스를 업데이트하기 위해 다른 맵리 듀스 작업을해야 할 수도 있습니다,이 시점에서

"UserX" [("UserA", "Favourite1"), ("UserA", "Favourite2"), ("UserA", "Favourite3"), ("UserB", "Favourite4")] 

또는 일부를 사용할 수 있습니다

는이 변환합니다이 작업 단계를 줄일 수 돼지, 하이브, HBase와 같은 Hadoop 관련 도구를 사용하여 데이터베이스를 관리 할 수 ​​있습니다.

Hadoop의 ec2 관리 명령에 Cloudera Distribution을 사용하여 Hadoop 클러스터를 만들고 EC2 (해당 AMI에 Python이 설정되어 있음)에서 분리하고 Dumbo (PyPI)를 사용하여 MapReduce를 만들 것을 권합니다. Hadoop에 액세스하지 않고도 로컬/dev 시스템에서 MapReduce 작업을 테스트 할 수 있으므로이 작업을 수행 할 수 있습니다.

행운을 빈다.