http://www.yes24.com/product/goods/106729751
데이터 파이프라인 핵심 가이드 - YES24
데이터 파이프라인의 모든 단계를 기초부터 탄탄하게 설명한다!데이터 파이프라인은 데이터 분석의 성공을 위한 기이다. 수많은 다양한 소스에서 데이터를 이동하고 컨텍스트를 제공하기 위해
www.yes24.com
책 목차:
01_데이터 파이프라인 소개: https://inhyeok-blog.tistory.com/m/28
02_최신 데이터 인프라: https://inhyeok-blog.tistory.com/29
03_일반적인 데이터 파이프라인 패턴: https://inhyeok-blog.tistory.com/30
04_데이터 수집: 데이터 추출:
05_데이터 수집: 데이터 로드:
06_데이터 변환하기:
07_파이프라인 오케스트레이션:
08_파이프라인의 데이터 검증:
09_파이프라인 유지 모범 사례:
10_파이프라인 성능 측정 및 모니터링:
데이터 파이프라인을 구축하는 모범 사례를 구성하는 핵심 요구사항과 개념이 존재한다. 이번 장(02_최신 데이터 인프라)에서는 아래의 최신 데이터 인프라의 핵심 구성 요소들에 대해서 살펴보고, 앞으로의 장(03_일반적인 데이터 파이프라인 패턴 ~ )에서는 데이터 인프라의 핵심 구성요소들이 데이터 파이프라인 설계 및 구현에 어떻게 영향을 미치는지 살펴보겠다.
최신 데이터 인프라의 핵심 구성 요소
- 데이터 소스의 다양성
- 클라우드 데이터 웨어하우스와 데이터 레이크
- 데이터 수집도구
- 모델링 도구 및 프레임워크
- 워크플로 오케스트레이션 플랫폼
1. 소스의 다양성
대부분의 조직은 다양한 데이터 소스로 부터 데이터를 수집한다.
- 소스 시스템 소유권
데이터는 타사의 시스템(일반적으로 RestAPI로 제공된다.), 타사의 웹 분석 도구(Google Analytics 등), 사내의 DB등에서 수집하는 것이 일반적이다. 이때 소스 시스템이 위치하는 곳이 어디인지는 이해하는 것은 다음과 같은 이유로 중요하다.
첫째, 타사의 시스템의 데이터를 받아오는 경우, RestAPI(최근에는 GraphQL을 제공하기도 한다.)를 통한 접근만 가능하기 때문에 SQL로 접근하는 형식과는 다르게 제한적인 데이터만 받아올 수 있을 수 있고, 데이터의 세부적인 사항까지 사용자 환경에 맞게 지정하기란 더욱 어렵다.
둘째, 내부적으로 구축된 시스템은 더 높은 접근 자유도를 가진다는 측면에서 유리하지만, 의도하지 않은 부하가 발생하거나 데이터를 점진적으로 로드할 수 있는지 여부까지 다양한 과제가 발생할 수 있다.
- 수집 인터페이스 및 데이터 구조
데이터를 수집하는 입장에서 가장 우선적으로 고려할 점은 데이터의 인터페이스와 구조이다.
일반적인 데이터 인터페이스 예시
- Postgres 또는 MySQL 데이터베이스와 같은 애플리케이션 뒤에 있는 데이터베이스
- REST API와 같은 시스템 상단의 추상화 계층
- Apache Kafka와 같은 스트림 처리 플랫폼
- 로그, 쉼표로 구분된 값(csv) 파일 및 기타 플랫 파일을 포함하는 공유 네트워크 파일 시스템(NFS) 또는 클라우드 스토리지 버킷
- 데이터 웨어하우스 또는 데이터 레이크
- HDFS 또는 HBase 데이터베이스의 데이터(하둡 기반의 분산환경)
일반적인 데이터 구조 예시
- REST API의 JSON
- MySQL 데이터베이스의 잘 구성된 데이터
- MySQL 데이터베이스 테이블의 열 내의 JSON
- 반정형화된 로그 데이터
- CSV, 고정 폭 형식(FWF) 및 기타 플랫 파일 형식
- 플랫 파일의 JSON
- Kafka의 스트림 출력
각 인터페이스와 데이터 구조는 다양한 장단점이 있다. 예컨데, 잘 구성된 데이터 조차도 애플리케이션이나 웹 사이트를 위해 정형화되어 있다. 따라서 분석 프로젝트를 위해 데이터 클렌징, 변환 작업 등의 추가 단계가 파이프라인에서 필요하다.
반정형 데이터(JSON 등)이 보편화 되고있다. 이는 Key-Value 구조/객체의 중첩 구조의 이점을 가지고 있지만, 데이터셋 안의 데이터 구조가 동일하지 않다. 따라서 누락되거나 불완전한 데이터를 처리해 줘야한다.
비정형 데이터(영상, 방대한 텍스트, 이미지 등) 역시 인공지능을 위해서 종종 사용되곤 한다.
- 데이터 사이즈
반드시 큰 규모의(페타바이트 정도의) 데이터 세트가 중요한 것은 아니다. 실제로는 대부분의 조직에서 큰 데이터보다 작은 데이터 세트를 더 중요시 여긴다. 또한 크고 작은 데이터 세트를 같이 모델링 하는 것이 일반적이다.
- 데이터 클렌징 작업과 유효성 검사
"garbage in, garbage out"
소스 데이터의 한계와 결함을 이해하고, 적절한 부분에서 해결해 주는 것이 중요하다.
지저분한 데이터
- 중복되거나 모호한 레코드
- 고립된 레코드
- 불완전하거나 누락된 레코드
- 텍스트 인코딩 오류
- 일치하지 않는 형식(예: 대시(-)가 있는 전화 번호와 없는 전화번호)
- 레이블이 잘못되었거나 레이블이 지정되니 않은 데이터
데이터 클렌징과 유효성을 보장해주는 주요 접근방식이 몇가지 있으며 자세한 내용은 이 책의 후반부에서 다룬다.
최악을 가정하고 최상을 기대하라
순수한 데이터는 없다. 하지만 깨끗한 출력을 위해 파이프라인이 데이터를 식별하고 정리해 준다고 가정한다.
가장 적합한 시스템에서 데이터를 정리하고 검증하라
때로는 데이터 원본을 데이터 레이크에 로드하고 나중에 파이프 라인에서 정형화 및 정리를 고려하는 것이 좋을 수 있다. 또한 최신 파이프라인은 ETL보다 ELT를 선호하기도 한다. 데이터 클렌징과 검증 프로세스를 올바른 작업에 올바른 도구를 사용해야 한다.
자주 검증하라
파이프라인이 끝날 때 검증하면 어디서 문제가 발생했는지 파악하기 어렵다. 반대로, 파이프라인 초기에 데이터 검증을 해도 이후에 모든 것이 잘 진행될 것이라고 가정하지 말아야 한다.
- 소스 시스템의 지연 시간 및 대역폭
소스 시스템에대 대량의 데이터를 자주 추출하는 것은 자주 있는 일이다. 하지만 이는 소스 시스템에 부하를 줄 수도 있고, 실제로 통신시간 및 비용 문제로 분리하게 프로젝트를 진행해야 할 수 도 있다.
2. 클라우드 데이터 웨어하우스 및 데이터 레이크
Public Cloud Provider의 등장으로 초기비용이 감소하고 Managed Serive가 주류가 되었다. 또한 클라우드 내 스토리지 비용이 감소했으며, 확상성 뛰어난 열 기반 데이터 베이스(Big Query, Snowflake 등)가 등장했다.
데이터 웨어하우스: 데이터 분석활동을 지원하지 위해 서로 다른 시스템의 데이터가 모델링 되어 저장되는 데이터베이스로, 데이터를 리포팅 및 분석 쿼리를 위해 정형화되고 최적화된다.
데이터 레이크: 다양한 데이터 유형, 대량의 데이터가 저장되는 곳으로 데이터 구조나 쿼리 최적화가 필요 없는 곳이다.
3. 데이터 수집 도구
데이터 수집은 상용 및 오픈 소스 도구들을 이용할 수 있다.
- Singer(https://www.singer.io/)
- Stitch(https://www.stitchdata.com/)
- Fivetran(https://www.fivetran.com/)
일부 팀은 데이터를 수집하기위해 직접 코드를 작성하기도 하고, 일부는 자체 프레임워크를 개발하기도 한다. 이는 비용, 법적/보안적 우험에 대한 우려, 직접 구축하는 분위기 등의 이유이다. 이에 대해서 5장에서 더 자세히 살펴본다.
데이터 수집은 ETL/ELT의 E와 L단계이다. 일부 도구는 이런 단계에만 집중하기도 하고, 어떤 도구는 변환 기능도 제공한다. 하지만 변환 기능이 횟수 제한이 있는 경우가 많아서 대부분의 팀은 E+L 기능만 포함된 도구를 사용한다.
4. 데이터 변환 및 모델링 도구
데이터 변환: ETL에서 T(Transform)에 해당하는 광범위한 용어로, 타임스탬프를 다른 시간대로 변환하는 간단한 일부터 특정 지표를 생성하는 것까지 다양하다.
데이터 모델링: 데이터 변환 유형으로, 데이터 분석을 위해 데이터를 최적화 해서 정형화하고 정의한다. 데이터 모델은 일반적으로 데이터 웨어하우스에서 하나 이상의 테이블로 표시된다.
변환에도 다양한 도구가 있다. 이때 앞서 언급한 데이터 수집도구를 이용해 간단한 변환(개인정보를 목적지까지 해쉬 값으로 변환하는 것)을 할 수도 있지만, 더 복잡한 변환과 모델링을 위해서는 dbt(https://www.getdbt.com/)와 같은 특수한 프레임워크를 쓰는 것이 낫다. 또한 데이터 변환은 SQL이나 Python과 같은 언어로 작성할 수 있다.
5. 워크플로 오케스트레이션 플랫폼
데이터 파이프라인의 복잡성과 수가 증가함에 따라 워크플로 오케스트레이션 플랫폼(=워크플로 관리 시스템(WMS)&오케스트레이션 플랫폼&오케스트레이션 프레임워크)을 도입하는 것이 중요하다. 이는 작업의 스케줄링 및 흐름을 관리해 준다.
아파치 에어플로우, Luigi, AWS Glue와 같은 플랫폼은 일반적인 용도(ML, 단순변환, 도커 컴포즈 등)로 설계되었고, Kubeflow와 같은 구체적인 사용 사례(ML)와 플랫폼(Docker, k8s)을 위해 설계되었다.
- 방향성 비순환 그래프
파이프라인에서 작업의 흐름과 종속성을 그래프로 나타낸다. 이때 파이프라인 그래프는 두가지 제약조건이 있다.
첫째, 파이프라인 단계는 항상 방향성을 가진다. 즉, 모든 종속 작업이 완료되어야만 그 다음 작업이 실행된다.
둘째, 파이프라인 그래프는 비순환 그래프여야한다. 즉, 작업은 순환할 수 없고 다음으로만 갈 수 있다.
이러한 제약조건 때문에 오케스트레이션 파이프라인은 방향성 비순환 그래프(DaGs)라는 그래프를 생성한다.
DAG는 작업의 집합을 나타내며 작업이 수행해야하는 실제 내용(SQL or Python 스크립트)는 외부에 저장되어있다. 오케스트레이션 플랫폼은 각 작업을 실행하지만, 그 작업의 내용은 데이터 인프라 전반에 걸쳐서 서로 다른 시스템에서 실행되는 스크립트로 존재하는 것이다.
6. 데이터 인프라 커스터마이징
데이터 인프라는 조직에 따라 모두 다르다. 따라서 제약 조건(비용, 엔지니어링 리소스, 보안 및 법적 리스크 허용 범위)과 그에 따른 트레이트오프를 이해하는 것이 중요하다.