Synapse POC 플레이북: Azure Synapse Analytics의 서버리스 SQL 풀을 사용한 데이터 레이크 탐색

아티클
06/01/2023

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

참고 항목

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

POC 준비

POC 프로젝트는 Azure Synapse에서 서버리스 SQL 풀을 활용하는 클라우드 기반 플랫폼에서 빅 데이터 및 고급 분석 환경을 구현할 때 정보에 입각한 비즈니스 결정을 내리는 데 도움이 될 수 있습니다. 데이터 레이크에서 데이터를 살펴보거나 이러한 데이터에서 인사이트를 얻거나, 기존 데이터 변환 파이프라인을 최적화해야 하는 경우 서버리스 SQL 풀을 사용하여 이점을 얻을 수 있습니다. 다음 시나리오에 적합합니다.

기본 검색 및 탐색: 데이터 레이크에서 다양한 형식(Parquet, CSV, JSON)으로 저장된 데이터를 빠르게 추론하여 데이터 레이크에서 인사이트를 잠금 해제하는 방법을 계획할 수 있습니다.
논리적 데이터 웨어하우스: 데이터를 재배치 및 변환하지 않고도 원시 데이터 또는 서로 다른 데이터를 기반으로 하여 관계형 추상화를 제공하여 항상 데이터의 최신 보기를 사용할 수 있습니다.
데이터 변환: T-SQL을 사용하여 간단하고 확장 가능하며 성능이 뛰어난 데이터 레이크 쿼리를 실행합니다. 쿼리 결과를 BI(비즈니스 인텔리전스) 도구에 피드하거나 관계형 데이터베이스에 로드할 수 있습니다. 대상 시스템에는 Azure Synapse 전용 SQL 풀 또는 Azure SQL Database가 포함될 수 있습니다.

서버리스 SQL 풀에서는 다음과 같은 다양한 전문가 역할을 활용할 수 있습니다.

데이터 엔지니어는 데이터 레이크를 탐색하고 서버리스 SQL 풀을 사용하여 데이터를 변환 및 준비하고, 데이터 변환 파이프라인을 단순화할 수 있습니다.
데이터 과학자는 OPENROWSET T-SQL 함수와 자동 스키마 추론을 사용하여 데이터 레이크에 저장된 데이터의 내용과 구조를 신속하게 추론할 수 있습니다.
데이터 분석가는 서버리스 SQL 풀에 연결할 수 있는 기본 쿼리 도구에서 T-SQL 쿼리를 작성할 수 있습니다. 데이터 과학자 또는 데이터 엔지니어가 만든 Spark 외부 테이블의 데이터를 탐색할 수 있습니다.
BI 전문가는 Data Lake 또는 Spark 테이블에 연결하는 Power BI 보고서를 신속하게 만들 수 있습니다.

서버리스 SQL 풀 POC 프로젝트는 서버리스 SQL 풀이 지원하도록 디자인된 주요 목표와 비즈니스 구동 요인을 식별합니다. 또한 주요 기능을 테스트하고, 구현 결정을 지원하는 메트릭을 수집합니다. POC는 프로덕션 환경에 배포되도록 디자인되지 않았습니다. 오히려 주요 질문에 초점을 맞춘 단기 프로젝트이며 해당 결과는 삭제할 수 있습니다.

서버리스 SQL 풀 POC 프로젝트 계획을 시작하기 전에 다음을 수행합니다.

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

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

팁

서버리스 SQL 풀을 처음 사용하는 경우 Azure Synapse 서버리스 SQL 풀을 사용하여 데이터 분석 솔루션 빌드 학습 경로를 통해 작업하는 것이 좋습니다.

목표 설정

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

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

POC는 제한된 개념 및 기능 집합을 신속하게 증명하기 위한 짧고 집중적인 활동이어야 합니다. 이러한 개념과 기능은 전체 워크로드를 대표해야 합니다. 증명할 항목 목록이 긴 경우 둘 이상의 POC를 계획할 수 있습니다. 이 경우 POC 간의 게이트를 정의하여 다음 게이트를 계속 진행해야 하는지 여부를 결정합니다. 서버리스 SQL 풀을 사용할 수 있는 다양한 전문 역할과 서버리스 SQL 풀이 지원하는 다양한 시나리오를 고려할 때 여러 POC를 실행하도록 선택할 수 있습니다. 예를 들어 한 POC는 다양한 형식의 데이터 검색 및 탐색과 같은 데이터 과학자 역할에 대한 요구 사항에 초점을 맞출 수 있습니다. 또 다른 POC는 데이터 변환 및 논리 데이터 웨어하우스 만들기와 같은 데이터 엔지니어링 역할에 대한 요구 사항에 초점을 맞출 수 있습니다.

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

기존 빅 데이터 및 고급 분석 플랫폼(온-프레미스 또는 클라우드)에서 마이그레이션하고 있나요?
마이그레이션 중이지만 기존 수집 및 데이터 처리를 최대한 적게 변경하려고 하나요?
마이그레이션 중이지만 그 과정에서 몇 가지 광범위한 개선 작업을 수행하려고 하나요?
완전히 새로운 빅 데이터 및 고급 분석 플랫폼(그린필드 프로젝트)을 빌드하려고 하나요?
현재 문제점은 무엇인가요? 확장성, 성능 또는 유연성을 예로 들 수 있습니다.
어떤 새로운 비즈니스 요구 사항을 지원해야 하나요?
충족해야 하는 SLA는 무엇인가요?
어떤 것이 워크로드가 되나요? 다양한 데이터 형식에 대한 데이터 탐색, 기본 탐색, 논리 데이터 웨어하우스, 데이터 준비 및/또는 변환, T-SQL 대화형 분석, Spark 테이블의 T-SQL 쿼리 또는 데이터 레이크에 대한 쿼리 보고 등을 예로 들 수 있습니다.
프로젝트를 소유할 사용자는 어떤 기술을 보유하고 있나요(POC를 구현해야 하나요)?

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

POC를 수행하는 이유는 무엇인가요?
- 서버리스 SQL 풀을 사용하여 저장하는 모든 원시 파일 형식을 탐색할 수 있는지 알아야 합니다.
- 데이터 엔지니어가 새 데이터 피드를 신속하게 평가할 수 있는지 알아야 합니다.
- 서버리스 SQL 풀을 사용할 때의 데이터 레이크 쿼리 성능이 데이터 탐색 요구 사항을 충족하는지 알아야 합니다.
- 서버리스 SQL 풀이 일부 시각화 및 보고 요구 사항에 적합한지 알아야 합니다.
- 서버리스 SQL 풀이 일부 데이터 수집 및 처리 요구 사항에 적합한지 알아야 합니다.
- Azure Synapse로의 이동이 예산을 충족하는지 알아야 합니다.
이 PoC를 마치면 다음 결과를 얻게 됩니다.
- 서버리스 SQL 풀에 적합한 데이터 변환을 식별하는 데이터를 얻게 됩니다.
- 데이터 시각화 중에 서버리스 SQL 풀을 가장 잘 사용할 수 있는 시기를 식별하는 데이터를 얻게 됩니다.
- 데이터 엔지니어와 데이터 과학자가 새 플랫폼을 얼마나 쉽게 채택할 수 있는지를 알 수 있는 데이터를 얻게 됩니다.
- 구현 또는 마이그레이션 프로젝트를 완료하는 데 필요한 작업을 보다 잘 예측할 수 있는 인사이트를 얻게 됩니다.
- 더 많은 테스트가 필요할 수 있는 항목 목록을 얻게 됩니다.
- 필요한 데이터가 있고 서버리스 SQL 풀이 클라우드 기반 빅 데이터 및 고급 분석 플랫폼을 지원하는 방법을 결정하는 것으로 확인된 테스트를 완료한 경우 POC가 성공합니다.
- 다음 단계로 이동할 수 있는지 또는 결정을 마무리하기 위해 더 많은 POC 테스트가 필요한지를 결정할 수 있습니다.
- 특정 데이터 포인트에서 지원하는 건전한 비즈니스 결정을 내릴 수 있습니다.

프로젝트 계획

목표를 사용하여 특정 테스트를 식별하고 식별한 출력을 제공합니다. 각 목표와 예상 결과를 지원하기 위한 테스트가 1개 이상 있는지 확인하는 것이 중요합니다. 또한 특정 데이터 탐색 및 분석 작업, 특정 변환 및 테스트하려는 특정 기존 처리를 식별합니다. 사용할 수 있는 특정 데이터 세트 및 코드베이스를 식별합니다.

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

목표: 데이터 엔지니어가 필요한 SLA 내에서 "매일 일괄 처리 원시 파일 유효성 검사"라는 기존 ETL 프로세스에 해당하는 처리를 수행할 수 있는지 여부를 알아야 합니다.
출력: T-SQL 쿼리를 사용하여 필요한 SLA 내에서 "일별 일괄 처리 원시 파일 유효성 검사" ETL 프로세스를 실행할 수 있는지 여부를 결정하는 데이터가 있습니다.
테스트: 유효성 검사 쿼리 A, B 및 C는 데이터 엔지니어링 부서에서 식별하며 전체 데이터 처리 요구 사항을 나타냅니다. 이러한 쿼리의 성능을 기존 시스템에서 얻은 벤치마크와 비교합니다.

POC 데이터 세트 평가

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

Important

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

개략적인 아키텍처 만들기

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

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

POC 리소스 식별

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

요구 사항 및 결과를 감독하는 비즈니스 담당자
POC에 대한 데이터를 소싱하고 기존 프로세스 및 논리에 대한 지식을 제공하는 애플리케이션 데이터 전문가
서버리스 SQL 풀 전문가
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 범위의 무절제한 증가를 방지합니다.

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

POC 계획에서 식별된 Synapse 작업 영역, 스토리지 계정 및 Azure 리소스를 만듭니다.
요구 사항에 따라 네트워킹 및 보안을 설정합니다.
POC 팀 구성원에게 적절한 액세스 권한을 부여합니다. Azure Storage에서 직접 파일에 액세스하기 위한 권한에 대해서는 이 문서를 참조하세요.
POC 데이터 세트를 로드합니다.
테스트를 구현 및 구성하고 기존 코드를 서버리스 SQL 풀 스크립트 및 뷰로 마이그레이션합니다.
테스트를 실행합니다.
- 많은 테스트를 병렬로 실행할 수 있습니다.
- 결과를 사용 가능하고 쉽게 이해할 수 있는 형식으로 기록합니다.
문제 해결 및 성능을 모니터링합니다.
결과를 평가하고 찾은 내용을 제시합니다.
기술 관련자 및 비즈니스와 협력하여 프로젝트의 다음 단계를 계획합니다. 다음 단계는 후속 POC 또는 프로덕션 구현일 수 있습니다.