Databricks 데이터 엔지니어 1강

이 시리즈는 Databricks 데이터 엔지니어 자격증(Associate·Professional)을 준비하는 강의다. 첫 강은 시험의 토대인 레이크하우스 플랫폼을 다룬다.

Databricks의 핵심 아이디어는 데이터 레이크(저비용 대용량 저장)와 데이터 웨어하우스(ACID·성능)의 장점을 하나로 합친 레이크하우스(Lakehouse)다. 이 구조를 이해하면 나머지 강의가 쉽게 연결된다.

이 강의 목표는 다음과 같다.

• 레이크하우스가 무엇이고 왜 등장했는지 이해한다.
• 플랫폼의 계층 구조(스토리지·Delta·거버넌스·워크로드)를 안다.
• Control Plane과 Compute Plane의 역할을 구분한다.

1. 왜 레이크하우스인가

전통적으로는 두 시스템을 따로 뒀다.

• 데이터 레이크: 값싸고 대용량이지만 ACID·성능·거버넌스가 약하다.
• 데이터 웨어하우스: 빠르고 신뢰성 있지만 비싸고 반정형·비정형에 약하다.

레이크하우스는 값싼 오브젝트 스토리지 위에 Delta Lake를 얹어, 웨어하우스의 트랜잭션·성능을 레이크에서 제공한다. 데이터를 복사·이중화하지 않고 하나의 소스에서 BI·ETL·ML을 함께 돌린다.

2. 플랫폼 계층 구조

계층	역할
워크로드	SQL 분석 · ETL · 데이터 과학/ML · 스트리밍
Unity Catalog	카탈로그·권한·계보(lineage)·감사
Delta Lake	ACID·스키마·Time Travel (오픈 테이블 포맷)
클라우드 스토리지	S3·ADLS·GCS (저비용 대용량)

3. Control Plane vs Compute Plane

• Control Plane: 웹 UI, 노트북, 잡 스케줄러, 카탈로그 등 관리 기능. Databricks 계정 쪽에 있다.
• Compute Plane: 실제 클러스터(스파크 실행)와 데이터. 내 클라우드 계정 쪽에 위치해 데이터가 밖으로 나가지 않는다.

4. 작업 공간 요소

• 클러스터: 스파크가 도는 컴퓨트. All-Purpose(대화형)와 Job(자동화)로 나뉜다.
• 노트북: 셀 단위로 SQL·Python을 섞어 실행하는 개발 환경.
• Repos: Git 연동 폴더로 노트북·코드를 버전관리한다.

코드 스니펫

-- 클러스터에서 바로 실행하는 첫 쿼리
SELECT current_catalog(), current_database(), version();

예제

예제) 회사가 BI 리포트용 웨어하우스와 ML용 데이터 레이크를 따로 운영해 데이터가 중복되고 정합성이 깨진다. 레이크하우스는 이를 어떻게 해결하나?

해설) 값싼 오브젝트 스토리지 위 Delta Lake 하나를 단일 소스로 삼아, 그 위에서 BI 쿼리와 ML 학습을 모두 수행한다. 데이터를 두 시스템으로 복사하지 않으므로 중복·정합성 문제가 사라지고, ACID 트랜잭션으로 동시 작업도 안전하다.

샘플 문제

문) Databricks 아키텍처에서 실제 클러스터와 데이터가 위치하는 곳은?

• (A) Databricks가 관리하는 Control Plane
• (B) 고객 클라우드 계정의 Compute Plane
• (C) 온프레미스 데이터센터
• (D) 노트북 로컬 디스크

정답: (B). 컴퓨트와 데이터는 고객 클라우드 계정(Compute/Data Plane)에 있어 데이터가 외부로 나가지 않는다. Control Plane은 UI·잡·카탈로그 같은 관리 기능을 담당한다.

정리

• 레이크하우스 = 저비용 레이크 + 웨어하우스의 ACID·성능을 하나로.
• 계층은 스토리지 → Delta Lake → Unity Catalog → 워크로드.
• Control Plane(관리)과 Compute Plane(실행·데이터)이 분리된다.
• 클러스터·노트북·Repos가 기본 작업 요소다.

다음 강에서는 레이크하우스의 심장인 Delta Lake를 자세히 본다.