DEVOCEAN

The Past, Present, and Future of Data Architecture

A journey through time and the introduction to data mesh

Diogo Silva Santos 의 Medium Post를 DeepL을 이용해 번역한 글입니다.

• 데이터 아키텍처가 필요한 이유는 무엇인가요?

• 1세대: 데이터 웨어하우스 아키텍처

• 2세대: 데이터 레이크 아키텍처

• 3세대: 클라우드 데이터 레이크 아키텍처

• 4세대: 데이터 메시 아키텍처

• 아키텍처 외에 데이터 메시의 또 다른 변화는 무엇인가요?

👋 If you are a new reader, my name is Diogo Santos. I write about data product principles, the evolution of the modern data stack, and the journey to data mesh (the future of data architecture). You can subscribe to my newsletter here.

오늘 글에서는 데이터 아키텍처의 진화에 대해 이야기하겠습니다. 아키텍처 변화의 동기와 데이터 이니셔티브에 미치는 영향에 대해 설명합니다.

그리고 최신 데이터 아키텍처인 데이터 메시를 소개하겠습니다.

연락이 필요하시면 LinkedIn으로 연락주세요.

• Tags: #데이터 아키텍처 | #데이터 메시 | #데이터 레이크 | #분산형 데이터 소유권

데이터 아키텍처가 필요한 이유는 무엇인가요?

데이터 기반 조직이 되는 것은 많은 기업의 최우선 전략 목표 중 하나입니다.

데이터 중심이란 조직에서 이루어지는 모든 의사 결정과 프로세스의 중심에 데이터를 두는 것을 의미합니다.

리더들은 데이터 기반이 되어야만 초개인화 및 고객 여정 재설계를 통해 고객 경험을 개선하고, 자동화와 머신러닝을 통해 운영 비용을 절감하며,

고차원적인 전략과 시장 포지셔닝에 중요한 비즈니스 트렌드를 파악할 수 있다는 점을 잘 알고 있습니다. 데이터 플랫폼은 데이터가 번성할 수 있는 환경을 조성합니다.

데이터 플랫폼은 조직의 모든 데이터를 위한 저장소이자 처리소입니다. 데이터 플랫폼은 데이터의 수집, 정리, 변환 및 적용을 처리하여 비즈니스 인사이트를 창출합니다. 데이터 플랫폼은 종종 여러 공급업체에서 지원하는 여러 통합 도구(Dbt, Snowflake, Kafka 등)로 구성되기 때문에 'Morden Data Stack'이라고도 합니다.

데이터 플랫폼의 주요 요소 중 하나는 데이터 아키텍처입니다. 데이터 아키텍처는 조직의 데이터 자산 구조를 설계, 구축 및 관리하는 프로세스입니다.

데이터 아키텍처는 다양한 소스 및 애플리케이션의 데이터를 통합하기 위한 프레임워크와 같습니다.

잘 설계된 데이터 아키텍처의 주요 목표는 데이터 사일로를 줄이고, 데이터 중복을 최소화하며, 데이터 관리 프로세스의 전반적인 효율성을 개선하는 것입니다.

지난 수십 년 동안 데이터 환경이 진화함에 따라 데이터 아키텍처도 진화했습니다. 그 진화를 좀 더 자세히 살펴보겠습니다.

분석 데이터는 비즈니스 의사 결정을 지원하는 전통적인 분석부터 ML로 강화된 지능형 제품에 이르기까지 새로운 소비 모델에 의해 주도되는 진화적 변화를 겪어 왔습니다.

Figure 1 — The evolution of data architecture

1세대: 데이터 웨어하우스 아키텍처

데이터 웨어하우스 아키텍처는 운영 시스템(SAP, Salesforce) 및 타사 데이터베이스(MySQL, SQL Server)에서 비즈니스 인텔리전스 시스템으로의 데이터 이동에 의해 정의됩니다.

데이터 웨어하우스는 스키마(눈송이 스키마, 스타 스키마)가 정의되고 데이터가 차원 및 팩트 테이블에 저장되는 중심점으로, 비즈니스가 운영 및 고객 상호 작용의 변화를 추적하고 추적할 수 있게 해줍니다.

데이터는 :

1. 다양한 운영 데이터베이스 및 소스에서 추출됨

2. 다차원 및 시간 가변 표 형식으로 표현되는 범용 스키마로 변환됩니다.

3. CDC(변경 데이터 캡처) 프로세스를 통해 웨어하우스 테이블에 로드됩니다.

4. SQL과 유사한 쿼리를 통해 액세스

5. 주로 보고 및 분석 시각화 사용 사례를 위해 데이터 분석가에게 제공됨

이 아키텍처 스타일에서는 데이터 마트도 작동합니다.

데이터 마트는 특정 스키마 형식으로 특정 부서의 비즈니스 문제를 해결하기 위해 데이터 웨어하우스 위에 있는 추가 계층(하나 또는 여러 개의 테이블로 구성)입니다.

데이터 마트가 없다면, 이러한 부서는 필요한 콘텐츠와 형식의 데이터를 얻기 위해 웨어하우스에서 여러 쿼리를 탐색하고 만들어야 할 것입니다.

Figure 2 — Data Warehouse Architecture | Source: Data Mesh Book

이 접근 방식의 주요 과제:

• 시간이 지남에 따라 전문 그룹만이 이해하고 유지 관리할 수 있는 수천 개의 ETL 작업, 테이블 및 보고서가 구축됩니다.

• CI/CD와 같은 최신 엔지니어링 관행이 적용되지 않습니다.

• 데이터 웨어하우스의 데이터 모델 및 스키마 설계가 너무 경직되어 여러 소스의 방대한 양의 정형 및 비정형 데이터를 처리하기 어렵습니다.

이는 다음 세대의 데이터 아키텍처로 이어집니다.

2세대: 데이터 레이크 아키텍처

데이터 레이크 아키텍처는 데이터 웨어하우징 아키텍처가 데이터의 새로운 사용,

즉 머신 러닝 모델 학습 프로세스에서 데이터 과학자의 데이터 액세스를 충족하는 데 어려움을 겪자 이에 대응하기 위해 2010년에 도입되었습니다.

데이터 과학자는 머신 러닝(ML) 모델 학습 프로세스를 위해 원본 형식의 데이터가 필요합니다.

또한 ML 모델에는 대량의 데이터가 필요하므로 데이터 웨어하우스에 저장하기 어려울 수 있습니다.

처음 구축된 데이터 레이크는 클러스터된 컴퓨팅 노드 집합에 걸쳐 Hadoop 분산 파일 시스템(HDFS)에 데이터를 저장하는 것이었습니다.

데이터는 MapReduce, Spark 및 기타 데이터 처리 프레임워크를 사용하여 추출 및 처리되었습니다.

데이터 레이크 아키텍처는 ETL 프로세스가 아닌 ELT 프로세스에서 작동합니다. 운영 시스템에서 데이터를 추출(E)하고 중앙 스토리지 리포지토리에 로드(L)합니다.

그러나 데이터 웨어하우징과 달리, 데이터 레이크는 데이터의 변환 및 모델링이 거의 또는 전혀 이루어지지 않는다고 가정합니다.

목표는 데이터를 원래 형태에 가깝게 유지하는 것입니다. 데이터가 레이크에 들어가면 데이터 변환 파이프라인(T)을 통해 아키텍처가 확장되어 원시 데이터를 모델링하고 데이터 웨어하우스 또는 기능 저장소에 저장합니다.

데이터 엔지니어링 팀은 레이크를 더 잘 구성하기 위해 다양한 '영역'을 만듭니다.

목표는 가장 원시 데이터부터 데이터 강화 단계, 가장 깨끗하고 액세스하기 쉬운 데이터에 이르기까지 정리 및 변환 정도에 따라 데이터를 저장하는 것입니다.

이 데이터 아키텍처는 데이터 웨어하우징에 필요한 광범위한 사전 모델링의 비효율성과 마찰을 개선하는 것을 목표로 합니다.

선행 변환은 데이터 액세스 및 모델 학습을 위한 반복을 더 느리게 만드는 장애물입니다.

Figure 3 — Data Lake Architecture | Source: Data Mesh Book

이 접근 방식의 주요 과제:

• 데이터 레이크 아키텍처는 복잡성과 성능 저하로 인해 데이터 품질과 안정성이 저하됩니다.

• 고도로 전문화된 데이터 엔지니어로 구성된 중앙 팀이 배치 또는 스트리밍 작업의 복잡한 파이프라인을 운영합니다.

• 관리되지 않는 데이터 집합을 생성하며, 이는 종종 신뢰할 수 없고 액세스할 수 없어 가치가 거의 없습니다.

• 데이터 계보와 종속성을 추적하기 어렵습니다.

• 광범위한 사전 데이터 모델링이 없기 때문에 서로 다른 데이터 원본 간에 시맨틱 매핑을 구축하기가 어려워 데이터 늪이 생깁니다.

3세대: 클라우드 데이터 레이크 아키텍처

2세대에서 3세대 데이터 아키텍처로의 가장 큰 변화는 클라우드로의 전환, 실시간 데이터 가용성, 데이터 웨어하우스와 데이터 레이크 간의 융합입니다. 더 자세히 알아보세요:

• Kappa와 같은 아키텍처를 통해 실시간에 가까운 데이터 가용성을 위한 스트리밍을 지원합니다.

• Apache Beam과 같은 프레임워크를 사용하여 데이터 변환을 위한 배치 및 스트림 처리의 통합을 시도합니다.

• 클라우드 기반 관리형 서비스를 완전히 수용하고 격리된 컴퓨팅 및 스토리지로 최신 클라우드 네이티브 구현을 사용하세요. 데이터 저장 비용이 훨씬 저렴해집니다.

• 데이터 웨어하우스를 확장하여 임베디드 ML 학습을 포함하거나 데이터 웨어하우스 무결성, 트랜잭션, 쿼리 시스템을 데이터 레이크 솔루션으로 구축하는 등 웨어하우스와 레이크를 하나의 기술로 통합하세요.

  데이터브릭스 레이크하우스는 웨어하우스와 유사한 트랜잭션 및 쿼리 지원 기능을 갖춘 전통적인 레이크 스토리지 솔루션의 한 예입니다.

Figure 4 — From Data Warehouse to Data Lakehouse Architecture (On the right) | Source: Databricks blog

클라우드 데이터 레이크는 이전 세대의 격차를 일부 해소하고 있습니다.

하지만 여전히 몇 가지 과제가 남아 있습니다:

• 데이터 레이크 아키텍처는 여전히 관리하기가 매우 복잡하여 데이터 품질과 안정성에 영향을 미칩니다.

• 아키텍처 설계는 여전히 중앙 집중식으로 고도로 전문화된 데이터 엔지니어 팀을 필요로 합니다.

• 인사이트를 얻기까지 긴 시간. 데이터 소비자는 분석 또는 기계 학습 사용 사례를 위한 데이터 집합을 얻기 위해 몇 달을 계속 기다려야 합니다.

• 데이터 웨어하우스는 더 이상 데이터를 통해 실제 세계를 복제하는 것이 아니며, 데이터 탐색 시 데이터 소비자의 경험에 영향을 미칩니다.

이러한 모든 과제가 4세대 데이터 아키텍처로 이어졌고, 이 글이 게시되고 있는 이 시점에서는 아직 초기 단계에 머물러 있습니다.

4세대: 데이터 메시 아키텍처

데이터 메시 아키텍처는 데이터 아키텍처에 대한 비교적 새로운 접근 방식으로, 이전 중앙 집중식 아키텍처에서 확인된 몇 가지 문제를 해결하고자 합니다.

데이터 메시 아키텍처는 마이크로서비스가 모놀리식 애플리케이션에 가져온 기능을 데이터 아키텍처에 도입합니다.

데이터 메시에서는 데이터가 분산되어 있고 데이터의 소유권이 여러 도메인에 분산되어 있습니다.

각 도메인은 데이터 모델링, 스토리지, 거버넌스 등 해당 범위 내의 데이터를 책임지며, 아키텍처는 각 도메인이 데이터를 독립적으로 관리할 수 있도록 일련의 관행을 제공해야 합니다.

다음은 데이터 메시 아키텍처의 핵심 구성 요소입니다:

1. 도메인 - 도메인은 자체 데이터를 소유하고 관리하는 독립적인 비즈니스 단위입니다.

   각 도메인은 명확한 비즈니스 목적을 가지고 있으며 데이터 모델링, 엔티티, 스키마 및 데이터를 관리하는 정책을 정의할 책임이 있습니다.

   이 개념은 마케팅이나 영업과 같은 다른 팀을 위해 설계된 데이터 웨어하우스 아키텍처의 데이터 마트와는 다릅니다.

   데이터 메시 아키텍처에서 영업팀은 팀의 다양한 초점/영역에 따라 여러 도메인을 가질 수 있습니다.

2. 데이터 제품 - 데이터 제품은 도메인에서 생산된 데이터의 최종 결과물로서 다른 도메인이나 애플리케이션에서 사용할 수 있도록 제공됩니다.

   각 데이터 제품에는 명확한 비즈니스 목적이 있습니다. 하나의 도메인에서 여러 데이터 제품을 처리할 수 있습니다.

   모든 데이터 자산이 데이터 제품으로 간주되거나 데이터 제품 취급을 받아야 하는 것은 아닙니다(완벽한 세상에서는 그렇게 되겠지만).

   데이터 제품은 조직에서 핵심적인 역할을 하는 데이터 자산입니다.

3. 데이터 인프라 - 데이터 인프라에는 소프트웨어 애플리케이션을 위한 컨테이너화된 마이크로서비스와 유사하게 도메인 내에서 데이터를 관리하는 데 필요한 도구와 기술이 포함됩니다.

   여기에는 데이터 저장, 처리 및 분석 도구가 포함됩니다.

4. 데이터 거버넌스 - 데이터 거버넌스는 각 도메인에서 관리합니다. 이는 데이터 품질, 개인정보 보호 및 보안을 관리하기 위한 일련의 절차를 의미합니다.

5. 메시 API - 마이크로서비스가 HTTP REST API를 통해 모든 것을 노출하는 것처럼, 데이터 메시 도메인은 다른 도메인과 데이터 제품에서 사용할 수 있는 잘 정의된 인터페이스를 통해 모든 것을 노출합니다.

Figure 5 — Data Mesh Architecture. Each domain team performs cross-domain data analysis on its own. The domain ingests operational data, builds analytical data models as data products, and publish them with data contracts to serve other domains’ data needs | Source: datamesh-architecture.com

데이터 메시를 데이터 아키텍처 설계 방식과 데이터 팀 구성 방식에 대한 패러다임의 변화로 볼 수 있습니다:

• 소프트웨어 제품 팀이 서비스 지향적인 것처럼, 데이터 팀은 기술이 아닌 하나 이상의 비즈니스 도메인에 특화된 교차 기능 팀이 됩니다.

• 마이크로서비스의 모든 부분이 독립적으로 작동하도록 컨테이너화된 것처럼, 하나 또는 여러 개의 마이크로서비스로 구성된 모든 비즈니스 도메인은 자체 OLAP 데이터베이스와 분산 파일 저장 시스템을 갖게 됩니다.

• 데이터 제품 A는 데이터 제품 B에 의해 소비되며, 애플리케이션 마이크로서비스가 서로 통신하는 것처럼 두 데이터 제품 모두 스트리밍 또는 REST API를 통해 다른 데이터 제품과 통신하게 됩니다.

• 데이터 제품 API에는 기존의 REST API 문서가 뒤따르게 되며, 데이터 제품은 메시 데이터 카탈로그를 통해 검색할 수 있습니다.

Figure 6: The mesh emerges when teams use other domains’ data products. Upstream domains publish articles, orders, and customer data products that are consumed either upstream by other data products such as shipment, or downstream by ML Models, CRM systems, or Analytics. | Source: datamesh-architecture.com

아키텍처 외에 데이터 메시의 또 다른 변화는 무엇인가요?

데이터 메시에서 가장 영향력 있는 변화는 아키텍처입니다.

그러나 중앙 집중식 데이터 레이크에서 분산형 데이터 메시로 전환하는 것은 사회 기술적인 현상이며, 이는 몇 가지 추가적인 변화를 의미합니다.

모놀리스 애플리케이션에서 마이크로서비스 애플리케이션으로 전환하면서 소프트웨어 엔지니어링 팀은 개발 수명 주기, 조직 구조, 동기 부여, 기술 및 거버넌스를 변경해야 했습니다.

이때 애플리케이션이 실제 사용자 문제를 해결하도록 보장하기 위해 제품 관리자의 역할이 등장했습니다.

데이터 메시 아키텍처를 적용할 때도 마찬가지입니다.

다음 글에서는 데이터 메시 구현의 과제에 대해 자세히 알아보겠습니다.

더 많은 콘텐츠를 읽고 싶으시다면 LinkedIn에서 저를 팔로우하여 매주 더 많은 포스팅을 읽어보시고, 제 글이 마음에 드셨다면 구독을 고려해 주세요.

읽어주셔서 감사드리며 곧 다시 만나 뵙겠습니다.

Originally published at https://dataproducthinking.substack.com on March 8, 2023.

#퍼온글