Amazon EMR FAQ

Q: Amazon EMR이란 무엇입니까?

Amazon EMR은 Apache Spark, Apache Hive 및 Presto와 같은 오픈 소스 프레임워크를 사용하여 데이터 처리, 대화식 분석 및 기계 학습을 위한 업계 최고의 클라우드 빅 데이터 플랫폼입니다. EMR을 사용하면 기존 온프레미스 솔루션의 50%도 안 되는 비용으로 표준 Apache Spark보다 1.7배 이상 빠르게 페타바이트 규모의 분석을 실행할 수 있습니다.

Q: Amazon EMR을 사용해야 하는 이유는 무엇입니까?

Amazon EMR에서는 컴퓨팅 용량 또는 오픈 소스 애플리케이션 관리를 고민하지 않고도 데이터 변환 및 분석에 집중하고 비용을 절감할 수 있습니다. EMR을 사용하면 Amazon EC2에서와 같이 대량 또는 소량의 용량을 프로비저닝하고 변화하는 컴퓨팅 수요를 관리하도록 크기 조정 규칙을 설정할 수 있습니다. 그리고 인프라에서 변화를 사용자에게 알리고 즉각적으로 작업을 수행할 수 있도록 CloudWatch 알림을 설정할 수 있습니다. Kubernetes를 사용하는 경우 EMR을 사용하여 Amazon EKS 클러스터에 워크로드를 제출할 수도 있습니다. EC2 또는 EKS 사용 여부에 관계없이, EMR의 최적화된 런타임 이점을 활용하여 분석 속도를 높이고 비용과 시간 모두를 절감할 수 있습니다.

Q: Amazon EMR을 배포 및 관리하려면 어떻게 해야 합니까?

Amazon EC2, Amazon Elastic Kubernetes Service(EKS) 또는 온프레미스 AWS Outposts를 사용하여 EMR에 워크로드를 배포할 수 있습니다. EMR 콘솔, API, SDK 또는 CLI로 워크로드를 실행 및 관리하고 Amazon Managed Workflows for Apache Airflow(MWAA) 또는 AWS Step Functions를 사용하여 조율할 수 있습니다. 대화식 경험을 위해서 EMR Studio 또는 SageMaker Studio를 사용할 수 있습니다.

Q: Amazon EMR을 시작하려면 어떻게 해야 합니까?

Q: 샘플 코드는 어디에서 찾을 수 있습니까?

이 도움말 및 자습서에서 샘플 코드를 확인할 수 있습니다. EMR Studio를 사용하는 경우 노트북 예제 세트를 통해 기능을 둘러볼 수 있습니다.

Q: 데이터 처리 애플리케이션을 개발하려면 어떻게 해야 합니까?

Amazon EMR Studio에서 R, Python, Scala 및 PySpark로 작성된 데이터 과학 및 데이터 엔지니어링 애플리케이션을 개발하고 시각화하며 디버깅할 수 있습니다. 또한, 예를 들어, Eclipse, Spyder, PyCharm 또는 RStudio를 사용하여 데스크톱에서 데이터 처리 작업을 개발하고 Amazon EMR에서 실행할 수 있습니다. 새 클러스터를 구동할 때 소프트웨어 구성에서 JupyterHub 또는 Zeppelin을 선택하고 하나 이상의 인스턴스를 사용하여 Amazon EMR에서 애플리케이션을 개발할 수도 있습니다.

Q: 명령줄 도구 또는 API를 AWS 관리 콘솔과 비교할 때 각각의 이점은 무엇입니까?

명령줄 도구 또는 API에서는 프로그래밍 방식으로 클러스터를 시작하고 실행 중인 클러스터의 진행 상태를 모니터링하고, 클러스터에 사용자 정의 기능을 추가로 생성(여러 프로세스 단계, 일정 예약, 워크플로, 모니터링 등의 순서)하거나, 기타 Amazon EMR 고객을 위한 유용한 도구 또는 애플리케이션을 개발할 수 있는 기능을 제공합니다. 반면 AWS Management Console은 사용하기 쉬운 그래픽 인터페이스를 제공하는데, 이를 통해 웹 브라우저에서 직접 클러스터를 시작하고 모니터링할 수 있습니다.

Q: 이미 실행 중인 클러스터에 단계를 추가할 수 있습니까?

예. 작업이 실행 중인 경우 AddJobFlowSteps API를 사용하여 옵션에서 단계를 추가할 수 있습니다. AddJobFlowSteps API는 현재 단계 순서의 마지막에 새로운 단계를 추가합니다. 클러스터에 조건부 논리를 구현하거나 디버깅을 수행하기 위해 이 API를 사용할 수도 있습니다.

Q: 클러스터가 완료되면 알림을 받을 수 있습니까?

Amazon SNS에 가입하여 클러스터가 끝날 때 SNS 주제에 클러스터를 게시할 수 있습니다. 또한, AWS 관리 콘솔에서 클러스터 진행률을 보거나 명령줄, SDK 또는 API를 사용하여 클러스터의 상태를 확인할 수 있습니다.

Q: 단계를 완료하면 클러스터를 종료할 수 있습니까?

예. 모든 단계가 완료되면 자동 종료 플래그를 설정하여 클러스터를 자동으로 종료할 수 있습니다.

Q: Amazon EMR은 어떤 OS 버전을 지원합니까?

Amazon EMR 5.30.0 이상 및 Amazon EMR 6.x 시리즈는 Amazon Linux 2에 기반합니다. Amazon Linux 2에 기반하여 생성된 사용자 지정 AMI를 지정할 수도 있습니다. 이렇게 하면 사실상 거의 모든 애플리케이션에 대해 정교한 사전 구성을 수행할 수 있습니다. 자세한 내용은 사용자 지정 AMI 사용을 참조하세요.

Q: Amazon EMR은 서드 파티 소프트웨어 패키지를 지원합니까?

예. 클러스터에 서드 파티 소프트웨어 패키지를 설치하기 위해 부트스트랩 작업을 사용할 수 있습니다. 또한, Hadoop 분산 캐시 메커니즘을 사용하여 정적으로 컴파일된 실행 파일을 업로드할 수 있습니다. EMR 6.x은 YARN NodeManager을 허용하여 EMR 클러스터 호스트 또는 Docker 컨테이너 내에 바로 컨테이너를 실행하는 하둡 3을 지원합니다. 자세한 내용은 설명서를 참조하세요.

Q: 디버깅을 위해 어떤 도구를 사용할 수 있습니까?

클러스터에 대한 정보를 수집하는 데 사용할 수 있는 도구가 여러 가지 있어서 무엇이 잘못되었는지 결정하도록 지원합니다. Amazon EMR Studio를 사용하는 경우 Spark UI 및 YARN Timeline Service와 같은 도구를 시작하여 디버깅을 단순화할 수 있습니다. Amazon EMR 콘솔에서 Apache Spark, Tez UI 및 WARN 타임라인 서버용 영구 애플리케이션 사용자 인터페이스, 여러 개의 클러스터 내 애플리케이션 사용자 인터페이스 및 모든 YARN 애플리케이션에 대한 Amazon EMR 콘솔의 애플리케이션 요약 보기에 오프클러스터 방식으로 액세스할 수 있습니다. 또한, 이러한 웹 인터페이스를 통해 SSH를 사용하여 프라이머리 노드에 연결하고 클러스터 인스턴스를 볼 수 있습니다. 자세한 내용은 설명서를 참조하세요.

Q: EMR Studio는 무엇입니까?

노트북을 사용해 작업을 제출할 수 있도록 EMR Studio가 통합 개발 환경(IDE)을 제공하므로 데이터 사이언티스트와 데이터 엔지니어는 R, Python, Scala 및 PySpark에서 작성한 데이터 엔지니어링 및 데이터 사이언스 애플리케이션을 쉽게 개발, 시각화 및 디버깅할 수 있습니다.

단일 로그인 기능, 완전관리형 Jupyter 노트북, 자동화 인프라 프로비저닝 및 AWS 콘솔 또는 클러스터 로그인 없이 작업을 디버깅하는 능력을 갖춘 완전관리형 애플리케이션입니다. 데이터 사이언티스트와 분석가는 사용자 지정 커널 및 라이브러리를 설치하고, GitHub 및 BitBucket과 같은 코드 리포지토리를 사용하여 동료와 협업하거나 Apache Airflow, AWS Step Functions 및 Amazon Managed Workflows for Apache Airflow와 같은 오케스트레이션 서비스를 사용하여 파라미터화된 노트북을 예약된 워크플로의 일부로 실행할 수 있습니다. 자세한 내용은 Amazon MWAA를 사용하여 Amazon EMR 노트북에서 분석 작업 오케스트레이션 주제를 참조하세요. EMR Studio 커널 및 애플리케이션은 EMR 클러스터에서 실행되므로 성능을 최적화한 Amazon EMR Runtime for Apache Spark를 사용하는 분산 데이터 처리의 이점을 누릴 수 있습니다. 관리자가 EMR Studio for analysts를 설정함으로써 기존 EMR 클러스터에서 애플리케이션을 실행하거나 EMR용으로 사전 정의된 AWS CloudFormation 템플릿을 사용하여 새 클러스터를 생성할 수 있습니다.

Q: EMR Studio로 어떤 작업을 할 수 있습니까?

EMR Studio를 통해 기업 자격 증명을 사용하여 AWS 콘솔에 로그인하지 않고도 완전관리형 Jupyter 노트북에 바로 로그인하고, 노트북을 몇 초 안에 사용하며, 샘플 노트북에 온보딩하고, 데이터 탐색을 수행할 수 있습니다. 또한, 노트북에서 사용자 지정 커널 및 Python 라이브러리를 로드해 환경을 사용자 지정할 수 있습니다. EMR Studio 커널 및 애플리케이션은 EMR 클러스터에서 실행되므로 성능을 최적화한 Amazon EMR Runtime for Apache Spark를 사용하는 분산 데이터 처리의 이점을 누릴 수 있습니다. Github 및 기타 리포지토리를 통해 노트북을 공유해 동료와 협업할 수 있습니다. 또한, 지속적 통합 및 배포 파이프라인으로 직접 노트북을 실행할 수도 있습니다. 노트북에 다른 파라미터 값을 전달할 수 있습니다. Apache Airflow 등의 워크플로우 통합 서비스를 사용하여 노트북을 연결하고, 노트북을 예정된 워크플로우에 통합할 수 있습니다. 또한 Spark UI 및 YARN 타임라인 서비스와 같은 기본 애플리케이션 인터페이스를 사용해 가능한 한 적은 클릭으로 클러스터 및 작업을 디버깅할 수 있습니다.

Q: EMR Studio는 어떻게 EMR Notebooks과 다른가요?

다섯 가지 큰 차이점이 있습니다.

1. EMR Studio용 AWS Management Console에 액세스할 필요가 없습니다. EMR Studio는 AWS Management Console의 외부에 호스팅합니다. AWS Management Console에 대한 액세스를 데이터 사이언티스트 또는 데이터 엔지니어에게 제공하지 않는 경우 유용합니다.
2. AWS IAM Identity Center(AWS SSO의 후속 서비스)를 사용하여 ID 제공업체의 엔터프라이즈 보안 인증 정보를 사용하여 EMR Studio에 로그인할 수 있습니다. 
3. EMR Studio는 노트북 우선 경험을 제공합니다. EMR Studio 커널 및 애플리케이션은 EMR 클러스터에서 실행되므로 성능을 최적화한 Amazon EMR Runtime for Apache Spark를 사용하는 분산 데이터 처리의 이점을 누릴 수 있습니다. 클러스터에 코드를 실행하여 최대한 단순하게 노트북을 기존 클러스터에 첨부하거나 새로운 것을 프로비저닝할 수 있습니다.
   
4. EMR Studio는 단순화된 사용자 인터페이스 및 추상적인 하드웨어 구성을 가지고 있습니다. 예를 들어 클러스터 양식을 설치하고 새 클러스터를 시작하기 위해 해당 양식을 사용할 수 있습니다. 
5. EMR Studio는 단순화된 디버깅 경험을 활성화하여 한 지점의 자연 애플리케이션 사용자 인터페이스에 최소한의 클릭을 사용하여 액세스할 수 있습니다.

Q: EMR Studio는 SageMaker Studio와 어떻게 다릅니까?

EMR Studio 및 SageMaker Studio 모두를 Amazon EMR에서 사용할 수 있습니다. EMR Studio는 R, Python, Scala 및 PySpark에서 작성한 데이터 엔지니어링 및 데이터 사이언스 애플리케이션을 쉽게 개발, 시각화 및 디버깅할 수 있는 통합 개발 환경(IDE)을 제공합니다. Amazon SageMaker Studio는 모든 기계 학습 개발 단계를 수행할 수 있는 웹 기반의 단일 시각적 인터페이스를 제공합니다. SageMaker Studio는 모델을 구축, 훈련 및 배포하는 데 필요한 액세스 권한, 제어 및 가시성을 각 단계별로 완벽하게 제공합니다. 신속하게 데이터를 업로드하고, 새로운 노트북을 생성하며, 모델을 훈련 및 튜닝하고, 단계를 앞뒤로 이동하며 실험을 조정하고, 결과를 비교하며, 모델을 프로덕션에 배포하여 한 곳에서 생산성을 크게 높일 수 있습니다. 

Q: EMR Studio를 시작하려면 어떻게 해야 합니까?

관리자가 반드시 처음 EMR Studio를 설치해야 합니다. Amazon EMR Studio의 고유 로그인 URL을 관리자에게 받으면 기업 자격 증명을 사용해 Studio에 직접 로그인할 수 있습니다.

Q: EMR Studio를 사용하기 위해서는 AWS Management Console에 로그인해야 하나요?

아니오. 관리자가 EMR Studio를 설치하고 Studio 액세스 URL을 제공하면, 고객 팀은 기업 자격 증명을 사용해 로그인할 수 있습니다. AWS Management Console에 로그인할 필요는 없습니다. EMR Studio에서 팀은 작업을 수행하고 관리자가 구성한 리소스에 액세스할 수 있습니다.

Q: EMR Studio의 Single Sign-On 경험에 지원되는 ID 제공업체는 무엇인가요?

AWS IAM Identity Center(AWS SSO의 후속 서비스)는 EMR Studio의 Single Sign-On 서비스 제공업체입니다. AWS IAM이 지원하는 ID 제공업체 목록은 설명서에서 찾을 수 있습니다.

Q: EMR Studio의 Workspace는 무엇입니까?

Workspace는 jupyter Notebooks를 구성하도록 지원합니다. Workspace 내 모든 노트북은 동일한 Amazon S3 위치에 저장되며 동일 클러스터에서 실행됩니다. 또한 GitHub 저장소 같은 코드 저장소를 workspace 내 모든 노트북에 링크할 수 있습니다. WorkSpace를 클러스터에 첨부하기 전에 생성 및 구성할 수 있으나 노트북을 실행하기 전에 클러스터를 연결해야 합니다.

Q: EMR Studio에서 WorkSpace를 생성하거나 클러스터 없이 WorkSpace를 열 수 있나요?

예. workspace를 클러스터에 첨부하지 않고 생성하거나 열 수 있습니다. 실행을 해야할 때에만 클러스터에 연결해야 합니다. EMR Studio 커널 및 애플리케이션은 EMR 클러스터에서 실행되므로 성능을 최적화한 Amazon EMR Runtime for Apache Spark를 사용하는 분산 데이터 처리의 이점을 누릴 수 있습니다.

Q: 노트북 코드에서 사용할 사용자 정의 라이브러리를 설치할 수 있습니까?

모든 Spark 쿼리는 EMR 클러스터에서 실행되므로, 클러스터에서 Spark 애플리케이션이 사용하는 모든 런타임 라이브러리를 설치해야 합니다. 노트북 셀 내부에 노트북 범위의 라이브러리를 쉽게 설치할 수 있습니다. 또한, 클러스터의 프라이머리 노드에 SSH를 사용하여 연결된 동안 또는 노트북 셀 내부에서 클러스터 프라이머리 노드에 Jupyter Notebook 커널 및 Python 라이브러리를 설치할 수도 있습니다. 자세한 내용은 설명서를 참조하세요. 부트스트랩 작업 또는 사용자 지정 AMI를 사용하여 클러스터를 생성할 때 필요한 라이브러리를 설치할 수도 있습니다. 자세한 내용은 부트스트랩 작업을 생성하여 추가 소프트웨어 설치 및 Amazon EMR 관리 가이드에서 사용자 지정 AMI 사용을 참조하세요.

Q: 노트북은 어디에 저장됩니까?

Workspace는 Workspace의 노트북 파일과 함께 정기적으로 Workspace를 생성할 때 지정한 Amazon S3 위치에 ipynb 파일 형식으로 자동 저장됩니다. 노트북 파일 이름은 Amzon EMR Studio의 노트북 이름과 같습니다.

Q: 노트북에서 버전 제어를 사용하려면 어떻게 해야 합니까? GitHub와 같은 리포지토리를 사용할 수 있습니까?

Git 기반 리포지토리를 Amazon EMR Studio 노트북에 연결하여 노트북을 버전 제어 환경에 저장할 수 있습니다.

Q: EMR Studio에서 노트북을 실행할 수 있는 컴퓨팅 리소스는 무엇입니까?

EMR Studio에서는 Amazon Elastic Compute Cloud(Amazon EC2)에서 실행되는 Amazon EMR 또는 Amazon Elastic Kubernetes Service(Amazon EKS) 기반 Amazon EMR에서 노트북 코드를 실행할 수 있습니다. 노트북을 기존 또는 새 클러스터에 연결할 수 있습니다. EMR Studio에서 사전 구성 클러스터 양식을 사용하여 AWS Service Catalog를 통해 클러스터 생성 및 클러스터 이름, 인스턴스 수, 그리고 인스턴스 유형을 특정하는 클러스터 생성이라는 2가지 방법으로 EMR 클러스터를 열 수 있습니다.

Q: Workspace를 EMR Studio 내 다른 컴퓨팅 리소스를 통해 재첨부할 수 있나요?

예, WorkSpace를 열고 좌측의 EMR 클러스터 아이콘을 선택하고, Detach 버튼을 누르고, 그 다음 클러스터 선택 드롭 다운 목록의 클러스터를 선택하고 Attach 버튼을 누릅니다.

Q: EMR Studio의 어디에서 모든 WorkSpace를 찾을 수 있나요?

EMR Studio에서 좌측의 Workspaces 탭을 선택하고 사용자 및 기타 사용자가 동일 AWS 계정에서 생성한 모든 Workspaces를 볼 수 있습니다.

 Q: EMR Studio를 사용하려면 어떤 IAM 정책이 필요합니까?

각 EMR Studio를 다른 AWS 서비스와 상호 운영하기 위해서는 승인이 필요합니다. EMR Studios에 필수 승인을 제공하기 위해 관리자는 EMR Studio 서비스 역할을 제공된 정책을 반영하여 생성해야 합니다. 또한 Studio 수준 권한을 정의하는 EMR Studio의 사용자 역할을 지정해야 합니다. AWS IAM Identity Center(AWS SSO의 후속 서비스)의 사용자 및 그룹을 EMR Studio에 추가할 때 사용자 또는 그룹에 세션 정책을 할당하여 세분화된 권한 제어를 적용할 수 있습니다. 세션 정책은 여러 IAM 역할을 만들 필요 없이 사용자 권한을 세분화하는 데 도움이 됩니다. 세션 정책에 대한 자세한 내용은 AWS Identity and Access Management 사용 설명서에서 정책 및 권한을 참조하세요.

Q: EMR Studio에서 WorkSpace에 첨부할 수 있는 EMR 클러스터에 제한이 있나요?

예. 고가용성(복수 마스터) 클러스터, Kerberized 클러스터 및 AWS Lake Formation 클러스트는 현재 지원하지 않습니다.

Q: Amazon EMR Studio 사용 요금은 얼마입니까?

Amazon EMR Studio는 추가 비용 없이 제공됩니다. EMR Studio 사용 시 Amazon Simple Storage Service 스토리지 및 Amazon EMR 클러스터에 해당되는 요금이 부과됩니다. 요금 옵션 및 세부 정보는 Amazon EMR 요금을 참조하세요.

Q: EMR Notebooks란 무엇입니까?

새 고객에게는 EMR Notebooks 대신, Amazon EMR Studio 사용을 권장합니다. EMR Notebooks는 Jupyter Notebook에 기반한 관리 환경으로, 데이터 사이언티스트, 분석가 및 개발자가 EMR 클러스터를 사용하여 데이터를 준비하고 시각화하며, 동료와 협업하고, 애플리케이션을 구축하며, 대화식 분석을 수행할 수 있습니다. 새 고객에는 EMR Studio 사용을 권장하고 있지만, 호환성을 위해 EMR Notebooks도 지원됩니다.

Q: EMR Notebooks로 어떤 작업을 할 수 있습니까?

EMR Notebooks를 사용하여 Apache Spark 애플리케이션을 구축하고 최소한의 노력으로 EMR 클러스터에서 인터랙티브 쿼리를 실행할 수 있습니다. 여러 사용자가 콘솔에서 직접 서버리스 노트북을 만들거나 기존의 공유 EMR 클러스터에 연결하거나 콘솔에서 직접 클러스터를 프로비저닝하고 즉시 Spark에서 실험을 시작할 수 있습니다. 노트북을 분리하고 다시 새 클러스터에 연결할 수도 있습니다. 노트북은 S3 버킷에 자동으로 저장되며, 콘솔에서 저장된 노트북을 검색하여 작업을 재개할 수 있습니다. EMR Notebooks는 Anaconda 리포지토리에 있는 라이브러리로 사전에 패키지되므로, 노트북 코드에서 이 라이브러리를 가져와 사용하며, 이를 사용해 데이터를 조작하고 결과를 시각화할 수 있습니다. 또한, EMR notebooks에는 통합된 Spark 모니터링 기능이 있어서, Spark 작업 진행을 모니터링하고 노트북 내에서 코드를 디버그할 수 있습니다.

Q: EMR Notebooks를 시작하려면 어떻게 해야 합니까?

EMR Notebooks를 시작하려면 EMR 콘솔을 열고 탐색 창에서 [Notebooks]를 선택합니다. 여기에서 [Create Notebook]을 선택하고 노트북 이름을 입력하고 EMR 클러스터를 선택하거나 바로 새로 만들어 사용할 노트북에 대한 서비스 역할을 제공하고 노트북 파일을 저장할 S3 버킷을 선택하고 [Create Notebook]을 클릭합니다. 노트북에서 [준비(Ready)] 상태를 표시하면, [열기(Open)]를 선택하여 노트북 편집기를 시작합니다.

Q: EMR Notebooks에서는 어떤 EMR 릴리스 버전을 지원합니까?

EMR Notebooks는 EMR 릴리스 5.18.0 이상을 실행하는 EMR 클러스터에 연결할 수 있습니다.

Q: EMR Notebooks의 사용 요금은 얼마입니까?

EMR Notebooks는 사용자에게 추가 비용 없이 제공됩니다. 평상시대로 계정에 연결된 EMR 클러스터에 요금이 부과됩니다. https://aws.amazon.com/emr/pricing/에서 클러스터 요금에 대해 자세한 내용을 확인할 수 있습니다.   

Q: Amazon S3에 내 데이터를 저장하려면 어떻게 해야 합니까?

Amazon EMR은 데이터를 클러스터에서 얻는 다양한 방법을 제공합니다. 가장 일반적인 방식은 데이터를 Amazon S3에 업로드하고 Amazon EMR 내장 기능을 사용하여 데이터를 클러스터에 로딩하는 것입니다. 하둡의 Distributed Cache 기능을 사용하여 파일을 배포 팡리 시스템에서 로컬 파일 시스템으로 옮길 수 있습니다. 자세한 내용은 설명서를 참조하세요. 대신 데이터를 온프레미스에서 클라우드로 마이그레이션한다면, AWS의 Cloud Data Migration 서비스 중 하나를 사용할 수 있습니다.

Q: 종료된 클러스터 로그를 확인하려면 어떻게 해야 합니까?

하둡 시스템 로그와 사용자 로그는 클러스터를 생성할 때 지정한 Amazon S3 버킷에 보관됩니다. Persistent application UI는 오프 클러스터, Spark History Server, Tez UI 및 YARN 타임라인 서버 로그를 실행하며, 애플리케이션 종료 후 30일 간 사용할 수 있습니다.

Q: Amazon EMR에서는 로그를 압축합니까?

현재 Amazon EMR은 Amazon S3로 로그를 이동할 때 이를 압축하지 않습니다.

Q: 인터넷 또는 Amazon S3 이외의 위치에서 내 데이터를 로딩할 수 있습니까?

예. 마지막으로, AWS Direct Connect를 사용하여 AWS로 전용 네트워크 연결을 설정할 수 있습니다. 대용량 데이터를 가지고 있다면 AWS Import/Export를 사용하십시오. 자세한 내용은 설명서를 참조하십시오.

Q: Amazon EMR에서는 입력 데이터를 처리하는 시간을 예측할 수 있습니까?

아니요. 클러스터별로 입력 데이터가 다르므로 작업 시간을 예측할 수 없습니다.

Q: Amazon EMR의 사용료는 얼마입니까?

Amazon EMR 요금은 간단하고 예측 가능합니다. 사용한 모든 시간(초)에 대해 초당 요금을 지불하며 최소 요금은 1분입니다. AWS 요금 계산기를 사용하여 청구액을 추산할 수 있습니다. Amazon EC2를 포함하는 다른 Amazon Web Services 사용은 Amazon EMR과 별도로 청구됩니다.

Q: Amazon EMR 클러스터에는 언제부터 언제까지 사용한 요금이 청구됩니까?

Amazon EMR 청구는 클러스터가 단계를 시작할 준비를 하면 시작됩니다. Amazon EMR 청구는 클러스터 종료 요청 시 종료됩니다. Amazon EC2 청구 시작 및 종료 시점에 대한 보다 자세한 정보는 Amazon EC2 청구 FAQ를 참조하세요.

Q: Amazon EMR, Amazon EC2 및 Amazon S3 사용은 어디에서 추적할 수 있습니까?

Billing and Cost Management 콘솔에서 사용을 추적할 수 있습니다.

Q: 콘솔에 표시된 정규화된 인스턴스 시간을 어떻게 계산합니까?

AWS Management Console에서 각 클러스터에는 [Normalized Instance Hours] 열이 있습니다. 이 열은 지금까지 해당 클러스터가 사용한 대략적인 컴퓨팅 시간을 표시하며, 시간은 가장 가까운 시간으로 올림 처리됩니다.

정규화된 인스턴스 시간은 m1.small 사용 1시간을 정규화된 컴퓨팅 시간 1시간으로 계산한 컴퓨팅 시간입니다. 설명서를 보고 인스턴스 패밀리 내 다른 크기의 목록과 시간 당 해당하는 표준화 팩터를 볼 수 있습니다.

예를 들어, 노드 10개의 r3.8xlarge 클러스터를 1시간 동안 실행하는 경우 콘솔에 표시되는 정규화된 인스턴스 시간은 640시간(10(노드 수) x 64(정규화 인자) x 1(클러스터가 실행된 시간) = 640)이 됩니다.

이것은 추정치이며, 청구 목적으로 사용해서는 안 됩니다. 청구 대상 Amazon EMR 사용량은 Billing and Cost Management 콘솔을 참조하십시오.

Q: Amazon EMR은 Amazon EC2 온디맨드 인스턴스, 스팟 인스턴스 및 예약 인스턴스를 지원합니까?

예. Amazon EMR은 온디맨드, 스팟 및 예약 인스턴스를 원활하게 지원합니다. Amazon EC2 예약 인스턴스에 대한 자세한 내용은 여기를 클릭하십시오. Amazon EC2 스팟 인스턴스에 대한 자세한 내용을 보려면 여기를 클릭하세요. Amazon EC2 용량 예약에 대한 자세한 내용을 보려면 여기를 클릭하세요.

Q: 요금에 세금이 포함되어 있습니까?

명시된 경우를 제외하고 요금에는 VAT 및 해당 판매세를 비롯한 관련 조세 공과가 포함되지 않습니다. 청구지 주소가 일본으로 되어 있는 고객의 경우 AWS 서비스 사용 시 일본 소비세의 적용을 받게 됩니다. 자세히 알아보세요. 

Q: 클러스터를 실행하는 동안, 내 데이터를 다른 사람이 볼 수 없게 하려면 어떻게 해야 합니까?

Amazon EMR은 두 개의 Amazon EC2 보안 그룹(마스터용 및 다른 클러스터 노드용)에서 인스턴스를 시작합니다. 마스터 보안 그룹에는 서비스와의 통신을 위해 열려 있는 포트가 있습니다. 또한, 시작할 때 지정한 키를 사용하여 인스턴스에 SSH 연결할 수 있도록 SSH 포트가 열려있습니다. 다른 노드는 다른 보안 그룹에서 시작합니다. 이 보안 그룹은 마스터 인스턴스와의 상호작용만 허용합니다. 기본적으로 두 보안 그룹 모두 다른 고객에게 속한 Amazon EC2 인스턴스와 같은 외부 소스가 액세스하지 못하도록 설정되어 있습니다. 둘 다 계정 내에 있는 보안 그룹이므로, 표준 EC2 도구나 대시보드를 사용하여 보안 그룹을 다시 구성할 수 있습니다. EC2 보안 그룹에 대한 자세한 내용을 보려면 여기를 클릭하세요. 또한, 규칙을 통해 예외 목록에 추가하지 않은 모든 포트에서 퍼블릭 액세스를 허용하는 경우 클러스터 생성을 방지하기 위해 사용하는 각 리전에서 Amazon EMR 퍼블릭 액세스 차단을 구성할 수 있습니다.

Q: 저장된 데이터는 얼마나 안전합니까?

Amazon S3는 저장된 데이터를 무단 액세스로부터 보호하는 인증 메커니즘을 제공합니다. 데이터를 업로드하는 고객이 달리 명시하지 않는 한 해당 고객만 데이터에 액세스할 수 있습니다. Amazon EMR 고객은 보안 전송을 위해 Amazon S3에 HTTPS 프로토콜을 사용하여 데이터를 전송할 수도 있습니다. 또한 Amazon EMR은 Amazon S3와 Amazon EC2 간에 데이터를 전송 시 항상 HTTPS를 사용합니다. 보안을 강화하기 위해 고객은 일반적인 데이터 암호화 도구를 사용하여 Amazon S3에 업로드하기 전에 입력 데이터를 암호화할 수 있습니다. 이 경우 Amazon EMR이 Amazon S3에서 데이터를 가져올 때, 고객은 클러스터 시작 부분에 복호화 단계를 추가해야 합니다.

Q: 보안 또는 규정 준수 감사를 위해 내 계정에서 이루어진 모든 EMR API 호출 기록을 확인할 수 있습니까?

예. AWS CloudTrail은 계정에 대한 AWS API 호출을 기록하고 로그 파일을 사용자에게 전달하는 웹 서비스입니다. CloudTrail에서 작성되는 AWS API 호출 내역을 통해 보안 분석, 리소스 변경 사항 추적 및 규정 준수 감사를 수행할 수 있습니다. AWS CloudTrail 세부 정보 페이지에서 CloudTrail에 대해 자세히 알아보고 CloudTrail의 AWS 관리 콘솔을 통해 활성화합니다.

Q: Amazon S3에서 EMR 사용자가 액세스할 수 있는 내용을 제어하려면 어떻게 해야 합니까?

기본적으로, Amazon EMR 애플리케이션 프로세스는 다른 AWS 서비스를 호출할 때 EC2 인스턴스 프로파일을 사용합니다. 멀티 테넌트 클러스터의 경우 Amazon EMR은 Amazon S3 데이터에 대한 사용자 액세스 관리를 위한 세 가지 옵션을 제공합니다.

1. AWS Lake Formation과 통합을 통해 AWS Lake Formation에서 AWS Glue 데이터 카탈로그의 데이터베이스, 테이블 및 열 액세스에 대한 세분화된 권한 부여 정책을 정의하고 관리할 수 있습니다. 대화식 EMR Spark 워크로드에 대해 Amazon EMR Notebooks 및 Apache Zeppelin을 통해 제출되는 작업에 권한 부여 정책을 적용하고 감사 이벤트를 AWS CloudTrail로 전송할 수 있습니다. 이 통합을 활성화하면 Security Assertion Markup Language(SAML) 2.0과 호환되는 엔터프라이즈 자격 증명 시스템에서 EMR Notebooks 또는 Apache Zeppelin으로의 연동 Single Sign-On도 활성화할 수 있습니다.
   
2. Apache Ranger와의 기본 통합을 통해 신규 또는 기존 Apache Ranger 서버를 설정하여 Hive Metastore를 통해 Amazon S3 데이터의 데이터베이스, 테이블 및 열에 액세스하는 사용자에 대한 세분화된 권한 부여 정책을 정의하고 관리할 수 있습니다. Apache Ranger는 Hadoop 플랫폼 전체에 걸쳐 포괄적인 데이터 보안을 활성화, 모니터링 및 관리하는 오픈 소스 도구입니다.
   
   이 기본 통합을 사용하면 Apache Ranger 정책 관리 서버에서 세 가지 유형의 권한 부여 정책을 정의할 수 있습니다. Hive에 대한 테이블, 열 및 행 수준 권한 부여, Spark에 대한 테이블 및 열 수준 권한 부여 및 Amazon S3에 대한 접두사 및 객체 수준 권한 부여를 설정할 수 있습니다. Amazon EMR은 해당하는 Apache Ranger 플러그인을 클러스터에 자동으로 설치하고 구성합니다. 이러한 Ranger 플러그인은 승인 정책을 위해 정책 관리 서버와 동기화되고, 데이터 액세스 제어를 적용하고 감사 이벤트를 Amazon CloudWatch Logs로 전송합니다.
   
3. Amazon EMR User Role Mapper: AWS IAM 권한을 활용하여 AWS 리소스에 대한 액세스를 관리할 수 있습니다. 사용자(또는 그룹)과 사용자 지정 IAM 역할 간의 매핑을 생성할 수 있습니다. 사용자 또는 그룹은 사용자 지정 IAM 역할에 의해 허용되는 데이터에만 액세스할 수 있습니다. 현재 이 기능은 AWS 랩을 통해 제공됩니다.

Q: Amazon EMR은 가용 영역을 어떻게 활용합니까?

Amazon EMR은 동일한 Amazon EC2 가용 영역에 있는 해당 클러스터에 대해 모든 노드를 시작합니다. 동일한 영역에서 클러스터를 실행하면 작업 흐름의 성능이 개선됩니다. 기본적으로 Amazon EMR은 클러스터를 실행하기 위해 가장 가용성이 높은 리소스가 있는 가용 영역을 선택합니다. 그러나 필요하다면 다른 가용 영역을 지정할 수 있습니다. 또한, 저렴한 요금의 온디맨드 인스턴스, 최적의 스팟 용량을 위해 할당을 최적화하는 옵션을 이용하거나 온디맨드 용량 예약을 사용할 수 있습니다.

Q: 어느 리전에서 Amazon EMR을 사용할 수 있습니까?

Amazon EMR을 지원하는 AWS 리전 목록은 모든 AWS 글로벌 인프라가 나와 있는 AWS 리전 표를 참조하십시오.

Q: Amazon EMR은 AWS 로컬 영역에서 지원됩니까?

EMR은 로스앤젤레스 AWS 로컬 영역에서 클러스터 시작을 지원합니다. 미국 서부(오레곤) 리전에서 EMR을 사용하여 클러스터를 로스앤젤레스 AWS 로컬 영역과 연관된 서브넷에서 시작할 수 있습니다

Q: 클러스터를 실행하려면 어느 리전을 선택해야 합니까?

클러스터를 생성하는 경우 일반적으로 데이터가 저장되어 있는 리전을 선택해야 합니다.

Q: 미국 리전에서 실행 중인 클러스터에서 EU 데이터를 사용하거나 그 반대로 할 수 있습니까?

예. 가능합니다. 데이터를 한 리전에서 다른 리전으로 전송할 경우, 대역폭 요금이 부과됩니다. 대역폭 요금 정보는 EC2 세부 정보 페이지의 요금 섹션을 참조하십시오.

Q: AWS GovCloud(US) 리전이 다른 리전과 다른 점은 무엇입니까?

AWS GovCloud (US) 리전은 미국 정부 기관과 고객을 위해 설계되었습니다. 미국 ITAR 요구 사항을 준수합니다. GovCloud에서 EMR은 스팟 인스턴스 또는 enable-debugging 기능을 지원하지 않습니다. EMR 관리 콘솔은 아직 GovCloud에서 사용할 수 없습니다.

Q: Amazon EMR 클러스터란 무엇입니까?
클러스터는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 모음입니다. 클러스터의 각 인스턴스는 노드라고 하며, 노드 유형이라고 하는 클러스터 내 역할을 보유합니다. Amazon EMR은 각 노드 유형에 서로 다른 소프트웨어 구성 요소를 설치하며, Apache Hadoop과 같은 분산 애플리케이션에서 각 노드에 역할을 제공할 수도 있습니다. 모든 클러스터에는 ‘j-’로 시작되는 고유한 식별자가 있습니다.

Q: 클러스터에서 노드 유형이란 무엇입니까?
Amazon EMR 클러스터에는 다음과 같은 세 가지 노드 유형이 있습니다.

1. 프라이머리 노드: 처리를 위해 다른 노드 사이에서 데이터 및 태스크 분산을 조정하도록 소프트웨어 구성 요소를 실행하여 클러스터를 관리하는 노드. 프라이머리 노드는 태스크 상태를 추적하고 클러스터 상태를 모니터링합니다. 각 클러스터에는 프라이머리 노드가 있으며, 프라이머리 노드에서만 단일 노드 클러스터를 생성할 수 있습니다.
2. 코어 노드: 클러스터의 Hadoop 분산 파일 시스템(HDFS)에서 태스크를 실행하고 데이터를 저장하는 소프트웨어 구성 요소를 포함하는 노드. 다중 노드 클러스터에는 하나 이상의 코어 노드가 있습니다.
3. 태스크 노드: HDFS에서 태스크만 실행하고 데이터를 저장하지 않는 소프트웨어 구성 요소를 포함하는 노드. 태스크 노드는 선택 사항입니다.
   
   

Q: 클러스터 단계란 무엇입니까?
하나의 클러스터 단계는 사용자가 정의한 처리 단위로, 대개 데이터를 처리하는 하나의 알고리즘에 매핑됩니다. 단계란 Java, Ruby, Perl, Python, PHP, R 또는 C++로 작성된 스트리밍 프로그램 또는 Java jar로서 구현된 하둡 MapReduce 애플리케이션입니다. 예를 들어 단어가 문서에 등장하는 빈도를 계산하여 빈도수에 따라 정렬하여 출력하려고 할 때, 첫 번째 단계는 MapReduce 애플리케이션에서 각 단어의 출현 횟수를 계수하는 것이며, 두 번째 단계는 MapReduce 애플리케이션에서 개수를 기준으로 첫 번째 단계의 출력 결과를 정렬하는 것입니다.

Q: 각 클러스터의 상태는 무엇을 의미합니까?
STARTING – EC2 인스턴스를 구성하여 클러스터가 시작됩니다.
BOOTSTRAPPING – 부트스트랩 작업이 클러스터에서 실행되고 있습니다.
RUNNING – 클러스터가 현재 실행 중인 단계입니다.
WAITING – 클러스터가 현재 활성 상태이나, 실행할 단계가 없습니다.
TERMINATING – 클러스터를 종료하는 중입니다.
TERMINATED – 클러스터가 오류 없이 종료되었습니다.
TERMINATED_WITH_ERRORS – 클러스터 종료 시 오류가 발생했습니다.

Q: 각 단계의 상태는 무엇을 의미합니까?
PENDING – 실행 대기 상태인 단계입니다.
RUNNING – 현재 실행 중인 단계입니다.
COMPLETED – 단계가 성공적으로 완료되었습니다.
CANCELLED – 이전 단계가 실패했거나 클러스터가 실행되기 전에 중단되어 해당 단계가 실행 전에 취소되었습니다.
FAILED – 단계를 수행하는 동안 실패했습니다.

Q: 클러스터를 시작하려면 어떻게 해야 합니까?
간단한 클러스터 요청 양식을 작성하면 AWS Management Console을 통해 클러스터를 시작할 수 있습니다. 요청 양식에서 클러스터의 이름, 입력 데이터의 Amazon S3 내 위치, 처리 애플리케이션, 원하는 데이터 출력 위치, 사용하려는 Amazon EC2 인스턴스 수와 유형을 지정합니다. 필요에 따라 클러스터 로그 파일과 실행 중인 클러스터에 로그인하기 위한 SSH 키를 저장할 위치를 지정할 수도 있습니다. 또는 RunJobFlow API를 사용하거나 명령줄 도구에서 'create' 명령을 사용하여 클러스터를 시작할 수 있습니다. EMR Studio를 통해 클러스터를 실행하려면 위의 EMR Studio 섹션을 참조하세요.

Q: 클러스터를 종료하려면 어떻게 해야 합니까?
AWS Management Console에서 클러스터를 선택하고 [Terminate] 버튼을 클릭하여 언제든지 클러스터를 종료할 수 있습니다. 또는 TerminateJobFlows API를 사용할 수 있습니다. 실행 중인 클러스터를 종료하면 Amazon S3에 보관되지 않은 결과를 잃게 되고, 모든 Amazon EC2 인스턴스가 종료됩니다.

Q: Amazon EMR은 동시에 여러 개의 클러스터를 지원합니까?
원하는 만큼 얼마든지 클러스터를 시작할 수 있습니다. 시작 시 모든 클러스터에 대한 인스턴스 수는 20개로 제한됩니다. 더 많은 인스턴스가 필요한 경우 Amazon EC2 인스턴스 요청 양식을 작성합니다. Amazon EC2 한도를 증가하면, 새로운 한도가 Amazon EMR 클러스터에 적용됩니다.

Q: Amazon EMR은 Amazon EC2와 Amazon S3를 어떻게 사용합니까?

입력 데이터와 데이터 처리 애플리케이션을 Amazon S3에 업로드합니다. 그러면 Amazon EMR은 지정한 수만큼 Amazon EC2 인스턴스를 시작합니다. 서비스는 클러스터를 실행하면서, S3 URI 계획을 사용하여 Amazon S3의 입력 데이터를 실행 중인 Amazon EC2 인스턴스로 가져옵니다. 클러스터가 완료되면, Amazon EMR은 출력 데이터를 Amazon S3로 전달합니다. 그러면 Amazon S3에서 출력 데이터를 검색하거나 이 데이터를 다른 클러스터에서 입력 데이터로 사용할 수 있습니다.

Q: Amazon EMR에서 컴퓨팅은 어떻게 수행됩니까?

Amazon EMR은 하둡 데이터 처리 엔진을 사용하여 MapReduce 프로그래밍 모델에 구현된 컴퓨팅을 수행합니다. 고객은 map()과 reduce() 함수에 대한 알고리즘을 실행합니다. 서비스는 하나의 단일 마스터와 여러 개의 다른 노드로 구성된, 고객이 지정한 수의 Amazon EC2 인스턴스를 시작합니다. Amazon EMR은 이 인스턴스에서 하둡 소프트웨어를 실행합니다. 마스터 노드는 입력 데이터를 블록으로 분할하여 블록 처리를 다른 노드에 분배합니다. 그러면 각 노드는 할당된 데이터에서 map 함수를 실행하고 중간 데이터를 생성합니다. 중간 데이터는 정렬되고 분할되어 reducer 함수를 노드에서 로컬로 적용하는 프로세스로 전송됩니다. 마지막으로, reducer 작업의 출력이 파일에 수집됩니다. 하나의 ‘클러스터’가 이러한 일련의 MapReduce 단계를 포함할 수 있습니다.

Q: Amazon EMR은 어떤 Amazon EC2 인스턴스 유형을 지원합니까?

인스턴스 유형 및 리전별 요금에 대한 자세한 내용은 EMR 요금 페이지를 참조하세요.

Q: 클러스터를 실행하는 데 시간이 얼마나 걸립니까?

클러스터를 실행하는 데 걸리는 시간은 클러스터의 유형, 입력 데이터의 양, 클러스터에서 사용하기로 선택한 Amazon EC2 인스턴스의 수와 유형 등 여러 가지 요인에 따라 달라집니다.

Q: 클러스터의 마스터 노드에 장애가 발생하면 Amazon EMR에서 이를 복구할 수 있습니까?

예. 마스터 노드가 3개인 EMR 클러스터(5.23 버전 이상)를 시작할 수 있으며, YARN Resource Manager, HDFS Name Node, Spark, Hive, Ganglia 같은 고가용성 애플리케이션을 지원할 수 있습니다. Amazon EMR은 기본 마스터 노드에 장애가 발생하거나 Resource Manager 또는 Name Node 같은 중요 프로세스에 장애가 발생하는 경우 자동으로 예비 마스터 노드로 장애 조치됩니다. 덕분에 마스터 노드가 잠재적 단일 장애 지점이 아니므로 장기 실행 EMR 클러스터를 중단 없이 실행할 수 있습니다. 장애 발생 시 Amazon EMR은 장애가 발생한 마스터 노드를 동일한 구성과 부트스트랩 작업으로 새 마스터 노드로 자동 교체합니다. 

Q: 클러스터의 다른 노드에 장애가 발생하면 Amazon EMR에서 이를 복구할 수 있습니까?

예. Amazon EMR은 노드 장애에 대한 내결함성이 있으며, 노드에 장애가 발생해도 작업을 계속 실행합니다. 또한, Amazon EMR은 코어 노드에 장애가 발생하면 새로운 코드를 프로비저닝합니다. 하지만 해당 클러스터의 모든 노드가 손실되는 경우에는 노드를 교체하지 않습니다.

Q: 클러스터 노드에 SSH로 연결할 수 있습니까?

예. SSH로 클러스터 노드에 연결하고 이곳에서 직접 하둡 명령을 실행할 수 있습니다. SSH로 특정 노드에 연결해야 할 경우, 먼저 마스터 노드에 SSH 연결한 후 해당 노드에 SSH로 연결해야 합니다.

Q: Amazon EMR 부트스트랩 작업이란 무엇입니까?

부트스트랩 작업은 클러스터를 실행하기 전에 사용자에게 사용자 정의 설치 프로그램을 실행하는 방법을 제공하는 Amazon EMR의 기능입니다. 부트스트랩 작업은 클러스터를 실행하기 전에 소프트웨어를 설치하거나 인스턴스를 구성하는 데 사용할 수 있습니다. 부트스트랩 작업에 대한 자세한 내용은 EMR의 개발자 안내서에서 참조할 수 있습니다.

Q: 부트스트랩 작업은 어떻게 사용할 수 있습니까?

Bash, Perl, Python, Ruby, C++ 또는 Java와 같이 클러스터 인스턴스에 이미 설치된 언어로 부트스트랩 작업 스크립트를 작성할 수 있습니다. 사전 정의된 부트스트랩 작업도 사용할 수 있습니다. 스크립트가 일단 작성되면 Amazon S3로 업로드하고 클러스터를 시작할 때 해당 위치를 참조하도록 해야 합니다. 부트스트랩 작업의 사용 방법에 대한 자세한 내용은 개발자 안내서를 참조하십시오.

Q: 클러스터에 대한 하둡 설정은 어떻게 구성합니까?

EMR의 기본 하둡 구성은 대부분 작업에 적합합니다. 그러나 클러스터의 특정 메모리와 처리 요구 사항에 따라 설정을 조정해야 할 수 있습니다. 예를 들어, 클러스터 작업이 메모리를 많이 사용하는 경우, 코어당 작업 수 및 작업 추적 힙 크기를 줄일 수 있습니다. 이 경우 사전 정의된 부트스트랩 작업을 사용하여 시작 시 클러스터를 구성합니다. 구성에 대한 자세한 내용과 사용 지침은 개발자 안내서의 메모리 집약적 부트스트랩 작업 섹션을 참조하세요. 클러스터 설정을 원하는 대로 사용자 정의할 수 있는 다른 사전 정의된 부트스트랩 작업도 사용할 수 있습니다. 사용 지침은 개발자 안내서의 하둡 부트스트랩 작업 구성 섹션을 참조하세요.

Q: 실행 중인 클러스터에서 노드 수를 변경할 수 있습니까?

예. 노드에는 (1) 하둡 분산 파일 시스템(HDFS)을 사용하여 영구 데이터를 호스팅하고 하둡 작업을 실행하는 코어 노드와 (2) 하둡 작업을 실행만 작업 노드, 두 가지 노드가 있습니다. 클러스터를 실행하는 동안 코어 노드 수를 늘리고 작업 노드 수를 늘리거나 줄일 수 있습니다. 이때 API, Java SDK 또는 명령줄 클라이언트를 사용하여 실행합니다. 실행 중인 클러스터의 크기를 변경하는 방법에 대한 자세한 내용은 개발자 안내서의 실행 중인 클러스터 크기 조정 섹션을 참조하세요. 또한 EMR 관리 스케일링을 사용할 수 있습니다.

Q: 코어 노드와 작업 노드는 각각 언제 사용할 수 있습니까?

코어 노드는 HDFS의 영구 데이터를 호스팅하므로 삭제할 수 없습니다. 코어 노드는 클러스터가 완료될 때까지 필요한 용량을 유지해야 합니다. 작업 노드는 추가하거나 삭제할 수 있습니다. 또한 HDFS를 포함하지 않으므로, 일시적으로만 필요한 용량에 적합합니다. 스팟 인스턴스 상 작업 인스턴스 필릿을 실행하여 비용을 최소화하는 동시에 용량을 늘립니다.

Q: 실행 중인 클러스터에서 노드 수를 변경해야 하는 이유는 무엇입니까?

실행 중인 클러스터에서 노드 수를 변경해야 하는 상황은 여러 가지가 있습니다. 클러스터의 속도가 예상보다 느린 경우 또는 시간 요구 사항이 변경된 경우, 코어 노드의 수를 늘려 클러스터의 성능을 향상할 수 있습니다. 클러스터 단계에 따라 필요한 용량이 다른 경우는 적은 수의 코어 노드로 시작하여 클러스터의 다양한 용량 요구 사항에 따라 작업 노드의 수를 늘리거나 줄일 수 있습니다. 또한 EMR 관리 스케일링을 사용할 수 있습니다.

Q: 클러스터 단계 간에 노드 수를 자동 변경할 수 있습니까?

예. 사전 정의된 단계를 워크플로에 포함함으로써 필요한 용량이 서로 다른 단계 간에 클러스터의 크기를 자동으로 조정하도록 할 수 있습니다. 모든 단계는 차례대로 실행되기 때문에 이렇게 하면 주어진 클러스터 단계를 실행할 노드 수를 설정할 수 있습니다.

Q: 다른 IAM 사용자가 내 클러스터에 액세스하도록 허용하려면 어떻게 해야 합니까?

EMR CLI 내의 모든 IAM 사용자가 볼 수 있는 새 클러스터를 생성하려면 클러스터를 생성할 때 --visible-to-all-users 플래그를 추가합니다. 예: elastic-mapreduce --create --visible-to-all-users. Management Console에서 Create Cluster Wizard를 실행하고 [Advanced Options] 창에서 [Visible to all IAM Users]를 선택하면 됩니다.

기존 클러스터를 모든 IAM 사용자가 볼 수 있도록 하려면 EMR CLI를 사용해야 합니다. --set-visible-to-all-users를 사용하고 클러스터 식별자를 지정합니다. 예: elastic-mapreduce --set-visible-to-all-users true --jobflow j-xxxxxxx. 해당 클러스터를 생성한 사용자만 이 작업을 수행할 수 있습니다.

자세한 내용은 EMR 개발자 안내서의 사용자 권한 구성 섹션을 참조하세요.

Q: 어떤 Amazon EMR 리소스를 태그할 수 있습니까?

활성화된 Amazon EMR 클러스터에 태그를 추가할 수 있습니다. Amazon EMR 클러스터는 Amazon EC2 인스턴스로 구성되어 있으며, Amazon EMR 클러스터에 추가된 태그는 해당 클러스터에 있는 각각의 활성화된 Amazon EC2 인스턴스에 전파됩니다. 활성화된 클러스터의 일부였으나 이미 종료된 클러스터 또는 Amazon EC2 인스턴스의 경우에는 태그를 추가, 편집 또는 제거할 수 없습니다.

Q: Amazon EMR을 태그 지정할 경우 IAM 사용자의 리소스 기반 권한을 지원합니까?

아니요. Amazon EMR은 태그에 의한 리소스 기반 권한을 지원하지 않습니다. 하지만 Amazon EC2 인스턴스에 전파된 태그는 일반적인 Amazon EC2 태그처럼 작동한다는 점을 명심해야 합니다. 따라서 Amazon EMR에서 전파된 태그가 IAM 정책의 조건에 부합할 경우에는 태그에 Amazon EC2의 IAM 정책이 적용됩니다.

Q: 리소스에 얼마나 많은 태그를 추가할 수 있습니까?

Amazon EMR 클러스터에는 최대 10개의 태그를 추가할 수 있습니다.

Q: 클러스터상의 내 Amazon EMR 태그가 해당 클러스터에 있는 각각의 Amazon EC2 인스턴스에 표시됩니까? 내 Amazon EMR 클러스터에서 태그를 제거하면 각각의 관련 EC2 인스턴스에서 해당 태그가 자동으로 제거됩니까?

예. Amazon EMR은 클러스터에 추가된 태그를 해당 클러스터의 EC2 인스턴스에 전파합니다. Amazon EMR 클러스터에 태그를 추가하면 관련 Amazon EC2 인스턴스에도 나타납니다. 반대로 Amazon EMR 클러스터에서 태그를 제거할 경우, 해당 태그는 관련 Amazon EC2 인스턴스에서도 제거됩니다. 하지만 Amazon EC2에 대한 IAM 정책을 사용하고 있으며 Amazon EMR의 태그 지정 기능을 사용할 계획이라면 Amazon EC2 태그 지정 API CreateTags 및 DeleteTags 사용에 대한 권한이 부여되어야 합니다.

Q: 어떻게 하면 비용 구분을 위해 내 대금 청구서에 내 태그가 표시되도록 할 수 있습니까?

여기에서 AWS 결제 보고서에 사용할 태그를 선택하십시오. 그런 다음 같은 태그 키 값을 가진 리소스를 기준으로 결제 정보를 정리하면 모든 리소스 비용의 합을 볼 수 있습니다.

Q: 어떤 Amazon EC2 인스턴스가 Amazon EMR 클러스터에 포함되어 있는지 어떻게 알 수 있습니까?

Amazon EMR 클러스터와 연관된 Amazon EC2 인스턴스에는 아래와 같이 2개의 시스템 태그가 존재합니다.

• aws:elasticmapreduce:instance-group-role=CORE
  • Key = instance-group role ; Value = [CORE or TASK];
• aws:elasticmapreduce:job-flow-id=j-12345678
  • Key = job-flow-id ; Value = [JobFlowID]

Q: Amazon EC2 인스턴스에서 바로 태그를 편집할 수 있습니까?

예. 태그는 Amazon EMR 클러스터의 일부인 Amazon EC2 인스턴스에서 바로 추가 또는 제거할 수 있습니다. 하지만 연결된 Amazon EC2 인스턴스에 직접 변경한 내용은 Amazon EMR의 태그 지정 시스템과 동기화되지 않으므로 이 방법을 권장하지는 않습니다. 연결된 Amazon EC2 인스턴스와 클러스터 모두에 올바른 태그가 지정될 수 있도록 Amazon EMR 클러스터의 태그는 Amazon EMR 콘솔, CLI 또는 API에서 추가 또는 제거하는 것이 좋습니다.

Q: Amazon EMR Serverless란 무엇입니까?

Amazon EMR Serverless는 Amazon EMR의 새로운 배포 옵션으로, 이 옵션을 사용하면 클러스터 구성, 관리 및 크기 조정 없이 Apache Spark 및 Apache Hive와 같은 빅 데이터 프레임워크를 실행할 수 있습니다.

Q: EMR Serverless는 누가 사용할 수 있습니까?

데이터 엔지니어, 분석가 및 사이언티스트는 EMR Serverless를 사용하여 Apache Spark 및 Apache Hive와 같은 오픈 소스 프레임워크에서 애플리케이션을 구축할 수 있습니다. 이러한 프레임워크를 사용하여 데이터를 변환하고 대화형 SQL 쿼리와 기계 학습 워크로드를 실행할 수 있습니다.

Q: EMR Serverless를 시작하려면 어떻게 해야 합니까?

EMR Studio, AWS CLI 또는 API를 사용하여 작업을 제출하고, 작업 상태를 추적하며, EMR Serverless에서 실행할 데이터 파이프라인을 구축할 수 있습니다. EMR Studio에서 시작하려면 AWS Management Console에 로그인하고 분석(Analytics) 범주에서 Amazon EMR로 이동한 다음 Amazon EMR Serverless를 선택합니다. AWS Management Console의 지침에 따라 분석(Analytics) 범주에서 Amazon EMR로 이동하고 Amazon EMR Serverless를 선택합니다. 시작 가이드의 지침에 따라 EMR Serverless 애플리케이션을 생성하고 작업을 제출합니다. CLI를 사용하여 애플리케이션을 시작하고 작업을 제출하려면 AWS CLI에서 애플리케이션 상호 작용 페이지를 참조하세요. GitHub 리포지토리에서 EMR Serverless 예제와 샘플 코드를 찾아볼 수도 있습니다.

Q: EMR Serverless는 어떤 오픈 소스 프레임워크를 지원합니까?

EMR Serverless는 현재 Apache Spark와 Apache Hive 엔진을 지원합니다. Apache Presto 또는 Apache Flink와 같은 추가 프레임워크에 대한 지원을 원하는 경우 emr-feedback@amazon.com으로 요청을 보내주세요.

Q: 어느 리전에서 EMR Serverless를 사용할 수 있습니까?

EMR Serverless는 아시아 태평양(뭄바이), 아시아 태평양(서울), 아시아 태평양(싱가포르), 아시아 태평양(시드니), 아시아 태평양(도쿄), 캐나다(중부), 유럽(프랑크푸르트), 유럽(아일랜드), 유럽(런던), 유럽(파리), 유럽(스톡홀름), 남아메리카(상파울루), 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(캘리포니아 북부) 및 미국 서부(오레곤)의 AWS 리전에서 제공됩니다.

Q: Amazon EMR Serverless, Amazon EMR on EC2, Amazon EMR on AWS Outposts, Amazon EMR on EKS 간의 차이는 무엇입니까?

Amazon EMR은 EC2 기반 클러스터, EKS 클러스터, Outposts 또는 Serverless에서 애플리케이션을 실행할 수 있는 옵션을 제공합니다. EC2 기반 EMR 클러스터는 애플리케이션 실행에 대한 최대한의 제어와 유연성을 필요로 하는 고객에게 적합합니다. EC2 기반 EMR 클러스터를 사용하면 애플리케이션별 성능 요구 사항을 충족하는 EC2 인스턴스 유형을 선택하고, Linux AMI를 사용자 지정하고, EC2 인스턴스 구성을 사용자 지정하고, 오픈 소스 프레임워크를 사용자 지정 및 확장하며, 추가 사용자 지정 소프트웨어를 클러스터 인스턴스에 설치할 수 있습니다. EKS 기반 Amazon EMR은 EKS를 기반으로 표준화하여 애플리케이션 전체의 클러스터를 관리하거나 동일한 클러스터에서 다른 버전의 오픈 소스 프레임워크를 사용하려는 고객에게 적합합니다. AWS Outposts 기반 Amazon EMR은 EMR을 데이터 센터와 더 가까운 위치의 Outpost 내에서 실행하려는 고객을 위한 옵션입니다. EMR Serverless는 클러스터 관리 및 운영 없이 오픈 소스 프레임워크를 사용하여 애플리케이션을 실행하는 것을 선호하는 고객에게 적합합니다.

Q: EMR Serverless와 EC2 기반 Amazon EMR의 기능에는 어떤 차이가 있습니까?

Q: EMR Serverless에서 지원되는 EMR 릴리스는 무엇입니까?

EMR Serverless는 EMR 릴리스 레이블 6.6 이상을 지원합니다. EMR Serverless는 다른 EMR 배포 옵션에서 제공되는 것과 동일한 성능 최적화 EMR 런타임을 제공하며 표준 오픈 소스 프레임워크의 API와 100% 호환됩니다.

Q: 사전 초기화된 용량에 대한 BilledResourceUtilization에 포함되나요?

BilledResourceUtilization은 사전 초기화된 용량이 작업에 사용된 기간만 고려하며 해당 용량의 유휴 시간은 고려하지 않습니다.

Q: BilledResourceUtilization과 TotalResourceUtilization의 차이는 무엇인가요?

작업자의 런타임 지속 시간이 60초 미만인 경우 BilledResourceUtilization은 이를 60초로 계산하고 TotalResourceUtilization은 이를 초 단위로 반올림합니다. 또한 BilledResourceUtilization에서는 20GB의 무료 스토리지가 계산에서 제외됩니다.

Q: 애플리케이션이란 무엇이고 어떻게 생성합니까?

Amazon EMR Serverless에서는 오픈 소스 분석 프레임워크를 사용하는 하나 이상의 EMR Serverless 애플리케이션을 생성할 수 있습니다. 애플리케이션을 생성하려면 다음 속성을 지정해야 합니다. 1) 사용하려는 오픈 소스 프레임워크 버전에 대한 Amazon EMR 릴리스 버전 2) Apache Spark 3.1 또는 Apache Hive 3.0 등 애플리케이션에서 사용하려는 특정 분석 엔진 애플리케이션을 생성한 후에는 데이터 처리 작업을 실행하거나 애플리케이션에 대한 대화형 요청을 시작할 수 있습니다.

Q: 작업자란 무엇입니까?

EMR Serverless 애플리케이션은 내부에서 작업자를 사용하여 워크로드를 실행합니다. 작업이 제출되면 EMR Serverless가 작업에 필요한 리소스를 계산하고 작업자를 예약합니다. EMR Serverless는 워크로드를 태스크로 분할하고, 오픈 소스 프레임워크로 작업자를 프로비저닝 및 설정한 다음, 작업이 완료되면 작업자를 해제합니다. EMR Serverless는 작업의 모든 수준에서 필요한 워크로드와 병렬 처리에 따라 작업자를 자동으로 확장하거나 축소합니다. 따라서 워크로드를 실행하는 데 필요한 작업자 수를 예측할 필요가 없습니다. 이 작업자의 기본 크기는 애플리케이션 유형과 Amazon EMR 릴리스 버전에 따라 다릅니다. 작업 실행을 예약할 때 이 크기를 재정의할 수 있습니다.

Q: 내 작업에서 사용할 수 있는 최소 및 최대 작업자 수를 지정할 수 있습니까?

EMR Serverless를 사용하는 경우 최소 및 최대 동시 작업자 수와 작업자의 vCPU 및 메모리 구성을 지정할 수 있습니다. 또한 애플리케이션의 리소스에 대한 최대 용량 제한을 설정하여 비용을 제어할 수 있습니다.

Q: 애플리케이션을 여러 개 생성해야 하는 경우는 언제입니까?

다음을 수행할 때는 애플리케이션을 여러 개 생성하는 것이 좋을 수 있습니다.

1. 서로 다른 오픈 소스 프레임워크 사용
2. 여러 사용 사례에 서로 다른 버전의 오픈 소스 프레임워크 사용
3. 한 버전에서 다른 버전으로 업그레이드할 때 A/B 테스트 수행
4. 테스트 및 프로덕션 시나리오를 위한 개별 논리 환경 유지
5. 비용 제어 및 사용량 추적이 독립되어 있는 여러 팀에 개별 논리 환경 제공
6. 서로 다른 사업부 애플리케이션 분리

Q: EMR Serverless 애플리케이션을 생성한 후 기본 속성을 변경할 수 있습니까?

예. EMR Studio 또는 update-application API/CLI 호출을 사용하여 초기 용량, 최대 용량 제한 및 네트워크 구성과 같은 애플리케이션 속성을 수정할 수 있습니다.

Q: 사전 초기화된 작업자 풀을 사용하여 애플리케이션을 생성해야 하는 경우는 언제입니까?

작업자가 사전에 초기화되지 않은 EMR Serverless 애플리케이션은 필요한 리소스를 결정하고 프로비저닝하는 데 최대 120초가 걸립니다. EMR Serverless는 애플리케이션을 위한 대기 중인 작업자 풀을 생성하여 작업자를 초기화된 상태로 유지하고 몇 초 안에 응답할 수 있게 하는 선택적 기능을 제공합니다. 이 기능을 사전 초기화된 용량이라고 하며 애플리케이션의 initial-capacity 파라미터를 설정하여 각 애플리케이션에 대해 구성할 수 있습니다.

사전 초기화된 용량을 사용하면 작업을 즉시 시작할 수 있으므로 시간에 민감한 작업을 구현하는 데 적합합니다. EMR Serverless 애플리케이션을 시작할 때 사전 초기화하려는 작업자 수를 지정할 수 있습니다. 그런 다음 사용자가 작업을 제출하면 사전 초기화된 작업자를 사용하여 작업을 즉시 시작할 수 있습니다. 사전 초기화에 선택된 작업자보다 많은 작업자가 작업에 필요한 경우 EMR Serverless가 자동으로 작업자를 추가합니다(지정된 최대 동시 작업자 제한까지). 작업이 완료되면 EMR Serverless가 지정된 사전 초기화 작업자 수로 돌아가 해당 수를 다시 유지합니다. 15분간 유휴 상태인 작업자는 자동으로 종료됩니다. 애플리케이션의 기본 유휴 시간 초과는 updateApplication API 또는 EMR Studio를 사용하여 변경할 수 있습니다.

Q: EMR Serverless에서 작업을 제출하고 관리하려면 어떻게 해야 합니까?

EMR Studio, SDK/CLI 또는 Apache Airflow 커넥터를 사용하여 EMR Serverless 작업을 제출하고 관리할 수 있습니다.

Q: EMR Serverless에서 실행하려는 작업에 종속성을 포함하려면 어떻게 해야 합니까?

PySpark의 경우 virtualenv를 사용하여 Python 종속성을 패키지로 만들고 작업 실행 중에 작업자에서 종속성을 사용할 수 있도록 하는 --archives 옵션을 사용하여 아카이브 파일을 전달할 수 있습니다. Scala 또는 Java의 경우 종속성을 jar 패키지로 만들고 Amazon S3에 업로드한 다음 EMR Serverless 작업 실행에서 --jars 또는 --packages 옵션을 사용하여 전달하면 됩니다.

Q: EMR Serverless Spark 및 Hive 애플리케이션은 사용자 정의 함수(UDF)를 지원합니까?

EMR Serverless는 Java 기반 UDF를 지원합니다. jar 패키지로 만들고 S3에 업로드한 다음 Spark 또는 HiveQL 스크립트에서 사용할 수 있습니다.

Q: EMR Serverless는 어떤 작업자 구성을 지원합니까?

자세한 내용은 지원되는 작업자 구성을 참조하세요.

Q: 예상보다 오래 실행되는 EMR Serverless 작업을 취소할 수 있습니까?

예. EMR Studio를 사용하거나 cancelJobRun API/CLI를 호출하여 실행 중인 EMR Serverless 작업을 취소할 수 있습니다.

Q: 작업자에 추가 스토리지를 추가할 수 있나요?

작업 제출 시 적절한 스토리지 옵션을 선택하여 EMR Serverless의 작업자에게 추가 스토리지를 추가할 수 있습니다. EMR Serverless는 두 가지 임시 스토리지 옵션을 제공합니다.

• 표준 스토리지: 이 옵션을 선택하면 기본적으로 작업자당 20GB의 임시 스토리지가 제공됩니다. 작업 제출 시 이를 사용자 정의하여 작업자당 20GB에서 최대 200GB까지 스토리지 용량을 늘릴 수 있습니다.
• 셔플에 최적화된 디스크 스토리지: 이 옵션을 선택하면 작업자당 최대 2TB의 임시 스토리지가 제공되며, 셔플을 많이 사용하는 워크로드에 최적화되어 있습니다.

Q: 코드 샘플은 어디에서 찾을 수 있나요?

EMR Serverless 코드 샘플은 GitHub 리포지토리에서 찾을 수 있습니다.

Q: EMR 서버리스에서 사용할 수 있는 작업자 옵션에는 어떤 것이 있습니까?

EMR 서버리스는 작업자에게 온디맨드 작업자와 사전 초기화된 작업자라는 두 가지 옵션을 제공합니다.

온디맨드 작업자는 작업에 필요한 경우에만 시작되고 작업이 완료되면 자동으로 릴리스됩니다. 이렇게 하면 사용한 리소스에 대해서만 비용을 지불하고 유휴 용량에 따른 추가 비용을 피할 수 있습니다. 온디맨드 작업자는 워크로드에 따라 애플리케이션을 확장하거나 축소하므로 리소스의 오버 또는 언더프로비저닝에 대해 걱정할 필요가 없습니다.

사전 초기화된 작업자는 작업자가 몇 초 만에 응답할 준비가 되도록 할 수 있는 선택적 기능입니다. 이렇게 하면 애플리케이션을 위한 작업자 웜 풀을 효과적으로 생성할 수 있습니다. 이를 통해 작업을 즉시 시작할 수 있으므로 반복적인 애플리케이션과 시간에 민감한 작업에 이상적입니다.

Q: 여러 가용 영역(AZ)에서 EMR 서버리스 애플리케이션을 구성할 수 있나요?

네. 여러 AZ에서 EMR 서버리스 애플리케이션을 구성할 수 있습니다. 여러 AZ를 설정하는 프로세스는 사용하는 작업자 유형에 따라 달라집니다.

온디맨드 작업자만 사용하는 경우 EMR Serverless는 기본적으로 여러 AZ에 작업을 분산하지만 각 작업은 하나의 AZ에서만 실행됩니다. 서브넷을 AZ에 연결하여 사용할 AZ를 선택할 수 있습니다. AZ에 장애가 발생하면 EMR 서버리스는 자동으로 다른 정상 AZ에서 작업을 실행합니다.

사전 초기화된 작업자를 사용하는 경우 EMR 서버리스는 지정한 서브넷에서 정상 AZ를 선택합니다. 채용공고는 신청을 중단할 때까지 해당 AZ에서 제출됩니다. AZ가 손상되면 애플리케이션을 다시 시작하여 다른 정상 AZ로 전환할 수 있습니다.

Q: 다른 리전의 데이터 스토어에 연결할 수 있나요?

EMR 서버리스는 VPC 연결 없이 구성된 경우 동일한 리전의 특정 AWS 리소스에만 액세스할 수 있습니다. 고려 사항을 참조하세요. 다른 리전 또는 AWS 외 리소스의 AWS 리소스에 액세스하려면 AWS 리소스의 퍼블릭 엔드포인트로 라우팅할 VPC 액세스와 NAT 게이트웨이를 설정해야 합니다.

Q: Amazon EMR Serverless 애플리케이션 및 작업 실행을 모니터링하려면 어떻게 해야 합니까?

Amazon EMR Serverless 애플리케이션과 작업 수준 지표는 30초마다 Amazon CloudWatch에 게시됩니다.

Q: EMR Serverless에서 Spark UI 및 Tez UI를 시작하려면 어떻게 해야 합니까?

EMR Studio에서 실행 중이거나 완료된 EMR Serverless 작업을 선택한 다음 Spark UI 또는 Tez UI 버튼을 클릭하여 시작할 수 있습니다.

Q: Amazon Virtual Private Cloud(VPC)의 리소스에 액세스할 수 있습니까?

예. 자체 VPC의 리소스에 액세스하도록 Amazon EMR Serverless 애플리케이션을 구성할 수 있습니다. 자세히 알아보려면 설명서에서 VPC 액세스 구성 섹션을 참조하세요. 

Q: EMR Serverless 애플리케이션에서 사용할 수 있는 분리의 종류는 무엇입니까?

각 EMR Serverless 애플리케이션은 다른 애플리케이션과 격리되어 보안 Amazon VPC에서 실행됩니다.

Q: Amazon EMR Serverless 서비스 할당량에서 변경된 사항은 무엇인가요?
Amazon EMR Serverless는 계정당 최대 동시 vCPU라고 하는 새로운 서비스 할당량을 도입했습니다. 이 vCPU 기반 할당량을 통해 애플리케이션이 리전 내에서 스케일 업할 수 있는 최대 집계 vCPU 수를 설정할 수 있습니다. 기존 애플리케이션 수준의 작업자 기반 할당량(최대 활성 작업자 수)은 2023년 2월 1일에 지원이 종료됩니다.

Q: 계정의 vCPU 할당량은 어디에서 보고 관리할 수 있나요?
AWS Service Quotas 관리 콘솔에서 할당량을 보고 관리하며 할당량 증가를 요청할 수 있습니다. 자세한 내용은 Service Quota 사용 설명서에서 Requesting a Quota Increase(할당량 증가 요청)를 참조하세요.

Q: 계정 수준 vCPU 할당량과 애플리케이션 수준 maximumCapacity 속성 사이의 차이점은 무엇인가요?
EMR Serverless에서는 두 가지 비용 제어 수단을 제공합니다. 1. 계정당 최대 동시 vCPU 할당량은 계정의 리전 내 모든 EMR Serverless 애플리케이션에 적용됩니다. 2. maximumCapacity 파라미터는 특정 EMR Serverless 애플리케이션의 vCPU를 제한합니다. 리전 내 모든 애플리케이션에서 사용하는 최대 동시 vCPU를 제한하려면 vCPU 기반 할당량을 사용하고, 특정 애플리케이션에서 사용하는 리소스를 제한하려면 maximumCapacity 속성을 사용해야 합니다. 예를 들어, 5개의 애플리케이션이 있고 각 애플리케이션이 최대 1,000개의 vCPU로 스케일 업이 가능한 경우 각 애플리케이션에 대해 maximumCapacity 속성을 1,000개의 vCPU로 설정하고 계정 수준 vCPU 기반 할당량은 5 * 1,000 = 5,000개의 vCPU로 구성합니다.

Q: vCPU 기반 계정 할당량에 도달하면 어떻게 알 수 있나요?
계정 수준 vCPU 할당량을 초과하는 경우 EMR Serverless는 새 용량의 프로비저닝을 중지합니다. 할당량을 초과한 후에 새 애플리케이션을 생성하려고 하면 다음 오류 메시지가 나타나며 애플리케이션 생성에 실패합니다. "Application failed to create as you have exceeded the maximum concurrent vCPUs per account service quota. You can view and manage your service quota using AWS Service Quotas console.(계정당 최대 동시 vCPU 서비스 할당량을 초과했으므로 애플리케이션을 생성하지 못합니다. AWS Service Quotas 콘솔을 사용하여 서비스 할당량을 보고 관리할 수 있습니다.)" 할당량을 초과한 후 새 작업을 제출하면 다음 오류 메시지가 나타나며 작업에 실패합니다. "Job failed as you have exceeded the maximum concurrent vCPUs per account service quota. You can view and manage your service quota using AWS Service Quotas console.(계정당 최대 동시 vCPU 서비스 할당량을 초과했으므로 작업에 실패합니다. AWS Service Quotas 콘솔을 사용하여 서비스 할당량을 보고 관리할 수 있습니다.)" 자세한 내용은 설명서를 참조하세요.

Q: Amazon EMR Serverless는 빅 데이터 배포의 비용을 절감하는 데 어떤 도움이 됩니까?

Amazon EMR Serverless 3가지 면에서 비용을 절감하는 데 도움이 될 수 있습니다. 첫째, 클러스터 관리, 보호 및 확장으로 인한 운영 간접비가 없습니다. 둘째, EMR Serverless는 작업 처리의 각 단계에서 자동으로 작업자를 확장하고 필요하지 않을 때 자동으로 축소합니다. 작업자 실행이 시작될 때부터 중지될 때까지 사용된 총 vCPU, 메모리 및 스토리지 리소스에 대해 요금이 부과되며 최소 1분 단위로 가장 가까운 초로 반올림됩니다. 예를 들어 작업을 처리하는 처음 10분 동안에는 작업자 10개가 필요하고 다음 5분간은 작업자 50개가 필요할 수 있습니다. 이 경우 세분화된 자동 크기 조정을 통해 10분간 작업자 10개와 5분간 작업자 50개에 대한 요금만 발생합니다. 따라서 미활용 리소스에 대한 요금을 지불하지 않아도 됩니다. 셋째, EMR Serverless에는 Apache Spark 및 Apache Hive와 Presto를 위한 Amazon EMR 성능 최적화 런타임이 포함됩니다. Amazon EMR 런타임은 API 호환되고 표준 오픈 소스 분석 엔진보다 최대 2배 이상 더 빠르기 때문에 작업이 더 빠르게 실행되고 컴퓨팅 요금은 줄어듭니다.

Q: EMR Serverless의 비용은 EC2 스팟 인스턴스 기반 Amazon EMR의 비용과 비슷합니까?

현재 EC2 기반 EMR 클러스터의 사용률에 따라 다릅니다. EC2 온디맨드 인스턴스를 사용하여 EMR 클러스터를 실행하는 경우 현재 클러스터 사용률이 70% 미만이면 EMR Serverless의 총 소유 비용(TCO)이 더 낮습니다. EC2 Savings Plans를 사용하는 경우 현재 클러스터 사용률이 50% 미만이면 EMR Serverless의 TCO가 더 낮습니다. EC2 스팟 인스턴스를 사용하는 경우 EC2 기반 Amazon EMR 및 EKS 기반 Amazon EMR이 지속적으로 더 비용 효율적입니다.

Q: 사전 초기화된 작업자 요금은 작업 실행이 완료된 후에도 부과됩니까?

예. 작업이 완료된 후 작업자를 중지하지 않으면 사전 초기화된 작업자에 대한 요금이 발생합니다.

Q: 질문, 의견 및 기능 요청이 있는 경우 어디로 문의해야 합니까?

EMR Serverless에 대한 질문과 유용한 피드백이 있는 경우 emr-feedback@amazon.com으로 이메일을 보내주세요.

Q: Amazon EKS 기반 Amazon EMR은 무엇인가요?
Amazon EKS 기반 Amazon EMR은 Amazon EMR의 배포 버전으로 고객이 쉽고 비용 효과적으로 대량 데이터를 처리하게 해줍니다. 컨테이너 내에서 서비스를 관리하며, Amazon Elastic Compute Cloud (Amazon EC2), AWS Fargate, 및 Amazon Simple Storage Service (Amazon S3)의 웹스케일 인프라를 갖춘 호스팅된 분석 프레임워크를 사용합니다.

Q: Amazon EKS 기반 Amazon EMR를 왜 사용해야 하나요?
Amazon EKS 기반 Amazon EMR은 컨테이너 기반 접근을 사용하여 작업을 처리하는 서비스와 인프라에서 분석 작업을 분리합니다. EKS 기반 EMR은 작업의 컴퓨팅, 메모리 및 애플리케이션 종속성을 기반으로 인프라를 동적 구성하여 애플리케이션 개발에 보다 집중하고 인프라 운영에 더 집중할 수 있습니다. 인프라 팀은 공동 컴퓨팅 플랫폼을 중심으로 관리하여 EMR 워크로드를 기타 컨테이너 기반 애플리케이션과 통합합니다. 복수의 팀, 조직, 또는 비즈니스 유닛은 Amazon EKS 및 AWS Identity and Access Management (IAM)로 활성화한 격리를 유지하는 동안 공유 인프라 상의 분석 프로세스를 동시 또는 독립적으로 수행할 수 있습니다.

Q: Amazon EKS 기반 Apache Spark를 이미 실행한 사용자의 이익은 무엇인가요?
이미 Apache Spark를 Amazon EKS 상에서 실행한다면 자동 프로비저닝 및 스케일링, 오픈소스 빅데이터 분석 프레임워크의 최신 완전 관리형 버전 사용 능력 등 Amazon EMR의 모든 이익을 얻을 수 있습니다. 오픈소스 Apache Spark on EKS보다 3배 빠른 성능의 EMR runtime for Apache Spark를 최적화하였습니다. 이것은 EMR Studio 및 Apache Spark UI, 정밀하게 나눈 데이터 액세스 제어 및 데이터 암호화에 대한 지원을 갖춘 서버리스 데이터 사이언스 경험입니다.

Q: 이 기능은 어떻게 기타 AWS services에 관련되었으며 이와 협업하나요?
Amazon EKS는 고객에게 AWS 기반 Kubernetes를 실행하기 위한 관리된 경험을 제공합니다. 이 경험은 EKS 관리 노드 그룹 및 AWS Fargate를 사용하여 컴퓨팅 용량을 추가할 수 있습니다. EKS 기반 EMR 작업 실행은 Amazon S3 상의 데이터에 액세스할 수 있는 반면 모니터링 및 로깅은 Amazon CloudWatch에 통합할 수 있습니다. AWS Identity and Access Management (IAM)은 작업 간 역할 기반 액세스 제어를 활성화하며 AWS 서비스에 의존적입니다.

Q: Amazon EKS 기반 Amazon EMR은 어떻게 작동합니까?
시작하려면 먼저 Amazon EMR에 EKS 클러스터를 등록하세요. 그리고 CLI, SDK 또는 EMR Studio를 사용하여 Sparak 작업을 EMR에 제출합니다. EMR은 EKS 기반 Kubernetes scheduler에 요청하여 Pods의 일정을 정합니다. 실행하는 각 작업에 대해 EKS 기반 EMR은 컨테이너를 생성합니다. 컨테이너는 보안 업데이트를 한 Amazon Linux 2 기본 이미지와 추가로 Apache Spark, 그리고 Spark를 실행하기 위한 관련 의존성, 그리고 사용자 애플리케이션 지정 의존성을 포함합니다. 각 작업을 팟에서 실행합니다. Pod은 이 컨테이너를 다운로드하여 실행을 시작합니다. 컨테이너 이미지를 노드에 사전 배포하면, 캐시 이미지를 사용하고 다운로드를 우회합니다. 로그 또는 지표 포워더 등의 사이드카 컨테이너를 포드에 배포할 수 있습니다. 포드는 작업이 종료된 다음 종료됩니다. 작업을 종료한 다음에도 여전히 Spark UI를 사용하여 디버그할 수 있습니다.

Q: EKS 종속 Amazon EMR을 통해 사용할 수 있는 AWS 컴퓨팅 서비스는 무엇입니까?
광범위한 사용자 지정 옵션을 제공하는 Amazon Elastic Compute Cloud(EC2) 인스턴스 또는 EC2 인스턴스를 프로비저닝 또는 관리할 필요 없이 분석을 처리하는 서버리스 AWS Fargate 서비스를 갖춘 Amazon EMR for EKS를 제공합니다. 애플리케이션 가용성은 분석 작업을 복수의 AWS Availability Zones (AZs)에 퍼트리면 자동으로 향상됩니다.

Q: EKS 기반 EMR을 시작하려면 어떻게 해야 합니까?
시작하려면 먼저 Amazon EMR에 Amazon EKS 클러스터를 등록하세요. 등록 후 실행을 위해 워크로드를 EMR에 제출하여 작업 정의 내 이 등록 (애플리케이션 의존성 및 프레임워크 파라미터 포함)을 참조합니다. EKS 기반 EMR을 통해 동일 EKS 클러스터에서 실행하는 분석 애플리케이션에 대한 다른 오픈 소스 빅데이터 분석 프레임워크, 버전 및 구성을 사용할 수 있습니다. 자세한 내용은 설명서를 참조하십시오.

Q: EMR 클러스터 및 EKS에서 실행한 애플리케이션에 대해 동일 EMR을 사용할 수 있나요?

예, EMR 클러스터 상에 실행한 애플리케이션 용 동일 EMR 릴리스 및 EKS로 실행하는 애플리케이션을 사용합니다.

Q: 분석 애플리케이션의 문제를 해결하려면 어떻게 해야 합니까?
Amazon EMR Spark UI를 사용하여 Spark 애플리케이션을 진단하고 문제를 해결할 수 있습니다. 모든 분석 애플리케이션을 위해 EMR은 애플리케이션 상세 정보, 관련 로그 및 지표에 대한 액세스를 완료 최대 30일 동안 제공합니다. 작업은 개별적으로 구성하여 Amazon S3 위치 또는 Amazon CloudWatch로 로그를 보낼 수 있습니다.

Q: EKS 내 EMR 애플리케이션을 볼 수 있나요?
예, EMR 애플리케이션은 EKS 콘솔에 Kubernetes 작업 및 배포로 나타납니다.

Q: 동일 EKS 클러스터 상의 각자 다른 요소로부터 복수의 작업 및 지원서를 격리해도 되나요?
예, Kubernetes는 자연스럽게 작업 격리를 제공합니다. 추가로 각 작업은 실행 역할을 실행하여 구성할 수 있으며, 직업이 액세스할 수 있는 AWS 리소스는 제한됩니다.

Q: EKS 상의 EMR는 비용 절감을 지원하나요?
EKS 기반 EMR은 필요를 제거하여 비용을 줄여 전용 클러스터를 실행합니다. 일반적이거나 공유된 공유 EKS 클러스터를 사용하여 오픈소스 빅데이터 분석 프레임워크를 필요로 하는 다른 버전이 필요합니다. 동일한 EKS 클러스터를 사용하여 다른 컨테이너형 비EMR 응용 프로그램을 실행할 수도 있습니다.

Q: EKS 기반 EMR에 어떻게 비용을 지불하나요?
Amazon EKS 구현 EMR 비용은 vCPU와, 작업을 실행하는 팟에서 요청한 메모리 리소스에 기반하여 분 당 입상으로 계산합니다. 요금 정보는 Amazon EMR 요금 페이지를 참조하세요.

Q: EKS 기반 EMR 및 EC2 기반 EMR 간의 차이는 무엇입니까?

Q: AWS Outposts는 무엇입니까?

AWS Outposts는 네이티브 AWS 서비스, 인프라 및 운영 모델을 사실상 모든 데이터 센터, 코로케이션 공간 또는 온프레미스 시설로 옮길 수 있습니다. EMR on Outposts를 사용하면 클라우드와 마찬가지로 온프레미스에서도 EMR 클러스터를 배포, 관리 및 조정할 수 있습니다.

Outposts 기반 EMR은 언제 사용해야 합니까?

기존 온프레미스에 Apache 하둡 배포를 보유하고 있고 피크 사용 기간에 용량 요구 사항을 충족하는 데 문제가 있는 경우, Outposts 기반 EMR을 사용하여 데이터를 클라우드로 이동할 필요 없이 처리 용량을 개선할 수 있습니다. Outposts 기반 EMR을 통해 온프레미스에 새 EMR 클러스터를 몇 분 안에 시작하고 온프레미스 HDFS 스토리지의 기존 데이터 세트에 연결하여 이 요구 사항을 충족하고 SLA를 유지할 수 있습니다

거버넌스, 규정 준수 또는 기타 사유로 인해 온프레미스에서 보관해야 하는 데이터를 처리해야 하는 경우 Outposts 기반 EMR을 사용하여 온프레미스(데이터에 근접)에서 Apache 하둡 및 Apache Spark와 같은 애플리케이션을 배포하고 실행할 수 있습니다. 그러면 많은 양의 온프레미스 데이터를 클라우드로 이전할 필요성이 줄어들기 때문에 해당 데이터를 처리하는 데 필요한 전반적인 시간도 줄어듭니다.

데이터 및 Apache 하둡 워크로드를 클라우드로 마이그레이션하는 프로세스를 진행하고 있으며, 마이그레이션을 완료하기 전에 EMR 사용을 시작하려면 AWS Outposts를 사용하여 기존 온프레미스 HDFS 스토리지에 연결된 EMR 클러스터를 시작할 수 있습니다. 그러면 클라우드 아키텍처로 진화하는 과정에서 Amazon S3로 데이터를 점진적으로 마이그레이션할 수 있습니다.

Q: Outposts 기반 EMR에서는 어떤 EMR 릴리스 버전을 지원합니까?

최소 지원되는 Amazon EMR 릴리스는 5.28.0입니다.

Q: Outposts를 사용하는 경우 어떤 EMR 애플리케이션을 사용할 수 있습니까?

EMR 릴리스 5.28.0 이상에서 모든 애플리케이션이 지원됩니다. 전체 EMR 애플리케이션 목록을 보려면 릴리스 노트를 확인하십시오.

Q: Outposts 기반 EMR에서 지원하지 않는 EMR 기능은 무엇입니까?

• EC2 스팟 인스턴스는 AWS Outposts에서 사용할 수 없습니다. 클러스터를 생성할 때 EC2 온디맨드 인스턴스를 선택해야 합니다.
• EC2 인스턴스 유형의 서브 세트는 AWS Outposts에서 사용할 수 있습니다. EMR 및 Outposts에서 지원되는 인스턴스 유형의 전체 목록은 AWS의 설명서를 확인하십시오.
• Amazon EBS 볼륨을 인스턴스에 추가할 때 범용 SSD(GP2) 스토리지 유형만 AWS Outposts에서 지원됩니다.

Q: Outpost에서 EMR 클러스터를 사용하여 기존 온프레미스 Apache 하둡 클러스터의 데이터를 읽을 수 있습니까?

Outpost의 EMR에서 실행 중인 워크로드는 기존 HDFS 스토리지의 데이터를 읽고 쓸 수 있어 기존 온프레미스 Apache 하둡 배포와 쉽게 통합할 수 있습니다. 이를 통해 데이터를 마이그레이션할 필요 없이 EMR을 사용하여 데이터 처리 요구 사항을 개선합니다.

Q: 데이터 저장 위치를 선택할 수 있습니까?

EMR 클러스터를 Outpost에서 시작하면 모든 컴퓨팅 및 데이터 스토리지 리소스는 Outpost에 배포됩니다. EMR 클러스터에 로컬로 작성된 데이터는 Outpost의 로컬 EBS 볼륨에 저장됩니다. Apache Hive, Apache Spark, Presto 및 기타 EMR 애플리케이션과 같은 도구는 Outpost, 기존 HDFS 설치와 같은 외부 파일 시스템 또는 Amazon S3에 로컬로 데이터를 작성하도록 구성되었습니다. Outposts 기반 EMR을 사용하면 Amazon S3 또는 Outpost의 로컬 데이터 저장을 완전하게 제어할 수 있습니다.

Q: EMR 기능은 S3에 데이터를 업로드해야 합니까?

Outpost에서 EMR 클러스터를 시작하면 로깅을 활성화하는 옵션이 있습니다. 로깅이 활성화되면 클러스터 로그는 지정한 S3 버킷에 업로드됩니다. 이 로그를 통해 클러스터가 종료된 후 클러스터의 디버깅을 간편하게 수행합니다. 비활성화하면 어떠한 로그도 S3로 업로드되지 않습니다.

Q: Outpost의 용량이 초과되면 어떻게 됩니까?

Outpost에서 클러스터를 시작할 때 EMR은 요청한 EC2 온디맨드 인스턴스의 수와 유형을 시작하려고 시도합니다. Outpost에 사용 가능한 용량이 없으면 EMR은 용량 부족 알림을 수신합니다. EMR은 일정 기간 동안 재시도하고 사용 가능한 용량이 없으면 클러스터는 시작하지 못합니다. 동일한 프로세스가 클러스터 크기를 재조정할 때도 적용됩니다. 요청된 인스턴스 유형에 대해 Outpost의 용량이 부족하면 EMR은 클러스터를 확장할 수 없습니다. 간편하게 Amazon CloudWatch 알림을 설정하여 Outposts의 용량 사용률을 모니터링하고 원하는 임계값보다 인스턴스 용량이 적은 경우 알림을 수신할 수 있습니다.

Q: Outpost와 AWS 간에 네트워크 연결이 중단되면 어떻게 됩니까?

Outpost와 AWS 리전 간에 네트워크 연결이 중단되더라도 Outposts의 클러스터는 계속 실행되지만 연결이 복원될 때까지 작업은 수행할 수 없습니다. 연결이 복원될 때까지 새 클러스터를 생성하거나 기존 클러스터에서 작업을 수행할 수 없습니다. 인스턴스에 장애가 발생한 경우 인스턴스는 자동으로 교체되지 않습니다. 또한 실행 중인 클러스터에 단계 추가, 단계 실행 상태 확인, CloudWatch 지표 및 이벤트 전송 같은 작업은 연결이 복원될 때까지 지연됩니다.

Outpost와 AWS 리전 간에 안정적이고 가용성 높은 네트워크 연결을 제공할 것을 권장합니다. Outpost와 AWS 리전 간에 네트워크 연결이 몇 시간 이상 중단되면 종료 방지 기능이 활성화된 클러스터는 계속 실행되지만 종료 방지 기능이 비활성화된 클러스트는 중단될 수 있습니다. 네트워크 연결이 일상적인 유지보수로 인해 영향 받을 경우 종료 방지 기능을 사전에 활성화할 것을 권장합니다.

Q: 이전에는 할 수 없었던 작업 중 이제 수행할 수 있는 작업은 무엇입니까?

대부분 EC2 인스턴스에는 인스턴스에 부착된 고정 스토리지 용량이 있으며 이를 "인스턴스 스토어"라고 부릅니다. 이제 Amazon EMR 클러스터의 인스턴스에 EBS 볼륨을 추가함으로써 인스턴스 스토리지를 사용자 정의할 수 있습니다. 이 기능을 사용하면 M4 및 C4와 같은 EBS 전용 인스턴스 패밀리에서 Amazon EMR 클러스터를 실행할 수 있습니다.

Q: Amazon EMR에서 실행되는 인스턴스에 EBS 볼륨을 추가하면 어떤 이점이 있습니까?

다음과 같은 시나리오에서 인스턴스에 EBS 볼륨을 추가하면 이점을 활용할 수 있습니다.

1. 처리를 위해서는 현재 인스턴스에서 제공하는 대용량 HDFS(또는 로컬) 스토리지가 필요한 경우입니다. EBS 볼륨이 지원되면, 인스턴스가 제공하는 컴퓨팅 파워와 비례하여 인스턴스의 스토리지 용량을 사용자 정의할 수 있습니다. 인스턴스의 스토리지를 최적화함으로써 비용을 절감할 수 있습니다.
2. 예전 세대 인스턴스 패밀리(M1 및 M2 패밀리 등)를 실행하고 있으며 최신 세대 인스턴스 패밀리로 전환하려고 하지만, 차세대 인스턴스 유형의 노드당 스토리지 가용성으로 인해 제약을 받는 경우입니다. 이제 새로운 세대 인스턴스 유형을 모두 사용하고 EBS 볼륨을 추가하여 스토리지를 최적화할 수 있습니다. 내부 벤치마크 결과는 이전 세대 인스턴스 패밀리(M1 또는 M2)에서 새로운 세대 인스턴스(M4, C4 및 R3)로 전환하면 비용을 절감하고 성능을 향상할 수 있음을 보여줍니다. Amazon EMR 팀은 적절한 결론에 도달하도록 애플리케이션을 실행하기를 권장합니다.
3. 차세대 EBS 전용 M4 및 C4 패밀리로 마이그레이션하거나 이를 사용하고자 하는 경우입니다.

Q: 클러스터가 종료된 후에도 EBS 볼륨에 데이터를 유지할 수 있습니까?

현재는 클러스터가 종료되면 Amazon EMR에서 볼륨을 삭제합니다. 클러스터의 수명 주기와 관계없이 데이터를 유지하려는 경우, Amazon S3를 데이터 스토어로 사용하는 것이 좋습니다.

Q: 어떤 종류의 EBS 볼륨을 인스턴스에 부착할 수 있습니까?

Amazon EMR에서는 범용 SSD(GP2), 마그네틱 및 프로비저닝된 IOPS(SSD)와 같은 다양한 EBS 볼륨 유형을 사용할 수 있습니다.

Q: 클러스터를 종료하면 EBS 볼륨은 어떻게 됩니까?

EMR 클러스터가 종료되면 Amazon EMR에서 볼륨을 삭제합니다.

Q: 이미 인스턴스 스토어가 있는 인스턴스에 EBS를 사용할 수 있습니까?

예. 이미 인스턴스 스토어가 있는 인스턴스에 EBS 볼륨을 추가할 수 있습니다.

Q: 실행 중인 클러스터에 EBS 볼륨을 부착할 수 있습니까?

아니요. 현재는 클러스터를 시작할 때만 EBS 볼륨을 추가할 수 있습니다.

Q: 클러스터의 볼륨으로 스냅샷을 생성할 수 있습니까?

EBS API를 사용하면 클러스터의 스냅샷을 생성할 수 있습니다. 하지만 현재 Amazon EMR은 스냅샷에서 복원하는 것을 허용하지 않습니다.

Q: 암호화된 EBS 볼륨을 사용할 수 있습니까?

EBS 루팅 디바이스 및 저장소 볼륨을 AWS KMS를 핵심 제공자로 사용할 수 있습니다. 더 많은 정보는 Local Disk Encryption을 암호화합니다.

Q: 부착된 볼륨을 실행 중인 클러스터에서 제거하면 어떻게 됩니까?

실행 중인 클러스터에서 부착된 볼륨을 제거하면 이는 노드 장애로 처리됩니다. Amazon EMR에서 동일한 노드와 EBS 볼륨으로 이를 교체하게 됩니다.

Q: Apache Spark란 무엇입니까?

Apache Spark^TM는 빅 데이터 워크로드에 사용되는 오픈 소스 분산 처리 시스템입니다. Apache Spark는 인 메모리 캐시 및 최적화된 쿼리 실행을 활용하여 모든 크기의 데이터에 대해 빠른 분석 쿼리를 실행합니다. Amazon EMR은 클라우드에서 Apache Spark를 구축하기 위한 최상의 서비스입니다. 상용 Spark 배포의 통합/테스트 성능을 클라우드의 규모, 단순성 및 비용 효율성과 결합하기 때문입니다. Amazon EMR을 활용하면 노드 프로비저닝, 클러스터 설정, Spark 구성 또는 클러스터 튜닝을 수행하지 않아도 단 몇 분 만에 Spark 클러스터를 시작할 수 있습니다. Amazon EMR runtime for Apache Spark을 발표하게 되어 기쁩니다. 이 런타임은 최적화된 성능의 Apache Spark용 런타임 환경으로, Amazon EMR 클러스터에서 사용할 수 있습니다. Amazon EMR runtime for Apache Spark은 EMR 런타임이 없는 클러스터보다 3배 이상 빠르며 표준 Apache Spark와 100% API 호환됩니다. Spark 및 Amazon EMR 기반 Spark에 대해 자세히 알아보세요.

Q: Presto란 무엇입니까?

Presto는 모든 크기의 데이터에 대해 빠른 분석 쿼리를 실행하기 위해 처음부터 모두 설계된 오픈 소스 분산 SQL 쿼리 엔진입니다. Amazon EMR을 활용하면 노드 프로비저닝, 클러스터 설정, Presto 구성 또는 클러스터 튜닝을 수행하지 않아도 단 몇 분 만에 Presto 클러스터를 시작할 수 있습니다. EMR에서는 컴퓨팅 인스턴스의 수에 상관없이 모두 단 몇 분 만에 프로비저닝할 수 있습니다. Presto에는 PrestoDB와 PrestoSQL라는 두 가지 커뮤니티 프로젝트가 있습니다. Amazon EMR은 두 프로젝트 모두를 지원합니다. Presto 및 Amazon EMR 기반 Presto에 대해 자세히 알아보세요.

Q: Apache Hive란 무엇입니까?

Hive는 오픈 소스 데이터 웨어하우스이자 하둡에서 실행되는 분석 패키지입니다. Hive는 Hive QL이라는 SQL 기반 언어로 작동합니다. 이에 따라 사용자는 Amazon S3에 저장된 데이터 소스를 구축, 요약 및 쿼리할 수 있습니다. Hive QL은 표준 SQL보다 많은 기능을 제공하며, map/reduce 함수와 Json 및 Thrift와 같은 복잡하고 확장 가능한 사용자 정의 데이터 유형에 최고의 지원을 제공합니다. 이 기능을 통해 텍스트 문서와 로그 파일 같은 복잡한 비정형 데이터 소스도 처리할 수 있습니다. Hive를 사용하면, Java로 작성되고 Amazon S3 스토리지를 통해 배포된 사용자 정의 함수를 사용하여 확장할 수 있습니다. 여기서 Apache Hive에 대해 자세히 알아볼 수 있습니다.

Q: Amazon EMR에서 실행되는 Hive로 어떤 작업을 할 수 있습니까?

Amazon EMR에서 Hive를 사용하면 Amazon EMR에서 사용할 수 있는 친숙한 유사 SQL 언어와 사용하기 쉬운 도구로 정교한 데이터 처리 애플리케이션을 구현할 수 있습니다. Amazon EMR을 사용하면 Hive 애플리케이션을 안정적인 데이터 웨어하우스로 바꾸어 데이터 분석, 모니터링, 비즈니스 인텔리전스 등의 작업을 수행할 수 있습니다.

Q: Hive는 기존의 RDBMS 시스템과 어떻게 다릅니까?

기존의 RDBMS 시스템은 트랜잭션 의미 체계와 ACID 속성을 제공합니다. 소량의 데이터를 매우 빠르게 검색할 수 있도록 테이블을 인덱싱 및 캐싱하고, 소량의 데이터를 빠르게 업데이트하며, 참조 무결성 제약 조건을 실행합니다. 일반적으로 기존의 RDBMS 시스템은 하나의 대형 컴퓨터에서 실행되며, map이나 reduce 함수의 실행을 지원하지 않습니다. 또한 일반적으로 복잡한 사용자 정의 데이터 유형을 지원하지 않습니다.

대조적으로, Hive는 MapReduce를 사용하여 유사 SQL 쿼리를 실행합니다. 결과적으로 시스템의 클러스터에서 실행되는 동안 전체 테이블을 검색하도록 최적화되었기 때문에 막대한 양의 데이터를 처리할 수 있습니다. Hive는 분할된 테이블을 제공하여 실행 중인 쿼리에 적합한 경우 전체 테이블이 아닌 테이블 일부를 검색할 수 있습니다.

기존의 RDMS 시스템은 트랜잭션 의미 체계와 참조 무결성이 필요하며 소소한 업데이트가 수시로 수행되는 경우에 가장 적합합니다. Hive는 대규모 데이터 세트의 오프라인 보고, 변환, 분석에 가장 적합합니다. 예를 들어 대규모 웹 사이트의 클릭 스트림 분석, 웹 사이트의 수집 등이 있습니다.

일반적인 사용법 중 하나로 RDBMS 시스템에서 Amazon S3로 데이터 내보내기가 있습니다. 이 경우 Hive를 실행하는 Amazon EMR 클러스터를 사용하여 오프라인 분석을 할 수 있습니다.

Q: Amazon EMR에서 실행되는 Hive를 시작하려면 어떻게 해야 합니까?

여기에 있는 설명서를 검토하는 것으로 시작하는 것이 가장 좋습니다.

Q: Amazon EMR 전용 Hive에 새로운 기능이 있습니까?

예. 자세한 내용은 설명서를 참조하세요.

• Apache Hive를 위해 사용할 수 있는 고가용성을 지원하기 위한 복수의 마스터 노드를 갖춘 EMR 클러스터를 시작하였습니다. Amazon EMR은 기본 마스터 노드에 장애가 발생하거나 Resource Manager 또는 Name Node 같은 중요 프로세스에 장애가 발생하는 경우 자동으로 예비 마스터 노드로 장애 조치됩니다. 즉 EMR 클러스터 기반 Apache Hive를 중단 없이 실행할 수 있습니다.
• Amazon EMR은 Apache Hive 클러스터용 EMR Managed Scaling을 정의하여 리소스 사용을 최적화하도록 지원합니다. EMR 관리형 스케일링을 통해 자동으로 클러스터의 사이즈를 조절하여 가능한 한 최저의 비용으로 최대 성능을 얻을 수 있습니다. EMR 관리형 스케일링을 통해 클러스터용 최저 및 최대 컴퓨팅 한도를 지정하고 Amazon EMR은 최고의 성능 및 리소스 이용을 위해 자동으로 클러스터의 사이즈를 조정합니다. EMR 관리형 스케일링은 지속적으로 클러스터에서 실행 중인 워크로드 관련 주요 지표를 샘플화합니다.
• Amazon EMR 6.0.0은 EMR 5.29에 대하여 평균 성능 속도를 2배 빠르게 하는 Hive LLAP에 대한 지원을 추가합니다. 자세한 내용은 여기를 참조하세요.
• Amazon EMR은 또한 복잡한 Apache Hive 쿼리에서 빠른 성능을 구현합니다. EMR은 Apache MapReduce보다 상당히 빠른 Apache Tez를 기본적으로 사용합니다. Apache MapReduce는 여러 단계를 사용하기에 복잡한 Apache Hive 쿼리는 4개 또는 5개의 작업으로 고장날 수 있습니다. Apache Tez는 보다 복잡한 쿼리를 위해 설계된 제품이기에 Apache Tez에서 동일한 작업은 하나의 작업으로 실행될 수 있어 Apache MapReduce보다 상당히 빨라집니다.
  
• Amazon EMR을 통해 로컬로 메타스토어를 떠나거나 이를 외부화할 수 있는 옵션을 가지게 됩니다. EMR은 AWS Glue Data Catalog, Amazon Aurora, Amazon RDS ㅁ;ㅊ AWS Lake Formation을 통해 통합을 제공합니다. Amazon EMR은 Glue 또는 Lake Formation에서 정보를 직접 얻어 메타스토어에서 증가시킵니다.
• Amazon S3에서 자동으로 테이블의 일부를 로딩할 수 있습니다. 이전에는 테이블 일부를 가져오려면 테이블 내의 개별 파티션에 대한 별도의 테이블 변환 문이 필요했습니다. Amazon EMR은 현재 Hive 언어에 대한 새로운 명령문 유형인 "alter table recover partitions" 를 지원합니다. 이 문을 사용하면 공유된 메타 데이터 스토리지를 관리할 필요 없이 손쉽게 테이블을 다수의 클러스터로 동시에 가져올 수 있습니다. 이 기능을 사용하여 어떤 외부 프로세스가 로그 파일과 같은 데이터를 보관하고 있는지 테이블에서 읽을 수 있습니다.
• Amazon S3에 데이터를 직접 작성할 수 있습니다. Amazon S3의 테이블에 데이터를 쓸 때, Amazon EMR에 설치된 Hive 버전은 임시 파일을 사용하지 않고 Amazon S3에 직접 씁니다. 이렇게 하면 성능이 크게 개선됩니다. 그러나 Hive 측면에서 보면 HDFS와 S3가 각기 다르게 동작하는 것을 의미합니다. 테이블이 Amazon S3에 있는 경우 동일한 테이블에 대해 동일한 문을 읽거나 쓸 수 없습니다. S3에 있는 테이블을 업데이트하려면 클러스터의 로컬 HDFS 파일 시스템에 임시 테이블을 생성하고 결과를 테이블에 쓴 다음 Amazon S3에 복사합니다.
• Amazon S3에 있는 리소스에 액세스할 수 있습니다. Amazon EMR에 설치된 버전의 Hive를 사용하여 사용자 정의 map 및 reduce 작업에 대한 스크립트 또는 Amazon S3에 있는 추가 라이브러리 같은 리소스를 Hive 스크립트에서 직접 참조할 수 있습니다(예: add jar s3://elasticmapreduce/samples/hive-ads/libs/jsonserde.jar).
  
  

Q: 어떤 유형의 Hive 클러스터를 지원합니까?

Hive는 두 가지 유형(대화형 및 배치)의 클러스터를 지원합니다. 대화형 모드에서는 고객이 클러스터를 시작하고, 마스터 노드에서 직접 대화형 Hive 스크립트를 실행할 수 있습니다. 일반적으로 이 모드는 임시 데이터 분석 및 애플리케이션 개발에 사용됩니다. 배치 모드에서는 Hive 스크립트를 Amazon S3에 저장하여 클러스터를 시작할 때 참조합니다. 일반적으로 배치 모드는 보고서 생성과 같은 반복 가능한 실행에 사용됩니다.

Q: Hive 클러스터를 시작하려면 어떻게 해야 합니까?

배치 클러스터 및 대화형 클러스터는 모두 AWS Management Console, EMR 명령줄 클라이언트 또는 API에서 시작할 수 있습니다. Hive 클러스터를 시작하는 방법에 대한 자세한 내용은 릴리스 안내서의 Hive 섹션을 참조하십시오.

Q: Hive와 PIG는 각각 언제 사용해야 합니까?

Hive와 PIG는 높은 수준의 데이터 처리 언어를 제공하고, 대규모 데이터 세트에서 실행되는 복잡한 데이터 유형을 지원합니다. Hive 언어는 SQL의 변형으로서, SQL과 관계형 데이터베이스에 이미 익숙한 사람에게 더 편리합니다. Hive는 분할된 테이블을 지원하므로, Amazon EMR 클러스터는 전체 테이블을 검색하는 것이 아니라 실행 중인 쿼리와 관련된 테이블 일부만 검색할 수 있습니다. PIG와 Hive는 둘 다 쿼리 계획 최적화 기능을 제공합니다. PIG는 전체 스크립트에서 쿼리를 최적화할 수 있지만 Hive는 문 수준에서 쿼리를 최적화합니다.

마지막으로, Hive 또는 PIG 중 어느 것을 선택할 것인지는 애플리케이션 도메인의 정확한 요구 사항 및 구현자나 쿼리 작성자가 선호하는 것을 고려하여 결정합니다.

Q: Amazon EMR은 어떤 버전의 Hive를 지원합니까?

Amazon EMR 기반 Hive의 최근 버전에 대해 더 자세한 정보를 알고 싶다면 설명서를 참조하세요.

Q: 두 클러스터에서 동시에 하나의 테이블에 쓰기 작업을 할 수 있습니까?

Hive는 테이블에 대한 동시 쓰기를 지원하지 않습니다. 동일한 테이블에 대한 동시 쓰기를 하거나 쓰기를 수행하는 테이블에서는 읽기 작업을 수행하지 마십시오. Hive는 동시에 읽기/쓰기를 하거나 동시에 쓰기/쓰기를 하면 비결정적인 동작을 합니다.

Q: 클러스터 간에 데이터를 공유할 수 있습니까?

예. 스크립트 상단에 'create external table' 문을 작성하여 Hive 스크립트에서 Amazon S3의 데이터를 읽을 수 있습니다. 액세스하는 각 외부 리소스에 대한 테이블 생성 문을 작성해야 합니다.

Q: 대규모 클러스터를 하나 실행하고 여러 사용자와 공유해야 합니까? 아니면 소규모 클러스터를 여러 개 실행해야 합니까?

Amazon EMR은 두 가지 방법을 모두 사용할 수 있도록 고유한 기능을 제공합니다. 하나의 대규모 클러스터는 정기적인 배치 워크로드를 처리하는 데 더욱 효율적일 수 있습니다. 반면에 임시 쿼리 또는 시간에 따라 다른 워크로드가 필요할 경우, Amazon S3에 저장된 데이터 소스를 공유하는 특정 작업에 맞게 조정된 몇 개의 클러스터를 별도로 생성할 수 있습니다. EMR 관리 스케일링을 사용하여 리소스 사용량을 최적화할 수 있습니다.

Q: 내 로컬 파일 시스템에 있는 스크립트 또는 jar 리소스에 액세스할 수 있습니까?

스크립트 또는 jar을 Amazon S3 또는 클러스터 마스터 노드에 업로드해야 참조할 수 있습니다. Amazon S3에 업로드하기 위해 s3cmd, jets3t 또는 S3Organizer 같은 도구를 사용할 수 있습니다.

Q: 여러 Hive 쿼리를 실행하는 영구 클러스터를 실행할 수 있습니까?

예. Hive 단계 사이에 종료되지 않도록 클러스터를 수동 종료 모드로 실행합니다. 데이터 손실의 위험을 줄이기 위해 Amazon S3에 있는 중요한 데이터를 정기적으로 관리하십시오. 정기적으로 작업을 새 클러스터로 전송하여 마스터 노드 장애 복구 프로세스를 테스트하는 것이 좋습니다.

Q: 동일한 소스 데이터에서 여러 사용자가 Hive 단계를 수행할 수 있습니까?

예. 별도의 클러스터에서 여러 사용자가 실행하는 Hive 스크립트에는 "create external table" 문이 포함되어 있으므로 Amazon S3에 있는 소스 데이터를 동시에 가져올 수 있습니다.

Q: 동일한 클러스터에서 여러 사용자가 쿼리를 실행할 수 있습니까?

예. 배치 모드에서는 단계가 순서로 구분되어 있습니다. 여러 사용자가 Hive 단계를 동일한 클러스터에 추가할 수 있습니다. 그러나 단계는 차례대로 실행됩니다. 대화형 모드에서는 여러 사용자가 동일한 클러스터에 로그온하고 Hive 명령문을 동시에 실행할 수 있습니다.

Q: 여러 AWS 사용자 간에 데이터를 공유할 수 있습니까?

예. 여기에 설명된 표준 Amazon S3 공유 메커니즘을 사용하여 데이터를 공유할 수 있습니다.

Q: Hive는 JDBC 액세스를 지원합니까?

예. Hive는 JDBC 드라이브를 제공합니다. 이 드라이브는 프로그래밍 방식으로 Hive 문을 실행하는 데 사용할 수 있습니다. 클러스터에서 JDBC 서비스를 시작하려면 Amazon EMR 명령줄 클라이언트에서 선택적 파라미터를 제공해야 합니다. 또한 보안 그룹에서 외부 연결을 허용하지 않으므로 SSH 터널을 설정해야 합니다.

Q: EMR AMI에서 패키지를 업데이트하려면 어떤 절차를 수행해야 합니까?

첫 번째 부팅 시 EMR용 Amazon Linux AMI는 Amazon Linux AMI Yum 저장소에 연결하여 보안 업데이트를 설치합니다. 사용자 지정 AMI를 사용할 때는 이 기능을 비활성화할 수 있지만 보안상의 이유로 이렇게 하지 않는 것이 좋습니다.

Q: EMR 클러스터에서 내 패키지를 업데이트할 수 있습니까?

예. 부트스트랩 작업을 사용하여 귀하의 클러스터에 있는 패키지에 대한 업데이트를 설치할 수 있습니다.

Q: Hive를 사용하여 DynamoDB 데이터를 처리할 수 있습니까?

예. DynamoDB 테이블을 기반으로 외부 Hive 테이블을 정의하면 됩니다. 그런 다음 Hive를 이용하여 DynamoDB에 저장된 데이터를 분석하고, 결과를 다시 DynamoDB에 로드하거나 Amazon S3에 저장할 수 있습니다. 자세한 내용은 개발자 안내서를 참조하십시오.

Q: Apache Hudi는 무엇입니까?

Apache Hudi는 증분 데이터 처리 및 데이터 파이프라인 개발을 간소화하는 데 사용되는 오픈 소스 데이터 관리 프레임워크입니다. Apache Hudi를 사용하면 Amazon S3의 레코드 수준에서 데이터를 관리할 수 있으므로 CDC(변경 데이터 캡처) 및 스트리밍 데이터 수집이 간소화되며 레코드 수준 업데이트 및 삭제가 필요한 데이터 프라이버시 사용 사례를 처리할 수 있습니다. Apache Hudi로 관리되는 데이터 세트는 개방형 스토리지 형식으로 S3에 저장되며 Presto, Apache Hive, Apache Spark 및 AWS Glue Data Catalog와 통합하여 사용할 경우 익숙한 도구에서 업데이트된 데이터에 거의 실시간으로 액세스할 수 있습니다.

Q: Apache Hudi는 언제 사용해야 합니까?

Apache Hudi는 S3에서 레코드 수준 데이터 관리가 필요한 사용 사례에 도움이 됩니다. 일반적으로 다음과 같은 5가지 사용 사례에 이러한 기능이 도움이 됩니다.

1. 사용자가 사용자 데이터의 사용 방법에 관한 기본 설정을 변경하도록 선택하는 경우 조직에 사용자 데이터를 제거하거나 사용자 기본 설정을 업데이트할 것을 요구하는 데이터 프라이버시 관련 법 준수. Apache Hudi는 오픈 소스 데이터 형식(예: Apache Parquet 및 Apache Avro)을 사용하여 S3에 저장된 데이터에서 레코드 수준 삽입, 업데이트 및 삭제 작업을 수행할 수 있는 기능을 제공합니다.
2. 엔터프라이즈 시스템에서 실시간 데이터 스트림 사용 및 변경 데이터 캡처 로그 적용. 많은 조직에서는 Apache Hive 및 Presto 같은 엔진에서 Amazon S3의 EDW(엔터프라이즈 데이터 웨어하우스) 및 ODS(운영 데이터 스토어) 데이터에 액세스하여 데이터 처리 및 분석을 수행합니다. Apache Hudi를 사용하면 변경 로그를 적용하는 프로세스가 간소화되며 사용자가 거의 실시간으로 데이터에 액세스할 수 있습니다.
3. 늦게 도착하거나 잘못된 데이터 복구. 데이터가 늦게 도착하거나 잘못된 경우 데이터 상태를 복구하고 새로운 레코드 또는 업데이트된 레코드를 포함하도록 기존 데이터 세트를 업데이트해야 합니다. Apache Hudi에서는 기존 데이터 세트에 레코드를 “upsert”하여 데이터 세트에 레코드가 있는지 여부에 따라 레코드를 삽입하거나 업데이트할 수 있습니다.
4. 데이터 세트 변경 내용을 추적하고 변경 사항을 롤백할 수 있는 기능 제공. Apache Hudi에서는 데이터 세트에 대한 모든 변경 사항이 커밋으로 추적되며 손쉽게 롤백할 수 있으므로 데이터 세트에 대한 특정 변경 사항을 찾고 “실행 취소”할 수 있습니다.
5. S3의 파일 관리 간소화. 데이터 파일의 크기를 효율적으로 변경하려면 다수의 작은 파일을 모니터링하여 소수의 큰 파일로 재작성하는 사용자 지정 솔루션을 구축해야 합니다. Apache Hudi를 사용하면 S3의 데이터 파일이 관리됩니다. 사용자는 데이터를 저장할 최적의 파일 크기를 구성하기만 하면 됩니다. 그러면 Hudi가 파일을 병합하여 효율적인 크기의 파일을 생성합니다.
6. Hudi 데이터세트를 목표로 하는 delta를 작성합니다. Hudi 데이터세트는 증분하여 당길할 수 있습니다. 즉, 지정 인스턴트 시간 이후 모든 행과 업데이트된 행 및 새 행만 가져올 수 있습니다.

Q: Apache Hudi 데이터 세트를 생성하려면 어떻게 해야 합니까?

Apache Hudi 데이터 세트는 Apache Spark를 사용하여 생성됩니다. Apache Spark DataFrame을 작성하는 것만큼 간단한 방법으로 데이터 세트를 생성할 수 있습니다. 필요한 경우 Apache Hudi 데이터 세트의 메타데이터를 AWS Glue Data Catalog 또는 Hive 메타스토어에 저장하여 데이터 검색을 간소화하고 Apache Hive 및 Presto와의 통합을 수행할 수 있습니다.

Q: Apache Hudi는 데이터 세트를 어떻게 관리합니까?

Apache Hudi에서 데이터 세트를 생성할 때 데이터 세트 최적화에 사용할 데이터 액세스 패턴의 유형을 선택할 수 있습니다. 읽기 작업이 많은 사용 사례의 경우 사용자는 “COW(기록 중 복사)” 데이터 관리 전략을 사용하여 데이터 세트의 잦은 읽기에 맞춰 최적화를 수행합니다. 이 전략은 열 기반 스토리지 형식을 사용하여 데이터를 구성하고, 업데이트가 기록될 때 기존 데이터와 신규 업데이트를 병합합니다. 쓰기 작업이 많은 워크로드의 경우 Apache Hudi는 “Merge on Read” 데이터 관리 전략을 사용하여 칼럼 및 행 저장소 형식을 결합해 데이터를 구성합니다. 이 업데이트는 행 기반 스토리지 형식으로 파일에 추가되며, 병합을 읽기 시간에 수행하여 업데이트된 결과를 제공합니다.

Q: Apache Hudi 데이터 세트에 기록하려면 어떻게 해야 합니까?

Apache Hudi 데이터 세트에 대한 변경은 Apache Spark를 사용하여 수행됩니다. Apache Spark에서 Apache Hudi 데이터 세트 작업은 Spark DataSource API를 사용하여 수행되므로 데이터를 읽고 쓸 수 있습니다. DataFrame은 기존 데이터에 새롭게 추가한 데이터 또는 업데이트를 포함하여 동일 DataSource API를 사용하여 쓸 수 있습니다". Hudi DeltaStreamer 유틸리티도 사용할 수 있습니다.

Q: Apache Hudi 데이터 세트를 읽으려면 어떻게 해야 합니까?

Apache Spark, Apache Hive, Presto, Amazon Redshift Spectrum 또는 Amazon Athena 중 하나를 사용하여 데이터를 읽을 수 있습니다. 필요한 경우 데이터 세트를 생성할 때 AWS Glue Data Catalog 또는 Hive 메타스토어에 해당 데이터의 메타데이터를 게시할 수 있습니다. 메타스토어에 메타데이터를 게시하도록 선택하는 경우 데이터 세트는 일반적인 테이블 형식으로 표시되며 Apache Hive 및 Presto를 사용하여 이 테이블을 쿼리할 수 있습니다.

Q: Apache Hudi를 사용할 때 알고 있어야 할 고려 사항이나 제한 사항은 무엇입니까?

Amazon EMR에서 Apache Hudi를 사용할 때의 고려 사항 및 제한 사항의 전체 목록은 Amazon EMR 설명서를 참조하십시오.

Q: Apache Hudi에서 기존 데이터는 어떻게 작동합니까?

Apache Hudi에서 기존 데이터를 관리하려는 경우 Amazon EMR 기반 Apache Hudi에 있는 가져오기 도구를 사용하여 Apache Parquet 데이터를 Apache Hudi 데이터 세트로 손쉽게 변환하거나 Hudi DeltaStreamer 유틸리티 또는 Apache Spark를 사용하여 기존 데이터를 Apache Hudi 데이터 세트로 재작성할 수 있습니다.

Q: Impala란 무엇입니까?

Impala는 SQL 구문을 사용하는 대화형 임시 쿼리를 위한 하둡 에코시스템의 오픈 소스 도구입니다. Impala는 MapReduce를 사용하지 않고 전통적 RDBMS(관계형 데이터베이스 관리 시스템)의 엔진과 비슷한 MPP(대량 병렬 처리) 엔진을 사용합니다. 이 아키텍처에서는 사용자가 HDFS 또는 HBase 테이블의 데이터를 아주 빠르게 쿼리할 수 있으며, 런타임 시 스키마를 제공하고 다양한 데이터 유형을 처리하는 하둡 기능을 활용할 수 있습니다. 따라서 Impala에서는 지연 시간이 짧은 대화형 분석이 가능합니다. 또한, Impala는 Hive 메타스토어를 사용해 파티션 이름 및 데이터 유형 등과 같은 입력 데이터에 대한 정보를 보관합니다. 그리고 Amazon EMR의 Impala는 하둡 2.x 이상을 실행하는 AMI가 필요합니다. Impala에 대해 더 알아보려면 여기를 클릭하십시오.

Q: Amazon EMR에서 실행되는 Impala로 어떤 작업을 수행할 수 있습니까?

Amazon EMR에서 Hive를 사용할 때와 마찬가지로 Amazon EMR에서 Impala를 사용하면 SQL 구문을 통해 정교한 데이터 처리 애플리케이션을 구현할 수 있습니다. 하지만 Impala는 특정 사용 사례의 경우 더욱 빠른 성능을 제공하도록 구축되었습니다(아래 참조). Amazon EMR에서는 Impala를 안정적인 데이터 웨어하우스로 사용하여 데이터 분석, 모니터링, 비즈니스 인텔리전스 등의 작업을 수행할 수 있습니다. 다음은 여기에 해당하는 3가지 사용 사례입니다.

• 장기 실행 중인 클러스터에서 Hive 대신 Impala를 사용해 임시 쿼리를 수행하십시오. Impala는 대화형 쿼리의 시간을 수 초로 줄여주므로 빠른 조사에 적합한 도구입니다. Impala는 배치 MapReduce 워크플로와 동일한 클러스터에서 실행할 수 있으며, 장기 실행 중인 분석 클러스터에서 Hive 및 Pig와 함께 사용하거나 Impala 쿼리에 맞게 특별히 조정된 클러스터를 생성할 수도 있습니다.
• 일시적인 Amazon EMR 클러스터에서 배치 ETL 작업에는 Hive 대신 Impala를 사용하십시오. Impala는 많은 종류의 쿼리에 대해 Hive보다 빠르므로 이러한 워크로드에 대해 더 나은 성능을 제공합니다. Impala는 Hive와 마찬가지로 SQL을 사용하므로 Hive에서 Impala로 손쉽게 쿼리를 수정할 수 있습니다.
• Impala를 타사 비즈니스 인텔리전스 도구와 함께 사용하십시오. 클라이언트 ODBC 또는 JDBC 드라이버를 클러스터와 연결하여 강력한 시각화 도구 및 대시보드용 엔진으로 Impala를 사용하십시오.

배치 Impala 클러스터와 대화형 Impala 클러스터는 모두 Amazon EMR에서 생성할 수 있습니다. 예를 들면 장기 실행 중인 Amazon EMR 클러스터에서 임시 대화형 쿼리를 위해 Impala를 사용하거나, 빠른 ETL 워크플로를 위해 일시적인 Impala 클러스터를 사용할 수 있습니다.

Q: Impala와 전통적 RDBMS의 차이점은 무엇입니까?

전통적 관계형 데이터베이스는 트랜잭션 의미 체계와 ACID 속성(데이터베이스 원자성, 일관성, 격리성, 내구성)을 제공합니다. 또한, 테이블을 인덱싱하고 캐시할 수 있으므로, 적은 양의 데이터를 아주 빠르게 검색할 수 있고, 적은 양의 데이터에 대한 빠른 업데이트를 제공하며, 참조 무결성 제약 조건을 적용합니다. 전통적 RDBMS는 일반적으로 대형 머신 한 대에서 실행되며, 복잡한 사용자 정의 데이터 유형에 대한 작업 수행을 지원하지 않습니다. Impala도 전통적 RDBMS과 비슷한 분산형 쿼리 시스템을 사용하기는 하지만, 쿼리 데이터를 HDFS에 저장하며 Hive 메타스토어를 사용해 입력 데이터에 대한 정보를 보관합니다. Hive와 마찬가지로 쿼리에 대한 스키마는 런타임 시 제공되기 때문에 스키마 변경이 쉽습니다. 또한, Impala는 복잡한 데이터 유형을 다양하게 쿼리하고 사용자 정의 함수도 실행할 수 있습니다. 하지만 Impala는 인 메모리로 데이터를 처리하기 때문에 최고의 성능을 위해서는 클러스터의 하드웨어 제한을 이해하고 쿼리를 최적화하는 것이 중요합니다.

Q: Impala와 Hive의 차이점은 무엇입니까?

Impala는 MPP(대량 병렬 처리) 엔진을 사용해 SQL 쿼리를 실행하며, Hive는 MapReduce를 사용해 SQL을 실행합니다. Impala는 MapReduce 작업을 생성하여 Hive의 오버헤드를 방지하기 때문에 Hive보다 쿼리 시간이 줄어듭니다. 하지만 Impala는 상당한 양의 메모리 리소스를 사용하며, 클러스터의 가용 메모리 공간은 쿼리가 사용할 수 있는 메모리의 양을 제약합니다. Hive에서는 이러한 제약 사항이 없으며, 같은 하드웨어로 더 큰 데이터 세트를 처리할 수 있습니다. 일반적으로 Impala는 빠른 대화형 쿼리에 사용하고, Hive는 대형 데이터 세트의 ETL 워크로드를 처리하는 데 사용해야 합니다. Impala는 빠른 성능을 낼 수 있도록 구축되었기 때문에 임시 조사에 매우 적합하지만 비싼 쿼리를 실행하거나 아주 큰 데이터 세트를 처리하는 데 상당히 많은 양의 메모리가 필요합니다. 이러한 제약 조건 때문에 속도보다 완료가 더욱 중요한 워크로드의 경우 Hive를 사용하는 것이 좋습니다. Impala와 Hive 간의 몇 가지 성능 벤치마크를 확인하려면 여기를 클릭하십시오.

Q: 하둡 1을 사용할 수 있습니까?

아니요. Impala는 하둡 2가 필요하며, 하둡 1.x를 구동하는 AMI의 클러스터에서는 실행되지 않습니다.

Q: Impala 클러스터에는 어떤 인스턴스 유형을 사용해야 합니까?

Impala를 가장 잘 활용하려면 클러스터에 대해 메모리가 최적화된 인스턴스를 사용하는 것이 좋습니다. 하지만 앞서 보여드린 것처럼 표준 인스턴스 유형을 사용해도 Hive보다 더 나은 성능을 제공합니다. Amazon EMR 개발자 안내서의 성능 테스트 및 쿼리 최적화 섹션을 참조하면 데이터 세트와 쿼리 유형에 따라 클러스터에 필요한 메모리 리소스를 대략적으로 알아볼 수 있습니다. 압축 유형, 파티션 및 실제 쿼리(조인 수, 결과 크기 등)는 모두 필요한 메모리에서 역할을 합니다. EXPLAIN 명령문을 사용하면 Impala 쿼리에 필요한 메모리와 기타 리소스를 추정할 수 있습니다.

Q: 쿼리 시 메모리가 부족하면 어떻게 됩니까?

메모리가 부족하게 되면 쿼리가 실패하고 영향을 받은 노드에 설치된 Impala 데몬이 종료됩니다. 그런 다음 Amazon EMR은 Impala가 다른 쿼리를 실행할 수 있도록 해당 노드의 데몬을 다시 시작합니다. 전체 노드가 종료되는 것이 아니라 노드에서 실행 중인 데몬만 종료되기 때문에 노드 HDFS의 데이터는 사용할 수 있는 상태로 유지됩니다. Impala를 통한 임시 분석의 경우, 쿼리 시간은 초 단위인 경우가 많습니다. 따라서 쿼리가 실패하면 빨리 문제를 발견하고 새로운 후속 쿼리를 빠르게 제출할 수 있습니다.

Q: Impala는 사용자 정의 함수를 지원합니까?

예. Impala는 UDF(사용자 정의 함수)를 지원합니다. Impala용 UDF는 Java나 C++를 통해 작성할 수 있습니다. 또한, Hive용으로 생성된 사용자 정의 집계 함수나 UDF를 수정할 수도 있습니다. Hive UDF에 대한 정보를 확인하려면 여기를 클릭하십시오.

Q: Impala가 쿼리할 데이터는 어디에 저장되어 있습니까?

Impala는 HDFS 또는 HBase 테이블의 데이터를 쿼리합니다.

Q: 클러스터에서 Impala와 MapReduce를 동시에 실행할 수 있습니까?

예. Impala와 MapReduce를 동시에 실행하는 멀티 테넌트 클러스터를 설정할 수 있습니다. 하지만 하둡 2.x에서 YARN을 사용하여 각 애플리케이션에 리소스(메모리, 디스크, CPU)를 할당해야 합니다. 할당된 리소스는 각 애플리케이션에서 실행할 작업의 필요에 따라 달라져야 합니다.

Q: Impala는 ODBC와 JDBC 드라이버를 지원합니까?

ODBC 드라이버를 사용할 수 있지만, Impala는 JDBC를 통해 연결된 타사 도구를 위한 엔진으로도 매우 뛰어난 성능을 발휘합니다. Impala 클라이언트 JDBC 드라이버는 http://elasticmapreduce.s3.amazonaws.com/libs/impala/1.2.1/impala-jdbc-1.2.1.zip에서 다운로드하여 설치할 수 있습니다. 비즈니스 인텔리전스 도구가 설치된 클라이언트 컴퓨터에서 JDBC 드라이버를 포트 21050에서 VPN 또는 SSH를 사용해 Impala 클러스터의 마스터 노드에 연결하십시오. 자세한 정보는 마스터 노드로 SSH 터널 열기 섹션을 참조하십시오.

Q: Apache Pig란 무엇입니까?

Pig는 하둡에서 실행되는 오픈 소스 분석 패키지입니다. Pig는 Pig Latin이라는 유사 SQL 언어로 작동합니다. 이를 통해 사용자는 Amazon S3에 저장된 데이터 소스를 구축, 요약 및 쿼리할 수 있습니다. SQL과 유사한 작업뿐만 아니라 Pig Latin은 또한 map/reduce 함수와 복잡하고 확장 가능한 사용자 정의 데이터 유형에 최고의 지원을 제공합니다. 이 기능을 통해 텍스트 문서와 로그 파일 같은 복잡한 비정형 데이터 소스도 처리할 수 있습니다. Pig를 사용하면, 사용자가 Java로 작성되고 Amazon S3 스토리지를 통해 배포된 사용자 정의 함수를 사용하여 확장할 수 있습니다.

Q: Amazon EMR에서 실행되는 Pig로 어떤 작업을 수행할 수 있습니까?

Amazon EMR에서 Pig를 사용하면 Amazon EMR에서 사용할 수 있는 친숙한 유사 SQL 언어와 사용하기 쉬운 도구로 정교한 데이터 처리 애플리케이션을 구현할 수 있습니다. Amazon EMR을 사용하면 Pig 애플리케이션을 안정적인 데이터 웨어하우스로 바꾸어 데이터 분석, 모니터링, 비즈니스 인텔리전스 등의 작업을 수행할 수 있습니다.

Q: Amazon EMR에서 실행되는 Pig를 시작하려면 어떻게 해야 합니까?

여기에 있는 설명서를 검토하는 것으로 시작하는 것이 가장 좋습니다.

Q: Amazon EMR 전용 Pig에 새로운 기능이 있습니까?

예. Amazon EMR과 함께 사용하면 Pig를 더욱 강화하는 다음의 세 가지 새로운 기능이 있습니다.

a/ 여러 파일 시스템 액세스 기능. 기본적으로 Pig 작업은 하나의 원격 파일 시스템에만 액세스할 수 있으며, 입력, 출력 및 임시 데이터용 S3 버킷 또는 HDFS 스토어가 파일 시스템으로 사용됩니다. EMR은 모든 작업에서 필요한 만큼 많은 파일 시스템에 액세스할 수 있도록 Pig를 확장했습니다. 그 이점 중 하나는 임시 작업 내 데이터가 로컬 HDFS에 항상 저장되어 있어 성능이 향상된다는 것입니다.

b/ S3에서 리소스 로딩 기능. EMR은 S3 파일 시스템으로부터 사용자 정의 JAR 및 스크립트를 가져올 수 있도록 Pig를 확장했습니다(예: "REGISTER s3:///my-bucket/piggybank.jar").

c/ 문자열과 날짜 시간 처리를 위한 추가 Piggybank 함수.

Q: 어떤 유형의 Pig 클러스터를 지원합니까?

Pig는 두 가지 유형(대화형 및 배치)의 클러스터를 지원합니다. 대화형 모드에서는 고객이 클러스터를 시작하고, 마스터 노드에서 직접 대화형 Pig 스크립트를 실행할 수 있습니다. 일반적으로 이 모드는 임시 데이터 분석 및 애플리케이션 개발에 사용됩니다. 배치 모드에서는 Pig 스크립트를 Amazon S3에 저장하여 클러스터를 시작할 때 참조합니다. 일반적으로 배치 모드는 보고서 생성과 같은 반복 가능한 실행에 사용됩니다.

Q: Pig 클러스터를 시작하려면 어떻게 해야 합니까?

배치 클러스터 및 대화형 클러스터는 모두 AWS Management Console, EMR 명령줄 클라이언트 또는 API에서 시작할 수 있습니다.

Q: Amazon EMR은 어떤 버전의 Pig를 지원합니까?

Amazon EMR은 여러 버전의 Pig를 지원합니다.

Q: 두 클러스터에서 동시에 하나의 S3 버킷에 쓰기 작업을 할 수 있습니까?

예. 두 클러스터에서 동시에 동일한 버킷에 쓰기 작업을 할 수 있습니다.

Q: 클러스터 간에 S3의 입력 데이터를 공유할 수 있습니까?

예. 두 클러스터에서 S3에 있는 동일한 데이터를 동시에 읽을 수 있습니다.

Q: 여러 AWS 사용자 간에 데이터를 공유할 수 있습니까?

예. 여기(http://docs.amazonwebservices.com/AmazonS3/latest/index.html?S3_ACLs.html)에 설명된 표준 Amazon S3 공유 메커니즘을 사용하여 데이터를 공유할 수 있습니다.

Q: 대규모 클러스터를 하나 실행하고 여러 사용자와 공유해야 합니까? 아니면 소규모 클러스터를 여러 개 실행해야 합니까?

Amazon EMR은 두 가지 방법을 모두 사용할 수 있도록 고유한 기능을 제공합니다. 하나의 대규모 클러스터는 정기적인 배치 워크로드를 처리하는 데 더욱 효율적일 수 있습니다. 반면에 임시 쿼리 또는 시간에 따라 다른 워크로드가 필요할 경우, Amazon S3에 저장된 데이터 소스를 공유하는 특정 작업에 맞게 조정된 몇 개의 클러스터를 별도로 생성할 수 있습니다.

Q: 내 로컬 파일 시스템에 있는 스크립트 또는 jar 리소스에 액세스할 수 있습니까?

스크립트 또는 jar을 Amazon S3 또는 클러스터 마스터 노드에 업로드해야 참조할 수 있습니다. Amazon S3에 업로드하기 위해 s3cmd, jets3t 또는 S3Organizer 같은 도구를 사용할 수 있습니다.

Q: 여러 Pig 쿼리를 실행하는 영구 클러스터를 실행할 수 있습니까?

예. Pig 단계 사이에 종료되지 않도록 클러스터를 수동 종료 모드로 실행합니다. 데이터 손실의 위험을 줄이기 위해 Amazon S3에 있는 중요한 데이터를 정기적으로 관리하십시오. 새 클러스터에 정기적으로 작업을 전송하여 마스터 노드의 장애 복구 프로세스를 테스트하는 것이 좋습니다.

Q: Pig는 JDBC 액세스를 지원합니까?

Pig는 JDBC를 통한 액세스를 지원하지 않습니다. 

Q: Apache HBase란 무엇입니까?

HBase는 Google의 BigTable을 본떠서 만든 비관계형 분산 오픈 소스 데이터베이스입니다. 이 데이터베이스는 Apache Software Foundation의 하둡 프로젝트의 일부로 개발되었으며, 하둡 분산 파일 시스템(HDFS)에서 실행되어 하둡에 BigTable과 같은 기능을 제공합니다. HBase는 열 기반 압축 및 스토리지를 사용하여 다량의 스파스 데이터를 저장할 수 있는 효율적이고 내결함성을 갖춘 방식을 제공합니다. 또한 HBase는 데이터가 디스크가 아닌 메모리 안에 저장되므로 데이터를 빠르게 조회할 수 있습니다. HBase는 순차 쓰기 작업에 최적화되어 있으며 배치 처리 삽입, 업데이트 및 삭제에 매우 유용합니다. HBase는 파일 시스템을 공유하고 하둡 작업에 직접 입력 및 출력하는 역할을 하는 등 하둡과 함께 원활하게 작동합니다. 또한 HBase는 Apache Hive와 통합하여 HBase 테이블에 대한 유사 SQL 쿼리, Hive 기반 테이블과의 조인 및 JDBC(Java Database Connectivity)에 대한 지원을 활성화할 수 있습니다. 여기서 Apache HBase에 대해 자세히 알아볼 수 있습니다.

Q: HBase에 Amazon EMR에서만 제공되는 새로운 기능이 있습니까?

Amazon EMR을 통해 Amazon S3 기반 HBase를 사용하여 클러스터의 HBase 루트 디렉터리 및 메타데이터를 직접 Amazon S3에 저장하고 복제 및 스냅샷을 생성할 수 있습니다. 자세한 내용은 설명서를 참조하세요.

Q: Amazon EMR은 어떤 버전의 HBase를 지원합니까?

Amazon EMR이 지원하는 최신 HBase에 대해 알아보려면 여기를 참조하세요.

Q: Kinesis로 연결되는 EMR 커넥터로 무엇을 할 수 있습니까?

커넥터는 EMR에서 Kinesis 스트림의 데이터를 직접 읽고 쿼리할 수 있도록 지원합니다. 이제 Hive, Pig, MapReduce, 하둡 스트리밍, Cascading과 같은 기존 하둡 에코시스템을 사용하여 Kinesis 스트림의 배치 프로세스를 수행할 수 있습니다.

Q: Kinesis로 연결되는 EMR 커넥터로 이전에는 하지 못했던 어떤 작업을 할 수 있습니까?

Kinesis 스트림의 데이터를 읽고 처리하기 위해서는 사용자가 개별 스트림 처리 애플리케이션을 작성하고, 배포하고, 유지 관리해야 했습니다. 이러한 작업에는 시간과 노력이 소요됩니다. 하지만 이 커넥터를 사용하면 간단한 Hive 또는 Pig 스크립트를 작성하여 Kinesis 스트림을 읽고 분석할 수 있습니다. 즉, SQL을 사용하여 Kinesis 스트림을 분석할 수 있습니다! 물론, 다른 하둡 에코시스템 도구도 사용할 수 있습니다. 새로운 처리 애플리케이션을 개발하거나 유지 관리할 필요가 없습니다.

Q: 누가 이 기능을 유용하게 사용하게 됩니까?

다음 사용자 유형은 이 통합을 유용하게 사용할 수 있습니다.

• 광범위한 하둡 에코시스템 도구 세트를 활용하여 Kinesis 스트림을 분석하는 데 관심이 있는 하둡 사용자.
  
• 스트림 처리 및 Kinesis 데이터의 ETL을 준비하고 실행하기 위한 간편한 방법을 찾고 있는 Kinesis 사용자.
  
• SQL(Hive를 통해) 또는 Pig와 같은 스크립팅 언어와 같은 친숙한 도구를 사용하여 Kinesis 스트림의 데이터를 임시 분석하려 하는 비즈니스 분석가 및 IT 전문가.
  

Q: 이러한 통합에 대한 사용 사례에는 무엇이 있습니까?

이러한 통합으로 지원되는 대표적 사용 사례는 다음과 같습니다.

• 스트리밍 로그 분석: 스트리밍 웹 로그를 분석하여 리전, 브라우저 및 액세스 도메인별로 몇 분마다 상위 10개의 오류 유형 목록을 생성할 수 있습니다.
  
• 복잡한 데이터 처리 워크플로: Kinesis 스트림을 S3, DynamoDB 테이블 및 HDFS에 저장된 데이터와 조인할 수 있습니다. Kinesis의 클릭스트림 데이터와 DynamoDB 테이블에 저장된 광고 캠페인 정보를 조인하는 쿼리를 작성하여 특정 웹사이트에 표시되는 광고 카테고리 중 가장 효과적인 카테고리를 파악할 수 있습니다.
  
• 임시 쿼리: 빠른 대화형 분석 쿼리를 위해 Kinesis의 데이터를 HDFS로 주기적으로 로드하고 이를 로컬 Impala 테이블로 사용할 수 있도록 합니다.
  

Q: 커넥터를 사용할 수 있으려면 어떤 EMR AMI 버전이 필요합니까?

EMR의 AMI 버전 3.0.4 이상을 사용해야 합니다.

Q: 이 커넥터는 독립 실행형 도구입니까?

아니요. 이 커넥터는 Amazon 하둡 배포에 포함된 구성 요소이며 EMR AMI 버전 3.0.4 이상에서 사용할 수 있습니다. 이 기능을 사용하려는 고객은 클러스터를 AMI 버전 3.0.4 이상에서 가동하면 됩니다.

Q: EMR이 Kinesis 스트림을 읽는 데 필요한 데이터 형식은 무엇입니까?

EMR Kinesis 통합에서는 특정 데이터 형식만 지원하지는 않습니다. 모든 형식의 데이터를 읽을 수 있습니다. 개별 Kinesis 레코드는 모든 하둡 MapReduce 프레임워크를 사용하여 읽을 수 있는 표준 레코드로 하둡에 제공됩니다. Hive, Pig, Cascading과 같은 개별 프레임워크에는 직렬화 및 역직렬화를 지원하는 내장 구성 요소가 있으므로, 개발자는 사용자 정의 코드를 구현하지 않아도 다양한 형식의 데이터를 손쉽게 쿼리할 수 있습니다. 예를 들어, Hive 사용자의 경우 테이블을 정의할 때 적절한 Hive SerDe를 지정하면, JSON 파일, XML 파일 및 SEQ 파일의 데이터를 읽을 수 있습니다. Pig에는 Loadfunc/Evalfunc, Cascading에는 Tap이라고 하는 유사한 구성 요소가 있습니다. 하둡 사용자는 형식별 코드를 작성하지 않아도 하둡 어댑터의 광범위한 에코시스템을 활용할 수 있습니다. 또한, 사용자 정의 역직렬화 형식을 구현하여 이러한 도구에서 도메인별 데이터를 읽을 수 있습니다.

Q: EMR에서 Hive를 사용하여 Kinesis 스트림을 분석하려면 어떻게 해야 합니까?

Kinesis 스트림을 참조하는 테이블을 생성합니다. 그런 다음 Hive의 다른 테이블과 마찬가지로 해당 테이블을 분석합니다. 자세한 내용은 자습서 페이지를 참조하십시오.

Q: Hive를 사용하여 Kinesis 스트림 데이터를 다른 데이터 소스와 결합하는 쿼리를 생성하려면 어떻게 해야 합니까?

먼저 Kinesis 스트림을 참조하는 테이블을 생성합니다. Hive 테이블이 생성되면, 이를 Amazon S3, Amazon DynamoDB, HDFS와 같은 다른 데이터 소스에 매핑하는 테이블과 조인할 수 있습니다. 이렇게 하면 효과적으로 Kinesis 스트림의 데이터를 다른 데이터 소스에 조인할 수 있습니다.

Q: 이 통합은 Hive에서만 사용할 수 있습니까?

아니요. Hive, Pig, MapReduce, 하둡 스트리밍 및 Cascading을 사용할 수 있습니다.

Q: Kinesis 스트림에서 실행되도록 예약된 작업을 설정하려면 어떻게 해야 합니까?

EMR Kinesis 입력 커넥터는 예약된 주기적 작업을 Cron과 같은 기존의 일정 예약 엔진에서 구성하고 관리할 수 있는 기능을 제공합니다. 예를 들어, N분마다 실행되는 Hive 스크립트를 개발할 수 있습니다. 작업의 구성 파라미터에서 해당 작업에 대한 논리적 이름을 지정할 수 있습니다. 논리적 이름은 EMR Kinesis 입력 커넥터에 해당 작업의 개별 인스턴스가 동일한 주기적 일정의 일부임을 알려주는 레이블입니다. 논리적 이름을 사용하면 프로세스에서 반복을 활용할 수 있습니다. 반복에 대해서는 다음에 설명되어 있습니다.

MapReduce는 배치 프로세스 프레임워크이므로, EMR을 사용하여 Kinesis 스트림을 분석하도록 지속적인 스트림이 배치로 분할됩니다. 각 배치를 반복이라고 부릅니다. 각 반복에는 번호가 할당되며, 이 번호는 0부터 시작합니다. 각 반복의 범위는 시작 시퀀스 번호와 종료 시퀀스 번호로 정의됩니다. 그런 다음 이러한 반복은 EMR에서 순서대로 처리됩니다.

시도가 실패하는 경우, EMR Kinesis 입력 커넥터는 반복의 알려진 시작 시퀀스 번호부터 시작하여, 논리적 이름 내에서 반복을 다시 시도합니다. 이 기능은 동일한 반복에 대한 연이은 시도가 이전 시도와 마찬가지로 Kinesis 스트림에서 정확히 동일한 입력 레코드를 갖도록 해줍니다. 이를 통해 Kinesis 스트림의 멱등적(일관된) 처리가 보장됩니다.

각 하둡 도구에서 런타임 파라미터로서 논리적 이름과 반복을 지정할 수 있습니다. 예를 들어 자습서의 ‘체크포인트로 쿼리 실행' 섹션에 있는 코드 샘플은 쿼리에 대한 논리적 이름을 지정하고 작업이 연속적으로 실행될 때마다 반복하도록 예약된 Hive 쿼리를 보여줍니다.

또한, 샘플 Cron 일정 예약 스크립트도 자습서에 제공되어 있습니다.

Q: 논리적 이름 및 반복에 대한 메타데이터는 어디에 저장되어 있습니까?

EMR Kinesis 입력 커넥터가 예약된 주기적 워크플로에서 작동할 수 있도록 하는 메타데이터는 Amazon DynamoDB에 저장되어 있습니다. Amazon DynamoDB 테이블을 프로비저닝하고 이를 하둡 작업에 대한 입력 파라미터로 지정해야 합니다. 이러한 통합을 사용할 수 있으려면 해당 테이블에 대한 적절한 IOPS를 구성하는 것이 중요합니다. Amazon DynamoDB 테이블 설정에 대한 자세한 내용은 시작 자습서를 참조하십시오.

Q: 반복 처리가 실패하면 어떤 일이 발생합니까?

반복 식별자는 Kinesis 스트림에서 특정 범위(시작 및 종료 시퀀스 번호)에 매핑하기 위해 사용자가 제공한 값입니다. 이러한 범위에 해당하는 데이터는 MapReduce 작업의 매핑 단계에서 로드됩니다. 이 단계는 프레임워크에서 관리되며 작업 실패 시 자동으로 다시 실행됩니다(기본적으로 3회). 재시도가 모두 실패하더라도, 마지막으로 성공한 데이터 범위 또는 이전 데이터 범위부터 다시 프로세스를 시도하도록 선택할 수 있습니다. 이 동작은 처리 도중 kinesis.checkpoint.iteration.no 파라미터를 입력하여 제어합니다. 이러한 값이 하둡 에코시스템의 다른 도구에 대해 어떻게 구성되는지에 대한 자세한 내용은 시작 자습서를 참조하십시오.

Q: 동일한 반복에서 여러 개의 쿼리를 실행할 수 있습니까?

예. 연이은 프로세스에서 kinesis.checkpoint.iteration.no 파라미터를 설정하여 이전에 실행한 반복을 지정할 수 있습니다. 이러한 구현은 동일한 반복에 대한 연이은 시도가 이전 시도와 마찬가지로 Kinesis 스트림에서 정확히 동일한 입력 레코드를 갖도록 해줍니다.

Q: 반복 내 레코드가 Kinesis 스트림에서 만료된 경우 어떤 일이 발생합니까?

반복의 시작 시퀀스 번호 및/또는 종료 시퀀스 번호가 Kinesis 스트림에서 만료된 레코드에 포함되어 있는 경우 하둡 작업이 실패합니다. Kinesis 스트림의 처음부터 데이터를 처리하려면 다른 논리적 이름을 사용해야 합니다.

Q: 데이터를 EMR에서 Kinesis 스트림으로 푸시할 수 있습니까?

현재 EMR Kinesis 커넥터는 다시 Kinesis 스트림으로 데이터를 작성하는 기능을 지원하지 않습니다.

Q: Kinesis용 EMR 하둡 입력 커넥터는 지속적인 스트림 처리를 지원합니까?

하둡 MapReduce 프레임워크는 배치 프로세스 시스템입니다. 그러므로 지속적인 쿼리는 지원하지 않습니다. 그러나 개발자가 지속적인 스트림 처리를 위한 애플리케이션을 구축할 수 있도록 해주는 Twitter Storm 및 Spark Streaming과 같은 하둡 에코시스템 세트가 최근에 출시되고 있습니다. Kinesis용 Storm 커넥터는 GitHub에서 제공되며, EMR에서 Spark Streaming을 설정하는 방법과 지속적인 쿼리를 실행하는 방법을 설명하는 자습서는 여기에서 찾아볼 수 있습니다.

또한, 개발자는 Kinesis 클라이언트 라이브를 활용하여 실시간 스트림 처리 애플리케이션을 개발할 수도 있습니다. Kinesis 설명서에서 사용자 지정 Kinesis 애플리케이션 개발에 대한 자세한 내용을 찾아볼 수 있습니다.

Q: 다른 AWS 계정에서 관리하는 Kinesis 스트림을 읽을 수 있도록 액세스 자격 증명을 지정할 수 있습니까?

예. Kinesis 스트림이 있는 계정의 적절한 액세스 자격 증명을 지정하여 다른 AWS 계정에서 스트림을 읽을 수 있습니다. 기본적으로 Kinesis 커넥터는 클러스터 생성 시 지정된, 사용자 제공 액세스 자격 증명을 활용합니다. kinesis.accessKey 및 kinesis.secretKey 파라미터를 설정함으로써 이러한 자격 증명을 재정의하여 다른 AWS 계정의 스트림에 액세스할 수 있습니다. 다음 예제에는 Hive와 Pig에서 kinesis.accessKey와 kinesis.secretKey 파라미터를 설정하는 방법이 나와 있습니다.

Hive용 코드 샘플:
...
STORED BY
'com.amazon.emr.kinesis.hive.KinesisStorageHandler'
TBLPROPERTIES(
"kinesis.accessKey"="AwsAccessKey",
"kinesis.secretKey"="AwsSecretKey",
);

Pig용 코드 샘플:
…
raw_logs = LOAD 'AccessLogStream' USING com.amazon.emr.kinesis.pig.Kin
esisStreamLoader('kinesis.accessKey=AwsAccessKey', 'kinesis.secretKey=AwsSecretKey'
) AS (line:chararray);

Q: 단일 Kinesis 스트림에서 여러 병렬 쿼리를 실행할 수 있습니까? 이는 성능에 영향을 미칩니까?

예. 고객은 각 쿼리에 대해 개별적인 논리적 이름을 사용하여 동일한 스트림에서 여러 병렬 쿼리를 실행할 수 있습니다. 그러나 Kinesis 스트림 내 샤드에서의 읽기는 초당 2MB라는 속도 제한이 적용됩니다. 그러므로 동일 스트림에 N개의 병렬 쿼리가 실행되는 경우 각 쿼리에 대한 스트림의 샤드당 송신 속도는 대략 초당 (2/N)MB입니다. 이로 인해 처리 속도가 느려질 수 있으며, 쿼리에 실패하는 경우도 발생합니다.

Q: EMR에서 여러 Kinesis 스트림을 조인 및 분석할 수 있습니까?

예. Hive의 경우 두 개의 다른 Kinesis 스트림으로 매핑되는 두 개의 테이블을 생성하고 테이블 간 조인을 생성할 수 있습니다.

Q: EMR Kinesis 커넥터는 병합 및 분할 이벤트와 같은 Kinesis 규모 조정 이벤트를 처리합니까?

예. 이러한 구현은 분할 및 병합 이벤트를 처리합니다. Kinesis 커넥터는 개별 Kinesis 샤드(Kinesis 스트림 내 논리적 규모 단위)를 하둡 MapReduce 매핑 작업과 연결합니다. 반복이 이루어지는 논리적 기간에 스트림 내 존재하는 각 고유 샤드는 정확하게 하나의 매핑 작업이 됩니다. 샤드 분할 또는 병합 이벤트가 발생하면, Kinesis는 새로운 고유 샤드 ID를 프로비저닝합니다. 그 결과, MapReduce 프레임워크는 Kinesis에서 읽기 위해 더 많은 매핑 작업을 프로비저닝합니다. 이 모든 작업은 사용자에게 투명하게 이루어집니다.

Q: 내 스트림에 "무활동" 기간이 있는 경우 어떤 일이 발생합니까?

이러한 구현은 사용자가 kinesis.nodata.timeout이라는 파라미터를 구성할 수 있도록 합니다. 예를 들어 kinesis.nodata.timeout이 2분으로 설정되어 있으며, 10분마다 Hive 쿼리를 실행하려 한다고 가정해 보겠습니다. 여기에서 일부 데이터는 마지막 반복(10분 전) 후 스트림에 기록되었습니다. 그러나 현재 새로운 레코드가 수신되지 않고 있습니다. 즉, 스트림에 아무런 활동이 없는 상태입니다. 이 경우 쿼리의 현재 반복이 시작되면 Kinesis 커넥터에서 새로운 레코드가 수신되지 않았음을 알게 됩니다. 커넥터에서는 2분 동안 계속하여 스트림을 폴링합니다. 만약 그동안에 아무 데이터도 수신되지 않는다면 폴링을 중단하며 스트림의 현재 배치에서 이미 읽은 레코드만 처리합니다. 그러나 kinesis.nodata.timeout 간격이 끝나기 전에 새로운 레코드가 수신되면 커넥터는 kinesis.iteration.timeout이라는 파라미터에 해당하는 간격만큼 추가로 대기합니다. 이러한 파라미터를 정의하는 방법을 보려면 자습서를 참조하십시오.

Q: 각 반복에서 계속해서 실패하는 쿼리를 디버깅하려면 어떻게 해야 합니까?

프로세스가 실패하는 경우 현재 하둡 작업을 디버깅할 때 사용하는 것과 같은 도구를 활용할 수 있습니다. 오류 로그를 식별하고 액세스하는 데 도움이 되는 Amazon EMR 웹 콘솔이 이러한 도구에 포함됩니다. EMR 작업 디버깅에 대한 자세한 내용은 여기에서 찾아볼 수 있습니다.

Q: 액세스 권한이 없는 DynamoDB 테이블을 지정하는 경우 어떤 일이 발생합니까?

작업이 실패하며 해당 작업에 대한 오류 로그에 예외가 표시됩니다.

Q: 작업은 실패하지 않았지만 DynamoDB로의 체크포인트 설정이 실패하는 경우 어떤 일이 발생합니까?

작업이 실패하며 해당 작업에 대한 오류 로그에 예외가 표시됩니다.

Q: Kinesis 스트림에서 EMR로의 읽기 처리량을 최대화하려면 어떻게 해야 합니까?

Kinesis 스트림의 처리량은 사용된 인스턴스 크기 및 Kinesis 스트림의 레코드 크기에 따라 증가합니다. 마스터 및 코어 노드의 경우 이 기능을 사용하려면 m1.xlarge 이상을 사용하는 것이 좋습니다. 

Q: Amazon EMR 서비스 수준 계약이란 무엇인가요?

서비스 수준 계약을 참조하세요.

Q: Amazon EMR 서비스 수준 계약에서 제공하는 내용은 무엇입니까?