[Spark] 빅데이터와 데이터 레이크 - Hadoop 변천사

데이터 엔지니어링의 변천사

기본적으로 1959년, COBOL의 등장이 처음으로 데이터를 처리하는 것에 대한 진지한 결과물로 등장.

이후 1977년, Oracle이 RDBMS를 만들며 COBOL을 계승, 대체함.

그리고 오랫동안 structured data만을 저장할 수 있어도 전혀 문제가 없었음. 그러나,

 

Variety

어느 시점, JSON, XML과 같은 semi-structured data들이 등장했고, RDBMS가 담기 어려워졌음.

심지어는 text, pdf 등의 un-structured data까지 등장을 해버렸음. 

 

Volume, Velocity

이전과는 비교도 안될 정도의 큰 규모의 데이터들을, 빠르게 다뤄야 하는 시간이 왔음.

 

이렇게 3V의 성질을 가진, 소위 빅데이터 가 등장하면서, RDBMS만으로는 이를 감당 못하게 됨.

 

그래서 이를 "빅데이터 문제"로 규정하고, 이를 해결하기 위한 솔루션이 2개로 추려짐.

 

1 Monolithic Approach: 하나의 큰 시스템.

2 Distributed Approach: 여러개의 작은 시스템들을 모아서, 마치 하나처럼 쓸 수 있게 하는 것.

 

결과적으로 Distributed가 Monolithic을 아래와 같은 3가지 관점에서 압도함.

 

이런 기반 위에서 등장한 혁신적인 녀석이 바로 Hadoop.

 

기본적으로 OS는 한대의 컴퓨터를 위한 프로그램인데, 이걸 바꾸어 여러대의 컴퓨터가 마치 하나의 큰 컴퓨터처럼 동작하게 만들기 위한 가장 큰 필요조건이 바로 Cluster Operating System이었음. CPU, Memory 등을 모두 공유해야 했으므로. 그걸 가능하게 한 게 바로 YARN. 같은 맥락으로 분산 저장을 가능하게 한 게 HDFS, 분산 컴퓨팅을 가능하게 한 게 Map-Reduce 모델. 결론적으로 이런 것들이 모여, Hadoop은 여러대의 컴퓨터를 하나의 컴퓨터처럼 쓸 수 있게하는 도구로 발전. 이후 추가로 HIVE와 HBase 같은 DB, Pig SL, Sqoop, Oozie 등이 등장함.

 

결론적으로, RDBMS의 여러 취약점들을 Hadoop이 다 커버함. 그러나 현대 데이터 엔지니어링에서, 중-소 단위의 엔지니어링에서는 RDBMS가 여전히 압도함. 다만 빅데이터를 다루는 데에 있어서는 Hadoop이 최고다, 이말이야.

 

 

본격적으로 Hadoop에 대하여

Hadoop을 정의하면, 많은 핵심 기술들을 제공하는 분산 데이터 처리 플랫폼이라고 할 수 있음.

많은 핵심 기술은 YARN, HDFS, Map/Reduce 등 포함함.

 

 

YARN

 

YARN은 Hadoop에서 리소스를 관리하고, 앱을 실행하는 프레임워크.

 

세개의 핵심 컴포넌트를 가짐. RM, NM, AM.

여러개의 노드들 중에, 하나를 골라서 대장 시키고, 이름을 Resource Manager, RM 이라고 부름. 나머지는 Node Manager, NM이라고 칭함. NM은 자기 노드 하나만 관리하는 애들이고, 주기적으로 그 관리 내역을 RM에 보고함. RM은 이를 기준으로, 클러스터 시스템 전반의 resource를 관리함.

클라이언트가 YARN 위에서 App을 띄우고 싶다고 요청하면, RM이 NM 하나 골라서 넘겨줌. 그럼 해당 노드에서, 클라이언트가 원하는 앱을 실행할 수 있음. NM은 해당 노드에서 애플리케이션을 관장하는 AM을 실행하고, 이제 AM이 앱을 다루면서 추가 리소스가 필요한 등의 요구사항을 RM에 직접 요청할 수 있는 실권을 줌. NM이 컨테이너를 띄우고, AM이 이를 관리하고 운영하는 방식이라고 생각하면 됨.

 

 

HDFS

 

HDFS는 하둡의 분산저장시스템. 크게는 읽고, 쓰는 기능을 제공함.

Master Node에는 Name Node, Worker Nodes에는 Data Nodes를 설치함.

 

쓰기 프로세스

클라이언트가 Name Node에 파일을 전달하면, Master Node가 이 파일을 block이라는 단위로 분할함. 일반적으로 128MB. 이 block들을 몇 군데의 Data Nodes에 나누어 전달하고, DN들은 이들을 저장함. NN은 이 일련의 과정에서 나오는 metadata, 그러니까 파일명, 디렉토리, 사이즈, 블락들에 대한 정보들까지 모두 저장함. 이후 읽기 프로세스에서 하나의 파일로 조립할 때 활용할 정보들이 모두 들어가 있음.

 

읽기 프로세스는 쓰기 프로세스의 역 과정.

 

 

M/R - Map Reduce

 

MR Framework는 늙어서 더 이상 사용되지 않지만, 그 Model은 계속 다른 방식으로 계승, 발전되기에 이해해야 함.

예를 들어 아래와 같은 데이터 파일이 있는데, 이 파일의 라인의 개수를 구하라는 질문이 있다면, 어떻게 풀까?

 

일반적인 for loop을 돌리기엔 너무 오래 걸리기도 하고, 애초에 저 파일이 저장될만한 물리적인 공간을 찾기도 어려움.

우선 물리적인 공간 문제는 위에서 배운 HDFS로 해결하면 됨. 시간이 너무 오래 걸리는 문제는,

 

1 map - 여러개의 노드에 저장한 block들에 대해서, 병렬적으로 for loop을 돌려주면 n 개의 노드라 하면 시간은 1/n로 단축됨.

2 reduce - 각각의 노드에서 카운팅이 끝나면 그 값들을 모두어서 제삼의 노드에 넣고, 그 리스트를 순회하면서 다 더해주면 됨.

 

즉, 병렬화를 통해 시간을 단축하는 것이 바로 Map Reduce인 것이다. 이렇게 Map Reduce를 활용한 서비스들은 Hive SQL, Spark SQL, Spark Scripting 등이 있음. 우리는 MR을 직접 다루지 않지만, 내부에는 그렇게 진행된다는 걸 이해하자.

 

그렇게 Hadoop이 매우매우 강성해졌지만, 시간이 지날수록 아래와 같이 여러가지 개선의 여지를 남겼다. 이것들을 개선하고자 만든 것이 바로 Spark다.

 

1 데이터 처리 속도가 훨씬 빠름

2 Spark SQL 퍼포먼스도 훨씬 빠름 (Composable Function API의 도입)

3 JAVA에 국한되지 않은 다양한 언어를 지원함

4 HDFS 뿐 아니라 cloud 저장소도 지원함

5 Resource-wise도, YARN 뿐 아니라 Docker, K8s 등의 방식도 지원함.

 

=> 결과적으로 Spark가 기존의 Hive 등을 비롯한 기성품들의 자리를 많이 차지하게 됐고, 최근은 두 가지로 보통 쓰임.

(1) Hadoop 위에 쓰이면, Data Lake

(2) Cloud 위에 쓰이면, Lakehouse

 

 

Data Lake?

기존 DWH가 담지 못하는, Semi 혹은 Unstructured Data를 담고, 더 많은 용량을 담고, 또 수직 확장이 아닌 수평 확장을 가능하게 하기 위해 등장한 녀석. 보통 이러한, 대용량의 비정형 데이터를 필요로 하는 게 바로 ML 단. 그래서 AI/ML 쪽에서 데이터 레이크를 자주 활용함.

 

Data Lake는 그러나, data consistency와 transaction 기능, 그리고 reporting에서 DWH에 비해 약점을 보였다. 그래서 Data Lake에만 온전히 의존할 수는 없고, 결론적으로 아래와 같은 그림이 만들어지게 됨.

 

그리고 이 흐름 속에서, Spark의 역할은 주로 다음 영역에 속함.

 

 

Spark에 대한 기본

우선, 들어가기 전에, Spark 는 cluster management나 storage management는 필요로 하지만, 직접 관장하지 않는다. 저 둘을 해주는 누군가가 필요하다는 의미. Cluster Manager는 보통 YARN, K8S 등을 쓰고, Distributed Storage는 보통 HDFS, S3, GCS 등을 씀. 그 기반 위에서 spark가 돌아간다.

 

(1) Spark Core:

(2) 그 위 app layer: 

 

※ DATABRICKS Cloud가 Spark를 클라우드 환경에서 쓸때는 거의 필수라고 함. 일단 지금은 패스.