728x90

하둡 사용의 이점

  • 큰 데이터 다룰때

하둡 사용의 단점

  • 적은 데이터를 다룰 때
  • 하둡에 데이터를 저장할 때 파일사이즈가 큰애들로 진행하는 것이 좋다. 작은 데이터 여러개가 하둡에 저장되어 있을 경우 네임노드에 부하를 주게된다. 
  • 맵리듀스 처리 시에도, 큰파일들도 알아서 128메가바이트씩 분산되지만, 만약 1kb등 작은 데이터는 부하를 불러올 수 있음
  •  프로그래밍 레벨에서 개발이 필요하다. 

하둡 단점 극복

  • Hive : SQL을 지원하는 하둡의 쿼리엔진
  • 하둡 에코시스템중에서 spark 엔진 등장
spark는 하둡에 큰 dependency가 있지는 않음. 
성능이 더 빠르다(인메모리 기반)
-> 메모리 사이즈를 벗어나는 데이터를 처리하기 어렵지만, 이 때 처리 하지 못한 데이터를 hive가 처리할 수 있다. 

보통 최근 메모리가 커져서 spark sql을 많이 사용.

 

-> 기본 적으로 메타스토어가 있다. 하둡에 데이터를 저장해놓고 저장한 데이터를 rdb해서 define해주어야 한다. 

-> 정의한 데이터를 sql로 활용한다. 

 

-> 컬럼등의 단위가 기존 데이터 베이스와 비슷하고, 작업한 쿼리가 분산으로 처리되어 작업됨. 

-> 하둡에 데이터가 저장되어 하이브로 테이블 생성

 

-> 칼럼단위로 데이터 저장

-> 대표적으로 ORC(하이브에서 많이 사용), Parquet

 

ORC file format?

- 하이브와 친밀함
- 자바만 지원
parquet fire format?

- 하이브뿐 아니라 피그 등 다양한 플랫폼 지원
- 컬럼별로 다양한 압축 코덱 적용 가능
- spark와 매우 친밀함.

-> 데이터 저장하고 etl처리하건 하둡이나 하이브로 구축 가능하다. 

-> 하둡은 데이터 저장된 이후로 배치처리 하는 과정을 담당. 

-> 저장 과정에서는 대표적으로 카프카 활용(주로 스트림 처리용으로/ 분산 큐 시스템)

-> 하이브로 구현하기 한계가 있는 부분을 spark 활용(stream이나 ml기능)

-> 좋은 방향성은 data warehouse/ data mart를 최대한 구성원에게 오픈해둔다.

-> 보안이 필요한 데이터에 대한 접근 권한 관리나 암호화 작업을 해두어야 한다. 

 

Apache Spark

 

클라우드에서의 활용

- 지금까지의 내용은 기본적으로 온프레미스 기반인데, 대부분 스타트업에서는 클라우드에서 활용한다. 

 

완전 관리형 서비스 활용

-> 완전관리형 서비스 : managed service는 플랫폼  layer단의 관리 자체를 아예 클라우드에서 제공하는 서비스를 사용하는 경우

-> kinesis가 kafka와 맵핑 가능

-> kafka를 관리하는 클라우드 서비스도 있다. 

-> EMR은 elastic mapreduce라고 해서 하둡 에코시스템을 클라우드서비스로 제공 / 위에 설명한 다양한 설정들을 EMR에서 하둡 클러스터를 손쉽게 설정가능하다. 

-> store에 저장된 이후에, 분석하기에 좋게 전처리하는 과정이 추가적으로 필요하다. 

 

AWS EMR

  • aws 클라우드 서비스
  • 하둡 에코 시스템을 제공

  • 버전에 대한 관리가 조금 복잡하다. 버전이 변하면 플랫폼과 연동 부분에 대해 관리해야 하는데 이러한 부분을 클라우드 서비스가 관리해준다. 
데이터를 이렇게 관리해서 어떤 인사이트를 얻을 것인가가 최근의 논의 사항이다. 

 


- 온프레미스에서 가장 효율적으로 구축가능한 데이터 플랫폼은 하둡이다. 

 

728x90

+ Recent posts