[Infra] 데이터 인프라 - Ingestion&Transformation

🔊 해당 포스팅은 YouTube GeekNews 채널의 데이터 인프라 강의 내용에 기반해 제가 재구성하여 작성함을 알려드립니다.

 

이번 포스팅에서는 저번 포스팅에서 알아본 데이터 인프라 구조의 첫 번째 구성요소 Sources에 이어 다음 단계인 Ingestion & Transformation을 알아보려 한다.

 

데이터 인프라의 큰 구조

Ingestion & Transformation

흔히 말하는 ETL 도구들이 이번 단계에 해당하는 것들이다. 즉, Sources 로부터 얻은 많은 데이터들을 추출, 변환하는 단계이다. 이번 포스팅에서는 위 그림에서 빨간색 네모칸 안에 있는 Connectors, Data Modeling, Workflow Manager에 대해 알아보려고 한다.

1. Connectors

위 그림에서 Connectors가 가르키는 화살표를 잘 살펴보면 알 수 있듯이, Sources에서 발생한 데이터들을 SnowFlake, 구글의 BigQuery, AWS의 RedShift와 같은 Data Warehouse나 Data Lake(AWS S3, 하둡의 HDFS, Parquet 등)로 전달하는 역할을 한다.

 

위 그림에서 언급된 Connectors의 예시 플랫폼들에 대해 간단히 소개하고 넘어가자.

 

• Fivetran : 소스들의 데이터들을 Normalization 하고 SQL 변형을 취해 분석이 가능한 스키마(테이블)로 변형해준다. 해당 플랫폼에서 Transform(변형)하는 연산 비용보다 상대적으로 저렴한 Load(적재)를 먼저 수행하는 ELT 구조를 수행한다.
• Stitch : Fivetran과 비슷한 역할을 한다. 단, ETL뿐만 아니라 분석 도구랑 연결까지 해주는 플랫폼이다.
• MATILLION : 위 2개와 비슷한 역할을 한다. 주목할만한 점은 Data Loader 기능을 모두에게 무료로 제공하는데, 이는 데이터를 추출, 적재까지 하는 것을 무료로 제공하는 것이다.(꽁짜는 언제나 진리다...)
• Panoply : 이는 좀 튀는 플랫폼이다. 예를 들어, 보통은 AWS Redshift라는 데이터 웨어하우스를 사용하면 소스의 데이터를 ETL하는 도구를 별도로 사용해야 하지만 Panoply는 이 2개를 한꺼번에 할 수 있게 제공해준다. 보통 크기가 작은 회사들이 주로 사용한다고 한다.

2. Data Modeling

참고로 Data Modeling은 위 그림에서 Sources 부분과 연결되어 있지는 않다. 단지 데이터를 저장하는 데이터 웨어하우스와 데이터 레이크와 연결이 되어 있다. 대체 Data Modeling 은 무슨 역할을 하는 걸까?

 

보통 실무에서 데이터 분석가들은 ETL과 같은 데이터 엔지니어링 업무를 잘 하지 않는다. 그런데 Data Modeling 관련 플랫폼들은 데이터 분석가도 데이터 엔지니어링 업무를 할 수 있도록 도와주는 것들이다. 예시 플랫폼으로는 dbt, LookML 등이 있다.

3. Workflow Manager

소스의 데이터를 가져와 데이터 웨어하우스, 데이터 레이크로 옮기는데, 이 옮기는 과정을 워크플로우 단위로 관리하는 것을 의미한다. 요즘 가장 자주 사용하는 것으로 Airflow가 있다. 간단히 Airflow가 어떤 특징이 있고 어떤 과정으로 동작하는지에 대해 알아보자.

 

Apache Airflow

 

에어플로우는 크게 3가지 특징을 갖는다.

 

• Task Scheduling : 특정 task를 언제 처리할지를 정함
• Distributed Executing : 많은 task들을 분산으로 효율적인 처리를 함
• Dependency Management : 예를 들어, 어떤 앞의 과정이 끝나기 전에는 뒤의 과정이 절대 시작될 수 없도록 관리하는 것이다.
• DAG(Directed Acyclic Graph) 특성

4가지 특징 중 3번째 의존성 관리(Dependency Management)에 대해 도식화해서 살펴보자.

 

의존성 관리를 이해해보자

 

소스들은 4가지가 존재한다. Transform1 이라고 되어있는 task는 광고 데이터라는 소스 부분 로직이 수행되면 실행될 것이다. 그런데 Transform2는 연결되어 있는 소스가 3가지이다. 무조건 A,B,C task들이 다 완료 되어야 Transform2가 수행되어야 한다. A,B의 소스까지만 task가 수행되고 Transform2가 수행되면 안되는 것이다. 이것이 바로 의존성 관리이다. 따라서 Airflow라는 도구를 사용해 A,B,C 소스까지 다 task가 수행되야 Transform2가 수행되도록 워크플로우 단위로 관리해주는 것이다.

 

그리고 마지막 특징인 DAG 특성을 살펴보자. DAG란, 쉽게 말해서 loop같은 순환되는 구조가 없는 그래프를 의미한다. DAG의 A인 Acyclic이 '비순환'이라는 의미이다. DAG에 대한 그림을 보면 바로 직관적으로 이해가 될 것이다.

 

DAG 그래프

DAG는 알고리즘 종류로도 불린다. 위 그림을 보면 각 노드에서 출발하거나 자신의 노드로 들어오는 Edge는 있어도 자기 자신으로 되돌아오는 Edge가 없다. 이렇게 자신으로 돌아오는 Edge 그래프가 없어야만 하는 그래프가 DAG이다. Airflow는 워크플로우를 관리할 때 이렇게 DAG 구조만을 유지해야 한다. 마지막으로 Airflow 이외의 워크플로우를 관리하는 다른 도구를 살펴보고 마무리하자.

 

• DAGSTER : Airflow랑 비슷하다. 다만 데이터 Application을 만들 수 있도록 제공한다. 이것도 DAG 특성을 지닌다. 다만 Airflow는 Task 단위로 관리하는 Task-Driven 이지만 DAGSTER은 Data-Driven 이다.
• Argo Airflow : Kubernetes에서 돌아가는 워크플로우이다.
• Prefect : Airflow랑 매우 유사하다. 단, Airflow가 출시된 이후에 나온 것이라서 그런지 Airflow보다 앞서 나가기(?)위해서 사용이 쉽고 마치 "현대판 Airflow" 같은 느낌이라고 한다.