Synapse POC 플레이북: Azure Synapse Analytics의 Apache Spark 풀을 사용한 빅 데이터 분석

아티클
03/25/2023

이 문서에서는 Apache Spark 풀을 위한 효과적인 Azure Synapse Analytics POC(개념 증명) 프로젝트를 준비하고 실행하기 위한 상위 수준 방법론을 제시합니다.

참고 항목

이 문서는 Azure Synapse 개념 증명 플레이북 시리즈 문서의 일부를 구성합니다. 시리즈에 대한 개요는 Azure Synapse 개념 증명 플레이북을 참조하세요.

POC 준비

POC 프로젝트는 Azure Synapse에서 Apache Spark 풀을 활용하는 클라우드 기반 플랫폼에서 빅 데이터 및 고급 분석 환경을 구현할 때 정보에 입각한 비즈니스 결정을 내리는 데 도움이 될 수 있습니다.

POC 프로젝트는 클라우드 기반 빅 데이터 및 고급 분석 플랫폼이 지원해야 하는 주요 목표와 비즈니스 구동 요인을 식별합니다. 주요 메트릭을 테스트하고 데이터 엔지니어링, 기계 학습 모델 빌드 및 학습 요구 사항의 성공에 중요한 주요 동작을 증명합니다. POC는 프로덕션 환경에 배포되도록 디자인되지 않았습니다. 오히려 주요 질문에 초점을 맞춘 단기 프로젝트이며 해당 결과는 삭제할 수 있습니다.

Spark POC 프로젝트 계획을 시작하기 전에 다음을 수행합니다.

조직에서 클라우드로 데이터를 이동하는 방법에 대한 제한 사항 또는 지침을 식별합니다.
빅 데이터 및 고급 분석 플랫폼 프로젝트의 경영진 또는 비즈니스 스폰서를 식별합니다. 클라우드로의 마이그레이션에 대한 지원을 보호합니다.
POC 실행 중에 지원할 수 있는 기술 전문가 및 비즈니스 사용자의 가용성을 식별합니다.

POC 프로젝트 준비를 시작하기 전에 먼저 Apache Spark 설명서를 읽는 것이 좋습니다.

팁

Spark 풀을 처음 사용하는 경우 Azure Synapse Apache Spark 풀로 데이터 엔지니어링 수행 학습 경로를 진행하는 것이 좋습니다.

지금까지는 직접적인 방해 요인이 없다고 확인했으므로 POC 준비를 시작할 수 있습니다. Azure Synapse Analytics의 Apache Spark 풀을 처음 사용하는 경우 Spark 아키텍처에 대한 개요를 확인하고 Azure Synapse에서 작동하는 방법을 알아볼 수 있는 이 설명서를 참조할 수 있습니다.

다음 주요 개념에 대한 이해를 발전시킵니다.

Apache Spark 및 해당 분산 아키텍처
RDD(Resilient Distributed Datasets) 및 파티션(메모리 내 및 물리적)과 같은 Spark 개념
Azure Synapse 작업 영역, 다양한 컴퓨팅 엔진, 파이프라인 및 모니터링
Spark 풀에서 컴퓨팅과 스토리지의 분리
Azure Synapse의 인증 및 권한 부여
Azure Synapse 전용 SQL 풀, Azure Cosmos DB 등과 통합되는 네이티브 커넥터

Azure Synapse는 데이터 처리 요구 사항을 더 잘 관리하고 비용을 제어할 수 있도록 스토리지에서 컴퓨팅 리소스를 분리합니다. Spark 풀의 서버리스 아키텍처를 사용하면 스토리지와 관계없이 Spark 클러스터를 스핀 업/스핀 다운하고 확장/축소할 수 있습니다. Spark 클러스터를 완전히 일시 중지(또는 자동 일시 중지를 설정)할 수 있습니다. 이렇게 하면 사용 중일 때만 컴퓨팅 비용을 지불합니다. 사용하지 않을 때는 스토리지 요금만 부과됩니다. 과도한 데이터 처리 요구 또는 대규모 부하를 위해 Spark 클러스터를 스케일 업한 다음, 덜 집중적인 처리 시간 동안 다시 스케일 다운하거나 완전히 종료할 수 있습니다. 클러스터를 효과적으로 스케일링하고 일시 중지하여 비용을 줄일 수 있습니다. Spark POC 테스트에는 다른 규모에서 가격과 성능을 비교하기 위해 다양한 규모(소형, 중간 및 대형)의 데이터 수집 및 데이터 처리가 포함되어야 합니다. 자세한 내용은 Azure Synapse Analytics Apache Spark 풀 조정 스케일링을 참조하세요.

시나리오에 가장 적합한 항목을 결정할 수 있도록 다양한 Spark API 집합 간의 차이점을 이해하는 것이 중요합니다. 팀의 기존 기술 집합을 활용하여 더 나은 성능 또는 사용 편의성을 제공하는 항목을 선택할 수 있습니다. 자세한 내용은 A Tale of Three Apache Spark APIs: RDDs, DataFrames, and Datasets(세 가지 Apache Spark API: RDD, DataFrames 및 Datasets)를 참조하세요.

데이터 및 파일 분할은 Spark에서 약간 다르게 작동합니다. 차이점을 이해하면 성능을 최적화하는 데 도움이 됩니다. 자세한 내용은 Apache Spark 설명서: 파티션 검색 및 파티션 구성 옵션을 참조하세요.

목표 설정

성공적인 POC 프로젝트에는 계획이 필요합니다. 먼저 POC를 수행하는 이유를 파악하여 실제 동기를 완전히 이해합니다. 동기에는 현대화, 비용 절감, 성능 향상 또는 통합 환경이 포함될 수 있습니다. POC에 대한 명확한 목표와 성공을 정의하는 조건을 문서화해야 합니다. 확인할 사항:

어떤 POC의 결과를 원하시나요?
이러한 결과로 무엇을 수행하나요?
이러한 결과는 누가 사용하나요?
성공적인 POC를 정의하는 것은 무엇인가요?

POC는 제한된 개념 및 기능 집합을 신속하게 증명하기 위한 짧고 집중적인 활동이어야 합니다. 이러한 개념과 기능은 전체 워크로드를 대표해야 합니다. 증명할 항목 목록이 긴 경우 둘 이상의 POC를 계획할 수 있습니다. 이 경우 POC 간의 게이트를 정의하여 다음 게이트를 계속 진행해야 하는지 여부를 결정합니다. Azure Synapse에서 Spark 풀 및 Notebook을 사용할 수 있는 다양한 전문 역할을 고려할 때 여러 POC를 실행하도록 선택할 수 있습니다. 예를 들어 하나의 POC는 수집 및 처리와 같은 데이터 엔지니어링 역할에 대한 요구 사항에 초점을 맞출 수 있습니다. 또 다른 POC는 ML(기계 학습) 모델 개발에 집중할 수 있습니다.

POC 목표를 고려할 때 목표를 구체화하는 데 도움이 되는 다음 질문을 스스로에게 제시합니다.

기존 빅 데이터 및 고급 분석 플랫폼(온-프레미스 또는 클라우드)에서 마이그레이션하고 있나요?
마이그레이션 중이지만 기존 수집 및 데이터 처리를 최대한 적게 변경하려고 하나요? Spark 간 Spark 마이그레이션 또는 Hadoop/Hive-Spark 마이그레이션을 예로 들 수 있습니다.
마이그레이션 중이지만 그 과정에서 몇 가지 광범위한 개선 작업을 수행하려고 하나요? 예를 들어 MapReduce 작업을 Spark 작업으로 다시 작성하거나, 레거시 RDD 기반 코드를 DataFrame/Dataset 기반 코드로 변환할 수 있습니다.
완전히 새로운 빅 데이터 및 고급 분석 플랫폼(그린필드 프로젝트)을 빌드하려고 하나요?
현재 문제점은 무엇인가요? 확장성, 성능 또는 유연성을 예로 들 수 있습니다.
어떤 새로운 비즈니스 요구 사항을 지원해야 하나요?
충족해야 하는 SLA는 무엇인가요?
어떤 것이 워크로드가 되나요? ETL, 일괄 처리, 스트림 처리, 기계 학습 모델 학습, 분석, 보고 쿼리 또는 대화형 쿼리를 예로 들 수 있습니다.
프로젝트를 소유할 사용자는 어떤 기술을 보유하고 있나요(POC를 구현해야 하나요)? PySpark와 Scala 기술, Notebook과 IDE 환경을 예로 들 수 있습니다.

다음은 POC 목표 설정의 몇 가지 예입니다.

POC를 수행하는 이유는 무엇인가요?
- 빅 데이터 워크로드에 대한 데이터 수집 및 처리 성능이 새 SLA를 충족한다는 것을 알아야 합니다.
- 거의 실시간 스트림 처리가 가능한지 여부와 지원할 수 있는 처리량을 알아야 합니다. (비즈니스 요구 사항을 지원할 수 있나요?)
- 기존 데이터 수집 및 변환 프로세스가 적합한지와 개선이 필요한 부분을 파악해야 합니다.
- 데이터 통합 런타임을 단축할 수 있는지와 어느 정도 단축할 수 있는지 알아야 합니다.
- 데이터 과학자가 Spark 풀에서 필요에 따라 기계 학습 모델을 빌드 및 학습시키고 AI/ML 라이브러리를 활용할 수 있는지 알아야 합니다.
- 클라우드 기반 Synapse Analytics로의 전환이 비용 목표를 충족하나요?
이 PoC를 마치면 다음 결과를 얻게 됩니다.
- 일괄 처리 및 실시간 스트리밍 둘 다에 대한 데이터 처리 성능 요구 사항을 충족할 수 있는지 확인하는 데이터가 제공됩니다.
- 사용 사례를 지원하는 다른 모든 데이터 형식(정형, 반정형 및 비정형)의 수집 및 처리를 테스트할 것입니다.
- 기존의 복잡한 데이터 처리 중 일부를 테스트하고 데이터 통합 포트폴리오를 새 환경으로 마이그레이션하기 위해 완료해야 하는 작업을 식별할 수 있습니다.
- 데이터 수집 및 처리를 테스트하고 기록 데이터의 초기 마이그레이션 및 로드에 필요한 작업을 예측하고 데이터 수집(ADF(Azure Data Factory), Distcp, Databox 등)을 마이그레이션하는 데 필요한 작업을 예측하는 데이터 포인트를 알게 됩니다.
- 데이터 수집 및 처리를 테스트하고 ETL/ELT 처리 요구 사항을 충족할 수 있는지 확인할 수 있습니다.
- 구현 프로젝트를 완료하는 데 필요한 작업을 보다 잘 예측할 수 있는 인사이트를 얻게 됩니다.
- 규모 및 스케일링 옵션을 테스트하고, 더 나은 가격-성능 설정을 위해 플랫폼을 더 잘 구성할 수 있는 데이터 포인트를 알게 됩니다.
- 더 많은 테스트가 필요할 수 있는 항목 목록을 얻게 됩니다.

프로젝트 계획

목표를 사용하여 특정 테스트를 식별하고 식별한 출력을 제공합니다. 각 목표와 예상 결과를 지원하기 위한 테스트가 1개 이상 있는지 확인하는 것이 중요합니다. 또한 특정 데이터 수집, 일괄 처리 또는 스트림 처리와 실행될 다른 모든 프로세스를 식별하여 매우 구체적인 데이터 세트 및 코드베이스를 식별할 수 있습니다. 이 특정 데이터 세트 및 코드베이스는 POC의 범위를 정의합니다.

다음은 계획에 필요한 특이성 수준의 예입니다.

목표 A: 정의된 SLA에 따라 일괄 처리 데이터의 데이터 수집 및 처리에 대한 요구 사항을 충족할 수 있는지 여부를 알아야 합니다.
결과 A: 일괄 처리 데이터 수집 및 처리가 데이터 처리 요구 사항 및 SLA를 충족할 수 있는지 여부를 결정하는 데이터를 얻게 됩니다.
- 테스트 A1: 처리 쿼리 A, B 및 C는 데이터 엔지니어링 팀에서 일반적으로 실행하므로 좋은 성능 테스트로 식별됩니다. 또한 전체 데이터 처리 요구 사항을 나타냅니다.
- 테스트 A2: 처리 쿼리 X, Y 및 Z는 거의 실시간 스트림 처리 요구 사항을 포함하므로 좋은 성능 테스트로 식별됩니다. 또한 전체 이벤트 기반 스트림 처리 요구 사항을 나타냅니다.
- 테스트 A3: Spark 클러스터의 다양한 규모(다양한 작업자 노드 수, 작업자 노드의 크기(예: 소형, 중간 및 대형) 및 실행기의 수와 크기)에서 이러한 쿼리의 성능을 기존 시스템에서 얻은 벤치마크와 비교합니다. 수확 체감의 법칙을 염두에 두세요. 더 많은 리소스를 추가(스케일 업 또는 스케일 아웃)하면 병렬 처리를 달성하는 데 도움이 될 수 있지만, 병렬 처리를 달성하기 위한 각 시나리오에는 고유한 특정 제한이 있습니다. 테스트에서 식별된 각 사용 사례에 대한 최적의 구성을 검색합니다.
목표 B: 데이터 과학자가 이 플랫폼에서 기계 학습 모델을 빌드하고 학습할 수 있는지 알아야 합니다.
결과 B: Spark 풀 또는 SQL 풀의 데이터에 대해 학습하고 다른 기계 학습 라이브러리를 활용하여 일부 기계 학습 모델을 테스트합니다. 이러한 테스트는 새 환경으로 마이그레이션할 수 있는 기계 학습 모델을 결정하는 데 도움이 됩니다.
- 테스트 B1: 특정 기계 학습 모델이 테스트됩니다.
- 테스트 B2: 요구 사항에 맞게 Spark(Spark MLLib)와 함께 제공되는 기본 기계 학습 라이브러리와 Spark에 설치할 수 있는 추가 라이브러리(예: scikit-learn)를 테스트합니다.
목표 C: 데이터 수집을 테스트하고 다음과 같은 데이터 포인트를 얻게 됩니다.
- 데이터 레이크 및/또는 Spark 풀로의 초기 기록 데이터 마이그레이션을 위한 작업을 예측합니다.
- 기록 데이터를 마이그레이션하는 방법을 계획합니다.
결과 C: 환경에서 달성할 수 있는 데이터 수집 속도를 테스트하고 결정하고, 사용 가능한 기간 동안 데이터 수집 속도가 기록 데이터를 마이그레이션하기에 충분한지 여부를 확인할 수 있습니다.
- 테스트 C1: 기록 데이터 마이그레이션의 다양한 접근 방식을 테스트합니다. 자세한 내용은 Azure 간 데이터 전송을 참조하세요.
- 테스트 C2: ExpressRoute의 할당된 대역폭을 식별하고 인프라 팀의 제한 설정이 있는지 확인합니다. 자세한 내용은 Azure ExpressRoute란?(대역폭 옵션)을 참조하세요.
- 테스트 C3: 온라인 및 오프라인 데이터 마이그레이션 모두에 대한 데이터 전송 속도를 테스트합니다. 자세한 내용은 복사 작업 성능 및 확장성 가이드를 참조하세요.
- 테스트 C4: ADF, Polybase 또는 COPY 명령을 사용하여 데이터 레이크에서 SQL 풀로의 데이터 전송을 테스트합니다. 자세한 내용은 Azure Synapse Analytics의 전용 SQL 풀에 대한 데이터 로드 전략을 참조하세요.
목표 D: 증분 데이터 로드의 데이터 수집 속도를 테스트하고 데이터 레이크 및/또는 전용 SQL 풀에 대한 데이터 수집 및 처리 기간을 에측하기 위한 데이터 포인트를 얻게 됩니다.
결과 D: 데이터 수집 속도를 테스트하고 데이터 수집 및 처리 요구 사항이 식별된 접근 방식을 충족할 수 있는지 여부를 확인할 수 있습니다.
- 테스트 D1: 일별 업데이트 데이터 수집 및 처리를 테스트합니다.
- 테스트 D2: Spark 풀에서 전용 SQL 풀 테이블로의 처리된 데이터 로드를 테스트합니다. 자세한 내용은 Apache Spark용 Azure Synapse Dedicated SQL 풀 커넥터를 참조하세요.
- 테스트 D3: 최종 사용자 쿼리를 실행하는 동안 일별 업데이트 로드 프로세스를 동시에 실행합니다.

여러 테스트 시나리오를 추가하여 테스트를 구체화해야 합니다. Azure Synapse를 사용하면 성능과 동작을 비교하기 위해 다양한 크기(작업자 노드 수, 작업자 노드의 크기(예: 소형, 중간 및 대형)를 쉽게 테스트할 수 있습니다.

몇 가지 테스트 시나리오는 다음과 같습니다.

Spark 풀 테스트 A: 여러 노드 형식(소형, 중간 및 대형)과 다양한 작업자 노드 수에서 데이터 처리를 실행합니다.
Spark 풀 테스트 B: 커넥터를 사용하여 Spark 풀에서 전용 SQL 풀로 처리된 데이터를 로드/검색합니다.
Spark 풀 테스트 C: Azure Synapse Link를 통해 Spark 풀에서 Azure Cosmos DB로 처리된 데이터를 로드/검색합니다.

POC 데이터 세트 평가

식별한 특정 테스트를 사용하여 테스트를 지원할 데이터 세트를 선택합니다. 이 데이터 세트를 검토하는 데는 시간이 걸립니다. 데이터 세트가 콘텐츠, 복잡성 및 규모 측면에서 향후 처리를 적절하게 나타내는지 확인해야 합니다. 너무 작은(1TB 미만) 데이터 세트를 사용하면 대표적인 성능을 얻을 수 없으므로 피합니다. 반대로 POC가 전체 데이터 마이그레이션이 되어서는 안 되므로 너무 큰 데이터 세트를 사용하지 마세요. 성능 비교에 사용할 수 있도록 기존 시스템에서 적절한 벤치마크를 가져와야 합니다.

Important

데이터를 클라우드로 이동하기 전에 차단 요소가 있는지 비즈니스 소유자에게 확인합니다. 데이터를 클라우드로 이동하기 전에 수행해야 하는 보안 또는 개인 정보 보호 문제 또는 데이터 난독 처리 요구 사항을 식별합니다.

개략적인 아키텍처 만들기

제안된 향후 상태 아키텍처의 개략적인 아키텍처에 따라 POC의 일부를 구성할 구성 요소를 식별합니다. 개괄적인 향후 상태 아키텍처에는 많은 데이터 원본과 데이터 소비자, 빅 데이터 구성 요소, 기계 학습 및 AI(인공 지증) 데이터 소비자가 포함될 수 있습니다. POC 아키텍처는 특히 POC의 일부가 될 구성 요소를 식별해야 합니다. 중요한 것은 POC 테스트에 포함되지 않을 구성 요소를 식별해야 한다는 것입니다.

이미 Azure를 사용 중인 경우 POC 중에 사용할 수 있는 기존 리소스(Microsoft Entra ID, ExpressRoute 등)를 식별합니다. 또한 조직에서 사용하는 Azure 지역을 식별합니다. 이제 ExpressRoute 연결의 처리량을 식별하고 POC가 프로덕션 시스템에 부정적인 영향을 주지 않고 해당 처리량의 일부를 사용할 수 있는지를 다른 비즈니스 사용자와 확인할 수 있는 적절한 시기입니다.

자세한 내용은 빅 데이터 아키텍처를 참조하세요.

POC 리소스 식별

특히 POC를 지원하는 데 필요한 기술 리소스 및 시간 약정을 식별합니다. POC에는 다음이 필요합니다.

요구 사항 및 결과를 감독하는 비즈니스 담당자
POC에 대한 데이터를 소싱하고 기존 프로세스 및 논리에 대한 지식을 제공하는 애플리케이션 데이터 전문가
Apache Spark 및 Spark 풀 전문가
POC 테스트를 최적화하는 전문가 고문
POC 프로젝트의 특정 구성 요소에 필요하지만 POC 기간 동안 반드시 필요하지는 않은 리소스. 이러한 리소스에는 네트워크 관리자, Azure 관리자, Active Directory 관리자, Azure Portal 관리자 등이 포함될 수 있습니다.
필요한 모든 Azure 서비스 리소스가 프로비저닝되고 스토리지 계정에 대한 액세스를 포함하여 필요한 수준의 액세스 권한이 부여되었는지 확인합니다.
POC 범위의 모든 데이터 원본에서 데이터를 검색하는 데 필요한 데이터 액세스 권한이 있는 계정이 있는지 확인합니다.

팁

POC를 지원하기 위해 전문가 고문을 고용하는 것이 좋습니다. Microsoft 파트너 커뮤니티에는 Azure Synapse를 평가(assess), 평가(evaluate) 또는 구현하는 데 도움을 줄 수 있는 전문 컨설턴트가 전 세계에 있습니다.

타임라인 설정

POC 계획 세부 정보를 검토하고 비즈니스 요구 사항을 검토하여 POC에 대한 시간 프레임을 식별합니다. POC 목표를 완료하는 데 필요한 시간을 현실적으로 예측합니다. POC를 완료하는 시간은 POC 데이터 세트의 크기, 테스트의 수와 복잡성, 테스트할 인터페이스 수의 영향을 받습니다. POC가 4주 이상 실행될 것으로 예상되는 경우 가장 중요한 목표에만 집중하도록 범위를 줄이는 것이 좋습니다. 계속하기 전에 모든 잠재 고객 리소스 및 스폰서로부터 승인 및 약정을 받아야 합니다.

POC 실행

모든 프로덕션 프로젝트의 엄격한 규칙에 따라 POC 프로젝트를 구현합니다. 계획에 따라 프로젝트를 실행하고 변경 요청 프로세스를 관리하여 POC 범위의 무절제한 증가를 방지합니다.

개괄적인 작업의 몇 가지 예는 다음과 같습니다.

Synapse 작업 영역, Spark 풀 및 전용 SQL 풀, 스토리지 계정 및 POC 계획에서 식별된 모든 Azure 리소스를 만듭니다.
POC 데이터 세트를 로드합니다.
- 원본에서 추출하거나 Azure에서 샘플 데이터를 만들어 Azure에서 데이터를 사용할 수 있도록 합니다. 자세한 내용은 다음을 참조하세요.
- Spark 풀 및 전용 SQL 풀에 대한 전용 커넥터를 테스트합니다.
기존 코드를 Spark 풀로 마이그레이션합니다.
- Spark에서 마이그레이션하는 경우 Spark 풀이 오픈 소스 Spark 배포를 활용한다는 점을 감안하면 마이그레이션 작업이 간단해질 수 있습니다. 그러나 핵심 Spark 기능 위에서 공급업체별 기능을 사용하는 경우 이러한 기능을 Spark 풀 기능에 올바르게 매핑해야 합니다.
- Spark가 아닌 시스템에서 마이그레이션하는 경우 마이그레이션 작업은 관련된 복잡성에 따라 달라집니다.
테스트를 실행합니다.
- 여러 Spark 풀 클러스터에서 여러 테스트를 병렬로 실행할 수 있습니다.
- 결과를 사용 가능하고 쉽게 이해할 수 있는 형식으로 기록합니다.
문제 해결 및 성능을 모니터링합니다. 자세한 내용은 다음을 참조하세요.
Spark 기록 서버의 진단 탭을 열어 데이터 기울이기, 시간 기울이기 및 실행기 사용량 비율을 모니터링합니다.