Azure Data Lake Storage 사용에 대한 모범 사례
이 문서에서는 성능을 최적화하고, 비용을 절감하고, Data Lake Storage 사용 Azure Storage 계정을 보호하는 데 도움이 되는 모범 사례 지침을 제공합니다.
데이터 레이크 구조화에 대한 일반적인 제안은 다음 문서를 참조하세요.
설명서 찾기
Azure Data Lake Storage는 전용 서비스 또는 계정 유형이 아닙니다. 높은 처리량 분석 워크로드를 지원하는 기능 세트입니다. Data Lake Storage 설명서는 이러한 기능을 사용하기 위한 모범 사례 및 지침을 제공합니다. 네트워크 보안 설정, 고가용성 설계 및 재해 복구와 같은 계정 관리의 다른 모든 측면은 Blob 스토리지 설명서 콘텐츠를 참조하세요.
기능 지원 및 알려진 문제 평가
Blob 스토리지 기능을 사용하도록 계정을 구성할 때 다음 패턴을 따릅니다.
Azure 스토리지 계정에서 Blob Storage 기능 지원원 문서를 검토하여 계정에서 기능이 완전히 지원되는지 확인합니다. 일부 기능은 아직 지원되지 않거나 Data Lake Storage 사용 계정에서 부분적으로 지원됩니다. 기능 지원이 지속적으로 확장되고 있으므로 이 문서의 업데이트를 정기적으로 검토해야 합니다.
Azure Data Lake Storage 문서의 알려진 문제를 검토하여 사용하려는 기능에 대한 제한 사항 또는 특별 지침이 있는지 확인합니다.
Data Lake Storage 사용 계정과 관련된 지침은 기능 문서를 검색합니다.
설명서에 사용되는 용어 이해
콘텐츠 집합 간에 이동하면 약간의 용어 차이를 알 수 있습니다. 예를 들어 Blob 스토리지 설명서의 콘텐츠는 파일 대신 Blob이라는 용어를 사용합니다. 기술적으로, 스토리지 계정에 수집하는 파일은 계정의 Blob이 됩니다. 따라서 용어가 올바른 것입니다. 그러나 blob이라는 용어를 사용하면 파일이라는 용어에 익숙할 경우 혼동이 발생할 수 있습니다. 파일 시스템을 참조하는 데 사용되는 컨테이너라는 용어도 볼 수 있습니다. 이러한 용어는 같은 용어로 간주됩니다.
프리미엄 고려
워크로드에 지속적으로 낮은 대기 시간이 필요하거나 높은 초당 입출력 작업(IOP)이 필요한 경우 프리미엄 블록 Blob 스토리지 계정을 고려해야 합니다. 이 유형의 계정은 고성능 하드웨어를 통해 데이터를 사용할 수 있습니다. 데이터는 짧은 대기 시간에 최적화된 SSD(반도체 드라이브)에 저장됩니다. SSD는 기존 하드 드라이브에 비해 더 높은 처리량을 제공합니다. 프리미엄 성능의 스토리지 비용은 더 높지만 트랜잭션 비용은 낮습니다. 따라서 워크로드가 많은 수의 트랜잭션을 실행하는 경우 프리미엄 성능 블록 Blob 계정이 경제적일 수 있습니다.
스토리지 계정을 분석에 사용할 경우 프리미엄 블록 Blob Storage 계정과 함께 Azure Data Lake Storage를 사용하는 것이 좋습니다. Data Lake Storage 사용 계정과 함께 프리미엄 블록 Blob 스토리지 계정을 사용하는 이 조합을 Azure Data Lake에 대한 프리미엄 계층이라고 합니다.
데이터 수집에 최적화
원본 시스템에서 데이터를 수집할 때 원본 하드웨어, 원본 네트워크 하드웨어 또는 스토리지 계정에 대한 네트워크 연결에서 병목 상태가 발생할 수 있습니다.
원본 하드웨어
Azure에서 온-프레미스 머신 또는 VM(Virtual Machines) 중에 무엇을 사용하든, 적절한 하드웨어를 신중하게 선택해야 합니다. 디스크 하드웨어의 경우 SSD(반도체 드라이브)를 사용하고 스핀들 속도가 빠른 디스크 하드웨어를 선택합니다. 네트워크 하드웨어의 경우 되도록이면 가장 빠른 NIC(네트워크 인터페이스 컨트롤러)를 사용합니다. Azure에서는 강력한 디스크와 네트워킹 하드웨어를 갖춘 Azure D14 VM을 사용하는 것이 좋습니다.
스토리지 계정에 대한 네트워크 연결
원본 데이터와 스토리지 계정 간의 네트워크 연결에서 병목 상태가 발생할 수 있습니다. 원본 데이터가 온-프레미스에 있는 경우 Azure ExpressRoute와 함께 전용 링크를 사용하는 것이 좋습니다. 원본 데이터가 Azure에 있는 경우 데이터가 Data Lake Storage 사용 계정과 동일한 Azure 지역에 있는 경우 성능이 가장 좋습니다.
최대 병렬 처리를 위한 데이터 수집 도구 구성
최상의 성능을 얻으려면 가능한 한 많은 읽기 및 쓰기를 병렬로 수행하여 모든 가용 처리량을 사용합니다.
다음 표에는 인기 있는 여러 분석 도구의 주요 설정이 요약되어 있습니다.
| 도구 | 설정 |
|---|---|
| DistCp | -m(mapper) |
| Azure Data Factory | parallelCopies |
| Sqoop | fs.azure.block.size, -m(mapper) |
참고 항목
수집 작업의 전반적인 성능은 데이터 수집에 사용하는 도구와 관련된 다른 요인에 따라 결정됩니다. 최신 지침은 사용하려는 도구의 설명서를 참조하세요.
모든 분석 시나리오에 필요한 처리량을 제공하도록 계정에서 스케일링할 수 있습니다. 기본적으로 Data Lake Storage 사용 계정은 광범위한 사용 사례 범주의 요구 사항을 충족하기 위해 기본 구성에서 충분한 처리량을 제공합니다. 기본 제한에 도달하면 Azure 지원에 문의하여 더 많은 처리량을 제공하도록 계정을 구성할 수 있습니다.
구조 데이터 세트
데이터의 구조를 미리 계획하는 좋습니다. 파일 형식, 파일 크기 및 디렉터리 구조는 모두 성능과 비용에 영향을 미칠 수 있습니다.
파일 형식
데이터를 다양한 형식으로 수집할 수 있습니다. 데이터는 JSON, CSV 또는 XML과 같은 사람이 읽을 수 있는 형식으로 표시할 수도 있고 .tar.gz처럼 압축된 이진 형식으로 표시할 수도 있습니다. 또한 데이터가 다양한 크기로 들어올 수 있습니다. 온-프레미스 시스템에서 SQL 테이블 내보내기의 데이터처럼 데이터가 대형 파일(테라바이트 단위)로 구성될 수 있습니다. IoT(사물 인터넷) 솔루션의 실시간 이벤트 데이터처럼 수많은 소형 파일(킬로바이트 단위)의 형태로 데이터가 들어올 수도 있습니다. 적절한 파일 형식 및 파일 크기를 선택하여 효율성과 비용을 최적화할 수 있습니다.
Hadoop은 정형 데이터의 저장 및 처리에 최적화된 파일 형식 세트를 지원합니다. 일반적인 형식은 Avro, Parquet 및 ORC(Optimized Row Columnar) 형식입니다. 이러한 형식은 전부 기계가 읽을 수 있는 이진 파일 형식이며 파일 크기를 관리할 수 있도록 압축됩니다. 각 파일에는 자체적으로 설명하는 스키마가 포함되어 있습니다. 이러한 형식 간의 차이는 데이터가 저장되는 방식에 있습니다. Avro는 행 기반 형식으로 데이터를 저장하고 Parquet 및 ORC 형식은 열 형식으로 데이터를 저장합니다.
쓰기가 많은 I/O 패턴 또는 여러 행의 레코드를 전체적으로 검색하는 것이 유리한 쿼리 패턴에는 Avro 파일 형식을 사용하는 것이 좋습니다. 예를 들어 Avro 형식은 여러 이벤트/메시지를 연속으로 작성하는 Event Hub 또는 Kafka와 같은 메시지 버스와 잘 작동합니다.
읽기가 많은 I/O 패턴 또는 레코드의 열 하위 집합에 초점을 맞추는 쿼리 패턴에는 Parquet 및 ORC 파일 형식을 사용하는 것이 좋습니다. 읽기 트랜잭션은 전체 레코드를 읽는 대신 특정 열을 검색하도록 최적화할 수 있습니다.
Apache Parquet는 읽기가 많은 분석 파이프라인에 최적화된 오픈 소스 파일 형식입니다. Parquet의 열 형식 스토리지 구조를 사용하면 관련이 없는 데이터를 건너뛸 수 있습니다. 스토리지에서 분석 엔진으로 보낼 데이터 범위를 좁힐 수 있으므로 쿼리가 훨씬 효율적입니다. 또한 유사한 데이터 형식(열의 경우)이 함께 저장되기 때문에, Parquet는 데이터 스토리지 비용을 절감할 수 있는 효율적인 데이터 압축 및 인코딩 체계를 지원합니다. Azure Synapse Analytics, Azure Databricks 및 Azure Data Factory와 같은 서비스에는 Parquet 파일 형식을 활용하는 기본 기능이 있습니다.
파일 크기
파일이 클수록 성능이 향상하고 비용이 절감됩니다.
일반적으로 HDInsight와 같은 분석 엔진에는 나열, 액세스 검사, 다양한 메타데이터 작업 수행과 같은 작업이 관련된 파일별 오버헤드가 있습니다. 데이터를 많은 작은 파일로 저장하는 경우 성능이 저하될 수 있습니다. 일반적으로 보다 높은 성능을 얻으려면 데이터를 큰 크기의 파일(256MB~100GB)로 구성해야 합니다. 일부 엔진과 애플리케이션은 100GB를 초과하는 파일을 효율적으로 처리하는 데 어려움을 겪을 수 있습니다.
파일 크기를 늘리면 트랜잭션 비용도 줄일 수 있습니다. 읽기 및 쓰기 작업 요금은 4메가바이트 단위로 청구되므로, 파일에 4메가바이트가 들어 있든 고작 몇 킬로바이트만 들어 있든 상관없이 작업에 대한 요금이 청구됩니다. 가격 책정 정보는 Azure Data Lake Storage 가격 책정을 참조하세요.
때때로 작은 파일들이 많은 원시 데이터에 대해 데이터 파이프라인의 제어가 제한될 수 있습니다. 일반적으로 시스템에는 다운스트림 응용 프로그램에서 사용하기 위해 작은 파일을 더 큰 파일로 집계하는 일종의 프로세스를 갖추는 것이 좋습니다. 실시간으로 데이터를 처리하는 경우 메시지 broker(예: Event Hubs 또는 Apache Kafka)와 함께 실시간 스트리밍 엔진(예: Azure Stream Analytics 또는 Spark Streaming)을 사용하여 데이터를 더 큰 파일로 저장할 수 있습니다. 작은 파일을 더 큰 파일로 집계할 때 다운스트림 처리를 위해 Apache Parquet와 같은 읽기 최적화 형식으로 저장하는 것이 좋습니다.
디렉터리 구조
워크로드마다 데이터 사용 방식에 대한 요구 사항이 다르지만 IoT(사물 인터넷), 일괄 처리 시나리오 또는 시계열 데이터에 맞게 최적화할 때 고려해야 하는 몇 가지 일반적인 레이아웃이 있습니다.
IoT 구조
IoT 워크로드에서는 수많은 제품, 디바이스, 조직 및 고객과 관련된 많은 데이터가 수집될 수 있습니다. 다운스트림 소비자를 위해 조직, 보안 및 데이터의 효율적인 처리가 가능하도록 디렉터리 레이아웃을 미리 계획해야 합니다. 고려해야 할 일반적인 템플릿은 다음과 같은 레이아웃일 수 있습니다.
- {Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/
예를 들어 비행기 엔진에 대한 영국 내 착륙 원격 분석은 다음 구조와 같이 표시될 수 있습니다.
- UK/Planes/BA1293/Engine1/2017/08/11/12/
이 예제에서는 디렉터리 구조의 끝 부분에 날짜를 배치함으로써 ACL을 사용하여 특정 사용자 및 그룹에 대한 지역 및 주제를 보다 쉽게 보호할 수 있습니다. 시작 부분에 데이터 구조를 배치하면 이러한 지역 및 주제를 보호하기가 훨씬 어렵습니다. 예를 들어 영국 데이터 또는 특정 평면에 대한 액세스 권한만 제공하려면 매시간 디렉터리 아래에 있는 수많은 디렉터리에 대해 별도의 권한을 적용해야 합니다. 또한 시간이 지나면 이 구조의 디렉터리 수가 기하급수적으로 증가합니다.
일괄 처리 작업 구조
일괄 처리에서 일반적으로 사용되는 방법은 데이터를 "내부" 디렉터리에 배치하는 것입니다. 그런 다음, 데이터가 처리되면 다운스트림 프로세스에서 사용할 새 데이터를 "외부" 디렉터리에 배치합니다. 이 디렉터리 구조는 개별 파일에 대한 처리가 필요하지만 대형 데이터 세트에 대한 대규모 병렬 처리가 필요 없을 수도 있는 작업에 종종 사용됩니다. 위에서 권장하는 IoT 구조와 마찬가지로, 좋은 디렉터리 구조에는 지역 및 주제(예: 조직, 제품 또는 생산자)와 같은 항목에 대한 부모 수준 디렉터리가 있습니다. 처리에서 보다 나은 구성, 필터링된 검색, 보안 및 자동화가 가능하도록 구조의 날짜 및 시간을 고려해야 합니다. 날짜 구조의 세분성 수준은 데이터가 업로드되거나 처리되는 간격(예: 시간별, 일별 또는 월별)에 따라 결정됩니다.
데이터 손상 또는 예기치 않은 형식으로 인해 파일 처리가 실패하는 경우가 있습니다. 이러한 경우 디렉터리 구조에서 /bad 폴더를 지원하여 추가 검사를 위해 파일을 이동할 수 있습니다. 또한 일괄 처리 작업은 이러한 불량 파일에 대한 보고 또는 알림을 처리하여 수동으로 개입할 수 있습니다. 다음과 같은 템플릿 구조를 고려합니다.
- {Region}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/
- {Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/
- {Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/
예를 들어 북아메리카 지역의 고객으로부터 고객 업데이트의 일일 데이터 추출 결과를 받는 마케팅 회사는 처리 전과 후에 다음 코드 조각처럼 표시될 수 있습니다.
- NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
- NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv
일괄 처리 데이터가 일반적으로 Hive 또는 기존 SQL 데이터베이스와 같은 데이터베이스에 직접 처리되는 경우, 출력이 이미 Hive 테이블 또는 외부 데이터베이스에 대한 별도의 폴더로 이동하기 때문에 /in 또는 /out 디렉터리가 필요하지 않습니다. 예를 들어 고객이 매일 추출하는 내용은 각각의 해당 디렉터리로 이동합니다. 그러면 Azure Data Factory, Apache Oozie 또는 Apache Airflow와 같은 서비스는 매일 Hive 또는 Spark 작업을 트리거하여 데이터를 처리하고 Hive 테이블에 씁니다.
시계열 데이터 구조
Hive 워크로드의 경우 시계열 데이터의 파티션 정리를 통해 일부 쿼리에서 데이터의 하위 세트만 읽도록 지원하여 성능을 향상시킬 수 있습니다.
시계열 데이터를 수집하는 이러한 파이프라인은 파일 및 폴더에 대해 구조적 명명을 사용하여 파일을 배치하는 경우가 많습니다. 다음은 날짜별로 구성된 데이터에서 일반적으로 나타나는 예입니다.
/DataSet/YYYY/MM/DD/datafile_YYYY_MM_DD.tsv
datetime 정보가 폴더 및 파일 이름 둘 다에 나타납니다.
날짜 및 시간의 일반적인 패턴은 다음과 같습니다.
/DataSet/YYYY/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv
앞에서 설명했듯이, 더 큰 파일 크기와 각 폴더에 포함된 적절한 파일 수의 요건에 맞는 폴더 및 파일 구성을 선택해야 합니다.
보안 설정
Blob 스토리지에 대한 보안 권장 사항 문서의 권장 사항부터 검토합니다. 우발적 또는 악의적인 삭제로부터 데이터를 보호하고, 방화벽 뒤에 있는 데이터를 보호하고, Microsoft Entra ID를 기본 ID 관리 수단으로 사용하는 방법에 대한 모범 사례 지침을 찾을 수 있습니다.
그런 다음, Data Lake Storage 사용 계정과 관련된 지침은 Azure Data Lake Storage 문서의 액세스 제어 모델을 검토합니다. 이 문서는 ACL(액세스 제어 목록)과 함께 Azure RBAC(역할 기반 액세스 제어) 역할을 사용하여 계층적 파일 시스템의 디렉터리 및 파일에 대한 보안 권한을 적용하는 방법을 이해하는 데 도움이 됩니다.
수집, 처리 및 분석
다양한 데이터 원본과 해당 데이터를 Data Lake Storage 지원 계정으로 수집할 수 있는 다양한 방법이 있습니다.
예를 들어 HDInsight 및 Hadoop 클러스터에서 대량의 데이터 세트를 수집하거나 애플리케이션 프로토타입 제작을 위한 소량의 임시 데이터 세트를 수집할 수 있습니다. 애플리케이션, 디바이스, 센서 등의 다양한 원본에서 생성되는 스트리밍된 데이터를 수집할 수 있습니다. 이러한 유형의 데이터에는 도구를 사용하여 이벤트별 데이터를 실시간으로 캡처하고 처리한 다음, 이벤트를 계정에 일괄적으로 쓸 수 있습니다. 페이지 요청 기록과 같은 정보가 포함된 웹 서버 로그를 수집할 수도 있습니다. 로그 데이터의 경우 더 큰 빅 데이터 애플리케이션의 일부로 데이터 업로드 구성 요소를 유연하게 포함할 수 있도록 로그 데이터를 업로드하는 사용자 지정 스크립트 또는 애플리케이션을 작성하는 것이 좋습니다.
계정에서 데이터를 사용할 수 있게 되면 해당 데이터를 분석하고, 시각화를 만들고, 로컬 머신이나 Azure SQL 데이터베이스 또는 SQL Server 인스턴스와 같은 다른 리포지토리에 데이터를 다운로드할 수도 있습니다.
다음 표에는 데이터를 수집, 분석, 시각화 및 다운로드하는 데 사용할 수 있는 권장 도구가 나와 있습니다. 이 표의 링크를 사용하여 각 도구를 구성하고 사용하는 방법에 대한 지침을 찾을 수 있습니다.
| 목적 | 도구 및 도구 지침 |
|---|---|
| 임시 데이터 수집 | Azure portal, Azure PowerShell, Azure CLI, REST, Azure Storage Explorer, Apache DistCp, AzCopy |
| 관계형 데이터 수집 | Azure Data Factory |
| 웹 서버 로그 수집 | Azure PowerShell, Azure CLI, REST, Azure SDK(.NET, Java, Python 및 Node.js), Azure Data Factory |
| HDInsight 클러스터에서 수집 | Azure Data Factory, Apache DistCp, AzCopy |
| Hadoop 클러스터에서 수집 | Azure Data Factory, Apache DistCp, WANdisco LiveData Migrator for Azure, Azure Data Box |
| 대량(테라바이트 단위) 데이터 세트 수집 | Azure ExpressRoute |
| 데이터 처리 및 분석 | Azure Synapse Analytics, Azure HDInsight, Databricks |
| 데이터 시각화 | Power BI, Azure Data Lake Storage 쿼리 가속 |
| 데이터 다운로드 | Azure portal, PowerShell, Azure CLI, REST, Azure SDK(.NET, Java, Python 및 Node.js), Azure Storage Explorer, AzCopy, Azure Data Factory, Apache DistCp |
참고 항목
이 표에는 Data Lake Storage를 지원하는 Azure 서비스의 전체 목록이 반영되지 않습니다. 지원되는 Azure 서비스 목록, 지원 수준을 보려면 Azure Data Lake Storage를 지원하는 Azure 서비스를 참조하세요.
원격 분석 모니터링
사용 및 성능 모니터링은 서비스 운영에 있어서 중요한 부분입니다. 빈번한 작업, 대기 시간이 높은 작업 또는 서비스 쪽 제한을 유발하는 작업을 예로 들 수 있습니다.
스토리지 계정에 대한 모든 원격 분석은 Azure Monitor의 Azure Storage 로그를 통해 사용할 수 있습니다. 이 기능을 통해 스토리지 계정을 Log Analytics 및 Event Hubs와 통합할 수 있을 뿐 아니라 로그를 다른 스토리지 계정에 보관할 수 있습니다. 메트릭 및 리소스 로그의 전체 목록과 관련 스키마를 보려면 Azure Storage 모니터링 데이터 참조를 검토하세요.
로그를 저장하는 위치는 로그에 액세스하는 방법에 대한 계획에 따라 달라집니다. 예를 들어 거의 실시간으로 로그에 액세스하고 로그의 이벤트와 Azure Monitor의 다른 메트릭 간에 상관 관계를 지정하려면 로그를 Log Analytics 작업 영역에 저장하면 됩니다. 이렇게 하면 작업 영역의 StorageBlobLogs 테이블을 열거하는 KQL 및 작성 쿼리를 사용하여 로그를 쿼리할 수 있습니다.
거의 실시간 쿼리 및 장기 보존을 위해 로그를 저장하려는 경우에는 Log Analytics 작업 영역과 스토리지 계정에 로그를 보내도록 진단 설정을 구성하면 됩니다.
Splunk와 같은 다른 쿼리 엔진을 통해 로그에 액세스하려는 경우에는 Event Hub에 로그를 보내고 Event Hub에서 선택한 대상으로 로그를 수집하도록 진단 설정을 구성하면 됩니다.
Azure Monitor의 Azure Storage 로그는 Azure Portal, PowerShell, Azure CLI 및 Azure Resource Manager 템플릿을 통해 사용하도록 설정할 수 있습니다. 대규모 배포의 경우 수정 작업에 대한 전체 지원과 함께 Azure Policy를 사용할 수 있습니다. 자세한 내용은 ciphertxt/AzureStoragePolicy를 참조하세요.