[AWS Data Engineering] 11장. Amazon Athena를 사용한 임시 쿼리
Amazon Athena는SQL을 사용하여 데이터 레이크의 데이터를 직접 쿼리하고 다양한 다른 데이터베이스를 쿼리할 수 있는 완전 관리형 서버리스 서비스입니다.
이 장에서는 Athena에 대해 자세히 살펴봅니다.
1. Amazon Athena - 데이터 레이크를 위한 인플레이스 SQL 분석
SQL(Structured Query Language)은 수십 년 동안 데이터 쿼리를 위한 매우 인기 있는 언어로 입니다. 매일 전 세계 수백만명의 사람들이 SQL을 직접 사용하여 다양한 데이터베이스의 데이터를 탐색하고 있으며 더 많은 사람들이 내부적으로 SQL을 사용하여 데이터베이스를 쿼리 하는 애플리케이션을 사용합니다.
2016년 말, AWS는 고객이 아마존 S3에 존재하는 구조화 및 반구조화 데이터를 직접 쿼리할 수 있는 새로운 서비스인 Amazon Athena의 출시를 발표했습니다. 아마존은 아테나가 완전한 표준 SQL 지원을 갖춘 프레스토의 관리형 버전이라고 언급했고, 이는 서버리스 서비스로서의 Presto SQL 분석 엔진의 힘을 AWS 고객들에게 제공하였습니다.
SQL은 크게 두 부분으로 나뉩니다.
- 데이터 정의 언어(DDL) : 데이터베이스 개체를 만들고 수정하는 데 사용
- 데이터 조작 언어(DML) : 데이터를 쿼리하고 조작하는 데 사용
2021년에 AWS는 Amazon Athena 엔진을 DDL 문용 HiveQL 및 DML 문용 Presto 버전 0.217을 기반으로 하는 v2로 업그레이드했습니다.
Amazon Athena에는 쿼리 중인 데이터에 대한 메타데이터를 제공하는 Hive 호환 데이터 카탈로그가 필요합니다. 카탈로그는 논리적 뷰를 제공하며, 이는 Amazon S3에 저장된 물리적 파일에 매핑됩니다. Athena는 원래 자체 데이터 카탈로그를 가지고 있었지만 오늘날 Hive 호환 데이터 저장소로 AWS Glue 데이터 카탈로그를 사용해야 합니다.
2. Amazon Athena 쿼리를 최적화하기 위한 팁과 요령
원시 데이터가 데이터 레이크에 수집되면 Glue 크롤러를 사용하거나 Athena와 함께 DDL문을 실행하여 테이블을 정의함으로써 AWS Glue 데이터 카탈로그에 해당 데이터에 대한 테이블을 즉시 생성할 수 있습니다. 테이블이 생성되면 Amazon Athena를 사용하여 데이터에 대해 SQL쿼리를 실행하여 테이블 탐색을 시작할 수 있습니다.
그러나 원시 데이터는 종종 CSV 또는 JSON과 같은 일반 텍스트 형식으로 수집됩니다. 대규모 데이터 세트에 대해 복잡한 쿼리를 실행해야 하는 경우 이러한 원시 형식은 쿼리에 효율적이지 않기 때문에 기본 Athena 쿼리 엔진을 최대한 활용하기 위해 작성하는 SQL 쿼리를 최적화할 수 있는 방법도 있습니다.
이 섹션에서는 성능 향상과 비용 절감을 위해 분석을 최적화할 수 있는 몇 가지 방법을 검토합니다.
1) 공통 파일 형식 및 레이아웃 최적화
데이터 엔지니어가 raw 파일에 적용할 수 있는 가장 효과적이고 쉬운 변환은 원시 파일을 최적화된 파일 형식으로 변환하고 파일의 레이아웃을 최적화된 방식으로 구성하는 것입니다.
원시 소스 파일을 최적화된 파일 형식으로 변환
Apache Parquet은 분석 및 CSV 또는 JSON과 같은 원시 데이터 형식보다 훨씬 더 성능이 좋습니다. 따라서 원시 소스 파일을 Parquet와 같은 형식으로 변환하는 것은 데이터 엔지니어가 Athena 쿼리의 성능을 개선하기 위해 수행할 수 있는 가장 중요한 작업 중 하나입니다.
Amazon Athena는 CTAS(선택 항목으로 테이블 생성; Create Table As Select)라는 개념을 사용하여 파일을 변환할 수 있습니다. 이 접근 방식에서는 Athena를 사용하여 CTAS 문을 실행하고 Athena에게 다른 테이블에 대한 SQL select 문을 기반으로 새 테이블을 생성하도록 지시합니다.
다음은 Athena에서 customers_csv 테이블의 Parquet 버전을 생성하는 SQL문입니다.
CREATE TABLE customers_parquet
WITH (
format = 'Parquet',
parquet_compression = 'SNAPPY')
AS SELECT *
FROM customers_csv;
특정 데이터 세트를 정기적으로 가져오는 경우 대부분의 시나리오에서 Parquet 형식으로 변환을 수행하도록 AWS Glue 작업을 구성하고 예약하는 것이 좋습니다. 그러나 다양한 데이터 세트에 대한 임시 탐색 작업을 수행하거나 시스템에서 일회성 데이터 로드를 수행하는 경우 Amazon Athena를 사용하여 변환을 수행하는 것을 고려할 수 있습니다.
데이터 세트 분할
일반적인 데이터 분할 전략은 날짜와 관련된 열로 파일을 분할하는 것입니다.
예를 들어 판매 테이블에는 특정 판매 거래의 연도, 월, 일을 각각 반영하는 YEAR 열, MONTH 열 및 DAY 열이 있을 수 있습니다. 데이터가 S3에 기록되면 특정 날짜와 관련된 모든 판매 데이터가 동일한 S3 접두사 경로에 기록됩니다.
분할된 데이터 세트는 다음과 같습니다.
/datalake/transform_zone/sales/YEAR=2021/MONTH=9/DAY=29/sales1.parquet
/datalake/transform_zone/sales/YEAR=2021/MONTH=9/DAY=30/sales1.parquet
/datalake/transform_zone/sales/YEAR=2021/MONTH=10/DAY=1/sales1.parquet
/datalake/transform_zone/sales/YEAR=2021/MONTH=10/DAY=2/sales1.parquet
분할은 WHERE절을 사용하여 하나 이상의 분할된 열을 기반으로 쿼리 결과를 필터링할 때 상당한 성능 이점을 제공합니다.
Select sum(SALE_AMOUNT) from SALES where YEAR = ‘2021’ and MONTH = ‘9’ and DAY = ‘30’2021년 9월 마지막 날의 총매출을 쿼리해야 하는 경우 다음 쿼리를 실행하여 /datalake/transform_zone/sales/YEAR=2021/MONTH=9/DAY=30 의 단일 S3 접두사에 있는 파일만 읽으면 됩니다.
Apache Spark를 사용하여 데이터를 작성할 때 분할할 하나 이상의 열을 지정할 수 있습니다. 또는 Amazon Athena CTAS 문을 사용하여 분할된 데이터 세트를 생성할 수 있습니다. 그러나 Athena에서 단일 CTAS 문은 최대 100개의 파티션만 만들 수 있습니다.
기타 파일 기반 최적화
최적화된 파일 형식(ex. Apache Parquet)을 사용하는 것과 데이터를 분할하는 것은 일반적으로 분석 성능에 가장 큰 긍정적인 영향을 미치는 두 가지 전략입니다. 그러나 몇 가지 다른 전략을 사용하여 성능을 미세 조정할 수 있니다.
파일 크기 최적화
분석 쿼리를 최적화하려면 작은 파일이 많이 있는 것을 피하는 것이 중요합니다. S3의 각 파일에 대해 분석 엔진은 다음을 수행해야 합니다.
- 파일을 엽니다.
- Parquet 메타데이터를 읽어 쿼리가 파일 콘텐츠를 스캔해야 하는지 여부를 확인합니다.
- 파일에 쿼리에 필요한 데이터가 포함되어 있으면 파일 내용을 스캔합니다.
- 파일을 닫습니다.
매우 많은 수의 파일을 나열한 다음 각 파일을 처리하는 데 상당한 입/출력(I/O) 오버헤드 가 있을 수 있습니다. 따라서
분석을 최적화하려면 128MB에서 1,024MB 사이의 파일 크기를 목표로 해야 합니다.
버케팅
버케팅은 파티셔닝과 관련된 개념입니다. 버케팅을 사용하면 지정한 열(또는 열)의 해시 값을 기반으로 지정된 수의 버킷에 데이터 행을 함께 그룹화합니다. 현재 Athena는 Spark에서 사용되는 버킷 구현과 호환되지 않으므로 Athena CTAS 문을 사용하여 데이터를 버킷해야 합니다.
파티션 프로젝션
매우 많은 수의 파티션이 있는 시나리오에서는 모든 정보를 읽는 데 상당한 오버헤드가 있을 수 있습니다. 성능을 향상시키기 위해 파티션을 반영하는 구성 패턴을 제공하는 파티션 프로젝션을 구성할 수 있습니다. 그런 다음 Athena는 이 구성 정보를 사용하여 파티션을 읽을 필요 없이 가능한 파티션 값을 결정할 수 있습니다.
예를 들어, 파티션을 나누는 YEARMONTH라는 열이 있을 때, 파티션 프로젝션 범위를 200501, NOW로 구성할 수 있습니다. 그런 다음 Athena는 Glue 카탈로그에서 파티션 정보를 읽을 필요 없이 해당 기간 동안 가능한 모든 유효한 파티션을 결정할 수 있습니다.
2) 최적화된 SQL 쿼리 작성
SQL 쿼리 방식 또한 쿼리 성능에 상당한 영향을 미칠 수 있습니다.
필요한 특정 열만 선택
데이터를 탐색할 때, 쿼리 시작을 select * 로 지정하여 모든 열을 선택하는 쿼리를 실행하는 것이 일반적입니다. 그러나 분석에 권장되는 Parquet 형식은 열 기반 파일 형식이므로 디스크에 저장된 데이터가 행이 아닌 열로 그룹화됩니다. 쿼리 할 특정 열을 지정하면 분석 엔진은 해당 열에 대한 데이터만 읽을 수 있습니다.
Athena가 모든 열의 데이터를 처리할 필요가 없기 때문에 열이 많은 테이블이 있는 경우 쿼리에 중요한 열만 지정하면 쿼리 성능이 크게 향상될 수 있습니다. Athena의 비용은 스캔한 데이터의 양을 기반으로 하므로 특정 열만 선택해도 상당한 비용 절감 효과를 얻을 수 있습니다.
근사 집계 함수 사용
Presto 데이터베이스 엔진(및 Athena)은 쿼리에 사용할 수 있는 다양한 함수와 연산자를 지원합니다.
다음과 같은 작업에 사용됩니다.
- 지난달과 비교하여 이번 달의 모든 판매 합계 계산
- 매장당 평균 주문 수 계산
- 어제 전자 상거래 상점에 액세스한 총 고유 사용자 수 결정
- 기타 고급 통계 계산
결과에서 약간의 편차를 허용할 수 있는 시나리오의 경우 Presto는 대략적인 집계 함수를 제공하며 완전히 정확한 동등한 버전의 함수에 비해 상당한 성능 향상을 제공합니다.
like 연산자 대신 정규식 사용
특정 패턴과 일치하는 데이터 행을 선택하는 일반적인 방법은 다음 쿼리와 같이 like 연산자를 사용하는 것입니다
select
category_name, count(category_name)
from
film_category
where
category_name like 'Comedy' or category_name like 'Drama' or
category_name like 'Music' or category_name like 'New'
group by
category_name위 쿼리는 각 범주에 포함된 영화 수와 함께 선택한 범주(Comedy, Drama, Music 및 New)를 반환합니다.
select
category_name, count(category_name)
from
film_category
where
regexp_like(category_name, '(?i)^comedy|drama|music|new')
group by
category_name
다음 쿼리는 이전 쿼리와 동일한 결과를 반환하지만 이렇게 하면 명령문을 단순화하고 쿼리 성능을 높일 수 있습니다.
일반 like 대신 regexp_like를 사용하는 것이 쿼리 성능을 개선하는 데 권장됩니다. 특히 많은 like 연산자가 필요한 여러 비교를 수행해야 하는 시나리오에서 그렇습니다.
추가로, 여기서 설명한 세 가지 최적화된 SQL쿼리 작성 사례 외에도 쿼리 최적화에 깊이 들어갈 수 있는 다른 방법이 있습니다. 예를 들어 사용자는 EXPLAIN문을 Athena 쿼리의 일부로 사용하여 특정 SQL 문의 논리적 실행 계획을 볼 수 있습니다.
3. Amazon Athena Query Federation과 외부 데이터소스의 쿼리 연합
Athena 출시 이후 AWS는 Athena를 더욱 강력한 쿼리 엔진으로 만들기 위해 추가한 기능 중 v2와 함께 사용할 수 있게 된 주요 개선 사항 중 하나는 다음에 살펴볼 통합 쿼리를 실행하는 기능이 있습니다.
1) Athena Federated Query를 사용하여 외부 데이터 소스 쿼리
쿼리 연합(데이터 가상화라고도 함)은 단일 SQL 쿼리 문을 통해 서로 다른 데이터베이스 엔진이나 다른 시스템에서 여러 외부 데이터 소스를 쿼리 하는 프로세스입니다.
데이터 레이크는 조직의 여러 시스템에서 데이터를 수집하고 중앙 집중식 스토리지로 가져오도록 설계되어 데이터는 비즈니스 가치를 창출하는 방식으로 결합될 수 있습니다.
그러나 조직에서 생성한 모든 단일 데이터 세트를 데이터 레이크의 중앙 집중식 저장소로 가져오는 것은 실용적이지 않습니다. 일부 데이터 세트의 경우 조직은 데이터 세트에 대한 모든 기록 데이터를 보관할 필요가 없거나 데이터가 현재 기록 데이터를 이미 저장하고 있는 시스템에 있습니다. 이러한 시나리오에서는 소스 데이터 세트를 직접 쿼리하고 소스의 데이터를 데이터 레이크의 데이터와 즉시 결합하는 것이 더 합리적일 수 있습니다.
임시 수행 또는 상대적으로 쿼리 빈도가 낮은 소수의 팀에서만 데이터를 쿼리해야 하는 경우 Athena Federated Query 기능을 사용하여 데이터에 액세스 하는 것이 좋습니다.
예를 들어 Athena Federated Query를 사용하면 데이터 분석가가 다음 데이터 세트를 결합하는 단일 SQL 쿼리를 실행할 수 있습니다.
- Amazon S3의 마스터 고객 데이터
- Amazon Aurora의 현재 주문 정보
- Amazon DynamoDB의 배송 추적 데이터
- Amazon Redshift의 제품 카탈로그 데이터:
또 다른 사용 사례로 외부 시스템에서 데이터 레이크로 야간에 데이터를 로드하지만 일부 쿼리에서 일부 실시간 데이터를 참조할 수 있어야 하는 경우입니다.
순수 SQL을 사용하여 여러 시스템의 데이터를 읽고 조작하는 기능을 통해 데이터 처리를 단순화할 수 있는 다른 많은 잠재적인 사용 사례가 있습니다. 여러 시스템에서 독립적으로 읽은 다음 데이터를 프로그래밍 방식으로 처리해야 하는 대신 단일 SQL 쿼리로 데이터를 처리하여 데이터 처리가 간소화됩니다.
사전 구축된 커넥터 및 맞춤형 커넥터
Athena Federated Query는 AWS Lambda 에서 실행되는 코드를 사용하여 외부 시스템의 데이터와 메타데이터에 연결하고 쿼리합니다. 연결된 데이터 소스를 사용하는 쿼리가 실행되면 Athena는 관련 Lambda 함수를 호출하여 메타데이터를 읽고, 읽어야 하는 테이블 부분을 식별하고, 여러 Lambda 함수를 시작하여 데이터를 병렬로 읽습니다.
AWS는 여러 소스를 오픈 소스로 제공합니다.
- MySQL, Postgres 및 Redshift와 같은 소스에 연결하기 위한 JDBC 커넥터
- Amazon 관리 NoSQL 데이터베이스에서 읽기 위한 DynamoDB 커넥터
- Redis 인스턴스에서 데이터를 읽기 위한 Redis 커넥터
- CloudWatch 로그 및 CloudWatch 지표 커넥터, SQL을 사용하여 애플리케이션 로그 파일 및 메트릭을 쿼리 할 수 있습니다.
- 여러 AWS 서비스와 통합되어 AWS 리소스에 대한 SQL 쿼리를 실행하는 AWS CMDB 커넥터. 통합 서비스에는 EC2, RDS, EMR 및 S3가 포함됩니다.
AWS에서 제공하는 커넥터 외에도 누구나 사용자 지정 커넥터를 생성하여 외부 시스템에 연결할 수 있습니다. 온프레미스 또는 클라우드에 관계없이 AWS Lambda에서 대상 시스템으로 네트워크 연결을 만들 수 있는 경우 잠재적으로 해당 시스템에 대한 Athena Federated Query 커넥터를 생성할 수 있습니다. 타사에서도 Athena Federated Query용 커넥터를 만들 수 있습니다.
4. Amazon Athena Workgroups로 거버넌스 및 비용 관리
이 장의 두 번째 섹션에서는 쿼리가 더 적은 데이터를 스캔하여 비용을 절감할 수 있도록 데이터를 최적화할 수 있는 몇 가지 방법을 살펴보았지만 일부 이러한 최적화는 효율적인 SQL 쿼리 작성을 기반으로 합니다. 조직에서 사용자가 실수로 최적화되지 않은 SQL 쿼리를 실행하여 엄청난 양의 데이터를 스캔하게 될 경우가 있습니다. 따라서 조직은 다른 사용자나 팀이 스캔하는 데이터의 양을 제어할 수 있는 방법을 원합니다.
조직이 거버넌스와 보안에 대해 가지고 있는 우려 사항 중 일부는 다음과 같습니다.
- Athena는 모든 쿼리의 결과와 관련 메타데이터를 S3에 저장합니다. 이러한 결과에는 기밀 정보가 포함될 수 있으므로 조직에서는 이 데이터를 보호해야 합니다.
- 조직의 여러 팀이 동일한 AWS 계정에서 Athena를 사용할 수 있으며 조직은 쿼리 기록과 같은 항목이 각 팀에 대해 별도로 저장되기를 원합니다.
1) Athena 작업 그룹 개요
조직이 이러한 거버넌스 문제를 관리할 수 있도록 AWS는 Athena Workgroups 개념을 도입했습니다. 서로 다른 사용자, 팀 또는 시스템 간에 쿼리 실행 및 쿼리 기록을 분리할 수 있는 리소스 유형입니다.
자주 실행하는 쿼리를 저장할 수 있으며 실행한 기록 쿼리 목록도 사용할 수 있습니다. 그러나 이러한 목록에는 쿼리가 실행되는 작업 그룹에 대한 쿼리만 표시되므로 팀 또는 프로젝트를 다른 작업 그룹으로 분할하면 쿼리 기록 및 저장된 쿼리가 작업 그룹과 연결된 특정 팀에만 표시됩니다.
작업 그룹을 사용하면 조직에서 각 작업 그룹에 대해 스캔되는 데이터의 양(Athena 비용)을 제어할 수 있습니다. 또한 작업 그룹을 사용하여 쿼리 결과에 대한 S3 경로를 비롯한 여러 설정을 적용하고 쿼리 결과의 암호화 여부를 제어할 수 있습니다.
2) 사용자 그룹에 대한 설정 적용
Athena Workgroups의 주요 용도 중 하나는 서로 다른 Athena 사용자 그룹을 분리하고 각 그룹에 대한 설정을 적용합니다. 각 팀에 대한 별도의 작업 그룹, 다른 응용 프로그램에 대한 별도의 작업 그룹 또는 다른 유형의 사용자에 대한 별도의 작업 그룹이 될 수 있습니다.
관리자는 각 사용자 그룹이나 다른 프로젝트 또는 사용 사례에 대해 다양한 설정을 적용할 수 있습니다. 기본적으로 각 사용자는 여러 설정을 제어할 수 있지만 작업 그룹을 사용하면 관리자가 사용자 설정을 재정의하여 사용자가 작업 그룹 설정을 사용하도록 할 수 있습니다.
다음은 관리자가 작업 그룹 구성원에 대해 적용할 수 있는 구성 항목입니다.
- 쿼리 결과 위치 : Athena 쿼리 결과가 기록될 S3 경로입니다. 이를 통해 조직은 쿼리 결과 파일이 S3에 저장되는 위치를 제어할 수 있으며 조직은 이 위치에 엄격한 액세스 제어 옵션을 설정하여 권한이 없는 사용자가 쿼리 결과에 액세스 하지 못하도록 할 수 있습니다. 예를 들어 각 팀에 서로 다른 작업 그룹을 할당할 수 있으며 쿼리 결과에 대한 읽기 액세스만 허용하도록 해당 IAM 액세스 정책을 구성할 수 있습니다.
- 쿼리 결과 암호화 : 이 옵션은 쿼리 결과를 암호화하여 조직이 회사 보안 요구 사항을 준수하도록 하는 데 사용할 수 있습니다.
- 지표 : 성공적인 쿼리 수, 쿼리 실행 시간, 이 작업 그룹 내에서 실행되는 모든 쿼리에 대해 스캔된 데이터 양과 같은 항목을 반영하는 지표를 CloudWatch 로그로 보내도록 선택할 수 있습니다.
- Override client-side settings : 이 항목이 활성화되지 않은 경우 사용자는 쿼리 결과 위치 및 쿼리 여부와 같은 항목에 대한 사용자 설정을 구성할 수 있습니다. 결과는 암호화됩니다. 따라서 쿼리 결과가 보호되고 회사 관리 표준이 충족되도록 하려면 이 설정을 활성화하는 것이 중요합니다.
- 요청자가 S3 버킷 지불 : Amazon S3에서 버킷을 생성할 때 사용할 수 있는 옵션 중 하나는 버킷을 쿼리 하는 사용자가 API 액세스 비용을 지불하도록 버킷을 구성하는 것입니다. 기본적으로 Athena는 요청자 지불에 대해 구성된 버킷에 대한 쿼리를 허용하지 않지만 이 항목을 활성화하여 이를 허용할 수 있습니다.
- 태그 : 비용 할당과 같은 항목을 지원하거나 작업 그룹에 대한 액세스를 제어하는 데 필요한 만큼 키:값 태그를 제공할 수 있습니다.
3) 데이터 사용 제어 사항
Athena 가격은 스캔한 데이터의 양을 기반으로 하므로, 스캔한 데이터의 양을 제한하면 비용을 관리하는 데 도움이 됩니다. Athena Workgroups에는 데이터 사용 제어 기능이 포함되어 있으며 두 가지 유형의 제어를 구현할 수 있습니다
쿼리별 데이터 사용량 제어
쿼리당 데이터 사용 제어를 사용하여 단일 쿼리로 스캔할 수 있는 최대 데이터 양을 구성할 수 있습니다. 사용자가 쿼리를 실행하고 Athena가 컨트롤에서 허용된 것보다 더 많은 데이터를 스캔하려고 하면 쿼리가 취소됩니다. 그러나 AWS 계정은 쿼리가 취소될 때까지 검색된 데이터 양에 대해 여전히 청구됩니다.
실용적인 예로, SQL에 익숙하지 않은 사용자 그룹이 있으며 임시 쿼리를 안전하게 실행할 수 있는 샌드박스 환경을 원할 수 있습니다. 이 시나리오에서는 샌드박스를 호출하고 이러한 사용자가 샌드박스 작업 그룹에 액세스 할 수 있도록 구성합니다. 그러면 예를 들어 쿼리당 제한이 100GB가 되도록 작업 그룹을 구성할 수 있습니다.
작업 그룹 데이터 사용량 제어
작업 그룹 데이터 사용 제어를 사용하면 지정된 기간 내에 전체 작업 그룹에서 검색하는 최대 데이터 양을 구성할 수 있습니다. 또한 작업 그룹 데이터 사용 제어는 쿼리를 취소하는 대신 Amazon Simple Notification Service(SNS)를 사용하여 제한을 초과할 때 작업을 트리거합니다.
예를 들어 하루에 최대 3TB의 데이터 검색에 대한 작업 그룹 데이터 사용량 제어를 구성할 수 있습니다. 그런 다음 관리자에게 이메일을 보내 작업 그룹에 대한 데이터 검색 제한을 초과했는지 알려주는 SNS 항목을 구성할 수 있습니다.
그러나 하나의 SNS 메시지에 의해 여러 대상이 트리거 될 수 있기 때문에 설정한 제한에 도달하면 프로그램 작업을 자동화하는 등의 작업도 수행할 수 있습니다. 예를 들어, 작업 그룹을 프로그래밍 방식으로 비활성화할 수 있는 람다 함수를 생성하여 작업 그룹에서 추가 쿼리가 실행되지 않도록 할 수 있습니다.
[Data Engineering with AWS] 도서를 요약 및 번역하여 작성하였습니다.
https://www.amazon.com/Data-Engineering-AWS-Gareth-Eagar/dp/1800560419
Amazon.com
Enter the characters you see below Sorry, we just need to make sure you're not a robot. For best results, please make sure your browser is accepting cookies.
www.amazon.com