Databricks에서 Zalando가 AI 및 분석을 위한 통합 데이터 기반을 구축한 방법

유럽 최고의 패션 및 라이프스타일 온라인 플랫폼인 Zalando에서는 유럽 전역의 7,000개 이상의 브랜드 및 파트너와 5천만 명 이상의 활성 고객을 연결하는 방대한 디지털 생태계를 운영합니다. 모든 고객 상호 작용(검색, 주문, 반품 등)은 개인화된 추천부터 물류 최적화에 이르기까지 의사 결정에 영향을 미치는 데이터의 맥박을 생성합니다.

이러한 규모로 운영하는 것은 고유한 과제를 안고 있습니다. 당사의 데이터 환경은 방대하고 복잡하며, 중앙 데이터 레이크로 테라바이트의 이벤트를 스트리밍하는 마이크로서비스 아키텍처에서 공급됩니다. 이 아키텍처를 통해 빠르게 확장할 수 있었지만, 거버넌스가 어려워지고 트랜잭션 데이터(일상적인 비즈니스 운영)와 분석 데이터(의사 결정 통찰력) 간의 구분이 모호해졌습니다.

수년 동안 우리는 소유권을 분산하여 이 문제를 해결하기 위해 분산된 접근 방식을 추구해 왔으며, 이를 통해 "결제" 또는 "물류"와 같은 도메인 팀이 자체 데이터 제품을 관리할 수 있었습니다. 중앙 집중식 거버넌스 구조는 팀에 대한 관리 가능한 부하를 보장하고 비즈니스 위험을 방지하기 위해 이 설정에서 중요합니다. 또한, 진실을 정의하는 통합된 계층이 없으면 메트릭 불일치 문제에 직면하게 됩니다. 마케팅 대시보드의 "순수익"이 재무 보고서와 다른 이유는 무엇일까요? 메트릭이 사일로에 존재하기 때문에 수명 주기 전반에 걸쳐 재사용을 위해 거버넌스하고 검색 가능하고 신뢰할 수 있는지 확인하기 어렵습니다.

이 게시물에서는 Zalando가 Databricks 플랫폼의 전체 기능을 활용하여 이를 달성하는 방법을 공유할 것입니다. 트랜잭션 데이터와 분석 데이터 간의 격차를 해소하는 통합 의미론적 계층을 구축하는 방법을 자세히 살펴보겠습니다. 구체적으로 다음을 다룰 것입니다.

• 기반: Unity Catalog가 수백 개의 팀에 걸쳐 연합 거버넌스와 안전한 공유를 어떻게 지원하는지
• 의미론적 계층: Metric Views에서 지원되는 Unity Catalog Business Semantics를 사용하여 비즈니스 로직을 한 번 정의하고 어디서나 제공하는 방법
• 대화형 AI 기반 분석: SQL 전문 지식 없이 자연어를 사용하여 데이터를 쿼리할 수 있는 생성형 AI 기반 인터페이스인 Genie를 통해 의미론적 계층을 활용하여 더 빠르고 데이터 기반 의사 결정을 내리는 방법

기반 – Unity Catalog를 통한 거버넌스 민주화

방대한 데이터 환경을 효과적으로 관리하기 위해 리소스 중심의 게이트키핑에서 벗어나기로 결정했습니다. 이 모델에서는 모든 새 데이터셋 또는 소비자가 맞춤형 IAM 역할, S3 버킷 정책 및 예외 처리를 필요로 했습니다. 그러나 문제를 식별했습니다. 권한은 수천 개의 리소스에 분산되어 검토하기 번거롭고 드리프트가 발생하기 쉬웠습니다. 따라서 ID 기반 거버넌스 접근 방식으로 전환했습니다. 액세스 결정은 사람 및 그룹에 연결된 재사용 가능한 정책으로 표현됩니다. 데이터셋 전체에서 일관되게 평가되고 중앙에서 적용됩니다. 이를 통해 팀 및 데이터가 변경됨에 따라 액세스를 더 쉽게 운영, 감사 및 발전시킬 수 있습니다. Databricks Unity Catalog를 사용하여 이 기반을 구축하고 그 위에 연합 액세스 제어 프레임워크를 구현했습니다.

아키텍처

데이터 생성과 소비를 엄격하게 분리하는 이중 카탈로그 패턴을 설계하여 민첩성이 제어 비용으로 발생하지 않도록 했습니다.

• 자율성을 위한 개인 카탈로그: 모든 도메인 팀은 내부 셀프 서비스 솔루션을 사용하여 자체 개인 카탈로그를 만듭니다. 이 개인 환경 내에서 팀은 중앙 승인을 기다리지 않고 자체 속도로 스키마를 만들고, 원시 데이터를 수집하고, 테이블을 구축할 수 있습니다. 이는 무제한 개발 및 반복에 최적화된 "공장" 역할을 합니다. 유일한 제한 사항은 여기서 생성된 모든 개체는 해당 팀 자체와 소수의 관련 기여자만 액세스할 수 있다는 것입니다. 이는 이러한 카탈로그를 기반으로 구축된 사용 사례가 회사 전체에서 사용되지 않는다는 것을 의미합니다.
• 거버넌스를 위한 중앙 공유 카탈로그: 회사의 다양한 팀이 이러한 데이터셋을 사용해야 하는 사용 사례의 경우 중앙 공유 카탈로그를 도입했습니다. 이는 회사 전체의 "쇼룸" 역할을 합니다. 조직 전체에서 공유되는 모든 데이터는 동적 뷰를 통해 여기에 노출되어야 하며, 엄격한 중앙 거버넌스 하에 있습니다. 데이터가 여기에 도착하는 순간 Unity Catalog를 통해 즉시 검색할 수 있습니다.

동적 뷰를 사용하는 이유: 중앙 집중식 제어 및 감사 가능성

중앙 집중식 액세스 프로세스를 통해 복잡한 규정 준수 규칙을 처리할 수 있도록 공유 카탈로그의 데이터를 직접 테이블 포인터가 아닌 동적 뷰를 통해서만 노출하기로 전략적으로 결정했습니다.

동적 뷰를 서비스 계층으로 사용하여 다음을 달성했습니다.

• GDPR을 위한 사용자 지정 프로세스 규칙: is_account_group_member()와 같은 함수를 사용하여 뷰 정의에 사용자 지정 로직을 직접 삽입합니다. 이를 통해 사용자가 반독점 요구 사항을 충족하는지 확인하고 민감한 데이터(예: 이메일)에 액세스할 권한이 있는지 확인하여 강력한 액세스 제어를 보장합니다.
• 기본 규정 준수 내부자 액세스: 자동화된 분류 프로세스로 인해 각 열이 분류됩니다. 모든 비민감 열은 기본적으로 다양한 사용자에게 액세스할 수 있으므로 데이터 민주화 및 의사 결정 속도가 빨라집니다.
• 전체 감사 가능성: 모든 팀 간 액세스가 이러한 중앙에서 관리되는 뷰를 통해 흐르기 때문에 액세스 결정에 대한 완전한 감사 추적을 유지합니다. 특정 행 또는 열에 대한 액세스 권한을 부여한 정책을 정확히 알고 있습니다.
• 신뢰할 수 있는 통찰력: 부분 집계로 인한 잘못된 데이터 또는 오해의 소지가 있는 숫자 생성을 방지하기 위해 필요한 특정 권한 없이 민감한 열에 액세스하려는 모든 쿼리는 권한 거부 오류로 명시적으로 실패합니다.

코드로서의 거버넌스: 공유 워크플로

이 프로세스를 효율적으로 유지하기 위해 GitOps 접근 방식을 사용하여 공유 워크플로를 자동화했습니다.

1. 공유를 위한 풀 요청: 팀이 개인 카탈로그의 데이터셋을 공유 카탈로그로 공유할 준비가 되면 티켓을 제출하지 않습니다. 소스 테이블을 가리키는 구성 파일이 있는 중앙 리포지토리에서 풀 요청(PR)을 엽니다.
2. 승인 규칙: PR은 공유 기준, 고유성 및 기타 중요한 결정 요인에 대해 확인됩니다.
3. 자동화된 유효성 검사 및 프로비저닝: PR이 승인되고 병합되면 당사 플랫폼 서비스는 중앙 공유 카탈로그에서 해당 동적 뷰를 자동으로 생성하고 열을 자동으로 분류합니다.

이 설정은 분산 팀의 민첩성을 유지하면서 중앙 집중식의 완전한 감사 가능한 거버넌스 표준을 시행하여 데이터를 쉽게 검색 가능하고 안전하며 규정을 준수하도록 합니다.

의미론적 계층 – "진실" 정의하기 (Metric Views 사용)

데이터 액세스를 위해 구축한 안전한 기반을 바탕으로 이제 일관된 데이터 해석을 보장하는 데 중점을 둡니다.

이전에 데이터 스택 전체에 분산되어 있던 비즈니스 로직을 적극적으로 중앙 집중화하고 있습니다.

• BI 도구: 개별 대시보드에 포함된 메트릭 정의
• SQL 스크립트: 노트북 및 파이프라인에 중복된 로직
• 구체화된 테이블: 특정 사용 사례에 연결된 사전 계산된 메트릭

수천 개의 메트릭 정의를 단일의 관리되는 계층으로 통합하고 있습니다. 이를 통해 "로직 잠금"을 해제할 수 있습니다. 한 대시보드 도구에서 "총 상품 가치"(NMV)의 정의는 노트북에서 작업하는 데이터 과학자나 사용자의 질문에 답하는 AI 봇이 완전히 액세스할 수 있습니다.

이를 달성하기 위해 Databricks Metric Views를 통합 시맨틱 계층으로 채택하고 있습니다. 이는 메트릭의 정의와 소비를 결정적으로 분리하여 사용자가 SQL 편집기, 대시보드 또는 AI 에이전트를 통해 쿼리하든 정확히 동일한 계산 결과를 받도록 보장합니다. 실제로 이를 통해 기술 및 비기술 사용자 모두 동일한 메트릭 정의를 사용하게 됩니다.

코드로서의 메트릭: 메트릭 수명 주기

Unity Catalog에서 데이터 공유를 위해 GitOps를 사용하는 것과 마찬가지로, 시맨틱 계층에 대해 엄격한 "코드로서의 메트릭" 접근 방식을 구현합니다. KPI 정의를 중앙 집중화하고 표준화하여 모든 팀 간의 일관성을 보장합니다.

아키텍처는 메트릭의 전체 수명 주기를 관리합니다.

1. YAML로 정의: 메트릭은 중앙 리포지토리에 저장된 코드(YAML 파일)로 정의됩니다. 이는 집계 논리(예: SUM(amount))와 테이블, 팩트 및 메트릭 간의 관계뿐만 아니라 소유권, 설명 및 서식과 같은 중요 메타데이터도 캡처합니다.

2. 자동화된 검증: 메트릭이 프로덕션에 병합되기 전에 CI/CD 파이프라인은 자동화된 검사 세트를 실행합니다. 여기에는 다음이 포함됩니다.
   • 고유성: 동일한 이름이나 정의를 가진 메트릭이 이미 존재하지 않는지 확인합니다.
   • 적합성: 검색 가능성을 보장하기 위해 명명 규칙(예: snake_case)을 적용합니다.
   • 소유권: 책임 소재를 위해 유효한 팀 ID가 메트릭에 첨부되었는지 확인합니다.
3. 인간 참여: 4가지 눈 원칙을 통해 각 풀 리퀘스트는 도메인 전문가가 검토합니다.
4. 개별 개발 환경: 팀이 프로덕션에 매우 가까운 환경에서 테스트하면서 빠르게 반복할 수 있도록 각 풀 리퀘스트는 별도의 테스트 환경에 메트릭 뷰를 배포합니다. 이 설정은 변경의 영향을 즉시 확인할 수 있도록 합니다.

Lakehouse를 위한 스타 스키마 구축

내부적으로는 확립된 차원 모델링 원칙에 의존합니다. 프로덕션 환경의 각 메트릭 뷰는 표준 인터페이스 역할을 하며, 일반적으로 팩트 테이블과 1:1로 매핑되고 규격화된 차원 테이블의 속성을 상속합니다.

이 설정은 규모에 매우 중요합니다. 메트릭 뷰가 공유 카탈로그 (섹션 1 참조)의 신뢰할 수 있는 데이터 위에 구축되도록 강제함으로써 시맨틱 계층이 기본 플랫폼의 모든 보안 및 규정 준수 이점을 상속하도록 보장합니다. 메트릭 뷰를 쿼리하는 사용자는 여전히 Unity Catalog 계층에서 정의한 동일한 행 수준 및 열 수준 보안 및 액세스 규칙의 적용을 받습니다. 올해 말에는 메트릭 뷰를 통한 추가 권한 부여 계층으로 이 설정을 강화하여 사용자가 더 이상 원시 데이터 액세스가 필요하지 않고 메트릭 및 차원 수준 액세스만 필요하도록 할 것입니다.

결과: 상호 운용성

이 아키텍처의 이점은 상호 운용성입니다. 비즈니스 로직을 독점 BI 도구에서 Lakehouse 시맨틱 계층으로 이동함으로써 미래를 준비합니다. 이 계층에서 한 번 정의된 메트릭은 즉시 다음에서 사용할 수 있습니다.

• Databricks 대시보드 표준 보고용.
• Genie 자연어를 사용하는 대화형 인터페이스에서 AI 기반 분석용.
• 외부 도구및 애플리케이션 표준화된 커넥터를 통해.

이 중앙 집중화는 비즈니스가 데이터와 "대화"할 수 있도록 하는 다음 주요 단계의 핵심 열쇠입니다.

대화형 AI 기반 분석

대시보드는 일상적이고 반복적인 질문에 답하는 데 필수적입니다. 그러나 비즈니스 속도는 종종 표준 보고서가 모든 것을 포착하는 능력을 능가합니다. 예를 들어, 카테고리 관리자는 다음과 같은 정보를 알아야 할 수 있습니다."지난주 독일에서 판매된 품목 수 상위 10개에는 들지 못했지만 클릭률이 높았던 스니커즈 브랜드는 무엇인가?" 기존 표준 보고서에서 다루지 않는 이와 같은 새로운 질문에 답하려면 종종 새로운 대시보드를 구축해야 했습니다. 셀프 서비스 도구를 사용하더라도 상당한 "인사이트 도달 시간" 지연이 지속되었습니다. 사용자는 답변을 얻기 전에 올바른 데이터 세트를 찾고, 위젯을 구성하고, 필터를 적용해야 했습니다. 이는 종종 일회성 대시보드로 이어져 대시보드 확산과 검색 가능성 감소에 기여했습니다.

사용자 경험을 최적화하기 위해 LLM 기반 대화형 인터페이스(종종 AI 챗봇이라고 함)를 제공하는 여러 "데이터와 대화" 솔루션을 평가했습니다. 이 계층이 없는 솔루션은 복잡한 비즈니스 로직에 대한 정확한 SQL을 생성하는 데 어려움을 겪었지만 Genie는 통합 시맨틱 계층에 기반하기 때문에 가장 좋은 성능을 보였습니다.

이것이 Metric Views의 도입이 Genie와 같은 대화형 AI 기반 분석에 중요한 이유입니다. Genie를 사전 설정된 Metric Views(섹션 2에 자세히 설명됨)로 안내함으로써, 우리는 중요한 돌파구를 달성했습니다. 즉, 거버넌스된 비즈니스 정의에 기반한 일관되고 신뢰할 수 있는 답변을 얻었습니다.

Metric Views가 AI 정확도를 대폭 향상시키는 이유

분석에 AI를 채택하는 데 가장 큰 장애물은 신뢰입니다. LLM이 SQL 쿼리를 잘못 생성하면 숫자가 틀리고 사용자는 신뢰를 잃게 됩니다.

Genie는 Metric Views의 시맨틱 계층과 함께 작동하여 이를 해결합니다.

• 추측 없음: 사용자가 "NMV"(순 상품 가치)를 요청할 때 Genie는 원시 테이블에서 계산하려고 시도하지 않습니다. "NMV"를 메트릭 뷰의 거버넌스된 메트릭으로 인식하고 미리 정의된 논리를 쿼리합니다. 따라서 메트릭 뷰는 SQL 문 생성의 복잡성을 줄여 정확도를 높입니다.
• 상황 인식: 설명, 동의어 및 샘플 쿼리를 추가하여 Unity Catalog 메타데이터를 풍부하게 만드는 데 많은 투자를 했습니다. Genie는 이 컨텍스트를 사용하여 사용자가 "취소"라고 말할 때 내부 정의와 일치하는, 배송 전에 취소된 주문을 구체적으로 의미한다는 것을 이해합니다.

최전선 역량 강화

과거에 Excel 내보내기 또는 BI 도구에 의존했던 머천다이저, 바이어, 가격 분석가와 같은 비기술 팀과 Genie를 테스트했습니다. 피드백은 즉각적이었습니다. 사용자는 SQL 한 줄도 모르거나 사용자 지정 보고서 뷰를 만드는 데 시간을 할애하지 않고도 세분화된 질문(예: 특정 장치 유형과 페어링된 특정 시장 성과)에 대한 빠른 답변을 얻을 수 있었습니다.

새로운 에이전트 모드의 도입은 사용자 경험을 크게 향상시켰습니다. 에이전트 모드는 분석 결과를 자동으로 분석하여 결과의 근본 원인을 파악하므로 사용자는 단순히 "왜" 그런 일이 발생했는지 물어볼 수 있습니다. Zalando에서는 이를 통해 정기적인 성과 회의(중요한 운영 결정이 내려지는 곳) 준비 시간을 몇 시간에서 몇 분으로 단축할 수 있습니다.

하지만 광범위한 기능으로 인해 Genie를 올바르게 설정하지 않으면, 예를 들어 집계되지 않은 테이블과 뷰에서는 비용이 많이 들 수 있습니다. 그렇기 때문에 Genie가 사용하는 데이터와 컨텍스트를 신중하게 큐레이션하는 것이 중요합니다. 또한, 전체 Genie 버전 관리를 도입하고 Genie 구성을 프로그래밍 방식으로 업데이트하는 것과 같은 추가적인 개선의 잠재력을 인식하고 있으며, 이는 Databricks에서 이미 작업 중이며 현재 부분적으로 지원되고 있습니다.

엔터프라이즈 채택을 위한 Genie 확장

Genie를 단순한 샌드박스 실험으로 취급하는 것이 아니라 엔터프라이즈 운영에 통합하고 있습니다. 확장을 위한 당사의 주요 영역은 다음과 같습니다.

• 거버넌스 수립: 큐레이션된 Genie 공간은 거버넌스되고 적절하게 유지 관리되는 Metric Views에 의해 지원될 것입니다.
• 데이터 신뢰성 보장: 데이터 소유 팀과 협력하여 큐레이션된 Genie 공간을 구축하고 있습니다. 이러한 공간은 Metric Views를 통해 데이터의 분석 표현을 제공하여 데이터 소유자 자신이 데이터 품질을 유지하도록 보장합니다.
• Agent Bricks와 통합 또는 Databricks One에서 Genie 사용: Agent Bricks를 사용하거나 Databricks One 내에서 Genie를 사용하여 이러한 큐레이션된 Genie 공간을 오케스트레이션할 계획입니다. 이 접근 방식은 사용자가 모든 데이터 문의에 대해 단일 통합 진입점을 갖도록 보장합니다.

Unity Catalog의 거버넌스, Metric Views를 통한 비즈니스 로직 표준화, Genie의 지능을 결합하여 "데이터에 질문하는 것"이 동료에게 질문하는 것만큼 쉬운 데이터 문화를 구축하고 있습니다.

이 게시물에 기여해주신 Merve Karali, Tobias Efinger, 그리고 Roberto Bruno Martins에게 감사드립니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)