앞선 S3 Tables & Catalog Federation 글에서 관리형 Iceberg 레이크하우스가 s3tablescatalog 아래에 어떻게 중첩되는지, 그래서 ARN이 왜 깊어지는지를 정리했습니다. 이번 글에서는 이 federated 데이터에 한 겹 더 얹히는 권한 계층, AWS Lake Formation을 알아봅니다. Lake For...

앞선 Amazon Athena & Glue Data Catalog 글에서 일반 Glue 테이블(S3 + Glue Catalog)을 기준으로 쿼리 흐름과 권한을 정리했습니다. 이번 글에서는 한 단계 더 들어가, 데이터 레이크하우스의 핵심인 Amazon S3 Tables와, 그것이 Glue Data Catalog에 연결되는 방식인 Catalog F...

앞선 AWS 데이터 분석 스택 Overview에서 분석 스택의 큰 그림과, 쿼리 한 번이 엔진과 메타스토어, 저장소를 지나는 흐름을 살펴봤습니다. 이번 글에서는 그 중심에 있는 두 구성요소, Amazon Athena와 AWS Glue Data Catalog를 자세히 알아봅니다. 이 둘은 한 쌍으로 움직입니다. Athena는 SQL을 실행하는 엔진이고...

S3 버킷에는 로그, 이벤트, 각종 추출 데이터가 끊임없이 쌓입니다. 그런데 막상 “이 데이터를 SQL로 한 번 들여다보자”고 하면, 어디서부터 손대야 할지 막막할 때가 많습니다. 별도 DB로 적재(ETL)해야 하나? 권한은 어디서 거나? 카탈로그는 또 뭔가? AWS는 이 “S3에 쌓인 데이터를 분석하는 일”을 여러 서비스의 조합으로 풉니다. Ath...

데이터 레이크나 레이크하우스에 쌓인 대규모 데이터를 SQL로 빠르게 조회하는 일의 중심에는 분산 SQL 엔진이 있습니다. Amazon Athena가 데이터를 옮기지 않고도 여러 소스를 한 쿼리로 조인하고 빠르게 응답하는 것도, 그 바탕에 분산 SQL 엔진이 있기 때문입니다. 이번 글에서는 SQL 엔진이 무엇이고, 단일 노드 엔진과 분산 SQL 엔진(T...

데이터 분석 스택을 다루다 보면 데이터 웨어하우스(Data Warehouse), 데이터 레이크(Data Lake), 레이크하우스(Data Lakehouse) 라는 용어가 자주 등장합니다. 셋 다 “데이터를 모아 분석한다”는 점은 같지만, 어디에 어떻게 저장하고 언제 스키마를 적용하느냐가 다릅니다. 이 차이를 모르면, 어떤 저장 방식을 택해야 하는지, ...

이 글은 AWS 데이터 분석 스택 시리즈의 출발점입니다. 데이터 웨어하우스, 데이터 레이크, 레이크하우스 같은 용어는 어느 날 동시에 등장한 것이 아니라, 각각 직전 방식의 한계를 풀면서 순서대로 진화한 결과입니다. 이번 글에서는 그 변천사를 시간 축으로 따라가며, 왜 이런 흐름이 생겼는지를 정리합니다. 세 패러다임의 정적인 비교는 이어지는 글에서 따...

앞선 리소스 계층 글에서 Organization -> Folder -> Project로 이어지는 리소스 계층과, 권한/정책이 위에서 아래로 상속된다는 점을 알아보았습니다. 이번에는 그 권한 체계의 핵심인 GCP IAM(Identity and Access Management)에 대해 알아보겠습니다. GCP IAM은 결국 “누가(Principa...

GCP를 처음 공부하기 시작하면서 가장 먼저 마주친 개념이 리소스 계층(Resource Hierarchy)이었습니다. 클라우드 콘솔에 들어가 프로젝트를 만들려는 순간부터 Organization, Folder, Project라는 단어가 등장하는데, 이 구조를 이해하지 못하면 IAM 권한이나 결제(Billing), 조직 정책이 어디에 어떻게 적용되는지 감...

GCP를 처음부터 공부해 보기로 마음먹고 가장 먼저 정리한 것은 “GCP가 도대체 무엇인가”였습니다. 개별 서비스나 명령어를 외우기 전에, 이 플랫폼이 어떤 성격을 가졌고 무엇을 잘하는지 큰 그림을 그려두면 이후 학습이 훨씬 수월하기 때문입니다. 이번 포스트는 GCP 학습 시리즈의 출발점으로, GCP가 무엇이고 어떤 특징이 있으며 어떤 서비스들로 구성...