데이터 파이프라인 기초

데이터에 대한 이해

데이터는 충분하다

데이터가 화두인 요즘, 대부분의 기업은 어떤 형태로든 다양한 데이터를 남긴다. 웹 서버에 들어온 각종 요청은 로그 형태로 남기며, ELK Stack (Elasticsearch, Logstash, Kibana) 등을 통해 사용한다. 각종 transaction은 DB에 기록된다. 사용자의 행동은 Google Analytics와 같은 도구를 통해 수집된다.

데이터는 불완전하다

여러 형태로 수집되는 데이터는 기본적으로 불완전하다. 누락치/결측치가 있고, 바로 인사이트를 제공하기에는 너무 저수준의 데이터이다.

생각보다 많은 데이터셋은 누락치와 결측치로 가득하다. 서버의 access log에서 user-agent를 수집하는데, user-agent의 파싱이 실패해서, 혹은 특정 값이 없어서 null이나 “”로 저장되기도 한다. 사용자가 회원가입을 할 때, 필수정보가 아닌 “나이”, “생일” 등의 정보를 입력하지 않을 수 있다. 그럼 그 사용자의 나이나 생일에 대한 정보는 누락된다.

누락된 데이터가 없어도, 너무 저수준의 데이터는 가독성이 낮고 인사이트가 적다. 예를들어, 우리 웹 서비스에 접근한 모든 IP를 수집해 로그로 남겼다고 하자. IP를 천개를 모아봤자, 그냥 숫자와 점의 나열에 불과하다. 이 데이터가 가치가 있으려면, 특징별로 묶거나, 각 IP의 빈도를 정리하거나, 시간대에 따른 특정 IP의 접속 횟수를 본다거나 하는 식으로 보다 적극적인 분석작업이 필요하다.

데이터세트의 크기가 가치를 결정하는 것은 아니다

데이터세트의 크기가 크다고 꼭 가치가 높은 것은 아니다. AI/ML 모델을 만들 때도 단순히 데이터의 레코드 수가 많다고 더 가치있는 모델이 학습되는 것은 아니다.

예를들어, 극단적으로 접속 IP와 접속시간 타임스탬프만 수집된 데이터가 수백 페타바이트 이상이라고 하자. 물론 IP와 접속시간은 유의미한 가치를 가질 수도 있다. 하지만 이 2개 칼럼만으로 경영상 유익한 통계를 내는 데는 한계가 있다.

데이터의 칼럼만 많은 경우도 마찬가지다. IP는 그 자체로는 숫자와 점의 나열에 불과하지만 지리정보 등 적절히 처리만 하면 꽤 유익한 정보를 도출할 수 있다. 즉, 적절한 데이터의 처리가 데이터의 가치를 높인다.

왜 데이터 파이프라인이 필요할까

데이터 파이프라인은 데이터를 추출하고, 적절히 변환하고 비즈니스 인사이트 추출이나 AI/ML 모델 학습을 위해 사용될 수 있도록 모으는 일련의 작업을 파이프라인으로 구성한 것이다.

데이터 파이프라인을 통해 조직 내 흩어져 축적되는 데이터를 한데 모으고 적절히 처리하며 가치있는 인사이트를 도출할 수 있는 환경을 자동적으로 구축할 수 있게 된다.

예를들어 쇼핑몰이라고 하자. 데이터베이스와 서버만 있는 간단한 쇼핑몰이다. 고객의 결제 관련 정보는 데이터베이스에 수집될 것이고, 고객의 접속정보는 웹 서버에 로그로 수집될 것이다. 웹페이지 내에서 고객의 행동패턴은 구글 애널리틱스로 기록될 것이다. 우선은 이런 흩어진 데이터를 한 곳으로 수집해 바로 분석할 수 있게 하는 게 필요하다.

그래서 데이터 파이프라인의 시작은 “추출(Extraction)”이다. 여기저기 산재한 데이터들을 추출해 파이프라인의 입구로 투입한다.

다음은 ELT냐 ETL이냐 하는 패턴에 따라 조금씩 다를 수 있는데, 요즘은 ELT, 나아가 EtLT가 대세다. 즉, 데이터레이크(Datalake)에 수집한 데이터를 약간의 전처리만 하여 한데 모아두는 것이다. 흩어진 데이터를 모은 다음, 민감한 데이터를 난독화, 마스킹 하고 중복을 제거하는 등의 단순한 작업을 처리하는 것이다. 비즈니스적인 판단이 없어도 할 수 있는 데이터 처리 작업이 해당된다. 이후 데이터레이크라고 불리는 저장소에 데이터를 업로드해둔다.

마지막은 변환(Transformation)이다. 비즈니스 애널리틱스를 위한 데이터 변환 작업은 “데이터 모델링”이라고도 한다. 데이터를 최종적인 목적에 맞는 형태로 변환하고 재구성해 데이터를 활용한 작업을 가능하게 한다. 여기서 변환하는 데이터는 특수한 목적을 위한 가공된 데이터다. 이렇게 가공된 데이터는 구체적인 목적의 통계를 추출하거나 모델을 학습시키는 데 활용된다.

데이터 파이프라인, 알아야 할 것들

데이터웨어하우스와 데이터레이크

추출한 데이터를 처리하는 시점에, 최종적으로 필요한 데이터의 형태(모델)를 정확히 아는 것은 어렵다. 보통 데이터를 변환하는 것은 비즈니스적인 이해가 필요하다. 예를 들어, 스타트업이라면 매출보다는 고객 관련 지표가 중요할 수 있다. 반면 대기업이라면, 월간활성사용자수(MAU)보다는 매출이 중요할 수 있다. 이런 이해는 비즈니스에 대한 이해에 기반한다.

비즈니스 도메인마다 도메인 지식이 있다. 데이터를 해석하기위해서는 많은 경우 이런 도메인 지식이 필요하며, 데이터를 제대로 적재하려면 도메인 지식에 기반해 어떤 데이터를 어떻게 쌓아야 하는지 결정할 수 있어야 한다.

많은 경우, 데이터를 수집하는 시점에 이런 요구사항을 정확히 이해하긴 어렵다. 충분한 자원이 받침되지 않는다면 말이다. 이런 경직된 data schema/model은 데이터를 쌓는 행위를 더 어렵게 한다. 그래서 나온 것이 데이터 레이크이며 ELT이다. 즉, 일단 적당히 데이터를 쌓고 보자는 것이다. 분석할 때, 필요한 형태로 가공해 쓰고, 일단 쌓을 때는 쌓는 것에 집중하자는 것이다.

따라서 Data Warehouse와 Data Lake의 차이는 정형화된 스키마의 유무 정도로 볼 수 있겠다. 참고로 많은 데이터 레이크는 레코드(행) 기반이 아닌 열(column) 기반 데이터베이스로 이뤄져 있다.

ETL과 ELT

오랬동안 ETL(Extract, Transform, Load)은 데이터 파이프라인의 표준이었다. 하지만, 앞서 살펴본 것과 같이 ETL은 데이터 수집과 변환 과정에 충분한 도메인 지식이 필요하고 설계에 많은 시간이 소요된다.

한편 ELT는 그런 고민 없이 데이터를 쌓을 수 있다. 일단 데이터를 추출한 후 데이터 레이크에 쌓는다. 이후 분석시 분석의 목적에 맞게 적절하게 데이터를 변환하고 처리한다.

현재는 ELT가 대세인데, ELT는 몇가지 장점이 있다.

  1. 데이터를 분석하는 시점에 필요한 데이터의 형태를 결정하면 되기 때문에 편리하다.
  2. 데이터 엔지니어와 분석가의 업무를 분리할 수 있다. (데이터 엔지니어는 Extract, Load를, 데이터 분석가는 Transform을 담당하면 되어 업무가 분리되고 의존성이 적어진다)

한편 EtLT라는 형태도 있다. 소문자 t는 transform을 의미한다. 즉 transform이 2번 있는 형태인데, 소문자인 이유는 간단하고 도메인 지식이 불필요한 데이터 변환을 의미하기 때문이다.

예를들어 중복된 데이터를 제거하거나 개인정보를 마스킹하거나 난독화하는 경우가 EtLT의 t에 해당한다.

OLTP와 OLAP

OLTP

OLTP(On Line Transaction Processing)은 비즈니스 로직과 관련된 데이터 처리를 의미한다. 예를들어, 쇼핑몰에서 고객이 로그인하고, 제품을 카트에 담고, 주문하는 프로세스가 OLTP다. 대체로 단일 혹은 소수의 레코드를 자주 읽고 쓰게 된다. OLTP는 일반적인 로우 기반 데이터베이스가 최적의 데이터 저장 옵션이다.

OLAP

OLAP(On Line Analytical Processing)은 데이터 분석과 관련된 처리를 의미한다. 데이터 분석을 위해 대량의 데이터를 드물게 읽고 쓴다. 앞서 말한 예를 이어 보자면, 최근 한달간 고객들이 주문한 모든 주문총액을 가져와 분석하는 경우를 예로 들 수 있다. 보통 로우 기반 데이터베이스는 이런 작업에 최적화되어 있지 않기 때문에 칼럼 기반 데이터베이스를 사용하게 된다.

로우 기반 데이터베이스와 칼럼 기반 데이터베이스

로우 기반 데이터베이스

MySQL과 같은 관계형 데이터베이스는 로우 기반 데이터베이스다. 사실 관계형 데이터베이스가 아니더라도 많은 데이터베이스가 로우 기반 데이터베이스다. 이런 로우 기반 데이터베이스는 트랜잭션 처리에 보통 최적화 되어 있으며, 하나 혹은 소수의 레코드를 빠르게 쿼리해오는 데 최적화되어 있다.

MySQL과 같은 데이터베이스는 파일시스템에 데이터를 쓸 때, 일정 사이즈별로 블록을 나눠 데이터를 쓴다. 각 블록은 여러개의 레코드를 저장하는데, 블록이 꽉 차면 다음 블록에 레코드를 담는다. 블록이 애매하게 남는다면 레코드를 쪼개 일부를 담기 보다는 남은 블록은 빈 상태로 둔다.

앞서 말했듯 OLTP에서는 보통 레코드 단위로 데이터가 필요하기 때문에, 이런 구조는 가장 효율적인 구조다. 하나의 레코드가 여러 블록에 나눠져 저장되면 한 레코드를 가져오는 데 여러번의 디스크 I/O가 발생하고, 이는 성능상 손실로 이어지기 때문이다.

칼럼 기반 데이터베이스

칼럼 기반 데이터베이스는 블록단위로 저장할 때 각 블록에 동일한 칼럼만 저장한다. 따라서 레코드 단위로 데이터를 가져오는 것 보다는 칼럼 단위로 데이터를 가져오는 데 최적화 되어 있다. 각 블록에 칼럼 단위로 저장되므로 여러 블록에 칼럼을 연속적으로 저장할 수 있고, 빈 공간이 거의 남지 않게 된다. 따라서 각 블록에 낭비되는 공간이 적다. 또, 각 블록이 동일한 데이터 유형을 저장하므로 압축도 유리하다. 나아가 분석용 쿼리시 로드해야할 데이터의 크기가 로우 기반 데이터베이스보다 작고 쿼리시 디스크 I/O 횟수도 적어지게 된다.

보통 OLAP에서는 많은 양의 데이터를 드물게 읽고 쓰며, 칼럼 단위로 읽게 되는 경우가 많으므로 이런 데이터베이스는 최적의 형태라고 할 수 있다.

AI/ML을 위한 데이터 파이프라인

AI/ML을 위한 데이터 파이프라인은 비즈니스 애널리틱스를 위한 파이프라인과는 조금 다른 점이 있다.

  1. 학습/검증 등 목적에 맞게 데이터세트를 분리하고 참조할 수 있게 “버전지정”을 해야한다.
  2. 카테고리 인코딩, 입력값 정규화 등 컴퓨터가 읽을 수 있는 형태로의 데이터 전처리가 수반된다.
  3. 데이터세트와 모델 모두 버전지정이 가능해야 한다.
  4. 파이프라인에 피드백도 포함되어 모델이 지속적으로 업데이트될 수 있어야 한다.

참고서적: Building Machine Learning Pipelines

데이터 파이프라인 오케스트레이션(Data pipeline Orchestration)

airflow와 같은 툴이 일반적으로 사용되며, 유향 비순환 그래프 (DAG) 형태로 작업을 관리한다.

유향 비순환 그래프라고 하면 표현이 어려운데 쉽게 말하자면 파이프라인이 한 방향으로만 흐른다는 얘기다. 데이터 처리는 보통 순차적으로 여러 작업들이 수행되며 진행되고, 한번 처리된 데이터가 다시 처리되면 안되니 어쩌면 당연한 얘기다.

즉, 1) 데이터 수집 → 2) 데이터 적재 → 데이터 변환 → 모델 학습과 같이 순차적으로 각 작업들이 동작하도록 관리하는 것이 데이터 파이프라인 오케스트레이션이다.

Reference

  • <데이터 파이프라인 핵심가이드>(제임스 댄스모어 지음, 정현아 조이정 옮김)