데이터 메시는 이전 모델의 한계를 훨씬 뛰어넘을 수 있는 데이터 설계에 대한 새로운 접근 방식을 제공합니다.
개요
데이터 관리 전략은 항상 진화하고 있습니다. 기업은 적시에 안정적으로 제공되는 통찰력을 통해 경쟁력을 유지할 수 있도록 이러한 변화에 적응할 준비를 해야 합니다.
데이터 웨어하우스 패러다임은 1980년대로 거슬러 올라갑니다. 당시 조직에는 메인프레임 및 운영 체제와 같은 여러 소스의 데이터를 통합하고 여기에서 통찰력을 추출하기 위한 중앙 집중식 데이터 플랫폼이 필요했습니다. 2000년대까지 데이터 웨어하우스 솔루션은 여전히 "비즈니스 인텔리전스"라고 불렸던 작업의 일부로 여겨졌습니다.
시간이 지남에 따라 데이터 웨어하우징은 보완 데이터 아키텍처, 특히 데이터 레이크 및 최근에는 하이브리드 데이터 레이크하우스의 개발을 촉진했습니다. 이러한 제품은 이제 데이터 웨어하우스와 함께 자주 사용됩니다. 그러나 엔터프라이즈 데이터의 가장 심오한 진화 중 하나는 2019년부터 두드러진 트렌드인 데이터 메시입니다.
데이터 메시는 비즈니스 도메인을 중심으로 구성된 데이터 에코시스템 모델입니다. 여러 기능을 수행하는 팀이 해당 도메인의 데이터를 관리, 제공 및 궁극적으로 소유할 수 있도록 지원하는 셀프 서비스 기능을 통해 관리됩니다. 주요 비즈니스 프로세스 및 의사 결정에 정보를 제공하는 고유한 데이터 제품을 생성할 수 있습니다.
데이터 메시 아키텍처에서 데이터는 주로 판매 및 고객 지원과 같은 비즈니스 고유의 문제에 해당하는 다양한 도메인 또는 주제 영역의 인프라에 존재합니다. 각 도메인에 고유한 스키마가 있을 수 있습니다.
여러 기능을 수행하는 팀(제품 관리자, 개발자, 비즈니스 분석가 및 해당 도메인 내의 다른 사람들)은 자체 데이터로 작업하고 필요에 따라 다른 도메인과 공유합니다. 이 팀은 데이터가 저장되는 위치 및 데이터를 로드하고 변환하는 방법에 대한 전문성을 갖고 있습니다. 경우에 따라 자체 전용 데이터 레이크 또는 허브를 사용하여 여러 데이터 소스를 데이터 메시의 섹션에 연결할 수 있습니다.
각 팀은 도메인 데이터를 관리하기 위해 자체 물리적 데이터 메시 인프라를 구축할 수 있습니다. 하지만 여러 스키마를 공동 배치하는 것은 특히 자주 조인하는 다른 도메인의 데이터 세트에 대해 효과적일 수 있습니다(동일한 데이터베이스에 저장되었을 때 성능이 더 좋습니다). 따라서 데이터 메시는 물리적 또는 논리적 엔터프라이즈 데이터 아키텍처일 수 있습니다.
소유권이 도메인별로 나누어지더라도 연합 거버넌스는 이를 관리할 수 없게 되는 것을 방지하는 데 도움이 됩니다. 데이터 상호 운용성 및 품질에 대한 표준과 DevOps 문화는 이러한 데이터 거버넌스를 보장합니다.
각 비즈니스 도메인은 자체 별도의 단위이므로 도메인 데이터가 너무 단편화되어 기업 전체에서 효율적으로 협업을 하는 것을 방해할 위험이 있습니다. 기업의 데이터 세트에 적용되는 제품 중심 사고의 개념이 바로 데이터 메시의 전체 가치를 실현하는 데 큰 차이를 만듭니다.
각 도메인 팀은 쉽고 안전한 데이터 액세스가 필요한 조직 내 다른 사용자(예: 개발자 또는 데이터 과학자)를 “고객”으로 여기고, 데이터 자산을 데이터 제품의 구성 요소로 인식해야 합니다. 예를 들어, 인공 지능(AI) 데이터 엔지니어는 소프트웨어의 알고리즘을 개선하기 위해 전자 건강 기록(EHR) 시스템 내에서 실행되는 프로그램의 분석 데이터가 필요할 수 있습니다.
데이터 메시는 일관된 데이터 제품을 통해 기업 전체에 이러한 수준의 편의성을 제공할 수 있습니다. 모든 제품에 필요한 기능:
데이터 메시를 EU와 같은 관세 동맹과 동일한 엔터프라이즈 데이터 관리로 생각해보세요. 각 국가는 자율적인 자체 단체임과 동시에 동료 회원국과의 제품 및 서비스 교환에 관해 특정 기준을 준수합니다. 같은 맥락으로 도메인 데이터 팀은 독립적으로 운영되지만 해당 데이터 제품의 특성에 대한 글로벌 "규칙"을 따릅니다.
데이터 메시의 배포 모델은 모든 도메인에 하나씩, 다양한 중복 데이터 파이프라인과 스토리지 인프라가 존재하는 것처럼 보일 수 있습니다. 이 설정은 빠르고 실행 가능한 통찰력을 얻는 것을 방해하는 기술적 복잡성을 생성할 수 있습니다. 하지만 기업 내 모든 팀에 동일한 수준의 셀프 서비스를 제공하고 도메인에 구애받지 않는 데이터 인프라 플랫폼을 사용하면 이를 방지할 수 있습니다.
이러한 데이터 플랫폼은 근본적인 복잡성을 숨기고 데이터 제품을 저장, 처리 및 제공하는 프로세스를 간소화합니다. 현재의 클라우드 트렌드 및 많은 기업이 사용하는 멀티 클라우드 환경에서 데이터 메시는 다음을 제공해야 합니다:
전반적으로 데이터 메시를 사용하면 클라우드에서 작업하는 팀은 다양한 데이터 소스와 혁신 중심 프로젝트를 통해 민첩성을 높일 수 있습니다.
기존 데이터 아키텍처는 데이터 소스가 상대적으로 적고 비즈니스 전반에 걸쳐 사용 사례가 적은 환경에서는 충분했습니다. 그러나 지금 원시 데이터 소스를 통찰력으로 빠르게 이동해야 하는 팀이 이러한 중앙 집중식 모델을 사용하면 병목 현상이 발생할 수 있습니다.
앞서 언급한 EHR 시스템에서 작업하는 가상의 AI 데이터 엔지니어가 빠르게 변화하는 비즈니스 요구 사항을 충족하기 위해 새로운 데이터 제품을 만들어야 한다고 상상해 보세요. 데이터 수집 및 처리를 위해 상대적으로 작고 고유한 구성 요소를 자체적으로 변경할 수 없기 때문에 속도가 느려질 수 있으며, 외부 지원을 받아 전체 데이터 파이프라인을 수정해야 할 수도 있습니다.
이것이 바로 이전 데이터 아키텍처가 종종 "모놀리식"으로 설명되는 이유입니다. 즉, 일부를 변경하면 전체가 변경된다는 의미입니다. 대조적으로, 데이터 메시 플랫폼은 여러 팀에서 작동하는 개별적으로 업데이트 가능한 구성 요소를 갖춘 마이크로서비스 아키텍처와 비슷합니다.
데이터 메시를 통해 달성할 수 있는 유연성과 민첩성은 중앙 집중식 데이터 웨어하우스 및 데이터 레이크에만 구축된 다른 데이터 아키텍처와 차별화되는 요소입니다.
이 네 가지 데이터 디자인 패턴은 상호 배타적이지 않습니다. 예를 들어 한 기업에 자체 데이터 레이크가 있는 다양한 기능을 수행하는 팀이 공존할 수 있습니다. 그러나 특정 아키텍처 한계를 극복해야 하는 필요성으로 인해 데이터 웨어하우스에서 데이터 레이크, 데이터 메시로 추적 가능하게 진화하였습니다.
초기 단계라는 제한적인 상황임에도 불구하고 데이터 메시가 미래의 데이터 아키텍처가 될 수 있는 세 가지 주요 원인은 다음과 같습니다:
데이터 메시를 통해 팀은 하나의 중앙 엔터프라이즈급 데이터 웨어하우스 또는 데이터 레이크의 병목 현상 없이, 원하는 방식으로 데이터에 액세스하고 사용할 수 있습니다. 자체 웨어하우스와 레이크를 데이터 메시 내의 노드로 사용하고 도메인 데이터를 로드 및 쿼리하며 데이터 제품을 더 빠르게 생성할 수 있습니다.
데이터가 수많은 소규모 도메인에서 관리되기 때문에 데이터 엔지니어는 더 이상 중앙 데이터 웨어하우스나 레이크에 버려지는 서로 다른 모든 정보를 분류해야 할 부담이 없습니다. 결과적으로 조직의 모든 구성원은 셀프 서비스 데이터 인프라 플랫폼을 사용하여 변화에 보다 신속하게 대응하고 필요에 따라 워크로드를 확장할 수 있습니다.
데이터 메시가 등장하기 전에는 기업 데이터의 소유권이 불분명하여 심지어 논쟁거리가 되는 경우도 많았습니다. 다른 도메인의 운영 팀들은 데이터를 전체 조직에서 격리된 전문 데이터 엔지니어가 처리하는 중앙 집중식 위치로 전송하곤 했습니다.
해당 엔지니어들은 그들의 전문 분야 밖의 도메인의 데이터로 작업해야 하는 어려운 과제에 직면했습니다. 또한 모든 팀이 사용할 수 있는 데이터 세트를 생성하기 위해 엔지니어들은 동일한 프로젝트에서 작업하는 도메인 팀 간의 중개자 역할을 수행해야 했습니다.
데이터 메시에서 소유권은 도메인 기반 설계로 인해 명확합니다. 팀은 위에서 설명한 기존의 푸시 및 수집 방식 대신에 각 팀이 능숙한 도메인에서 작업하고, 엔터프라이즈에서 데이터 제품을 사용할 수 있게 지원하고, 필요에 따라 다른 팀의 제품에 액세스하는 서브 및 풀 접근 방식을 따를 수 있습니다.
데이터 메시에서 데이터 소유권이 명백하기 때문에 팀은 데이터 제품을 배포하기 전에 데이터 제품의 품질을 보장해야 할 인센티브가 더 많습니다. 데이터 메시 개념과 DevOps의 기초를 긴밀하게 연결하여 품질이 더욱 향상됩니다.
DevOps는 제품의 지속적인 모니터링 및 개선과 함께 부서 간 협업을 강조합니다. 작업을 더 작고 관리하기 쉬운 부분으로 나누고 제품 비전을 공유하는 것과 같은 DevOps 원칙을 데이터 메시에 적용하면 데이터 아키텍처의 다양한 구성 요소를 더 쉽게 사용, 반복 및 유지 관리할 수 있습니다.
더 높은 품질의 데이터 제품이 이전보다 더 빨리 제공될 수 있습니다. DevOps가 기술적인 움직임인 동시에 문화적인 움직임인 것처럼, 데이터 메시에는 기술적 이익을 위해 책임과 협업을 강조하는 올바른 문화가 필요합니다. DevOps 자체는 이러한 문화적 변화를 가능하게 합니다.
데이터 메시를 본격적으로 시작하기 전에 기업은 다음과 같은 몇 가지 주요 사항을 먼저 고려해야 합니다:
데이터 메시는 소유권에 관해 팀 간 잠재적인 마찰이 발생할 수 있는 다양한 소스와 도메인을 가진 대규모 조직에 이상적입니다.
조직이 데이터 메시를 선택하는 경우 도메인 배포는 옴니채널 고객 경험 생성 또는 공급망 최적화와 같은 실제 비즈니스 이니셔티브와 밀접하게 조정되어야 합니다. 이를 통해 도메인 데이터 팀에 대한 보다 명확한 목표를 생성하고 데이터 메시가 단순한 실험이 아닌 실제 비즈니스 가치를 제공하도록 보장합니다.
각 도메인 팀이 데이터를 소유하고 있다고 해서 전사적 조정 및 거버넌스가 필요하지 않는 것은 아닙니다. 최신 도구를 사용하면 복잡한 워크로드를 쉽게 시작할 수 있지만 이러한 도구를 선택하고 구현하려면 여전히 전문가의 철저한 감독이 필요합니다.
데이터 관리 전문가는 프로세스 및 제품 개발을 통해 각 팀을 안내하는 중요한 역할을 합니다. 풍부한 경험을 통해 전문가의 도움으로 이러한 문제를 조기에 해결하면 전반적으로 회사가 나중에 문제를 해결하는 데 드는 시간과 비용을 절약할 수 있습니다.
모든 데이터에 대해 하나의 스키마로 작업할 때 발생하는 병목 현상을 제거하려면 각 도메인에 별도의 데이터 스키마가 필요합니다. 일부 시나리오에서는 성능상의 이유로 스키마를 함께 배치하고 연결해야 합니다. 동시에 데이터 메시 내의 모든 도메인에서 데이터 통합이 중요하다는 것을 기억하는 것이 중요합니다. 이를 통해 조직은 데이터 배치 전략을 활용하여 비즈니스 중심의 성과를 주도할 수 있습니다.
이러한 단계는 고성능 데이터 패브릭이 존재하는 한 매우 복잡하고, 다른 데이터 세트와 자주 결합되며, 정기적으로 재사용되는 워크로드에 최적의 속도 및 비용 조합을 제공합니다.
분산 데이터 소유권 자체가 새로운 개념은 아니지만 데이터 메시에 수반되는 특정 접근 방식이 실제 구현된 사례가 여전히 드물기 때문에 충분히 새롭습니다.
그러나 많은 조직에서 이미 데이터 모델 개발을 가속화하고 데이터 메시의 영향과 매우 유사한 방식으로 고객에게 더 나은 서비스를 제공하기 위해 설계 패턴과 클라우드 솔루션을 발전시키고 있습니다. 계속 부상 중이고 흥미로운 이 데이터 디자인 개념의 잠재력에 대해 자세히 알아보려면 테라데이타에 문의하세요.
데이터 메시에 대해 자세히 알아보기