일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 데이터 엔지니어
- AWS
- 카프카 구축
- 대용량 처리
- 스파크 스트리밍
- Redshift
- delta lake
- spark
- 데이터
- Data Engineer
- spark streaming
- 데이터 웨어하우스
- Schema Registry
- Parquet
- MySQL
- s3
- 델타레이크
- airflow
- kafka
- 카프카
- Data engineering
- 에어플로우
- 데이터 엔지니어링
- Zookeeper
- 컬럼 기반
- 레드시프트
- Data Warehouse
- kafka rest api
- 스파크
- docker
- Today
- Total
데이터 엔지니어 기술 블로그
[데이터 엔지니어링] RDS의 테이블을 Athena 에서 사용할 때의 문제 본문
개요
RDS에서 매일 생성되는 스냅샷으로 Athena에서 과거의 테이블을 사용할 수 있게 했다. 그러나 시간 문제가 두가지가 발생했다.
문제
첫 번째 문제 - 시간으로 필터할 수 없는 문제
S3에 데이터를 저장한 후 그대로 Glue로 크롤링 후 Athena에서 날짜로 필터해서 읽으려고 시도했다. 그러나 쿼리 결과가 비어있었다.
Athena는 Java Timestamp 형식이 필요하다고 하는데, 데이터가 그렇지 않은 것으로 예상된다.
해결 방법은 다음과 같다.
- 열을 스트링으로 정의한다.
- YYYY-MM-DD HH:MM:SS.fffffffff 형식으로 변환한다.
- 쿼리에서 Presto의 날짜 및 시간 함수를 사용하여 DATE 또는 TIMESTAMP로 읽는다.
https://aws.amazon.com/ko/premiumsupport/knowledge-center/query-table-athena-timestamp-empty/
두 번째 문제 - RDS에 저장된 데이터의 시간은 KST지만 Athena에서 읽을 때는 UTC인 문제
RDS에서 스냅샷을 떠서 Glue로 크롤링 후 Athena에서 읽는 방식으로 되어있다. 그러나 시간 컬럼의 쿼리의 결과가 9시간이 적은 것으로 표시되었다.
처음에는 아테나 문제인 줄 인지하고 스택 오버플로우에 질문을 해보았다.
CAST를 해서 VARCHAR로 변환했을 때에도 -9시간이 되면 아테나 문제지만, 위에서 열을 이미 스트링으로 정의했기 때문에 VARCHAR로 변환해도 똑같았다.
S3에 저장된 테이블 스냅샷을 읽어서 확인해보니, RDS 타임존은 KST로 설정되어 있지만, 스냅샷을 뜨면서 UTC시간으로 변환되어 저장된 것을 확인할 수 있었다.
세 번째 문제 - Glacier를 복원하여 Athena에서 읽는 문제
Glacier로 만들기 전 Standard 상태에서 Glue로 읽어서 테이블을 만든 이후에 Glaicer를 복원하였으나 Athena에서 그 테이블을 읽지 못하는 문제가 발생했다. 찾아본 결과 Glacier는 내부적으로 다른 API를 사용하기 때문에 2019년 릴리즈부터는 Athena에서 무시하기 떄문이라고 한다.
Glacier를 복원 후 Standard로 만든 후 읽는 방식으로 하니 정상적으로 동작했다.
'데이터 엔지니어링' 카테고리의 다른 글
[Airflow] 에어플로우 작업 실패시 Slack으로 메세지 보내는 방법 (0) | 2021.06.14 |
---|---|
[MYSQL] Docker MYSQL 로그에서 "mbind: Operation not permitted" 이슈 해결방법 (0) | 2021.06.07 |
[간단 데이터 엔지니어링] 프레스토(Presto)란? (0) | 2021.06.02 |
[🧙Kafka] 카프카 개념 - 신뢰성 있는 데이터 전달 (0) | 2021.04.14 |
[🧙Kafka] 카프카 개념 - 카프카 내부 이해하기 (0) | 2021.04.13 |