Spark (2) - Spark 구성 요소 이해하기 - Databricks & Unity Catalog & RDD

원래는 Databricks 에서 
Community Edition으로 노트북 환경 실습이 가능했지만,
Community Edition 에서 Free Edition으로 전환되어서 실습이 제한되었다.

따라서 For Work(업무용) 환경으로 대체해서 (AWS 연동)
DBU(Databricks Unit) + AWS 인스턴스 비용 형식으로 실습을 진행할거고
사용량 기준으로 과금이 될 수 있다.

PC방으로 비유하자면,
컴퓨터 이용로(AWS) 와 유료 게임 접속료(DBU)를 동시에 내는것과 같다.

실습 진행하면서 틈틈히 과금을 확인하면서 진행해야할것 같다.

---

1. Databricks 란?

Spark를 기업 환경에 맞게 만든 확장-운영 가능한 플랫폼

 

Databricks는 "Apache Spark 기반의 클라우드 데이터 플랫폼" 이다.

대용량 데이터 처리, SQL 분석, 머신러닝, 데이터 파이프라인 구척을 하나의 환경에서 통합 수행

 

1-1. 주요 기능

• 대용량 데이터 처리
• SQL 분석 및 시각화
• 머신러닝 (ML)
• 데이터 파이프라인 구축

1-2. 왜 많이 쓰는가?

• 관리 편의성: Spark 직접 구축 불필요하고 클러스터를 자동으로 관리해준다.
• 기업용 보안: 엔터프라이즈급 보안 기능 및 거버넌스 제공
• 클라우드 연동: AWS / Azure / GCP 등 원활한 통합 지원
• 성능 최적화: 최적화된 런타임으로 빠른 처리 속도

---

2. Databricks 아키텍쳐 (옛날 vs 현재)

2-1. 옛날(전통적인) 구조

• Hive Metastore 사용
• DBFS 파일 시스템 (이전 포스팅에서 배운 로컬 파일 시스템 여러개 두는 시스템)
• SparkContext 직접 접근 가능
• RDD 자유롭게 사용 가능 (RDD 개념은 아래 소제목 4에 있음)

 

2-2. 현재 구조

• Unity Catalog 기본 사용 (해당 개념은 아래 소제목 3에 있음
• Volume 기반 파일 관리
• Spark Connect 구조
• DataFrame 중심 사용

구조를 보면 이제 Notebook이 직접 Driver를 조작하지 않게 되었다.

기업 보안 중심적인 구조로 변화하게 된것이다.

 

---

3. Unity Catalog 란?

Databricks에서 데이터 자산을 중앙에서 관리하는 시스템으로,
메타데이터, 권한, 데이터 거버너스를 통합적으로 제어하는 계층이다.
"누가 어떤 데이터에 접근하는지 중앙에서 빡빡하게 감시하겠다"

 

1) 메타 데이터 중앙 관리

테이블 정의, 컬럼 정보, 데이터 위치를 계층적으로 관리한다.

Catalog
	ㄴ Schema
    	ㄴ Table / View / Volume

 

2) 권한 관리 (핵심)

매우 세밀한 단위로 보안 통제가 가능하며 중앙에서 일괄 적용된다.

• Catalog 단위, Schema 단위, Table 단위, Column 단위

3) 데이터 거버넌스

• 누가 어떤 데이터를 조회했는지 접근 기록
• 상세한 감사 로그 (Audit Log) 저장
• 데이터 계보 (Lineage) 추적을 통한 흐름 파악

4) 파일까지 통제 (Volumes)

비정형 파일도 객체처럼 관리하여 보안성을 높인다.

• 예전: /dbfs/path/to/file
• 현재: /Volumes/catalog/schema/...

---

4. RDD란? (간단히만 학습, 뒤에서 추가 학습 예정)

"Resilient Distributed Dataset"
Spark의 1세대 분산 데이터 구조로, 클러스터의 여러 노드에 분산되어 저장된 변경 불가능한 데이터 컬렉션

개발자가 "데이터를 이렇게 쪼개고, 저렇게 합쳐"라고 일일이 명령하고, 개발자가 코드를 짜는 대로만 작동한다.

 

• 분산 리스트
  • 데이터가 여러 노드에 나뉘어 저장 및 처리됨
• 불변성 (Immutable)
  • 생성된 후에는 변경 불가
    새로운 RDD로 변환만 가능
• 지연 실행 (Lazy)
  • Action이 호출될 때 까지실제 연산을 수행하지 않음
• 장애 복구
  • Lineage 정보를 통해 유실된 데이터를 재계산

4-1. RDD의 현재 위치 및 위상

• Spark의 기초/핵심 개념
  • 모든 상위 API(DataFrame)는 내부적으로 RDD로 변환되어 실행됨
• 내부 동작 이해용
  • Spark의 작동 원리와 최적화를 이해하기 위해 학습 필요

4-2. 실무 활용도

최신 Databricks 환경(Unity Catalog)에서는 보안상의 이유로 RDD 사용이 제한 될 수 있음

• 실무에서는 거의 사용 안함
  • 대부분의 작업은 최적화된 DataFrame이나 Dataset API를 사용
• 레거시 코드 유지보수
  • 오래된 Spark 어플리케이션이나 비정형 데이터의 복잡한 로우 레벨 처리 시 제한적 사용

---

5. RDD를 제한하는 이유

보안 + 구조 변화 + 성능 최적화 때문에 제한

과거의 Spark는 성능에만 집중했지만, 이제 기업들은 수천 명의 직원이 같은 데이터를 안전하게 나눠 쓰길 원한다.
그래서 Unity Catalog 로 문지기를 세우고, Spark Connect 로 서버 내부를 보호하며,
사고가 났을 때 Lineage 로 범인을 찾는 구조로 바뀐 것이다.

 

1) Spark Connect 구조

RDD는 SparkContext에 직접 접근해야 하지만,

최신 아키텍처는 Client-Server 분리 구조(Spark Connect)르 사용하므로 직접 접근이 제한된다.

 

2) Unity Catalog 충돌

RDD는 파일 경로에 직접 접근할 수 있어,

중앙 통제 및 권한 권리 시스템인 Unity Catalog의 보안 정책을 우회할 위험이 있다.

 

3) 최적화 문제

• RDD: Catalyst Optimizer의 최적화를 받지 못함
• DataFrame: 실행 계획 자동 최적화로 월등한 성능 보장

4) 멀티 사용자 환경 보호

여러 사용자가 클러스터를 공유하는 환경에서,
개별 사용자가 JVM에 직접 접근(RDD 방식)하는 것을 제한하여 시스템 안정성을 확보한다.