Analytics 관련 내용 정리 (Data warehouse/Search/Streaming)

범위

1. Data warehouse

• MPP (Massively Parallel Processing) Architecture
• Star Schema
• ETC

2. Search Service (Elasticsearch / Opensearch)

• Elasticsearch
• ETC

3. Streaming Service

• Kafka
• ETC

 

---

 

1. Data warehouse

1-1. MPP (Massively Parallel Processing) Architecture

 

개념:

• MPP는 데이터를 여러 노드에 분산하여 병렬로 처리하는 데이터베이스 아키텍처.
• 각 노드는 독립적인 프로세서, 메모리, 디스크를 가지며, 네트워크를 통해 서로 통신.
• 데이터 웨어하우스에서 대규모 데이터 처리에 적합.

특징:

• 확장성(Scalability): 노드를 추가하여 성능을 선형적으로 확장 가능.
• 병렬 처리(Parallelism): 작업을 병렬로 실행하여 처리 시간 단축.
• 내결함성(Fault Tolerance): 노드 장애 시 데이터 복구 가능.

MPP와 SMP의 차이:

• SMP (Symmetric Multiprocessing):
  • 프로세서가 하나의 메모리와 디스크를 공유.
  • 병렬 처리에 제한적이며 확장성이 낮음.
• MPP:
  • 각 노드가 독립적이며 확장성이 우수.

 

Redshift 구성 요소:

• 리더 노드(Leader Node):
  • SQL 클라이언트와 통신, 쿼리 계획 생성 및 작업 분배.
• 컴퓨트 노드(Compute Node):
  • 데이터를 저장하고 쿼리 실행.

Redshift 성능 최적화:

1. 데이터 분배 스타일:
   • EVEN: 데이터를 모든 노드에 균등 분배.
   • KEY: 특정 열을 기준으로 분배.
   • ALL: 모든 노드에 데이터를 복사 (작은 테이블에 적합).
2. 정렬 키(Sort Key):
   • Compound: 열 순서에 따라 정렬, 쿼리의 특정 열 필터링에 적합.
   • Interleaved: 여러 열 필터링이 필요할 때 사용.
3. 데이터 압축:
   • 컬럼별 최적화된 압축 방식으로 디스크 I/O 최소화.

 

1-2. Star Schema

 

 

구성:

• 중심에는 **사실 테이블(Fact Table)**이 있고, 이를 설명하는 **차원 테이블(Dimension Table)**이 주변에 위치.

• 장점:
  • 직관적인 설계로 BI 도구에서 최적화.
  • 쿼리 성능 향상을 위해 데이터 정규화 감소.

Redshift에서 스타 스키마 최적화:

1. 차원 테이블 분배:
   • DISTSTYLE ALL로 설정하여 모든 노드에 복사.
   • 데이터의 규모가 작고 노드간 이동 없이 차원테이블을 사용할 수 있도록 모두 복사해둠
2. 사실 테이블 최적화:
   • DISTKEY와 SORTKEY를 활용하여 자주 사용되는 열 중심으로 최적화.
   • 규모가 크기 때문에 EVEN(R.R) 혹은 DIST KEY 스타일로 분산

 

1-3. ETC

테이블 설계 모범 사례:

• 적절한 정렬 키 선택: 쿼리에서 자주 사용되는 필드나 범위 검색에 활용되는 열을 정렬 키로 설정하여 쿼리 성능을 향상시킬 수 있습니다.
• 효율적인 분산 스타일 선택: 테이블 간 조인 및 집계 작업의 효율성을 높이기 위해 키 분산, 전체 분산, 자동 분산 등 적절한 분산 스타일을 선택합니다.
• 압축 인코딩 활용: COPY 명령어를 사용하여 데이터를 로드할 때 자동으로 압축 인코딩을 적용하면 저장 공간을 절약하고 I/O 성능을 개선할 수 있습니다.
• 기본 키 및 외래 키 제약 조건 정의: 데이터 무결성을 유지하고 쿼리 최적화를 지원하기 위해 기본 키와 외래 키 제약 조건을 설정합니다.
• 최소한의 열 크기 사용: 필요한 데이터 크기에 맞게 열 크기를 최소화하여 저장 공간을 절약하고 성능을 향상시킵니다.
• 날짜/시간 데이터 타입 활용: 날짜 관련 데이터를 처리할 때 적절한 날짜/시간 데이터 타입을 사용하여 효율성을 높입니다.

데이터 로드 모범 사례:

• COPY 명령어 사용: 대량의 데이터를 효율적으로 로드하기 위해 COPY 명령어를 활용합니다.
• 여러 파일에서 단일 COPY 명령어 사용: 병렬 처리를 통해 로드 성능을 높이기 위해 여러 파일을 대상으로 단일 COPY 명령어를 사용합니다.
• 데이터 파일 검증: 데이터 로드 전후에 파일을 검증하여 데이터의 정확성과 무결성을 확인합니다.
• 멀티 로우 삽입 및 벌크 삽입 활용: 다중 행 삽입과 벌크 삽입을 통해 삽입 작업의 효율성을 높입니다.
• 정렬 키 순서에 따른 데이터 로드: 정렬 키 순서에 맞게 데이터를 로드하여 쿼리 성능을 최적화합니다.
• 순차적 블록 로드: 데이터를 순차적인 블록으로 로드하여 디스크 I/O를 최소화합니다.
• 시계열 테이블 사용: 시간 기반 데이터의 효율적 관리를 위해 시계열 테이블을 활용합니다.
• 유지 관리 기간 고려: 시스템 유지 관리 기간을 고려하여 데이터 로드 일정을 조정합니다.

쿼리 설계 모범 사례:

• 필요한 열만 선택: SELECT *를 지양하고 필요한 열만 선택하여 쿼리 성능을 향상시킵니다.
• CASE 표현식 활용: 복잡한 집계를 수행할 때 동일한 테이블을 여러 번 조회하는 대신 CASE 표현식을 사용합니다.
• 크로스 조인 최소화: 크로스 조인은 성능에 부정적인 영향을 미칠 수 있으므로 필요 시에만 사용합니다.
• 서브쿼리 활용: 작은 결과 집합을 반환하는 서브쿼리를 사용하여 메인 쿼리의 효율성을 높입니다.
• 조건절 활용: 데이터 집합을 최대한 제한하기 위해 WHERE 절 등 조건절을 적극 활용합니다.
• 비용이 적은 연산자 사용: 비교 연산자를 LIKE 연산자보다, LIKE 연산자를 SIMILAR TO나 POSIX 연산자보다 우선 사용하여 성능을 최적화합니다.
• 함수 사용 최소화: 쿼리 조건절에서 함수 사용을 피하여 불필요한 연산을 줄입니다.
• 정렬 키 활용: GROUP BY 절에서 정렬 키를 사용하여 효율적인 집계를 수행합니다.
• 일관된 정렬 순서 유지: GROUP BY와 ORDER BY 절에서 동일한 열 순서를 유지하여 쿼리 최적화를 지원합니다.

성능 튜닝 기법:

• 워크로드 관리: 워크로드 관리(Workload Management)를 통해 ETL 작업의 성능을 향상시킵니다.
• 동시성 확장 활용: 동시성 확장(Concurrency Scaling)을 통해 동시 처리 성능을 극대화합니다.
• 정기적인 테이블 유지 관리: 정기적으로 테이블을 분석하고 진공(VACUUM) 작업을 수행하여 최적의 성능을 유지합니다.
• 자동 테이블 최적화 사용: 자동 테이블 최적화 기능을 활용하여 테이블 설계를 최적화합니다.
• 물리화된 뷰 활용: 물리화된 뷰를 사용하여 복잡한 쿼리의 성능을 향상시킵니다.
• 단일 트랜잭션 내 다중 단계 수행: 여러 단계를 단일 트랜잭션으로 처리하여 일관성과 성능을 높입니다.
• 대량 데이터 추출 시 UNLOAD 사용: 대량의 결과 집합을 추출할 때 UNLOAD 명령어를 사용하여 효율성을 높입니다.
• 일회성 ETL 처리에 Redshift Spectrum 활용: 일회성 ETL 작업에 Amazon Redshift Spectrum을 사용하여 자원을 효율적으로 활용합니다.

 

VACUUM의 주요 유형

1. VACUUM FULL:
   • 테이블 전체를 정렬 및 정리.
   • 모든 행을 정렬 키 기준으로 재배치.
   • 가장 시간이 오래 걸리며 많은 리소스 소비.
   • 사용 사례: 큰 변경 작업 이후 전체 데이터 최적화가 필요한 경우.
2. VACUUM SORT ONLY:
   • 삭제된 데이터는 그대로 두고, 데이터 정렬만 수행.
   • 사용 사례: 테이블의 데이터가 잘 정렬되지 않은 경우.
3. VACUUM DELETE ONLY:
   • 삭제된 데이터를 제거하지만, 정렬은 수행하지 않음.
   • 빠르게 공간을 회수하고 싶을 때 사용.
   • 사용 사례: 데이터 삭제 작업 이후 빠른 공간 복구가 필요한 경우.
4. VACUUM REINDEX:
   • 테이블의 인덱스를 재구성.
   • 클러스터형 인덱스가 성능 저하를 일으킬 경우 사용.

 

---

 

2. Search Service (Elasticsearch / Opensearch)

2-1. Elasticsearch/Opensearch 개요

• Elasticsearch는 오픈소스 기반의 실시간 검색 및 분석 엔진으로, 대규모 데이터에서 빠르고 정확한 검색과 복잡한 분석 작업을 지원.
• Opensearch는 Elasticsearch의 오픈소스 버전으로, AWS에서 제공하는 관리형 서비스(Opensearch Service)로도 사용 가능.

 

1. 문서(Document):
   • 데이터의 최소 단위로 JSON 형식으로 저장.
   • 관계형 DB에서 "행"에 해당함
2. 인덱스(Index):
   • 문서의 집합으로 데이터베이스의 "테이블"에 해당.
   • 다양한 데이터 구조와 필드를 저장 가능.
3. 샤드(Shard):
   • 데이터를 여러 서버에 분산해 저장하고, 분산 처리를 가능하게 함.
   • Primary Shard: 원본 데이터 저장.
   • Replica Shard: 원본의 복제본으로, 장애 복구 및 읽기 성능 향상에 사용.
4. 노드(Node)와 클러스터(Cluster):
   • 노드: Elasticsearch를 실행하는 개별 인스턴스.
   • 클러스터: 여러 노드로 구성되며, 데이터 분산 및 고가용성을 제공.

---

주요 기능

1. 검색(Search):
   • 정확한 값 검색과 전체 텍스트 검색 지원.
   • 검색 질의(Query DSL)를 사용해 필터, 범위, 정렬 등 복잡한 검색 조건을 설정 가능.
2. 분석(Analysis):
   • 데이터의 토큰화, 스템머(형태소 분석) 등 텍스트 분석 기능 제공.
3. 집계(Aggregation):
   • 데이터를 그룹화하거나 통계를 계산하는 기능.
   • 예: 평균, 합계, 최대값, 최소값 계산.
4. 실시간 로그 및 메트릭 분석:
   • 운영 환경에서 실시간 로그를 모니터링하고, 메트릭을 분석하여 문제를 빠르게 파악.

---

Elasticsearch/Opensearch 성능 최적화

1. 샤드 및 레플리카 구성 최적화:
   • 데이터를 효율적으로 분산하기 위해 적절한 샤드 개수 설정.
   • 노드와 샤드 간의 균형을 유지.
2. 인덱스 설정:
   • 자주 조회되는 데이터를 위한 캐싱 전략 설정.
   • **라이프사이클 관리(ILM)**를 통해 오래된 인덱스를 자동으로 아카이빙하거나 삭제.
3. 검색 쿼리 최적화:
   • 필터 캐싱 활용.
   • 쿼리 비용이 높은 정렬과 스크립트를 최소화.

---

AWS Opensearch 관련 서비스

1. AWS 관리형 서비스:
   • Opensearch Service는 Elasticsearch를 관리형으로 제공하며, 클러스터 관리, 백업, 모니터링을 지원.
2. 통합 서비스:
   • AWS Kinesis와 연계해 실시간 데이터 스트리밍 처리.
   • AWS Lambda와의 통합을 통해 이벤트 기반 데이터 처리 가능.

---

예상 면접/시험 질문

1. 기술 질문:
   • "Elasticsearch와 Opensearch의 차이점을 설명하라."
   • "Elasticsearch에서 샤드가 무엇이며, 어떻게 작동하는가?"
   • "검색 쿼리의 성능을 최적화하기 위한 방법은 무엇인가?"
2. 트러블슈팅 질문:
   • "Elasticsearch 클러스터의 노드가 장애를 겪는 상황에서 어떻게 대처할 것인가?"
   • "검색 속도가 느려졌을 때 문제를 해결하는 과정을 설명하라."
3. 의사결정 질문:
   • "고객의 요구사항에 따라 Elasticsearch와 Redshift 중 어떤 것을 추천하겠는가?"

 

---

3. Streaming Service

 

Kafka란?

• Apache Kafka는 분산형 메시지 스트리밍 플랫폼으로, 대규모 실시간 데이터 처리에 적합.
• 구성 요소:
  • Producer: 메시지를 Kafka로 전송.
  • Consumer: Kafka에서 메시지를 읽음.
  • Broker: 메시지를 저장하고 전달하는 서버.
  • Topic: 메시지가 그룹화되어 저장되는 단위.

Kafka의 주요 특징

1. 내결함성(Fault Tolerance):
   • 복제(replicas)를 통해 데이터 손실 방지.
2. 확장성(Scalability):
   • 브로커와 파티션(partition)을 추가해 선형적으로 확장 가능.
3. 실시간 처리:
   • 대규모 데이터를 실시간으로 스트리밍 및 처리.

---

Kafka 구성 및 작동 원리

1. Topic과 Partition:
   • Topic은 데이터를 저장하는 논리적 단위.
   • Partition은 Topic을 여러 부분으로 나누어 데이터 병렬 처리가 가능.
   • Replica: 각 Partition의 복제본.
2. Offset:
   • 각 메시지가 Partition에 저장되는 고유 번호로, 메시지 순서를 유지.
3. Consumer Group:
   • 동일한 Consumer Group 내 Consumer들은 Partition을 나눠 처리.

---

Kafka 성능 최적화

Best Practices:

1. 파티션 수 적절히 설정:
   • 처리량과 병렬 처리를 고려해 파티션 개수를 설정.
   • 파티션이 너무 많으면 브로커와 컨트롤러의 부담 증가.
2. 복제본 설정:
   • 최소 3개의 복제본 설정으로 내결함성 강화.
3. 데이터 압축 사용:
   • 네트워크 및 디스크 사용량을 줄이기 위해 메시지 압축(gzip, Snappy) 활성화.
4. Retention 설정:
   • 불필요한 데이터를 삭제하기 위해 적절한 데이터 보존 기간 설정.
5. 모니터링 도구 활용:
   • Prometheus와 Grafana를 활용해 Kafka 성능 및 브로커 상태 모니터링.

AWS에서 Kafka 클러스터 최적화:

• Amazon MSK(AWS Managed Streaming for Kafka):
  • Kafka 클러스터의 배포, 관리, 확장을 AWS에서 지원.
  • 비용 최적화를 위해 브로커 크기와 파티션 수 조정.

---

예상 면접/시험 질문

기술 질문:

1. Kafka의 Topic과 Partition의 역할을 설명하라.
   • 답변: Topic은 데이터 그룹화 단위, Partition은 병렬 처리 단위.
2. Kafka의 Offset이 무엇이며, 왜 중요한가?
   • 답변: 메시지 순서를 유지하며 Consumer가 처리한 위치를 추적.
3. Kafka에서 Consumer Group은 어떻게 작동하는가?
   • 답변: 각 Consumer는 Partition을 나눠 병렬 처리.

트러블슈팅 질문:

1. Consumer가 데이터를 읽지 못할 때 문제를 해결하는 과정을 설명하라.
   • 진단: Topic 이름, Consumer Group 설정, 네트워크 상태 확인.
   • 해결: Offset 초기화 또는 재설정.
2. Kafka의 브로커 장애 시 어떻게 복구할 것인가?
   • 복구 과정: 복제본(Replica) 상태 확인, 브로커 재시작.

의사결정 질문:

1. Kafka와 SQS(Simple Queue Service) 중 어떤 것을 선택해야 하는가?
   • Kafka: 대규모 실시간 데이터 처리.
   • SQS: 단순 메시징 서비스.

 

 

출처:

https://www.databricks.com/kr/glossary/star-schema

Star Schema (스타 스키마)

 

https://sunrise-min.tistory.com/entry/Star-schema%EC%99%80-Snowflake-schema-%EB%B9%84%EA%B5%90

Star schema와 Snowflake schema 비교