최신 데이터 인프라

 

 

파이프라인을 구축하기 위한 제품과 설계를 결정하기 전에 최신 데이터 스택을 구성하는 요소를 이해할 필요가 있다!

 

선택 방법은 다양하지만 업계 표준이 되어 파이프라인 구현에 있어

모범 사례의 발판을 마련한 핵심 요구 사항과 개념은 있다!

 

⬇️⬇️⬇️⬇️⬇️

 

1. 데이터 소스의 다양성

 

2. 클라우드 데이터 웨어하우스와 데이터 레이크

 

3. 데이터 수집 도구

 

4. 모델링 도구 및 프레임워크

 

5. 워크플로 오케스트레이션 플랫폼

 

 

 

데이터 소스의 다양성

 

대부분 조직에는 수백 개는 아니더라도 수십 개의 데이터 소스가 있으며, 이를 통해 분석 작업을 수행할 수 있다

 

소스 시스템 소유권

 

분석 팀은 조직이 구축하고 소유한 소스 시스템과 타사 도구 및 공급업체에서 데이터를 수집 하는 것이 일반적이다

 

ex.

 

전자상거래 회사는 고객 장바구니 데이터를 앱과 연결된 PostgreSQL 데이터베이스에 저장할 수 있고

Google Analytics와 같은 타사 웹 분석 도구를 사용하여 웹 사이트의 사용을 추적할 수도 있음

 

두 데이터 소스(PostgreSQL, Google Analytics)를 함께 사용하면 구매까지 이어지는 고객 행동을 완벽하게 파악할 수 있음

 

=> 이러한 고객 행동의 분석으로 끝나는 데이터 파이프라인은 두 소스 모두에서 데이터를 수집하면서 시작됨

 

데이터 수집(data ingestion)이라는 용어는 한 소스에서 데이터를 추출하여 다른 소스로 로드하는 것을 의미함

 

 

소스 시스템이 위치하는 곳이 어디인지를 이해하는 것은 여러 가지 이유로 중요함

 

1. 타사 데이터 소스에 위치한 데이터를 엑세스하려고 한다면 엑세스 방법에 제한이 있을 수 있음

(대부분의 솔루션 공급업체는 REST API를 통한 데이터 접근은 제공하지만 SQL 데이터베이스 형태까지 직접 엑세스 X)

 

2. 내부적으로 구축된 시스템은 엑세스 방법뿐만 아니라 데이터를 사용자가 필요로 하는 형태에 맞추어 정의하는 등의 더 많은 기회를 분석팀에 제공할 수 있음

 

수집 인터페이스 및 데이터 구조

 

소스 데이터를 소유한 사람이 누구든 관계없이 데이터 엔지니어가 새로운 데이터 수집을 구축할 때 가장 먼저 알아보는 것은 소스 데이터를 얻는 방법과 형식이다

 

데이터에 대한 인터페이스가 무엇인지 먼저 살펴봐야하는데 일반적으로는

 

• Postgres 또는 MySQL 데이터베이스와 같은 애플리케이션 뒤에 있는 데이터베이스
  
  
• REST API와 같은 시스템 상단의 추상화 계층
  
  
• Apache Kafka와 같은 스트림 처리 플랫폼
  
  
• 로그, 쉼표로 구분된 값(csv) 파일 및 기타 플랫 파일을 포함하는 공유 네트워크 파일 시스템(NFS) 또는 클라우드 스토리지 버킷
  
  
• 데이터 웨어하우스 또는 데이터 레이크
  
  
• HDFS 또는 HBase 데이터베이스의 데이터
  
  

등이 있고 

 

이러한 인터페이스뿐만 아니라 데이터 구조도

 

• REST API의 JSON
  
  
• MySQL 데이터베이스의 잘 구성된 데이터
  
  
• MySQL 데이터베이스 테이블의 열 내의 JSON
  
  
• 반정형화된 로그 데이터
  
  
• CSV, 고정 폭 형식(FWF) 및 기타 플랫 파일 형식
  
  
• 플랫 파일의 JSON
  
  
• Kafka의 스트림 출력

 

와 같이 다양하다

 

 

잘 구성된 데이터는 작업하기는 가장 쉬울 수 있지만, 그런 데이터는 일반적으로 애플리케이션이나 웹 사이트를 위해서

정형화되어 있다!

 

=> 분석 프로젝트에 더 적합한 형태로 정형화하기 위해서는 데이터 수집 외에도 클렌징, 변환 작업 등의 추가 단계가

파이프라인에 필요할 수 있다

 

JSON과 같은 반정형 데이터가 점점 보편화 되고 있으며 속성-값 구조와 객체의 중첩(nesting) 구조의 이점을 가지고 있다!

 

=> 하지만 관계형 데이터베이스와 달리 같은 데이터셋 안의 데이터 구조가 모두 동일하다는 보장은 X

 

(파이프라인에서 누락되거나 불완전한 데이터를 처리하는 방법은 상황에 따라 달라지며 데이터 유연성이 증가할수록 점점 더 많이 필요함)

 

비정형 데이터는 일부 분석 작업에 흔히 사용되는데 자연어 처리(NLP) 모델은 교육 및 검증 작업을 위해 방대한 양의 텍스트 데이터를 필요로 하고 컴퓨터 비전(CV) 프로젝트에는 이미지와 비디오 콘텐츠가 필요하다

 

데이터 사이즈

 

페타바이트 규모의 큰 데이터셋만 중요시되는게 아니라 크고 작은 데이터셋을 함께 수집하고 모델링하는 것이 일반적이다

 

=> 파이프라인의 각 단계를 설계할 때 데이터 사이즈를 고려해야 하지만 사이즈가 크다고 가치가 높은건 X

 

데이터 클렌징 작업과 유효성 검사

 

데이터 소스가 매우 다양하듯이, 소스 데이터의 품질도 매우 다양함

 

=> 소스 데이터의 한계와 결함을 이해하고 파이프라인의 적절한 부분에서 해결해주는 것이 중요함

 

지저분한 데이터에는 공통적인 특성이 있다!

 

• 중복되거나 모호한 레코드
• 고립된 레코드
  
  
• 불완전하거나 누락된 레코드
  
  
• 텍스트 인코딩 오류
  
  
• 일치하지 않는 형식(예 : 대시(-)가 있는 전화번호와 없는 전화번호)
• 레이블이 잘못되었거나 레이블이 지정되지 않은 데이터

물론 소스 시스템에는 데이터 유효성 문제 외에도 수많은 다른 문제가 있음

 

=> 데이터 클렌징과 유효성을 보장해주는 완벽한 방법은 없지만 현재 데이터 생태계에는 주요 특성과 접근 방식이 있다!

 

1. 최악을 가정하고 최상을 기대하라

 

: 입력 데이터셋에 수많은 유효성 및 일관성 문제가 있지만 깨끗한 출력을 위해 데이터를 식별하고 정리하는 파이프라인을 구축한다고 가정함

 

2. 가장 적합한 시스템에서 데이터를 정리하고 검증하라

 

: 때로는 데이터를 원본 그대로 데이터 레이크에 로드하고 나중에 파이프라인에서 정형화 및 정리에 대해 걱정하는 것이 좋을 수 있음 (데이터 클렌징과 검증 프로세스를 서두르지 말고 올바른 작업에 올바른 도구를 사용해야함!)

 

3. 자주 검증하라

 

: 파이프라인의 데이터를 초기에 정리하지 않았을 때 데이터 검증을 파이프라인이 끝날 때까지 기다리지 않아야 한다

(파이프라인이 끝날 때 데이터를 검증하면 어디에서 문제가 발생했는지 파악하기가 어려움)

 

=> 반대로, 파이프라인 초기에 데이터를 검증을 했다고 해도 이후 단계에서 모든 것이 잘 진행될 것이라고 가정하지 말아야 함!

 

소스 시스템의 지연 시간 및 대역폭

 

소스 시스템에서 대량의 데이터를 자주 추출하는 것은 최신 데이터 스택의 일반적인 사용 사례임

 

파이프라인의 데이터 추출 단계는 API 속도 제한, 연결 시간 초과, 느린 다운로드 및 시스템에 대한 부담이 있음

=> 실제로 대량의 데이터를 자주 추출하는게 어려운 일!!

 

대부분 데이터 파이프라인에서는 데이터 수집이 첫 번째 단계임

따라서, 소스 시스템과 해당 데이터의 특성을 이해하는 것이 파이프라인을 설계하고 인프라와 관련된 결정을 내리는 첫 번째 단계이다

 

 

클라우드 데이터 웨어하우스 및 데이터 레이크

 

 

• 클라우드에서 데이터 파이프라인, 데이터 레이크, 웨어하우스 및 분석 처리 구축 및 배포가 쉬워짐
  (더 이상 IT 부서와 대규모 초기 비용에 대한 예산을 기다릴 필요가 없어짐 => 클라우드 공급업체에서 관리해주는 관리 서비스(특히 데이터베이스)가 주류가 됨)
  
  
• 지속적인 클라우드 내 스토리지 비용 감소
  
  
• Amazon Redshift, Snowflake 및 Google Big Query와 같은 확장성이 뛰어난 열 기반 데이터베이스의 등장

 

등의 변화로 퍼블릭 클라우드 공급업체 (Amazon, Google, Microsoft)는 지난 10년 넘게 분석 및 데이터 웨어하우징 변화를 불러 일으켰고 데이터 레이크의 개념을 도입했다

 

데이터 웨어하우스는 사용자가 원하는 질문에 대답할 수 있는 데이터 분석 활동을 지원하기 위해 서로 다른 시스템의 데이터가 모델링되어 저장되는 데이터베이스임!

 

=> 데이터 웨어하우스의 데이터는 리포팅 및 분석 쿼리를 위해 정형화되고 최적화됨

 

데이터 레이크는 데이터가 저장되지만 데이터 웨어하우스처럼 데이터 구조나 쿼리 최적화가 필요 없는 곳이다

 

=> 여기에는 다양한 데이터 유형뿐만 아니라 대량의 데이터가 포함될 가능성이 높음

 

 

동일한 데이터 생태계에서 데이터 웨어하우스와 데이터 레이크 모두를 수용할 수 있는 공간이 있으며, 데이터 파이프라인이 둘 사이에서 데이터를 이동하는 경우가 많다

 

 

 

데이터 수집 도구

 

한 시스템에서 다른 시스템으로 데이터를 수집할 필요성은 거의 모든 데이터 파이프라인에 공통적임

 

=> 데이터 팀은 데이터를 수집할 다양한 데이터 소스를 생각해야 한다!

 

Singer, Stitch, Fivetran과 같은 툴이 널리 보급되어 있음에도 불구하고 조직마다 다르지만 여러 이유로 일부는 자체 프레임워크를 직접 개발하기도 한다

 

데이터 수집은 전통적으로 ELT 또는 ETL 프로세스의 추출 및 로드 단계다

 

=> 일부 도구는 이러한 단계에만 집중하는 반면, 어떤 도구는 사용자에게 몇 가지 변환 기능도 제공함

 

(실제로 대부분 데이터 팀은 데이터 수집 중 수행하는 변환 횟수를 제한하기 때문에 소스로부터 데이터를 추출하고 대상에 로드하는 두 가지 기능을 갖춘 수집 도구를 사용함)

 

 

데이터 변환 및 모델링 도구

 

파이프라인은 머신러닝, 분석 및 리포팅과 같은 새로운 목적을 위해 데이터를 변환하고 모델링하는 작업으로 구성됨

 

데이터 모델링과 데이터 변환이라는 용어는 종종 같은 의미로 사용되는 경우가 있음

 

구별해보자면

 

데이터 변환 : 데이터 변환은 ETL 또는 ELT 프로세스에서 T(Transform)에 해당하는 광범위한 용어이다

 

데이터 모델링 : 데이터 모델은 데이터 분석을 위해 데이터를 이해하고 최적화된 형식으로 정형화하고 정의한다 

(보다 구체적인 데이터 변환 유형)

 

데이터 수집과 마찬가지로 최신 데이터 인프라에는 여러가지 방법론과 도구가 있다

 

일부 데이터 수집 도구는 어느 정도 수준의 데이터 변환 기능을 제공하지만 이러한 기능은 매우 간단한 경우가 많음

=> 좀 더 복잡한 데이터 변환 및 데이터 모델링을 위해서는 dbt와 같이 작업을 위해 특별히 설계된 도구와 프레임워크를 찾는게 바람직함

 

분석 및 보고에 사용되는 데이터 모델은 일반적으로 SQL 또는 GUI 사용자 인터페이스를 통해 정의 및 작성되는데

 

SQL은 데이터 엔지니어와 분석가 모두에게 익숙한 접근성이 높은 언어로 낮은 진입장벽을 제공한다

 

=> 대부분의 경우 GUI 방식의 사용자 인터페이스가 아닌 SQL에서 데이터 모델 구축을 지원하는 변환 프레임워크를 선택하는 것이 바람직함

(훨씬 더 많은 사용자 정의가 가능하고 개발 프로세스에 처음부터 끝까지 관여할 수 있음)

 

 

워크플로 오케스트레이션 플랫폼

 

조직의 데이터 파이프라인의 복잡성과 수가 증가함에 따라 데이터 인프라에 워크플로 오케스트레이션을 도입하는 것이  중요하다!

 

=> 이러한 플랫폼은 파이프라인에서 작업의 스케줄링 및 흐름을 관리해줌

 

워크플로 오케스트레이션 플랫폼은 워크플로 관리 시스템(WMS), 오케스트레이션 플랫폼 또는 오케스트레이션 프레임워크라고도 한다!

 

방향성 비순환 그래프

 

 

거의 모든 최신 오케스트레이션 프레임워크는 파이프라인에서 작업의 흐름과 종속성을 그래프로 나타낸다

 

그러나 파이프라인 그래프에는 몇 가지 특정 제약 조건이 있음

 

1. 파이프라인 단계는 항상 방향성을 가짐

 

=> 하나의 작업 또는 여러 개의 작업으로 시작하고 특정 작업으로 끝남

(실행 경로와 순서를 보장하기 위해 필요)

 

2. 파이프라인 그래프는 비순환(acyclic) 그래프여야 함

 

=> 작업이 이전에 완료된 작업을 다음 작업으로 가리킬 수 없음

(작업은 돌아갈 수 없기 때문에 순환할 수 없고 다음으로만 갈 수 있음)

 

 

이러한 두 가지 제약 조건을 염두에 두고 오케스트레이션 파이프라인은 방향성 비순환 그래프 (DaGs)라는 그래프를 생성!

 

 

위의 DAG는 네 가지 작업이 있는 DAG이고 작업 A가 완료되면 B, C가 실행되고, 둘 다 완료되면 작업 D가 실행된다

 

 

DAG는 작업들의 집합을 나타내며 작업이 수행해야 하는 실제 내용은 이 곳에 저장되어 있지 않다

 

오케스트레이션 플랫폼은 모든 종류의 작업(ex. SQL, 파이썬 등등)을 실행할 수 있음

 

=> 오케스트레이션 플랫폼은 각 작업을 실행하지만 그 작업의 내용은 데이터 인프라 전반에 걸쳐서 서로 다른 시스템에서 실행되는 코드로 존재!

 

데이터 인프라 커스터마이징

 

대부분의 조직은 특정 요구 사항을 충족하는 도구와 공급업체를 선택하고 나머지는 자체적으로 구축함

 

=> 직접 구축하든 구매하든, 고품질의 데이터 파이프라인을 구축하는 데 필요한 고품질의 데이터 인프라를 구축할 수 있음

 

중요한건 제약 조건(비용, 엔지니어링 리소스, 보안 및 법적 리스크 허용 범위)과 그에 따른 트레이드오프를 이해하는 것!!

 

=> 이제 제품 또는 도구를 선택할 때 중요한 의사 결정 사항을 배워보자...