데이터 아키텍처의 변화

티스토리 메뉴 펼치기 댓글수13

데이터 엔지니어

데이터 아키텍처의 변화

긍긍이 행님 송근일
댓글수13

데이터 엔지니어링을 왜 배워야 하는지에 대한 글을 아직 읽지 않으신 분들은 아래 링크를 통해 읽고 오시면 좋을 것 같습니다~

https://data-engineer-song.tistory.com/1

 

실무 AI 프로젝트 - 분석보다 엔지니어링이 중요한 이유

빅데이터 시대다. 컴퓨팅 기술의 발달로 수많은 데이터가 쌓이면서 데이터 분석가의 수요가 높아질 것이라고 한다. 하지만 이 말은 틀렸다. 물론 데이터 분석 자체가 필요 없다는 것이 아니라, �

data-engineer-song.tistory.com

 

예전에는 데이터라고 하면 엑셀 시트의 표와 같은 정형데이터만을 일컬었다. 그러나 최근에는 수많은 종류의 비정형 데이터가 생겨나고, 같은 정형 데이터라 하더라도 이전에 비해 변동성이 커졌다. 이런 시대적 흐름에 따라 당연히 데이터를 쌓는 저장소의 형태도 기존과는 많이 달라졌다.

 

이번 게시물에서는 데이터 아키텍처가 과거에 비해 어떻게 달라졌는지, 그리고 실제 기업의 아키텍처는 어떤 식으로 구성되어 있는지에 대해 설명하겠다.


기존의 데이터베이스 형태

예전에는 mysql이나 postgresql과 같은 관계형 데이터베이스를 많이 사용했다.

 

이런 관계형 데이터베이스 시스템에서는 데이터를 쌓기 전에 데이터를 쌓을 형식을 미리 정했다. 즉 테이블을 어떻게 구성할지, 각 테이블의 컬럼은 어떤 형식으로 지정할 지 등등을 모두 정하고 쌓았다는 것이다. 여기서 말하는 데이터의 형식을 유식한 말로 스키마라고 표현한다.

 

이런 시스템의 장점은 명확했다. 스키마가 정해져 있어서 일관성이 있었으며, 한 번 만들어 두면 변동되는 경우가 거의 없어서 데이터 관리 인력도 많이 필요하지 않았다.

 

관계형 데이터베이스의 예시로 내가 과거에 구축했던 DB의 일부를 가져와 보았다.

관계형 데이터베이스 예시

위 사진에서 사각형 표 모양으로 되어 있는 부분을 테이블이라 부르고, 그 안에 있는 요소는 컬럼이라고 부른다. 테이블은 엑셀 시트의 표고, 컬럼은 해당 표의 열이라고 생각하면 된다. 이런 관계형 데이터베이스를 적재하고 처리하는 전체적인 데이터 아키텍처를 데이터 웨어하우스(DW)라고 부른다.

 

빅데이터 시대에 드러난 데이터 웨어하우스의 단점

아아앆~~

그러나 최근에는 데이터가 너무나도 다양해지면서 데이터웨어하우스의 한계점이 드러나기 시작했다.

 

일례로,

  1. 페이스북, 구글과 같은 써드 파티에서 제공하는 데이터
  2. 음성과 같은 비정형 데이터
  3. 실시간으로 쌓이는 디바이스 로그 데이터
  4. 연속적으로 생성되는 스트리밍 데이터
  5. 등등..

과 같이 예전에 비해 기업이 활용할 수 있는 데이터가 정말 다양해지고 있다.

 

이런 데이터 특성상 스키마가 매우 자주 바뀌며, 어떨 땐 스키마 자체를 정의할 수 없는 경우도 있다. 얼마나 문제가 심각한지 이를 관리하는 aws Glue라는 서비스가 있을 정도이다(내가 매우 자주 사용하는 서비스다).

 

결국 데이터의 다양성과 변동성이 예측 불가능해서 정적인 스키마만으로는 관리가 어려워진 것이다.

 

어떤 사람들은 데이터가 바뀌거나 추가될 때마다 스키마를 바꾸면 되는거 아니냐고 할 수 있지만 한 번 해봐라 내가 데이터 엔지니어링을 아무것도 몰랐던 시절에 이걸 시도했는데, 진심 죽을 뻔했다.

 

새로운 데이터 저장소의 등장 - 데이터 레이크

결국 유연하고 포괄적인 저장소에 대한 필요성이 부각되었고, 그래서 나온 것이 바로 데이터 레이크다. 데이터 레이크란 분석에 필요한 모든 종류의 데이터를 있는 그대로(데이터 변환작업 없이) 저장하는 단일 저장소를 의미한다. 데이터 레이크는 관계형 DB와 달리 스키마를 설정하지 않아도 되어 높은 유연성을 지닌다.

 

질문 1.

여기서 어떤 사람은 이런 질문을 던질 수 있다.

“데이터 레이크에는 데이터가 정리된 형태로 존재하지 않을 텐데 결국 분석을 위해서는 어느 정도 정제된 데이터가 필요하지 않나요?"

 

이 질문에 답해보겠다. 데이터 레이크를 도입한다고 해서 기업이 데이터레이크만 가지고 있는 것은 아니다. 일반적인 기업은 데이터 레이크에서 필요한 데이터를 뽑아서 정리하고, 이를 데이터 레이크가 아닌 다른 저장소(이를 테면 aws의 redshift나 RDS 등등)에 저장하여 사용한다.

 

질문 2.

여기서 또 아래와 같은 질문을 할 수도 있다.

“어차피 필요한 데이터만 뽑아서 사용할거면 데이터 레이크는 왜 있어야 하는 거죠? 애초에 수집할 때 필요한 데이터만 수집하면 되는 것 아닌가요?"

 

문제는 어떤 데이터가 필요할 지 모른다는 것이다. 지금 당장은 A라는 데이터만 필요할 수 있지만 갑자기 B라는 데이터가 필요하게 될 수도 있고, 어떤 것이 미래에 필요할 지는 아무도 모른다. 특히 요즘같이 비즈니스 트렌드가 빠르게 바뀌는 시대에는 더더욱... 그러니까 일단 다 쌓아놓는 것이다.

 

데이터 엔지니어링 업무의 변화

과거와 현재의 차이

이렇게 데이터 웨어하우스에서 레이크로 트렌드가 변화하면서 데이터 엔지니어링 업무도 과거에 비해 바뀌었다.

 

1. 과거

과거에는 데이터 엔지니어링 업무를 ETL이라고 줄여서 표현했다. ETL Extract, Transform, Load의 약자다. 말 그대로 데이터를 추출(Extract)하고 이를 스키마에 맞게 변환(Transform)한 다음 데이터베이스에 적재(Load)하는 것이다. 어떤 데이터를 어떤 목적으로 활용할지를 미리 정했기 때문에 Load하기 전에 Transform할 수 있었던 것이다.

 

따라서 예전에는 필요한 데이터를 효율적으로 쌓는 것이 엔지니어링의 주요 쟁점이었다. 이런 효율적인 디비를 구축하는 과정을 전문용어로 데이터 모델링(혹은 ER 모델링)이라고 지칭한다.

 

2. 현재

요즘에는 어떨까? 요즘에는 데이터 엔지니어의 업무를 ELT이라고 표현한다. 데이터를 추출(Extract)한 다음에 일단 다 데이터 레이크에 저장(Load)하고, 나중에 변환(Transform)하자는 마인드인 것이다. 이렇게 먼저 쌓고 나중에 변환하다보니, DB에 쌓인 대용량 데이터를 처리하는 Apache Spark Presto와 같은 시스템이 각광을 받기 시작했다(이런 시스템은 추후에 실습을 통해 다룰 예정이다).

 

물론 요즘에도 관계형 디비를 활용하기 때문에 효율성 증대를 위한 데이터 모델링 작업도 많이 한다. 데이터가 아무리 많아져도 관계형 디비가 사라지진 않을 것이다. 관계형 디비는 데이터 엔지니어링의 기본 중의 기본이라고 생각하면 된다.

 

실제 데이터 아키텍처

aws를 활용하는 기업의 일반적인 데이터 아키텍처 예시

그렇다면 데이터레이크를 도입한 기업의 데이터 아키텍처는 실제 어떤 형식으로 되어 있을까? Aws를 활용하는 기업의 경우, 대부분이 위의 도식과 같다.

 

위 도식화에서 데이터가 수집부터 분석까지 가는 과정을 설명해보겠다.

  1. 다양한 데이터 소스로부터 데이터를 뽑아서 aws S3에 업로드한다(S3가 기업의 데이터 레이크라고 할 수 있다)
  2. S3의 데이터를 Spark를 통해 변환하여 aws Redshift에 적재한다(Reshift에는 "어느 정도" 정리된 데이터가 쌓인다)
  3. Redshift의 데이터를 최종적으로 정제한 후 aws RDS(혹은 Athena)에 저장한다(RDS에는 "가장 잘" 정리된 데이터가 쌓인다)
  4. 최종적으로 RDS(혹은 Athena)에 있는 데이터로 머신러닝 모델을 만들거나(aws SageMaker) 시각화(aws QuickSight)한.

이렇게 데이터를 로드하고 처리해서 최종적으로 분석까지 가는 과정을 전문용어로 데이터 파이프라인이라고 지칭한다. 물론 위의 경우는 하나의 예시이고, 기업의 비즈니스 모델, 자금적 여유, 회사의 규모 등에 따라 언제든지 달라질 수 있다. 나는 추후에 위의 아키텍처를 직접 aws로 구축하고 앱까지 만들어보는 실습을 진행할 예정이다.

 

(이 모든 과정을 aws를 통해서 다 구현할 수 있다는 것이 놀랍지 않은가? 내가 aws를 좋아하는 이유다)

정리하자면...

우리는 데이터 저장소의 최신 트렌드와, 실제 기업에서 어떤 식으로 데이터 아키텍처를 구성하는지를 살펴 보았다.

 

다음 게시물에서는 관계형 데이터베이스의 개념에 대해 설명하겠다. 이후에는 aws RDS를 통해 관계형 DB를 로드하고 관리하는 법까지 살펴보겠다.

 

다시 한번 강조하지만 데이터 레이크가 있다고 하더라고 관계형 데이터베이스는 어느 기업이든 사용하기 때문에 매우 중요하다.

맨위로

https://data-engineer-song.tistory.com/2

신고하기