Notice
Recent Posts
Recent Comments
Link
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

짱이 될거야

빅데이터 처리 Hadoop, Spark, Python 본문

면접 준비

빅데이터 처리 Hadoop, Spark, Python

jeong57 2022. 10. 20. 10:25

빅데이터 처리 필요성

4차 산업혁명이 시작되면서 데이터를 어떻게 활용하는지가 신기술에 큰 영향을 미치게 되었다.

코로나19 등으로 인해서 비대면 업무가 가속화됐고 온라인 업무 처리가 발달한 것도 빅데이터 처리에 대한 관심을 키웠다.

 

그 과정에서 데이터 3법이 등장했고 다양한 기업(금융, 기업, 공공기관)들이 관심을 가지고 있다.

 

데이터 3법

  • 개인정보보호법: 개인정보보호 소관 부처를 하나로 모아서 중복 규제를 없앴다. 개인과 기업의 정보 활용 폭을 넓혔다.
  • 정보통신망법: 가명정보 개념 도입, 상업 목적으로 활용 가능
  • 신용정보법: 가명정보 금융분야 빅데이터 분석에 이용 가능, 가명정보 주체 동의 없이 활용 허용
  • 특징: 가명정보 개념 도입, 개인정보의 판단기준을 명확화
  • 기대:
    • 데이터 활용 근거가 마련되어 가명정보 데이터를 활용한 연구와 상품 개발 활성화
    • '본인'의 정보를 '본인'이 활용할 수 있는 마이데이터 산업의 활성화 기대
  • 우려: 민감정보 활용해서 수익 창출하기 때문에 보안과 개인정보 오남용 발생

빅데이터 처리 방법

1. Apache Hadoop: 아파치 소프트웨어 재단에서 관리

  • 간단한 프로그래밍 모델을 사용해서 컴퓨터이 클러스터에서 대규모 데이터 자료를 분산저장 및 처리할 수 있는 오픈소스 프레임워크
  • HDFS(Hadoop Distributed File System): 스키마를 미리 정의하지 않고도 어플리케이션 데이터에 높은 처리량으로 액세스할 수 있게 해주는 분산 파일 시스템
  • YARN(Yet Another Resource Negotiator): 클러스터에서 컴퓨팅 리소스를 관리하고 이를 사용해서 사용자 어플리케이션을 예약하는 리소스 관리 플랫폼
  • 맵리듀스(MapReduce): 구글에서 대용량 데이터 처리를 분산 병렬 컴퓨팅에서 처리하기 위한 목적으로 제작한 소프트웨어 프레임워크
    • 함수형 프로그래밍에서 일반적으로 사용되는 Map과 Reduce 함수 기반으로 주로 구성된다.

2. Hadoop을 쓰는 이유

  • 내결함성: 데이터가 클러스터 전체에 복제되므로 장애가 발생할 경우 데이터 쉽게 복구 가능.
  • 비용 관리: 다른 플랫폼보다 더 저렴한 비용으로 데이터 저장해서 관리
  • 오픈소스 프레임워크: 더 많은 아이디어와 빠른 개발, 문제 발생 시 문제 해결도 지원하기 때문에 이점.
  • 안정적 데이터 처리: 구조화된 데이터와 구조화되지 않은 데이터 모두 처리 가능하므로 더 빠르고 유연하게 빅데이터 수집, 처리, 분석 가능

3. Hadoop 활용

  • 분석 및 빅데이터
  • AI 및 머신러닝
  • 클라우드 컴퓨터

3. Apache Spark: 오픈소스 클러스터 컴퓨팅 프레임워크

  • 아파치 재단의 오픈소스로 관리되고 있는 in-memory 기반의 대용량 데이터 고속 처리 엔진.
  • 범용 분산 클러스터 컴퓨팅 프레임워크
  • 디스크 기반의 Hadoop에 비해 성능을 100배 정도 끌어올렸다.
  • 클러스터: 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합

4. Hadoop과 Spark의 차이

  • 공통점: 둘 다 빅데이터 분산 처리하는 프레임워크, mapreduce 방식으로 데이터 분산 처리
  • Hadoop
    • 디스크로부터 map/reduce할 데이터를 불러오고, 처리 결과를 디스크로 쓴다.
    • 데이터 읽기/쓰기 속도는 느리고 디스크 용량 만큼의 데이터를 한 번에 처리 가능.
    • 느린 이유: 중간 결과를 디스크에 쓰기 때문에 I/O로 인해 작업 속도에 제약이 생긴다.
  • Spark
    • 메모리로부터 map/reduce할 데이터를 불러오고, 처리 결과를 메모리로 쓴다.
    • 데이터 읽기/쓰기 속도는 빠르고 메모리 용량 만큼의 데이터만 한 번에 처리 가능.
    • 메모리 용량보다 크면 과부하 걸릴 수 있다.
  • 메모리 커버 가능한 데이터라면 메모리 기반, 메모리 용량 이상이면 디스크 기반이 유리.
  • Spark: 기계 학습이나 마이닝 같은 반복 작업이 많을수록 유리.

5. Spark의 장점

  • 속도: 인메모리 기반의 빠른 처리
  • 다양한 언어 지원: 자바, 스칼라, 파이썬, R, 인터페이스 등 다양한 언어 지원해서 작업 편리성 높였다.
  • SQL, 머신러닝 등 다양한 컴포넌트 제공해서 데이터 처리 프로세스 효율성 높였다.
  • 어디서나 동작
    • Yarn, 쿠버네틱스 등 다양한 클러스터에서 동작
    • HDFS, Casandra 등 다양한 파일 포맷을 지원

6. Spark와 Hadoop의 결합

  • Spark는 Hadoop을 대체하는 게 아니라 함께 하며 성능 높이고자 나온 것.
  • Hadoop 사용자들이 쉽게 Spark 사용 가능하도록 했다.
  • 내가 활용한 프로젝트
    • DB에서 Sqoop을 통해 HDFS에 파일을 가져오고, 그걸 Spark에서 처리하도록 했다.

내가 프로젝트에 활용한 것

1. HDFS

  • VMWare에 Ubuntu를 설치해서 활용했다.
  • 가상환경이기 때문에 일단 초기 데이터베이스를 그 내부에 저장시켜서 사용했다.
  • 실제 처리 과정은 Sqoop으로 데이터베이스를 MySQL에서 HDFS로 옮기고, 그걸 Spark에서 활용했다.
  • 그리고 처리 결과를 HDFS로 옮기고 Sqoop을 활용해 데이터베이스에 넣었다.
  • (이 때, 매일 새벽 4시-사용자가 많이 없는 시간-에 전통주와 태그 연결 테이블을 다 초기화시키고 다시 넣었다. 중복 피하기 위해서)

2. Spark 설치 후 Python 활용

  • PySpark 설치하고 pyspark.sql module을 활용했다.

3. Python 활용 이유

  • 특징
    • 스크립트 언어: 컴파일 과정 없이 인터프리터가 소스 코드 한 줄씩 읽어서 실행, 실행 결과 바로 확인하고 수정 가능해서 쉽다.
    • 동적 타이핑: 변수 자료형 지정하지 않고 단수 선언만으로 값 지정 가능.
    • 플랫폼 독립적: 리눅스, 유닉스, 윈도우, 맥 등 대부분의 운영 체제에서 모두 동작.
  • 장점
    • 간결하고 쉬운 문법: high-level 언어, 인간의 사고와 유사해서 코드를 이해하기 쉽다.
    • 빠른 개발 속도: 쉬운 문법 덕분에 오류 발생 줄임
    • 높은 확장성 및 이식성: 다른 언어나 라이브러리에 쉽게 접근해 연동 가능. 어플 성능 보장하면서도 별도 설치나 구성 과정 없이 스크립트 언어 장점 누릴 수 있다.
    • 활발한 생태계: 수많은 표준 라이브러리 제공, 모든 코드를 일일이 작성할 필요 없다. 커뮤니티 활동도 다양하다.
  • 활용 사례
    • google: 백엔드에는 c++(짧은 대기 시간과 엄격한 메모리 제어 필요), python(프로그램 빠른 전달과 유지관리 필요)
    • instagram, netflix, ...
  • 파이썬의 최근 업데이트
    • 오류 메시지
      • 기존: SyntaxError에서 구문 분석 중이거나 잘못된 위치를 가리켰다. (혼동 위험)
      • 개선
        • 닫히지 않은 괄호 위치에 집중해서 좀 더 에러가 발생한 곳을 자세히 파악 가능.
        • 문제가 감지된 위치가 아니라 구문 오류 자체를 강조한다.
    • OR
      • 기존: case 404 ~ case 405~
      • 개선: case 404 | (수직선 기호) | case 405 사용 가능

4. 처리 과정

  • 네이버 후기 스크래핑으로 데이터 가져와서 데이터베이스에 맞게 추출 (18만 건)
  • VMWare 로컬에 저장해서 데이터 처리했다.
  • 초기 데이터 처리
    1. 데이터 맞춤법 검사(hanspell) 문제: '간장닭다리' => '간 장닭 다리'
    2. 형태소 분석(KoNLPy, 코엔엘파이) 문제
      • 부드럽다 => 부드럽다
      • 부드럽고 => 부드럽고
      • '달다' => '달다'
      • '달지 않다' => '달' + '지' + '않다'
      • '달지 않고' => '달' + '지' + '않고'
      • '달아서' => '달아서'
      • 달다, 달고, 달아서 => '달다'로 간주해야 한다.
      • 달지 않다, 안 달아서 => '달지 않다'로 간주해야 한다.
    3. ' '(split) 기준으로 단어 분리하고 워드 카운팅 후 팀원들과 쓸 단어를 선택했다.
      • '멜론', '메론' -> '멜론' 등으로 맞춤법 다양한 것들을 처리
      • '집들이', '친구', '지인', '파티' -> '파티용': 비슷한 카테고리 한 묶음 처리
      • '단맛', '달다', '달아요', '달고', '달콤 등 => '달달함: 같은 의미이지만 형태소 분석 결과가 다른 것들을 묶음
      • 프론트에서 쓰는 방법
        • '달다', '산미' 같은 경우에는 태그 유무로 and 선택
        • 매실, 유자, 귤, 포도, 복분자 같은 건 과일로 묶어서 or 선택 가능
    4. customized konlpy형태소 분석기를 활용해서 사전을 재정의하고 워드 카운팅
      • '달지', '안달아서', '안 달아서' (stopwords: 사용하지 않을 단어) / '단맛', '달다', '달아요', '달고', '달콤', '달아서' (add_dictionary: 사용할 단어)
      • key-value 형태 딕셔너리 만들어서 서비스에서 활용하기로 한 태그에 대해 개수를 셌다.
      • 제일 많이 나오는 3개를 추출해서 각 전통주와 해당 태그 인덱스를 나타내는 csv를 추출
      • dictionary, islice, sort 활용
    5. HDFS에 csv 저장해서 데이터베이스 초기화 후 집어넣기.

5. 어려웠던 것

  • 한국어 전처리가 굉장히 어렵다
    • 띄어쓰기, 맞춤법 틀린 게 많은데 맞춤법 검사기나 형태소 분석기가 완전하지는 않다.
  • 데이터프레임이 계속 변하는데, 어떨 때는 행제목이 없어지고 어떨 때는 남아 있었다. 그래서 RDD와 Dataframe 변환 할 때 그 부분을 항상 신경써야 했다.
  • 형태소 분석의 경우 customoized konlpy 라이브러리를 썼는데 형태소와 품사를 함께 보여주는 pos만 지원된다. 그래서거기서 분석된 형태소만 가지고 워드 카운팅하는 부분이 어려웠다.

 


cf) 오픈소스 소프트웨어의 장점

1. 비용 절감

  • 무료로 이용 가능하고 소스 코드가 공개되어 직접 소프트웨어 개선 또는 수정 가능
  • 개발 비용 적다
  • 무료 다운로드와 수정/재배포가 발생해서 초기 개발 비용이 새 소프트웨어 개발하는 것의 절반 정도.

2. 빠르고 유연한 개발

  • 다양한 이용자들에게서 최신 기술 정보와 문제점의 해결책 공유
  • 독점 프로그램에 비해 기술의 발전 속도에 빠른 편

3. 호환성/유연성

  • 주로 오픈포맷 또는 오픈프로토콜(개방형 표준) 사용하기 때문에 서로 다른 소프트웨어간 연동 쉽다.
  • 서로 다른 플랫폼끼리의 상호 연동 또한 가능

4. 신뢰성/안정성

  • 전 세계 수많은 개발자와 전문가가 개발에 참여하기 때문에 독점 프로그램에 비해 안정적으로 작동한다.
  • 하지만 개발자가 적극적으로 참여하는 경우에만 해당하므로 오픈 소스의 평판과 개발 과정을 주의 깊게 봐야 한다.

예: Linux, Netscape

 

cf) 소프트웨어 분류

  • 프리웨어: 무료 소프트웨어로 복제/사용 가능하며 조건, 기간, 기능 등에 제한이 없다.
  • 쉐어웨어: 정식 제품 구매 전에 먼저 체험해볼 수 있도록 한다. 대중들에게 알리며 프로그램 기능 사용해볼 수 있도록 한다. 저작권 있다.
  • 애드웨어: 광고를 보는 것을 전제로 무료로 사용할 수 있는 소프트웨어

 

cf) 버전 종류

  • 알파버전: 미처 발견하지 못한 오류를 찾아내기 위해 개발자들이 자체적으로 내부 테스트하는 것
  • 베타버전: 소수의 일반 사용자가 테스트하는 불안정 버전. 제품 테스트나 오류 수정에 사용.
  • VOLUME 버전(CORP 버전): 인증 확인 절차가 생략된 버전으로, 대규모로 구입하는 경우 별도 인증 절차를 간략화시킨 버전.
  • RETAIL 버전: 소비자에게 판매대는 완성 버전. 소프트웨어로 판매대는 마지막 버전.

 

'면접 준비' 카테고리의 다른 글

SQL vs NoSQL  (0) 2022.11.27
REST API vs RESTful API  (0) 2022.10.20
Spark: RDD, Dataframe, Dataset  (0) 2022.10.20
프레임워크, 라이브러리, 플랫폼의 차이  (0) 2022.10.20
Comments