들어가며

9월 1일 코엑스에서 Snowflake의 Data Cloud World Tour가 열렸다. 저는 아직 오프라인 summit에 참가한 적이 없었거니와 제 직무인 빅데이터와 연관이 있는 summit이기에 매우 참가하고 싶었습니다. 하지만 평일에 진행되기에 신입사원인 저는 아쉽지만 이번 기회엔 참가하지 못할 것이라 생각했습니다. 그러나 마침 팀장님께서 AI/Bigdata와 관련된 다양한 summit이나 교육기회가 있으면 참가하라고 하셨고 사내 학습데이라는 좋은 제도(최대 월 2회, 개인학습을 업무시간으로 인정)를 통해 다녀올 수 있었습니다.

아래부터는 9/1일 코엑스에서 개최한 snowflake data tour에 다녀온 후기 및 정보 공유입니다.

기조연설 및 SNOWFLAKE 설명

현재 많은 기업들이 빅데이터의 활용성을 중요하게 생각하여 클라우드로 데이터베이스를 이관하면서 방대한 데이터들을 수집합니다.

기존 데이터 플랫폼의 한계점

1. 고정된 클러스터 리소스
2. 리소스 경합으로 인한 성능 저하
3. 이기종 플랫폼 간의 데이터 동기화 이슈
4. 데이터 사일로
5. 플랫폼 관리 복잡도 증가
6. 제한된 사용자 및 워크로드만 수용

특히 데이터 사일로에 대해서 해결하고자 많은 노력을 합니다.

플랫폼 한계점을 극복하기 위한 노력들

1. 데이터 민주화
2. ETL에서 ELT로 변화
3. 데이터 플랫폼의 성능 개선
4. Data Mesh
5. 데이터 가시성 확보

아키텍처 현대화: 데이터 플랫폼 구축

Tranditional Data Platform

1. 섬세한 클러스터 사이징 필요: 스토리지 + 컴퓨팅
2. 최소 6달 이상의 플랫폼 구축 기간 필요
3. 지속적인 유지 관리 및 튜닝 필요
4. 플랫폼 확장에 대한 오버헤드 존재: 시스템 다운타임 및 데이터 Rebalancing
5. 데이터 소스 다양화는 ETL 과부화 야기
6. 데이터 증가는 ETL 비용 증가 및 지연의 주요 원인
7. 데이터 레이크 보편화로 인해 원천 데이터 분석 요구사항 증가 → 유연하지 않은 ETL 파이프라인
8. 리소스 경합으로 성능 저하
9. 시간대 별 작업 분배로 최적화
10. 리소스 부족: 노드 추가 → 다운타임 발생 → 업무 지연
11. 비즈니스를 고려하지 않는 통합으로 접근: 다양한 형식의 data → ETL프로세스 집중 및 확산
12. 소수의 데이터 엔지니어 팀은 데이터 도메인 지식 부족 → 데이터 품질이슈 → 빅뱅 방식의 단일 데이터 플랫폼 구축은 장시간의 요구

Snowflake

1. ETL을 ELT로 전환
2. Fast extraction & load: 데이터 처리 최소화로 빠른 데이터 통합
3. 데이터 처리(ELT) 비용 절감
4. 워크로드 유형별로 물리적으로 격리된 실행 환경을 구성(Scale up, Scale out을 동시에 수행함으로써 Scale Across가능)
5. 이기종 DBMS간의 데이터 동기화
6. Data Sharing - 데이터 공급자: 데이터셋을 상품화하여 쉽고 안전하게 공유, 데이터 소비자: 필요한 데이터를 쉽게 검색 및 활용
7. Data Mesh: Snowflake Reference Architecture
8. 데이터 플랫폼은 기존 Domain시스템 별로 분산 구축
9. 데이터, 품질 및 파이프라인은 도메인 중심으로 오너십 유지 → Data Mesh 기반의 Self-Service Data Platform
10. 여러 도메인에 분산된 데이터는 유기적으로 연계 및 활용
11. New Workload → UNISTORE: Snowflake Unistore는 Transactional 워크로드와 Analytical 워크로드를 함께 사용하는 현대적인 접근 방식

SK브로드밴드의 사용 사례

Big Data, Data Lake → (OLAP) → Public Cloud

1. Cloudera 라이선스
2. Peak치에 맞춰진 하드웨어 용량의 문제
3. 배치 처리 시간의 증가 문제
4. 현업 사용자들을 위한 분석 환경

Why snowflake

1. 비용 절감(40%)
2. 효율성: Platform 유지관리 불필요
3. 안정성
4. Vision

	데이터	사용자	혁신,성장
SK브로드밴드	사내 모든 분석용 데이터	전 구성원의 Data Citizen화	Data로 일하는 문화 장착
Snowflake	Optimize Storage	Virtual Warehouse Scale up, Scale out	Data Sharing, Market place

→ 비즈니스 모델 혁신을 통한 성장

Future

OLAP + OLTP → UNISTORE → SK브로드밴드 DATA CLOUD

SK브로드밴드 아키텍처

• ETL - Hadoop → Amazon EMR, SPARK
• DW - On-prem DW → snowflake

Snowflake의 도입효과

1. Scale-Up/Down: 원하는 쿼리 성능에 맞추어 Warehouse 컴퓨팅 엔진 크기를 실시간 조절 가능하며 쿼리가 들어오지 않을 때에는 자동 suspend
2. Auto Clustering: 동시 쿼리 수행성을 높이기 위해 Auto clustering 설정 가능(Scale in/out 효과)
3. Data Lake + DW = Snowflake: 기존 정형데이터 csv뿐만 아니라 EMR에서 생성되는 Parquet 파일 로딩/쿼리 가능
4. Easy to use: 백업, 인덱싱, 파티셔닝 등 기존 관리 작업 필요하지 않음, 사용자 친화 UI

Qraft의 사용 사례

기존의 데이터 처리 과정

다양한 벤더사와 자사의 데이터들을 (각기 다른 데이터 형식) 가져와 python으로 전처리하여 사용

금융 데이터 분석

• 외부테이터: 다양한 데이터 벤더가 각각의 프로토콜과 포맷으로 데이터 제공
• ELT필요성: 금융 도메인을 기반으로 데이터 가공 필요
• 한정된 인력

금융 시계열 데이터: 데부분의 data는 onpramise, 과거의 데이터를 수집하기 위해 벤더사에서 구매하여 사용 → 데이터 통합 플랫폼 필요, dB, 서버, 성능 최적화, 저장용량 한계

데이터 통합관리 위해 DW도입 - 하둡 기반은 어렵고 당시 시니어 부재, 비용 비쌈, 스파크 필수적 → Cloud-based platform 이용 (성능 때문에 Amazon Redshift 사용 x) → GCP Bigquery 사용

Data를 API를 통해 불러올 경우: airflow사용, 배치 통해서 REST, SOAP 등으로 big query에 저장

실시간 동기화 추가(CDC platform) - airbyte, fivefarn... 중 google datafushion사용 → 실시간으로 변경사항 체크, 코드없이 etl 파이프라인 구축가능 + data stream과 data flow 동시에 사용가능

Architectire Before(GCP)

Platform	Role	Setup	Description
BigQuery	Data Warehouse	GCP 서비스 이용	구조화된 데이터 저장
Airflow	Workflow Orchestration	Airflow Helm Chart로 Kubernetes operator 적용하여 배포 및 관리	ETL 배치 작업 실행
Google Cloud Storage	Data Lake	GCP 서비스 이용	로우 데이터 저장
PostgreSQL/MySQL	로우 데이터 저장 및 데이터 분석용	AWS RDS Database 및 On-premise로로 이중화	시계열 데이터 저장

최종테이블은 data fusion과 datastream+dataflow를 머지해서 사용
하지만! data fusion이 너무 비싸고 replicate시에 오류가 생기면 서버가 죽는다.
→ GCP에서 Snowflake로 이전
[참고] Data replicate

Architectire After(snowflake)

• Snowflake통해서 Data sharing 이용(실시간 가능)
• airflow는 flyte(MLops전용 pipeline)로 대체

Platform	Role	Setup	Description
Snowflake	Data Warehouse	Snowflake 계정 생성	구조화된 데이터 저장
Flyte	Workflow Orchestration	Flyte Helm Chart로 배포 및 관리	ETL 배치 작업 실행
AWS S3	Data Lake	AWS 서비스 이용	로우 데이터 저장

Flexible Resource Utilization

• 컴퓨팅 리소스를 필요할 때만 사용합니다.
• scale-up, scale-out에 제약이 없어 빠른 쿼리 성능 개선이 가능합니다.
• 스토리지 비용이 많이 단축됩니다.
• 압축률이 높아 대용량 데이터를 효율적으로 저장할 수 있습니다.

Single Source of Truth

• 데이터가 파편화되어 저장되지 않습니다.
• 모든 유형의 데이터를 하나의 플랫폼에서 접근이 가능합니다.

All in One

• Data Lake, Data Warehouse, Data Mart 기능을 포함하여 통합 플랫폼으로 구성이 가능합니다.
• AWS, Azure, GCP를 포함한 클라우드 플랫폼을 지원합니다.
• 데이터 분석 환경을 개선하는 일에 보다 집중할 수 있습니다.

마치며

빅데이터 시장에서 유망한 플랫폼회사로 자리매꿈하고 있는 snowflake의 summit을 통해 현재 빅데이터 기술의 동향에 대해서 알게 되었고, 다양한 회사들의 데이터 아키텍쳐 구조를 알 수 있었습니다.

[2022-12-18 추가]
당시에 입사한지 한달도 채 안된 상태였기에 들었던 내용들의 10%도 이해하지 못하였고 우선 기록하는데에 급급했습니다. 현재도 아직 새내기이지만 글을 다시 정리하며 보니 그 때에 보지이 않던 것들이 많이 보이기 시작하고 다른 회사들에서 클라우드 플랫폼의 변화와 아키텍쳐 구축에 대해 어떤 고민을 하는지 심층적으로 분석하게 되며, 어떻게 하면 효율적으로 데이터를 구축할 수 있을지에 대해 다시금 생각하게 되었습니다.