앞선 Amazon Athena & Glue Data Catalog 글에서는 일반 Glue 테이블(S3 + Parquet 파일 + Glue Catalog)을 기준으로 쿼리 흐름과 권한을 정리했습니다. 그런데 다음 편에서 다룰 S3 Tables는 “관리형 Iceberg 레이크하우스”입니다. 즉 S3 Tables를 제대로 이해하려면 그 바탕에 깔린 ...
앞선 AWS 데이터 분석 스택 Overview에서 분석 스택의 큰 그림과, 쿼리 한 번이 엔진과 메타스토어, 저장소를 지나는 흐름을 살펴봤습니다. 그 중심에 있는 두 구성요소, Amazon Athena와 AWS Glue Data Catalog를 자세히 알아봅니다. 이 둘은 한 쌍으로 움직입니다. Athena는 SQL을 실행하는 엔진이고, Glue D...
데이터 레이크나 레이크하우스에 쌓인 대규모 데이터를 SQL로 빠르게 조회하는 일의 중심에는 분산 SQL 엔진이 있습니다. Amazon Athena가 데이터를 옮기지 않고도 여러 소스를 한 쿼리로 조인하고 빠르게 응답하는 것도, 그 바탕에 분산 SQL 엔진이 있기 때문입니다. SQL 엔진이 무엇이고, 단일 노드 엔진과 분산 SQL 엔진(Trino/Pre...
S3 버킷에는 로그, 이벤트, 각종 추출 데이터가 끊임없이 쌓입니다. 그런데 막상 “이 데이터를 SQL로 한 번 들여다보자”고 하면, 어디서부터 손대야 할지 막막할 때가 많습니다. 별도 DB로 적재(ETL)해야 하나? 권한은 어디서 거나? 카탈로그는 또 뭔가? AWS는 이 “S3에 쌓인 데이터를 분석하는 일”을 여러 서비스의 조합으로 풉니다. Ath...
데이터 분석 스택을 다루다 보면 데이터 웨어하우스(Data Warehouse), 데이터 레이크(Data Lake), 레이크하우스(Data Lakehouse) 라는 용어가 자주 등장합니다. 셋 다 “데이터를 모아 분석한다”는 점은 같지만, 어디에 어떻게 저장하고 언제 스키마를 적용하느냐가 다릅니다. 이 차이를 모르면, 어떤 저장 방식을 택해야 하는지, ...
데이터 웨어하우스, 데이터 레이크, 레이크하우스는 나란히 놓고 고르는 세 가지 선택지처럼 소개되곤 합니다. 실제로는 각각 직전 방식이 부딪힌 한계를 풀면서 순서대로 등장했고, 그 순서를 모르면 왜 레이크하우스가 파일 위에 굳이 테이블 계층을 다시 얹는지 설명되지 않습니다. 변천사를 시간 축으로 따라가며 각 단계가 어떤 운영 문제를 풀려 했는지 정리합니...
앞선 리소스 계층 글에서 Organization -> Folder -> Project로 이어지는 리소스 계층과, 권한/정책이 위에서 아래로 상속된다는 점을 알아보았습니다. 이번에는 그 권한 체계의 핵심인 GCP IAM(Identity and Access Management)에 대해 알아봅니다. GCP IAM은 결국 “누가(Principal)...
GCP를 처음 공부하기 시작하면서 가장 먼저 마주친 개념이 리소스 계층(Resource Hierarchy)이었습니다. 클라우드 콘솔에 들어가 프로젝트를 만들려는 순간부터 Organization, Folder, Project라는 단어가 등장하는데, 이 구조를 이해하지 못하면 IAM 권한이나 결제(Billing), 조직 정책이 어디에 어떻게 적용되는지 감...
GCP를 처음부터 공부해 보기로 마음먹고 가장 먼저 정리한 것은 “GCP가 도대체 무엇인가”였습니다. 개별 서비스나 명령어를 외우기 전에, 이 플랫폼이 어떤 성격을 가졌고 무엇을 잘하는지 큰 그림을 그려두면 이후 학습이 훨씬 수월하기 때문입니다. 이번 포스트는 GCP 학습 시리즈의 출발점으로, GCP가 무엇이고 어떤 특징이 있으며 어떤 서비스들로 구성...
CloudFront를 ALB나 EC2 앞단에 두려고 하면, 정작 오리진(origin)은 퍼블릭 서브넷에 두고 퍼블릭 IP를 부여해야 했습니다. 그러면서도 “CloudFront만 들어오게” 하려고 Security Group에 CloudFront managed prefix list를 걸거나, 커스텀 헤더를 검증하는 등 추가 작업이 필요했고, 결국 오리진이...