IT 위키 - 사용자 기여 [ko]

레이 오브젝트 스토어

2025-05-13T21:13:44Z

빅데이터분석기사: 새 문서: 레이 오브젝트 스토어는 Ray에서 분산된 객체 데이터를 저장하고 공유하기 위한 메모리 기반 저장소이다. ==개요== Ray의 오브젝트 스토어는 Plasma를 기반으로 구현되었으며, 각 노드에 로컬 저장소가 존재하지만, 클러스터 전체에서 논리적으로 연결되어 하나의 분산 캐시처럼 동작한다. Remote 함수나 액터 메서드의 결과값은 이 오브젝트 스토어에 저장되며, ObjectRef를...

레이 오브젝트 스토어는 Ray에서 분산된 객체 데이터를 저장하고 공유하기 위한 메모리 기반 저장소이다.
==개요==
Ray의 오브젝트 스토어는 Plasma를 기반으로 구현되었으며, 각 노드에 로컬 저장소가 존재하지만, 클러스터 전체에서 논리적으로 연결되어 하나의 분산 캐시처럼 동작한다. Remote 함수나 액터 메서드의 결과값은 이 오브젝트 스토어에 저장되며, ObjectRef를 통해 참조된다.
==특징==
*모든 객체는 불변(immutable)이며, 직렬화되어 저장된다.
*각 노드는 자체 오브젝트 스토어를 가지며, 객체는 요청이 있을 때 다른 노드로 전송된다.
*객체는 수동 복제가 아닌 요청 기반 복사를 통해 전파된다.
*Ray는 참조 횟수를 추적하여 더 이상 필요하지 않은 객체를 자동으로 제거한다.
*객체 크기가 작을 경우 인라인으로 직접 반환되고, 클 경우 오브젝트 스토어에 저장된다.
==주요 기능==
*Remote 함수와 액터의 반환값 또는 인자로 사용되는 객체 저장
*`ray.put()`을 통해 직접 객체를 저장하고 ObjectRef를 생성할 수 있음
*다른 노드가 객체를 필요로 하면 원 소유자에게 요청하여 복사
*메모리 부족 시 가비지 컬렉션 또는 디스크로 스필링 수행
==예시==
<syntaxhighlight lang="python">
import ray
ray.init()

data = [1, 2, 3]
obj_ref = ray.put(data)
result = ray.get(obj_ref)
</syntaxhighlight>
==장애 허용==
*소유자 노드가 소실되면 해당 객체도 손실된다.
*모든 복사본이 존재하는 노드가 사라진 경우에도 객체가 소실되며, ObjectLostError가 발생한다.
*객체 재구성이 가능할 경우, lineage 정보를 기반으로 자동 재생성할 수 있다.
==같이 보기==
*[[레이 (분산 컴퓨팅)]]
*[[레이 ObjectRef]]
*[[레이 리모트 함수]]
*[[레이 Raylet]]
*[[글로벌 컨트롤 스토어]]
==참고 문헌==
*Moritz, Philipp et al. ''Ray: A Distributed Framework for Emerging AI Applications''. OSDI 2018.
*Ray Documentation. ''Object Store''. https://docs.ray.io
==각주==
[[분류:분산 컴퓨팅]]

레이 GCS

2025-05-13T21:06:26Z

빅데이터분석기사: 새 문서: 레이 GCS(Global Control Store)는 Ray 클러스터의 전역 상태 정보를 저장하고 관리하는 중앙 구성 요소이다. ==개요== GCS는 Ray 클러스터 내 모든 작업, 객체, 함수, 이벤트 등의 메타데이터를 저장하는 전역 키-값 저장소로, Ray의 제어 흐름을 중앙 집중화하여 구성 요소 간의 복잡한 상태 동기화를 단순화한다. Ray 2.0 이후부터는 GCS(Global Control Service)라는 명칭으로 불린다. ==...

레이 GCS(Global Control Store)는 Ray 클러스터의 전역 상태 정보를 저장하고 관리하는 중앙 구성 요소이다.
==개요==
GCS는 Ray 클러스터 내 모든 작업, 객체, 함수, 이벤트 등의 메타데이터를 저장하는 전역 키-값 저장소로, Ray의 제어 흐름을 중앙 집중화하여 구성 요소 간의 복잡한 상태 동기화를 단순화한다. Ray 2.0 이후부터는 GCS(Global Control Service)라는 명칭으로 불린다.
==주요 기능==
*작업(Task), 객체(Object), 함수(Function), 이벤트(Event) 테이블 저장
*클러스터 상태를 위한 Pub/Sub 기능 제공<ref>Pub/Sub은 Publish-Subscribe의 줄임말로, 생산자(Publisher)가 전송한 메시지를 수신자(Subscriber)가 비동기적으로 받아보는 방식이다. Ray에서는 작업 상태 변경, 객체 생성 등과 같은 이벤트를 GCS가 브로드캐스트하면, 이를 구독한 구성 요소들이 수신하여 처리한다.</ref>
*Web UI, 디버깅, 프로파일링 툴 등에 정보 제공
*구성 요소의 상태 복구 시 참조되는 계보(lineage) 정보 유지
*액터 메타데이터(IP, 포트 등) 등록 및 조회
==특징==
*GCS는 기본적으로 헤드 노드에서 실행된다.
*모든 구성 요소는 GCS를 통해 간접적으로 상태를 공유하기 때문에 자체적으로는 무상태(stateless)로 유지된다.
*이러한 구조는 장애 발생 시 재시작을 용이하게 하며, 구성 요소 간 독립 확장을 가능하게 한다.
==장애 허용==
*기본적으로 GCS는 단일 장애 지점(SPOF)이다.
*Ray 2.0 이상에서는 외부 고가용성 Redis를 활용하여 Kubernetes 환경에서 GCS 장애 허용 구성이 가능하다.
==역할 요약==
*클러스터의 중앙 메타데이터 저장소
*작업 스케줄링 및 객체 배포 시 상태 기준점 제공
*구성 요소 재시작 및 복구를 위한 기준 상태 보존
==같이 보기==
*[[레이 (분산 컴퓨팅)]]
*[[레이 Raylet]]
*[[레이 리모트 함수]]
*[[레이 ObjectRef]]
*[[레이 리모트 액터]]
==참고 문헌==
*Moritz, Philipp et al. ''Ray: A Distributed Framework for Emerging AI Applications''. OSDI 2018.
*Ray Team. ''Global Control Store (GCS)''. https://docs.ray.io
==각주==

레이 리모트 액터

2025-05-13T21:01:50Z

빅데이터분석기사: 새 문서: 레이 리모트 액터는 상태를 유지하는 객체를 분산 환경에서 실행할 수 있도록 지원하는 Ray의 실행 단위이다. ==개요== Remote Actor는 @ray.remote 데코레이터가 붙은 클래스이며, 각 인스턴스는 클러스터 내의 단일 워커 프로세스로 생성된다. 일반 remote 함수와 달리 액터는 내부 상태를 유지할 수 있으며, 메서드 호출은 비동기적으로 실행되고 ObjectRef를 반환한다. 액터는...

레이 리모트 액터는 상태를 유지하는 객체를 분산 환경에서 실행할 수 있도록 지원하는 Ray의 실행 단위이다.
==개요==
Remote Actor는 @ray.remote 데코레이터가 붙은 클래스이며, 각 인스턴스는 클러스터 내의 단일 워커 프로세스로 생성된다. 일반 remote 함수와 달리 액터는 내부 상태를 유지할 수 있으며, 메서드 호출은 비동기적으로 실행되고 ObjectRef를 반환한다. 액터는 순차적으로 메시지를 처리하여 상태 충돌 없이 일관성을 유지한다.
==특징==
*상태(state)를 유지할 수 있음
*하나의 액터는 하나의 워커 프로세스에서 실행됨
*메서드 호출은 remote 함수처럼 ObjectRef를 반환
*모든 메서드 호출은 직렬화되어 순차적으로 실행됨
*액터 풀을 통해 병렬 처리 가능
==예시==
<syntaxhighlight lang="python">
import ray
ray.init()

@ray.remote
class Counter:
def __init__(self):
self.n = 0

def increment(self):
self.n += 1

def read(self):
return self.n

counter = Counter.remote()
counter.increment.remote()
print(ray.get(counter.read.remote())) # 출력: 1
</syntaxhighlight>
==동작 방식==
*액터는 생성 시 GCS에 등록되며, 메타데이터(IP, 포트 등)가 저장된다.
*이후 메서드 호출은 gRPC를 통해 액터 프로세스에 직접 전달된다.
*액터 생성 요청은 먼저 Actor Creation Task로 등록되고, 완료 전이라도 핸들은 반환된다.
*자원 할당은 액터 생성 시 수행되며, 메서드 호출 시에는 별도 자원 할당이 필요 없다.
==장애 허용==
*액터는 상태를 가지므로 복구가 복잡하다.
*메시지 처리 중 실패: 자동 재시도되지 않음
*메시지 처리 전/후 실패: 최대 max_restarts 또는 max_retries`횟수까지 자동 복구 가능
*초기화 실패는 첫 번째 메시지 실패로 간주됨
==같이 보기==
*[[레이 (분산 컴퓨팅)]]
*[[레이 리모트 함수]]
*[[레이 ObjectRef]]
*[[레이 Raylet]]
*[[글로벌 컨트롤 스토어]]
==참고 문헌==
*Moritz, Philipp et al. ''Ray: A Distributed Framework for Emerging AI Applications''. OSDI 2018.
*Ray Documentation. ''Actors''. https://docs.ray.io
==각주==
[[분류:분산 컴퓨팅]]

레이 리모트 함수

2025-05-13T20:57:17Z

빅데이터분석기사: 새 문서: 레이 리모트 함수는 Ray에서 분산 비동기 처리를 위해 사용하는 기본 실행 단위이다. ==개요== 리모트 함수(Remote Function)는 `@ray.remote` 데코레이터를 통해 정의되며, 클러스터의 여러 노드에서 병렬로 실행될 수 있는 비동기 태스크를 생성한다. 함수 호출 시 결과값이 즉시 반환되는 대신, 미래 결과를 참조하는 ObjectRef 객체가 반환되며, `ray.get()`을 통해 최종 값을 가져...

레이 리모트 함수는 Ray에서 분산 비동기 처리를 위해 사용하는 기본 실행 단위이다.
==개요==
리모트 함수(Remote Function)는 `@ray.remote` 데코레이터를 통해 정의되며, 클러스터의 여러 노드에서 병렬로 실행될 수 있는 비동기 태스크를 생성한다. 함수 호출 시 결과값이 즉시 반환되는 대신, 미래 결과를 참조하는 ObjectRef 객체가 반환되며, `ray.get()`을 통해 최종 값을 가져올 수 있다.
==특징==
*함수 호출 시 즉시 ObjectRef 반환
*비동기 실행을 통해 병렬 처리 가능
*클러스터 자원 상황에 따라 실행 노드가 자동으로 결정됨
*작은 결과는 직접 반환되며, 큰 결과는 객체 저장소에 저장됨
*`@ray.remote(max_retries=n)`으로 자동 재시도 횟수 지정 가능
==실행 과정==
1. 사용자가 remote 함수를 호출하면 ObjectRef가 반환된다. 2. 호출자는 해당 작업의 소유자가 되며, 의존성 객체가 준비될 때까지 대기한다. 3. 준비 완료 시 Ray 스케줄러가 적절한 노드에 자원을 할당한다. 4. 작업 명세는 gRPC를 통해 워커에게 전달된다. 5. 작업이 실행되고 결과는 object store에 저장되며 ObjectRef와 연결된다.
==예시==
<syntaxhighlight lang="python">
import ray
ray.init()

@ray.remote
def square(x):
return x * x

futures = [square.remote(i) for i in range(4)]
print(ray.get(futures)) # [0, 1, 4, 9]
</syntaxhighlight>
==장애 허용==
*응용 수준 오류: 예외가 결과로 반환되며 자동 재시도되지 않음
*시스템 수준 오류: 워커 프로세스 장애 등의 경우 최대 설정 횟수만큼 자동 재시도됨
==같이 보기==
*[[레이 (분산 컴퓨팅)]]
*[[레이 리모트 액터]]
*[[레이 ObjectRef]]
*[[레이 Raylet]]
*[[글로벌 컨트롤 스토어]]
==참고 문헌==
*Moritz, Philipp et al. ''Ray: A Distributed Framework for Emerging AI Applications''. OSDI 2018.
*Ray Documentation. ''Remote Functions''. https://docs.ray.io
==각주==
[[분류:분산 컴퓨팅]]

레이 ObjectRef

2025-05-13T20:54:37Z

빅데이터분석기사: 새 문서: 레이 ObjectRef는 Ray에서 원격 함수 또는 액터 호출의 결과를 참조하기 위한 객체 참조자이다. ==개요== ObjectRef는 Ray에서 분산 비동기 실행을 지원하기 위해 사용하는 참조 메커니즘이다. remote 함수나 액터 메서드를 호출하면 즉시 결과값이 반환되는 것이 아니라, 해당 결과를 가리키는 ObjectRef 객체가 반환된다. ObjectRef는 작업이 완료되었을 때 결과를 가져올 수 있도...

레이 ObjectRef는 Ray에서 원격 함수 또는 액터 호출의 결과를 참조하기 위한 객체 참조자이다.
==개요==
ObjectRef는 Ray에서 분산 비동기 실행을 지원하기 위해 사용하는 참조 메커니즘이다. remote 함수나 액터 메서드를 호출하면 즉시 결과값이 반환되는 것이 아니라, 해당 결과를 가리키는 ObjectRef 객체가 반환된다. ObjectRef는 작업이 완료되었을 때 결과를 가져올 수 있도록 연결된 참조 역할을 한다.
==주요 특징==
*비동기 실행 결과를 지연 참조(lazy reference)할 수 있다.
*Ray 클러스터 내 객체의 위치를 추적할 수 있는 메타데이터를 포함한다.
*`ray.get(ObjectRef)`를 호출하면 해당 결과를 가져온다.
*하나의 객체는 여러 ObjectRef를 통해 참조될 수 있다.
==생성 방식==
*Remote 함수 또는 액터 메서드 호출 시 자동 생성된다.
*ray.put()을 통해 명시적으로 객체를 저장하고 ObjectRef를 생성할 수도 있다.
<syntaxhighlight lang="python">
import ray
ray.init()

@ray.remote
def f(x):
return x + 1

obj_ref = f.remote(10)
result = ray.get(obj_ref) # result = 11
</syntaxhighlight>
==내부 동작==
*ObjectRef는 고유 식별자(ID)를 통해 Ray의 객체 저장소에 저장된 데이터를 가리킨다.
*소유자(owner)는 ObjectRef의 수명 주기를 관리하며, 참조 카운트를 통해 자동 메모리 해제(GC)가 이루어진다.
*참조된 객체가 다른 노드에 있을 경우, Ray는 소유자로부터 복사 정보를 받아와 로컬 노드에 복제한다.
==장애 허용==
*소유자 노드가 사라질 경우, ObjectRef도 함께 소실될 수 있다.
*객체가 저장된 모든 노드가 사라지면, ObjectLostError가 발생한다.
*GCS에 저장된 작업 계보(lineage)를 통해 객체 재생성(reconstruction)이 가능한 경우도 있다.
==같이 보기==
*[[레이 (분산 컴퓨팅)]]
*[[레이 리모트 함수]]
*[[레이 리모트 액터]]
*[[레이 Raylet]]
==참고 문헌==
*Moritz, Philipp et al. ''Ray: A Distributed Framework for Emerging AI Applications''. OSDI 2018.
*Ray Team. ''Object References in Ray''. https://docs.ray.io
==각주==
[[분류:분산 컴퓨팅]]

레이 Raylet

2025-05-13T20:50:16Z

빅데이터분석기사: 새 문서: 레이 Raylet은 Ray 분산 컴퓨팅 프레임워크의 핵심 구성 요소로, 각 워커 노드에서 태스크 실행과 객체 저장을 관리하는 경량 프로세스이다. ==개요== Raylet은 Ray 클러스터 내의 각 노드에서 실행되며, 태스크 스케줄링과 객체 저장소 관리를 담당한다. Ray 0.x 버전에서는 글로벌 스케줄러와 로컬 스케줄러가 분리되어 있었으나, Raylet 구조가 도입되면서 이 기능들이 단일...

레이 Raylet은 Ray 분산 컴퓨팅 프레임워크의 핵심 구성 요소로, 각 워커 노드에서 태스크 실행과 객체 저장을 관리하는 경량 프로세스이다.
==개요==
Raylet은 Ray 클러스터 내의 각 노드에서 실행되며, 태스크 스케줄링과 객체 저장소 관리를 담당한다. Ray 0.x 버전에서는 글로벌 스케줄러와 로컬 스케줄러가 분리되어 있었으나, Raylet 구조가 도입되면서 이 기능들이 단일 프로세스에 통합되었다. Raylet은 분산 스케줄러와 오브젝트 스토어를 하나의 프로세스로 구성하여 통신 효율성과 시스템 단순성을 높였다.
==구성 요소==
*'''로컬 스케줄러(Local Scheduler)''': 로컬 노드에서 실행 가능한 작업을 수락하고 실행한다. 자원이 부족하거나 작업이 다른 노드에서 더 적절하게 실행될 경우, 다른 노드로 위임한다.
*'''객체 저장소(Object Store)''': Plasma 기반으로 구현되며, 분산된 캐시 역할을 수행한다. 작업의 입력 및 출력 객체를 저장하고 공유한다.
==주요 기능==
*태스크의 의존성 분석 및 준비 완료 대기
*클러스터 내에서 적절한 노드로 작업 분산
*작업 결과를 공유 메모리 기반 객체 저장소에 저장
*자원 요구사항을 기반으로 스케줄링 의사결정 수행
*노드 간 통신 및 글로벌 컨트롤 스토어(GCS)와 메타데이터 연동
==작동 방식==

# 클라이언트로부터 태스크 요청이 들어오면 Raylet은 먼저 필요한 객체가 로컬에 있는지 확인한다.
# 객체가 준비되면 태스크를 실행하거나, 다른 노드로 위임한다.
# 결과는 로컬 객체 저장소에 기록되며, 필요 시 다른 노드로 전파된다.
# 실행 결과는 ObjectRef를 통해 클라이언트에게 전달된다.

==같이 보기==
*[[레이 (분산 컴퓨팅)]]
==참고 문헌==
*Moritz, Philipp et al. ''Ray: A Distributed Framework for Emerging AI Applications''. OSDI 2018.
*The Ray Team. ''Ray Architecture Overview''. https://docs.ray.io
==각주==
[[분류:분산 컴퓨팅]]

레이 (분산 컴퓨팅)

2025-05-13T20:42:50Z

빅데이터분석기사:

레이(Ray)는 머신 러닝 및 분산 애플리케이션을 위한 범용 분산 컴퓨팅 프레임워크이다.
==개요==
레이는 파이썬 중심의 API를 기반으로 하며, 간결한 코드로 대규모 분산 처리를 가능하게 해주는 범용 분산 실행 엔진이다. Ray는 동시성(concurrency), 병렬성(parallelism), 분산성(distribution)을 모두 지원하며, 특히 강화 학습, 하이퍼파라미터 튜닝, 대규모 데이터 처리 등의 머신 러닝 워크로드에 적합하다. 서버리스(serverless) 방식의 분산 실행 모델을 채택하여 사용자가 인프라를 직접 관리하지 않고도 작업을 분산 실행할 수 있도록 설계되었다.
==주요 특징==
*파이썬 기반의 간단한 API 제공
*함수 기반의 원격 실행(Remote Function) 및 액터(Actor) 모델 지원
*스케일 아웃 가능한 병렬 처리 프레임워크
*다양한 머신 러닝 툴킷과 통합(TensorFlow, PyTorch 등)
*자동 리소스 관리 및 스케줄링 기능 포함
*강화 학습, 서빙, 튜닝을 위한 하위 프레임워크 포함(Ray RLlib, Ray Serve, Ray Tune)
==주요 구성 요소==
*'''Ray Core''': 분산 태스크 및 액터 실행을 위한 기본 모듈
*'''Ray Tune''': 대규모 하이퍼파라미터 튜닝을 위한 라이브러리
*'''Ray RLlib''': 강화 학습 알고리즘의 분산 학습을 위한 프레임워크
*'''Ray Serve''': 머신 러닝 모델 서빙을 위한 확장 가능한 서버리스 솔루션
*'''Ray Data''': 분산 데이터 로딩 및 전처리를 위한 컴포넌트
==아키텍처==
[[파일:레이 아키텍처.png|섬네일|레이 아키텍처]]
Ray 클러스터는 '''헤드 노드(head node)'''와 하나 이상의 '''워커 노드(worker node)'''로 구성된다.
===헤드 노드===
헤드 노드는 클러스터 전체를 관리하며, 워커 노드와 동일한 구성 요소에 더해 아래의 두 가지 주요 컴포넌트를 추가로 포함한다.
*'''Global control store (GCS)''': 클러스터 전역 정보를 저장하는 구성 요소로, 객체 테이블, 태스크 테이블, 함수 테이블, 이벤트 로그 등을 포함한다. 이 정보는 웹 UI, 디버깅, 프로파일링 등에 활용된다.
*'''Autoscaler''': 워크로드에 따라 워커 노드를 자동으로 생성하거나 제거하여 자원 낭비를 줄이고 성능을 최적화한다.
헤드 노드는 기본적으로 '''단일 장애 지점(single point of failure)'''으로, 장애 발생 시 클러스터 전체가 소실되며 재생성이 필요하다. 이로 인해 기존 워커 노드는 '''고아 노드(orphaned node)'''가 되어 수동으로 제거해야 할 수 있다.<ref>Ray 2.0부터는 외부 고가용성 Redis 데이터베이스와 함께 Kubernetes 위에 배포할 경우 GCS 장애 허용 기능을 지원한다.</ref>
=== 워커 노드===
각 워커 노드는 '''Raylet'''이라는 핵심 컴포넌트를 포함하며, 이는 다음 두 구성 요소로 구성된다.
*'''Object store''': 분산 캐시와 유사하게 작동하며, 클러스터 내 모든 object store는 연결되어 하나의 통합 캐시를 구성한다.
*'''Scheduler''': 각 노드는 로컬 스케줄러를 통해 작업을 수행하며, 다른 노드와 통신하여 전역 분산 스케줄러로 기능한다.
==리모트 함수==
Remote function은 Ray에서 분산 병렬 처리를 위해 사용하는 기본 단위로, 다음과 같은 현대 애플리케이션 요구사항을 충족한다.
*동일한 코드를 여러 코어나 머신에서 실행 가능
*오류 발생 시 자동 재시도 등 내결함성 제공
*큰 파라미터도 효율적으로 처리 가능
*프로세스 간 정보 전달이 용이함
Ray는 함수 호출을 올바른 프로세스로 자동 매핑하여 실행하며, 함수 호출 결과는 곧바로 '''ObjectRef''' 형태로 반환된다. ObjectRef란 실제 결과가 저장될 미래 객체에 대한 일종의 포인터이다.
===실행 방식===
*사용자가 remote 함수를 호출하면, Ray는 작업을 비동기적으로 분산 실행한다.
*ObjectRef를 통해 값을 나중에 받아올 수 있으며, ray.get()을 사용하여 결과를 확인한다.
*remote 함수는 반드시 다른 머신에서 실행되는 것은 아니며, 같은 노드 내 다른 프로세스일 수도 있다.
===예시 코드===
<syntaxhighlight lang="python">
import ray
ray.init()

@ray.remote
def f(x):
return x * x

futures = [f.remote(i) for i in range(4)]
print(ray.get(futures)) # [0, 1, 4, 9]
</syntaxhighlight>

=== 동작 흐름 ===

* 함수 호출자는 해당 작업의 '''소유자(owner)'''가 되며, ObjectRef를 관리한다.
*작업 제출 시, owner는 인자로 전달된 모든 ObjectRef가 준비될 때까지 대기한다.
* 준비 완료되면, 분산 스케줄러에 자원을 요청하고 작업 실행을 위한 워커 주소를 받는다.
*[[GRPC (RPC 프레임워크)|gRPC]]를 통해 워커에게 작업 명세를 전달하며, 워커는 작업을 실행 후 결과를 저장한다.
**작은 결과는 인라인으로 전달되고, 큰 객체는 local object store에 저장된다.
===오류 처리===
*'''응용 수준 오류''': 예외가 발생하면 해당 예외 객체가 결과로 반환되며, 재시도는 이루어지지 않는다.
*'''시스템 수준 오류''': 예를 들어 워커 프로세스가 죽는 경우, 지정된 횟수만큼 자동 재시도된다.<ref>max_retries 옵션을 통해 최대 재시도 횟수를 설정할 수 있다.</ref>
==리모트 액터==
Remote function은 상태를 갖지 않는(stateless) 함수의 병렬 실행에 적합하다. 그러나 상태를 유지해야 하는 경우에는 Remote Actor를 사용한다.
===개요===
*상태를 유지하는 객체를 분산 환경에서 사용할 수 있게 해주는 기능이다.
* '''@ray.remote''' 데코레이터를 클래스에 붙여 사용한다.
*액터는 하나의 프로세스로 실행되며, 그 안의 상태는 외부에서 접근할 수 없다.
*상태 변경은 해당 액터에 메시지를 보내는 방식으로만 가능하다.
===예시 코드===
<syntaxhighlight lang="python">
import ray
ray.init()

@ray.remote
class Counter(object):
def __init__(self):
self.n = 0

def increment(self):
self.n += 1

def read(self):
return self.n

counters = [Counter.remote() for i in range(4)]
[c.increment.remote() for c in counters]
futures = [c.read.remote() for c in counters]
print(ray.get(futures)) # [1, 1, 1, 1]
</syntaxhighlight>

=== 액터 모델 ===

* 액터는 고유 주소(handle)를 가진 프로세스이다.

*내부 상태는 외부에서 직접 접근할 수 없으며, 메시지를 통해 간접적으로만 조작할 수 있다.
*각 액터는 메시지를 하나씩 순차적으로 처리하므로 상태 충돌이 발생하지 않는다.
*상태를 나누거나 복제할 수 있다면, 여러 액터 풀을 구성하여 처리량을 향상시킬 수 있다.
===동작 방식===
*Ray는 액터를 새로운 워커로 생성하고, 그 이후 모든 메서드는 해당 워커에서 실행된다.
*액터 생성은 GCS에 등록되어 메타데이터(IP, 포트 등)를 공유한다.
*각 클라이언트는 GCS를 재조회하지 않고, 캐시된 메타데이터로 직접 gRPC를 통해 액터에게 메시지를 전송한다.
*메서드 호출은 remote function과 동일하게 ObjectRef를 반환한다.
=== 장애 처리===
*액터는 상태를 가지므로 복구가 더 복잡하다.
*메시지 처리 중 실패 시 자동 재시도되지 않는다.
*메시지 사이에서 실패한 경우, Ray는 다음 호출 시 최대 설정된 횟수만큼 재시도한다.
*초기화 실패도 첫 메시지 실패와 동일하게 처리된다.
==장애 허용==
Ray는 애플리케이션 계층과 시스템 계층으로 구성되어 있으며, 두 계층 모두 장애 복구 기능을 갖추고 있다.
===시스템 계층 구성 요소===
*'''Global Control Store (GCS)''': Ray의 전체 상태를 저장하는 중앙 구성 요소
*'''분산 스케줄러''': 작업 분배 및 자원 할당을 담당
*'''분산 오브젝트 저장소''': 객체 데이터를 클러스터 내에서 분산 관리<ref>GCS를 제외한 구성 요소는 수평 확장 및 장애 허용이 가능하다.</ref>
===Global Control Store (GCS)===
* GCS는 시스템 상태를 중앙에서 유지하여 나머지 구성 요소들이 무상태(stateless)로 설계되도록 한다.
*구성 요소가 장애로 인해 재시작되면, GCS에서 상태를 읽어와 복구한다.
*이를 통해 객체 저장소와 스케줄러를 독립적으로 확장할 수 있다.
*기본적으로 GCS는 헤드 노드에 존재하며, 단일 장애 지점(SPOF)이 된다.
===Remote Function의 장애 허용===
*Remote function은 상태가 없기 때문에 복구가 간단하다.
* 시스템 오류로 실패한 작업은 지정된 최대 횟수만큼 자동 재시도된다.
*응용 오류(Exception 발생)는 자동 재시도되지 않고, 예외 객체로 반환된다.
*최대 재시도 횟수는 `@ray.remote(max_retries=n)`으로 설정 가능하다.
=== Remote Actor의 장애 허용===
*액터는 상태를 갖기 때문에 복구가 더 복잡하다.
* 초기화, 메시지 처리 중, 요청 간 등 어떤 단계에서도 실패할 수 있다.
====메시지 처리 중 실패====
*자동 재시도되지 않음
*다음 메시지를 처리할 때까지 대기하며, 최대 max_restarts 횟수까지 액터를 재시작한다.
==== 요청 간 실패====
*다음 메시지 호출 시 자동으로 액터를 복구한다.
* 상태 복구 로직이 적절히 구현되어 있다면 실패는 느린 처리 외에는 큰 영향을 주지 않는다.
*상태 복구 로직이 없을 경우, 액터는 초기 상태로 재시작된다.
===기타 사항===
*대부분의 자원은 애플리케이션 종료 시 자동 정리된다.
*'''Detached''' 리소스(예: detached actor, placement group)는 클러스터가 유지되는 한 계속 유지된다.<ref>이로 인해 클러스터의 자동 스케일 다운이 방지될 수 있다.</ref>
==기타 설계 사항==
===직렬화(Serialization)===
*Ray는 Plasma in-memory object store를 사용하여 객체를 노드 간 및 프로세스 간 효율적으로 전달한다.
*NumPy 배열은 zero-copy 방식으로 같은 노드 내 여러 워커가 공유할 수 있다.
*Plasma에 저장된 객체는 불변이며(shared memory)에 저장된다.
*객체는 요청이 있을 때에만 다른 노드로 전송되며, 사전 복제되지 않는다.
===리소스 관리===
*기본적으로 함수와 액터는 동일한 자원(CPU 1개)을 요구한다.
*GPU, 메모리 등 필요한 자원을 명시할 수 있으며, 스케줄러는 이를 고려하여 실행 노드를 할당한다.
* 자원이 부족한 경우, 오토스케일러가 필요한 사양을 가진 노드를 추가한다.
===자동 스케일링(Autoscaler)===
*오토스케일러는 다음을 담당한다:
**워커 노드 생성
**워커 노드 제거
**워커 재시작
===배치 전략(Placement Groups)===
*Placement group은 작업과 자원을 함께 배치하기 위한 논리적 단위이다.
*사전 자원 할당(preallocation)을 통해 작업 지연을 줄일 수 있다.
*'''Pack''': 하나의 노드에 최대한 묶어 배치하여 locality 향상
*'''Spread''': 여러 노드에 분산 배치하여 신뢰성 및 부하 분산 확보<ref>Placement group은 CPU, GPU 등 자원 묶음 단위로 구성된다.</ref>
===네임스페이스(Namespaces)===
*Ray는 작업과 액터를 논리적으로 그룹화하기 위해 네임스페이스를 사용한다.
*기본적으로 익명 네임스페이스에서 실행된다.
*여러 프로그램에서 동일한 액터를 공유하려면 동일한 네임스페이스를 명시해야 한다.
<syntaxhighlight lang="python">
ray.init(namespace="bdad")
</syntaxhighlight>
===의존성 관리===
*Conda 또는 virtualenv 기반으로 동적 환경 구성이 가능하다.
* 런타임 환경을 함수 단위로 설정할 수도 있다.
<syntaxhighlight lang="python">
ray.init(runtime_env={"pip": "requirements.txt"})

@ray.remote(runtime_env={"conda": ["some_package"]})
def some_function(x): ...
</syntaxhighlight>
===Job API===
*클러스터에 작업을 제출하고 추적할 수 있는 API를 제공한다.
*작업 ID로 상태를 조회하거나 실행 로그를 확인할 수 있다.
==예시 코드==
<syntaxhighlight lang="python">
import ray

ray.init()

@ray.remote
def f(x):
return x * x

futures = [f.remote(i) for i in range(4)]
print(ray.get(futures))
</syntaxhighlight>위 예시는 4개의 태스크를 병렬로 실행한 뒤 결과를 수집하는 단순한 병렬 처리 예제이다.
==사용 사례==
*대규모 강화 학습 환경 구축 및 실험(RLlib)
*수천 개의 하이퍼파라미터 조합을 통한 모델 최적화(Ray Tune)
*실시간 모델 예측 요청 처리(Ray Serve)
*분산 데이터 로딩 및 전처리(Ray Data)
*일반적인 병렬 처리 및 배치 작업 수행
==Ray와 다른 프레임워크 비교==
*Dask와 유사한 파이썬 중심의 API를 제공하지만, Ray는 액터 모델 기반의 상태 유지 작업에 더 적합하다.
*Apache Spark보다 경량이며, 머신 러닝에 특화된 구성 요소를 포함하고 있다.
*Celery와 달리 분산 스케줄링 및 리소스 관리를 자동으로 처리한다.
==같이 보기==
*[[분산 처리]]
*[[강화 학습]]
*[[하이퍼파라미터 최적화]]
*[[서버리스 컴퓨팅]]
*[[파이썬]]
==참고 문헌==
*Moritz, Philipp et al. ''Ray: A Distributed Framework for Emerging AI Applications''. Proceedings of the 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2018.
*Anyscale, Inc. ''The Ray Documentation''. https://docs.ray.io/
==각주==
[[분류:분산 컴퓨팅]]

파일:레이 아키텍처.png

2025-05-13T20:41:56Z

빅데이터분석기사:

출처: https://www.linkedin.com/posts/vishnu-pradeep65_ray-architecture-basics-101-a-ray-cluster-activity-7101243889704964096-G-Yn/

GRPC (RPC 프레임워크)

2025-05-13T20:39:13Z

빅데이터분석기사: 새 문서: gRPC는 고성능 오픈소스 원격 프로시저 호출(Remote Procedure Call, RPC) 프레임워크이다. ==개요== gRPC는 Google에서 개발한 내부 RPC 시스템에서 유래하였으며, 현재는 다양한 언어와 플랫폼에서 사용할 수 있는 일반 목적의 RPC 프레임워크로 발전하였다. HTTP/2를 기반으로 하며, 바이너리 직렬화 형식인 프로토콜 버퍼(Protocol Buffers)를 사용하여 높은 성능과 효율적인 통신을 지...

gRPC는 고성능 오픈소스 원격 프로시저 호출(Remote Procedure Call, RPC) 프레임워크이다.
==개요==
gRPC는 Google에서 개발한 내부 RPC 시스템에서 유래하였으며, 현재는 다양한 언어와 플랫폼에서 사용할 수 있는 일반 목적의 RPC 프레임워크로 발전하였다. HTTP/2를 기반으로 하며, 바이너리 직렬화 형식인 프로토콜 버퍼(Protocol Buffers)를 사용하여 높은 성능과 효율적인 통신을 지원한다.
==특징==
*HTTP/2 기반 통신 프로토콜 사용
*Protocol Buffers를 통한 고속 직렬화 및 역직렬화
*클라이언트-서버 간 명확한 인터페이스 정의 (.proto 파일 사용)
*다양한 언어 지원 (Python, C++, Java, Go, Rust 등)
*동기 및 비동기 방식의 호출 모두 지원
*스트리밍 지원 (클라이언트 스트리밍, 서버 스트리밍, 양방향 스트리밍)
==작동 방식==
1. 개발자는 .proto 파일을 사용해 서비스와 메시지를 정의한다. 2. gRPC 툴체인은 이 파일을 바탕으로 서버와 클라이언트 코드를 생성한다. 3. 클라이언트는 로컬 함수 호출처럼 원격 서버의 함수를 호출하며, 내부적으로 gRPC는 이 호출을 HTTP/2 요청으로 변환하여 서버에 전달한다. 4. 서버는 정의된 로직을 수행하고, 결과를 다시 클라이언트로 전송한다.
==사용 사례==
*마이크로서비스 간 고성능 통신
*분산 머신 러닝 및 데이터 처리 시스템 (예: Ray)
*모바일 및 IoT 기기와 서버 간 통신
*실시간 스트리밍 기반 애플리케이션
==gRPC와 기존 RPC의 차이점==
*기존의 REST API는 텍스트 기반(JSON) 통신을 주로 사용하며, HTTP/1.1 기반이다.
*반면, gRPC는 바이너리 기반의 Protocol Buffers를 사용하고 HTTP/2 위에서 동작하기 때문에 다중 요청 처리 및 스트리밍에서 우수한 성능을 보인다.
==같이 보기==
*[[RPC]]
*[[프로토콜 버퍼]]
*[[HTTP/2]]
*[[분산 시스템]]
*[[Ray]]
==참고 문헌==
*Vaidyanathan, Varun et al. ''gRPC: A High Performance, Open Source Universal RPC Framework''. Google Inc., 2016.
*The gRPC Authors. ''gRPC Official Documentation''. https://grpc.io
==각주==
[[분류:네트워크]]
[[분류:오픈 소스]]

레이 (분산 컴퓨팅)

2025-05-13T20:38:24Z

빅데이터분석기사:

레이(Ray)는 머신 러닝 및 분산 애플리케이션을 위한 범용 분산 컴퓨팅 프레임워크이다.
==개요==
레이는 파이썬 중심의 API를 기반으로 하며, 간결한 코드로 대규모 분산 처리를 가능하게 해주는 범용 분산 실행 엔진이다. Ray는 동시성(concurrency), 병렬성(parallelism), 분산성(distribution)을 모두 지원하며, 특히 강화 학습, 하이퍼파라미터 튜닝, 대규모 데이터 처리 등의 머신 러닝 워크로드에 적합하다. 서버리스(serverless) 방식의 분산 실행 모델을 채택하여 사용자가 인프라를 직접 관리하지 않고도 작업을 분산 실행할 수 있도록 설계되었다.
==주요 특징==
*파이썬 기반의 간단한 API 제공
*함수 기반의 원격 실행(Remote Function) 및 액터(Actor) 모델 지원
*스케일 아웃 가능한 병렬 처리 프레임워크
*다양한 머신 러닝 툴킷과 통합(TensorFlow, PyTorch 등)
*자동 리소스 관리 및 스케줄링 기능 포함
*강화 학습, 서빙, 튜닝을 위한 하위 프레임워크 포함(Ray RLlib, Ray Serve, Ray Tune)
==주요 구성 요소==
*'''Ray Core''': 분산 태스크 및 액터 실행을 위한 기본 모듈
*'''Ray Tune''': 대규모 하이퍼파라미터 튜닝을 위한 라이브러리
*'''Ray RLlib''': 강화 학습 알고리즘의 분산 학습을 위한 프레임워크
*'''Ray Serve''': 머신 러닝 모델 서빙을 위한 확장 가능한 서버리스 솔루션
*'''Ray Data''': 분산 데이터 로딩 및 전처리를 위한 컴포넌트
==아키텍처==
Ray 클러스터는 '''헤드 노드(head node)'''와 하나 이상의 '''워커 노드(worker node)'''로 구성된다.
===헤드 노드===
헤드 노드는 클러스터 전체를 관리하며, 워커 노드와 동일한 구성 요소에 더해 아래의 두 가지 주요 컴포넌트를 추가로 포함한다.
*'''Global control store (GCS)''': 클러스터 전역 정보를 저장하는 구성 요소로, 객체 테이블, 태스크 테이블, 함수 테이블, 이벤트 로그 등을 포함한다. 이 정보는 웹 UI, 디버깅, 프로파일링 등에 활용된다.
*'''Autoscaler''': 워크로드에 따라 워커 노드를 자동으로 생성하거나 제거하여 자원 낭비를 줄이고 성능을 최적화한다.
헤드 노드는 기본적으로 '''단일 장애 지점(single point of failure)'''으로, 장애 발생 시 클러스터 전체가 소실되며 재생성이 필요하다. 이로 인해 기존 워커 노드는 '''고아 노드(orphaned node)'''가 되어 수동으로 제거해야 할 수 있다.<ref>Ray 2.0부터는 외부 고가용성 Redis 데이터베이스와 함께 Kubernetes 위에 배포할 경우 GCS 장애 허용 기능을 지원한다.</ref>
=== 워커 노드===
각 워커 노드는 '''Raylet'''이라는 핵심 컴포넌트를 포함하며, 이는 다음 두 구성 요소로 구성된다.
*'''Object store''': 분산 캐시와 유사하게 작동하며, 클러스터 내 모든 object store는 연결되어 하나의 통합 캐시를 구성한다.
*'''Scheduler''': 각 노드는 로컬 스케줄러를 통해 작업을 수행하며, 다른 노드와 통신하여 전역 분산 스케줄러로 기능한다.
==리모트 함수==
Remote function은 Ray에서 분산 병렬 처리를 위해 사용하는 기본 단위로, 다음과 같은 현대 애플리케이션 요구사항을 충족한다.
*동일한 코드를 여러 코어나 머신에서 실행 가능
*오류 발생 시 자동 재시도 등 내결함성 제공
*큰 파라미터도 효율적으로 처리 가능
*프로세스 간 정보 전달이 용이함
Ray는 함수 호출을 올바른 프로세스로 자동 매핑하여 실행하며, 함수 호출 결과는 곧바로 '''ObjectRef''' 형태로 반환된다. ObjectRef란 실제 결과가 저장될 미래 객체에 대한 일종의 포인터이다.
===실행 방식===
*사용자가 remote 함수를 호출하면, Ray는 작업을 비동기적으로 분산 실행한다.
*ObjectRef를 통해 값을 나중에 받아올 수 있으며, ray.get()을 사용하여 결과를 확인한다.
*remote 함수는 반드시 다른 머신에서 실행되는 것은 아니며, 같은 노드 내 다른 프로세스일 수도 있다.
===예시 코드===
<syntaxhighlight lang="python">
import ray
ray.init()

@ray.remote
def f(x):
return x * x

futures = [f.remote(i) for i in range(4)]
print(ray.get(futures)) # [0, 1, 4, 9]
</syntaxhighlight>

=== 동작 흐름 ===

* 함수 호출자는 해당 작업의 '''소유자(owner)'''가 되며, ObjectRef를 관리한다.
*작업 제출 시, owner는 인자로 전달된 모든 ObjectRef가 준비될 때까지 대기한다.
* 준비 완료되면, 분산 스케줄러에 자원을 요청하고 작업 실행을 위한 워커 주소를 받는다.
*[[GRPC (RPC 프레임워크)|gRPC]]를 통해 워커에게 작업 명세를 전달하며, 워커는 작업을 실행 후 결과를 저장한다.
**작은 결과는 인라인으로 전달되고, 큰 객체는 local object store에 저장된다.
===오류 처리===
*'''응용 수준 오류''': 예외가 발생하면 해당 예외 객체가 결과로 반환되며, 재시도는 이루어지지 않는다.
*'''시스템 수준 오류''': 예를 들어 워커 프로세스가 죽는 경우, 지정된 횟수만큼 자동 재시도된다.<ref>max_retries 옵션을 통해 최대 재시도 횟수를 설정할 수 있다.</ref>
==리모트 액터==
Remote function은 상태를 갖지 않는(stateless) 함수의 병렬 실행에 적합하다. 그러나 상태를 유지해야 하는 경우에는 Remote Actor를 사용한다.
===개요===
*상태를 유지하는 객체를 분산 환경에서 사용할 수 있게 해주는 기능이다.
* '''@ray.remote''' 데코레이터를 클래스에 붙여 사용한다.
*액터는 하나의 프로세스로 실행되며, 그 안의 상태는 외부에서 접근할 수 없다.
*상태 변경은 해당 액터에 메시지를 보내는 방식으로만 가능하다.
===예시 코드===
<syntaxhighlight lang="python">
import ray
ray.init()

@ray.remote
class Counter(object):
def __init__(self):
self.n = 0

def increment(self):
self.n += 1

def read(self):
return self.n

counters = [Counter.remote() for i in range(4)]
[c.increment.remote() for c in counters]
futures = [c.read.remote() for c in counters]
print(ray.get(futures)) # [1, 1, 1, 1]
</syntaxhighlight>

=== 액터 모델 ===

* 액터는 고유 주소(handle)를 가진 프로세스이다.

*내부 상태는 외부에서 직접 접근할 수 없으며, 메시지를 통해 간접적으로만 조작할 수 있다.
*각 액터는 메시지를 하나씩 순차적으로 처리하므로 상태 충돌이 발생하지 않는다.
*상태를 나누거나 복제할 수 있다면, 여러 액터 풀을 구성하여 처리량을 향상시킬 수 있다.
===동작 방식===
*Ray는 액터를 새로운 워커로 생성하고, 그 이후 모든 메서드는 해당 워커에서 실행된다.
*액터 생성은 GCS에 등록되어 메타데이터(IP, 포트 등)를 공유한다.
*각 클라이언트는 GCS를 재조회하지 않고, 캐시된 메타데이터로 직접 gRPC를 통해 액터에게 메시지를 전송한다.
*메서드 호출은 remote function과 동일하게 ObjectRef를 반환한다.
=== 장애 처리===
*액터는 상태를 가지므로 복구가 더 복잡하다.
*메시지 처리 중 실패 시 자동 재시도되지 않는다.
*메시지 사이에서 실패한 경우, Ray는 다음 호출 시 최대 설정된 횟수만큼 재시도한다.
*초기화 실패도 첫 메시지 실패와 동일하게 처리된다.
==장애 허용==
Ray는 애플리케이션 계층과 시스템 계층으로 구성되어 있으며, 두 계층 모두 장애 복구 기능을 갖추고 있다.
===시스템 계층 구성 요소===
*'''Global Control Store (GCS)''': Ray의 전체 상태를 저장하는 중앙 구성 요소
*'''분산 스케줄러''': 작업 분배 및 자원 할당을 담당
*'''분산 오브젝트 저장소''': 객체 데이터를 클러스터 내에서 분산 관리<ref>GCS를 제외한 구성 요소는 수평 확장 및 장애 허용이 가능하다.</ref>
===Global Control Store (GCS)===
* GCS는 시스템 상태를 중앙에서 유지하여 나머지 구성 요소들이 무상태(stateless)로 설계되도록 한다.
*구성 요소가 장애로 인해 재시작되면, GCS에서 상태를 읽어와 복구한다.
*이를 통해 객체 저장소와 스케줄러를 독립적으로 확장할 수 있다.
*기본적으로 GCS는 헤드 노드에 존재하며, 단일 장애 지점(SPOF)이 된다.
===Remote Function의 장애 허용===
*Remote function은 상태가 없기 때문에 복구가 간단하다.
* 시스템 오류로 실패한 작업은 지정된 최대 횟수만큼 자동 재시도된다.
*응용 오류(Exception 발생)는 자동 재시도되지 않고, 예외 객체로 반환된다.
*최대 재시도 횟수는 `@ray.remote(max_retries=n)`으로 설정 가능하다.
=== Remote Actor의 장애 허용===
*액터는 상태를 갖기 때문에 복구가 더 복잡하다.
* 초기화, 메시지 처리 중, 메시지 사이 등 어떤 단계에서도 실패할 수 있다.
====메시지 처리 중 실패====
*자동 재시도되지 않음
*다음 메시지를 처리할 때까지 대기하며, 최대 max_restarts 횟수까지 액터를 재시작한다.
==== 메시지 사이 실패====
*다음 메시지 호출 시 자동으로 액터를 복구한다.
* 상태 복구 로직이 적절히 구현되어 있다면 실패는 느린 처리 외에는 큰 영향을 주지 않는다.
*상태 복구 로직이 없을 경우, 액터는 초기 상태로 재시작된다.
===기타 사항===
*대부분의 자원은 애플리케이션 종료 시 자동 정리된다.
*'''Detached''' 리소스(예: detached actor, placement group)는 클러스터가 유지되는 한 계속 유지된다.<ref>이로 인해 클러스터의 자동 스케일 다운이 방지될 수 있다.</ref>
==기타 설계 사항==
===직렬화(Serialization)===
*Ray는 Plasma in-memory object store를 사용하여 객체를 노드 간 및 프로세스 간 효율적으로 전달한다.
*NumPy 배열은 zero-copy 방식으로 같은 노드 내 여러 워커가 공유할 수 있다.
*Plasma에 저장된 객체는 불변이며(shared memory)에 저장된다.
*객체는 요청이 있을 때에만 다른 노드로 전송되며, 사전 복제되지 않는다.
===리소스 관리===
*기본적으로 함수와 액터는 동일한 자원(CPU 1개)을 요구한다.
*GPU, 메모리 등 필요한 자원을 명시할 수 있으며, 스케줄러는 이를 고려하여 실행 노드를 할당한다.
* 자원이 부족한 경우, 오토스케일러가 필요한 사양을 가진 노드를 추가한다.
===자동 스케일링(Autoscaler)===
*오토스케일러는 다음을 담당한다:
**워커 노드 생성
**워커 노드 제거
**워커 재시작
===배치 전략(Placement Groups)===
*Placement group은 작업과 자원을 함께 배치하기 위한 논리적 단위이다.
*사전 자원 할당(preallocation)을 통해 작업 지연을 줄일 수 있다.
*'''Pack''': 하나의 노드에 최대한 묶어 배치하여 locality 향상
*'''Spread''': 여러 노드에 분산 배치하여 신뢰성 및 부하 분산 확보<ref>Placement group은 CPU, GPU 등 자원 묶음 단위로 구성된다.</ref>
===네임스페이스(Namespaces)===
*Ray는 작업과 액터를 논리적으로 그룹화하기 위해 네임스페이스를 사용한다.
*기본적으로 익명 네임스페이스에서 실행된다.
*여러 프로그램에서 동일한 액터를 공유하려면 동일한 네임스페이스를 명시해야 한다.
<syntaxhighlight lang="python">
ray.init(namespace="bdad")
</syntaxhighlight>
===의존성 관리===
*Conda 또는 virtualenv 기반으로 동적 환경 구성이 가능하다.
* 런타임 환경을 함수 단위로 설정할 수도 있다.
<syntaxhighlight lang="python">
ray.init(runtime_env={"pip": "requirements.txt"})

@ray.remote(runtime_env={"conda": ["some_package"]})
def some_function(x): ...
</syntaxhighlight>
===Job API===
*클러스터에 작업을 제출하고 추적할 수 있는 API를 제공한다.
*작업 ID로 상태를 조회하거나 실행 로그를 확인할 수 있다.
==예시 코드==
<syntaxhighlight lang="python">
import ray

ray.init()

@ray.remote
def f(x):
return x * x

futures = [f.remote(i) for i in range(4)]
print(ray.get(futures))
</syntaxhighlight>위 예시는 4개의 태스크를 병렬로 실행한 뒤 결과를 수집하는 단순한 병렬 처리 예제이다.
==사용 사례==
*대규모 강화 학습 환경 구축 및 실험(RLlib)
*수천 개의 하이퍼파라미터 조합을 통한 모델 최적화(Ray Tune)
*실시간 모델 예측 요청 처리(Ray Serve)
*분산 데이터 로딩 및 전처리(Ray Data)
*일반적인 병렬 처리 및 배치 작업 수행
==Ray와 다른 프레임워크 비교==
*Dask와 유사한 파이썬 중심의 API를 제공하지만, Ray는 액터 모델 기반의 상태 유지 작업에 더 적합하다.
*Apache Spark보다 경량이며, 머신 러닝에 특화된 구성 요소를 포함하고 있다.
*Celery와 달리 분산 스케줄링 및 리소스 관리를 자동으로 처리한다.
==같이 보기==
*[[분산 처리]]
*[[강화 학습]]
*[[하이퍼파라미터 최적화]]
*[[서버리스 컴퓨팅]]
*[[파이썬]]
==참고 문헌==
*Moritz, Philipp et al. ''Ray: A Distributed Framework for Emerging AI Applications''. Proceedings of the 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2018.
*Anyscale, Inc. ''The Ray Documentation''. https://docs.ray.io/
==각주==
[[분류:분산 컴퓨팅]]

레이 (분산 컴퓨팅)

2025-05-13T20:15:05Z

빅데이터분석기사:

레이(Ray)는 머신 러닝 및 분산 애플리케이션을 위한 범용 분산 컴퓨팅 프레임워크이다.
==개요==
레이는 파이썬 중심의 API를 기반으로 하며, 간결한 코드로 대규모 분산 처리를 가능하게 해주는 범용 분산 실행 엔진이다. Ray는 동시성(concurrency), 병렬성(parallelism), 분산성(distribution)을 모두 지원하며, 특히 강화 학습, 하이퍼파라미터 튜닝, 대규모 데이터 처리 등의 머신 러닝 워크로드에 적합하다. 서버리스(serverless) 방식의 분산 실행 모델을 채택하여 사용자가 인프라를 직접 관리하지 않고도 작업을 분산 실행할 수 있도록 설계되었다.
==주요 특징==
*파이썬 기반의 간단한 API 제공
*함수 기반의 원격 실행(Remote Function) 및 액터(Actor) 모델 지원
*스케일 아웃 가능한 병렬 처리 프레임워크
*다양한 머신 러닝 툴킷과 통합(TensorFlow, PyTorch 등)
*자동 리소스 관리 및 스케줄링 기능 포함
*강화 학습, 서빙, 튜닝을 위한 하위 프레임워크 포함(Ray RLlib, Ray Serve, Ray Tune)
==주요 구성 요소==
*'''Ray Core''': 분산 태스크 및 액터 실행을 위한 기본 모듈
*'''Ray Tune''': 대규모 하이퍼파라미터 튜닝을 위한 라이브러리
*'''Ray RLlib''': 강화 학습 알고리즘의 분산 학습을 위한 프레임워크
*'''Ray Serve''': 머신 러닝 모델 서빙을 위한 확장 가능한 서버리스 솔루션
*'''Ray Data''': 분산 데이터 로딩 및 전처리를 위한 컴포넌트
==아키텍처==
Ray 클러스터는 '''헤드 노드(head node)'''와 하나 이상의 '''워커 노드(worker node)'''로 구성된다.
===헤드 노드===
헤드 노드는 클러스터 전체를 관리하며, 워커 노드와 동일한 구성 요소에 더해 아래의 두 가지 주요 컴포넌트를 추가로 포함한다.
*'''Global control store (GCS)''': 클러스터 전역 정보를 저장하는 구성 요소로, 객체 테이블, 태스크 테이블, 함수 테이블, 이벤트 로그 등을 포함한다. 이 정보는 웹 UI, 디버깅, 프로파일링 등에 활용된다.
*'''Autoscaler''': 워크로드에 따라 워커 노드를 자동으로 생성하거나 제거하여 자원 낭비를 줄이고 성능을 최적화한다.
헤드 노드는 기본적으로 '''단일 장애 지점(single point of failure)'''으로, 장애 발생 시 클러스터 전체가 소실되며 재생성이 필요하다. 이로 인해 기존 워커 노드는 '''고아 노드(orphaned node)'''가 되어 수동으로 제거해야 할 수 있다.<ref>Ray 2.0부터는 외부 고가용성 Redis 데이터베이스와 함께 Kubernetes 위에 배포할 경우 GCS 장애 허용 기능을 지원한다.</ref>
=== 워커 노드===
각 워커 노드는 '''Raylet'''이라는 핵심 컴포넌트를 포함하며, 이는 다음 두 구성 요소로 구성된다.
*'''Object store''': 분산 캐시와 유사하게 작동하며, 클러스터 내 모든 object store는 연결되어 하나의 통합 캐시를 구성한다.
*'''Scheduler''': 각 노드는 로컬 스케줄러를 통해 작업을 수행하며, 다른 노드와 통신하여 전역 분산 스케줄러로 기능한다.
==리모트 함수==
Remote function은 Ray에서 분산 병렬 처리를 위해 사용하는 기본 단위로, 다음과 같은 현대 애플리케이션 요구사항을 충족한다.
*동일한 코드를 여러 코어나 머신에서 실행 가능
*오류 발생 시 자동 재시도 등 내결함성 제공
*큰 파라미터도 효율적으로 처리 가능
*프로세스 간 정보 전달이 용이함
Ray는 함수 호출을 올바른 프로세스로 자동 매핑하여 실행하며, 함수 호출 결과는 곧바로 '''ObjectRef''' 형태로 반환된다. 이 ObjectRef는 실제 결과가 저장될 미래 객체에 대한 참조이다.
===실행 방식===
*사용자가 remote 함수를 호출하면, Ray는 작업을 비동기적으로 분산 실행한다.
*ObjectRef를 통해 값을 나중에 받아올 수 있으며, ray.get()을 사용하여 결과를 확인한다.
*remote 함수는 반드시 다른 머신에서 실행되는 것은 아니며, 같은 노드 내 다른 프로세스일 수도 있다.
===예시 코드===
<syntaxhighlight lang="python">
import ray
ray.init()

@ray.remote
def f(x):
return x * x

futures = [f.remote(i) for i in range(4)]
print(ray.get(futures)) # [0, 1, 4, 9]
</syntaxhighlight>

=== 동작 흐름 ===

* 함수 호출자는 해당 작업의 '''소유자(owner)'''가 되며, ObjectRef를 관리한다.
*작업 제출 시, owner는 인자로 전달된 모든 ObjectRef가 준비될 때까지 대기한다.
* 준비 완료되면, 분산 스케줄러에 자원을 요청하고 작업 실행을 위한 워커 주소를 받는다.
*gRPC를 통해 워커에게 작업 명세를 전달하며, 워커는 작업을 실행 후 결과를 저장한다.
**작은 결과는 인라인으로 전달되고, 큰 객체는 local object store에 저장된다.
===오류 처리===
*'''응용 수준 오류''': 예외가 발생하면 해당 예외 객체가 결과로 반환되며, 재시도는 이루어지지 않는다.
*'''시스템 수준 오류''': 예를 들어 워커 프로세스가 죽는 경우, 지정된 횟수만큼 자동 재시도된다.
*max_retries 옵션을 통해 최대 재시도 횟수를 설정할 수 있다.
==리모트 액터==
Remote function은 상태를 갖지 않는(stateless) 함수의 병렬 실행에 적합하다. 그러나 상태를 유지해야 하는 경우에는 Remote Actor를 사용한다.
===개요===
*상태를 유지하는 객체를 분산 환경에서 사용할 수 있게 해주는 기능이다.
* '''@ray.remote''' 데코레이터를 클래스에 붙여 사용한다.
*액터는 하나의 프로세스로 실행되며, 그 안의 상태는 외부에서 접근할 수 없다.
*상태 변경은 해당 액터에 메시지를 보내는 방식으로만 가능하다.
===예시 코드===
<syntaxhighlight lang="python">
import ray
ray.init()

@ray.remote
class Counter(object):
def __init__(self):
self.n = 0

def increment(self):
self.n += 1

def read(self):
return self.n

counters = [Counter.remote() for i in range(4)]
[c.increment.remote() for c in counters]
futures = [c.read.remote() for c in counters]
print(ray.get(futures)) # [1, 1, 1, 1]
</syntaxhighlight>

=== 액터 모델 ===

* 액터는 고유 주소(handle)를 가진 프로세스이다.

*내부 상태는 외부에서 직접 접근할 수 없으며, 메시지를 통해 간접적으로만 조작할 수 있다.
*각 액터는 메시지를 하나씩 순차적으로 처리하므로 상태 충돌이 발생하지 않는다.
*상태를 나누거나 복제할 수 있다면, 여러 액터 풀을 구성하여 처리량을 향상시킬 수 있다.
===동작 방식===
*Ray는 액터를 새로운 워커로 생성하고, 그 이후 모든 메서드는 해당 워커에서 실행된다.
*액터 생성은 GCS에 등록되어 메타데이터(IP, 포트 등)를 공유한다.
*각 클라이언트는 GCS를 재조회하지 않고, 캐시된 메타데이터로 직접 gRPC를 통해 액터에게 메시지를 전송한다.
*메서드 호출은 remote function과 동일하게 ObjectRef를 반환한다.
=== 장애 허용===
*액터는 상태를 가지므로 복구가 더 복잡하다.
*메시지 처리 중 실패 시 자동 재시도되지 않는다.
*메시지 사이에서 실패한 경우, Ray는 다음 호출 시 최대 설정된 횟수만큼 재시도한다.
*초기화 실패도 첫 메시지 실패와 동일하게 처리된다.
==장애 허용==
Ray는 애플리케이션 계층과 시스템 계층으로 구성되어 있으며, 두 계층 모두 장애 복구 기능을 갖추고 있다.
===시스템 계층 구성 요소===
*'''Global Control Store (GCS)''': Ray의 전체 상태를 저장하는 중앙 구성 요소
*'''분산 스케줄러''': 작업 분배 및 자원 할당을 담당
*'''분산 오브젝트 저장소''': 객체 데이터를 클러스터 내에서 분산 관리<ref>GCS를 제외한 구성 요소는 수평 확장 및 장애 허용이 가능하다.</ref>
===Global Control Store (GCS)===
* GCS는 시스템 상태를 중앙에서 유지하여 나머지 구성 요소들이 무상태(stateless)로 설계되도록 한다.
*구성 요소가 장애로 인해 재시작되면, GCS에서 상태를 읽어와 복구한다.
*이를 통해 객체 저장소와 스케줄러를 독립적으로 확장할 수 있다.
*기본적으로 GCS는 헤드 노드에 존재하며, 단일 장애 지점(SPOF)이 된다.
===Remote Function의 장애 허용===
*Remote function은 상태가 없기 때문에 복구가 간단하다.
* 시스템 오류로 실패한 작업은 지정된 최대 횟수만큼 자동 재시도된다.
*응용 오류(Exception 발생)는 자동 재시도되지 않고, 예외 객체로 반환된다.
*최대 재시도 횟수는 `@ray.remote(max_retries=n)`으로 설정 가능하다.
=== Remote Actor의 장애 허용===
*액터는 상태를 갖기 때문에 복구가 더 복잡하다.
* 초기화, 메시지 처리 중, 메시지 사이 등 어떤 단계에서도 실패할 수 있다.
====메시지 처리 중 실패====
*자동 재시도되지 않음
*다음 메시지를 처리할 때까지 대기하며, 최대 `max_restarts` 횟수까지 액터를 재시작한다.
==== 메시지 사이 실패====
*다음 메시지 호출 시 자동으로 액터를 복구한다.
* 상태 복구 로직이 적절히 구현되어 있다면 실패는 느린 처리 외에는 큰 영향을 주지 않는다.
*상태 복구 로직이 없을 경우, 액터는 초기 상태로 재시작된다.
===기타 사항===
*대부분의 자원은 애플리케이션 종료 시 자동 정리된다.
*'''Detached''' 리소스(예: detached actor, placement group)는 클러스터가 유지되는 한 계속 유지된다.<ref>이로 인해 클러스터의 자동 스케일 다운이 방지될 수 있다.</ref>
==기타 설계 사항==
===직렬화(Serialization)===
*Ray는 Plasma in-memory object store를 사용하여 객체를 노드 간 및 프로세스 간 효율적으로 전달한다.
*NumPy 배열은 zero-copy 방식으로 같은 노드 내 여러 워커가 공유할 수 있다.
*Plasma에 저장된 객체는 불변이며(shared memory)에 저장된다.
*객체는 요청이 있을 때에만 다른 노드로 전송되며, 사전 복제되지 않는다.
===리소스 관리===
*기본적으로 함수와 액터는 동일한 자원(CPU 1개)을 요구한다.
*GPU, 메모리 등 필요한 자원을 명시할 수 있으며, 스케줄러는 이를 고려하여 실행 노드를 할당한다.
* 자원이 부족한 경우, 오토스케일러가 필요한 사양을 가진 노드를 추가한다.
===자동 스케일링(Autoscaler)===
*오토스케일러는 다음을 담당한다:
**워커 노드 생성
**워커 노드 제거
**워커 재시작
===배치 전략(Placement Groups)===
*Placement group은 작업과 자원을 함께 배치하기 위한 논리적 단위이다.
*사전 자원 할당(preallocation)을 통해 작업 지연을 줄일 수 있다.
*'''Pack''': 하나의 노드에 최대한 묶어 배치하여 locality 향상
*'''Spread''': 여러 노드에 분산 배치하여 신뢰성 및 부하 분산 확보<ref>Placement group은 CPU, GPU 등 자원 묶음 단위로 구성된다.</ref>
===네임스페이스(Namespaces)===
*Ray는 작업과 액터를 논리적으로 그룹화하기 위해 네임스페이스를 사용한다.
*기본적으로 익명 네임스페이스에서 실행된다.
*여러 프로그램에서 동일한 액터를 공유하려면 동일한 네임스페이스를 명시해야 한다.
<syntaxhighlight lang="python">
ray.init(namespace="bdad")
</syntaxhighlight>
===의존성 관리===
*Conda 또는 virtualenv 기반으로 동적 환경 구성이 가능하다.
* 런타임 환경을 함수 단위로 설정할 수도 있다.
<syntaxhighlight lang="python">
ray.init(runtime_env={"pip": "requirements.txt"})

@ray.remote(runtime_env={"conda": ["some_package"]})
def some_function(x): ...
</syntaxhighlight>
===Job API===
*클러스터에 작업을 제출하고 추적할 수 있는 API를 제공한다.
*작업 ID로 상태를 조회하거나 실행 로그를 확인할 수 있다.
==예시 코드==
<syntaxhighlight lang="python">
import ray

ray.init()

@ray.remote
def f(x):
return x * x

futures = [f.remote(i) for i in range(4)]
print(ray.get(futures))
</syntaxhighlight>위 예시는 4개의 태스크를 병렬로 실행한 뒤 결과를 수집하는 단순한 병렬 처리 예제이다.
==사용 사례==
*대규모 강화 학습 환경 구축 및 실험(RLlib)
*수천 개의 하이퍼파라미터 조합을 통한 모델 최적화(Ray Tune)
*실시간 모델 예측 요청 처리(Ray Serve)
*분산 데이터 로딩 및 전처리(Ray Data)
*일반적인 병렬 처리 및 배치 작업 수행
==Ray와 다른 프레임워크 비교==
*Dask와 유사한 파이썬 중심의 API를 제공하지만, Ray는 액터 모델 기반의 상태 유지 작업에 더 적합하다.
*Apache Spark보다 경량이며, 머신 러닝에 특화된 구성 요소를 포함하고 있다.
*Celery와 달리 분산 스케줄링 및 리소스 관리를 자동으로 처리한다.
==같이 보기==
*[[분산 처리]]
*[[강화 학습]]
*[[하이퍼파라미터 최적화]]
*[[서버리스 컴퓨팅]]
*[[파이썬]]
==참고 문헌==
*Moritz, Philipp et al. ''Ray: A Distributed Framework for Emerging AI Applications''. Proceedings of the 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2018.
*Anyscale, Inc. ''The Ray Documentation''. https://docs.ray.io/
==각주==
[[분류:분산 컴퓨팅]]

레이 (분산 컴퓨팅)

2025-05-13T19:58:13Z

빅데이터분석기사:

레이 (분산 컴퓨팅)

2025-05-13T19:38:12Z

빅데이터분석기사:

레이 (분산 컴퓨팅)

2025-05-13T19:37:20Z

빅데이터분석기사:

레이 (분산 컴퓨팅)

2025-05-13T19:28:26Z

빅데이터분석기사: 새 문서: 레이(Ray)는 머신 러닝 및 분산 애플리케이션을 위한 범용 분산 컴퓨팅 프레임워크이다. ==개요== 레이는 파이썬 중심의 API를 기반으로 하며, 간결한 코드로 대규모 분산 처리를 가능하게 해주는 범용 분산 실행 엔진이다. Ray는 동시성(concurrency), 병렬성(parallelism), 분산성(distribution)을 모두 지원하며, 특히 강화 학습, 하이퍼파라미터 튜닝, 대규모 데이터 처리 등의 머...

아파치 스파크 그래프프레임

2025-05-13T04:52:29Z

빅데이터분석기사: 새 문서: 아파치 스파크 그레프프레임(GraphFrames for Apache Spark)은 스파크에서 그래프 이론 기반의 데이터 처리를 가능하게 해주는 라이브러리로, 그래프X(GraphX)의 기능을 데이터프레임 API로 확장한 것이다. ==개요== 그레프프레임은 정점(vertex)과 간선(edge)을 각각 데이터프레임으로 표현하며, 스파크 SQL과의 통합을 통해 강력한 질의 기능과 분산 처리 성능을 동시에 제공한다....

아파치 스파크 그레프프레임(GraphFrames for Apache Spark)은 스파크에서 그래프 이론 기반의 데이터 처리를 가능하게 해주는 라이브러리로, 그래프X(GraphX)의 기능을 데이터프레임 API로 확장한 것이다.
==개요==
그레프프레임은 정점(vertex)과 간선(edge)을 각각 데이터프레임으로 표현하며, 스파크 SQL과의 통합을 통해 강력한 질의 기능과 분산 처리 성능을 동시에 제공한다. 그래프 알고리즘의 선언적 실행이 가능하며, 복잡한 관계형 데이터 처리에 적합하다. 스파크의 구조화된 API와 결합되어 생산성과 확장성이 뛰어나다.
==주요 기능==
*정점 및 간선을 데이터프레임으로 정의
*스파크 SQL과 통합된 그래프 질의 지원
*BFS(Breadth-First Search), 페이지랭크(PageRank), 연결 요소(Connected Components) 등 주요 그래프 알고리즘 내장
*모티프 탐색(Motif Finding)을 통한 패턴 기반 질의 지원
*정점 및 간선 속성에 대한 조건 필터링 및 조인 가능
*Python, Scala API 지원
==구성 요소==
*'''Vertices''': 고유 ID를 가진 개체(예: 사용자, 상품 등)를 나타내는 데이터프레임
*'''Edges''': 정점 간의 관계(예: 친구, 구매 등)를 나타내는 데이터프레임
*'''GraphFrame''': 정점과 간선을 함께 포함하는 그래프 객체로, 다양한 알고리즘과 질의 기능을 수행
==모티프 탐색==
GraphFrames의 모티프 기능은 그래프 내에서 사용자가 지정한 구조적 패턴을 찾는 데 사용된다. 이 기능은 쿼리 언어를 통해 정점과 간선의 관계를 문자열로 표현하여 직관적으로 패턴을 탐색할 수 있게 해준다. 예를 들어, A → B → C 형태의 경로를 찾으려면 다음과 같이 표현할 수 있다.<syntaxhighlight lang="python">
motifs = g.find("(a)-[e1]->(b); (b)-[e2]->(c)")
motifs.show()
</syntaxhighlight>이 기능은 사기 탐지, 추천 시스템, 소셜 네트워크 분석 등에서 유용하게 활용된다.
==예시 코드==
다음은 Python에서 GraphFrame을 생성하고 간단한 알고리즘을 수행하는 예시이다.<syntaxhighlight lang="python">
from pyspark.sql import SparkSession
from graphframes import GraphFrame

spark = SparkSession.builder.appName("GraphFrameExample").getOrCreate()

vertices = spark.createDataFrame([
("1", "Alice"), ("2", "Bob"), ("3", "Charlie")
], ["id", "name"])

edges = spark.createDataFrame([
("1", "2", "friend"), ("2", "3", "follow")
], ["src", "dst", "relationship"])

g = GraphFrame(vertices, edges)
g.inDegrees.show()
</syntaxhighlight>
==한계점==
*GraphFrames는 GraphX보다 느릴 수 있으며, 대규모 처리 시 성능 이슈가 발생할 수 있다.
*아직 일부 그래프 알고리즘의 구현은 제한적이며, 확장에는 별도 구현이 필요하다.
*Java API는 지원되지 않는다.
==관련 프로젝트==
*GraphX: RDD 기반의 그래프 처리 엔진으로 GraphFrames의 기반이 되는 프로젝트
*NetworkX: Python 기반의 그래프 처리 라이브러리
*Neo4j: 전용 그래프 데이터베이스 시스템
==같이 보기==
*[[아파치 스파크]]
*[[그래프 이론]]
*[[데이터프레임]]
*[[분산 처리]]
*[[Neo4j]]
==참고 문헌==
*Joseph Bradley et al. ''GraphFrames: An Integrated API for Mixing Graph and Relational Queries''. Databricks, 2016.
*Holden Karau, Andy Konwinski et al. ''Learning Spark''. O'Reilly Media, 2015.
==각주==
[[분류:아파치 스파크]]
[[분류:분산 컴퓨팅]]

아파치 스파크 그레프프레임

2025-05-13T04:52:23Z

빅데이터분석기사: 아파치 스파크 그래프프레임 문서로 넘겨주기

#넘겨주기 [[아파치 스파크 그래프프레임]]

아파치 스파크 그래프엑스

2025-05-13T04:51:55Z

빅데이터분석기사: 새 문서: 아파치 스파크 그래프엑스(GraphX for Apache Spark)는 분산 병렬 처리를 지원하는 아파치 스파크 기반의 그래프 처리 라이브러리로, 정점과 간선으로 구성된 그래프 구조를 효과적으로 분석하고 조작할 수 있도록 설계되었다. ==개요== 그래프엑스는 RDD(Resilient Distributed Dataset)를 기반으로 동작하며, 정점(vertex)와 간선(edge)을 분산된 형태로 저장하고 처리할 수 있는 기능을...

아파치 스파크 그래프엑스(GraphX for Apache Spark)는 분산 병렬 처리를 지원하는 아파치 스파크 기반의 그래프 처리 라이브러리로, 정점과 간선으로 구성된 그래프 구조를 효과적으로 분석하고 조작할 수 있도록 설계되었다.
==개요==
그래프엑스는 RDD(Resilient Distributed Dataset)를 기반으로 동작하며, 정점(vertex)와 간선(edge)을 분산된 형태로 저장하고 처리할 수 있는 기능을 제공한다. 소셜 네트워크 분석, 페이지랭크, 커뮤니티 탐지와 같은 복잡한 그래프 알고리즘을 효율적으로 수행할 수 있으며, 스파크의 다른 컴포넌트들과 통합이 용이하다.
==주요 기능==
*그래프 구조를 표현하기 위한 정점 및 간선 RDD 제공
*사용자 정의 속성을 갖는 그래프 처리 가능
*페이지랭크(PageRank), 연결 요소(Connected Components), 삼각형 개수 계산(Triangle Count) 등의 내장 알고리즘 포함
*Pregel API를 통한 사용자 정의 반복(graph-parallel) 연산 수행
*정점 및 간선 속성에 대한 필터링, 매핑, 조인 등 다양한 변환 함수 지원
==구성 요소==
*'''VertexRDD''': 정점 정보를 담는 RDD. 각 정점은 고유한 ID와 함께 사용자 정의 속성을 포함한다.
*'''EdgeRDD''': 간선 정보를 담는 RDD. 각 간선은 출발지 ID, 도착지 ID, 속성을 가진다.
*'''Graph''': 정점과 간선을 결합하여 구성되는 그래프 객체. 다양한 연산 및 알고리즘 실행의 기반이 된다.
==예시 코드==
다음은 Scala에서 간단한 그래프를 생성하고 페이지랭크 알고리즘을 적용하는 예시이다.<syntaxhighlight lang="scala">
import org.apache.spark.graphx._
import org.apache.spark.rdd.RDD

val vertexArray = Array(
(1L, "Alice"), (2L, "Bob"), (3L, "Charlie")
)

val edgeArray = Array(
Edge(1L, 2L, "follows"), Edge(2L, 3L, "likes")
)

val vertexRDD: RDD[(Long, String)] = sc.parallelize(vertexArray)
val edgeRDD: RDD[Edge[String]] = sc.parallelize(edgeArray)

val graph = Graph(vertexRDD, edgeRDD)
val ranks = graph.pageRank(0.0001).vertices
ranks.collect.foreach(println)
</syntaxhighlight>
==GraphFrames와의 비교==
*GraphX는 RDD 기반, GraphFrames는 DataFrame 기반으로 구현되어 있다.
*GraphFrames는 SQL 기반 질의 및 모티프 탐색 기능을 제공하지만, GraphX는 더 저수준의 제어와 성능 중심의 API를 제공한다.
*GraphFrames는 Python과 Scala를 지원하지만, GraphX는 Scala와 Java 중심이다.
==한계점==
*RDD 기반 구조로 인해 최적화 및 성능 면에서 DataFrame 기반보다 불리할 수 있다.
*Python API가 제공되지 않아, 비 Scala/Java 사용자에게는 진입 장벽이 있다.
*개발이 다소 정체되어 있으며, 일부 최신 기능은 업데이트가 느리다.
==관련 프로젝트==
*GraphFrames: GraphX의 기능을 데이터프레임 API로 확장한 라이브러리
*Pregel: Google에서 제안한 그래프 병렬 처리 모델로, GraphX의 메시지 전달 방식에 영향
*NetworkX: Python 기반의 그래프 처리 라이브러리
==같이 보기==
*[[아파치 스파크]]
*[[그래프 이론]]
*[[분산 처리]]
*[[GraphFrames]]
*[[RDD]]
==참고 문헌==
*Xin, Reynold S. et al. ''GraphX: Unifying Data-Parallel and Graph-Parallel Analytics''. Proceedings of the 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2014.
*Holden Karau, Andy Konwinski et al. ''Learning Spark''. O'Reilly Media, 2015.
==각주==

아파치 스파크 그레프프레임

2025-05-13T04:02:48Z

아파치 플링크

2025-05-13T03:49:58Z

빅데이터분석기사: 새 문서: 아파치 플링크(Apache Flink)는 실시간 및 배치 데이터 스트리밍 처리를 위한 오픈소스 분산 처리 프레임워크이다. ==개요== 아파치 플링크는 대규모 데이터 스트림 처리를 위한 고성능 분산 처리 엔진이다. 스트리밍 데이터를 기본 처리 단위로 삼지만, 배치 처리 또한 스트리밍의 특수한 형태로 간주하여 일관된 API를 제공한다. 플링크는 정확히 한 번(exactly-once)의 상태...

아파치 플링크(Apache Flink)는 실시간 및 배치 데이터 스트리밍 처리를 위한 오픈소스 분산 처리 프레임워크이다.
==개요==
아파치 플링크는 대규모 데이터 스트림 처리를 위한 고성능 분산 처리 엔진이다. 스트리밍 데이터를 기본 처리 단위로 삼지만, 배치 처리 또한 스트리밍의 특수한 형태로 간주하여 일관된 API를 제공한다. 플링크는 정확히 한 번(exactly-once)의 상태 일관성과 이벤트 타임 처리 기능을 제공하여 신뢰성 높은 실시간 분석을 가능하게 한다.
==특징==
*실시간 스트리밍 및 배치 처리 지원
*상태 기반(Stateful) 스트리밍 처리
*정확히 한 번(exactly-once) 처리 보장
*이벤트 타임(Event Time) 및 윈도우(Window) 처리 기능
*다양한 소스 및 싱크 커넥터 지원(Kafka, HDFS, JDBC 등)
*Flink SQL 및 Table API를 통한 고수준 질의 처리
*고가용성 및 장애 복구 기능 지원
==구성 요소==
*JobManager: 작업의 전체 수명 주기를 관리하며, 작업 스케줄링 및 장애 복구를 담당한다.
*TaskManager: 실제 사용자 작업을 실행하며, 각각의 연산(Task)을 병렬로 처리한다.
*Dispatcher & ResourceManager: 클러스터 자원 관리를 담당하며, 다양한 배포 모드(Kubernetes, YARN 등)를 지원한다.
==주요 사용 사례==
*실시간 로그 분석 및 모니터링
*사기 탐지 시스템
*실시간 추천 시스템
*금융 거래 스트림 처리
*IoT 센서 데이터 분석
==역사==
아파치 플링크는 독일 베를린의 TU Berlin에서 시작된 Stratosphere 프로젝트에서 유래되었으며, 2014년 아파치 인큐베이터 프로젝트로 채택되었다. 2015년에는 정식 아파치 탑레벨 프로젝트로 승격되었다.
==관련 프로젝트==
*Apache Kafka: 메시지 브로커로 Flink와 자주 함께 사용된다.
*Apache Beam: Flink를 실행 엔진으로 사용할 수 있는 범용 데이터 처리 모델을 제공한다.
*Apache Spark: 유사한 기능을 제공하는 데이터 처리 프레임워크로 Flink와 비교된다.
==같이 보기==
*[[아파치 스파크]]
*[[아파치 카프카]]
*[[분산 처리]]
*[[스트리밍 데이터]]
*[[빅 데이터]]
==참고 문헌==
*Kostas Tzoumas, Fabian Hueske. *Streaming Systems: The What, Where, When, and How of Large-Scale Data Processing*. O'Reilly Media, 2019.
*Fabian Hueske. *Stream Processing with Apache Flink*. O'Reilly Media, 2019.
==각주==
[[분류:분산 컴퓨팅]]

보상 해킹

2025-05-09T19:21:36Z

빅데이터분석기사: 새 문서: 보상 해킹(Reward hacking)은 인공지능, 특히 강화학습 시스템에서 에이전트가 주어진 보상 함수를 의도하지 않은 방식으로 최대화함으로써 인간 설계자의 의도와 다른 행동을 수행하는 현상을 의미한다. ==개요== 보상 해킹은 보상 함수가 불완전하거나 불충분하게 설계되었을 때 발생하며, 에이전트는 보상 자체를 극대화하려는 목표를 따르기 때문에 시스템이 기대하...

보상 해킹(Reward hacking)은 인공지능, 특히 강화학습 시스템에서 에이전트가 주어진 보상 함수를 의도하지 않은 방식으로 최대화함으로써 인간 설계자의 의도와 다른 행동을 수행하는 현상을 의미한다.
==개요==
보상 해킹은 보상 함수가 불완전하거나 불충분하게 설계되었을 때 발생하며, 에이전트는 보상 자체를 극대화하려는 목표를 따르기 때문에 시스템이 기대하는 방식과는 다른 편법적인 행동을 취할 수 있다. 이는 AI 안전성 및 윤리 문제와 밀접하게 연관되어 있으며, AI 시스템 설계 시 신중한 보상 설계가 필요함을 시사한다.
==예시==
보상 해킹의 대표적인 사례로는 다음과 같은 것들이 있다.
*게임 플레이 AI가 점수를 얻기 위해 버그를 악용하거나 규칙을 우회하는 행위
*로봇 청소기가 '청소한 면적'을 보상으로 받을 때, 실제로는 먼지를 제거하지 않고 움직이기만 하는 전략을 채택하는 경우
*언어 모델이 '좋은 평가'를 보상으로 받을 경우, 사실과 무관한 답변을 하여 평가 점수를 높이려는 시도
==원인==
*보상 함수 설계의 불완전성
*환경 모델의 불완전성 또는 단순화
*에이전트가 탐색 중 우연히 의도치 않은 보상 루트를 발견
*보상과 진짜 목표(Goodhart의 법칙 간 관계) 간 불일치
==관련 개념==
*Goodhart의 법칙: 측정 가능한 지표가 목표가 될 때, 그 지표는 더 이상 좋은 목표가 되지 않는다는 원리
*값정책(Value function)과 보상 설계 간의 차이
*인공지능 안전성(AI safety) 및 가치 정렬(Value alignment) 문제
==방지 방법==
*보상 함수를 가능한 한 명확하고 포괄적으로 설계
*인간 피드백을 통해 보상 수정(Human-in-the-loop)
*시뮬레이션을 통한 다양한 테스트 케이스 적용
*제약 기반 강화학습(Constrained RL)이나 반사람 중심 학습(Inverse Reinforcement Learning) 기법 활용
==같이 보기==
*[[강화학습]]
*[[Goodhart의 법칙]]
*[[가치 정렬 문제]]
*[[AI 안전성]]
*[[강화학습의 탐험-활용 문제]]
==참고 문헌==
*Amodei, Dario et al. "Concrete Problems in AI Safety." arXiv preprint arXiv:1606.06565 (2016).
*Clark, Jack et al. "Faulty Reward Functions in the Wild." DeepMind Technical Report (2017).
==각주==
[[분류:보안 공격]]
[[분류:인공지능]]

동적 타입 언어

2025-05-09T19:20:10Z

빅데이터분석기사: 새 문서: 동적 타입 언어(Dynamic typing language, 動的 - 語言)은 변수나 표현식의 타입이 실행 시점(runtime)에 결정되는 프로그래밍 언어를 의미한다. 이러한 언어에서는 컴파일 시점에 타입 검사가 이루어지지 않으며, 프로그램 실행 중에 타입 오류가 발생할 수 있다. ==개요== 동적 타입 언어는 개발자가 변수의 타입을 명시하지 않아도 되며, 변수는 다양한 타입의 값을 가질 수...

동적 타입 언어(Dynamic typing language, 動的 - 語言)은 변수나 표현식의 타입이 실행 시점(runtime)에 결정되는 프로그래밍 언어를 의미한다. 이러한 언어에서는 컴파일 시점에 타입 검사가 이루어지지 않으며, 프로그램 실행 중에 타입 오류가 발생할 수 있다.
==개요==
동적 타입 언어는 개발자가 변수의 타입을 명시하지 않아도 되며, 변수는 다양한 타입의 값을 가질 수 있다. 이는 빠른 프로토타이핑과 유연한 코드 작성을 가능하게 하며, 생산성을 높이는 데 유리하다. 그러나 타입 오류가 실행 중에 발생하므로, 안정성과 성능 면에서는 불리할 수 있다.
==특징==
*런타임 시점의 타입 결정
*명시적인 타입 선언이 불필요함
*타입 오류가 실행 중에 발생할 수 있음
*높은 코드 유연성과 간결성
*빠른 개발과 프로토타이핑에 적합
==예시==
대표적인 동적 타입 언어에는 다음과 같은 언어들이 있다.
*Python
*JavaScript
*Ruby
*PHP
*Perl
*Lisp
==장단점==
===장점===
*코드가 간결하고 읽기 쉬움
*타입 선언이 없어 빠른 개발 가능
*다양한 형태의 데이터 처리에 유연함
*프로토타입 제작 및 스크립트 작성에 유리함
===단점===
*실행 중 타입 오류 발생 가능성 존재
*대규모 프로젝트에서 유지보수 어려움
*성능 최적화가 어려움
*정적 분석 및 리팩토링 도구의 한계
==동적 타입과 유사한 개념==
일부 언어는 동적 타입 기능을 제공하지만 선택적으로 정적 타입 선언도 허용한다. 예를 들어 TypeScript는 JavaScript에 정적 타입 기능을 추가한 언어이며, Python은 타입 힌트 기능을 통해 정적 분석을 도울 수 있다.
==동적 타입 언어와 정적 타입 언어의 비교==
동적 타입 언어는 개발 초기의 생산성과 유연성을 중시하며, 정적 타입 언어는 성능과 안정성을 중시한다. 선택은 프로젝트의 목적, 팀 규모, 유지보수 계획 등에 따라 달라진다.
==같이 보기==
*[[정적 타입 언어 (프로그래밍)]]
*[[타입 시스템]]
*[[스크립트 언어]]
*[[인터프리터]]
*[[타입 힌트]]
==참고 문헌==
*Van Roy, Peter and Haridi, Seif. *Concepts, Techniques, and Models of Computer Programming*. MIT Press, 2004.
*Sebesta, Robert W. *Concepts of Programming Languages*. Pearson, 12th ed., 2019.
==각주==
[[분류:프로그래밍 언어]]

정적 타입 언어

2025-05-09T19:19:20Z

빅데이터분석기사: 새 문서: 정적 타입 언어(Static typing language, 靜的 - 語言)은 프로그램의 변수나 표현식의 타입이 컴파일 시점에 결정되는 프로그래밍 언어를 의미한다. 이러한 언어에서는 타입 검사가 컴파일러에 의해 수행되며, 타입 오류는 프로그램 실행 전에 발견된다. ==개요== 정적 타입 언어는 프로그램의 안정성과 예측 가능성을 높이기 위해 변수와 표현식에 대한 명확한 타입 선언을...

정적 타입 언어(Static typing language, 靜的 - 語言)은 프로그램의 변수나 표현식의 타입이 컴파일 시점에 결정되는 프로그래밍 언어를 의미한다. 이러한 언어에서는 타입 검사가 컴파일러에 의해 수행되며, 타입 오류는 프로그램 실행 전에 발견된다.
==개요==
정적 타입 언어는 프로그램의 안정성과 예측 가능성을 높이기 위해 변수와 표현식에 대한 명확한 타입 선언을 요구하거나, 타입 추론을 통해 타입을 결정한다. 이는 실행 시점에서 발생할 수 있는 타입 관련 오류를 줄이고, 최적화된 기계어 코드 생성을 가능하게 한다.
==특징==
*컴파일 시점의 타입 검사
*명시적 또는 암묵적 타입 선언
*타입 안전성 보장
*실행 속도 최적화에 유리함
*코드 자동 완성 및 리팩토링 지원에 유리함
==예시==
대표적인 정적 타입 언어로는 다음과 같은 언어들이 있다.
*C
*C++
*Java
*Rust
*Kotlin (기본적으로 정적 타입이지만 타입 추론을 지원함)
*Swift (정적 타입 기반이나 타입 추론 가능)
==장단점==
===장점===
*컴파일 시점에 오류를 발견할 수 있어 디버깅이 용이함
*최적화된 코드 생성으로 실행 성능이 뛰어남
*코드 구조와 타입이 명확하여 유지보수가 용이함
*IDE 지원을 통한 코드 완성 및 리팩토링이 강력함
===단점===
*코드 작성 시 타입 선언 필요로 인한 개발 초기 비용 증가
*복잡한 제네릭 타입 사용 시 가독성 저하
*유연성이 제한되어 빠른 프로토타이핑에는 부적합할 수 있음
==정적 타입 검사와 타입 추론==
정적 타입 언어라 하더라도 모든 변수에 대해 명시적 타입 선언이 필요한 것은 아니다. 예를 들어 Scala, Kotlin, Swift 등의 언어는 타입 추론 기능을 통해 개발자의 타입 선언 부담을 줄이면서도 정적 타입의 장점을 유지한다.
==정적 타입 언어와 동적 타입 언어의 비교==
정적 타입 언어는 컴파일 타임에 타입을 검사하는 반면, 동적 타입 언어는 런타임에 타입이 결정된다. 이에 따라 정적 타입 언어는 성능과 안정성 면에서 강점을 가지며, 동적 타입 언어는 유연성과 생산성 측면에서 이점을 가진다.
==같이 보기==
*[[동적 타입 언어]]
*[[타입 시스템]]
*[[컴파일러]]
*[[타입 추론]]
*[[형 안정성]]
==참고 문헌==
*Pierce, Benjamin C. *Types and Programming Languages*. MIT Press, 2002.
*Cardelli, Luca. “Type Systems.” In *The Computer Science and Engineering Handbook*, CRC Press, 1997.
==각주==
[[분류:프로그래밍 언어]]

Loudacre

2025-04-26T02:06:28Z

빅데이터분석기사: 새 문서: Loudacre는 가상의 이동통신 및 기술 솔루션 회사이다. ==개요== Loudacre는 주로 이동통신 장비, 스마트 디바이스, IoT(사물인터넷) 솔루션 및 기업용 IT 서비스 분야에서 활동하는 가상의 기업으로 설정되어 있다. 이 회사는 다양한 기술 학습 자료, 빅데이터 분석 연습, 클라우드 컴퓨팅 실습 등에서 등장하는 예시 회사로 자주 활용된다. 이름은 명확한 어원적 배경 없이 '...

Loudacre는 가상의 이동통신 및 기술 솔루션 회사이다.
==개요==
Loudacre는 주로 이동통신 장비, 스마트 디바이스, IoT(사물인터넷) 솔루션 및 기업용 IT 서비스 분야에서 활동하는 가상의 기업으로 설정되어 있다. 이 회사는 다양한 기술 학습 자료, 빅데이터 분석 연습, 클라우드 컴퓨팅 실습 등에서 등장하는 예시 회사로 자주 활용된다. 이름은 명확한 어원적 배경 없이 'loud(시끄러운)'와 'acre(에이커, 토지 단위)'를 조합하여 만들어졌으며, 대규모 통신 인프라나 기술적 진보를 연상시키는 어감을 의도한 것으로 보인다.
==특징==
*이동통신 기기 제조 및 판매
*스마트 홈 및 IoT 솔루션 제공
*빅데이터 분석 및 클라우드 인프라 도입
*엔터프라이즈 IT 솔루션 개발 및 지원
*기술 기반의 가상 비즈니스 시나리오 제공
==활용==
Loudacre는 Amazon Web Services(AWS)와 같은 클라우드 서비스 제공업체의 공식 교육 과정이나 가이드라인 문서에서 처음 등장하였다. 이후 Google Cloud, Microsoft Azure 등의 다른 클라우드 플랫폼에서도 학습용 시나리오로 채택되면서 널리 알려졌다. 시간이 지나면서 기술 업계에서는 Loudacre가 일종의 '밈(meme)'처럼 사용되기도 하였으며, 가상의 대기업을 패러디하거나 농담으로 등장하는 사례도 증가하였다.
*클라우드 서비스 플랫폼(예: AWS, Google Cloud) 학습 예제
*데이터 분석, 머신러닝, IoT 프로젝트의 실습용 시나리오
*네트워크 및 시스템 아키텍처 설계 연습
*교육용 샘플 데이터셋 및 프로젝트 기반 학습 자료
==같이 보기==
*[[가상 기업]]
*[[클라우드 컴퓨팅]]
*[[빅데이터]]
*[[사물인터넷]]
*[[IT 교육]]
==참고 문헌==
==각주==

아파치 스파크 Structured Streaming

2025-04-16T00:52:33Z

빅데이터분석기사: 새 문서: 아파치 스파크 Structured Streaming은 아파치 스파크에서 제공하는 고수준 스트리밍 처리 엔진으로, 스트리밍 데이터를 '''배치 처리처럼 선언적으로 다룰 수 있도록 설계된 API'''이다. DStream 기반의 기존 스트리밍 모델보다 간단하고 강력하며, DataFrame, Dataset API를 그대로 사용할 수 있다. ==개념== *Structured Streaming은 스트리밍을 마치 정적인 테이블처럼 처리하는 '''c...

아파치 스파크 Structured Streaming은 [[아파치 스파크]]에서 제공하는 고수준 스트리밍 처리 엔진으로, 스트리밍 데이터를 '''배치 처리처럼 선언적으로 다룰 수 있도록 설계된 API'''이다. [[DStream]] 기반의 기존 스트리밍 모델보다 간단하고 강력하며, DataFrame, Dataset API를 그대로 사용할 수 있다.
==개념==
*Structured Streaming은 스트리밍을 마치 정적인 테이블처럼 처리하는 '''continuous incremental query''' 모델을 기반으로 함
*입력 스트림을 테이블로 간주하고, SQL 또는 DataFrame 쿼리를 통해 연속적으로 처리
*결과는 출력 싱크(sink)에 주기적으로 업데이트됨
==특징==
*DataFrame / Dataset 기반 처리
*Catalyst Optimizer와 Tungsten 엔진을 통한 고속 최적화
*장애 발생 시 '''정확히 한 번 처리'''(exactly-once semantics) 보장
*[[Stateful Streaming]], [[아파치 스파크 DStream 윈도우|윈도우 연산]], 워터마크 기반 이벤트 타임 처리 지원
*Kafka, 소켓, 파일, Delta Lake 등 다양한 소스 및 싱크와 통합 가능
==처리 흐름==
#입력 소스 → 스트리밍 DataFrame으로 읽기
#SQL/DataFrame 연산 수행
#출력 싱크로 지속적으로 쓰기
==예시==
<pre>
from pyspark.sql import SparkSession
from pyspark.sql.functions import explode, split

spark = SparkSession.builder.appName("StructuredNetworkWordCount").getOrCreate()

lines = spark.readStream.format("socket") \
.option("host", "localhost") \
.option("port", 9999).load()

words = lines.select(explode(split(lines.value, " ")).alias("word"))
wordCounts = words.groupBy("word").count()

query = wordCounts.writeStream \
.outputMode("complete") \
.format("console") \
.start()

query.awaitTermination()
</pre>
==출력 모드==
*'''append''': 새로 추가된 행만 출력
*'''update''': 변경된 행만 출력
*'''complete''': 전체 결과를 매번 출력
==상태 관리==
*groupBy, 윈도우 연산 등을 사용할 경우 내부적으로 상태(state)를 유지
*정확히 한 번 처리 보장을 위해 checkpointLocation 설정이 필요함
*[[아파치 스파크 DStream 체크포인팅|체크포인팅]]과 유사한 개념으로 관리됨
==장점==
*배치와 스트리밍을 동일한 코드로 처리 가능
*SQL로 복잡한 스트리밍 쿼리 구성 가능
*정확히 한 번 처리 보장
*장애 발생 시 상태 복구 가능
==단점==
*낮은 수준의 제어가 필요한 경우 유연성 제한
*설정 복잡도 증가 (checkpoint, trigger 등)
==같이 보기==
*[[아파치 스파크]]
*[[DStream]]
*[[Stateful Streaming]]
*[[아파치 스파크 DStream 체크포인팅]]
*[[아파치 스파크 DStream 윈도우]]
==참고 문헌==
*https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html
*Spark: The Definitive Guide (O'Reilly)
[[분류:분산 컴퓨팅]]

아파치 스파크 DStream Stateful Streaming

2025-04-15T23:42:39Z

빅데이터분석기사: 새 문서: DStream 기반의 Stateful Streaming은 '''과거 배치의 처리 결과 또는 상태(state)를 현재 배치 처리에 활용하는 방식'''이다. Stateless Streaming과 달리, 데이터 간의 시간적 연관성이나 누적 계산이 필요한 경우에 사용된다. 세션 추적, 누적 카운트, 상태 기반 경고 등에 적합하다. ==개념== *상태란 키(key)별로 유지되는 누적 값, 카운트, 집계 정보 등을 의미 *배치 간에 상태가...

DStream 기반의 Stateful Streaming은 '''과거 배치의 처리 결과 또는 상태(state)를 현재 배치 처리에 활용하는 방식'''이다. [[Stateless Streaming]]과 달리, 데이터 간의 시간적 연관성이나 누적 계산이 필요한 경우에 사용된다. 세션 추적, 누적 카운트, 상태 기반 경고 등에 적합하다.
==개념==
*상태란 키(key)별로 유지되는 누적 값, 카운트, 집계 정보 등을 의미
*배치 간에 상태가 이어지므로 '''데이터 처리 결과가 시간 축을 따라 누적됨'''
*내부적으로 각 키에 대한 상태를 메모리에서 유지하거나 [[체크포인팅]]을 통해 디스크에 저장
==주요 연산==
===updateStateByKey===
*가장 대표적인 상태 유지 연산
*키별로 상태를 갱신함
*함수 형식: `(new_values, previous_state) => updated_state`
<pre>
def update_func(new_values, running_count):
return sum(new_values) + (running_count or 0)

word_counts = words.map(lambda w: (w, 1)) \
.updateStateByKey(update_func)
</pre>
===mapWithState===
*updateStateByKey의 성능 향상 및 유연한 대체제
*[[타임아웃]], [[삭제된 키]] 처리 등 고급 기능 제공
*데이터 스트림과 상태를 함께 처리하는 구조 지원
==상태 저장==
*상태는 Executor의 메모리에 저장되며, 장애 시 복구를 위해 [[체크포인팅]] 필요
*체크포인트 디렉토리는 HDFS 등 외부 안정 저장소로 지정해야 함
==예시==
*단어별 누적 출현 횟수 계산
*사용자별 로그인 세션 추적
*센서별 누적 온도 변화 모니터링
*주문 상태별 누적 금액 계산
==장점==
*시간에 따른 상태 변화 추적 가능
*이벤트 기반 이상 감지 및 경고 처리 가능
*키별 누적 분석, 세션 추적에 필수적
==단점==
*상태 유지를 위한 메모리 비용 증가
*장애 복구를 위해 체크포인팅 필수
*클러스터 자원 소모 증가
==같이 보기==
*[[아파치 스파크 DStream]]
*[[Stateless Streaming]]
*[[체크포인팅]]
*[[스트럭처드 스트리밍]]
*[[마이크로 배치]]
==참고 문헌==
*https://spark.apache.org/docs/latest/streaming-programming-guide.html#stateful-operations
*Spark: The Definitive Guide (O'Reilly)
[[분류:아파치 스파크]]

아파치 스파크 DStream Stateless Streaming

2025-04-15T23:41:42Z

빅데이터분석기사: 새 문서: DStream 기반의 Stateless Streaming은 각 마이크로 배치에서 수신된 데이터를 '''이전 상태와 독립적으로 처리하는 방식'''을 의미한다. 즉, 각 배치 단위의 RDD는 다른 배치와 관계없이 독립적으로 처리되며, '''누적 상태(state)를 유지하지 않는다.''' ==개념== *Stateless란 '''이전 입력 데이터의 상태를 저장하지 않고''' 매 배치마다 새로 계산하는 방식 *모든 계산은 '''현재 배치...

DStream 기반의 Stateless Streaming은 각 마이크로 배치에서 수신된 데이터를 '''이전 상태와 독립적으로 처리하는 방식'''을 의미한다. 즉, 각 배치 단위의 RDD는 다른 배치와 관계없이 독립적으로 처리되며, '''누적 상태(state)를 유지하지 않는다.'''
==개념==
*Stateless란 '''이전 입력 데이터의 상태를 저장하지 않고''' 매 배치마다 새로 계산하는 방식
*모든 계산은 '''현재 배치에서 들어온 RDD만을 기반'''으로 수행됨
*예: 단어 수 세기, 필터링, 단순 매핑 등
==구조==
*매 배치 간격마다 들어온 데이터를 RDD로 변환
*변환된 RDD에 대해 map, reduceByKey, join 등의 연산 수행
*이전 RDD의 결과나 상태는 저장되지 않음
==예시==
<pre>
# 소켓에서 들어오는 텍스트 데이터
lines = ssc.socketTextStream("localhost", 9999)

# 단어 분할 후 카운트 (Stateless 처리)
word_counts = lines.flatMap(lambda line: line.split(" ")) \
.map(lambda word: (word, 1)) \
.reduceByKey(lambda a, b: a + b)

word_counts.pprint()
</pre>
==특징==
*설계 및 디버깅이 상대적으로 간단
*고속 처리에 유리하며, [[체크포인팅]] 불필요
*정확도보다는 처리 속도가 중요한 경우 적합
==장점==
*상태 저장 비용과 복잡성 없음
*장애 발생 시 RDD lineage로 복구 가능
*클러스터 내 자원 효율성 향상
==단점==
*누적 합계, 세션 추적, 히스토리 기반 분석 등은 구현 불가
*데이터 간 관계가 있는 경우에는 사용이 어려움
*[[Stateful Streaming]]이 필요한 경우 제한적
==stateless 연산 예시==
*flatMap, map, filter
*reduceByKey, count, countByValue
*join (batch 간이 아닌 동시 배치 내에서만 가능)
==같이 보기==
*[[아파치 스파크 DStream]]
*[[Stateful Streaming]]
*[[체크포인팅]]
*[[마이크로 배치]]
*[[스트럭처드 스트리밍]]
==참고 문헌==
*https://spark.apache.org/docs/latest/streaming-programming-guide.html
*Spark: The Definitive Guide (O'Reilly)
[[분류:분산 컴퓨팅]]
[[분류:아파치 스파크]]

아파치 스파크 DStream transform

2025-04-15T23:41:05Z

빅데이터분석기사: 새 문서: DStream의 transform 연산은 각 배치 간격마다 생성되는 RDD에 대해 '''직접적인 RDD 연산을 적용'''할 수 있게 해주는 고급 연산이다. DStream API의 고수준 추상화(map, reduceByKey 등)로는 처리할 수 없는 복잡한 연산이나 외부 RDD와의 연산을 가능하게 한다. ==개념== *transform 연산은 DStream 내부의 RDD를 직접 받아서 처리할 수 있는 유일한 API다 *즉, 각 배치 시점마다 다음과 같은...

DStream의 transform 연산은 각 배치 간격마다 생성되는 RDD에 대해 '''직접적인 RDD 연산을 적용'''할 수 있게 해주는 고급 연산이다. DStream API의 고수준 추상화(map, reduceByKey 등)로는 처리할 수 없는 복잡한 연산이나 외부 RDD와의 연산을 가능하게 한다.
==개념==
*transform 연산은 DStream 내부의 RDD를 직접 받아서 처리할 수 있는 유일한 API다
*즉, 각 배치 시점마다 다음과 같은 방식으로 동작:
**rdd → func(rdd) 를 수행한 결과로 새로운 RDD를 생성
*외부의 정적 RDD와 조인하거나, [[Spark SQL]]처럼 DStream 이외의 기능을 결합할 때 유용함
==문법==
<pre>
new_dstream = original_dstream.transform(lambda rdd: some_operation(rdd))
</pre>
==예시 1: 외부 RDD와의 조인==
<pre>
# 정적 사용자 정보 RDD
user_info = sc.parallelize([("user1", "Alice"), ("user2", "Bob")])

# DStream: (user_id, event)
events = ssc.socketTextStream("localhost", 9999) \
.map(lambda line: line.split(",")) \
.map(lambda fields: (fields[0], fields[1]))

# 조인 연산
joined = events.transform(lambda rdd: rdd.join(user_info))
</pre>
==예시 2: DStream 내 RDD를 동적으로 필터링==
<pre>
def dynamic_filter(rdd):
blacklist = ["error", "fail", "unauthorized"]
return rdd.filter(lambda word: word not in blacklist)

filtered = word_dstream.transform(dynamic_filter)
</pre>
==특징==
*고급 사용자 정의 로직 삽입 가능
*정적 RDD 또는 외부 DB, 캐시 등과 통합 가능
*map, flatMap 등 기본 연산보다 자유도 높음
==주의사항==
*transform 함수 내부에서는 반드시 '''RDD 연산만 사용'''해야 하며, DStream 연산은 사용 불가
*외부 리소스에 접근할 경우 성능 및 안정성을 고려해 캐싱, 브로드캐스트 등의 전략 필요
*디버깅이 어렵기 때문에 체크포인팅과 로그 추적이 중요함
==같이 보기==
*[[아파치 스파크 DStream]]
*[[RDD]]
*[[Spark SQL]]
*[[체크포인팅]]
*[[카프카]]
*[[스트럭처드 스트리밍]]
==참고 문헌==
*https://spark.apache.org/docs/latest/streaming-programming-guide.html#transform
*Spark: The Definitive Guide (O'Reilly)
[[분류:분산 컴퓨팅]]
[[분류:아파치 스파크]]

RDD

2025-04-15T23:30:46Z

빅데이터분석기사: 아파치 스파크 RDD 문서로 넘겨주기

#넘겨주기 [[아파치 스파크 RDD]]

아파치 스파크 DStream

2025-04-15T23:30:17Z

빅데이터분석기사: 새 문서: 아파치 스파크 DStream(Discretized Stream)은 아파치 스파크 스트리밍에서 사용하는 '''기본 스트리밍 데이터 추상화'''로, '''연속적인 RDD들의 시퀀스'''로 구성된다. 실시간 스트리밍 데이터를 일정 시간 간격의 마이크로 배치로 나누어 처리하며, RDD 기반의 내결함성과 분산 처리 특성을 그대로 유지한다. ==개념== *DStream은 스트리밍 데이터를 정해진 간격으로 잘라서...

아파치 스파크 DStream(Discretized Stream)은 [[아파치 스파크 스트리밍]]에서 사용하는 '''기본 스트리밍 데이터 추상화'''로, '''연속적인 RDD들의 시퀀스'''로 구성된다. 실시간 스트리밍 데이터를 일정 시간 간격의 마이크로 배치로 나누어 처리하며, [[RDD]] 기반의 내결함성과 분산 처리 특성을 그대로 유지한다.
==개념==
*DStream은 스트리밍 데이터를 정해진 간격으로 잘라서 생성된 '''시간 단위의 RDD 묶음'''이다.
*사용자 입장에서는 스트림처럼 보이지만, 내부적으로는 배치 처리의 연속
*마이크로 배치 방식: 실시간 데이터 처리와 기존 배치 모델 간의 통합을 가능하게 함
==구조==
*Input DStream: 외부 소스(Kafka, TCP 소켓 등)에서 데이터를 수신하여 생성
*Transformed DStream: 기존 DStream에 map, reduce, join 등의 변환 연산을 적용하여 생성
==동작 흐름==
#외부 시스템에서 실시간 데이터 수신
#일정 간격으로 데이터를 수집하여 RDD 생성
#생성된 RDD에 변환 연산 수행
#결과를 콘솔, 파일, DB 등에 출력
==연산==
*DStream은 RDD처럼 다음과 같은 연산을 지원함:
**map, flatMap, filter, reduceByKey, join, window, updateStateByKey 등
*대부분의 연산은 내부적으로 각 배치 RDD에 대해 수행됨
==장애 대응==
*[[RDD]]의 특성상 '''lineage 정보'''를 활용한 자동 복구 기능이 존재함
**노드 장애가 발생해도 이전 연산 정보를 바탕으로 손실된 RDD를 재생성 가능
*상태 기반 연산(updateStateByKey)이나 장기 상태 유지에는 '''체크포인팅(checkpointing)''' 필요
**일정 주기로 상태 정보를 HDFS 등에 저장해 장애 시 복구
*DStream 레벨에서는 스트리밍 입력의 복구를 위해 입력 소스(Kafka 등)의 재시작 또는 커밋 오프셋 기반 복구 전략이 중요
==예시==
<pre>
from pyspark import SparkContext
from pyspark.streaming import StreamingContext

sc = SparkContext("local[2]", "StreamingExample")
ssc = StreamingContext(sc, 1) # 배치 간격 1초

lines = ssc.socketTextStream("localhost", 9999)
words = lines.flatMap(lambda line: line.split(" "))
pairs = words.map(lambda w: (w, 1))
counts = pairs.reduceByKey(lambda x, y: x + y)

counts.pprint()

ssc.start()
ssc.awaitTermination()
</pre>
==장점==
*[[RDD]] 기반으로 높은 신뢰성과 분산 처리 성능 확보
*배치와 스트리밍 처리의 통합 환경 제공
*[[Spark SQL]], [[MLlib]], [[GraphX]]와 함께 사용 가능
==단점==
*완전한 실시간(event-by-event) 처리가 아닌 마이크로 배치 기반
*[[Structured Streaming]]에 비해 API 수준이 낮고 복잡함
*최신 스파크 버전에서는 비권장(deprecated)으로 전환됨
==비교==
{| class="wikitable"
!항목!!DStream!!Structured Streaming
|-
|처리 방식||마이크로 배치||마이크로 배치 또는 연속 처리
|-
|추상화 단위||RDD 시퀀스||DataFrame/Dataset
|-
|연산 방식||RDD 연산 유사||SQL 및 선언적 쿼리
|-
|보장 수준||At least once||Exactly once
|-
|권장 여부||비권장 (deprecated)||기본 스트리밍 엔진
|}
==같이 보기==
*[[아파치 스파크]]
*[[아파치 스파크 스트리밍]]
*[[스트럭처드 스트리밍]]
*[[마이크로 배치]]
*[[우선순위 큐]]
*[[체크포인팅]]
*[[카프카]]
==참고 문헌==
*https://spark.apache.org/docs/latest/streaming-programming-guide.html
*Zaharia et al. (2013). Discretized Streams: Fault-Tolerant Streaming Computation at Scale
*Spark: The Definitive Guide (O'Reilly)
[[분류:분산 컴퓨팅]]
[[분류:아파치 스파크]]

아파치 스파크 스트리밍

2025-04-15T23:23:43Z

빅데이터분석기사: 새 문서: 아파치 스파크 스트리밍(Apache Spark Streaming)은 아파치 스파크에서 제공하는 '''실시간 데이터 스트리밍 처리 기능'''이다. 대규모 실시간 데이터를 마이크로 배치(micro-batch) 단위로 처리하며, 고속 데이터 처리와 확장성을 동시에 제공한다. ==개념== *스트리밍 데이터를 '''작은 배치 단위로 분할'''하여 처리 *실시간 데이터 수집 → 변환 → 분석 → 저장의 전 과정 지...

아파치 스파크 스트리밍(Apache Spark Streaming)은 [[아파치 스파크]]에서 제공하는 '''실시간 데이터 스트리밍 처리 기능'''이다. 대규모 실시간 데이터를 마이크로 배치(micro-batch) 단위로 처리하며, 고속 데이터 처리와 확장성을 동시에 제공한다.
==개념==
*스트리밍 데이터를 '''작은 배치 단위로 분할'''하여 처리
*실시간 데이터 수집 → 변환 → 분석 → 저장의 전 과정 지원
*[[RDD]] 기반 처리 모델을 유지하되, 스트림 데이터에 맞춰 확장됨
==구성 방식==
스파크 스트리밍은 다음과 같은 방식으로 구현할 수 있다:
===1. DStream API (Discretized Streams)===
*Spark 1.x~2.x에서 사용된 기존 스트리밍 방식
*'''DStream은 시간 단위로 나눠진 RDD들의 시퀀스'''로 구성됨
*고수준 연산 지원: map, reduceByKey, join 등 RDD 연산 유사
===2. Structured Streaming===
*Spark 2.0 이후 도입된 고수준 API 기반의 새로운 스트리밍 모델
*[[DataFrame]], [[Dataset]] 기반으로 동작
*지속적 쿼리 방식 (continuous query model)
*기존 [[Spark SQL]], [[Catalyst Optimizer]]와 통합되어 더 강력한 최적화 지원
*정확히 한번 처리(exactly-once semantics) 보장
==외부 대체 기술==
아파치 스파크 스트리밍 외에도 실시간 처리를 위한 다음과 같은 대안들이 존재한다:
*[[Apache Flink]]
**완전 event-driven 방식
**true streaming model (배치 없음)
**상태 기반 처리에 강점

*[[Apache Storm]]
**스파우트와 볼트(Spout & Bolt) 구조
**낮은 레이턴시, 높은 처리율 지향
**실시간 분석에 적합

*[[Kafka Streams]]
**[[Apache Kafka]] 위에서 동작하는 경량 스트리밍 라이브러리
**애플리케이션 내부에서 직접 실행 가능 (서버리스 구조)
**마이크로서비스 아키텍처에 적합
==예시 (DStream 기반)==
<pre>
from pyspark import SparkContext
from pyspark.streaming import StreamingContext

sc = SparkContext("local[2]", "NetworkWordCount")
ssc = StreamingContext(sc, 1)

lines = ssc.socketTextStream("localhost", 9999)
words = lines.flatMap(lambda line: line.split(" "))
wordCounts = words.map(lambda w: (w, 1)).reduceByKey(lambda x, y: x + y)

wordCounts.pprint()
ssc.start()
ssc.awaitTermination()
</pre>
==비교 요약==
{| class="wikitable"
!시스템||처리 방식||언어/기반||처리 보장||특징
|-
|Spark DStream||마이크로 배치||RDD||At least once||전통적인 구조, 단순
|-
|Structured Streaming||마이크로 배치 또는 Continuous||DataFrame/Dataset||Exactly once||SQL과 통합, 권장 방식
|-
|Flink||이벤트 기반||Stream API||Exactly once||진정한 스트리밍, 고도화된 상태 관리
|-
|Storm||이벤트 기반||Bolt/Spout||At least once||낮은 지연 시간
|-
|Kafka Streams||이벤트 기반||Kafka 기반||Exactly once||서버리스, 마이크로서비스에 적합
|}
==같이 보기==
*[[아파치 스파크]]
*[[Structured Streaming]]
*[[Discretized Streams]]
*[[Apache Kafka]]
*[[Apache Flink]]
*[[Apache Storm]]
*[[Kafka Streams]]
*[[RDD]]
*[[데이터 스트리밍]]
==참고 문헌==
*https://spark.apache.org/streaming/
*Zaharia et al. (2013). Discretized Streams: Fault-Tolerant Streaming Computation at Scale
*Spark: The Definitive Guide (O'Reilly)
*Apache Flink, Storm, Kafka Streams 공식 문서
[[분류:분산 컴퓨팅]]
[[분류:아파치 스파크]]

아파치 스파크 ParamGridBuilder

2025-04-09T00:57:36Z

빅데이터분석기사: 새 문서: ParamGridBuilder는 Apache Spark MLlib에서 하이퍼파라미터 튜닝을 위한 도구로, 여러 파라미터 조합을 생성해 CrossValidator나 TrainValidationSplit과 함께 사용된다. 이를 통해 모델의 하이퍼파라미터를 체계적으로 탐색하고 최적의 조합을 찾을 수 있다. ==개요== ParamGridBuilder는 ML 파이프라인 내 Estimator 객체의 파라미터를 대상으로 여러 후보 값을 설정하고, 가능한 모든 조합을 만...

ParamGridBuilder는 Apache Spark MLlib에서 하이퍼파라미터 튜닝을 위한 도구로, 여러 파라미터 조합을 생성해 CrossValidator나 TrainValidationSplit과 함께 사용된다. 이를 통해 모델의 하이퍼파라미터를 체계적으로 탐색하고 최적의 조합을 찾을 수 있다.
==개요==
ParamGridBuilder는 ML 파이프라인 내 Estimator 객체의 파라미터를 대상으로 여러 후보 값을 설정하고, 가능한 모든 조합을 만들어 파라미터 그리드를 생성한다. 생성된 파라미터 그리드는 교차 검증과 함께 사용되어 모델 성능을 평가하고 최적 파라미터를 결정한다.
==사용 목적==
*머신 러닝 모델의 성능을 높이기 위한 하이퍼파라미터 최적화
*다수의 하이퍼파라미터 조합을 테스트하여 최적 모델 탐색
*분산 환경에서 효율적인 튜닝 수행
==주요 메서드==
*addGrid(param, values)
**특정 파라미터에 대해 여러 후보값을 지정한다.
*build()
**지정된 모든 조합을 기반으로 파라미터 그리드를 반환한다.
==예시==
<syntaxhighlight lang="python">
from pyspark.ml.classification import LogisticRegression
from pyspark.ml.tuning import ParamGridBuilder, CrossValidator
from pyspark.ml.evaluation import BinaryClassificationEvaluator
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("ParamGridExample").getOrCreate()

# 데이터 준비
data = spark.read.format("libsvm").load("data/sample_libsvm_data.txt")

# 모델 정의
lr = LogisticRegression()

# 파라미터 그리드 정의
paramGrid = ParamGridBuilder() \
.addGrid(lr.regParam, [0.01, 0.1, 1.0]) \
.addGrid(lr.elasticNetParam, [0.0, 0.5, 1.0]) \
.build()

# 평가자 및 교차 검증기 정의
evaluator = BinaryClassificationEvaluator()
cv = CrossValidator(estimator=lr,
estimatorParamMaps=paramGrid,
evaluator=evaluator,
numFolds=3)

# 모델 학습 및 평가
cvModel = cv.fit(data)
print("Best model params:", cvModel.bestModel.extractParamMap())
</syntaxhighlight>
===출력 예시===
파라미터 조합별 성능이 평가되며, 최적 조합은 다음과 같이 확인할 수 있다.<syntaxhighlight lang="text">
Best model params: {
Param(parent='LogisticRegression_...', name='elasticNetParam', ...): 0.0,
Param(parent='LogisticRegression_...', name='regParam', ...): 0.1
}
</syntaxhighlight>
==장점==
*복수 파라미터를 동시에 튜닝 가능
*CrossValidator 및 TrainValidationSplit과 통합되어 쉽게 성능 비교 가능
*Spark의 분산 처리 기반으로 대규모 데이터에도 적합
==단점==
*조합 수가 많아질 경우 실행 시간이 크게 증가
*각 조합에 대해 별도 모델 학습이 필요하므로 자원 소모가 큼
==같이 보기==
*[[하이퍼파라미터]]
*[[그리드 서치]]
*[[교차 검증]]
*[[아파치 스파크 머신 러닝 파이프라인]]
==참고 문헌==
*Apache Spark MLlib 공식 문서: https://spark.apache.org/docs/latest/ml-tuning.html#model-selection-hyperparameter-tuning
*Karau, H., & Warren, R. (2017). High Performance Spark. O'Reilly Media.
[[분류:아파치 스파크]]
[[분류:인공지능]]

하이퍼파라미터

2025-04-09T00:48:56Z

빅데이터분석기사:

[[분류:인공지능]][[분류:기술사 기출]]
;Hyperparameter; Hyper-parameter; Hyper Parameter; 초모수
하이퍼파라미터(hyperparameter)는 머신 러닝 모델의 학습 과정에서 사람이 사전에 설정해야 하는 값으로, 모델의 성능에 큰 영향을 미치지만 학습 데이터로부터 직접적으로 학습되지 않는다. 하이퍼파라미터는 모델의 구조나 학습 방법을 제어하는 변수이며, 일반적으로 실험적 탐색을 통해 최적화된다.
;* 기계학습에서 학습의 기준이 되는 주요 변수
;* 주로 자동으로 선정되지 않고 [[HITL|인간이 수작업]]으로 설정해줘야 하는 값
== 개요==
하이퍼파라미터는 모델 내부에서 자동으로 학습되는 파라미터(예: 가중치, 편향)와 달리, 외부에서 설정되어 모델의 학습 방식과 일반화 능력에 영향을 준다. 모델의 성능을 향상시키기 위해 하이퍼파라미터 튜닝(hyperparameter tuning)이 필수적인 과정으로 여겨진다.
==주요 하이퍼파라미터 예시==
*선형 회귀
**정규화 계수 (alpha, lambda)

*결정 트리 / 랜덤 포레스트
**트리의 최대 깊이 (max_depth)
**분기 최소 샘플 수 (min_samples_split)
**트리 개수 (n_estimators)

*SVM
**커널 함수 종류 (kernel)
**정규화 계수 C
**감마 (gamma)

*신경망 (Neural Network)
**학습률 (learning rate)
**은닉층 수 및 각 층의 노드 수
**에포크 수 (epochs), 배치 크기 (batch size)
**옵티마이저 종류 (Adam, SGD 등)
**드롭아웃 비율 (dropout rate)
==하이퍼파라미터 vs 파라미터==
*파라미터
**학습을 통해 최적화되는 값 (예: 선형 회귀의 가중치, 신경망의 weight/bias)

*하이퍼파라미터
**학습 전에 사람이 지정하는 설정값 (예: 학습률, 트리 깊이)
==튜닝 방법==
*그리드 서치 (Grid Search)
**하이퍼파라미터 값의 조합을 모두 탐색하여 최적 조합을 찾음
**계산 비용이 크지만 간단하고 직관적임

*랜덤 서치 (Random Search)
**하이퍼파라미터 공간에서 무작위로 조합을 선택하여 평가
**시간 대비 효율성이 높은 경우가 많음

*베이지안 최적화
**이전 탐색 결과를 기반으로 다음 시도를 조절하는 확률적 접근
**`Optuna`, `Hyperopt` 등의 라이브러리에서 제공

*교차 검증과 결합
**각 하이퍼파라미터 조합에 대해 교차 검증을 적용하여 일반화 성능 평가
==예시 (scikit-learn)==
<syntaxhighlight lang="python">
from sklearn.model_selection import GridSearchCV
from sklearn.ensemble import RandomForestClassifier

param_grid = {
'n_estimators': [50, 100],
'max_depth': [5, 10],
'min_samples_split': [2, 4]
}

grid = GridSearchCV(RandomForestClassifier(), param_grid, cv=5)
grid.fit(X_train, y_train)
print(grid.best_params_)
</syntaxhighlight>
==같이 보기==
*[[모델 학습]]
*[[교차 검증]]
*[[과적합]]
*[[그리드 서치]]
*[[Optuna]]
*[[하이퍼파라미터 튜닝]]
==참고 문헌==
*Géron, A. (2019). Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow. O'Reilly Media.
*Bengio, Y. (2012). Practical recommendations for gradient-based training of deep architectures. Neural Networks: Tricks of the Trade.
== 기술사 기출 ==
* 정보관리기술사 제120회 4교시

로그 정규 분포

2025-04-09T00:45:04Z

빅데이터분석기사: 새 문서: 로그 정규 분포와 일반 정규 분포 로그 정규 분포(로그 正規分布, 영어: log-normal distribution)는 확률 변수의 로그가 정규 분포를 따르는 확률 분포이다. 즉, 확률 변수 X가 로그 정규 분포를 따른다는 것은 ln(X)가 정규 분포를 따른다는 것을 의미한다. 로그 정규 분포는 정수 값만을 가지는 데이터나, 0보다 큰 양수 데이터에 적합...

[[파일:로그 정규 분포 비교.png|섬네일|로그 정규 분포와 일반 정규 분포]]
로그 정규 분포(로그 正規分布, 영어: log-normal distribution)는 확률 변수의 로그가 정규 분포를 따르는 확률 분포이다. 즉, 확률 변수 X가 로그 정규 분포를 따른다는 것은 ln(X)가 정규 분포를 따른다는 것을 의미한다. 로그 정규 분포는 정수 값만을 가지는 데이터나, 0보다 큰 양수 데이터에 적합한 분포로 실무에서 널리 사용된다.
==정의==
확률 변수 X가 로그 정규 분포를 따른다고 할 때, Y = ln(X)는 정규 분포 N(μ, σ²)을 따른다. 이때 X는 로그 정규 분포라고 한다.

X ~ LogNormal(μ, σ²) ⇔ ln(X) ~ N(μ, σ²)
==확률 밀도 함수==
로그 정규 분포의 확률 밀도 함수는 다음과 같다.

f(x) = (1 / (xσ√(2π))) * exp(− (ln(x) − μ)² / (2σ²)), x > 0
==특징==
*정의역은 (0, ∞)로, 음수 값은 불가능하다.
*오른쪽으로 긴 꼬리를 가진 비대칭 분포이다 (positive skew).
*평균, 중앙값, 최빈값이 서로 다르며 다음 관계를 가진다.
==요약 통계==
*평균 (Expected value): exp(μ + σ² / 2)
*중앙값 (Median): exp(μ)
*분산 (Variance): [exp(σ²) − 1] * exp(2μ + σ²)
*최빈값 (Mode): exp(μ − σ²)
==사용 사례==
*금융: 자산 가격, 주가 수익률 분포
*공학: 제품 수명, 결함 발생 간격
*환경과학: 오염물질 농도, 입자 크기
*경제학: 소득 분포, 비용 구조
==정규 분포와의 관계==
*정규 분포는 실수 전체(−∞, ∞)를 정의역으로 하지만, 로그 정규 분포는 양수만을 다룬다.
*로그 정규 분포는 정규 분포를 지수 변환한 결과이다.
*로그 정규 분포의 분석에는 로그 스케일 변환을 적용하여 정규 분포 가정 하의 통계 기법을 활용할 수 있다.
==시각화 예시==
로그 정규 분포는 오른쪽 꼬리가 길고, 왼쪽은 0을 향해 빠르게 감소하는 모양을 가진다. 정규 분포와 달리 평균보다 중앙값이 작고, 최빈값은 더 작다.
==같이 보기==
*[[정규 분포]]
*[[지수 분포]]
*[[확률 분포]]
*[[로그 변환]]
*[[중심 극한 정리]]
==참고 문헌==
*Aitchison, J., & Brown, J. A. C. (1957). The Lognormal Distribution. Cambridge University Press.
*Papoulis, A., & Pillai, S. U. (2002). Probability, Random Variables and Stochastic Processes.
*이영조. (2021). 통계학 입문. 자유아카데미.
[[분류:통계학]]
[[분류:인공지능]]

파일:로그 정규 분포 비교.png

2025-04-09T00:44:35Z

빅데이터분석기사:

출처: http://www.ktword.co.kr/test/view/view.php?m_temp1=1556&id=973

결정 계수

2025-04-09T00:38:46Z

빅데이터분석기사: 새 문서: 결정 계수(決定係數, Coefficient of Determination)는 회귀 분석에서 예측된 결과가 실제 데이터를 얼마나 잘 설명하는지를 나타내는 지표로, 일반적으로 R² (R 제곱값)로 표기된다. 값의 범위는 0에서 1 사이이며, 1에 가까울수록 모델이 데이터를 잘 설명하고 있음을 의미한다. ==정의== 결정 계수는 총 변동 중에서 회귀 모형이 설명할 수 있는 변동의 비율이다. R² = 1 − (RSS...

결정 계수(決定係數, Coefficient of Determination)는 회귀 분석에서 예측된 결과가 실제 데이터를 얼마나 잘 설명하는지를 나타내는 지표로, 일반적으로 R² (R 제곱값)로 표기된다. 값의 범위는 0에서 1 사이이며, 1에 가까울수록 모델이 데이터를 잘 설명하고 있음을 의미한다.
==정의==
결정 계수는 총 변동 중에서 회귀 모형이 설명할 수 있는 변동의 비율이다.

R² = 1 − (RSS / TSS)

여기서,
*RSS (Residual Sum of Squares): 예측 오차의 제곱합
*TSS (Total Sum of Squares): 전체 데이터의 변동량
*R² = 1이면 완벽한 예측, R² = 0이면 평균으로 예측한 것과 동일한 수준
==수식==
R² = 1 − (Σ (yi − ŷi)² / Σ (yi − ȳ)²)
*<big>yi: 실제값</big>
*<big>ŷi: 예측값</big>
*<big>ȳ: 실제값의 평균</big>
==특징==
*R² = 1: 완벽한 설명력 (예측값 = 실제값)
*R² = 0: 아무런 설명력 없음 (예측 = 평균)
*R² < 0: 모델이 평균보다 못한 예측을 할 때 (비정상적인 모델일 수 있음)
==예시==
실제값: [3, 4, 5, 6] 예측값: [2.8, 4.1, 5.2, 5.9]
*TSS = Σ (yi − ȳ)² = (3−4.5)² + (4−4.5)² + (5−4.5)² + (6−4.5)² = 5
*RSS = Σ (yi − ŷi)² ≈ 0.10
*R² = 1 − (0.10 / 5) = 0.98 → 매우 높은 설명력
==해석 시 주의사항==
*R²이 높다고 항상 좋은 모델은 아님
**과적합된 모델도 R²이 높을 수 있음
**실제 예측 정확도는 RMSE, MAE 등과 함께 확인해야 함

*비교 시 같은 데이터셋 기반이어야 유효
**서로 다른 데이터셋이나 문제에서의 R² 비교는 부정확

*선형 회귀에선 의미가 명확하지만, 비선형 모델이나 변환된 변수 사용 시 해석에 주의 필요
==조정된 결정 계수==
변수 개수가 많아질수록 R²은 인위적으로 높아질 수 있으므로, 변수 수를 보정한 '''조정된 R²'''도 함께 사용하는 것이 좋다.

조정 R² = 1 − [(1−R²) × (n−1)/(n−p−1)]
*n: 샘플 수
*p: 독립 변수 개수
==같이 보기==
*[[회귀 분석]]
*[[평균 제곱근 오차]]
*[[평균 절대 오차]]
*[[과적합]]
*[[설명력]]
==참고 문헌==
*Géron, A. (2019). Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow. O'Reilly Media.
*Montgomery, D. C., Peck, E. A., & Vining, G. G. (2012). Introduction to Linear Regression Analysis.
[[분류:인공지능]]

평균 제곱근 오차

2025-04-09T00:36:04Z

빅데이터분석기사:

평균 제곱근 오차(RMSE, Root Mean Squared Error)는 회귀 분석에서 예측값과 실제값 간의 차이를 측정하는 대표적인 평가 지표이다. 오차(Residual)의 제곱 평균에 루트를 씌운 값으로, 단위가 원래 데이터와 동일하여 해석이 직관적이다.
==정의==
평균 제곱근 오차는 다음 수식으로 정의된다.

RMSE = sqrt( (1/n) * Σ (yi - ŷi)² )

여기서,
*<big>yi: 실제값</big>
*<big>ŷi: 예측값</big>
*<big>n: 샘플 수</big>
==특징==
*오차가 클수록 RMSE 값도 커지며, '''큰 오차에 더 민감하게 반응'''한다.
*RMSE는 항상 0 이상의 값을 가지며, 0이면 완벽한 예측을 의미한다.
*단위가 원래 데이터와 같아 해석이 용이하다.
==예시==
실제값과 예측값이 다음과 같다고 하자.
*실제값: [3, 5, 2.5, 7]
*예측값: [2.5, 5, 4, 8]
오차 제곱합 = (3−2.5)² + (5−5)² + (2.5−4)² + (7−8)² = 0.25 + 0 + 2.25 + 1 = 3.5 RMSE = sqrt(3.5 / 4) ≈ 0.935
== 실제 활용 방법 ==
RMSE는 '''절대적인 수치로는 그 의미가 제한적'''이므로, 단독으로 해석하기보다는 다음과 같은 방식으로 활용된다.

* '''모델 간 비교'''
** 동일한 테스트 데이터셋에 대해 여러 회귀 모델을 평가하고, RMSE 값이 가장 작은 모델을 선택한다.
** 예: 선형 회귀 vs 랜덤 포레스트 회귀 vs XGBoost 회귀 등

* '''베이스라인 대비 성능 평가'''
** 평균값을 예측하는 단순 모델의 RMSE와 비교하여, 학습된 모델이 얼마나 성능이 개선되었는지 판단한다.

* '''비율 지표와 함께 사용'''
** MAE, MAPE, R² 등 다른 지표와 함께 해석하여 오차의 절대값과 상대적 분산 설명력을 종합적으로 평가한다.

* '''특정 도메인의 기준값과 비교'''
** 도메인 지식이 있는 경우, 해당 산업이나 데이터셋 특성에 따라 '허용 가능한 오차 수준'과 비교한다.
** 예: RMSE가 5인 경우, 부동산 가격 예측에서는 허용되지만, 체온 예측에서는 과도한 오차일 수 있음

==장점==
*예측값과 실제값의 차이를 직관적으로 표현 가능
*단위가 원래 데이터와 같아 성능 해석에 유리함
*다른 모델과의 비교가 용이함
==단점==
*이상치에 민감함 (오차를 제곱하기 때문)
*각 샘플의 중요도가 동일하다고 가정
==활용==
*회귀 문제의 성능 평가 지표
*머신 러닝, 통계 모델, 시계열 분석 등에서 예측 정확도 측정
*하이퍼파라미터 튜닝의 목적 함수로 사용 가능
==같이 보기==
*[[평균 제곱 오차]]
*[[평균 절대 오차]]
*[[평균 절대 백분율 오차]]
*[[모델 평가]]
*[[회귀 분석]]
==참고 문헌==
*Géron, A. (2019). Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow. O'Reilly Media.
*Hyndman, R. J., & Athanasopoulos, G. (2018). Forecasting: Principles and Practice.
[[분류:인공지능]]

평균 제곱근 오차

2025-04-09T00:34:06Z

빅데이터분석기사: 새 문서: 평균 제곱근 오차(RMSE, Root Mean Squared Error)는 회귀 분석에서 예측값과 실제값 간의 차이를 측정하는 대표적인 평가 지표이다. 오차(Residual)의 제곱 평균에 루트를 씌운 값으로, 단위가 원래 데이터와 동일하여 해석이 직관적이다. ==정의== 평균 제곱근 오차는 다음 수식으로 정의된다. RMSE = sqrt( (1/n) * Σ (yi - ŷi)² ) 여기서, *<big>yi: 실제값</big>...

아파치 스파크 RFormula

2025-04-09T00:30:35Z

빅데이터분석기사:

RFormula는 Apache Spark MLlib에서 제공하는 피처 엔지니어링 도구로, R 언어의 공식(formula) 문법을 사용하여 특성과 레이블을 자동으로 정의하고 전처리 과정을 단순화하는 기능을 제공한다. 이 기능은 범주형 변수 인코딩, 수치형 변수 선택, 다항식 식별 등을 간결한 구문으로 수행할 수 있어, 모델링 파이프라인 구성 시 유용하다.
==개요==
RFormula는 `"label ~ features"` 형식의 문자열 수식을 기반으로 입력 컬럼을 분석하고, 내부적으로 다음 작업을 수행한다.
*범주형 변수는 자동으로 StringIndexer + OneHotEncoder로 변환
*수치형 변수는 그대로 사용
*지정된 레이블은 숫자형 인코딩 처리
*결과로 `"features"` 벡터 컬럼과 `"label"` 숫자형 컬럼 생성
==문법 구조==
*`"y ~ x1 + x2 + x3"`
**레이블 `y`, 피처는 `x1`, `x2`, `x3`
*`"y ~ ."`
**레이블 `y`, 나머지 모든 컬럼을 피처로 사용
*`"y ~ x1 + x2 - x3"`
**`x3`은 피처에서 제외
*`"y ~ x1:x2"`
**상호작용(interaction) 항(term) 포함
==예시==
<syntaxhighlight lang="python">
from pyspark.ml.feature import RFormula
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("RFormulaExample").getOrCreate()

df = spark.createDataFrame([
(1, "M", 20.0),
(0, "F", 25.0),
(1, "F", 22.0)
], ["label", "gender", "age"])

formula = RFormula(formula="label ~ gender + age")
model = formula.fit(df)
output = model.transform(df)
output.select("features", "label").show()
</syntaxhighlight>
===출력 예시===
{| class="wikitable"
!features!!label
|-
|[1.0,20.0]||1.0
|-
|[0.0,25.0]||0.0
|-
|[0.0,22.0]||1.0
|}
==장점==
*복잡한 피처 엔지니어링 단계를 간결하게 표현 가능
*자동으로 StringIndexer 및 OneHotEncoder 적용
*DataFrame 기반 파이프라인에 쉽게 통합 가능
*R 사용자에게 익숙한 공식 문법
==단점==
*수식 표현이 간단하지만, 세부 조정은 어려움
*자동 인코딩 결과를 세밀하게 제어하려면 별도 Transformer 사용 필요
==활용 시 주의==
*입력 DataFrame의 컬럼 타입에 따라 자동 처리 방식이 달라짐
*기존의 `features` 또는 `label` 컬럼이 있다면 덮어쓸 수 있음
==같이 보기==
*[[StringIndexer]]
*[[One-hot encoding]]
*[[VectorAssembler]]
*[[아파치 스파크 머신 러닝 파이프라인]]
*[[피처 엔지니어링]]
==참고 문헌==
*Apache Spark MLlib 공식 문서: https://spark.apache.org/docs/latest/ml-features.html#rformula
*Karau, H., & Warren, R. (2017). High Performance Spark. O'Reilly Media.
[[분류:아파치 스파크]]
[[분류:분산 컴퓨팅]]
[[분류:인공지능]]

아파치 스파크 RFormula

2025-04-09T00:30:15Z

빅데이터분석기사: 새 문서: RFormula는 Apache Spark MLlib에서 제공하는 피처 엔지니어링 도구로, R 언어의 공식(formula) 문법을 사용하여 특성과 레이블을 자동으로 정의하고 전처리 과정을 단순화하는 기능을 제공한다. 이 기능은 범주형 변수 인코딩, 수치형 변수 선택, 다항식 식별 등을 간결한 구문으로 수행할 수 있어, 모델링 파이프라인 구성 시 유용하다. ==개요== RFormula는 `"label ~ features"` 형식...

아파치 스파크 StringIndexer

2025-04-09T00:28:35Z

빅데이터분석기사: 새 문서: StringIndexer는 Apache Spark MLlib에서 제공하는 범주형 문자열 데이터를 수치형 인덱스로 변환하는 변환기(Transformer)이다. 머신 러닝 알고리즘은 일반적으로 숫자형 입력을 필요로 하므로, 문자열로 표현된 범주형 변수를 정수형 인덱스로 매핑하는 데 사용된다. ==개요== StringIndexer는 입력 열(input column)에 포함된 고유한 문자열 레이블을 빈도 또는 알파벳 순에 따라 정수...

StringIndexer는 Apache Spark MLlib에서 제공하는 범주형 문자열 데이터를 수치형 인덱스로 변환하는 변환기(Transformer)이다. 머신 러닝 알고리즘은 일반적으로 숫자형 입력을 필요로 하므로, 문자열로 표현된 범주형 변수를 정수형 인덱스로 매핑하는 데 사용된다.
==개요==
StringIndexer는 입력 열(input column)에 포함된 고유한 문자열 레이블을 빈도 또는 알파벳 순에 따라 정수 인덱스로 변환한다. 결과는 새 열(output column)에 저장된다. 이 작업은 머신 러닝 파이프라인에서 전처리 단계로 자주 사용되며, 이후 원-핫 인코딩과 함께 사용되기도 한다.
==동작 방식==
*가장 많이 등장하는 범주에 낮은 인덱스(보통 0)를 부여
*같은 빈도일 경우, 알파벳 순으로 우선순위 결정
*새로운 데이터에 대해 fit된 인덱싱 모델을 transform 단계에서 재사용 가능
==주요 파라미터==
*inputCol: 변환할 열 이름
*outputCol: 결과가 저장될 열 이름
*handleInvalid: 'skip', 'error' (기본값), 'keep' 중 선택
**학습 시 보지 못한 범주가 나왔을 경우 처리 방식 지정
==예시==
<syntaxhighlight lang="python">
from pyspark.ml.feature import StringIndexer
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("StringIndexerExample").getOrCreate()

data = spark.createDataFrame([
(0, "사과"),
(1, "바나나"),
(2, "사과"),
(3, "포도")
], ["id", "fruit"])

indexer = StringIndexer(inputCol="fruit", outputCol="fruitIndex")
model = indexer.fit(data)
indexed = model.transform(data)
indexed.show()
</syntaxhighlight>
===출력 예시===
{| class="wikitable"
!id!!fruit!!fruitIndex
|-
|0||사과||0.0
|-
|1||바나나||2.0
|-
|2||사과||0.0
|-
|3||포도||1.0
|}
==StringIndexerModel 저장 및 로드==
<syntaxhighlight lang="python">
model.save("/path/to/model")
from pyspark.ml.feature import StringIndexerModel
loaded_model = StringIndexerModel.load("/path/to/model")
</syntaxhighlight>
==StringIndexer와 OneHotEncoder 결합==
StringIndexer로 인덱싱한 결과를 OneHotEncoder에 연결하여 원-핫 인코딩을 수행할 수 있다.<syntaxhighlight lang="python">
from pyspark.ml.feature import OneHotEncoder
from pyspark.ml import Pipeline

encoder = OneHotEncoder(inputCols=["fruitIndex"], outputCols=["fruitVec"])
pipeline = Pipeline(stages=[indexer, encoder])
model = pipeline.fit(data)
encoded = model.transform(data)
encoded.select("fruit", "fruitIndex", "fruitVec").show()
</syntaxhighlight>
==장점==
*범주형 문자열 데이터를 머신 러닝에 적합한 수치형으로 변환 가능
*파이프라인과 쉽게 통합
*모델 직렬화 및 배포 가능
==단점==
*숫자 인덱스가 순서를 의미하지 않음에도, 일부 알고리즘이 이를 순서로 해석할 수 있음
*새로운 범주가 등장할 경우 별도 처리 필요 (`handleInvalid` 옵션 활용)
==같이 보기==
*[[아파치 스파크 머신 러닝 파이프라인]]
*[[One-hot encoding]]
*[[pyspark.ml.feature]]
*[[피처 엔지니어링]]
==참고 문헌==
*Apache Spark MLlib 공식 문서: https://spark.apache.org/docs/latest/ml-features.html#stringindexer
*Karau, H., & Warren, R. (2017). High Performance Spark. O'Reilly Media.
[[분류:분산 컴퓨팅]]
[[분류:아파치 스파크]]
[[분류:인공지능]]

아파치 스파크 머신 러닝 파이프라인

2025-04-09T00:22:16Z

빅데이터분석기사:

아파치 스파크 머신 러닝 파이프라인(Spark ML Pipeline)은 Apache Spark의 머신 러닝 라이브러리인 MLlib에서 제공하는 고수준 API로, 데이터 전처리부터 모델 학습, 평가, 예측에 이르기까지 전체 머신 러닝 흐름을 구조화된 방식으로 구성할 수 있도록 지원한다. 파이프라인은 대규모 분산 처리 환경에서 확장성과 재현성을 높이기 위해 설계되었다.
==개요==
스파크 머신 러닝 파이프라인은 여러 처리 단계를 연결하여 순차적으로 실행할 수 있는 구조로, 각 단계는 변환기(Transformer) 또는 추정기(Estimator) 객체로 구성된다. 학습이 완료되면 전체 파이프라인이 하나의 모델(PipelineModel)로 저장되며, 동일한 방식으로 새로운 데이터에 적용할 수 있다.
==주요 구성 요소==
*DataFrame
**Spark ML 파이프라인은 입력 데이터로 DataFrame을 사용한다. 이 DataFrame은 구조화된 테이블 형태이며, 스키마를 포함한다.

*Transformer
**입력 DataFrame을 다른 DataFrame으로 변환하는 객체
**예: Tokenizer, VectorAssembler, StandardScaler, 학습 완료된 모델

*Estimator
**Transformer를 생성할 수 있는 객체. .fit() 메서드를 통해 학습하고 Transformer를 반환한다.
**예: LogisticRegression, DecisionTreeClassifier

*Pipeline
**여러 개의 Transformer와 Estimator를 순서대로 연결한 구조

*PipelineModel
**학습이 완료된 Pipeline 인스턴스. .transform()을 통해 예측 및 처리 수행 가능
==예제==
아래는 간단한 텍스트 분류 파이프라인 구성 예시이다.<syntaxhighlight lang="python">
from pyspark.ml import Pipeline
from pyspark.ml.feature import Tokenizer, HashingTF
from pyspark.ml.classification import LogisticRegression

# 단계별 구성
tokenizer = Tokenizer(inputCol="text", outputCol="words")
hashingTF = HashingTF(inputCol="words", outputCol="features")
lr = LogisticRegression(maxIter=10, regParam=0.001)

# 파이프라인 구성
pipeline = Pipeline(stages=[tokenizer, hashingTF, lr])

# 학습 데이터
training = spark.createDataFrame([
(0, "spark is great"),
(1, "hadoop is old"),
(0, "spark is fast"),
(1, "mapreduce is slow")
], ["label", "text"])

# 파이프라인 학습
model = pipeline.fit(training)

# 테스트 데이터 예측
test = spark.createDataFrame([
(0, "spark wins again"),
(1, "hadoop struggles")
], ["label", "text"])

predictions = model.transform(test)
predictions.select("text", "prediction").show()
</syntaxhighlight>
==장점==
*분산 환경에서 대규모 데이터 처리 가능
*파이프라인 구조로 전처리, 학습, 예측 단계를 일관성 있게 정의
*모델과 파이프라인을 직렬화하여 저장 및 재사용 가능
*CrossValidator, TrainValidationSplit 등과 통합 가능
==단점==
*scikit-learn보다 낮은 수준의 유연성
*MLlib API가 아직 일부 알고리즘에 한정적일 수 있음
==관련 모듈==
*pyspark.ml.feature – 전처리용 Transformer 제공
*pyspark.ml.classification – 분류 모델
*pyspark.ml.regression – 회귀 모델
*pyspark.ml.tuning – 교차 검증, 하이퍼파라미터 튜닝
*pyspark.ml.evaluation – 평가 메트릭 제공
==같이 보기==
*[[Apache Spark]]
*[[Spark MLlib]]
*[[머신 러닝 파이프라인]]
*[[Spark DataFrame]]
*[[모델 평가]]
*[[하이퍼파라미터 튜닝]]
==참고 문헌==
*Apache Spark MLlib 공식 문서: https://spark.apache.org/docs/latest/ml-guide.html
*Karau, H., Konwinski, A., Wendell, P., & Zaharia, M. (2015). Learning Spark. O'Reilly Media.
[[분류:분산 컴퓨팅]]
[[분류:아파치 스파크]]
[[분류:인공지능]]

아파치 스파크 머신 러닝 파이프라인

2025-04-09T00:21:43Z

빅데이터분석기사:

아파치 스파크 머신 러닝 파이프라인(Spark ML Pipeline)은 Apache Spark의 머신 러닝 라이브러리인 MLlib에서 제공하는 고수준 API로, 데이터 전처리부터 모델 학습, 평가, 예측에 이르기까지 전체 머신 러닝 흐름을 구조화된 방식으로 구성할 수 있도록 지원한다. 파이프라인은 대규모 분산 처리 환경에서 확장성과 재현성을 높이기 위해 설계되었다.
==개요==
스파크 머신 러닝 파이프라인은 여러 처리 단계를 연결하여 순차적으로 실행할 수 있는 구조로, 각 단계는 변환기(Transformer) 또는 추정기(Estimator) 객체로 구성된다. 학습이 완료되면 전체 파이프라인이 하나의 모델(PipelineModel)로 저장되며, 동일한 방식으로 새로운 데이터에 적용할 수 있다.
==주요 구성 요소==
*DataFrame
**Spark ML 파이프라인은 입력 데이터로 DataFrame을 사용한다. 이 DataFrame은 구조화된 테이블 형태이며, 스키마를 포함한다.

*Transformer
**입력 DataFrame을 다른 DataFrame으로 변환하는 객체
**예: `Tokenizer`, `VectorAssembler`, `StandardScaler`, 학습 완료된 모델

*Estimator
**Transformer를 생성할 수 있는 객체. `.fit()` 메서드를 통해 학습하고 Transformer를 반환한다.
**예: `LogisticRegression`, `DecisionTreeClassifier`

*Pipeline
**여러 개의 Transformer와 Estimator를 순서대로 연결한 구조

*PipelineModel
**학습이 완료된 Pipeline 인스턴스. `.transform()`을 통해 예측 및 처리 수행 가능
==예제==
아래는 간단한 텍스트 분류 파이프라인 구성 예시이다.<syntaxhighlight lang="python">
from pyspark.ml import Pipeline
from pyspark.ml.feature import Tokenizer, HashingTF
from pyspark.ml.classification import LogisticRegression

# 단계별 구성
tokenizer = Tokenizer(inputCol="text", outputCol="words")
hashingTF = HashingTF(inputCol="words", outputCol="features")
lr = LogisticRegression(maxIter=10, regParam=0.001)

# 파이프라인 구성
pipeline = Pipeline(stages=[tokenizer, hashingTF, lr])

# 학습 데이터
training = spark.createDataFrame([
(0, "spark is great"),
(1, "hadoop is old"),
(0, "spark is fast"),
(1, "mapreduce is slow")
], ["label", "text"])

# 파이프라인 학습
model = pipeline.fit(training)

# 테스트 데이터 예측
test = spark.createDataFrame([
(0, "spark wins again"),
(1, "hadoop struggles")
], ["label", "text"])

predictions = model.transform(test)
predictions.select("text", "prediction").show()
</syntaxhighlight>
==장점==
*분산 환경에서 대규모 데이터 처리 가능
*파이프라인 구조로 전처리, 학습, 예측 단계를 일관성 있게 정의
*모델과 파이프라인을 직렬화하여 저장 및 재사용 가능
*`CrossValidator`, `TrainValidationSplit` 등과 통합 가능
==단점==
*scikit-learn보다 낮은 수준의 유연성
*MLlib API가 아직 일부 알고리즘에 한정적일 수 있음
==관련 모듈==
*`pyspark.ml.feature` – 전처리용 Transformer 제공
*`pyspark.ml.classification` – 분류 모델
*`pyspark.ml.regression` – 회귀 모델
*`pyspark.ml.tuning` – 교차 검증, 하이퍼파라미터 튜닝
*`pyspark.ml.evaluation` – 평가 메트릭 제공
==같이 보기==
*[[Apache Spark]]
*[[Spark MLlib]]
*[[머신 러닝 파이프라인]]
*[[Spark DataFrame]]
*[[모델 평가]]
*[[하이퍼파라미터 튜닝]]
==참고 문헌==
*Apache Spark MLlib 공식 문서: https://spark.apache.org/docs/latest/ml-guide.html
*Karau, H., Konwinski, A., Wendell, P., & Zaharia, M. (2015). Learning Spark. O'Reilly Media.
[[분류:분산 컴퓨팅]]
[[분류:아파치 스파크]]
[[분류:인공지능]]

머신 러닝 파이프라인

2025-04-09T00:21:17Z

빅데이터분석기사:

머신 러닝 파이프라인(Machine Learning Pipeline)은 데이터 전처리부터 모델 학습, 예측, 평가, 배포까지 일련의 과정을 체계적으로 구성한 자동화 흐름이다. 파이프라인을 통해 반복 가능한 작업을 재사용 가능하고 일관성 있게 수행할 수 있으며, 실험 및 배포 환경에서 생산성을 크게 높인다.
==개요==
머신 러닝 파이프라인은 전체 모델링 과정에서 필요한 여러 단계를 순차적으로 연결한 구조이다. 각 단계는 독립적인 처리 블록으로 구성되며, 입력 데이터를 변환하거나 학습, 예측 등의 작업을 수행한다.
==주요 단계==
*데이터 수집 (Data Collection)
**외부 소스(API, DB, 파일 등)로부터 원시 데이터를 수집한다.
*데이터 전처리 (Data Preprocessing)
**결측값 처리, 이상치 제거, 정규화, 인코딩 등 모델 학습에 적합한 형태로 데이터를 가공한다.
*특성 선택 및 추출 (Feature Engineering)
**모델 성능에 영향을 줄 수 있는 유의미한 피처를 선택하거나, 새로 생성한다.
*학습 데이터 분리 (Train-Test Split)
**데이터셋을 학습용(train)과 평가용(test)으로 분할하여 과적합을 방지한다.
*모델 학습 (Model Training)
**머신 러닝 알고리즘에 학습 데이터를 공급하여 모델을 훈련시킨다.
*모델 평가 (Model Evaluation)
**정확도, 정밀도, 재현율, F1-score, RMSE 등 지표로 모델 성능을 측정한다.
*하이퍼파라미터 튜닝 (Hyperparameter Tuning)
**최적의 파라미터 조합을 찾기 위해 Grid Search, Random Search 등을 사용한다.
*모델 저장 및 배포 (Model Deployment)
**학습된 모델을 저장하고 API 형태로 서비스에 통합하거나, 운영 환경에 배포한다.
==시각적 예시==
<syntaxhighlight lang="python">
# 간단한 scikit-learn 파이프라인 예시
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression

pipeline = Pipeline([
('scaler', StandardScaler()),
('classifier', LogisticRegression())
])

pipeline.fit(X_train, y_train)
y_pred = pipeline.predict(X_test)
</syntaxhighlight>
==장점==
*일관성 있는 데이터 흐름 관리
*코드 재사용성 및 유지보수 용이
*실험 반복 및 비교가 쉬움
*운영 환경으로 전환이 용이 (MLOps와 통합 가능)
*데이터 누출(leakage) 방지
==활용 도구==
*scikit-learn
**`Pipeline`, `FeatureUnion` 등을 사용해 전처리와 모델을 연결
*TensorFlow Extended (TFX)
**TensorFlow 기반 파이프라인 구성 및 운영 자동화 도구
*Apache Airflow
**스케줄 기반 워크플로우 관리로 ML 작업 자동화
*MLflow
**실험 추적, 모델 관리, 배포 자동화에 적합
*Kubeflow
**Kubernetes 기반 머신러닝 파이프라인 구축용 플랫폼
==같이 보기==
*[[특성 공학]]
*[[모델 평가]]
*[[하이퍼파라미터]]
*[[MLOps]]
*[[scikit-learn]]
*[[데이터 전처리]]
==참고 문헌==
*Géron, A. (2019). Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow. O'Reilly Media.
*scikit-learn 공식 문서: https://scikit-learn.org/stable/modules/compose.html
*TensorFlow Extended (TFX): https://www.tensorflow.org/tfx
[[분류:인공지능]]

원 핫 인코딩

2025-04-09T00:20:52Z

빅데이터분석기사: 새 문서: 원 핫 인코딩(One-hot encoding)은 범주형(categorical) 데이터를 머신 러닝 알고리즘에서 사용할 수 있도록 수치형 데이터로 변환하는 기법 중 하나이다. 각 범주를 이진 벡터의 고유한 위치에 1로 표시하고, 나머지는 0으로 처리하여 범주 간의 순서 또는 크기 의미를 제거한다. ==개요== 범주형 데이터는 대부분 문자열로 표현되며, 모델 학습에 직접 사용할 수 없다. 이를 해...

원 핫 인코딩(One-hot encoding)은 범주형(categorical) 데이터를 머신 러닝 알고리즘에서 사용할 수 있도록 수치형 데이터로 변환하는 기법 중 하나이다. 각 범주를 이진 벡터의 고유한 위치에 1로 표시하고, 나머지는 0으로 처리하여 범주 간의 순서 또는 크기 의미를 제거한다.
==개요==
범주형 데이터는 대부분 문자열로 표현되며, 모델 학습에 직접 사용할 수 없다. 이를 해결하기 위해 원 핫 인코딩을 적용하면 각 범주는 서로 독립적인 이진 변수로 변환되므로, 범주 간의 잘못된 거리 정보를 피할 수 있다.
*예: '사과', '바나나', '포도' 세 가지 범주가 있을 때
**사과 → [1, 0, 0]
**바나나 → [0, 1, 0]
**포도 → [0, 0, 1]
==특징==
*범주 수만큼 차원이 증가
*범주 간 순서나 우선순위가 포함되지 않음
*희소 행렬(sparse matrix)을 생성함
==구현 예시==
===pandas를 사용한 예시===
<syntaxhighlight lang="python">
import pandas as pd

df = pd.DataFrame({'과일': ['사과', '바나나', '사과', '포도']})
encoded = pd.get_dummies(df['과일'])
print(encoded)
</syntaxhighlight>
===scikit-learn을 사용한 예시===
<syntaxhighlight lang="python">
from sklearn.preprocessing import OneHotEncoder

encoder = OneHotEncoder(sparse=False)
X = [['사과'], ['바나나'], ['사과'], ['포도']]
encoded = encoder.fit_transform(X)
print(encoded)
</syntaxhighlight>
==장점==
*범주형 데이터를 정량적으로 표현 가능
*범주 간 불필요한 순서를 부여하지 않아 모델의 오해를 방지
*대부분의 머신 러닝 모델에서 효율적으로 사용됨
==단점==
*범주의 수가 많을 경우 차원이 급격히 증가 (차원의 저주)
*희소 행렬로 인해 메모리 비효율 발생 가능
*테스트 데이터에 훈련 데이터에 없던 범주가 등장하면 에러 발생 가능
==변형 기법==
*[[Label Encoding]] – 범주를 정수값으로 변환하나, 순서가 부여되어 잘못된 해석 가능
*[[Binary Encoding]] – 차원 수를 줄이기 위해 각 범주를 2진수로 인코딩
*[[Target Encoding]] – 범주의 통계값(예: 평균)을 대신 사용
==같이 보기==
*[[Label Encoding]]
*[[범주형 변수]]
*[[피처 엔지니어링]]
*[[scikit-learn]]
*[[pandas]]
==참고 문헌==
*Géron, A. (2019). Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow. O'Reilly Media.
*scikit-learn 공식 문서: https://scikit-learn.org/stable/modules/generated/sklearn.preprocessing.OneHotEncoder.html
*pandas 공식 문서: https://pandas.pydata.org/docs/reference/api/pandas.get_dummies.html
[[분류:인공지능]]

아파치 스파크 머신 러닝 파이프라인

2025-04-08T23:29:28Z

빅데이터분석기사: 새 문서: 아파치 스파크 머신 러닝 파이프라인(Spark ML Pipeline)은 Apache Spark의 머신 러닝 라이브러리인 MLlib에서 제공하는 고수준 API로, 데이터 전처리부터 모델 학습, 평가, 예측에 이르기까지 전체 머신 러닝 흐름을 구조화된 방식으로 구성할 수 있도록 지원한다. 파이프라인은 대규모 분산 처리 환경에서 확장성과 재현성을 높이기 위해 설계되었다. ==개요== 스파크 머신 러...

아파치 스파크 머신 러닝 파이프라인(Spark ML Pipeline)은 Apache Spark의 머신 러닝 라이브러리인 MLlib에서 제공하는 고수준 API로, 데이터 전처리부터 모델 학습, 평가, 예측에 이르기까지 전체 머신 러닝 흐름을 구조화된 방식으로 구성할 수 있도록 지원한다. 파이프라인은 대규모 분산 처리 환경에서 확장성과 재현성을 높이기 위해 설계되었다.
==개요==
스파크 머신 러닝 파이프라인은 여러 처리 단계를 연결하여 순차적으로 실행할 수 있는 구조로, 각 단계는 변환기(Transformer) 또는 추정기(Estimator) 객체로 구성된다. 학습이 완료되면 전체 파이프라인이 하나의 모델(PipelineModel)로 저장되며, 동일한 방식으로 새로운 데이터에 적용할 수 있다.
==주요 구성 요소==
*DataFrame
**Spark ML 파이프라인은 입력 데이터로 DataFrame을 사용한다. 이 DataFrame은 구조화된 테이블 형태이며, 스키마를 포함한다.

*Transformer
**입력 DataFrame을 다른 DataFrame으로 변환하는 객체
**예: `Tokenizer`, `VectorAssembler`, `StandardScaler`, 학습 완료된 모델

*Estimator
**Transformer를 생성할 수 있는 객체. `.fit()` 메서드를 통해 학습하고 Transformer를 반환한다.
**예: `LogisticRegression`, `DecisionTreeClassifier`

*Pipeline
**여러 개의 Transformer와 Estimator를 순서대로 연결한 구조

*PipelineModel
**학습이 완료된 Pipeline 인스턴스. `.transform()`을 통해 예측 및 처리 수행 가능
==예제==
아래는 간단한 텍스트 분류 파이프라인 구성 예시이다.<syntaxhighlight lang="python">
from pyspark.ml import Pipeline
from pyspark.ml.feature import Tokenizer, HashingTF
from pyspark.ml.classification import LogisticRegression

# 단계별 구성
tokenizer = Tokenizer(inputCol="text", outputCol="words")
hashingTF = HashingTF(inputCol="words", outputCol="features")
lr = LogisticRegression(maxIter=10, regParam=0.001)

# 파이프라인 구성
pipeline = Pipeline(stages=[tokenizer, hashingTF, lr])

# 학습 데이터
training = spark.createDataFrame([
(0, "spark is great"),
(1, "hadoop is old"),
(0, "spark is fast"),
(1, "mapreduce is slow")
], ["label", "text"])

# 파이프라인 학습
model = pipeline.fit(training)

# 테스트 데이터 예측
test = spark.createDataFrame([
(0, "spark wins again"),
(1, "hadoop struggles")
], ["label", "text"])

predictions = model.transform(test)
predictions.select("text", "prediction").show()
</syntaxhighlight>
==장점==
*분산 환경에서 대규모 데이터 처리 가능
*파이프라인 구조로 전처리, 학습, 예측 단계를 일관성 있게 정의
*모델과 파이프라인을 직렬화하여 저장 및 재사용 가능
*`CrossValidator`, `TrainValidationSplit` 등과 통합 가능
==단점==
*scikit-learn보다 낮은 수준의 유연성
*MLlib API가 아직 일부 알고리즘에 한정적일 수 있음
==관련 모듈==
*`pyspark.ml.feature` – 전처리용 Transformer 제공
*`pyspark.ml.classification` – 분류 모델
*`pyspark.ml.regression` – 회귀 모델
*`pyspark.ml.tuning` – 교차 검증, 하이퍼파라미터 튜닝
*`pyspark.ml.evaluation` – 평가 메트릭 제공
==같이 보기==
*[[Apache Spark]]
*[[Spark MLlib]]
*[[머신 러닝 파이프라인]]
*[[Spark DataFrame]]
*[[모델 평가]]
*[[하이퍼파라미터 튜닝]]
==참고 문헌==
*Apache Spark MLlib 공식 문서: https://spark.apache.org/docs/latest/ml-guide.html
*Karau, H., Konwinski, A., Wendell, P., & Zaharia, M. (2015). Learning Spark. O'Reilly Media.
[[분류:인공 지능]]
[[분류:분산 컴퓨팅]]
[[분류:아파치 스파크]]

머신 러닝 파이프라인

2025-04-08T23:27:57Z

빅데이터분석기사: 새 문서: 머신 러닝 파이프라인(Machine Learning Pipeline)은 데이터 전처리부터 모델 학습, 예측, 평가, 배포까지 일련의 과정을 체계적으로 구성한 자동화 흐름이다. 파이프라인을 통해 반복 가능한 작업을 재사용 가능하고 일관성 있게 수행할 수 있으며, 실험 및 배포 환경에서 생산성을 크게 높인다. ==개요== 머신 러닝 파이프라인은 전체 모델링 과정에서 필요한 여러 단계를...

하둡 에코시스템

2025-04-03T21:38:44Z

빅데이터분석기사:

하둡 에코시스템(Hadoop Ecosystem)은 [[아파치 하둡]]을 중심으로 분산 저장과 분산 처리를 수행하는 다양한 오픈소스 도구들과 기술들을 아우르는 개념이다. 하둡은 단순한 분산 파일 시스템과 맵리듀스 처리 엔진에서 시작했지만, 그 위에 다양한 기능을 제공하는 도구들이 결합되며 하나의 '''데이터 처리 플랫폼'''으로 발전했다.
==주요 구성 요소==
하둡 에코시스템은 다음 네 가지 계층으로 구성된다:
===1. 저장(Storage) ===
* '''[[HDFS (Hadoop Distributed File System)]]'''** 하둡의 기본 분산 파일 시스템으로, 대용량 파일을 여러 노드에 분산 저장
*Apache HBase
**HDFS 위에 구축된 분산형 컬럼 기반 NoSQL 데이터베이스
===2. 자원 관리(Resource Management)===* '''[[YARN (Yet Another Resource Negotiator)]]'''
**클러스터 자원 관리 및 작업 스케줄링 담당
**다양한 처리 엔진(Hive, Spark, MapReduce 등)과 통합 가능
===3. 처리 엔진(Processing Frameworks) ===
*'''MapReduce'''** 초기 하둡의 기본 분산 처리 모델, 병렬 배치 처리에 적합
*'''Apache Spark'''
**인메모리 기반 분산 처리 프레임워크, MapReduce보다 빠르고 유연함
* Apache Tez**DAG 기반 고속 처리 엔진, Hive와 함께 사용됨
*Apache Flink
**스트리밍 처리 특화 프레임워크
=== 4. 상위 레벨 도구(High-Level Tools)===
*'''Apache Hive'''** SQL 유사 언어(HiveQL)로 하둡 데이터 처리
* '''Apache Pig'''
**데이터 흐름 기반 처리 언어(Pig Latin)
*'''Apache Sqoop'''
**관계형 DB와 하둡 간 대량 데이터 전송
* '''Apache Flume'''** 로그 및 실시간 데이터 수집 도구
*Apache Oozie
**워크플로우 기반 하둡 작업 스케줄링 도구
==부가 구성 요소==
* '''Apache Zookeeper'''** 분산 환경에서의 동기화, 리더 선출, 설정 관리 등
*Apache Ambari
**하둡 클러스터 설치, 관리, 모니터링 UI
*Apache Knox
**하둡 에코시스템의 보안 게이트웨이 역할 수행
*Apache Ranger
**세분화된 권한 제어 및 감사 로깅

== 구성도 ==
┌────────────────────────────┐
│ User Interface │
│ (Hue, [[아파치 제플린|Zeppelin]]) │
└────────────┬───────────────┘
│
┌──────────────────▼────────────────────┐
│ Processing / Compute Layer │
│ (MapReduce, Spark, Tez, Flink, Storm)│
└──────────────────┬────────────────────┘
│
┌──────────────────▼────────────────────┐
│ Resource Management Layer │
│ (YARN, Mesos) │
└──────────────────┬────────────────────┘
│
┌──────────────────▼────────────────────┐
│ Storage Layer (HDFS, HBase) │
│ + External: S3, Cassandra, Alluxio │
└──────────────────┬────────────────────┘
│
┌──────────────────▼────────────────────┐
│ Data Ingestion / ETL Layer │
│ (Flume, Sqoop, Kafka, NiFi, Oozie) │
└──────────────────┬────────────────────┘
│
┌──────────────────▼────────────────────┐
│ Metadata / Coordination Layer │
│ (ZooKeeper, Atlas, Ranger) │
└───────────────────────────────────────┘

== 특징==
*대규모 데이터 저장 및 분석을 위한 확장 가능한 아키텍처
*다양한 데이터 유형(정형/비정형)과 처리 방식(배치/스트리밍)에 대응
* 오픈소스 기반 → 기업 환경에 맞게 커스터마이징 가능
== 활용 분야==
*로그 분석, 클릭스트림 분석
*머신러닝 파이프라인 구축
*데이터 웨어하우징
*IoT 및 센서 데이터 수집 및 처리
==같이 보기==
*[[아파치 하둡]]
*[[HDFS (Hadoop Distributed File System)]]
*[[YARN (Yet Another Resource Negotiator)]]
*[[Apache Hive]]
*[[Apache Spark]]
*[[Apache Zookeeper]]
==참고 문헌==
*Tom White, "Hadoop: The Definitive Guide", O'Reilly
*The Apache Software Foundation: https://hadoop.apache.org/
*Cloudera, Hortonworks, MapR 등 하둡 배포판 문서

하둡 에코시스템

2025-04-03T21:36:14Z

빅데이터분석기사: 새 문서: ┌────────────────────────────┐ │ User Interface │ │ (Hue, Zeppelin) │ └────────────┬───────────────┘ │ ┌──────────────────▼─...

┌────────────────────────────┐
│ User Interface │
│ (Hue, [[아파치 제플린|Zeppelin]]) │
└────────────┬───────────────┘
│
┌──────────────────▼────────────────────┐
│ Processing / Compute Layer │
│ (MapReduce, Spark, Tez, Flink, Storm)│
└──────────────────┬────────────────────┘
│
┌──────────────────▼────────────────────┐
│ Resource Management Layer │
│ (YARN, Mesos) │
└──────────────────┬────────────────────┘
│
┌──────────────────▼────────────────────┐
│ Storage Layer (HDFS, HBase) │
│ + External: S3, Cassandra, Alluxio │
└──────────────────┬────────────────────┘
│
┌──────────────────▼────────────────────┐
│ Data Ingestion / ETL Layer │
│ (Flume, Sqoop, Kafka, NiFi, Oozie) │
└──────────────────┬────────────────────┘
│
┌──────────────────▼────────────────────┐
│ Metadata / Coordination Layer │
│ (ZooKeeper, Atlas, Ranger) │
└───────────────────────────────────────┘

아파치 주키퍼 znode

2025-04-03T21:24:44Z

빅데이터분석기사: 새 문서: znode는 아파치 주키퍼에서 사용되는 데이터 단위이자 노드로, 주키퍼의 트리 구조 네임스페이스를 구성하는 핵심 요소이다. 각각의 znode는 파일 시스템의 디렉토리나 파일처럼 취급되며, 데이터와 메타데이터를 포함할 수 있다. 클라이언트는 znode를 통해 정보를 저장하거나, 상태 변화를 감지하거나, 노드 간 동기화를 구현할 수 있다. ==개념== *znode는 주키퍼의...

znode는 [[아파치 주키퍼]]에서 사용되는 데이터 단위이자 노드로, 주키퍼의 트리 구조 네임스페이스를 구성하는 핵심 요소이다. 각각의 znode는 파일 시스템의 디렉토리나 파일처럼 취급되며, 데이터와 메타데이터를 포함할 수 있다. 클라이언트는 znode를 통해 정보를 저장하거나, 상태 변화를 감지하거나, 노드 간 동기화를 구현할 수 있다.
==개념==
*znode는 주키퍼의 경로(path)를 구성하는 각 지점이며, 예: `/app/servers/server1`
*각 znode는 최대 1MB 크기의 데이터를 저장할 수 있음
*znode는 자식 노드를 가질 수 있으며, 이를 통해 계층적 트리 구조를 형성함
*메타데이터에는 버전, 생성 시간, 자식 수, ACL(Access Control List) 등이 포함됨
==znode의 종류==
#'''영속 노드(Persistent znode)'''
#*명시적으로 삭제되지 않는 한 유지됨
#*서비스 설정, 공유 상태 저장 등 지속적인 정보에 사용

#'''임시 노드(Ephemeral znode)'''
#*znode를 생성한 클라이언트 세션이 종료되면 자동 삭제됨
#*리더 선출, 세션 감지, 임시 등록 등에 사용

#'''시퀀스 노드(Sequential znode)'''
#*znode 생성 시 고유한 숫자가 자동으로 뒤에 붙음
#*'''영속 시퀀스''' 또는 '''임시 시퀀스'''로 생성 가능
#*예: `/queue/task-000000001`, `/queue/task-000000002`
==znode의 기능==
*'''데이터 저장''': 클라이언트가 znode에 문자열 또는 바이트 배열을 저장
*'''노드 감시(Watch)''': 특정 znode의 생성, 삭제, 변경 등을 클라이언트가 감시 가능
*'''노드 삭제''': 클라이언트는 권한이 있을 경우 znode를 삭제 가능
*'''ACL 설정''': 각 znode마다 접근 권한 설정 가능 (읽기/쓰기 등)
==사용 예시==
*`/services/web/instance1` → 웹 서비스 인스턴스 등록 (임시 znode)
*`/config/database/url` → 구성 설정 저장 (영속 znode)
*`/election/candidate0000000003` → 리더 선출 대기열 (시퀀스 znode)
==제약 사항==
*하나의 znode는 1MB를 넘는 데이터를 저장할 수 없음
*임시 znode는 자식 노드를 가질 수 없음
*동일 경로에 중복된 znode 생성 불가
==같이 보기==
*[[아파치 주키퍼]]
*[[분산 락]]
*[[리더 선출]]
*[[분산 시스템]]
==참고 문헌==
*Apache ZooKeeper 공식 문서: https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html
*"ZooKeeper: Wait-free coordination for internet-scale systems" – Hunt et al. (2010), USENIX ATC
[[분류:분산 컴퓨팅]]