Data Catalog 만들기 - Data Catalog에 대해서
이 내용은 Data Catalog 만들기 책을 읽고 1장(Data Catalog란 무엇인가?)와 2장(Data Catalog는 왜 중요한가?)를 읽고 리뷰하는 글 입니다.
Data Catalog란 무엇인가?
이 책의 저자는 Data Catalog라는 용어에 대해서 다음과 같은 문장으료 표현합니다.
- 사용자의 데이터 전달 플랫폼
- 데이터 자산화 도구
- 다양한 데이터 서비스 간의 연계자
Data Catalog는 데이터 사용자들이 필요로 하는 데이터에 대한 접근을 쉽게 도와주고, 단순히 파일 혹은 스키마와 같이 범용적인 형태로 저장되어 있는 데이터를 통합적으로 관리 할 수 있는 자산으로서 변환해주고, 다양한 데이터 서비스에서의 접근을 용이하게 하고 그 결과를 다시 Catalog화 하여 연계하는 역할을 합니다.
Data Lake
저자는 Data Catalog를 설명하기 전에 먼저 Data Lake에 대한 이해가 필요하다고 말하며 관련 설명을 이어나갔습니다. 이 과정에서 원천 데이터를 어떻게 다루어야 하는지, 어떤 환경이 구축되어야 하는지에 대해 이야기를 시작했습니다.
데이터 레이크에 대해 간략하게 적은 포스트가 있습니다.
위 포스트에서는 데이터 레이크에는 “Raw 데이터, 정형/비정형 데이터를 고루 저장하는 하나의 스토리지” 개념으로 보는 경향이 있습니다. 데이터 엔지니어링을 하는 과정에서 현재의 Data Lake라는 개념이 처음 등장했을 때, 원천 데이터를 효율적으로 저장하는 방식으로만 보면 그런 개념으로 보일 수 있습니다.
하지만 중요한 건 이 책에서 말하는 다음과 같은 내용입니다.
- 잘 정리 된 메타데이터 기반 검색
- 즉시 데이터를 조회 할 수 있는 Schema-on-read
- 전사 데이터의 연계 분석
- 다양한 데이터 전처리/분석 도구와의 연계
1 ) 잘 정리 된 메타데이터 기반 검색
이 부분에 관련한 부분은 데이터 디스커버리 툴이라고 생각합니다. 이러한 플랫폼 중 하나인 Datahub 관련 포스트를 작성하고 있습니다.
데이터 디스커버리 툴의 목표는 “다양한 플랫폼에서의 탐색과 검색 서비스 제공”이 가장 큰 이유라고 생각합니다. 이런 점에서 저자가 말하는 잘 정리 된 메타데이터가 의미하는 바는 데이터 디스커버리(대표적으로 Datahub)에서 주요하게 사용되는 다음과 같은 정보라고 생각됩니다.
- Owner
- Tag
- Domain
- TableName
- ColumnName
- ETC
이러한 메타데이터가 잘 정돈되어 있으면, 우리는 검색을 통해 원하는 데이터로의 접근이 가능해집니다.
2 ) 즉시 데이터를 조회 할 수 있는 Schema-on-read
이전에 데이터 중심 애플리케이션 책을 통해 공부하면서 이와 관련한 내용을 공부 한 적이 있습니다.
그 당시 관련 포스트를 작성하면서 책에서 이야기 했던 쓰기 스키마와 읽기 스키마라는 용어로 이 장에서 이야기하는 Schema-on-write와 Schema-on-read에 대해서 공부했습니다.
하지만 그 책을 공부하는 당시만 하더라도 데이터 파이프라인에 대한 명확한 이해가 부족했고 데이터 카탈로그 시스템에 대해 무지했기 때문에 읽기 스키마의 활용에 대해서 잘 이해하지 못했습니다. 그리고 현재 현업을 통해 데이터 거버넌스를 책임지고 관련 작업을 이어가면서 S3라는 스토리지와 그 스토리지를 통해 얻는 Glue 스키마의 활용성에 대해 이해하면서 이 부분이 매우 중요함을 알게 되었습니다.
제가 진행하고 있는 작업 중 데이터 레이어를 구축 업무를 진행하면서 알게 된 내용은 데이터 레이어 아키텍처의 타겟은 데이터 웨어하우스가 아닌 데이터 레이크였다는 사실이였습니다. 사내 데이터 환경에 따라 이러한 부분은 어느정도 유연하게 변경 될 수 있지만, 원천 데이터의 관리를 위해 읽기 스키마를 적극적으로 활용하는 아키텍처는 언젠가 목표로 가져야 할 아키텍처임을 알게 되었습니다.
사담이 길었습니다만, Data Lake의 구축하는 것에 Schema-on-read는 매우 중요한 개념이라고 생각합니다.
3 ) 전사 데이터의 연계 분석
책에서 주요하게 말하는 키워드는 다음과 같습니다.
- 충분한 개방성을 통해 팀 간의 사일로를 최소화 하는 것
- Schema-on-read를 통해 다양한 형태로의 자유로움 활용이 가능하도록 하는 것
- 충분한 성능을 통해 작업의 지연을 최소화 할 것
개방성에 대한 내용에 대해서는 그 범위를 파악하는 방법에 대해 궁금하지만, 그 외에는 매우 공감되는 내용이였습니다.
4 ) 다양한 데이터 전처리/분석 도구와의 연계
이 부분에서는 일반적으로 생각하는 BI 툴, 언어, 플랫폼에 관련 연계가 가능해야 한다고 말합니다. 보통 이런 연계성은 사용하는 Data Lake의 종류에 따라 활용도가 달라지는 부분이라 AWS S3를 사용하는 환경에서는 걱정하지 않을 수 있는 부분이였습니다. 하지만 HDFS와 같은 On-Promise 환경에서의 스토리지를 사용한다면 이 부분에 대한 주의가 필요 할 것 같습니다.
무엇보다 마지막에 나온 한 문장은 크게 공감했습니다.
원천 데이터 뿐만 아니라 가공 데이터에 대해서도 Data Lake에서 활용 할 수 있도록 해야한다.
Data Lake 플랫폼에서 Data Catalog의 역할
저자는 Data Catalog가 Data Lake의 게이트웨이가 된다고 말합니다. 사용자는 Data Catalog를 이용하여 Data Lake에 적재 된 데이터를 검색하고, 배경지식을 이해하며, 실 데이터를 가져오는 동작을 할 수 있습니다. 즉, 사용자가 필요로 하는 데이터를 찾고, 이해하고, 확보하는 사용자의 데이터 전달 플랫폼입니다.
또한 Data Catalog가 있어야 Data Lake에 담긴 데이터는 자산이 된다고 합니다.
가장 쉽게 예시를 들 수 있는 것은 Glue라고 생각합니다.
AWS S3를 통해 우리는 보관하고 싶은 파일을 S3 버킷 내에 저장하게 됩니다. 이 후 S3 버킷의 해당 키를 가진 파일에 대한 정보를 보면 정말 간단한 정보만 조회 할 수 있습니다. 예를 들면, 파일의 크기나 생성 시간 등과 같은 정보입니다.
하지만 우리가 알고 싶은건 저장한 parquet, csv 등에 실제로 담겨있는 데이터에 대한 컬럼과 같은 스키마 정보입니다. 혹은 그 안의 데이터에 대한 프로파일링 정보 등 일 수 있습니다. 그리고 AWS에서는 그러한 동작을 위해서 Glue 라는 별도의 서비스를 제공합니다. Glue는 S3의 키 경로를 통해 담겨있는 파일에 대한 스키마를 생성해줍니다. 그리고 해당 스키마에 대해서 Owner, Tag등을 설정 할 수 있도록 지원해줍니다.
이렇게 스키마를 생성하면 다양한 플랫폼에서 S3에 담겨있는 파일에 대한 정보를 얻을 수 있습니다. Redshift에서 Spectrum으로 조회 하는 것과 Datahub에서 Glue 스키마 정보를 가져오는 것이 이러한 부분이라고 생각합니다.
정리하면 Data Catalog는 다음과 같은 이점이 있습니다.
- Data Lake에 담긴 데이터에서 메타데이터를 수집하여 사용자가 검색 및 활용하기에 좋은 형태로 만들어줍니다.
- Data Lake에 담긴 데이터에 대해 제목, 설명, 태그, 계보 등을 활용 할 수 있도록 해줍니다. 즉 자산화를 할 수 있습니다.
- 다양한 플랫폼에서 해당 Data Lake에 담긴 데이터에 대한 활용이 가능하게 만듭니다.
저는 Glue로 예시를 들었기에 하나의 스키마 단위에서 사용 할 수 있다고 생각하고 있습니다.
Data Catalog의 활용 절차
저자는 상품 카탈로그와 비교하는 글을 적었지만, 저는 간략하게 Data Catalog를 활용하는 사용자에 대해서만 추려서 적도록 하겠습니다.
- Data Catalog를 사용하는 사용자는 필요한 데이터를 찾기 위해, 업무 명 등의 키워드로 검색하거나, 카테고리 분류를 통해 필요한 데이터를 검색합니다.
- 검색 결과에서 데이터를 선택하고 ‘Data Catalog’의 다양한 정보를 조회하여 데이터의 배경지식(Context)를 이해합니다.
- 데이터를 즐겨찾기에 추가하거나, 실 데이터 조회를 위해 ‘대화형 쿼리 서비스’를 사용합니다.
- 관련하여 후기를 작성하거나 평가를 진행합니다.