Amazon Athena

 

Amazon Athena

 

- 표준 Amazon S3을 사용하여 직접 데이터를 쉽게 분석할 수 있는 대화형 쿼리 서비스

- Facebook에서 개발한 인메모리 쿼리 엔진인 Presto를 base로 개발되었습니다.

- AWS Management Console에서 몇 가지 작업을 수행하면 Amazon S3에 저장된 데이터에서 Athena를 가리키고, 표준 SQL을 사용하여 임시 쿼리를 실행하고, 몇 초 안에 결과를 얻을 수 있습니다.

- 서버리스 서비스이므로 설정하거나 관리할 인프라가 없으며, 실행하는 쿼리에 대해서만 비용을 지불합니다.

- 자동으로 쿼리를 병렬로 실행하게 조정되므로, 많은 데이터 세트와 복잡한 쿼리가 있더라도 결과가 빠릅니다.

- Amazon S3에 저장된 비정형, 반정형 및 정형 데이터를 분석하는 데 도움을 줍니다. 예를 들면 CSV, JSON 또는 컬럼 방식 데이터 형식이 해당됩니다. Athena을(를) 사용하면 데이터를 집계하거나 Athena로 로드할 필요 없이 ANSI SQL을 사용한 임의 쿼리를 실행할 수 있습니다.

 

 

테이블과 데이터베이스

 

- Athena에서 테이블과 데이터베이스는 기본 소스 데이터에 대한 스키마를 정의하는 메타데이터 정의를 위한 컨테이너입니다.

- 각 데이터 세트에 대한 테이블이 Athena에 있어야 합니다.

- 테이블의 메타데이터는 Amazon S3의 데이터 위치를 Athena에 알려주고, 데이터의 구조(예: 열 이름, 데이터 유형 및 테이블 이름)를 지정합니다.

- 데이터베이스는 테이블의 논리적 그룹이며 데이터 세트에 대한 메타데이터와 스키마 정보만 보유합니다.

- 쿼리하려는 각 데이터 세트에 대해 쿼리 결과를 얻고 반환하는 데 사용할 기본 테이블이 Athena에 있어야 합니다.

- 데이터를 쿼리하기 전에 테이블이 Athena에 등록되어 있어야 합니다. 자동 또는 수동으로 테이블을 만들면 등록이 이루어집니다.

테이블 생성 방법에 관계없이 테이블 생성 프로세스는 Athena을(를) 통해 데이터 세트를 등록합니다. AWS Glue 데이터 카탈로그에서 등록이 이루어지며, 등록하면 Athena가 데이터에서 쿼리를 실행할 수 있게 됩니다.

 

테이블을 생성한 후 SQL SELECT 문을 사용하여 소스 데이터에 대한 특정 파일 위치 가져오기를 포함하여 쿼리할 수 있습니다. 쿼리 결과는 Amazon S3지정한 쿼리 결과 위치의 에 저장됩니다.

 

 

 

쿼리를 실행하기 위해 Athena에서 작업하는 테이블과 데이터베이스는 메타데이터를 기반으로 합니다. 메타데이터는 데이터 세트의 기본 데이터에 대한 데이터입니다. 해당 메타데이터가 데이터 세트를 설명하는 방법을 스키마라고 합니다. 예를 들어 테이블 이름, 테이블의 열 이름 및 각 열의 데이터 유형은 기본 데이터 세트를 설명하는 메타데이터로 저장된 스키마입니다. Athena에서는 메타데이터를 데이터 카탈로그 또는 메타스토어로 구성하기 위한 시스템을 호출합니다. 데이터 세트와 이를 설명하는 데이터 카탈로그의 조합을 데이터 원본이라고 합니다.

 

메타데이터와 기본 데이터 세트의 관계는 작업하는 데이터 원본 유형에 따라 달라집니다. MySQL, PostgreSQL, SQL Server와 같은 관계형 데이터 원본은 데이터 세트와 메타데이터를 밀접하게 통합합니다. 이러한 시스템에서는 데이터가 작성될 때 메타데이터가 가장 자주 작성됩니다. Hive를 사용하여 구축된 것과 같은 다른 데이터 원본을 사용하면 데이터 세트를 읽을 때 즉석에서 메타데이터를 정의할 수 있습니다.

 

 

 

Query Guide

 

 

JOIN

Left에 작은 테이블, Right에 큰 테이블을 두면 Presto는 Right의 큰 테이블을 Worker node에 올리고 Join을 수행한다. (Presto는 join reordering을 지원하지 않음) 즉, Left에 큰 테이블, Right에 작은 테이블을 두면 더 작은 메모리를 사용하여 더 빠르게 쿼리할 수 있다.

 

 

JOIN (Big Tables)

Presto는 Index 없이 fast full table scan 방식. Big table간 join은 아주 느리다. 따라서 AWS 가이드는 이런 류의 작업에 Athena 사용을 권장하지 않는다. Big Table은 ETL을 통해 pre-join된 형태로 활용하는 것이 좋다.

 

 

ORDER BY

Presto는 모든 row의 데이터를 한 worker로 보낸 후 정렬하므로 많은 양의 메모리를 사용하며, 오랜 시간 동안 수행하다가 Fail이 나기도 한다. LIMIT 절과 함께 ORDER BY를 사용. 개별 worker에서 sorting 및 limiting을 가능하게 해줄 수 있다. 또한 ORDER BY절에 String 대신 Number로 컬럼을 지정하면 된다. 예로는, ORDER BY order_id 대신 ORDER BY 1

 

GROUP BY

GROUPING할 데이터를 저장한 worker node로 데이터를 보내서 해당 memory의 GROUP BY값과 비교하며 Grouping한다. GROUP BY절의 컬럼 배치 순서를 높은 cardinality부터 낮은 cardinality 순(unique count가 큰 순부터 낮은 순으로)으로 배치한다. 같은 의미의 값인 경우 가능하면 string 컬럼보다 number 컬럼을 활용해 GROUP BY한다.

 

 

LIKE

여러 개의 string 컬럼에 like검색을 써야하는 경우 regular expression을 사용하는 것이 더 좋다.

SELECT count(*) FROM lineitem WHERE regexp_like(l_comment, 'wake|regular|express|sleep|hello')

 

 

 

Data Preparation Guide

 

 

Metadata-Driven Read Optimization

parquet, ORC format의 경우 data section별로 metadata를 보관한다. 따라서 filter(where) 조건을 잘 주면 data read를 skip할 수도 있다. 즉, 필터조건에 따라 필요 없는 block을 제외하고 읽을 수 있도록 하기 위해 data 적재 시 가장 사용성이 높은 필터 조건 중심으로 data를 sorting 해두는 것이 좋다. (e.g. sorting by value)

 

 

Partitioning Data

적절한 파티셔닝을 통해 필요한 데이터만 선택적으로 read할 수 있도록 한다. Hive의 MSCK REPAIR TABLE 커맨드를 지원한다. yy=2019 혹은 dt=2019–10–20 와 같은 format을 지켜서 partition directory를 만들면 partition도 일괄생성으로 편하게 만들 수 있다.

 

 

 

Optimize File Size

 

 

optimal S3 file size is between 200MB-1GB

file size가 아주 작은 경우(128MB 이하), executor engine이 S3 file을 열고, object metadata에 접근하고, directory를 리스팅하고, data transfer를 세팅하고, file header를 읽고, compression dictionary를 읽는 등의 행동을 해야 하는 오버헤드로 인해 효율이 떨어지게 된다. file size가 아주 크고 splittable하지 않은 경우, query processor는 한 파일을 다 읽을 때까지 대기해야 하고 이는 athena의 강력한 parallelism 기능을 활용할 수 없게 한다.

 

 

Join Big Tables in the ETL Layer

Athena는 index 없이 full table scan을 사용한다. 따라서 작은 규모의 데이터를 join할 때는 아무 문제없지만 큰 데이터를 조인할 때는 ETL을 활용해 pre-join된 형태로 활용하는 것이 좋다.

 

 

Optimize Columnar Data Store Generation

The stripe size or block size parameter : ORC stripe size, Parquet block size는 block당 최대 row수를 의미한다. ORC는 64MB, Parquet는 128MB를 default로 가진다. 효과적인 sequential I/O를 고려하여 column block size를 정의할 것.