DATABRICKS-Fundamentals-5

1. 오늘 강의에서 다룰 질문 3가지

여러분, Databricks 워크스페이스를 만들면 “웹에서 접속하는 화면”은 바로 보이죠.
그런데 수업을 하거나 실무에서 설명할 때는 아래 3가지 질문을 꼭 답할 수 있어야 합니다.

Databricks는 Azure 어디에 설치되나요?
노트북/잡/클러스터/데이터는 각각 어디에 있나요?
왜 굳이 Control Plane / Data Plane으로 나누나요?

이 3가지를 이해하면, Databricks가 “그냥 웹앱”이 아니라 클라우드 네이티브 데이터 플랫폼이라는 게 보입니다.

2. 큰 그림: Control Plane vs Data Plane

2.1 한 문장 요약

Control Plane(컨트롤 플레인): Databricks가 제공하는 “관리/제어” 영역 (UI, 노트북/잡/클러스터 설정 등)
Data Plane(데이터 플레인): 고객(Azure 구독) 안에서 실제로 돈이 나가는 “실행/데이터” 영역 (클러스터 VM, 스토리지 등)

강의 멘트(핵심):
“**설정/관리(컨트롤)**는 Databricks가, **실행/데이터(데이터)**는 고객 구독에서 돌아간다.”

3. Control Plane(컨트롤 플레인) — “Databricks의 두뇌”

3.1 Control Plane에 있는 것들 (왜 중요한가?)

여기에는 Databricks가 제공하는 웹 애플리케이션(Workspace UI) 과 “메타데이터/설정 정보”가 들어있습니다.

Databricks Web Application (브라우저에서 보는 Workspace UI)
Notebooks (노트북 자체, 또는 노트북 메타/버전/권한 등)
Jobs / Workflows 설정
Queries / Alerts / Dashboards 설정(특히 SQL 기능)
Cluster 설정(클러스터 생성 옵션, 노드 타입, 런타임 등)
사용자/권한/기본 정책(일부는 Account/Workspace 레벨로 나뉨)

왜 컨트롤 플레인이 필요한가?
Databricks는 사용자가 “직접 VM을 만들어서 Spark 설치하고 튜닝”하는 대신,
UI/REST API로 ‘요청’만 하면 Databricks가 적절한 리소스를 띄우고 관리해줍니다.
즉, 컨트롤 플레인은 클라우드 인프라를 추상화해주는 제어 계층이에요.

3.2 Control Plane에 “직접 접속” 못하는 이유

사용자는 컨트롤 플레인 내부 서버에 SSH 같은 방식으로 들어가는 게 아니라,
- 브라우저(UI) 또는
- REST API/CLI
  로만 기능을 사용합니다.

이렇게 막아두는 이유

보안/컴플라이언스: 관리 계층에 대한 직접 접근을 줄여 공격면을 최소화
운영 안정성: Databricks가 서비스 품질(SLA)을 보장하려면 관리 영역은 일관된 방식으로 운영되어야 함

4. Data Plane(데이터 플레인) — “실제 실행과 비용이 발생하는 곳”

4.1 Data Plane에 있는 핵심 요소

Data Plane은 고객의 Azure Subscription 안에 있습니다. 그래서 비용도 여기서 발생합니다.

Compute(클러스터/SQL Warehouse 실행 리소스)
- Spark 작업을 돌리는 VM/노드들(드라이버/워커)
Storage(데이터 저장소)
- 고객 데이터: 보통 ADLS Gen2 / Blob Storage
- 워크스페이스 기본 스토리지(Workspace Root Storage / Root DBFS)

강의 멘트(핵심):
“컨트롤 플레인은 ‘설정과 명령’, 데이터 플레인은 ‘실제 실행과 데이터’입니다.
비용이 큰 건 대부분 데이터 플레인에서 나옵니다.”

4.2 “클러스터는 왜 고객 구독에 만들까?”

비용/과금 주체가 고객이기 때문
네트워크/보안(예: VNet, Private Link, 방화벽, NSG) 정책을 고객이 통제하기 때문
기업 환경에서는 데이터/네트워크 통제가 매우 중요 → 실행 인프라가 고객 구독에 있어야 함

5. DBFS와 Workspace Root Storage — “기본 저장소지만, 메인 데이터레이크는 아니다”

5.1 DBFS( Databricks File System )가 뭔가요?

초보자 기준으로는 이렇게 이해하면 됩니다.

DBFS는 Databricks에서 파일을 다루기 위한 가상 파일시스템 인터페이스
내부적으로는 Azure Storage(ADLS/Blob) 같은 곳을 기반으로 동작할 수 있음
예: 라이브러리 업로드, 임시 파일, 일부 로그/결과 등

5.2 Workspace Root Storage(= Root DBFS) 주의사항

워크스페이스를 만들면 자동으로 “기본 저장소”가 하나 생기는데, 이것이 Root DBFS입니다.

워크스페이스 시스템 용도(일부 로그/시스템 데이터)에 적합
하지만 실무에서 데이터레이크(원천/정제/골드 데이터) 를 여기에 넣는 건 권장되지 않음

왜 별도 Storage Account가 필요할까?

데이터 거버넌스/보안: “데이터는 고객이 직접 통제하는 저장소에”
운영/백업/수명주기(Lifecycle): 워크스페이스와 데이터의 생명주기를 분리
멀티 워크스페이스 공유: 하나의 데이터레이크를 여러 워크스페이스에서 접근
비용/정책/권한 모델을 더 명확하게 설계 가능

강의 멘트:
“Root DBFS는 ‘워크스페이스의 기본 공용창고’ 같은 느낌이고,
우리 회사의 핵심 데이터는 ‘별도의 공식 창고(ADLS Gen2)’에 보관하는 게 정석입니다.”

6. 인증과 접근 방식 — SSO / API / CLI

6.1 사용자(Web UI) 접근

일반적으로 SSO(Microsoft Entra ID 기반)로 로그인
즉, “회사 계정”으로 Databricks에 접속하는 흐름이 자연스럽게 구성됨

6.2 자동화/도구 접근(REST API / CLI)

운영/배포/자동화에서는 UI보다 API/CLI가 중요할 때가 많음
예: 노트북 배포, 잡 생성/실행, 클러스터 관리, 리포지토리 연동 등

강의 팁:
“팀이 커지면 ‘수동 클릭’은 한계가 옵니다.
그래서 컨트롤 플레인이 REST API를 제공하는 게 매우 중요해요.”

7. (그림에서 보이는) 추가 포인트: Serverless Compute Plane

일부 기능(예: Serverless SQL Warehouses, Model Serving 등)은
“서버리스” 형태의 컴퓨팅 플레인을 사용하기도 합니다.

초보자 기준으로는 이렇게만 기억해도 충분합니다.

Classic compute plane: 일반적인 Spark 클러스터(드라이버/워커 VM 기반)
Serverless compute plane: 관리 부담을 더 줄인 실행 방식(서비스형)

8. 실무 베스트 프랙티스 체크리스트 (강의에서 꼭 강조)

8.1 리소스 정리 전략

프로젝트마다 Resource Group을 분리 → 나중에 삭제/정리 쉬움
실습 끝난 후 클러스터 종료/삭제 습관화 (비용 폭탄 방지)

8.2 데이터 저장소 설계

Root DBFS에 핵심 데이터 적재 ❌
별도 ADLS Gen2 Storage Account 만들고,
- Raw / Silver / Gold 구조(또는 Bronze/Silver/Gold)
- 접근 권한(ACL/RBAC) 명확히 설계

8.3 네트워크/보안(기업 환경)

VNet 인젝션, Private Link, 방화벽/NSG 정책 등은
“데이터 플레인”에서 고객이 통제한다는 점을 연결해서 설명

9. 자격증/인터뷰 포인트 (따로 정리)

9.1 자주 나오는 핵심 질문

Control Plane과 Data Plane의 차이?
- Control Plane: 관리/UI/설정/메타데이터
- Data Plane: 실행(클러스터)/데이터 저장소(ADLS/Blob)
비용은 어디서 발생?
- 대부분 Data Plane(클러스터 VM, 스토리지, 네트워크 egress 등)
노트북/잡 설정은 어디에 저장?
- Control Plane(설정/메타), 실행은 Data Plane
DBFS Root Storage를 메인 데이터레이크로 쓰면 안 되는 이유?
- 데이터 거버넌스/통제, 워크스페이스와 데이터 생명주기 분리, 공유/보안/운영 측면
Databricks에 접속하는 방법 2가지 이상 설명
- Workspace UI(SSO), REST API/CLI(토큰/자격증명 기반)