데이터과학 삼학년

아파치 피닉스(Apache Phoenix): HBase에서 SQL을 이용한다?!

Dan-k — Tue, 18 Mar 2025 22:12:16 +0900

HBase는 대규모 데이터를 처리하는 NoSQL 데이터베이스

하지만 HBase는 SQL을 지원하지 않음

아파치 피닉스(Apache Phoenix)는 HBase 위에서 SQL을 사용할 수 있도록 해주는 도구

1. 아파치 피닉스란?

- HBase의 SQL 계층을 제공하는 쿼리 엔진

- SQL 쿼리로 HBase 데이터를 관리하고 조회할 수 있도록 도와줌

- JDBC 연결을 통해 기존 SQL 기반 애플리케이션에서 HBase를 쉽게 활용 가능

- HBase의 분산 처리 성능을 그대로 유지하며 SQL로 데이터를 다룰 수 있음

2. 아파치 피닉스의 주요 특징

- SQL 지원

SQL을 통해 HBase 데이터를 직관적으로 쿼리하고 관리 가능

- HBase 통합

HBase 위에서 실행되어, 분산 아키텍처를 그대로 활용

- JDBC 지원

SQL 기반 애플리케이션에서 HBase와 쉽게 연결 가능

- 고성능

쿼리 최적화를 통해 대규모 데이터 처리 성능 최적화

- 쿼리 최적화

복잡한 SQL 쿼리를 자동으로 최적화해 빠른 성능 제공

3. 아파치 피닉스 사용 예시

SQL 쿼리로 HBase 테이블 생성, 데이터 삽입, 조회 가능

CREATE TABLE my_table (id INTEGER PRIMARY KEY, name VARCHAR);
UPSERT INTO my_table VALUES (1, 'John Doe');
SELECT * FROM my_table;

SQL을 사용하여 HBase 데이터 모델링

테이블 생성, 인덱스 추가, 데이터 수정 등을 SQL로 처리

CREATE TABLE employees (
    id INTEGER PRIMARY KEY,
    name VARCHAR,
    department VARCHAR
);

4. 아파치 피닉스 사용의 장점

- SQL 쿼리 지원으로 SQL에 익숙한 개발자가 쉽게 사용 가능

- HBase의 성능과 SQL의 편리함을 동시에 활용

- JDBC 지원으로 기존 SQL 기반 애플리케이션에서 HBase를 손쉽게 연결

- 자동 쿼리 최적화로 빠른 데이터 처리 속도 제공

테이블 직원 만들기 ( ID 정수 기본 키, 이름 바르 차르, 부서 Varchar );

큰 수의 법칙, 중심극한의 정리

Dan-k — Sun, 16 Mar 2025 18:13:23 +0900

1. 큰 수의 법칙(Law of Large Numbers, LLN)

큰 수의 법칙은 표본 크기가 커질수록 표본의 평균이 모집단의 평균에 가까워진다는 정리입니다.

✔️ 개념
• 표본 크기 n 이 커질수록 표본 평균 $ \bar{X} $은 모집단 평균 $ \mu $ 에 수렴
• 개별 표본 값이 변동성이 크더라도, 많은 데이터를 모으면 전체적인 경향이 모집단을 반영

✔️ 수식

표본 평균 $ \bar{X}n $ 은 모집단 평균 $ \mu $ 에 확률적으로 수렴

\[
\lim_{n \to \infty} \bar{X}_n = \mu
\]

✔️ 예제

예를 들어, 동전을 던질 때 앞면이 나올 확률은 0.5입니다.
하지만 동전을 10번 던지면 앞면이 정확히 5번 나올 확률은 낮습니다.
그러나 1000번, 10000번 던질수록 앞면이 나오는 비율은 0.5에 가까워짐.

2. 중심극한정리(Central Limit Theorem, CLT)

중심극한정리는 표본의 크기가 충분히 크면, 모집단의 분포와 관계없이 표본평균의 분포가 정규분포를 따른다는 정리입니다.

✔️ 개념
• 모집단이 어떤 분포든지 상관없이, 충분히 큰 표본을 반복적으로 추출하면 표본 평균의 분포는 정규분포에 가까워짐
• 표본 크기가 커질수록 표본 평균의 분포가 평균 $ \mu $ , 분산 $ \sigma^2/n $ 인 정규분포 $ N(\mu, \sigma^2/n) $ 에 수렴

✔️ 수식

표본 평균 $ \bar{X} $ 의 분포는
$$ \bar{X} \sim N\left( \mu, \frac{\sigma^2}{n} \right) $$단, n이 클 때

✔️ 예제

예를 들어, 주사위를 던지는 경우
• 주사위 하나의 숫자는 균등분포(Uniform Distribution)를 따름
• 하지만 주사위를 30번 던지고 평균을 구하면, 그 값들의 분포는 점점 정규분포에 가까워짐

3. 큰 수의 법칙 vs 중심극한정리 차이점

	큰 수의 법칙 (LLN)	중심극한정리 (CLT)
핵심 내용	표본 평균이 모집단 평균에 수렴	표본 평균의 분포가 정규분포에 가까워짐
목적	표본 크기가 커질수록 평균이 모집단의 평균과 같아짐을 보장	표본의 크기가 커질수록 분포 형태가 정규분포에 가까워짐을 보장
필요한 표본	크기 크면 클수록 좋음	대략 30개 이상이면 정규분포 근사 가능
적용 예시	동전을 1000번 던지면 앞면 비율이 0.5에 가까워짐	주사위를 30번씩 여러 번 던지면 평균값들이 정규분포를 따름

즉,
• 큰 수의 법칙은 “많이 하면 평균이 모집단과 같아진다”
• 중심극한정리는 “표본평균의 분포가 정규분포에 가까워진다”

불균형 데이터 오버샘플링 기법: SMOTE, ADASYN, SMOTE-Tomek Link

Dan-k — Sun, 23 Feb 2025 20:30:41 +0900

1. SMOTE (Synthetic Minority Over-sampling Technique)

개념

SMOTE는 소수 클래스(minority class)의 데이터를 합성하여 새로운 데이터를 생성하는 방식의 오버샘플링 기법입니다. 단순히 데이터를 복제하는 것이 아니라, K-최근접 이웃(K-NN) 기반으로 새로운 데이터를 생성하여 데이터의 다양성을 증가시킵니다.

알고리즘

소수 클래스의 데이터 샘플을 선택합니다.
선택된 샘플의 K-최근접 이웃을 찾습니다.
이웃 중 하나를 랜덤하게 선택하여 기존 데이터와의 차이를 계산합니다.
이 차이에 랜덤한 값을 곱하고 기존 데이터에 더하여 새로운 데이터를 생성합니다.

장점

기존 데이터를 단순 복제하는 것이 아니라, 새로운 데이터를 생성하여 모델의 일반화 성능을 향상시킴.
다양한 데이터 분포를 유지하면서 소수 클래스의 샘플 수를 증가시킴.

단점

생성된 샘플이 실제 데이터가 아니므로, 원본 데이터의 분포를 왜곡할 가능성이 있음.
노이즈가 있는 데이터의 경우, 노이즈까지 증폭될 위험이 있음.

2. ADASYN (Adaptive Synthetic Sampling)

개념

ADASYN은 SMOTE와 유사한 방식으로 새로운 데이터를 생성하지만, 데이터 밀도가 낮은 영역에 더 많은 샘플을 생성하는 방식으로 적응적(adaptive) 오버샘플링을 수행합니다.

알고리즘

각 소수 클래스 샘플의 K-최근접 이웃을 찾고, 다수 클래스 샘플과의 비율을 계산하여 샘플링 가중치를 부여합니다.
샘플링 가중치가 높은(즉, 데이터 밀도가 낮은) 샘플 주변에서 더 많은 데이터를 생성합니다.
새로운 데이터를 생성하는 과정은 SMOTE와 유사하지만, 밀도가 낮은 영역일수록 더 많은 샘플이 추가됩니다.

장점

소수 클래스의 데이터 분포를 더욱 자연스럽게 확장할 수 있음.
밀도가 낮은 영역을 보완하여 모델의 성능을 향상시킬 가능성이 높음.

단점

노이즈가 많은 데이터셋에서는 성능이 저하될 수 있음.
계산량이 증가할 가능성이 있음.

3. SMOTE-Tomek Link

개념

Tomek Link는 데이터 정제(cleaning) 기법으로, 클래스 간 경계에 위치한 샘플을 제거하여 더 명확한 분류 경계를 만들도록 돕습니다. SMOTE와 결합하여 오버샘플링과 언더샘플링을 함께 수행하면, 데이터의 균형을 맞추면서도 더 정제된 데이터셋을 만들 수 있습니다.

알고리즘

SMOTE를 적용하여 소수 클래스 데이터를 합성합니다.
Tomek Link를 찾아 제거합니다.
- Tomek Link: 두 개의 샘플 (A, B)이 서로의 최근접 이웃이며, A는 다수 클래스, B는 소수 클래스인 경우, B를 제거합니다.

장점

SMOTE의 단점을 보완하여 경계에 위치한 애매한 샘플을 정리함으로써 모델의 성능 향상 가능.
불필요한 데이터 포인트를 줄여 과적합(overfitting) 가능성을 낮춤.

단점

Tomek Link 제거 과정에서 일부 중요한 경계 데이터까지 손실될 가능성이 있음.
데이터 양이 줄어들기 때문에, 성능 향상이 보장되지 않을 수도 있음.

4. 비교

기법 장점 단점

SMOTE	데이터 다양성 증가, 과적합 방지	데이터 왜곡 가능성, 노이즈 증폭 위험
ADASYN	밀도가 낮은 영역을 보완, 자연스러운 데이터 생성	노이즈가 많은 데이터에서는 성능 저하 가능
SMOTE-Tomek Link	경계 정리로 모델 성능 향상, 과적합 방지	중요한 샘플 손실 가능성, 데이터 감소

5. 결론

단순한 오버샘플링이 필요한 경우에는 SMOTE를, 데이터 밀도가 낮은 영역을 보완하고 싶다면 ADASYN을, 데이터 정제까지 함께 고려하고 싶다면 SMOTE-Tomek Link를 고려

https://towardsdatascience.com/smote-synthetic-data-augmentation-for-tabular-data-1ce28090debc/

SMOTE: Synthetic Data Augmentation for Tabular Data | Towards Data Science

An exploration of SMOTE and some variants like Borderline-SMOTE and ADASYN

towardsdatascience.com

LLM을 활용한 추천 시스템

Dan-k — Mon, 27 Jan 2025 10:05:24 +0900

LLM을 활용한 추천 시스템: 넷플릭스 데이터셋 사례

추천 시스템은 방대한 콘텐츠 속에서 사용자들이 적합한 항목을 찾을 수 있도록 돕는 중요한 역할을 하고 있습니다. 여러분이 이 글을 발견한 것도 추천 시스템 덕분일 가능성이 높습니다.

기존의 추천 시스템은 주로 협업 필터링과 콘텐츠 기반 필터링에 의존해 왔습니다. 하지만 최근 등장한 **대규모 언어 모델(LLMs)**은 이 분야에 새로운 가능성을 열어주고 있습니다. 이번 글에서는 넷플릭스 데이터셋을 활용하여 LLM 기반 추천 시스템을 구축하는 과정을 소개하고, 이 기술이 추천 시스템을 어떻게 혁신하는지 알아보겠습니다.

LLM이 추천 시스템에서 게임 체인저가 되는 이유

LLM은 기존 추천 시스템과 비교해 여러 가지 독특한 강점을 제공합니다.

1. 풍부한 세계 지식

LLM은 방대한 데이터 학습을 통해 축적된 세계 지식을 내포하고 있어, 보다 세부적이고 문맥적으로 적합한 추천이 가능합니다.

2. 제로샷 및 퓨샷 학습 능력

사전 학습된 모델로도 새로운 추천 시나리오에 빠르게 적응할 수 있습니다.

3. 고품질 텍스트 표현 생성

텍스트를 이해하고 표현하는 데 강점을 가져, 더 정교한 콘텐츠 기반 추천이 가능합니다.

시스템 개념과 설계

이 시스템의 핵심은 LLM을 활용해 영화 설명을 임베딩(embedding)으로 변환하는 것입니다. 이 임베딩은 영화의 의미적 정보를 내포하며, 이를 기반으로 유사한 영화를 빠르게 찾을 수 있습니다. 유사성 검색은 FAISS(Facebook AI Similarity Search) 라이브러리를 활용해 효율적으로 수행됩니다.

구현 과정

1. 데이터 준비

먼저 넷플릭스 데이터셋을 불러와 각 영화의 다양한 정보를 텍스트로 결합합니다.

import pandas as pd

df = pd.read_csv("netflix_titles.csv")

def create_textual_representation(row):
    return f"""Type: {row['type']}, Title: {row['title']}, Director: {row['director']}, Cast: {row['cast']}, Released: {row['release_year']}, Genres: {row['listed_in']}, Description: {row['description']}"""

df['textual_representation'] = df.apply(create_textual_representation, axis=1)

이 과정은 영화의 타입, 제목, 감독, 배우, 장르, 설명 등의 정보를 하나의 텍스트로 결합합니다. 이렇게 생성된 텍스트는 LLM의 입력값으로 사용됩니다.

2. 임베딩 생성

LLM(LLaMA 2)을 활용하여 각 텍스트의 임베딩을 생성합니다. 아래는 로컬 API를 사용하여 임베딩을 생성하는 예제입니다.

import requests

def get_embedding(text):
    res = requests.post('http://localhost:11434/api/embeddings', json={'model': 'llama2', 'prompt': text})
    return res.json()['embedding']

최적화 팁

임베딩 캐싱: 반복 작업을 줄이기 위해 생성된 임베딩은 로컬 파일에 저장합니다.
병렬 처리: 데이터가 클 경우, ThreadPoolExecutor를 사용해 병렬로 임베딩을 생성하여 처리 속도를 높입니다.

3. FAISS 인덱스 생성

FAISS를 사용해 임베딩 기반 유사성 검색을 위한 인덱스를 생성합니다.

import faiss

index = faiss.IndexFlatL2(4096)  # 임베딩 차원 크기
index.add(X)  # X는 생성된 임베딩 배열

FAISS는 대규모 데이터셋에서도 빠른 유사성 검색이 가능하며, 확장성 있는 구조를 제공합니다.

4. 추천 생성

특정 영화와 유사한 영화를 추천하려면 해당 영화의 임베딩을 기준으로 인덱스에서 가장 가까운 임베딩을 찾습니다.

def get_recommendations(movie_index, num_recommendations=5):
    movie_embedding = X[movie_index].reshape(1, -1)
    D, I = index.search(movie_embedding, num_recommendations + 1)
    return df.iloc[I[0][1:]]  # 입력 영화는 제외

예를 들어, favorite_movie_index = 1358로 설정하면, 해당 영화와 유사한 영화 목록을 출력할 수 있습니다.

이 접근법의 장점

1. 의미적 이해

LLM을 통해 설명, 장르, 캐스트 등 다양한 정보를 학습하여 영화 간의 미묘한 관계를 이해할 수 있습니다.

2. 유연성

새로운 특성(feature)을 쉽게 추가하거나, 텍스트 외 다른 콘텐츠로도 확장 가능합니다.

3. 확장성

FAISS를 통해 수백만 개 이상의 항목을 효율적으로 처리할 수 있습니다.

4. 콜드 스타트 문제 해결

사용자 기록이 없는 경우에도 콘텐츠 기반 추천이 가능해 초기 사용자 경험을 개선할 수 있습니다.

한계점 및 개선 방향

1. 텍스트 품질 의존성

영화 설명이나 메타데이터가 부실할 경우, 추천 품질이 낮아질 수 있습니다.

2. 개인화 부족

사용자 선호도와 시청 기록을 반영하지 않아 개인화된 추천이 어렵습니다.

3. 모델 성능 의존성

사용하는 LLM과 임베딩 품질에 따라 시스템 성능이 크게 좌우됩니다.

4. 실시간 응답성

대규모 데이터에서 실시간으로 작동하려면 추가적인 최적화가 필요합니다.

결론

LLM을 활용한 추천 시스템은 기존 방식과는 다른 차원의 추천 경험을 제공합니다. 텍스트 데이터를 보다 깊이 이해하고 활용할 수 있어 더 정교한 추천이 가능하며, 특히 콘텐츠 기반 추천에 강점을 보입니다.

이 글에서 소개한 구현은 비교적 간단한 예제지만, LLM과 FAISS의 결합을 통해 고도화된 추천 시스템 구축의 가능성을 보여줍니다. 앞으로 LLM 기술이 더욱 발전하면서 추천 시스템의 새로운 패러다임이 열릴 것으로 기대됩니다.

참고 자료

Netflix Titles Dataset: Kaggle
FAISS Documentation: FAISS GitHub

MAB(Multi-Armed Bandit), 톰슨 샘플링

Dan-k — Fri, 24 Jan 2025 10:00:25 +0900

1. MAB란 무엇인가?

Multi-Armed Bandit(MAB) 문제는 여러 개의 슬롯 머신(팔을 당기는 밴딧) 중에서 어느 것을 선택해야 가장 높은 보상을 얻을 수 있는지 결정하는 문제입니다. 이 문제는 탐색(Exploration)과 활용(Exploitation) 사이의 균형을 잡는 것이 핵심입니다.

주요 구성 요소

팔(Arm): 선택 가능한 슬롯 머신 또는 행동.
보상(Reward): 선택한 팔에서 얻는 결과(예: 클릭, 구매 등).
목표: 보상의 합계를 최대화.

MAB 문제는 A/B 테스트, 광고 배치, 콘텐츠 추천 등 다양한 실생활 문제에 응용됩니다.

2. 탐색과 활용의 트레이드오프

MAB의 가장 큰 도전 과제는 탐색과 활용 사이의 트레이드오프를 해결하는 것입니다.

탐색(Exploration): 더 나은 팔을 찾기 위해 새로운 선택을 시도.
활용(Exploitation): 현재 가장 성과가 좋은 팔을 선택하여 보상을 극대화.

예시

만약 3개의 팔을 가진 슬롯 머신이 있다고 가정해봅시다. 각각의 팔은 서로 다른 확률로 보상을 제공합니다. 이 확률을 미리 알 수 없기 때문에 탐색과 활용을 통해 최적의 팔을 찾아야 합니다.

3. 톰슨 샘플링(Thompson Sampling)

개요

톰슨 샘플링은 확률론적 방법을 이용해 탐색과 활용을 균형 있게 수행하는 알고리즘입니다. 각 팔의 보상 분포를 추정하기 위해 베타 분포를 사용합니다.

동작 원리

각 팔에 대해 베타 분포를 초기화합니다.
- 베타 분포의 초기값은 (모두 동일한 사전 정보).
- 알파가 커질수록 오른쪽으로 봉우리가 이동!!!! -> 즉, 선택(성공)될 수록 선택될 확률이 높아지는 것!!
각 팔에서 샘플을 한 번씩 추출합니다.
가장 높은 샘플 값을 가진 팔을 선택합니다.
선택한 팔의 결과에 따라 베타 분포를 업데이트합니다.
- 성공(보상 획득):
- 실패(보상 미획득):
위 과정을 반복합니다.

4. 예제 코드

아래는 톰슨 샘플링을 구현한 Python 코드입니다:

import numpy as np
from scipy.stats import beta
import matplotlib.pyplot as plt

# 팔의 실제 보상 확률
true_conversion_rates = [0.1, 0.3, 0.5]
num_arms = len(true_conversion_rates)

# 각 팔의 베타 분포 파라미터 초기화
alpha = np.ones(num_arms)
beta_params = np.ones(num_arms)

# 시뮬레이션 설정
num_trials = 1000
rewards = np.zeros(num_trials)

for trial in range(num_trials):
    # 1. 각 팔의 샘플링
    sampled_theta = [np.random.beta(alpha[i], beta_params[i]) for i in range(num_arms)]

    # 2. 가장 높은 샘플 값을 가진 팔 선택
    chosen_arm = np.argmax(sampled_theta)

    # 3. 선택된 팔에서 보상 관찰
    reward = np.random.rand() < true_conversion_rates[chosen_arm]

    # 4. 보상에 따라 베타 분포 업데이트
    if reward:
        alpha[chosen_arm] += 1
    else:
        beta_params[chosen_arm] += 1

    # 보상 기록
    rewards[trial] = reward

    # 5. 주기적으로 베타 분포 시각화
    if trial % 200 == 0 or trial == num_trials - 1:
        x = np.linspace(0, 1, 1000)
        plt.figure(figsize=(12, 6))
        for i in range(num_arms):
            plt.plot(x, beta.pdf(x, alpha[i], beta_params[i]), label=f"Arm {i+1}: Beta({alpha[i]}, {beta_params[i]})")
        plt.title(f"Trial {trial+1}")
        plt.legend()
        plt.show()

print(f"총 보상: {rewards.sum()}")

5. 결과 분석

위 코드는 다음을 보여줍니다:

초기에는 각 팔에 대해 고르게 탐색합니다.
시간이 지남에 따라 가장 보상이 높은 팔을 점점 더 자주 선택하게 됩니다.
각 팔의 베타 분포는 트라이얼이 진행됨에 따라 업데이트됩니다.

시각화

각 팔의 베타 분포를 시각화하면 탐색 및 활용 과정에서 팔들의 우선순위가 어떻게 변화하는지 확인할 수 있습니다.

처음에는 각 arm의 확률 분포를 기준으로 랜덤하게 선택했을때 선택되는 arm이 다를 수 있지만,

시도(exploration)가 반복됨에 따라 각 arm의 확률분포가 극단적으로 수렴하여 랜덤하게 선택되어도, 가장 우측에 봉우리가 만들어진 arm이 계속 선택될 것(exploitation)

6. 결론

톰슨 샘플링은 간단하면서도 강력한 MAB 알고리즘입니다. 베타 분포를 활용해 확률론적으로 최적의 선택을 수행하며, 실생활의 다양한 문제에 적용 가능합니다.

MAB 알고리즘은 온라인 광고, 콘텐츠 추천, 의료 실험 등 다양한 분야에서 큰 가치를 제공합니다. 특히, 탐색과 활용의 균형을 자동으로 맞춘다는 점에서 실용성이 매우 높습니다.

import numpy as np

class ThompsonSampling:
    def __init__(self, num_arms):
        self.num_arms = num_arms
        self.successes = np.ones(num_arms)  # 각 팔의 성공 횟수 초기화
        self.failures = np.ones(num_arms)  # 각 팔의 실패 횟수 초기화

    def select_arm(self):
        # 각 팔에 대한 베타 분포에서 샘플링
        samples = np.random.beta(self.successes, self.failures)
        # 가장 높은 확률 값을 가진 팔 선택
        return np.argmax(samples)

    def update(self, chosen_arm, reward):
        if reward:
            self.successes[chosen_arm] += 1
        else:
            self.failures[chosen_arm] += 1
            

def run_experiment(num_arms, trials, data):
    ts = ThompsonSampling(num_arms)
    total_reward = 0
    for _ in range(trials):
        selected_arm = ts.select_arm()
        reward = get_reward(selected_arm, data)
        total_reward += reward
        ts.update(selected_arm, reward)
    return total_reward


# 예시 데이터
data = {0: 0.3, 1: 0.7, 2: 0.2}  # 각 팔의 실제 보상 확률
num_arms = len(data)
trials = 1000

total_reward = run_experiment(num_arms, trials, data)
print("Total reward:", total_reward)

참고자료

https://multithreaded.stitchfix.com/blog/2020/08/05/bandits/\

Multi-Armed Bandits and the Stitch Fix Experimentation Platform | Stitch Fix Technology – Multithreaded

We understand that there is a lot going on in the world right now. We’re continuing to publish blog posts in the hope they provide some intellectual stimulation and a sense of connection during these times. See the following for actions that we’re taki

multithreaded.stitchfix.com

[Spark] 스파크 사용 최적화 / 유의사항!!!

Dan-k — Wed, 25 Dec 2024 18:26:31 +0900

스파크 사용 시 흔히 저지르는 실수와 최적화 방법

스파크는 빅데이터 처리를 위한 프레임워크로, 빠른 처리 속도로 유명합니다. 이전 글에서는 스파크의 기본 개념과 빠른 이유에 대해 다루었습니다. 이번 글에서는 스파크 애플리케이션의 성능과 메모리 활용을 개선하기 위해 알아야 할 흔한 실수와 최적화 방법에 대해 다루겠습니다. 여기에는 클러스터 최적화, 설정 값 조정, 코드 수준의 최적화 등이 포함됩니다.

실수 1: 지연 평가(Lazy Evaluation)를 이해하지 못함

스파크는 전통적인 스크립트처럼 코드 라인별로 실행되지 않습니다.

data = spark.read.csv("large_file.csv")

data.filter(data["age"] > 30)

print("Filtering done.")

위 코드에서 print 문은 실행되지만, 스파크는 아직 필터링을 처리하지 않았습니다. 스파크는 지연 평가를 사용하여, 변환 작업은 액션(예: .collect() 또는 .saveAsTextFile())이 트리거될 때만 실행됩니다. 즉각적인 실행을 기대하면 혼란스러울 수 있습니다.

변환 작업(지연된 연산)과 액션(실행을 트리거하는 연산)의 차이를 이해해야 합니다.

data = spark.read.csv("large_file.csv")

filtered_data = data.filter(data["age"] > 30)

filtered_data.show()  # 이 액션이 실행을 트리거합니다.

###

실수 2: 데이터 분포를 고려하지 않고 기본 파티션 사용

잘못된 데이터 파티셔닝은 작업 부하 분배의 불균형을 초래하여 작업이 느려지거나 충돌할 수 있습니다.

파티셔닝 무시

데이터 파티셔닝은 성능에 매우 중요합니다. 특히 데이터셋을 조인할 때 그렇습니다. 적절한 파티셔닝 없이 스파크는 데이터를 반복적으로 셔플링하여 불필요한 성능 저하를 초래할 수 있습니다. 병렬 처리는 스파크 작업 튜닝에서 매우 중요한 역할을 합니다. 각 파티션 ~ 작업은 처리에 단일 코어를 필요로 합니다.

너무 많은 또는 너무 적은 파티션 사용

너무 많은 파티션은 불필요한 오버헤드를 추가할 수 있고, 너무 적은 파티션은 클러스터 자원을 충분히 활용하지 못할 수 있습니다. 일반적인 가이드라인은 코어 수의 2~3배 정도의 파티션을 가지는 것입니다. 큰 데이터셋에 대해 파티션을 조정하지 않으면 불균형한 처리가 발생할 수 있습니다.

large_data = spark.read.csv("large_file.csv")

print(large_data.rdd.getNumPartitions())  # 기본 파티션 수가 높거나 낮을 수 있습니다.

###

.repartition() 또는 .coalesce() 사용하여 파티셔닝 조정

partitioned_data = large_data.repartition(10)

print(partitioned_data.rdd.getNumPartitions())  # 이제 10개의 파티션으로 설정되었습니다.

.repartition(numPartitions): 파티션 수를 증가 또는 감소시키는 데 사용됩니다. 클러스터의 노드 간에 데이터를 셔플링하므로 비용이 많이 듭니다. 더 많은 파티션이 필요하거나 조인 작업 후 데이터를 고르게 분배할 때 유용합니다.

.coalesce(numPartitions): 주로 파티션 수를 줄이는 데 사용됩니다. 동일한 노드 내에서 파티션을 병합하여 셔플링을 피하므로 .repartition()보다 저렴합니다. 특히 처리 후 출력 준비를 위해 파티션을 통합할 때 유용합니다.

실수 3: 캐시/퍼시스트를 적절히 사용하지 않음

데이터를 여러 번 사용할 때 캐시하지 않으면 스파크는 각 변환을 다시 계산합니다. 이는 변환이 복잡할 경우 비용이 많이 들 수 있습니다.

# 캐시 없이 데이터를 여러 번 사용

filtered_data = data.filter(data["age"] > 30)

filtered_data.count()

filtered_data.show()

각 액션은 필터링 단계를 다시 트리거합니다.

.cache() 또는 .persist() 사용

# 데이터를 재사용할 의도가 있다면 캐시합니다.

filtered_data = data.filter(data["age"] > 30).cache()

filtered_data.count()

filtered_data.show()  # 이제 더 빠르게 실행됩니다.

캐시 및 퍼시스트의 부적절한 사용

많은 사람들이 캐시(예: cache() 또는 persist())를 간과하여 반복 알고리즘이나 반복 액세스에서 재계산을 피할 수 있습니다. 그러나 모든 것을 캐시하면 메모리 문제가 발생할 수 있습니다. 필요할 때만 캐시하고 데이터가 더 이상 필요하지 않을 때는 unpersist를 사용하여 캐시를 해제하세요.

너무 많은 변환 체인

중간 액션이나 캐시 없이 긴 변환 체인은 계보를 너무 복잡하게 만들어 실행 시간을 증가시킬 수 있습니다. 때로는 복잡한 체인을 분할하고 액션을 도입하거나 데이터를 캐시하는 것이 좋습니다.

실수 4: 셔플 작업의 잘못된 구성

셔플 작업(예: join, groupBy)은 네트워크와 메모리에 무거운 작업입니다. 잘못된 구성은 이러한 작업이 실패하게 만들 수 있습니다.

joined_data = large_data1.join(large_data2, "id")

joined_data.show()

데이터 크기에 따라 셔플 관련 구성을 조정하고 가능한 셔플을 줄이세요.

spark.conf.set("spark.sql.shuffle.partitions", "100")  # 데이터 크기에 따라 조정

joined_data = large_data1.join(large_data2, "id")

joined_data.show()

실수 5: 큰 데이터셋을 드라이버로 수집

큰 데이터셋을 .collect() 또는 .take()로 드라이버로 가져오는 것은 메모리 오류를 일으킬 수 있습니다.

all_data = data.collect()  # 전체 데이터셋을 드라이버로 수집

데이터셋이 너무 크면 드라이버가 충돌할 수 있습니다. 작은 데이터 하위 집합에 대해 take 또는 takeSample과 같은 액션을 사용하는 것이 좋으며, 데이터셋 크기가 관리 가능한 경우를 제외하고 collect를 피하세요.

sample_data = data.limit(1000).collect()  # 관리 가능한 양만 수집

# 또는 데이터를 직접 저장소에 씁니다.

data.write.parquet("output_path")

실수 6: 최적화 기술을 생략

스파크에는 성능을 향상시키기 위한 최적화가 있지만, 이를 언제 사용해야 하는지 이해해야 합니다.

large_data.join(small_data, "id").show()  # 큰 테이블과 작은 테이블의 느린 조

작은 테이블에 대해 브로드캐스트 조인을 사용하고, 스파크의 Catalyst 옵티마이저에 의해 최적화된 DataFrame API를 활용하세요.

# 작은 테이블에 대해 브로드캐스트 조인을 사용

from pyspark.sql.functions import broadcast

large_data.join(broadcast(small_data), "id").show()  # 브로드캐스트가 조인을 최적화합니다.

실수 7: 비효율적인 집계

집계 작업을 실행할 때 성능에 미치는 영향을 이해하지 못함.

# 큰 데이터를 직접 그룹화하는 대신

data.groupBy("category").sum("amount").show()

# 가능한 경우 맵 사이드 집계를 사용

data = data.map(lambda x: (x['category'], x['amount'])) \\

.reduceByKey(lambda a, b: a + b)

groupByKey 대신 reduceByKey 사용: groupByKey는 동일한 키를 가진 모든 값을 단일 실행기로 보내 잠재적으로 메모리 문제를 일으킬 수 있습니다. 반면 reduceByKey는 각 파티션에서 로컬 축소를 수행한 후 데이터를 노드 간에 전송하여 일반적으로 더 효율적입니다.

참고자료

https://medium.com/@vinciabhinav7/apache-spark-common-mistakes-14407bebe259

Apache Spark — Common mistakes…

Spark is a framework for processing big data. In Part 1 we focused on the Basics of spark and Why its so fast

medium.com

네거티브 샘플링

Dan-k — Fri, 20 Dec 2024 14:56:42 +0900

1. 네거티브 샘플링의 개념

대규모 데이터 학습에서 연산량을 줄이고 효율성을 높이는 기법.
모든 데이터를 사용하지 않고 일부만 선택해 학습.
주요 활용 분야: 자연어 처리(NLP), 딥러닝.
대표 사례: Word2Vec.

https://wikidocs.net/69141

2. 네거티브 샘플링의 작동 원리

Skip-gram 모델
1. 중심 단어(center word)에서 주변 단어(context word)를 예측.
2. 예: "고양이가 책상 위에 있다" 문장에서 중심 단어 "고양이"를 기준으로 "책상", "위에" 등을 예측.

https://wikidocs.net/69141

문제점
1. 어휘 크기가 10만 개라면, 중심 단어마다 10만 개의 확률 분포를 계산해야 함.
2. 엄청난 연산량을 요구.
해결: 네거티브 샘플링 도입
- 긍정 샘플(positive sample): 중심 단어와 실제 관련 있는 단어.
- 네거티브 샘플(negative sample): 나머지 단어 중 일부를 무작위 선택.
- 모델은 긍정 샘플과 네거티브 샘플을 구분하도록 학습.

3. 네거티브 샘플링의 수학적 접근

손실 함수(Loss Function):
- $v_c$: 중심 단어 벡터.
- $v_o$: 긍정 샘플 벡터.
- $v_i$: 네거티브 샘플 벡터.
- $P_n(w)$: 네거티브 샘플링 분포.
- $k$: 네거티브 샘플 개수.
역할:
- 중심 단어와 긍정 샘플 간 관계 강화.
- 중심 단어와 네거티브 샘플 간 관계 약화.

4. 네거티브 샘플링의 장점

연산 효율성 증가: 일부 데이터만 사용해 연산량 감소.
대규모 데이터셋 처리 가능: 방대한 데이터도 빠르게 학습.
간단한 구현: 기존 모델에 쉽게 통합 가능.

5. 네거티브 샘플링의 한계

샘플 품질 의존성: 무작위 선택된 네거티브 샘플이 부적절할 가능성.
균형 문제: 샘플 수가 너무 적거나 많으면 학습 성능 저하.
도메인 특화 데이터: 적절한 샘플 분포 정의 어려움.

6. 네거티브 샘플링 활용 사례

Word2Vec
- 구글 개발.
- Skip-gram + 네거티브 샘플링 결합.
- 효율적 단어 임베딩 생성.
GloVe
- Stanford NLP 연구.
- 대규모 텍스트 데이터 처리.
추천 시스템
- 사용자-아이템 상호작용 데이터 학습.
- 실제 상호작용하지 않은 아이템을 네거티브 샘플로 사용.

7. 결론

핵심 장점
- 연산량 감소.
- 빠른 학습.
- 대규모 데이터 효율적 처리.
중요성
- 자연어 처리, 추천 시스템 등에서 널리 활용.
- 적절한 네거티브 샘플 선택과 균형 유지 필요.

참고 자료

범주형 변수 상관관계?! -> cross tab with chi square

Dan-k — Wed, 13 Nov 2024 10:40:25 +0900

교차표와 카이제곱 검정: 독립성 테스트

1. 교차표란?

교차표(Cross Tabulation): 두 변수 간의 관계를 2차원 행렬로 나타내는 방법
- 두 변수의 각 범주에 대한 빈도를 표시
- Excel의 피벗 테이블과 유사하게 데이터를 시각화
- 주요 장점: 데이터 분포를 쉽게 이해 가능

2. 카이제곱 검정이란?

카이제곱 검정(χ² Test): 두 변수 간의 관계가 통계적으로 유의미한지 평가하는 방법
- 목적: 관찰된 데이터가 우연인지, 아니면 두 변수 간에 실제로 의미 있는 관계가 있는지를 판단

3. 예시

질문: "마지막 접촉 채널과 디바이스 유형 간에 관계가 있는가?"
- 방법: 교차표를 통해 두 변수의 분포 확인 후 카이제곱 검정 수행

4. 카이제곱 검정 수행 절차

관찰 데이터(Observed Data) 준비: 두 변수의 실제 데이터를 교차표 형태로 정리
기대값(Expected Values) 계산: 각 셀의 기대값 계산
- 각 행, 열의 총합을 이용하여 기대값 도출
카이제곱 통계량 계산: 각 셀에 대해 관찰값과 기대값 차이를 제곱 후 기대값으로 나누어 카이제곱 통계량 계산
카이제곱 값 합산: 모든 셀의 카이제곱 값을 합산하여 최종 카이제곱 값 도출
유의미성 평가: 최종 카이제곱 값을 임계값과 비교하여 귀무가설 기각 여부 결정

5. 예시 계산: 데스크탑 사용자와 유기적 검색

기대값 계산 방식
- 행 총합(데스크탑) / 전체 총합
- 열 총합(유기적 검색) / 전체 총합
- 위 두 값 곱한 후 전체 총합으로 곱산
수식 예시

sessionsexpected = (r1 / T) * (c1 / T) * T = (100 / 300) * (80 / 300) * 300 = 26.67 ≈ 27

모든 셀에 대해 기대값을 계산한 후 관찰값과 비교하여 카이제곱 통계량 계산

6. Python을 사용한 카이제곱 검정 예시

import pandas as pd
from scipy.stats import chi2_contingency

# 데이터 프레임 생성
data = {'device_category': ['Phone', 'Tablet', 'Desktop'],
        'Organic_Search': [35, 20, 25],
        'Paid_Search': [15, 30, 20],
        'Email': [10, 25, 35],
        'Display': [40, 25, 20]}
df = pd.DataFrame(data)

# 교차표 생성
cross_tab = df.set_index('device_category')

# 카이제곱 검정 수행
chi2, p, dof, expected = chi2_contingency(cross_tab)

print(f"Chi2: {chi2}")
print(f"P-value: {p}")
print(f"Degrees of Freedom: {dof}")
print("Expected Frequencies:")
print(expected)

출력 결과: 카이제곱 값, p-값, 자유도 및 기대값이 포함됨

7. 결과 해석

유의미성 평가: 자유도와 유의수준을 사용해 임계값 결정
- 예: 자유도 6, 유의수준 0.1일 때, 임계 카이제곱 값 = 10.64
- 결론: 관찰된 카이제곱 값이 임계값 초과 시 귀무가설 기각 → 두 변수 간 유의미한 관계 있음

8. 결론

카이제곱 검정: 두 변수 간 관계 평가에 유용한 도구
- 데이터 분석 시 단순 우연이 아닌 유의미한 관계 여부를 판단하는 데 활용
- 교차표와 카이제곱 검정을 통해 데이터에서 유용한 통찰 도출 가능

https://www.dartistics.com/cross-tab-w-chi-square.html

Cross Tab with Chi-Square

Let’s get a little wordy and a little Greek. The full title of this topic (phonetically) is “Cross Tabulations with a Chi-Square Test of Independence.” To really write it in a way that will make a statistician happy, it’s, “Cross Tabulations with

www.dartistics.com

[SQL : impala] Join 최적화 (Broadcast Vs Partitioned)

Dan-k — Thu, 7 Nov 2024 22:23:28 +0900

1. JOIN 방식의 개요

임팔라의 JOIN 방식: 두 가지 방식 제공
- BROADCAST JOIN: 작은 테이블을 모든 노드에 전송하여 메모리상에서 JOIN 수행
- PARTITIONED JOIN: 큰 테이블 간 결합 시 파티셔닝을 통한 분산 처리 수행

BROADCAST JOIN

정의: JOIN 대상 중 작은 테이블을 쿼리 참여 노드에 모두 전송하여 JOIN 연산 수행
적합한 사용 시기: 작은 테이블과 큰 테이블의 JOIN 연산 시 유리
특징: 작은 테이블이 전체 노드에 복제되므로 빠른 처리 가능. 큰 테이블 broadcast 시 메모리 과부하 발생 가능

PARTITIONED JOIN

정의: JOIN 연산에 참여하는 두 테이블을 키(key) 기준으로 파티셔닝 후 각 파티션에서 JOIN 수행
적합한 사용 시기: 큰 테이블 간 결합에 주로 사용
특징: 데이터를 분산 처리하여 메모리 사용 최적화 및 대규모 데이터 JOIN에서 성능 향상 가능

2. BROADCAST JOIN과 PARTITIONED JOIN 비교

비교 항목 BROADCAST JOIN PARTITIONED JOIN

사용 상황	작은 테이블과 큰 테이블의 JOIN	큰 테이블 간의 JOIN
처리 방식	작은 테이블을 모든 노드로 전송	테이블을 키 기준으로 파티셔닝
장점	간단한 구성으로 빠른 JOIN 가능	메모리 사용 최적화, 대규모 데이터 효율적 처리
단점	큰 테이블 broadcast 시 메모리 과다 사용 위험	초기 파티셔닝 작업으로 오버헤드 발생
메모리 사용	테이블 크기에 따라 메모리 사용 급증	파티셔닝을 통한 메모리 사용 절감

3. JOIN 힌트를 통한 최적화 방법

JOIN 힌트: 특정 JOIN 방식을 강제하여 쿼리 최적화 가능
힌트 종류
- BROADCAST: BROADCAST JOIN 강제
- SHUFFLE: PARTITIONED JOIN 강제

JOIN 힌트 사용 예시

BROADCAST 힌트: 작은 테이블을 모든 노드로 전송
- small_table을 broadcast하여 JOIN 수행
- large_table이 큰 경우 적합

SELECT *
FROM large_table AS t1
	JOIN /* +BROADCAST */ small_table AS t2 ON t1.id = t2.id;

SELECT /*+ BROADCAST(t1) */ * FROM large_table AS t1 JOIN small_table AS t2 ON t1.id = t2.id;
SHUFFLE 힌트: 테이블을 파티셔닝하여 PARTITIONED JOIN 수행
- large_table1과 large_table2 간 PARTITIONED JOIN 수행 강제
- 대규모 데이터 집합 간 JOIN 시 유리

SELECT *
FROM large_table1 AS t1
	JOIN /* +SHUFFLE */ large_table2 AS t2 ON t1.id = t2.id;

4. 결론: 데이터 특성에 맞는 JOIN 방식 선택하기

BROADCAST JOIN: 작은 테이블 JOIN에서 성능이 뛰어남, 큰 테이블 broadcast 시 메모리 부담
PARTITIONED JOIN: 큰 테이블 간 JOIN에 적합, 파티셔닝을 통한 메모리 최적화 가능
JOIN 힌트 활용: 데이터 특성 및 쿼리 목적에 맞는 JOIN 방식 강제 가능

SELECT 
	straight_join t1.name, t2.id, t3.price
FROM t1 join /* +shuffle */ t2 join /* +broadcast */ t3 on t1.id = t2.id and t2.id = t3.id;

source: https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/optimize-shuffles.html

https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/optimize-shuffles.html

Optimize shuffles -

Optimize shuffles Certain operations, such as join() and groupByKey(), require Spark to perform a shuffle. The shuffle is Spark's mechanism for redistributing data so that it's grouped differently across RDD partitions. Shuffling can help remediate perform

docs.aws.amazon.com

https://impala.apache.org/docs/build/html/topics/impala_hints.html

Optimizer Hints

The Impala SQL supports query hints, for fine-tuning the inner workings of queries. Specify hints as a temporary workaround for expensive queries, where missing statistics or other factors cause inefficient performance. Hints are most often used for the re

impala.apache.org

[앱개발] React Native

Dan-k — Sun, 27 Oct 2024 22:59:48 +0900

React Native로 모바일 앱 개발하기

1. 크로스 플랫폼 개발의 필요성

모바일 애플리케이션 시장의 확대로 다양한 플랫폼(iOS, Android)에서 실행 가능한 앱이 요구됨.
기존에는 각각의 플랫폼에 맞는 네이티브 코드를 작성해야 했으나, 크로스 플랫폼 개발 프레임워크가 이를 해결.
React Native는 Facebook이 개발한 오픈소스 크로스 플랫폼 프레임워크로, 단일 코드베이스로 iOS와 Android 앱을 만들 수 있음.

source: https://pronteff.com/integrating-native-modules-into-react-native-android/

2. React Native란?

React Native는 JavaScript와 React를 사용해 모바일 애플리케이션을 개발할 수 있는 프레임워크.
네이티브 앱 성능을 제공하면서도, 단일 코드베이스로 여러 플랫폼을 지원.
React의 컴포넌트 기반 아키텍처를 적용해 UI와 로직을 재사용 가능하게 함.

3. React Native의 주요 특징

크로스 플랫폼 개발: iOS와 Android용 애플리케이션을 하나의 코드로 개발.
핫 리로딩(Hot Reloading): 코드 변경 시 애플리케이션이 자동으로 업데이트되어 빠른 개발 사이클 가능.
Native Module 지원: 카메라, GPS, 스토리지 등 네이티브 모듈에 접근 가능.
다양한 라이브러리 및 커뮤니티 지원: 다양한 플러그인과 커뮤니티 패키지 사용 가능.

4. React Native 기본 설치 및 설정

환경 설정: Node.js, npm/yarn 설치 후 react-native-cli 설치.
bash 코드 복사 npm install -g react-native-cli
새 프로젝트 생성:
bash 코드 복사 npx react-native init MyNewApp
앱 실행: 에뮬레이터 혹은 실제 기기에서 앱 실행
bash 코드 복사 npx react-native run-android # Android npx react-native run-ios # iOS

5. React Native의 UI 컴포넌트

뷰(View): 레이아웃을 구성하는 컨테이너 역할.
텍스트(Text): 텍스트를 표시하는 컴포넌트.
버튼(Button): 기본 버튼 컴포넌트, 다양한 동작을 트리거하는 데 사용.
스크롤뷰(ScrollView): 스크롤 가능한 화면을 구현.
이미지(Image): 네트워크, 로컬 등 다양한 이미지 표시 지원.

UI 구성 예시

javascript
코드 복사
import React from 'react';
import { View, Text, Button } from 'react-native';

const App = () => {
  return (
    <View style={{ padding: 20 }}>
      <Text>Welcome to React Native!</Text>
      <Button title="Click me!" onPress={() => alert('Button clicked!')} />
    </View>
  );
};

export default App;

6. 네이티브 모듈과의 통합

카메라, 위치 정보, 파일 시스템 등 네이티브 기능을 활용할 수 있는 모듈을 지원.
React Native 라이브러리 혹은 네이티브 코드(Java, Swift)로 구현 가능.

7. React Native의 장점과 단점

장점
- 생산성: 크로스 플랫폼 코드 재사용을 통해 개발 속도 향상.
- 다양한 라이브러리: 오픈소스 커뮤니티 지원이 많아 라이브러리 활용이 용이.
- 네이티브 성능: 네이티브 모듈을 통해 iOS와 Android 모두 최적화된 성능 제공.
단점
- 복잡한 UI 구현의 한계: 네이티브 앱에 비해 고도로 복잡한 UI 구현에 제약.
- 네이티브 코드 필요성: 네이티브 모듈이 필요한 경우 Java나 Swift 등의 네이티브 언어 지식이 필요.
- 성능: 크로스 플랫폼이기에 네이티브 앱 대비 성능이 약간 낮을 수 있음.

8. React Native로 빠르게 모바일 앱 개발하기

React Native는 크로스 플랫폼 개발의 효율성과 생산성을 크게 높일 수 있음.
네이티브 성능과 UI 컴포넌트 사용이 가능하므로, 중소형 프로젝트는 물론 대형 프로젝트에도 사용하기 적합.
iOS와 Android 앱을 한 번에 개발하고자 하는 팀에 강력한 선택지가 될 수 있음.