20250526 15주차 1일째 TIL

오랜만에 TIL.

 

이제 다시 달려보자.

 

 

스파크를 피하는 방법

1. 샘플링
   • 전체 데이터가 많다면 일부씩 하면 됨
     • Random 샘플링 - 표본이 우연히 편향될 수 있고, 매번 결과가 달라짐.
     • Stratified 샘플링 - 특정 집단으로 편향을 줄이기 위한 층화추출 > 매번 결과가 달라진다는 문제는 그대로 있음.
     • Systematic 샘플링 - 아이디와 같이 패턴이 없거나 순서의 영향을 받지 않는 컬럼을 기준으로 함.
       • ID는 가입 순서이기 때문에 초기 가입 유저와 최근 가입 유저의 성질이 다르기 때문에, 영향을 미칠만한 차이는 보통 없음. > 하지만 패턴이 있는지 검사해보는 것이 좋음
       • 건너뛰는 단위는 소수를 사용하는 것이 특정 패턴을 피하기에 좋음.
2. 분할 처리
   • 샘플링과 궁합이 좋은 방법론으로 데이터가 완벽히 분할되는 경우, 10%씩 10번 작업하면 된다는 것임. > 소셜 네트워크와 같은 그래프 데이터는 분할이 어려움.
   • 데이터 분할 설계하기
     • 메모리에 여유를 줘서 데이터를 분할.
   • 집계 데이터 저장
     • 각 파티션의 데이터를 불러와, 필요한 연산을 수행한 뒤 최종 결과만을 집계하여 저장 > 다만 최종 집계결과만 남기는 것보다 중간 계산 과정을 남겨서 검산이 가능함.
3. Progress 관리하기 - Supervisord
   • Supervisord
     • 비주기적으로 죽는 프로세스를 반복적으로 부활시켜 운영할 때 유용
     • 특정 배치 스크립트(ex. python3 main.py)를 실행하고, 해당 스크립트가 죽을 때 마다 다시 실행
4. DASK 사용
   • 분산 처리 도구이지만, 스파크보다 비교적 가볍게 사용 가능.
   • 중간 규모 데이터에 자주 사용(1~100GB).
   • 싱글 머신으로 큰 파일을 읽을 때 유용.
5. 회피기 패시브 - 자동화
   • 스파크를 쓸 때도 주기적인 데이터 처리를 위해 스케쥴링 하는 경우가 많음.
   • Batch vs Streaming
     • 주기적인 대규모 데이터에 대한 처리를 Batch Job이라고 함.
     • 실시간으로 발생하는 데이터에 대한 처리를 Streaming job이라고 함
     • 데이터 분석가는 일반적으로 전자를 수행하는 경우가 많고, 자동화 역량이 필요한 경우도 많음.
   • 스케줄링과 Cron
     • 소프트웨어 이름임과 동시에 스케줄링 표현식의 이름.
     • job이 실패할 경우 알람이 오지 않고 따로 알람 세팅해도 OOM으로 프로세스가 죽으면 레포팅이 안됨.
     • 서버 자체가 죽으면 확인이 어렵고, 로그를 제외하면 히스토리 파악이 어려움.
     • GUI를 따로 제공하지 않고, 로드 밸런싱을 포함한 자원 관리를 지원하지 않아, Airflow나 Jenkins를 많이 사용.
   • 모니터링과 히스토리 관리
     • 주기적인 Batch Job을 설정하면 의도대로 수행하지 않았을 때 알람이 오는 것이 좋은데, 이를 모니터링이라 하며 슬랙 등의 메신저로 수신.
     • 손쉬운 모니터링 도구를 지원하는 툴이 대부분이지만, 수동으로 설정하는 것도 어렵지는 않음.
     • 완료된 job들이 언제 어떻게 수행되었는지 logging을 이용하여 알 수 있음.

지피티와 함께 공부하기

파이썬의 Garbage Collection

• 파이썬같은 동적 메모리 할당 언어에서 참조되지 않으면 메모리를 자동으로 회수하는 기능
• 방식
  • 참조 카운트 - 객체가 몇 개의 변수에 의해 참조되는지 카운팅하면서 숫자가 0이 되면 메모리에서 제거
  • 순환 참조 감지 - 리스트나 객체가 서로 참조하며 루프를 형성할 경우, 참조 카운트로는 제거가 되지 않기 떄문에 GC 모듈이 주기적으로 검사해서 순환 참조를 제거.
  • 직접 제어하기 ㄴ 1. 순환 참조가 의심되는데 메모리가 줄지 않을 때 ㄴ 2. 메모리 사용량을 정밀하게 측정하거나 디버깅할 때 ㄴ 3. 메모리 최적화가 중요한 서버나 대용량 처리 코드에서 일시적으로 GC 타이밍을 조절하고 싶을 때함수설명

    gc.collect()	수동으로 GC 실행
    gc.get_count()	세대별 객체 수 확인
    gc.get_threshold()	GC가 실행되는 기준값 조회
    gc.set_threshold(x, y, z)	GC 실행 기준값 설정 (세대별)
    gc.disable() / gc.enable()	자동 GC 끄기/켜기
    gc.get_objects()	현재 추적 중인 모든 객체 리스트 반환

  • 🔸 자주 쓰는 함수

넘파이와 벡터라이즈

• 반복문을 사용하지 않고 배열 단위로 연산하여 성능을 높이는 방식.
• import numpy as np import time x = np.arange(1_000_000) # 루프 방식 start = time.time() y1 = [i ** 2 for i in x] print("루프:", time.time() - start) # 벡터라이즈 방식 start = time.time() y2 = x ** 2 print("벡터라이즈:", time.time() - start)
• np.vectorize()라는 함수도 있으나, 단순히 적용을 벡터처럼 하는 것 뿐이고 성능최적화 방식은 아님.

Pickling과 Job broker - 스파크만의 방식이 아닌 분산 컴퓨팅 프레임워크에서 사용

• Pickling
  • 파이썬 객체를 직렬화하는 방법.
    • 직렬화 - 파이썬의 객체 정보를 다른 컴퓨터에서도 작동하면서, 네트워크상으로 전송할 수 있는 포맷으로 변환하는 과정
  • 특징
    • 제한 - 파일 핸들, 소켓, 스레드같은 직렬화 불가능한 객체는 안됨. > 잡브로커를 활용하여 간접적으로 접근이 가능.(pd.to_csv()같은 기능을 사용할 수 있으나, 이는 노드 자체 설정을 통해 허용 여부를 설정 가능)
    • 보안 - 신뢰할 수 없는 데이터에 대한 보안 취약점이 존재
    • 속도 - pickle이나 cloudpickle이 빠름.
  • 동작 과정
    • 객체 > 바이트 스트림으로 변환(파이썬 객체를 피클링) - 이것이 직렬화
    • 전송/저장 > 바이트 스트림을 네트워크로 전송하거나 파일로 저장
    • 바이트 스트림 > 객체 : 수신 측에서 역피클링(역직렬화)해서 원래 객체 복원
  • 스파크에서 주로 사용하는 직렬화 방식
    • JAVA 직렬화 방식을 사용.
    • 성능 향상을 위해서는 Kryo 직렬화 라이브러리를 많이 사용하고, PySpark에서는 피클링 방식을 사용.
• Job Broker(스파크에만 있는 개념이 아님!! )
  • 분산 컴퓨팅 환경에서 작업을 관리하고 분배하는 중개자 역할
  • 작업을 클러스터 내 워커 노드에 효율적으로 배포하고 실행되도록 조율하는 시스템
  • 주로 하는 역할
    • 작업 스케쥴링 - 클러스터의 가용 자원에 맞게 작업 실행 시점과 위치 결정
    • 작업 큐 관리 - 대기 중인 작업을 관리하며 우선순위에 따라 작업 실행 순서 조절
    • 작업 할당 및 배포 - 적절한 워커 노드에 작업을 할당하고 실행환경(라이브러리, 데이터 등)을 준비
    • 상태 모니터링 및 관리 - 작업 진행 상태(성공, 실패, 재시도 등)를 모니터링하고, 오류 발생 시 복구 처리
    • 결과 집계 및 반환 - 워커 노드에서 처리한 결과를 수집해 사용자에게 전달
  • 스파크에서의 잡 브로커와 관련 역할을 맡은 컴포넌트
    • 드라이버 - 애플리케이션 실행의 중심으로 작업을 나누고, 스케쥴러에게 전달
    • 스케쥴러 - DAG(Directed Acyclic Graph)를 기반으로 작업 단위를 분할하고, 실행 계획 수립
      • DAG - 방향이 있는 비순환 그래프로 노드들이 방향성을 가진 간선으로 연결되어 있으나, 사이클(순환)이 없는 구조를 뜻함. 스파크에서는 작업의 실행 계획을 나타내는 그래프로, 데이터 처리 단계들(노드)이 순서대로 진행되며, 한번 처리된 단계가 다시 돌아가지 않음. > 작업들이 서로 영향을 주지만, 한 방향으로 흘러가면서 작업 의존성과 실행 순서를 표현하는 개념.
    • 클러스터 매니저 - YARN, Mesos, Kubernates, Standalone 같은 외부 자원 관리 시스템과 연동하여 리소스 할당
    • 실행기 - 워커 노드에서 실제 작업(태스크)를 실행하는 프로세스
  • 스파크에서 주로 사용되는 주요 클러스터 매니저
    • YARN
      • 하둡 에코시스템과 긴밀하게 통합되어, 하둡한경에 최적화되어 있음. 리소스 관리, 스케줄링이 안정적이나 비하둡 환경에선 무거울 수 있음
    • Mesos
      • 범용 클러스터 매니저로 다양한 프레임워크를 지원하며, 자원 할당이 유연하여 멀티 테넌시 지원됨. 대규모 클라우드 데이터센터, 다양한 워크로드 관리를 할 수 있지만, 복잡한 설정과 운영이 필요함.
        • 멀티 테넌시(Multi-tenancy)
          • 한 대의 서버나 클러스터가 여러 사용자의 작업을 동시에 안전하고 독립적으로 처리하는 능력으로 하나의 클러스터를 여러 사용자가 쓸 때, 서로의 작업이나 데이터에 간섭하지않고 격리된 상태로 운영하는 것
    • Kubernated(K8S)
      • 컨테이너 오케스트레이션에 최적화. 스파크 컨테이너화가 가능하며, 자동 스케일링, 자원 관리가 강력함. 클라우드 네이티브, 마이크로서비스 환경에 최적화되어 있으나, 초기 학습 곡선이 있고, 네이티브 클러스터 매니저는 아니지만 널리 채택됨.
        • 컨테이너(Container)
          • 애플리케이션과 그 실행에 필요한 라이브러리, 설정 등을 묶어 가볍게 격리해서 실행하는 기술(Docker)
        • 오케스트레이션(Orchestration)
          • 여러 컨테이너를 대규모로 관리하고 자동 배포, 확장, 복구 등을 자동으로 수행하는 시스템
        • 컨테이너 오케스트레이션
          • 여러 대의 서버에 분산된 컨테이너를 체계적으로 관리하는 것을 의미.
        • 워크로드 관리
          • 컴퓨팅 자원을 여러 작업이 효율적이고 공정하게 사용할 수 있도록 스케줄링, 배분, 모니터링 하는 것을 의미. 배치 작업, 실시간처리, 머신러닝 모델 학습 등이 포함됨.
    • Standalone 모드
      • 별도의 외부 클러스터 매니저 없이 스파크 자체적으로 클러스터 관리가 되며, 소규모 또는 개발환경에서 간단히 사용할 수 있고, 설치 및 설정이 쉬움.
  • Airflow에서 주로 사용되는 Job Broker
    • Celery - 분산작업 큐 시스템을 구현하기 위한 프레임워크
    • RabbitMQ - 메시지 브로커 중 하나로 작업 메시지를 큐에 전달하고 관리하는 역할
    • Celery가 작업들을 분배하기 위해 메시지 브로커가 필요한데, RabbitMQ 혹은 Redis를 메시지 브로커로 쓰면서 잡 브로커 역할을 진행.
      • Redis(Remote Dictionary Server) - dlsapahfl zl-rkqt wjwkdth
        • 데이터를 메모리에 사용해서 빠르고, 딕셔너리처럼 key에 해당하는 값을 저장, 스냅샷이나 AOF(Append Only File)로 디스크에 저장 가능하며, 단일 스레드로 동작하지만 빠름
        • 활용 예시들
          • 캐시 - DB 쿼리 결과를 잠깐 저장해서 성능 향상
          • 세션 저장소 - 웹 로그인 세션 정보를 저장
          • Pub/Sub - 메시지 발행/구독 시스템으로 사용(비동기 이벤트 처리 등)
          • 작업 큐(브로커) - 분산시스템에서 Job 브로커로 사용
          • 실시간 통계 - 빠른 read/write 덕분에 실시간 데이터 수집에 유리
          • 락 처리 - 분산 락 시스템 구현 가능(SETNX 등 이용)
• 스파크 내에서 메모리가 부족할 때 작동하는 방식.
  • 스필링 - 일부 데이터를 디스크에 임시저장하여 메모리를 확보 > 디스크에 저장하면서 순간적으로 느려질 수 있음.
  • 가비지 컬렉션 최적화 - JVM의 가비지 컬렉션이 작동하여 메모리 해제를 시도
  • 메모리 조정 옵션 - spark.executor.memory / spark.memory.fraction 을 통해 메모리 할당량 조절

멀티 프로세싱과 멀티 스레딩

• 멀티프로세싱 - 독립적인 메모리 공간을 가지며 서로 메모리를 공유하지 않음
  • cpu 코어를 여러 개 활용하기 좋음. 파이썬에서는 GIL을 극복하는 수단임.
• 멀티스레딩 - 같은 프로세스 내에서 실행되고 메모리 공간을 공유
  • 여러 스레드가 같은 메모리에 접근할 수 있으나, 파이썬은 GIL때문에 병렬 CPU 연산은 제한되며, I/O 바운드 작업에 적합.
• Joblib과 머신러닝
  • 사이킷런 안에서 joblib이 병렬 프로세싱을 통해 속도를 높임. > 20개의 작업을 4개의 프로세서로 멀티 프로세싱을 하면 1,2,3,4번을 모두 완료해야 5,6,7,8 작업으로 넘어감.
  • 이 외에도 multiprocessing 패키지도 많이 사용. > 주피터 노트북에서 제대로 사용이 어려움. cue/pool로 할 것인지 옵션이 있어 입문자에겐 어려울 수 있음.