Haonly's Blog

여러가지 이유로 Spark DataFrame 의 row count 보다는 크기를 계산하여야 한다.

• Broadcast join 이 적합한지 확인용
• Executor 자원을 얼마나 할당할지 확인용
• 데이터 크기를 비교하여 DataFrame 이 정상적으로 생긴 것인지 확인용
• 다양하게...

disk 에 저장하지 않고도 Spark 에서 DataFrame 의 크기를 알려주는 API 가 있다.

import org.apache.spark.util.SizeEstimator
// dataframe 생성
SizeEstimator.estimate(df)

이런 방법으로 데이터 크기를 측정할 수 있다.

Spark Dataframe 에서 칼럼 사이즈 구하기: 스칼라 & 파이썬

1. Scala

import org.apache.spark.sql.SparkSession
import org.apache.spark.sql.functions._

// 스파크 세션 생성
val spark = SparkSession.builder()
  .appName("ArrayLengthExample")
  .getOrCreate()

// 예제 데이터프레임 생성
import spark.implicits._
val df = Seq(
  (Array(1.0, 2.0, 3.0)),
  (Array(4.0, 5.0)),
  (Array.empty[Double])
).toDF("double_array")

// double_array 배열의 길이를 계산
val dfWithArrayLength = df.withColumn(
  "array_length",
  size(col("double_array"))
)

// 결과 출력
dfWithArrayLength.show(truncate = false)

2. Python

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, size

# 스파크 세션 생성
spark = SparkSession.builder \
    .appName("ArrayLengthExample") \
    .getOrCreate()

# 예제 데이터프레임 생성
data = [
    ([1.0, 2.0, 3.0],),
    ([4.0, 5.0],),
    ([],)
]

df = spark.createDataFrame(data, ["double_array"])

# double_array 배열의 길이를 계산
df_with_array_length = df.withColumn(
    "array_length",
    size(col("double_array"))
)

# 결과 출력
df_with_array_length.show(truncate=False)

하둡에 적재된 Iceberg 테이블에 각 칼럼들에 대한 description 을 추가하여 
칼럼 설명을 달 수 있다.

테이블을 생성하며 하는 것이 더 효율적이겠지만 칼럼이 추가되거나 comment 를 추가하지 못했었다면 
spark shell 명령어로도 추가할 수 있다.

spark.sql("ALTER TABLE my_table ALTER COLUMN my_col_1 COMMENT '1번 칼럼입니다';")

Gitmoji

Gitmoji란 git + emoji를 합친 말로 gitmoji를 이용하여 commit message를 작성할 때 어떤 종류의 변경/커밋인지 아이콘으로 표시할 수 있는 기능이다.

gitmoji를 사용하면 가독성이 올라가기도 하며 커밋 자체가 예뻐진다!

IntelliJ / PyCharm 에서 설치법

보통 코드 commit 을 IntelliJ나 PyCharm 에서 하므로 여기에 적용해 두면 편하다.

1. shift 키 두번 눌러서 'plugins' 검색

2. Marketplace에 gitmoji 검색

3. 설치하고 재시작 해주면 끝이다!

아래는 gitmoji 아이콘별 코드, 설명이다.

가상 면접 사례로 배우는 대규모 시스템 설계 기초

내가 보려고 정리하는 내용

그냥 읽기만 하면 기억에 잘 남지 않으니 간단하게 정리하면서 읽어보자.

제 1장. 사용자 수에 따른 규모 확장성

1.1 DNS, 로드밸런서, 데이터베이스 다중화

사용자가 웹사이트에 접속하여 무언가 요청을 하는 간단한 시스템에서 확장성을 다룬다.

되게 오랫동안 기억 저 안쪽에만 넣어둔 'DNS' 가 나왔다.

• DNS: 도메인 이름(google.com)의 IP 주소를 알려준다.

사용자가 늘어감에 따라 하나의 서버에서 요청/처리를 하는 것이 아니라 여러 서버를 두어야 한다.

• 데이터베이스
  • RDBMS
  • NoSQL
  • 각각의 장단을 고려해 바람직한 데이터베이스를 사용해야 한다.

예를 들어 아주 낮은 응답 지연시간이 요구되거나 다루는 데이터가 정형 데이터가 아닐 경우 NoSQL을 사용해야 하는 경우가 있을 수  있다.

성능을 개선하는 방법으로 확장에 대해 소개한다.

• 수직적 규모 확장(scale up): 서버에 고사양 자원을 추가하는 행위
• 수평적 규모 확장(scale out): 더 많은 서버를 추가하여 성능을 개선하는 행위

웹 서버에 너무 많은 부하(사용자가 많아짐)가 생기면 웹 서버가 다운될 수 있어 이를 막기 위해 로드밸런서를 도입해야한다.

로드밸런서는 웹 서버들에게 트래픽을 고르게 분산하는 역할을 한다.

우리가 흔히 LB 구성한다고 할 때의 그 LB이다.

이렇게 분산된다면 웹 계층의 경우 분산된 서버끼리 트래픽을 골고루 나누게 되는데 데이터베이스의 경우 어떻게 해결할까? 장애의 복구나 다중화가 필요하다.

데이터베이스 다중화

• 쓰기 연산은 주 데이터베이스 서버로, 읽기 연산은 부 데이터베이스 서버 여러대로 분산시킬 수 있다.
• 이를 통해 더 나은 성능을 기대할 수 있고
• 데이터를 보존할 수 있어 안정성이 높아진다.
• 하나의 데이터베이스 서버에 장애가 발생하더라도 다른 서버의 데이터를 가져와 계속 서비스 할 수 있어 가용성이 높아진다.

1.2 캐시

캐시는 값비싼 연산 결과나 자주 참조되는 데이터를 메모리에 두어 뒤이은 요청이 빨리 처리될 수 있도록 하는 저장소이다.

캐시 계층은 데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨신 빠르다. 데이터 요청이 올 때 데이터베이스를 참조하기 전에 캐시에서 데이터를 반환할 수 있도록 한다.

캐시를 사용할 때 고려할 점

• 캐시를 쓰는 바람직한 상황
• 영구적으로 보관할 데이터라면 데이터베이스에 보관
• 만료에 대한 정책
• 일관성 유지
• 캐시 단일 서버 장애 대응(캐시 분산)
• 캐시 메모리 크기
• 어떤 데이터를 캐시에서 삭제할지(LRU, LFU, FIFO 등 대학생 때 배웠던 그것!)

1.3 CDN(콘텐츠 전송 네트워크)

CDN은 이미지, 비디오, CCS, java script 파일 등을 캐시할 수 있는 정적 콘텐츠를 전송하는데 쓰이는, 지리적으로 분산된 서버의 네트워크이다.

CDN은 보통 제 3 사업자에 의해 운영되어 데이터 전송 양에 따라 요금을 내게 된다.

정적 콘텐츠를 웹 서버를 통해 서비스하는 것이 아니라 CDN을 통해 제공해 더 나은 성능을 보장할 수 있다.

1.4 무상태(stateless) 웹 계층

서버의 수평적 확장에서 고려해야 할 부분으로 공유되어야할 상태 정보를 웹 계층에서 제거해야한다.

공유 데이터는 NoSQL 등에 저장할 수 있다.

1.5 데이터 센터

엄청 커져서 분산된 데이터 센터가 만들어졌다면, 즉 다중 데이터센터 아키텍처가 만들어진 상황이라면

동기화, 테스트 ,배포 등에 고려할 점들이 많다.

시스템 컴포넌트들을 분리하여 독립적으로 확장할 수 있도록 구성해야한다.

1.6 메시지 큐

비동기 통신을 지원하기 위한 메시지 큐는 메시지의 버퍼 역할을 하며 비동기적으로 전송한다.

카프카, Rabbit MQ 등에서 다뤄볼 수 있다.

메시지 큐를 이용하면 서비스 또는 서버간 결합이 느슨해져서 규모 확장성을 보장하는 애플리케이션을 구성하기 좋다.

1.7 로그, 메트릭 그리고 자동화

로그: 애플리케이션에서 발생하는 개별 이벤트로 에러 로그를 통해 오류를 찾을 수 있다.

메트릭: 시스템의 상태를 파악할 수 있다.

• CPU,  메모리 등 호스트 단위 메트릭
• 캐시 성능, 디비 성능인 종합 메트릭
• 재방문, 일별 능동 사용자 같은 것이 핵심 비즈니스 메트릭이라고 한다.

자동화: ci/cd등을 통한 생산성을 높이는 도구 또는 코드 검증 절차 자동화 등 개발 생산성을 향상 시키는 것

1.8 데이터베이스의 규모 확장

데이터베이스 또한 수직적/수평적 확장을 할 수 있다.

수직적 확장

• 스케일업
• 기존 서버에 더 많은 자원(CPU, RAM 등)을 증설하는 방법
• 많은 양의 데이터를 보관하고 처리할 수 있다.
• 단일 포인트 실패로 인한 문제점이 크다.
• 비용이 많이 든다

수평적 확장

• 데이터베이스의 수평적 확장은 샤딩이라고 부른다.
• 더 많은 서버를 추가함으로써 성능을 향상시킨다.
• 대규모 데이터베이스를 샤드라고 부르는 작은 단위로 분할하는 기술로 각각의 샤드에 보관되는 데이터 사이에는 중복이 없다.

안정적인 시스템 규모 확장을 위해서는

웹 계층은 무상태 계층으로, 모든 계층에는 다중화를 도입하고 데이터 계층 샤딩은 필수

각 계층은 독립적 서비스로 분할하며 모니터링과 자동화 필수

오류

error: scala.reflect.internal.MissingRequirementError: object java.lang.Object in compiler mirror not found.

원인

scala 2.11  버전과 java SDK 버전이 맞지 않아 발생하는 오류

해결방법

scala 버전에 맞게 java SDK를 8 버전으로 바꾼다.

나의 경우 9버전이었다.