[HADOOP] EMR- 자동 조절이 필요합니까? EC2 만 사용해야합니까? Qubole을 사용해야할까요?

EMR- 자동 조절이 필요합니까? EC2 만 사용해야합니까? Qubole을 사용해야할까요?

프로비저닝 시간을 줄이기 위해 우리는 5 개의 인스턴스 (약 5 개가 필요할 것으로 예상 됨)가있는 전용 EMR 클러스터를 유지하기로 결정했습니다. 우리가 더 많이 필요로 할 때, 우리는 일종의 자동 크기 조정을 구현해야 할 필요가 있다고 생각합니다.

나는 EMR에 익숙하지 않다. 자동 스케일링을 지원 하는가? 나는 이것을 docs에서 찾았다 : http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-manage-resize.html

그게 자동 크기 조정을 찾는 올바른 장소인가, 아니면 "크기 조정"이 의미하는 바를 오해하고있는 것입니까? 나는 EMR의 한 가지 이점은 "주문형 처리"이며, 얼마나 많은 인스턴스를 지정하지 않고도 ec2 인스턴스 사이의로드를 분할한다고 생각합니다. 따라서이 인스턴스가 ec2 인스턴스를 자체적으로 확장한다는 인상을줍니다 우리가 자동 조절할 필요가 없다는 것을 의미합니다. "주문 처리 중"이 의미하는 바를 오해하고 있습니까?

내가 제공 한 크기 조정 링크가 내가하려는 일에 적합하다면, 누가 크기를 조정할지 결정하는 경험이 있습니까? 이 문서에서는 크기 조정시기를 알리는 방법과 같은 방법 만 설명합니다. 나는 그들의 정규적인 자동 스케일링 서비스를 사용했고 특정 조건에 따라 크기를 조정할 수는 있지만 여기서는이를 볼 수 없다.

EMR 자동 조절이 나쁜 생각인지 확신 할 수 없습니다. EMR이 이미 필요한 컴퓨팅 성능을 사용하고 있기 때문에 Qubole과 같은 회사 전체가이 문제를 다루고 있기 때문에 너무 복잡합니다. 나는 EMR이 실제로 무엇을 제공하는지에 관해 많이 모른다. 그래서 아마 혼란 스럽다.

해결법

1. ==============================

   1.링크 한 페이지는 수동 또는 프로그래밍 방식으로 클러스터의 노드를 늘리는 방법을 보여줍니다. EMR에 대한 자동 확장에 대해 다른 것을 찾지 못했습니다.

   링크 한 페이지는 수동 또는 프로그래밍 방식으로 클러스터의 노드를 늘리는 방법을 보여줍니다. EMR에 대한 자동 확장에 대해 다른 것을 찾지 못했습니다.

   사실을 놓치지 않는 한, 당신은 여전히 ​​자신의 스케일링 알고리즘과 프로세스를 고안해야합니다. 일자리 잔고, 비용을 지불하는 시간 단위, 덜 비싼 "스팟"인스턴스, 다중 클러스터 등을 고려하여 요인을 고려한다면, 이것은 아마도 사소한 운동이 아닙니다.

   클러스터 크기가 커지는 것 외에도 다운 사이징이 있습니다. EMR을 사용하면 작업 노드에 대해 (수동 또는 프로그래밍 방식으로)이 작업을 수행 할 수 있지만 핵심 노드에는이 작업을 수행하지 않는다고 명시합니다. AWS 기능을 통해 코어 노드를 종료하고 데이터를 잃을 위험이 있습니다. 시간이 지남에 따라 작업 부하가 증가하거나 감소하면 코어 노드 크기를 줄이는 것이 비용을 낮추는 데 유용합니다.

   Qubole은 이러한 모든 것을 자동으로 처리합니다. UI 또는 API에서 작업을 실행하면 클러스터가 시작, 크기 조정 또는 크기 조정됩니다. 작업이 끝나면 클러스터가 다운 사이징되거나 종료됩니다. 또한 한 번에 최소 개수의 노드를 계속 실행할 수 있습니다. 또한 Qubole 노드의 시작 시간이 EMR보다 훨씬 빠르다고 들었습니다.

   희망이 당신을 도와줍니다.

2. ==============================

   2.AWS는 현재 (2016 년 말 현재) EMR의 일부로 상자 밖으로 자동 확장을 지원하지 않습니다. 그러나 EMR API는 1) 모니터링 데이터를 수집하고 2) 프로그래밍 방식으로 클러스터를 위아래로 확장하는 데 필요한 모든 요소를 ​​제공합니다.

   AWS는 현재 (2016 년 말 현재) EMR의 일부로 상자 밖으로 자동 확장을 지원하지 않습니다. 그러나 EMR API는 1) 모니터링 데이터를 수집하고 2) 프로그래밍 방식으로 클러스터를 위아래로 확장하는 데 필요한 모든 요소를 ​​제공합니다.

   기본적으로 EMR 클러스터에 자동 확장을 구현하는 두 가지 주요 옵션이 있습니다.

   두 옵션 모두 장단점이 있습니다. 옵션 2의 장점은 서버가없는 방식 (자체 서버를 실행하지 않아도 됨)입니다. 단점은 CloudWatch 메트릭이 일괄 적으로 수집되므로 (일반적으로 5 분 간격) 데이터가 약간 지연되거나 덜 정확할 수 있다는 것입니다. 또한 이벤트 기반 접근 방식은 클러스터 확장의 현재 및 과거 상태를 검사하는 데 필요한 도구를 제공하지 않을 수도 있습니다. 반면에 옵션 1에는 서버가 필요하지만 확장 규칙의 논리를 사용자 정의하기 위해 더 많은 제어 기능이 제공됩니다. 또한 확장 성 결정 내역을 검색 가능한 기록으로 유지할 수 있습니다.

   Atlassian에서 개발 된 EMR 자동 확장 프레임 워크 인 Themis를 살펴볼 수 있습니다. 위의 옵션 1에서 설명한대로 자동 확장 루프가 구현됩니다. 현재 기능에는 자동 UI뿐만 아니라 자동 UI가 포함되어 있으며 구성이 매우 쉽습니다.

from https://stackoverflow.com/questions/26747528/autoscaling-emr-is-it-required-should-i-just-use-ec2-should-i-just-use-qubole by cc-by-sa and MIT license