Big Data World, Part 3: Building Data Pipelines

2021.11.28 - [Data Engineer] - Big Data World, Part 2: Roles

Big Data World, Part 2: Roles

이전 포스팅에 이어 이번엔 데이터 파이프라인을 구축하는 방법에 대해 포스팅한 글을 정리하려 한다.

 

https://blog.jetbrains.com/blog/2021/05/20/big-data-world-part-3-building-data-pipelines/

Big Data World, Part 3: Building Data Pipelines | JetBrains News

 

이전 포스팅에서 데이터 엔지니어의 다른 무엇보다도 데이터 전송과 데이터 웨어하우스의 아키텍처를 담당한다.

이는 꽤 간단해 보이나, 실제로 이를 성취하는 좋은 방법이 항상 명백하지는 않다.

 

What a pipeline is

어느 정도에 대해서는 개발하는 모든 것들이 데이터 파이프라인으로 표현 가능하다. 백엔드 개발에서는 아래와 같이 보인다.

이는 마치 ETL 처럼 보인다, 아무것도 추출하지 않지만 의미는 동일하다고 볼 수 있다.

 

일반적인 CI(Continuous Integration) 파이프라인은 아래와 같다.

이 측면에서도 CI 서버는 마찬가지로 ETL 툴이라고 볼 수 있다.

 

그러나 데이터 엔지니어링에서 이는 훨씬 더 복잡하다. 더 많은 데이터 소스, 많은 sinks(우리가 데이터를 저장할 곳), 많고 복잡한 변환 그리고 수많은 데이터가 존재한다.

상상해보자, 수십개의 운영 데이터베이스, Kafka에서 오는 사이트 클릭스트림, 수백 개의 리포트, OLAP cubes(다차원), A/B 테스트.

또한 원시데이터(rawdata) 계층부터 시작하여 보고서 작성에 적합한 집계되고 정리되고 검증된 데이터 계층까지 여러 가지 방법으로 다양한 계층에서 데이터를 저장한다고 상상해보라고 한다.

 

데이터 엔지니어가 이런 다양안 작업을 파이프라인을 통해 설계하는 것은, 오케스트라가 다양한 악기 연주자로 구성되는 것과 비유된다.

실제로, 데이터를 전송하는 과정에는 별개의 파이프라인이 필요하게 된다.

There actually are two levels of pipelines: in orchestrators and in ETL tools.

Orchestrators

https://habr.com/ru/company/mailru/blog/344398/

2021.08.28 - [Data Engineer/Airflow] - #3 Airflow Concepts documentation 부수기 [Architecture]

#3 Airflow Concepts documentation 부수기 [Architecture]

위 저자가 설명하는 Orchestrators는 DAGs(directed acyclic graphs - 방향 비순환 그래프)를 통해 job을 통합하여 관리하게 된다.
데이터 엔지니어의 Tool Box중 Orchestrators가 필요한 이유는 이러한 툴이 데이터 파이프라인 구축이 비교적 간단하기 때문이다.

 

다음은 파이프라인의 low - level 을 알아보자.

ETL Tools

앞서 언급했던 것 처럼, 오케스트레이터는 일반적으로 다른 툴 (지역화된 ETL 파이프라인을 구축하기 위한 툴)을 호출한다. ETL Tool들은 DAG로도 작동하는 경우가 있어 흥미롭다고 할 수 있다.

 

예를 들어, Apache Spark 같은 경우 범용 분산 컴퓨팅 엔진임에도 불구하고 대표적인 ETL Tool로 활용된다.

가장 자주 사용되는 경우는, sources to sinks로 데이터를 변환하여 적재한다.

 

https://user-images.githubusercontent.com/20614350/49424014-40609900-f7d4-11e8-901f-881531e64ad8.png

Batch vs stream processing

일반적으로 ETL 도구는 배치 처리 또는 스트림 처리의 두 가지 방법 중 하나로 동작한다.

배치 처리는 데이터를 가져와서 처리한 후에 종료된다.

스트림 프로세싱에서는 지속적으로 실행되어서 소스에서 데이터가 나오면 데이터를 얻는다.

 

이러한 방식으로 표현하면 스트림 처리에서는 항상 Kafka처럼 스트림 소스에서 사용되는 것처럼 보이지만 놀랍게도 꼭 그런 것만은 아니다.

대표적인 예로 관계형 데이터베이스가 있는데, 거기서 데이터를 추출하는 방법은 2가지가 있다.

1. 데이터베이스에서 필요한 모든 데이터를 하나의 배치로 묶는다. (일반적인 배치 프로세싱)

2. 데이터베이스 데이터를 스트림 데이터로 변경 가능하다 (Debezium. 같은 툴을 활용)

 

Apache NiFi

지금까지는 오케스트레이터와 ETL 툴의 측면과 배치 처리와 스트림 처리의 측면을 나눠서 구분해 봤는데 

Apache NiFi 같은 경우 오케스트레이터이자 ETL 도구이다. 또한 배치 모드와 스트리밍 모드 모두에서 동작할 수 있다.(일부 기능 제한)

 

https://stackoverflow.com/questions/55281566/apache-nifi-merge-sql-lines-into-json

 

이번 시리즈를 정리하면서 애매했던 개념들이 확실히 정리되는 것 같다.