Data Layer Architecture

What is the Data Layer Architecture?

이 글에서 말하는 데이터 레이어 아키텍처란 데이터를 계층화하여 데이터 사용자에게 명확 한 데이터를 제공 할 수 있도록 도와주는 레이어 아키텍처입니다. 보통 데이터 레이어라고하면 도메인 별 서비스 측면에서의 데이터 레이어 아키텍처나 JS에서 사용하는 데이터 레이어라는 개념이 다뤄집니다.

하지만 제가 말하는 데이터 레이어 아키텍처란 데이터 레이크, 웨어하우스의 경우에서 너무나 많은 데이터가 쌓이기 시작했을 때 데이터 사용자에게 정확한 데이터를 제공하기 위한 데이터 거버넌스 관점에서의 데이터 레이어 아키텍처입니다.

Why we use Data Layer Architecture?

조금 더 자세하게 알아보겠습니다.

다음과 같은 데이터 웨어하우스가 있습니다.

이 글을 보는 사람은 이런 형태의 데이터 웨어하우스 스키마들을 보고 놀랄 수 있지만, 그럼에도 상당히 많은 데이터 관련 업무를 하는 사람들은 스스로의 데이터 웨어하우스와 유사하다는 생각을 할 수 있습니다. 조금 더 나아가면 도메인이나 특정 기준의 측면에서 구분하는 경우도 있습니다.

이러한 데이터 레이어 아키텍처도 꽤 괜찮아 보입니다. 하지만 데이터 레이어를 선택 할 때 염두 할 부분은 “우리가 어떤 목적으로 설계하는가” 입니다. 만약 우리가 서비스를 위한 데이터베이스를 구성한다면 도메인 및 특정 기준의 측면에서 데이터 레이어를 설정하는 건 좋은 방안이 될 수 있습니다. 우리가 서비스를 제공하기 위한 데이터베이스 정규화를 수행하는 것이 이러한 레이어 안에서 벌어지게 될 것입니다. 하지만 우리가 제공하고자 하는 서비스는 “데이터 사용자 및 비즈니스 의사 결정자가 데이터를 사용하여 결과를 도출 할 수 있도록 도와주는” 서비스임을 생각하면 위의 아키텍처가 좋은 아키텍처인지 모호합니다.

대부분의 회사는 서비스를 제공하는 과정에서 많은 도메인을 가지게 됩니다. 예를들면 간단한 쇼핑 앱의 경우에도 상품, 결제, 유저, 장바구니, 리뷰 등 정말 많은 기능이 포함되어 있고 그에 따라 별도의 스키마를 가지게 됩니다. 이러한 경우 우리는 OLTP 데이터 플랫폼을 통해 정확한 서비스 제공를 제공하고자 합니다. 하지만 분석에는 OLAP 데이터 플랫폼을 이용하여 가능한 빠르게 가능한 많은 데이터를 연산하고자 합니다.

만약, OLAP로 설계 된 데이터 웨어하우스에서 도메인 별로 데이터가 나누어지게 되면 불필요한 조인이 많이 발생하게 되고, 원하는 데이터를 탐색하는 경우 많은 시간이 소요 될 수 있습니다. 데이터 웨어하우스 입장에서는 조인을 최소화하기 위해 가능한 컬럼 단위의 데이터 적재를 최대화하고 조회 시 컬럼을 최소화 하는 것이 일반적인 Best Practice입니다.

그리고 데이터 사용자 입장에서 접근 할 수 있는 데이터의 구분이 상당히 중요합니다. 일반적으로 사용하는 데이터베이스의 GRANT를 통한 개별 유저에게 개별 테이블의 권한을 주는 것은 안전 할 수 있지만 상당한 오버헤드를 발생 시킵니다. 그래서 권한 별 혹은 직책 별 데이터 접근 권한을 부여하는 것이 일반적입니다.

이러한 접근 권한을 부여 할 때 도메인 별 레이어는 상당히 복잡한 권한 구분이 필요합니다. 결제 서비스를 조회하고자 하는 데이터 사용자는 언제든지 상품에 대한 데이터 접근이 필요 할 수 있습니다.

그런 이유로 대부분의 경우 도메인 별 데이터 레이어 아키텍처는 추천하지 않습니다.

하지만 도메인 단위의 구분이 불필요한 것은 아닙니다. 데이터 레이어는 실제 데이터에 접근하는 레이어이기 때문에 서비스 제공에 효율적인 방안으로 구성해야 하지만 오너십에 대한 구분에서는 중요한 개념이라고 생각합니다. 다수의 데이터 엔지니어가 작업을 하다보면 필연적으로 주로 맡게되는 도메인이 생기게 됩니다. 모든 데이터 엔지니어가 각 도메인 영역을 나누어 개발을 진행하는 것은 그리 효율적이지 않습니다. 이 경우 해당 도메인에 대한 지식은 개발에 직접 참가한 엔지니어가 가장 잘 알고 있기 때문에 해당 도메인의 오너십을 맡아 메타데이터를 최신화하거나 관리하는것이 가장 효율적인 경우가 대부분입니다.

그러면 우리가 말하는 데이터 레이어 아키텍처인 “데이터 사용자들의 분석을 위한 데이터 웨어하우스 및 레이크”에 적합한 아키텍처에는 어떤 것이 있을까요?

여기서는 “데이터 거버넌스” 관점으로 파악하면 좋겠다는 생각을 했습니다. 데이터 거버넌스에 대한 이해를 위해 데이터 거버넌스에 대한 글을 포함합니다. 데이터 거버넌스 측면에서, 더 나아가 데이터 카탈로그 측면에서 데이터 레이어 아키텍처를 통해 우리가 얻고자 하는 이점은 “데이터 접근 권한에 대한 명확한 기준”과 “데이터 사용자들의 데이터 이해도를 높이는 것(데이터 소스에 대한 탐색, 데이터의 명확한 파악 등)” 등이 있습니다. 여기에는 데이터 레이어의 개념에서 “테이블 명의 명명규칙 정의”가 추가 될 것 같습니다.

이러한 목적을 위한 대표적인 데이터 레이어는 “메달리온 아키텍처” 가 있습니다.

메달리온 아키텍처는 브론즈, 실버, 골드라는 세 단계로 각 데이터를 계층화하는 방법입니다. 각 계층을 지나면서 적재되는 데이터는 조금씩 목적에 가까운 필터를 거치게 되는 것 입니다. 브론즈는 데이터의 raw 데이터 원본을 의미하고 실버 레이어로 넘어오면서 사용되지 않거나 의미가 없는 데이터를 필터링하고 사내 규정에 맞는 컬럼 명으로 변경되게 됩니다. 그 후 골드 레이어로 넘어오면서 실버 레이블의 데이터가 종합되어 비즈니스 단계에서 사용되는 종합 데이터가 됩니다.

이러한 레이어를 도입하여 얻을 수 있는 이점은 다음과 같습니다.

• 데이터의 특성 및 소스를 추적하기 쉽습니다.
  • 해당 데이터가 이전 레이어의 데이터를 사용했음이 명확하기 때문에 추적이 쉽습니다.
  • 특정 레이어는 무조건적으로 이전 레이어의 데이터를 사용하기 때문에 데이터의 특성은 이전 레이어의 데이터 특성을 상속합니다.
• 데이터 사용자에게 개별적인 권한을 줄 수 있습니다.
  • 계층적 구조로 특정 수준 이상의 데이터에만 데이터 사용자가 접근하도록 함으로써 보안적인 측면의 향상과 명확한 직무 별 역할, 체계화 된 데이터 제공이 가능해집니다.
• 각 레이블에서 “처리 된” 정보는 다음 레이블에서의 작업 부하를 줄이고 명확한 데이터 제공이 가능합니다.
  • 각 레이블에서 적절한 필터링과 종합 쿼리를 수행한다면 다음 레이블은 보다 해당 필터링 및 종합에 대한 염두를 하지 않아도 됩니다.
  • 개별 리포트에 대한 쿼리가 짧아 질 것으로 예상됩니다.

일반적으로 메달리온 아키텍처는 “데이터 레이크 레이어 아키텍처”라고 부릅니다. 만약 데이터 환경이 HDFS(혹은 S3)와 Spark 과 같은 처리 프레임워크가 함께 있다면, 저는 데이터 레이크에서 구축하는 것도 괜찮다는 생각을 하고 있습니다. 하지만, 이 과정에서 연산량에 비례한 비용을 지출해야하는 위험성이 있다면 웨어하우스 단계에서 진행하는 것도 괜찮다고 생각합니다. 물론, 동일한 raw 데이터를 별도의 스토리지에 저장해놓는 로직을 포함해서 말입니다.

How

데이터 레이어를 적용하려면 제가 생각하기에 가장 중요한 원칙이 있습니다.

바로 동일 레이어 및 이후 레이어에서 파생되는 데이터를 만들지 않는다는 조건에 부합해야 하는 것 입니다. 이유는 만약 이전 레이어 혹은 동일 레이어의 데이터를 참조하게되면, 데이터는 명확한 계층 구조가 유지되지 않고 끊임없이 분산 될 가능성이 있기 때문입니다.

물론 이 원칙에 치명적인 단점이 있습니다.

• 유사한 정보를 얻기 위해 테이블이 분리 되어야 할 수 있다.
• 불필요한 필터링이 있을 수 있다.

이 외에도 단점이 있을 수 있지만 현재 생각나는 정보 기준으로 위와 같은 문제가 있음을 생각해 낼 수 있었습니다. 그런데 중요 한 점은 우리가 데이터 레이어를 적용하는 이유는 정확한 정보와 불필요한 필터링 제거입니다. 그런데 왜 위와 같은 문제가 발생 한 걸까요?

원인은 이전 레이어가 충분히 하위 레이어에 파생 될 가능성을 포함하지 않는게 아닐까? 로 귀결된다고 생각합니다. 레이어링을 할 때는 많은 연산을 한번에 수행하면 안됩니다. 이 경우에는 raw 데이터에서 바로 리포트를 위한 데이터 종합이 발생한다고 생각 할 수 있죠. 가능한 다음 레이어를 넘길 때 활용에 용이한 형태로 넘기는 것을 우선적으로 생각해야 합니다.

이러한 이유가 “메달리온 아키텍처” 를 고작 3레이어로 만들게 된 이유이지 않을까 생각됩니다. 레이어가 많으면 많을수록 위에서 말한 규칙은 지켜지기 어렵습니다. 예를 들어 극단적으로 레이어를 길게 만들었을 때, 5번째 레이어의 데이터를 6번째 레이어로 세분화 시킬 때 7번째 레이어에서 얼마나 세분화 될 지 추정해야 6번째 레이어에서 가져 갈 세분화 및 종합 정도등을 유추 할 수 있습니다.

저는 대부분의 데이터는 메달리온 아키텍처와 같이 3단계로 나누어 질 수 있으며, 별도의 BI 툴 및 임시 뷰/테이블과 같이 더 이상 쪼개어지지 않는 한계를 포함하여 4개 레이어로 표현가능하다고 생각합니다.

Detail

이제 각 레이어에 입력 될 데이터에 대해 예제를 만들어보고자 합니다. 기본은 메달리온 아키텍처을 채택하고, 추가적으로 서비스 및 데이터 활용 형식에 따라 사용 할 수 있는 Platinum이라는 단계를 추가했습니다.

Bronze

Bronze 레이어는 필수적으로 다음과 같은 데이터가 들어가야 합니다.

• 소스 데이터( 타 데이터베이스, Kafka 토픽, Third-party, 데이터 레이크 )에서 가져 온 raw 데이터
  • 여기서는 필수적으로 raw한 데이터를 가져오도록 강제합니다. 이유로는 타 데이터베이스 특히 서비스에 연결 된 데이터베이스라면 불필요한 쿼리를 사용하는 것은 자제하는게 좋습니다.
• 무조건 정제가 되지 않은 상태

Silver

Silver 레이어는 필수적으로 다음과 같은 데이터가 들어가야 합니다.

• Bronze 레이어에서 파생 된 데이터임이 명확한 데이터
• 불필요한 데이터를 필터링하거나 구분이 명확하다면 해당 구분에 대해 쪼개어진 형태의 데이터
• 가능한 종합이 진행되기 전의 데이터를 의미하나 “종합되지 않으면 사용 할 수 없는” 데이터는 어떻게 다룰지 고민이 됨
• 절대 조인이 사용되지 않은 형태

Gold

Gold 레이어는 필수적으로 다음과 같은 데이터가 들어가야 합니다.

• Bronze 또는 Silver에서 파생 된 데이터임이 명확한 데이터
• 명확한 목적을 가지고 만들어진 데이터

Platinum

• 더 이상 쪼개어지지 않는 데이터 ( 어디에도 파생되지 않는 것이 명확한 데이터 )
• 명확한 목적이 있는 데이터임이 명확한 데이터
• 주기적으로 사용성 검증이 필요 한 데이터

위와 같은 레이어링이 명확하게 지켜진다면 데이터의 사용성이 향상 될 것이라고 생각합니다.

참고

• https://www.databricks.com/kr/glossary/medallion-architecture
• https://learn.microsoft.com/ko-kr/azure/databricks/lakehouse/medallion
• https://www.linkedin.com/pulse/medallion-architecture-amit-kumar-9rxde/