[빅데이터를 지탱하는 기술] 1. 빅데이터의 기초 지식

데이터 엔지니어링 입문서로 추천되는 '빅데이터를 지탱하는 기술'에 대해 개인적인 생각으로 정리한 글입니다.

데이터 엔지니어로서 업무를 시작하기 전과 시작한 후에 느끼는 점이 달라 정리하게 됐습니다. 잘못된 부분이 있다면 댓글로 알려주시면 감사하겠습니다.

(출처 표기가 되지 않은 이미지는 모두 직접 그린 것이기 때문에 사용하실 때 반드시 출처를 남겨주시길 바랍니다.)

 

빅데이터를 지탱하는 기술 | 니시다 케이스케 - 교보문고

 

이 책의 가장 첫 장인 '빅데이터의 기초 지식' 부분에서는 빅데이터 기술의 역사부터 기본적인 용어들을 정리한다.

책의 전체 내용이 아닌 각 파트에서 개인적으로 와닿았던 부분들을 나의 용어로 정리해서 작성해본다.

 

[배경] 빅데이터의 정착

분산 시스템에 의한 데이터 처리의 고속화

빅데이터의 취급하기 어려운 점을 극복한 두 가지 대표 기술

 

요즘은 빅데이터를 활용해 비즈니스 가치를 창출하지 않는 기업이 없다고 말할 수 있다.

기업 뿐만 아니라 개인 조차도, AWS, GCP 등 클라우드 서비스를 통해 누구든 손쉽게 데이터 분석을 진행할 수 있다.

 

한참 내가 대학교를 다닐 당시에도, '빅데이터(Big Data)' 붐이었던 것 같다.

사실 빅데이터는 이보다 훨씬 이전부터 존재해왔을 것이다. 당장의 Facebook, Youtube, Google 같은 서비스는 아주 예전부터 사용자의 수많은 데이터를 끌어모아왔을 테니까. 하지만, 내가 어렸을 때는 Youtube가 찰떡같이 내가 궁금해하는 영상을 추천해주고, Google이 귀신같이 내가 검색할 단어를 자동완성해주지 않았다. (이와 관련해서는 Netflix의 '소셜 딜레마' 라는 다큐 시청을 강력히 추천한다.)

 

지금에야 빅데이터가 하나의 기술 분야로 정착했지만, 빅데이터의 취급이 어려웠던 점은 크게 두 가지 이유가 있었다.

1. '데이터의 분석 방법을 모른다'

2. '데이터 처리에 많은 수고와 시간이 걸린다'

 

이건 사실, 지금에서도 여전히 어려움이 많은 것 같다. 실제로 실무에와서도 두 가지 어려움을 엄청나게 느꼈기 때문이다.

데이터가 있어도 그 안에서 어떠한 가치를 창조하지 못한다면 데이터는 그 쓸모를 다하지 못한다.

또, 지식이 있어도 데이터 처리에만 많은 시간을 소비한다면 할 수 있는 것은 한정될 수 밖에 없다.

 

이 책은 두 번째 어려움인 '데이터 처리'에 대해 다룬다. 나 또한 데이터 분석가가 아닌 데이터 엔지니어이기 때문에 이에 대해 포커싱했다.

 

빅데이터 기술의 요구

빅데이터의 기술로 가장 먼저 예를 들 수 있는 것이 'Hadoop'과 'NoSQL'이다.

웹 서버 등에서 생성된 데이터는 먼저 RDB와 NoSQL, 텍스트 파일 등에 저장되며, 이후 Hadoop에서 모여 대규모 데이터 처리가 실행된다.

전통적인 관계형 데이터베이스(RDB)로는 취급할 수 없을 만큼 대량의 데이터가 쌓이게 되면서, 기존의 RDB와는 다른 구조의 Hadoop과 NoSQL이 탄생하게 됐다.

 

Hadoop

Hadoop은 '다수의 컴퓨터에서 대량의 데이터를 처리하기'위한 시스템이다.

책의 예시가 굉장히 적절한데, 예를 들어 전 세계의 웹 페이지를 모아서 검색 엔진을 만들려면 방대한 데이터를 저장해둘 스토리지와 데이터를 순차적으로 처리할 수 있는 구조가 필요하다. 그러기 위해서는 수백 대, 수천 대 단위의 컴퓨터가 이용돼야 하며 그것을 관리하는 것이 Hadoop이라는 프레임워크다.

 

Hadoop은 Google의 MapReduce 프로그래밍 모델을 기반으로 만들어졌다. 

위 예시처럼 Google은 자신들이 수집한 방대한 데이터를 처리하기 위해 큰 데이터 세트를 효율적으로 처리할 프레임워크가 필요했고, 이러한 필요에 의해 만들어진 것이 MapReduce이다.

 

이 아이디어에 영감을 받아, Doug Cutting과 Mike Cafarella는 Hadoop을 개발했고, 이는 MapReduce를 핵심 구성요소로 채택해 분산 데이터 처리를 가능하게 했다. 초기 Hadoop의 경우, MapReduce를 동작시키려면 데이터 처리의 내용을 기술하기 위해 JAVA로 프로그래밍을 해야 했다. 하지만 이후, Hive의 도입으로 프로그래밍 없이 데이터를 집계할 수 있게 함으로써 많은 사람이 Hadoop을 이용한 분산 시스템의 혜택을 받을 수 있게 됐다.

 

 

간단하게, Hive가 뭔지 살펴보자.

Hive는 Hadoop 에서 데이터 요약, 질의, 분석을 위해 개발된 데이터 웨어하우스 인프라스트럭처로, Facebook에서 처음 개발돼 현재는 Apache Software Foundation의 프로젝트로 관리되고 있다. 생긴것 부터 Hadoop의 상징인 코끼리와 벌이 합쳐진 모양이다.

 

번외로, Hadoop의 마스코트가 코끼리인 이유는 창시자인 Doug Cutting의 아들이 좋아했던 장난감 코끼리에서 영감을 받아 선택된 것이며, Hive(벌집) 역시, 데이터 웨어하우스의 역할을 상징적으로 표현한 것이라고 한다. (수많은 벌들이 벌집에 데이터를 수집하듯, Hive는 여러 소스에서 데이터를 수집하여 저장하고 분석하는 장소로 사용되기 때문이지 않을까 싶다.)

 

<Hive의 주요 특징>

1. SQL 유사 쿼리 언어(HiveQL): Hive는 SQL과 유사한 쿼리 언어인 HiveQL을 사용해 Hadoop 데이터를 쉽게 질의할 수 있다.

2. 메타스토어: Hive는 메타데이터를 저장하는 메타스토어를 유지 관리한다. 이 메타스토어는 테이블 정의, 데이터 타입 정보, 파일 위치 등의 정보를 포함한다.

3. Scalability와 최적화: Hive는 내부적으로 제출된 쿼리를 MapReduce 작업으로 변환하여 처리한다.

 

Hadoop과 Hive까지 간단히 살펴봤으니 이제, NoSQL을 알아보자.

 

NoSQL

빈번한 읽기/쓰기 및 분산처리가 강점인 NoSQL은 전통적인 RDB의 제약을 제거하는 것을 목표로 한 데이터베이스의 총칭이다.

Not Only SQL 또는 Non-Relational Operational Database의 약자로 말 그대로 SQL만을 사용하지 않는 데이터베이스 관리 시스템이다.

 

1. 비관계형 구조: NoSQL은 테이블 기반의 관계형 구조를 사용하지 않으며, Document, Key-Value, Graph, Column-Family 등 다양한 데이터 모델을 제공한다.

2. 스키마 없음 또는 유연한 스키마: NoSQL 데이터베이스는 고정된 스키마가 없거나 매우 유연한 스키마를 사용해 다양한 형태의 데이터를 저장할 수 있다.

3. 확장성: NoSQL 데이터베이스는 수평적 확장이 가능하여, 데이터베이스 서버를 추가함으로써 용량을 쉽게 확장할 수 있다.

4. 분산 처리: NoSQL 데이터베이스는 데이터를 여러 서버에 분산하여 저장하고 처리할 수 있다.

5. 대용량 데이터 처리: 매우 큰 데이터 세트를 효율적으로 처리할 수 있도록 설계됐다. (ex. 소셜 네트워크, 온라인 광고, IoT 등에서 발생하는 대량의 비구조화 데이터를 관리하는데 적합하다.)

NoSQL의 종류(https://www.geeksforgeeks.org/types-of-nosql-databases/)

NoSQL 데이터베이스에는 위 이미지를 보면 알 수 있듯 다양한 종류가 있다.

- Key-Value Database

- Column-Family Database

- Graph Database

- Documnet Database

각 데이터베이스마다 목표가 다르기 때문에 단순 비교를 할 수 없지만, RDB보다 고속의 읽기, 쓰기가 가능하고 분산처리 뛰어나다는 공통점을 갖고 있다.

 

NoSQL은 애플리케이션에서 온라인으로 접속하여 빠른 데이터 접근과 유연한 데이터 관리를 제공하는 반면, Hadoop은 대량의 데이터를 저장하고 복잡한 분석 작업을 효율적으로 수행하기 위한 플랫폼으로 설계됐다.

 

이 둘을 조합함으로써, NoSQL 데이터베이스에 기록하고, Hadoop으로 처리하기를 통해 현실적인 비용으로 이전의 대규모 데이터를 처리하는데 어려움을 해결할 수 있게 됐다.

 

분산 시스템의 비즈니스 이용 개척

데이터 웨어하우스와의 공존

Hadoop에 의한 데이터 웨어하우스의 증가 (출처: 책)

 

분산 시스템의 발전에 따라, (엔터프라이즈) 데이터 웨어하우스 제품을 Hadoop이 대체하게 됐다. 

전통적인 데이터 웨어하우스에서도 대량의 데이터를 처리할 수 있으며, 오히려 여러 방면에서 Hadoop보다 우수하다. 하지만, 데이터 용량을 늘리려면 하드웨어를 교체해야 하는 등 확장성면에서 어려움이 있었다. 

 

따라서, 가속도적으로 늘어나는 데이터 처리는 Hadoop에 맡기고, 비교적 작은 데이터 또는 중요 데이터만을 데이터 웨어하우스에 넣는 식으로 사용을 구분하게 됐다.

 

스몰 데이터와 빅데이터의 활용

빅데이터와의 비교로 기존 기술을 이용해서 취급할 수 있는 작은 데이터를 '스몰 데이터'라고 한다. 

레코드 수로는 약 수백만에서 수천만 건, 데이터 양으로 따지면 '수 GB'까지를 스몰 데이터라고 한다.

 

어쨌든, 빅데이터와 스몰 데이터 모두 데이터이며, 본질적인 차이는 없다.

 

개인적인 생각으로 실제로 생각보다 빅데이터가 있는 곳은 많지 않다. 그래서 스몰 데이터부터 처리하는 방법을 알아야 한다고 생각한다.

스몰 데이터를 빅데이터 처리 방식만으로 처리하는 건 오버 엔지니어링일 수 있다. 

회사에서 일할 때도, Spark가 오히려 비용, 처리 속도면에서 오버 스택인 경우가 종종 있었다. 

 

결국은, 효율적인 스몰 데이터의 처리 방법을 알지 못한 채 빅데이터 기술만 배워서는 충분하지 않다.

이 둘을 모두 적재적소로 구사하는 것이 가장 이상적인 엔지니어링이라고 생각한다.

 

스몰 데이터의 기술에서는 데이터양이 증가하면 처리 시간이 급격히 증가한다. 빅데이터 기술의 경우, 시간의 증가는 억제되지만, 데이터양이 적은 상황에서는 스몰 데이터 기술이 더 우수하다.

 

데이터 디스커버리지(Data Discoverage)의 기초지식

빅데이터 기술이 나오기 시작한 시기와 같은 시기에 데이터 웨어하우스에 저장된 데이터를 시각화하려는 방법으로 '데이터 디스커버리지'가 인기를 끌게 됐다.

 

데이터 디스커버리지(Data Discoverage)는 대화형으로 데이터를 시각화해 데이터로부터 의미있는 패턴, 트렌드, 관계를 탐색하는 프로세스를 말한다. '셀프서비스용 BI 도구'라고도 불릴만큼 BI 도구와 밀접하게 연결돼있다.

 

빅데이터 시대의 데이터 분석 기반

[재입문] 빅데이터의 기술

분산 시스템을 활용해서 데이터를 가공해 나가는 구조

빅데이터 기술이 기존의 데이터 웨어하우스와 다른 점은 다수의 분산 시스템을 조합하여 확장성이 뛰어난 데이터 처리 구조를 만든다는 점이다. 이 책에서 다루는 '빅데이터 기술'이란 분산 시스템을 활용해 데이터를 순차적으로 가공해나가는 일련의 구조다.

 

데이터 파이프라인(Data Pipeline)

데이터 수집에서 워크플로 관리까지 차례대로 전달해나가는 데이터로 구성된 시스템을 '데이터 파이프라인'이라고 한다.

데이터 파이프라인은 어디(데이터 소스)에서 데이터를 수집하여 무엇을 하고 싶은지에 따라 변한다. 간단한 구성으로도 가능하지만, 하고자 하는 일이 늘어남에 따라 함께 복잡해진다. 이러한 데이터 파이프라인을 설계하고 구축하는 것이 데이터 엔지니어의 메인 테스크라고 할 수 있다.

 

데이터 수집

데이터 파이프라인은 가장 먼저 데이터를 수집하는 것부터 시작한다. 

스마트폰의 이벤트 데이터, 로그 파일, 임베디드 장비의 센서 데이터 등 각기 다른 데이터 소스로부터 데이터를 전송한다.

이 때 데이터 전송(Data Transfer)의 방법은 크게 다음의 두 가지가 있다.

 

벌크(Bulk)형

: 이미 어딘가에 존재하는 데이터를 정리해 추출하는 방법으로, 데이터베이스와 파일 서버 등에서 정기적으로 데이터를 수집하는데 사용한다.

 

스트리밍(Streaming)형

: 차례차례로 생성되는 데이터를 끊임없이 계속해서 보내는 방법으로, 모바일 애플리케이션, 소셜 미디어 피드 등에서 실시간으로 생성되고 연속적으로 전송하는데 사용된다.

 

 

스트림 처리와 배치 처리

이전엔, 데이터 웨어하우스에서 다루는 데이터 대부분이 벌크형 방법이 이용됐다. 하지만, 실시간 데이터가 많아지며 오히려 스트리밍형 방식이 주류가 되고 있다. 스트리밍형 방법으로 수집된 데이터를 실시간으로 처리하는 것을 스트림 처리(Stream Processing)이라고 한다.

 

스트림 처리의 결과를 시계열 데이터 베이스에 저장함으로써, 지금 무슨 일이 일어나고 있는지 즉시 알 수 있다.

하지만, 스트림 처리는 장기적인 데이터 분석에는 적합하지 않다. 스트림 처리는 실시간으로 들어오는 데이터를 즉각적으로 처리하는데 초점이 맞춰져있기 때문이다.

 

따라서, 장기적인 데이터 분석을 위해서는 대량의 데이터를 저장하고 처리하는데 적합한 분산 시스템(그림의 4, 5)이 좋으며, 스트림 처리가 아닌 정리된 데이터를 효율적으로 가공하기 위한 배치 처리(Batch Processing)가 필요하다.

 

스트림 처리와 배치 처리에 사용되는 대표적인 프레임워크는 각각 Kafka와 Airflow가 있다.

 

분산 스토리지

수집된 데이터는 분산 스토리지(distributed storage)에 저장된다. 

분산 스토리지는 여러 컴퓨터와 디스크로부터 구성된 스토리지 시스템을 말한다.

대표적으로는, 한 덩어리로 모인 데이터에 이름을 부여해서 파일로 저장하는 객체 스토리지(object storage)가 있다. (ex. Amazon S3)

 

분산 데이터 처리

분산 스토리지에 저장된 데이터를 처리하는 데는 '분산 데이터 처리(distributed data processing)의 프레임 워크가 필요하다. (그림의 6, 7)

MapReduce가 사용된 것이 바로 이 부분으로 데이터 양과 처리의 내용에 따라 많은 컴퓨터 자원이 필요하게 된다. 분산 데이터 처리의 주 역할은 나중에 분석하기 쉽도록 데이터를 가공해서 그 결과를 외부 데이터베이스에 저장하는 것이다.

 

빅데이터를 집계할 때, Hive와 같은 쿼리 엔진을 사용하거나, 분산 스토리지에서 추출한 데이터를 외부 데이터 웨어하우스에 변환하여 사용하기도 하는데 이 과정을 ETL(Extract-Transform-Load) 프로세스라고 한다. 말 그대로, 데이터 추출, 가공, 데이터 웨어하우스에 로드하는 것을 의미한다.

 

요즘엔 ETL 뿐만 아니라 ELT 방식도 사용되는데, 둘의 차이는 다음의 이미지를 보면 쉽게 알 수 있다.

https://aws.amazon.com/ko/compare/the-difference-between-etl-and-elt/

ETL 프로세스: 데이터의 바깥에서 데이터를 가공 후 적재

ELT 프로세스: 데이터를 로드 후, 가공하는 경우

 

워크플로우 관리(Workflow Management)

워크플로우 관리는 전체 데이터 파이프라인의 동작을 관리하는 것을 의미한다.

매일 정해진 시간에 배치 처리를 스케줄대로 실행하고, 오류가 발생한 경우에는 관리자에게 통지하는 목적으로 사용한다.

(예를 들어, 회사에서는 특정 작업을 Airflow를 통해 배치 처리 해두고, Task에 Fail이 발생하면 Slack으로 관리자에게 알림)

 

데이터 웨어하우스와 데이터 마트

데이터 파이프라인의 기본형

이 부분을 정리하기 위해 이 포스팅을 썼다해도 과언이 아닌 중요한 부분이다.

데이터 웨어하우스를 중심으로 하는 데이터 파이프라인

데이터 파이프라인의 기본형은 위의 프로세스와 같다.

데이터 웨어하우스는 일반적인 RDB와는 달리 '대량의 데이터를 장기 보존하는 것'에 최적화돼있다. 

정리된 데이터를 한 번에 전송하는 것은 뛰어나지만, 소량의 데이터를 자주 쓰고 읽는 데는 적합하지 않다.

 

업무 시스템을 위한 RDB나 로그 등을 저장하는 파일 서버는 '데이터 소스(Data Source)'라고 부른다.

즉, 데이터가 생성되거나 처음으로 집계되는 장소를 의미한다.

거기에 보존된 raw data를 추출하고, 필요에 따라 가공한 후 데이터 웨어하우스에 저장하기까지의 흐름이 ETL 프로세스다.

 

데이터 분석을 위해서는 데이터 웨어하우스에 무분별하게 접근하기보다, 필요한 데이터만 추출하여 데이터 마트(Data Mart)를 구축한다.

데이터 마트는 BI 도구와 함께 데이터를 시각화하는데 사용되기도 한다.

 

데이터 레이크

데이터를 그대로 축적

ETL 프로세스가 복잡해지고, 여러 데이터가 수집, 생성되며 위의 기본형만으로는 처리할 수 없게되자 '데이터 레이크'라는 개념이 생겨났다.

데이터 레이크(Data Lake)는 모든 데이터를 원래의 형태로 수집하고 추후 필요에 따라 가공하는 구조다.

구체적으로는 임의의 데이터를 저장할 수 있는 분산 스토리지가 데이터 레이크로 이용된다. (ex. S3)

데이터 레이크를 중심으로 하는 데이터 파이프라인

데이터 레이크에서는 모든 데이터를 그대로 저장하고, 나중에 필요한 것만을 꺼내서 사용한다.

 

데이터 레이크와 데이터 마트

데이터 레이크는 단순한 스토리지에 불과하다. (데이터 가공x)

이 때 MapReduce 등의 분산 데이터 처리 기술을 사용해 데이터 분석에 필요한 데이터를 가공, 집계한 후 데이터 마트로 추출하여 데이터 분석을 진행한다.

 

데이터 분석 기반을 단계적으로 발전시키기

팀과 역할 분담, 스몰 스타트와 확장

위의 살펴본 대부분의 프로세스는 데이터 엔지니어가 담당한다.

데이터 엔지니어는 데이터 분석가가 유의미한 인사이트를 도출할 수 있도록 좋은 재료(데이터)를 준비한다고 생각한다.

업무의 영역이 회사마다 다르기도 하지만, 결국 가능한 작은 시스템에서 시작해 단계적으로 확장해 나가는 것이 좋다.

 

애드 혹 분석 및 대시보드 도구

애드 혹 분석(Ad-Hoc Analysis)는 일회성 데이터 분석으로, 데이터 마트를 만들지 않고 데이터 레이크와 데이터 웨어하우스에 직접 연결하는 경우가 많다.

데이터 레이크에 직접 연결 VS 데이터 마트에 연결

 

대시보드 도구는 데이터 마트가 없어도 동작하도록 설계돼있어, 설정한 스케줄에 맞춰 데이터 레이크와 데이터 웨어하우스에 접속해 쿼리를 실행하고 그 결과로부터 그래프를 생성한다. (이러한 서비스를 해줄 수 있도록 도와주는 Amazon Glue, Amazon Athena 등이 있다.)

 

데이터 마트와 워크플로우 관리

사실 위의 오른쪽 이미지처럼, 데이터 마트를 미리 구축하는 것이 집계 속도를 높이는데 유리하다.

데이터 마트 구축은 배치 처리로 자동화되는 경우가 많기 때문에 그 실행 관리를 위해 워크플로우 관리 도구를 사용한다. 
(실제로 데이터 엔지니어 채용 과제로 이 프로세스를 구축하라는 과제를 받은 적이 있다.)

 

데이터를 수집하는 목적

'검색', '가공', '시각화'의 세 가지 예

데이터 검색: 대량의 데이터 중에서 조건에 맞는 것을 찾고 싶은 경우

데이터 가공: 업무 시스템의 일부로 데이터 처리 결과를 이용하고 싶은 경우(자동화 필수)

데이터 시각화: 데이터를 시각적으로 봄으로써 알고 싶은 경우

 

 

꽤 긴 내용이지만 챕터 1(빅데이터의 기초 지식) 에서 정리하고 싶던 부분들을 개인적인 생각 및 추가적으로 공부한 내용과 함께 정리했다.

모든 걸 깊게 다루지는 않았지만 데이터 엔지니어링에서 가장 기초가 되는 부분들을 대략적으로 살펴볼 수 있는 중요한 챕터였다고 생각한다.