.

Data_Engineering_TIL(20200925)

• study program : T아카데미 - 아파치 하둡 입문과 활용

** URL : https://tacademy.skplanet.com/frontMain.action

[학습내용]

• 그렇게 크지 않은 데이터를 하둡에서 처리하는 것은 적절하지 않다. RDS에서 처리하는 것 보다 느릴수도 있다.

• HDFS에 데이터를 저장할때는 파일사이즈가 기본적으로 큰것이 좋다. 하둡에 작은파일이 많이 저장되어 있으면 여러가지 측면에서 좋지않다. 먼저 네임노드 메모리에 부하를 많이 준다. 두번째는 성능도 많이 떨어지게 된다. 그래서 볼륨이 작은파일들은 어떻게 관리하냐면 하둡에서 제공하는 ‘헤르’라는 압축 유형이 있는데 이거를 이용해서 별도의 ETL 처리를 통해서 관리를 하는편이다.

• MapReduce할때도 마찬가지인데 큰 파일들은 128MB 블럭 단위로 알아서 연산을 하겠지만 데이터 파일자체가 예를들어서 1KB 이런것들이 수천개 수만개가 있는경우도 있을것이다. 그런 파일들을 MapReudce에서 한꺼번에 빠르게 처리하려면 ‘컴바인’ 포맷이라는게 있는데 이거로 파일들을 합쳐서 combine input format으로 mapper에게 던져주면 성능측면에서 상당히 장점을 얻을 수 있다.

• 하둡의 활용 측면에서 단점은 MapReduce 는 프로그래밍 레벨(Java, Python, C++ 등)의 개발을 했어야 했다. 그래서 더 쉬운 분석 지원을 위해 SQL 을 지원하는 쿼리 엔진이 필요했는데 그래서 등장한 어플리케이션이 하이브이다.

• 하이브가 스팍 대비 장점도 있다. 스팍은 메모리에서 데이터를 처리하기 때문에 전체 클러스터의 메모리양을 벗어나는 데이터는 처리하기 어렵고, 보통은 메모리보다 디스크 용량이 훨씬 크기 때문에 스팍에서 처리하지 못한 데이터는 하이브에서는 처리가 가능하다. 왜냐하면 하이브는 디스크 단위로 데이터를 읽고 쓰기 때문이다. 최근의 분산환경에서는 메모리가 큰편이기 때문에 스팍에서 ETL 처리를 하는게 일반적이다.

• 하이브 아키텍처

기본적으로 메타스토어가 있다. HDFS에 데이터를 저장해놓고, RDB처럼 스키마를 정의를 해줘야 한다. 예를 들어서 create table ... 쿼리를 통해 정의를 해서 SQL 쿼리로 데이터 조회 또는 처리를 할 수 있는 것이다. 메타스토어는 기본적으로 MySQL 같은 RDB를 사용하게 구성하는 것이 일반적이다.

• Columnar vs Row-based File Format

하둡에 저장할 데이터의 크기를 줄이기 위해서 Columnar 데이터 파일 포맷이라는게 있다. csv와 같이 로우단위로 저장하는 일반적인 형태가 아니라 컬럼단위로 데이터를 저장함.

장점은 아래와 같다.

1) 압축률이 매우 좋음

2) 데이터 Read 시 I/O 양을 줄일 수 있음 (클라우드 전환 시 비용과도 연관됨)

3) 컬럼에 동일한 데이터 타입이 저장되기 때문에 컬럼별로 적합한 인코딩 방식을 사용할 수 있음

4) 위와 같은 이유로 인해 읽기 성능이 증가함

• Columnar 예시 (ORC와 parquet)

parquet은 일반적으로 spark에서 많이 쓰고, ORC는 하이브에서 많이 사용하는 포맷인데 어떤거를 써도 좋다.

• kinesis firehose의 fan-out

실시간데이터를 처리할때 kinesis firehose에서 하나는 spark stream으로 보내고, 다른 하나는 s3로 두개의 카피를 fan-out 할 수 있다.

spark stream 이외의 옵션도 있는데 hadoop application 중에 apache flink 등을 이용하여 스트리밍 데이터를 처리할 수 있다.