이 블로그에서는 다음 사항을 전체적으로 다룰 것입니다. (a) 데이터 웨어하우징이란 무엇입니까? (b) 데이터 웨어하우스를 위한 데이터 모델링 접근 방식 (c) AWS의 데이터 웨어하우스, 그리고 마지막으로 (d) 매니지드 서비스를 사용하여 운영 부하를 줄이기 위한 데이터 웨어하우징. " "를 일반인의 관점에서 이해해 봅시다. 데이터 웨어하우스란 무엇인가 Wikipedia 에 따르면 EDW(엔터프라이즈 데이터 웨어하우스)라고도 알려진 데이터 웨어하우스(DW 또는 DWH)는 보고 및 데이터 분석에 사용되는 시스템이며 의 핵심 구성 요소로 간주됩니다. 데이터 웨어하우스는 하나 이상의 서로 다른 소스에서 수집된 통합 데이터의 중앙 저장소입니다. 이는 기업 전체의 작업자를 위한 분석 보고서를 생성하는 데 사용되는 현재 및 과거 데이터를 한 곳에 저장합니다. 이는 기업이 데이터를 조사하고 통찰력을 얻어 의사결정을 내릴 수 있다는 점에서 유익합니다. 비즈니스 인텔리전스 기본적으로 기업이 데이터 기반 조직이 되도록 돕기 위해 통찰력(비즈니스 인텔리전스)을 수집, 저장, 효율적으로 제공하는 기술입니다. 어떤 의미에서는 또 다른 트랜잭션 데이터베이스이지만 분석 작업 부하에 최적화된 데이터베이스입니다. 위 다이어그램에 따라 데이터는 소스에서 수집되어 사용량에 따라 변환(ETL/ELT)되고 DWH/데이터 마트 및 비즈니스 인텔리전스 도구를 통해 노출되는 Insights에 저장됩니다. ELT(ETL 대 ELT), Cloud DWH(AWS Redshift, Google Big Query, Snowflake, Databricks) 및 기타 관리형 데이터 솔루션이 존재하지 않았던 온프레미스 설정 시절에는 모든 것이 단순해 보였지만 최근에는 단순화되고 확장되었습니다. DWH의 도달 범위. 이 블로그에서는 모든 측면을 한 번에 하나씩 이해해 보겠습니다. 단순화를 위해 무한한 컴퓨팅 및 스토리지가 없으며 트랜잭션 시스템이 분석 쿼리를 효율적으로 처리할 수 없다는 전제를 사용하겠습니다. 스토리지에 최적화된 데이터 웨어하우스를 설계하고 분석 쿼리(슬라이싱/다이싱/큐브 등)를 효율적으로 처리하며 필요한 대기 시간을 제공하는 효율적인 방법이 필요한 곳입니다. 이 모든 것에 대해 위한 두 가지 이론적 디자인 모델이 다음과 같이 등장했습니다. Datawarehouse 디자인을 (a) Bill Inmon - 하향식 접근 방식(EDW) 및 (b) Ralph Kimball – 상향식 접근 방식(데이터 마트). Inmon의 접근 방식은 중앙에서 글로벌 규모로 구축하고 느린 구축을 고려하는 반면 Kimball의 방식은 사일로별로 독립적인 데이터 마트를 만들고 나중에 서로 연결하는 것입니다. 어떤 모델이 가장 좋고 어떤 모델을 선택해야 하는지에 대해 자세히 알아보지 않겠습니다. 제 경우에는 간단히 말해서 두 모델 모두 작동하며 전적으로 조직의 사용 사례와 성숙도에 따라 다릅니다. 이 디자인의 또 다른 핵심 포인트는 "데이터 표현", 더 빠른 쿼리 및 차원성의 핵심 축인 Star Schema, Snowflake 스키마 또는 Star와 Snowflake의 하이브리드를 사용한 차원 모델링입니다. 유일한 핵심 내용은 무한한 물류에도 불구하고 좋은 데이터웨어하우스 설계로 다차원 문제를 해결할 수 있다는 것입니다. 그러니 무시하지 않는 것이 좋습니다. 의 다음 단계는 온프레미스(Teradata, IBM DB2, Oracle 등)에서 Cloud DW(Snowflake, Redshift, BigQuery 등)에 이르기까지 다양한 플랫폼을 선택하는 것입니다. 기존 데이터 웨어하우스를 구축하는 것은 복잡하며 지속적인 관리 및 유지 관리는 어렵고 비용이 많이 들 수 있습니다. 다음 섹션에서는 AWS Redshift를 사용하여 구축하는 방법을 살펴보겠습니다(온프레미스가 더 나은지, 클라우드가 더 나은지, 어떤 클라우드 DWH가 더 나은지는 논쟁의 여지가 없습니다). DW 구축 Amazon Redshift는 사용이 간편하고 비용 효율적인 분석 쿼리에 탁월한 성능을 제공하는 완전 관리형 페타바이트 규모의 엔터프라이즈급 데이터 웨어하우스입니다. Amazon Redshift는 패치 적용, 백업, 하드웨어 프로비저닝과 같은 작업을 자동화하여 기존 데이터 웨어하우스에 필요한 운영 오버헤드를 줄입니다. 데이터 웨어하우스의 인프라 및 성능 기준을 사용자 지정할 수 있는 Amazon Redshift 클러스터를 구성할 수 있습니다. Amazon Redshift는 또한 Redshift Spectrum, Datashare, Redshift ML 및 서버리스 설정을 제공하므로 DWH 이상으로 Amazon Redshift 클러스터를 사용할 수 있습니다. 설정방법은, 데이터 수집에 활용할 서비스 정의(AWS DMS, DynamoDB, EMR, Glue, Kinesis, S3, SSH Host 등) 상호 작용 방법 정의(쿼리 분석 도구 및 관리 인터페이스) Redshift MPP 아키텍처 이해(분산, 비공유) 필요한 데이터 크기, 증가, 노드 및 쿼리 성능을 갖춘 클러스터(DC2, DS2 또는 RA3) 시작 필수 데이터 유형, 스키마 유형, 압축, 버퍼, 인코딩을 사용하여 사용 사례 또는 DWH 구현에 따라 데이터베이스 스키마를 설계합니다. 다양한 파일 형식에 대해 COPY를 사용하여 데이터 로드, 최소한의 변경을 위해 INSERT, 유지 관리를 위해 ANALYZE 및 VACUUM 사용 쿼리 최적화 및 성능 향상 수행 외부 테이블에는 Spectrum을, 제로 카피에는 데이터 공유를 사용하여 S3를 활용합니다. 심층적인 통찰력을 위해 Redshift ML을 사용하세요 BI 도구용 AWS Quicksight를 활용하여 통찰력을 얻으세요. 지금까지는 Cloud DWH를 사용하는 것이 합리적이지만 ? 아래 이미지는 데이터 레이크와 데이터 웨어하우스가 원활하게 함께 작동하는 방식을 설명합니다. AWS RDS는 에 제공되는 비용 효율적이고 내구성이 뛰어난 솔루션을 제공하는 데이터 소스 역할을 합니다. 그런 다음 데이터는 ETL 프로세스를 사용하여 변환되고 Redshift에 온보딩됩니다. Athena, Glue, Spectrum, Lake Formation 등과 같은 추가 AWS 서비스는 포괄적인 데이터 솔루션을 만들기 위한 격차를 해소하는 데 중요한 역할을 합니다. 이것이 DWH + 데이터 레이크/데이터 솔루션용 관리 서비스의 큰 체계에 어떻게 적합합니까 Amazon S3 결론적으로, 이 블로그에서는 데이터 웨어하우징의 기본 사항을 다루고, 이론적으로 그리고 기술 스택에 초점을 맞춰 구현 접근 방식을 자세히 살펴봅니다. 또한 더 넓은 데이터 솔루션 환경에 어떻게 원활하게 통합되는지에 대한 조감도도 얻을 수 있습니다.
