데이터 아키텍처의 과거, 현재, 미래

데이터 아키텍처를 전체적으로 이해하는데 좋은 글일거 같아 옮겨봅니다. 참고로, Diogo Silva Santos 의 Medium Post를 DeepL을 이용해 번역한 supecialkim님의 글입니다. 이미지를 포함한 상세 내용은 아래 링크를 참고해주시면 좋을거 같습니다. 🔔 데이터 아키텍처가 필요한 이유는 무엇인가요? 🚩 데이터 아키텍처는 조직의 데이터 자산 구조를 설계, 구축 및 관리하는 프로세스이자 다양한 소스 및 애플리케이션의 데이터를 통합하기 위한 프레임워크와 같습니다. 잘 설계된 데이터 아키텍처의 주요 목표는 데이터 사일로를 줄이고, 데이터 중복을 최소화하며, 데이터 관리 프로세스의 전반적인 효율성을 개선하는 것입니다. 🔔 1세대: 데이터 웨어하우스 아키텍처 🚩 데이터 웨어하우스 아키텍처는 운영 시스템(SAP, Salesforce) 및 타사 데이터베이스(MySQL, SQL Server)에서 비즈니스 인텔리전스 시스템으로의 데이터 이동에 의해 정의됩니다. 이 아키텍처 스타일에서는 데이터 마트도 작동하는데, 데이터 마트는 특정 스키마 형식으로 특정 부서의 비즈니스 문제를 해결하기 위해 데이터 웨어하우스 위에 있는 추가 계층(하나 또는 여러 개의 테이블로 구성)입니다. 🚩 주요 과제: - 시간이 지남에 따라 전문 그룹만이 이해하고 유지 관리할 수 있는 수천 개의 ETL 작업, 테이블 및 보고서가 구축됩니다. - CI/CD와 같은 최신 엔지니어링 관행이 적용되지 않습니다. - 데이터 웨어하우스의 데이터 모델 및 스키마 설계가 너무 경직되어 여러 소스의 방대한 양의 정형 및 비정형 데이터를 처리하기 어렵습니다. 🔔 2세대: 데이터 레이크 아키텍처 🚩 처음 구축된 데이터 레이크는 클러스터된 컴퓨팅 노드 집합에 걸쳐 Hadoop 분산 파일 시스템(HDFS)에 데이터를 저장하는 것이었습니다. 데이터는 MapReduce, Spark 및 기타 데이터 처리 프레임워크를 사용하여 추출 및 처리되었습니다. 데이터 레이크 아키텍처는 ELT 프로세스에서 작동합니다. 그러나 데이터 웨어하우징과 달리, 데이터 레이크는 데이터의 변환 및 모델링이 거의 또는 전혀 이루어지지 않는다고 가정합니다. 🚩 주요 과제: - 데이터 레이크 아키텍처는 복잡성과 성능 저하로 인해 데이터 품질과 안정성이 저하됩니다. - 고도로 전문화된 데이터 엔지니어로 구성된 중앙 팀이 배치 또는 스트리밍 작업의 복잡한 파이프라인을 운영합니다. - 데이터 계보와 종속성을 추적하기 어렵습니다. 🔔 3세대: 클라우드 데이터 레이크 아키텍처(데이터 레이크 하우스) 🚩 가장 큰 변화는 클라우드로의 전환, 실시간 데이터 가용성, 데이터 웨어하우스와 데이터 레이크 간의 융합입니다 - Kappa와 같은 아키텍처를 통해 실시간에 가까운 데이터 가용성을 위한 스트리밍 또는 Apache Beam과 같은 프레임워크를 사용하여 데이터 변환을 위한 배치 및 스트림 처리의 통합을 지원하고자 합니다. - 클라우드 기반 관리형 서비스를 완전히 수용하고 격리된 컴퓨팅 및 스토리지로 최신 클라우드 네이티브 구현을 사용할 수 있고, 데이터 저장 비용이 훨씬 저렴해질 수 있습니다. 🚩 주요 과제: - 데이터 레이크 아키텍처는 여전히 관리하기가 매우 복잡하여 데이터 품질과 안정성에 영향을 미칩니다. - 아키텍처 설계는 여전히 중앙 집중식으로 고도로 전문화된 데이터 엔지니어 팀을 필요로 합니다. - 인사이트를 얻기까지 긴 시간. 데이터 소비자는 분석 또는 기계 학습 사용 사례를 위한 데이터 집합을 얻기 위해 몇 달을 계속 기다려야 합니다. 🔔 4세대: 데이터 메시 아키텍처 🚩 마이크로서비스가 모놀리식 애플리케이션에 가져온 기능을 데이터 아키텍처에 도입합니다. 데이터 메시에서는 데이터가 분산되어 있고 데이터의 소유권이 여러 도메인에 분산되어 있습니다. 각 도메인은 데이터 모델링, 스토리지, 거버넌스 등 해당 범위 내의 데이터를 책임지며, 아키텍처는 각 도메인이 데이터를 독립적으로 관리할 수 있도록 일련의 관행을 제공해야 합니다. 데이터 메시의 핵심 구성요소는 도메인, 데이터 제품, 데이터 인프라, 데이터 거버넌스, 메시 API등입니다. 🚩 아키텍처 외에 데이터 메시의 또 다른 변화는 무엇인가요? 모놀리스 애플리케이션에서 마이크로서비스 애플리케이션으로 전환하면서 소프트웨어 엔지니어링 팀은 개발 수명 주기, 조직 구조, 동기 부여, 기술 및 거버넌스를 변경해야 했습니다.그리고, 애플리케이션이 실제 사용자 문제를 해결하도록 보장하기 위해 제품 관리자의 역할이 필요합니다.