▽ 1장 데이터 파이프라인 소개는 이전 포스팅을 참고해주세요 ▽
2. 최신 데이터 인프라
이 장에서는 파이프라인을 구축하기 위한 제품과 설계를 결정하기 전에 최신 데이터 인프라를 구성하는 주요 구성 요소에 대한 설명이 등장한다.
2 - 1. 데이터 소스의 다양성
대부분의 조직에는 분석 작업의 수행 대상이 되는 수십개에서 수백개의 데이터 소스가 존재한다.
데이터 소스들은 여러 차원으로 구분될 수 있다.
소스 시스템 소유권
데이터 수집(data ingestion)이란, 한 소스에서 데이터를 추출하여 다른 소스로 로드하는 행위이다.
데이터 수집의 대상이 되는 소스 시스템은 위치에 따라서
1. 타사 데이터 소스에 위치한 데이터
2. 내부적으로 구축된 시스템
으로 구별된다.
타사 데이터 소스에 위치한 데이터 소스의 경우, 엑세스 방법에 제한이 있을 수 있다.
예를 들어서, 데이터 소스를 제공하는 솔루션 공급 업체가 Rest API를 통한 데이터 접근은 제공하지만 SQL 데이터베이스에 직접 액세스를 허용하지 않는 경우가 흔하게 존재한다.
이러한 경우에, 통신 속도와 같은 제한이 생길 수 있고 엑세스 가능한 데이터와 세부 수준까지 분석가가 필요로하는 환경에 맞게 지정하기가 어렵다.
내부적으로 구축된 시스템의 경우, 엑세스 방법 뿐만 아니라 데이터의 세부 수준을 분석가가 필요로 하는 환경에 맞춰서 지정할 수 있다는 장점이 있으나 시스템을 구축하는 단계에서 이러한 행위 시에 발생할 수 있는 잠재적인 문제들을 고려해야 한다.
예를 들어서, 데이터 수집이 시스템에 부하를 가하는지에 대한 고려부터 데이터를 점진적(incremental)으로 로드할 수 있는지에 대한 여부까지 고려 사항이 큰 폭으로 증가한다.
수집 인터페이스 및 데이터 구조
소스 데이터의 소유권과 관계없이 데이터 엔지니어는 소스 데이터를 얻는 방법과 형식을 우선적으로 고려해야 한다.
소스 데이터를 얻는 방식 즉, 데이터 인터페이스 중 가장 일반적인 것은 다음과 같다.
1. Postgres 또는 MySQL 데이터베이스와 같은 애플리케이션 뒤에 있는 데이터베이스
2. Rest API와 같은 시스템 상단의 추상화 계층
3. Apache Kafka와 같은 스트림 처리 플랫폼
4. CSV 파일 및 기타 플랫 파일을 포함하는 공유 네트워크 파일 시스템(NFS) 또는 클라우드 스토리지 버킷
5. 데이터 웨어하우스 또는 데이터 레이크
6. HDFS 또는 HBase 데이터베이스의 데이터
소스 데이터의 형식 즉, 데이터 구조 중 가장 일반적인 것은 다음과 같다.
1. Rest API의 JSON
2. MySQL 데이터베이스의 잘 구성된 데이터
3. MySQL 데이터베이스 테이블의 열 내의 JSON
4. 반정형화된 로그 데이터
5. CSV, 고정 폭 형식(FWF) 및 기타 플랫 파일 형식
6. 플랫 파일의 JSON
7. Kafka의 스트림 출력
잘 구성된 데이터는 파이프라인 구축 및 분석 작업을 진행하기 쉬울 수 있으나, 해당 데이터는 일반적으로 애플리케이션이나 웹 사이트를 위해서 정형화되어 있으므로 이를 분석 작업에 더 적합한 형태로 정형화하기 위해서는 데이터 수집 외에 추가적으로 클렌징, 변환 작업 등을 파이프라인에 구축해야한다.
JSON과 같은 반정형 데이터의 경우, 관계형 데이터베이스와 달리 같은 데이터 세트 안에 데이터의 무결성을 보장하기 어렵다. 즉, 같은 데이터 세트 내에 있더라도 누락되거나 구조가 다른 데이터가 포함되어 있을 수 있으므로 파이프라인에서 처리해주어야 한다.
비정형 데이터는 자연어 처리(NLP)나 컴퓨터 비전(CV)과 같이 이미지, 비디오, 텍스트 등의 데이터를 의미한다. 이 또한 파이프라인 구성 시에 데이터 형식을 고려해주어야 한다.
데이터 사이즈
데이터 엔지니어는 파이프라인의 각 단계를 설계할 때 데이터 사이즈를 고려하여야 한다. 그러나, 데이터 사이즈가 크다고 해서 가치가 비례하게 커지는 것은 아니므로 대용량 / 소용량 두가지로 데이터 세트를 구별하기 보다는 스펙트럼의 측면에서 데이터 사이즈를 고려해주어야 한다.
데이터 클렌징 작업과 유효성 검사
데이터 소스의 다양성만큼이나 소스 데이터의 품질도 다양하다. 데이터 파이프라인은 소스 데이터에 존재하는 한계와 결함을 이해하고 해결하는 역할을 수행해야 한다.
품질이 낮은 데이터는 몇가지 공통적인 특성이 있다.
1. 중복되거나 모호한 레코드
2. 고립된 레코드
3. 불완전하거나 누락된 레코드
4. 텍스트 인코딩 오류
5. 일치하지 않는 형식
6. 레이블이 잘못되었거나 레이블이 지정되지 않은 데이터
데이터 엔지니어는 이러한 데이터들의 품질을 개선하기 위해서 몇가지 원칙을 가지고 파이프라인을 설계해야한다.
1. 최악을 가정하고 최상을 기대하라
입력 데이터 세트에 수많은 유효성 및 일관성 문제가 있음에도 불구하고 깨끗한 출력을 위해서 데이터를 식별하고 정리하는 파이프라인을 구축한다고 가정한다.
2. 가장 적합한 시스템에서 데이터를 정리하고 검증하라
파이프라인에서 나중에 데이터를 정리할 때까지 좋은 방식일 때가 있다. 데이터 엔지니어는 데이터 클렌징과 검증 프로세스를 서두르지 말고 올바른 작업에 올바른 도구를 사용해야 한다.
3. 자주 검증하라
파이프라인의 데이터를 여러 포인트에서 자주 검증한다.
소스 시스템의 지연 시간 및 대역폭
최신 데이터 스택에서는 소스 시스템에서 대량의 데이터를 자주 추출하는 것이 일반적이다.
이를 가능하게 하기 위해서는 API 속도 제한, 연결 시간 초과, 느린 다운로드 및 시스템에 대한 부담 등을 고려하여 데이터 파이프라인을 구축해야 한다.
클라우드 데이터 웨어하우스 및 데이터 레이크
퍼블릭 클라우드 공급업체가 등장하면서 데이터 웨어하우징과 분석 환경에도 많은 변화가 있었다.
1. 클라우드에서 데이터 파이프라인, 데이터 레이크, 데이터 웨어하우스의 구축 및 배포가 쉬워졌고 클라우드 공급업체에서 관리해주는 관리 서비스(데이터베이스 등)가 주류가 되었다.
2. 지속적인 클라우드 내 스토리지 비용 감소가 있었다.
3. Amazon Redshift, Snowflake, Google Big Query 등의 확장성이 뛰어난 열 기반 데이터베이스가 등장하였다.
이러한 변화는 데이터 레이크라는 개념을 도입하는데 중요한 역할을 했다.
여기서 데이터 레이크란, 데이터가 저장되지만 데이터 웨어하우스처럼 데이터 구조 통일이나 쿼리 최적화 필요 없이 다양한 부서의 다양한 유형을 가진 데이터들을 집대성한 곳이다.
단일 데이터 레이크에는 텍스트, 이미지 등 여러 유형과 구조를 가진 데이터들이 포함되어 있다.
데이터 파이프라인은 데이터 웨어하우스와 데이터 레이크 간의 빈번한 데이터 이동을 담당하게 된다.
데이터 수집 도구
본 책에서는 가장 일반적인 데이터 수집 도구 및 프레임워크에 대해서 설명한다.
1. Singer
2. Stitch
3. Fivetran
데이터 변환 및 모델링 도구
데이터 변환과 데이터 모델링은 종종 같은 의미로 사용되기도 하지만 정확한 학습을 위해서 두 용어를 구분하여 설명한다.
데이터 변환이란, ETL 또는 ELT 프로세스에서 T에 해당하는 광범위한 용어로, 저장된 타임스탬프를 한 시간대에서 다른 시간대로 변환하는 것처럼 간단할 수도 비즈니스 로직을 통해서 집계되고 필터링된 여러 원본 열을 바탕으로 새 지표를 생성하는 것처럼 복잡할 수도 있는 작업을 총칭한다.
데이터 모델링이란, 보다 구체적인 데이터 변환의 한 유형으로써, 데이터 분석을 위해서 데이터를 이해하고 최적화된 형식으로 정형화하고 정의하는 과정이다.
워크플로 오케스트레이션 플랫폼
데이터 파이프라인이 복잡해지고 많아지면서 데이터 인프라에 워크플로 오케스트레이션 플랫폼을 도입하는 것이 중요한 과제로 떠올랐다.
Apache Airflow나 Luigi, AWS Glue와 같은 범용적인 오케스트레이션 플랫폼도 있고, Kubeflow Pipeline과 같이 ML에 특화된 오케스트레이션 플랫폼도 존재한다.
방향성 비순환 그래프
거의 모든 최신 오케스트레이션 프레임워크는 각 작업의 흐름과 종속성을 그래프로 나타낸다. 이러한 그래프들은 몇 가지 특정 제약 조건이 있다.
1. 파이프라인 단계는 하나 또는 여러개의 작업으로부터 다른 작업을 향하는 방향성을 가진다.
2. 파이프라인 그래프는 비순환 그래프여야 한다.
데이터 인프라 커스터마이징
데이터 인프라는 조직의 목적과 특성에 따라서 다르게 설계되는데 대부분은 특정 요구 사항을 충족하는 도구와 공급업체를 선택하고 나머지를 자체적으로 구축한다.
각 조직의 제약 조건(비용, 엔지니어링 리소스, 보안 및 법적 리스크 허용 범위)과 그에 따른 트레이드 오프를 이해하고 데이터 인프라에 대한 의사 결정을 내려야 한다.
'Study > Data Engineering' 카테고리의 다른 글
[Apache Spark] "Python3" 명령어 실행 불가로 인한 오류 (0) | 2023.03.11 |
---|---|
[Apache Spark] 로컬 환경에서 Apache Spark 설치하기 (0) | 2023.02.14 |
[airflow] Docker에서 airflow 환경 설정 및 실행하기 (1) | 2023.02.06 |
[요리고 Airflow 도입기] 0. Airflow 사용을 결정한 이유 (0) | 2023.02.01 |
[데이터 파이프라인 핵심 가이드] 1. 데이터 파이프라인 소개 (0) | 2023.01.19 |