All
2장에서는 클라우드 데이터 플랫폼이 단일 데이터 웨어하우스 아키텍처와 다른점을 살펴본다
데이터 웨어하우스와 데이터 플랫폼
예제 상황
•
마케팅 부서에 MySQL 에 저장된 이메일 마케팅 캠페인 데이터 존재
•
사용자 클릭스트림 데이터 CSV 파일 내부 SFTP 서버에 존재
•
이 두 데이터를 조합해 데이터 분석 자동화
데이터 소스 형태
•
마케팅 캠페인 테이블(정형데이터)
campaign_id | email | unique_code | send_date |
campaign_1 | user1@example.com | 1234 | 2025-01-03 |
campaign_2 | user2@example.com | 2345 | 2025-03-04 |
•
클릭 스트림 데이터(반정형)
timestamp | content_json | other… |
1565395200 | {
url: “https://…”,
user_id: 3245,
browser_info: {...}
} | … |
1565396281 | {
url: “https://…”,
user_id: 3245,
browser_info: {...}
} | … |
클라우드 데이터 웨어하우스 활용
AWS로 예를 들면
flowchart LR A[MySQL] -->|Glue | B[Redshift] C[클릭스트림 CSV] -->|Glue| B
Mermaid
복사
•
Redshift는 모든 데이터를 정형 테이블 형태로 스키마를 맞춰 적재해야 하므로, 수집 단계에서 구조화가 필요함
SQL 예제
URL 파싱 및 캠페인 코드 추출
SELECT
DISTINCT SUBSTRING(
JSON_VALUE(CL.content_json, '$.url'),
1,
CHARINDEX('?', JSON_VALUE(CL.content_json, '$.url'))
) AS landing_url,
SUBSTRING(
JSON_VALUE(CL1.content_json, '$.url'),
1,
CHARINDEX('?', JSON_VALUE(CL1.content_json, '$.url'))
) AS follow_url
FROM clicks CL
JOIN campaigns CM
ON CM.unique_code = SUBSTRING(
JSON_VALUE(CL.content_json, '$.url'),
CHARINDEX('code=', JSON_VALUE(CL.content_json, '$.url')) + 5,
LEN(JSON_VALUE(CL.content_json, '$.url'))
)
LEFT JOIN (
SELECT
JSON_VALUE(CL_INNER.content_json, '$.user_id') AS user_id
FROM clicks CL_INNER
) AS CL1
ON JSON_VALUE(CL.content_json, '$.user_id') = CL1.user_id
WHERE CM.campaign_id = 'campaign_1';
SQL
복사
•
반정형 데이터에서 원하는 값을 추출하려면 복잡한 SQL 문이 필요함
한계점
•
복잡한 문자열 파싱
◦
JSON_VALUE 등 SQL 함수 사용 → 쿼리가 어렵고 가독성이 안좋음
•
확장성 제약
◦
SQL만으로 처리할 수 없는 로직이 생기면 대응 불가
◦
새로운 로직 추가 시 전체 구조 변경 필요
•
테스트·모듈화 어려움
◦
SQL 스크립트 단위 테스트 및 재사용성 낮음
클라우드 데이터 플랫폼 활용
flowchart LR A[MySQL] -->|Glue| S3 C[클릭스트림 로그] -->|Glue| S3 S3 -->|Spark 처리| Redshift
Mermaid
복사
위와 같은 구조는 업스트림 데이터 소스변경 관리가 용이함
•
웨어하우스: 입력/출력 스키마 모두 필요하기때문에 하나라도 변경되면 작업이 실패
•
플랫폼: 출력 스키마가 없어 업스트림 스키마 변경에도 파이프라인 동작
PySpark 예제
def get_full_url(json_column):
# extract full URL value from a JSON Column
url_full = from_json(json_column, "url STRING")
return url_full
def extract_url(json_column):
url_full = get_full_url(json_column)
url = substring_index(url_full, "?", 1) # "?" 이전 부분 추출
return url
def extract_campaign_code(json_column):
url_full = get_full_url(json_column)
code = substring_index(url_full, "?", -1) # "?" 이후 문자열
return substring_index(code, "=", -1) # "code=XYZ"에서 "XYZ" 추출
campaigns_df = ... # Spark SQL 또는 Python API 사용
clicks_df = ... # 마찬가지로 클릭 로그 로딩
result_df = campaigns_df.join(...) # 캠페인 조인 처리
Python
복사
•
스파크를 통해 재사용성이 높아짐
•
함수를 작은 단위로 분리해 테스트가 쉬움
데이터 액세스 관점
•
마케팅팀: 단순 리포트·지표 중심, 정형 테이블에 접근
•
데이터 분석가: 가공 전 원본 데이터까지 접근 필요, 복잡 쿼리·머신러닝 작업
데이터 웨어하우스는 집계된 형태만 제공하고 원천 데이터를 제공하지 않기 때문에, 다양한 사용자 그룹의 요구를 만족시키기 어려움
데이터 플랫폼은 BI용 집계 데이터와 함께 원천 데이터를 레이크 형태로 제공 가능하여 유연성이 높음