CDC (Change Data Capture)
- 데이터베이스에서 발생하는 변경 사항을 실시간으로 감지·수집하여 다른 시스템으로 전달하는 기술
- 푸시 : 데이터 source에서 변경 식별, target에 데이터 적재
- 풀 : 정기적으로 데이터 적재
CDC : Log Scanner on Database
- 데이터베이스 영향 최소화, 변경 식별 지연시간 최소화, 트랙잭션 무결성 영향 최소화, 스키마 변경 불필요
- Time Stamp on Rows : 마지막 변경 시점을 기록, 변경 시점을 기준으로 데이터 식별 (실시간 추적 X)
- Version Numbers on Rows : 버전을 기록, 참조 테이블
- Status on Rows : 위 두 기법에 대한 보완, 데이터 변경 여부를 True / False로 저장
- Time/Version/Status on Rows : 위 세 기법 모두 활용
- Triggers on Tables : Subscribe and Publish, 시스템 복잡도 증가, 변경 관리 어려움, 확장성 감소 (실시간 추적)
- Event Programming : 데이터 변경 식별을 애플리케이션에서 구현 (개발 부담, 복잡도 증가)
- Log Scanner on DataBase : 트랜잭션 무결성 / 애플리케이션 영향도 최소화, 스키마 변경 불필요 (실시간 추적)
EAI (Enterprise Application Integration)
- 기업 내부에 흩어져 있는 여러 애플리케이션과 시스템을 하나의 통합된 흐름으로 연결하는 기술·아키텍처
- 웹서비스, XML 등 표준 기술을 사용하여 서비스 중심으로 하나의 프로세스를 처리
- 시스템 간 데이터 공유, 업무 프로세스 자동화, 중복 개발 감소, 데이터 정합성 유지
- 미들웨어(=Hub, 브로커)를 이용하여 비즈니스 로직을 중심으로 Application 통합 (중앙집중식 연결구조)
- Federation(inter-communication) : EAI 엔진이 외부 시스템으로부터 데이터 요청을 일괄 수령 후 전달
- Meditation : Subscribe and Publish
* 미들웨어(=Bus)를 이용하는 것은 ESB(Enterprise Service Bus)
ODS(Operational Data Store) vs DW(Data Warehouse)
| ODS | DW | |
| 목적 | 운영 지원 | 의사결정·분석 지원 |
| 주 사용 시점 | 현재 또는 거의 실시간 데이터의 업데이트 저장 환경 |
과거 데이터 중심 적재(Load), 접근(Access) 기능 중심 |
| 데이터 성격 | 최신 데이터, 정제 최소화 | 정제·통합된 데이터 상세 데이터 및 2차 가공 요약 데이터 |
| 데이터 범위 | 짧은 기간 (최근 데이터) 소규모 데이터 |
장기간 (수년치 가능) 대규모 데이터 |
| 갱신 방식 | 빈번한 갱신 (Near Real-time) | 주기적 배치 (ETL) |
| 정규화 | 높음 (3NF 등) | 낮음 (Star / Snowflake) |
| 사용 주체 | 운영자, CS, 실시간 모니터링 | 경영진, 분석가, BI |
| 쿼리 성격 | 단순 조회, 빠른 응답 | 복잡한 집계·분석 |
| 시스템 부하 | OLTP와 분석 사이 완충 | 분석 전용 |
무공유 클러스터(Shared-Nothing Cluster)
- 각 노드가 자신의 CPU, 메모리, 디스크를 모두 독립적으로 소유
- 뛰어난 확장성 (노드 확장 제한 없음), 적은 병목 현상, 비용 효율
- 데이터 재분배 필요, 복잡한 트랜잭션 / 조인 처리, 데이터 일관성 관리가 어려움
- Hadoop HDFS, Spark, Cassandra, MongoDB (Sharded), Amazon Redshift
[Node A] ─ Disk A (자신이 관리하는 데이터 파일을 로컬 디스크에 저장)
[Node B] ─ Disk B
[Node C] ─ Disk C
공유 디스크 클러스터(Shared-Disk Cluster)
- 모든 노드가 하나의 공통 디스크를 공유
- 데이터의 일관성, 가용성 확보
- 트랜잭션은 독립적으로 처리되지 않고, 일관성 유지를 위해 조정되고 관리
- CPU와 메모리는 각자, 스토리지만 공유
- 데이터 일관성, 관리 단순, 장애 복구 용이, fault-tolerance 제공
- 노드를 추가하더라도 스토리지 병목 발생, 확장성 제한, 고성능 공유 스토리지 필요(비용)
- Oracle RAC, IBM DB2 pureScale, MS SQL Server Failover Cluster
[Node A] ─┐
[Node B] ─┼─ Shared Disk (SAN, NAS)
[Node C] ─┘
Oracle RAC
- 한 노드가 장애를 일으킨 경우, 클러스터를 구성하는 다른 노드가 살아 있으면 서비스가 가능
- 추가 처리 성능 필요시 새 노드를 추가하기 쉬움
- 모든 노드가 동일한 데이터 파일에 접근, 특정 노드가 데이터를 소유하지 않음.
구글 파일 시스템 (GFS, Google File System)
가정
- 서버의 고장이 빈번히 발생하는 저가형 서버로 구성된 환경
- 대부분의 파일은 대용량
- 연속적으로 많은 데이터를 읽는 연산 + 임의의 영역에 적은 데이터를 읽는 연산
- 쓰기 연산은 순차적으로, 파일 갱신은 드물게
- 여러 클라이언트에서 동시에 데이터를 추가
- 낮은 응답시간보다는 높은 처리율이 중요 (Throughput > Latency)
원리
- Master : 메타데이터 관리 (파일 → chunk 매핑, 위치, 버전, 락)
- ChunkServer : 실제 데이터 저장
- Client : 데이터 읽기/쓰기 수행
Client ↔ Master ↔ ChunkServer
↕
Metadata* 데이터는 Master를 거치지 않는다
파일 분할 방식 (Chunk)
- 파일 → 64MB 고정 크기 Chunk
- 각 Chunk는 ChunkHandle(ID) 로 식별
- 각 Chunk는 기본 3개 복제본 유지
- 마스터 서버에 의해 Chunk의 생성 / 삭제
읽기 동작 원리
- Client → Master (이 파일의 이 offset은 어느 chunk이고 어디 있나?)
- Master → Client : ChunkHandle, Replica 위치들 (ChunkServer 목록)
- Client → ChunkServer : 가장 가까운 서버 선택, 직접 데이터 읽기
러스터 (Luster)
- 객체 기반 클러스터 분산 파일 시스템
- 메타 데이터(메타데이터 서버에 의해 관리)와 실제 데이터를 분리
- 클라이언트 파일 시스템 + 메타 데이터 서버 + 객체 저장 서버
- 동시성 제어를 위한 별도 잠금 사용
하둡 에코시스템 요약
비정형 데이터 수집 : Chuckwa, Flume, Scribe, Kafka
정형 데이터 수집 : Sqoop, Hiho
데이터 연동 : Sqoop
분산 파일 시스템 : HDFS (순차 접근 방식 지원, 파일 단위로 저장, 파일은 변경되지 않는다고 가정)
자원 관리 : YARN
분산 데이터베이스 : Hbase
대용량 SQL 질의 : Hive, Pig
데이터 마이닝 : Mahout
실시간 SQL 질의 : Impala, Tajo
워크플로우 관리 : Oozie, Azkaban
인메모리 관리, 데이터 처리 분산 시스템 : Apache Spark
SQL on 하둡 : Shark, Apache Drill, HAWQ
구글 빅테이블
- NO SQL (ACID 보다는 BASE, Basically Available, Soft state, Eventually consistent)
ACID
| A – Atomicity (원자성) | 트랜잭션은 전부 성공 or 전부 실패 |
| C – Consistency (일관성) | 트랜잭션 전후 제약조건 유지 |
| I – Isolation (격리성) | 동시에 실행돼도 혼자 실행한 것처럼 |
| D – Durability (지속성) | 커밋된 데이터는 장애 후에도 보존 |
BASE
| B – Basically Available | 항상 응답은 함 (정확하지 않아도) |
| S – Soft State | 상태가 계속 변할 수 있음 |
| E – Eventual Consistency | 결국엔 일관성 도달 |
ACID vs BASE
| ACID | BASE | |
| 일관성 | 강함 (즉시) | 약함 (최종적) |
| 가용성 | 상대적으로 낮음 | 매우 높음 |
| 확장성 | 수직 확장 위주 | 수평 확장에 유리 |
| 장애 허용 | 제한적 | 강함 |
| 트랜잭션 | 엄격 | 느슨 |
| 철학 | 정확성 우선 | 가용성 우선 |
스파크 (Spark)
- 데이터 처리를 위한 분산 시스템
Scribe
- 데이터 수집 플랫폼 (Facebook)
- 중앙 집중서버
아파치 타조 (Tago)
- 고려대 대학원에서 개발된 아파치 인큐베이션 프로젝트
하둡
- 비공유형 분산 아키텍처
- 각 노드는 자체 저장소와 자원을 가지고, 병목 없이 독립적으로 처리가 가능
- 하둡 분산 파일시스템(HDFS = 3중 복제, 데이터 유실 방지) + MapReduce
맵리듀스 절차
- 데이터 분할(Splitting), 맵핑(Mapping), 셔플 및 정렬(Shuffling & Sorting), 리듀싱(Reducing)
- Split → Map → Combine → Shuffle & Sort → Reduce
SQL-on-Hadoop
- 하둡에 저장된 대용량 데이터를 SQL로 처리, 분석하는 기술
- 샤크(Shark), 아파치 드릴(Drill), 호크(HAWQ)
- 임팔라 : SQL-on-Hadoop 쿼리 엔진 (MapReduce를 쓰지 않고 실시간 SQL 쿼리 제공)
- 아파치 타조
- 스팅거 (Stinger) : Hive를 배치용 SQL에서 실용적인 SQL-on-Hadoop으로 끌어올린 프로젝트
샤크
- 인메모리 기반 대용량 데이터 웨어하우스
- 하이브와 호환, SQL 질의 및 사용자 정의 함수 사용
Oozie
- 하둡 작업 워크플로우 관리 도구, 코디네이터 시스템
- MapReduce, Hive, Pig, Sqoop, Spark 작업 연결
Hive
- 하둡에서 SQL 분석을 가능하게 해주는 DW 도구
- 하둡 위의 데이터 웨어하우스 시스템
Chukwa
- 하둡 기반 로그 수집·모니터링 시스템
- 분산 환경에서 생성되는 데이터를 HDFS에 안정적으로 저장
Hiho
- 하둡 데이터 정합성·품질 검증 도구
- 대용량 데이터(Sqoop) 검증 및 정합성 체크 솔루션
Sqoop
- RDBMS ↔ Hadoop 간 대용량 데이터 전송, 연동 솔루션
- 오라클, MySQL, 사이베이스 등 관계형 데이터베이스 연동 가능
- 데이터 이동, 연동
- Direct 옵션으로 대량의 데이터를 효율적으로 이동
Pig
- 대용량 데이터 처리용 스크립트 언어 플랫폼
- 데이터 처리를 위한 고차원 언어, 추상화된 병렬 처리 언어
- Pig Latin 언어 제공, MapReduce 프로그래밍
- 데이터 처리
Flume
- 실시간 로그/이벤트 수집 시스템
- Source – Channel – Sink 구조
- 데이터 수집,
Mahout
- 하둡 기반 머신러닝 알고리즘 라이브러리
- 대규모 데이터 분석용 알고리즘 제공
- 데이터 분석
로그 데이터 수집 시스템
- 아파티 Flume-NG, 아파치 Chukwa, 페이스북 Scribe
페이스북 프레스토
- 데이터 웨어하우스에서 대화형 쿼리를 실행하기 위한 분산 SQL 엔진
아마존 Simple DB 모델
- Domain, Item, Attribute, Value
- Schema가 없음.
MySQL
- 장애가 발생한 노드가 복귀되어 클러스터에 투입되면 기존/변경 데이터 모두 동기화가 자동으로 수행
- MySQL 노드는 클러스터 데이터에 접근을 지원
- 관리 노드는 클러스터를 관리하는 노드, 시작과 재구성에만 관여
- 클러스터 참여 노드 수는 255개 제한, 데이터 노드는 48개 제한
- MySQL 클러스터는 비공유형 메모리 기반 데이터베이스의 클러스터링 지원
하이퍼바이저 가상화
- 물리 서버 위에 하이퍼바이저를 두고 그 위에 각각 독립적인 OS를 가진 가상 머신(VM) 실행
- 호스트 컴퓨터에서 다수의 운영 체제를 동시에 실행하기 위한 논리적인 플랫폼
- VMware ESXi, KVM, Hyper-V, Xen → IaaS에서 주로 활용
컨테이너 기반 가상화
- 더 낮은 수준의 가상화, 경량화된 구조
- 호스트 OS 커널을 공유 → 각기 다른 커널을 사용할 수 없음
- 애플리케이션과 실행 환경만 격리
- 가상 운영환경 : 가상화를 지원하는 계층
- Docker, Kubernetes
| 하이퍼바이저 | 컨테이너 | |
| 가상화 단위 | OS 단위 가상머신별 관리 |
프로세스 단위 중앙 집중식 관리 구조 |
| 커널 | VM마다 독립 커널 | 호스트 커널 공유 |
| OS 혼합 | 가능 (Linux + Windows) | 불가능 (커널 동일) |
| 성능 | 상대적으로 오버헤드 큼 | 거의 네이티브 수준 |
| 부팅 시간 | 수십 초 ~ 수분 | 수 초 이내 |
| 리소스 사용 | 큼 | 매우 효율적 |
| 격리 수준 | 매우 강함 | 상대적으로 약함 |
| 보안 | 높음 | 커널 취약점 영향 가능 |
| 이식성 | 낮음 | 매우 높음 |
| 대표 기술 | VMware, KVM | Docker, Podman |
Memory Ballooning
- 가상머신(VM)마다 메모리를 고정으로 다 주면, 어떤 VM의 메모리는 놀고 있는데, 다른 VM의 메모리는 부족할 수 있음.
- 하이퍼바이저가 메모리를 유연하게 재분배하는 것
- 각 VM 안에 Balloon Driver가 설치됨
Transparent Page Sharing (TPS)
- 여러 VM이 똑같은 내용을 메모리에 올려놓는 경우가 많음 → 동일한 OS, 라이브러리, 초기 데이터 (중복 데이터)
- 하이퍼바이저가 메모리 페이지 내용을 스캔하여 하나의 공유 페이지로 합친다.
스타 스키마
- 기본키와 외래키를 사용하여 차원 테이블과 연결
- OLAP에 적합, 대량의 데이터를 분석하는 데 사용
- 차원 테이블을 정규화하지 않고 중복을 허용
스노우 플레이크 스키마
- 스타 스키마의 차원 테이블을 제 2 정규형 이상으로 정규화
- 조인할 테이블 개수가 많아져 복잡도가 증가
- 데이터 중복을 줄이기 위해 관련 데이터가 여러 테이블로 나누어 저장
댓글