데이터 플랫폼 설계와 구축 | 02. 데이터 웨어하우스만이 아닌 데이터 플랫폼인 이유 | 데이터 플랫폼에서의 데이터 수집,처리,엑세스 방식

데이터 수집

애저 데이터 팩토리와 같은 관리형 서비스를 사요하면 데이터 플랫폼이나 데이터 웨어하우스로 데이터를 수집하는 파이프라인은 비교적 쉽게 만들 수 있다. ... 그러나 데이터 수집 파이프라인이 동작하는 방식에서 클라우드 데이터 플랫폼과 클라우드 데이터 웨어하우스 구현 간에 근본적인 차이점이 있다.

클라우드 데이터 웨어하우스만 활용한 사례

• 마케팅 캠페인 데이터(MYSQL) - 애저 데이터 팩토리 서비스 - 애저 시냅스 (데이터 스토리지와 처리)
• 클릭 스트림 로그 - 애저 데이터 팩토리 서비스 - 애저 시냅스 (데이터 스토리지와 처리)

1. MYSQL 연동 서비스를 통해서 캐페인 데이터를 입력 받는다.
2. DW에서 저장할 스키마에 맞게 변경한다. 입력 데이터를 그대로 유지하기도 한다.
3. 데이터 팩토리를 출력 데이터 스키마를 기반으로 dst DW에 신규 테이블을 만든다.

데이터 세트의 중요한 속성은 스키마다. 데이터 팩토리가 MYSQL에서 애저 시냅스로 데이터를 적재할 수 있도록 하려면 src, dst 테이블의 스키마를 알아야 한다. 이 정보들은 미리 필요하다. 즉, 파이프라인이 실행되기 전에 파이프라인에서 스키마를 사용할 수 있어야 한다. 구체적으로는, 입력 데이터 소스에 대한 스키마는 데이터 팩토리에서 자동으로 유추할 수 있지만, 출력 스키마, 특히 입출력 스키마 간 매핑 정보는 사전에 제공되어야 한다.

클라우드 데이터 플랫폼 사례

• 마케팅 캠페인 데이터(MYSQL) - 애저 데이터 팩토리 서비스(수집) - 애저 블록 스토리지(저장) -(읽기/쓰기) - 애저 데이터브릭스(처리) -(읽기) - 애저 시냅스 (데이터 스토리지와 처리)
• 클릭 스트림 로그 (CSV, 100s GBs, SFTP) - 애저 데이터 팩토리 서비스(수집) - 애저 블록 스토리지(저장) -(읽기/쓰기) - 애저 데이터브릭스(처리) -(읽기) - 애저 시냅스 (데이터 스토리지와 처리)

데이터 플랫폼 아키텍처에서 수집 데이터의 기본 데스티네이션은 애저 블롭 스토리지이며, 이 유스케이스에서는 무한 확장 가능한 파일 시스템으로 생각할 수 있다.

1. 데이터 팩토리를 MYSQL 소스에 연결해 테이블 스키마를 가져오고 입력 데이터 세트를 생성한다.
2. 데이터 팩토리는 데이터 싱크 유형에 따라 입력 데이터 세트를 해당 출력 데이터 세트로 변환한다.
3. 데이터 팩토리는 애저 블롭 스토리지에 텍스트 파일을 새로 저장한다. 이 작업에서는 스키마가 필요하지 않다.

이 수집 파이프라인과 이전 파이프라인의 주요 차이점은 , 애저 블롭 스토리지 데이터 팩토리 서비스에서 스키마를 미리 지정할 필요가 없다는 점이다. 이 유스케이스에서 MYSQL에서 소스 컬럼 및 데이터 형식에 상고나없이 수집한 데이터가 애저 블록 스토리지에 텍스트 파일로 저장된다. 데이터 처리를 위한 추가 계층이 있다. 이 계층은 애저 데이터 브릭스 플랫폼의 아파치 스파크를 사용해 구현했으며, 소스 텍스트 파일을 효율성이 높은 바이너리 형식으로 변환하는 일을 한다. 이렇게 하면 애저 블롭 스토리지에서 텍스트 파일의 유연성과 바이너리 형식의 호율성을 함께 얻을 수 있다.
-> 유연하게 텍스트로 저장하고, 바이너리로 효율적으로 처리하기 위해 변환한다.

이 설계에서는 출력 스키마와 소스 스키마에 대한 매핑 정보를 수작업으로 정의할 필요성이 없어진다. 이 부분은 2가지 측면에서 중요하다.

1. RDBMS에는 수백개의 테이블이 포함될 수 있는데, 수작업으로 인한 오류가 증가할 수 있다.
2. 변경이 발생했을 때 회복성 측면이다.

업스트림 데이터 소스의 변경 관리

소스 데이터는 전혀 정적이지 않다. 마케팅 캠페인 데이터를 담당하는 개발자는 꾸준히 새로운 데이터를 추가할 것이다. 이로 인해 소스 테이블에 신규 컬럼이 추가되거나 컬럼 명이 변경 또는 삭제될 수 있다. 이러한 유형의 변경 사항을 처리하는데 데이터 수집 파이프라인 및 처리 파이프라인 구축은 데이터 아키텍트나 데이터 엔지니어가 가장 중요하게 처리해야하는 작업 중 하나다.

소스 MYSQL 데이터에 신규 컬럼이 추가됐다. 입력 데이터 세트 스키마는 자동으로 조정되지만, 출력 데이터 소스는 조정되지 않는다.

데이터 팩토리는 컬럼 위치에 따른 입출력 컬럼 매핑 방식일 때, 기존 컬럼 위치에 새로운 컬럼의 값이 도착하고 실패하게 된다. 운영 담당자는 출력 데이터 세트 스키마를 수작업으로 변경한 뒤 파이프라인을 다시 시작해야 한다.

일부 데이터베이스의 경우, 스키마 변경 시 테이블 락이 존재하기 때문에 최종 사용자가 사용할 수 없는 상황이 되기도 한다. 그리고 테이블의 크기에 따라서 스키마 변경 작업이 몇 시간 이상 걸리는 경우도 있다. 다수의 데이터 데스티네이션에서 스키마 변경 작업을 일원화된 방식으로 처리할 수 없다보니, 데이터 팩토리나 ETL 툴에서는 플랫폼 운영자가 이 작업을 맡는다.

데이터 플랫폼 구현에서 출력 dst는 애저 블록 스토리지 파일이다. 출력 스키마가 필요하지 않으므로 소스 스키마가 변경되더라도 수집 파이프라인이 신규 스키마를 가진 파일을 생성하면서 계속 작업을 이어 나간다. 하지만 데이터 플랫폼에서도 스키마 변경 처리 작업을 하긴 해야한다. 이는 8장에서 다룬다.

데이터 처리

• 관계형 데이터 : campaign_id, email, unique_code, send_date 컬럼을 가진 테이블 -
• 클릭 스트림 데이터 : timestamp, content_json(json 타입으로 반정형 데이터), other_details

데이터 웨어하우스

데이터 웨어하우스에서는 관계형 데이터와 클릭 스트림 데이터 사이에서 PK로 JOIN할 수 있는 쿼리를 생성해야 한다. 클릭 스트림 데이터의 content_json 필드에 대해서 substring 표현식을 사용해서 복잡한 쿼리를 사용해야만 한다.

ETL 파이프라인에서 미리 파싱하거나, 쿼리 가독성을 위해서 사용자 정의 함수를 등록할 수도 있지만 각각의 단점이 있다. 전자의 방법에 대해서는 ETL 처리에 상당한 시간이 소요될 수 있고, 데이터 양이 많아지면 상당한 비용이 발생할 수 있다는 점이다. 후자의 방법은 별도의 개발 프로세스가 추가되어야 하는 단점이 있다.

게다가 각각의 컬럼을 컬럼 그 자체로 사용하지 못하고 substring을 사용하는 방법은 테스트하기가 어렵고 사용자에게 버그가 노출되어 신뢰도가 떨어지게 된다. 그리고 스토리지 서비스에서 제공하는 다양한 성능 최적화 기법을 사용할 수 없게 된다. 컬럼을 컬럼 그 자체로 사용하지 못하고 커스텀된 방식으로 사용하기 때문이다.

데이터 플랫폼에서의 처리

클라우드는 데이터 웨어하우스 외부의 데이터들을 여러 종류의 분산 데이터 처리 엔진을 사용해 규모에 상관없이 처리할 수 있는 다양한 방법을 제공한다. 이 중 아파치 스파크는 가장 널리 채택 및 사용되는 분산 데이터 처리 엔진 중 하나다. 클라우드 공급 업체에서는 스파크 작업을 실행할 수 있는 일종의 관리 서비스를 제공한다. 애저에서는 데이터브릭스를 제공한다.

애저 데이터브릭스 플랫폼 위에서 실행되는 스파크는 모든 데이터 처리를 담당한다. 아파치 스파크를 사용하면 두 가지 방식으로 데이터를 처리할 수 있다. SQL을 사용해서 데이터를 처리하거나, 파이썬이나 스칼라 등의 범용 프로그래밍 언어를 사용하는 방식을 제공한다.

이렇게 범용적인 프로그래밍 언어로API를 사용할 수 있으면, 캠페인 코드를 추출하는 substring 작업을 별도의 파이썬 함수로 분리하고 테스트할 수 있게 된다. 코드의 모듈화와 테스트 용이성으로 인해 데이터 웨어하우스와는 차별화된 장점을 가져갈 수 있다.

데이터 엑세스

데이터 웨어하우스와 데이터 플랫폼 아키텍쳐 모두 최종 사용자가 데이터에 엑세스할 수 있는 다양한 방법을 제공한다. 전자에서는 순수 SQL 파이프라인을 구축할 수 있고, 후자에서는 스파크를 활용해서 구축할 수 있다.

일반 사용자는 보통 SQL 인터페이스를 활용해서 데이터를 대시보드로 그리는 툴을 사용한다. 고급 사용자나 데이터 분석가들은 기본 분석 도구로 SQL도 사용하고, 애저 데이터브릭스가 제공하는 스파크 SQL을 사용해서 데이터르 조회할 수 있다. 복잡하고 디테일한 데이터를 조회하기 위해서는 반드시 스파크와 같은 툴과 애저 블롭 스트로리지의 파일에 대한 엑세스가 필요하곤 한다.

데이터 웨어하우스만으로는 다양한 사용자의 필요사항을 만족시킬 수 없다. 하지만 클라우드 데이터 플랫폼은 가능하다. 클라우드 데이터 플랫폼에서는 데이터 웨어하우스를 사용할 수도 있고, 스토리지의 원시 데이터도 사용 가능하기 때문이다.

 

데이터 웨어하우스 설계	데이터 플랫폼 설계
관계형 데이터 소스만 있다	정형 데이터, 반정형 데이터가 있는 데이터 소스들이 있다
소스 데이터 통제권과 스키마 변경 관리를 위한 프로세스를 갖추고 있다	다양한 데이터 소스로부터 데이터를 수집해서 사용하려하다. 즉 전체 통제 권한을 갖고 있지 않다.
유스케이스는 BI  리포트 툴과 대화형 SQL 쿼리로 제한된다.	기존의 BI와 데이터 분석 외에도 머신러닝, 데이터 과학유스케이스에도 데이터를 사용하길 원한다.
데이터 사용자 커뮤니티가 한정된다.	업무를 수행하기 위해 데이터를 액세스해야 하는 사용자들이 점점 증가한다.
데이터 볼륨이 크지 않아서 클라우드 데이터 웨어하우스 내부에 모든 데이터를 저장하고 처리하더라도 비용이 합리적이다	데이터 저장 및 처리를 위해 다양한 클라우드 서비스르 사용해 클라우드 비용을 최적화하길 원한다.

 

1. 스키마 변경을 처리하는 방법 : 데이터 웨어하우스 설계와 달리 데이터 플랫폼은 들어오는 데이터에 대한 스키마를 제공할 필요가 없어 스키마 변경을 훨씬 쉽게 처리할 수 있다.

2. 처리가 이루어지는 곳 : 데이터 웨어하우스의 SQL 처리는 간단해 보일 수 있지만, 사용 가능한 데이터 프레임워크의 부족, 확장성, 복잡성, 성능 최적화 제약 등은 데이터 종류가 다양해지거나, 데이터 볼륨이 증가함에 따라 문제가 될 수 있다.

3. 데이터 플랫폼에서 스파크와 같은 분산 데이터 처리 엔진은 대규모 반정형 데이터 세트를 처리할 때 상당한 유연성을 제공한다. 스파크가 파일을 작은 청크로 분할해 여러 병렬 작업을 사용해 각 청크를 처리한다. 

4. 사용자에게 최대의 유용성을 제공한다. 고급 사용자들은 스파크 작업을 통해 데이터 레이크에 엑세스할 수 있으며, SQL 기반 엑세스를 통해서 데이터 웨어하우스의 데이터에도 접근하 수 있다.