DA•CDO

■ 데이터브릭스란

• 데이터브릭스는 아파치 스파크 기술을 모티브 
• 스파크라는 기술은 UC버클리대학 내 빅데이터 연구 조직인 AMP랩에서 처음 탄생 
• 해당 연구실 교수와 연구원들은 가치가 커질 것으로 예상하고 2013년에 데이터브릭스를 공동 설립
• 2020년 기준 연 매출이 4억 2500만 달러(한화 약 4740억 원)

■ 데이터브릭스 아키텍처

ㅁ Apache Spark외에 여러 솔루션 도입

• Delta Lake : 데이터레이크의 ACID를 지원해 DW처럼 활용
• mlflow : 머신 러닝 개발과 관리 기능 지원(ML 개발 + MLOps)
• Koalas : 대량의 데이터 분석 지원(Pandas와 비슷한 활용)
• Redash : SQL 시각화 기능 지원

■ 구독 플랜

• SaaS(Software as a Service)형 서비스로 클라우드 비용에 상관없이 SaaS 구독 정책 따름
• 자원 활용 만큼 후불 지불 정책

■ Databricks vs. Snowflake

1. 모두 Data Warehouse에서 Data Lakehouse로의 전환 사상에서 발전
2. EDW의 경우 
       - 구조화된 데이터
       - 중앙 집중식 저장 및 처리 방식
       - 고가의 장비
       - ETL 중심
       - 데이터 신뢰성 확보
3. Data Lake의 경우 
       - 다양한 유형의 데이터
       - 분산 저장 및 처리
       - 저가의 장비
       - ELT(저장 후 필요에 따라 활용)
       - 데이터 신뢰성 부족
4. EDW와 Data Lake의 장점을 결합한 것이 Data Lakehouse 개념

■ Databricks vs. Snowflake 아키텍처 비교

■ 개인적 사견

• Snowflake는 클라우드 기반의 DW엔진처럼 보여짐, NoSQL 영역을 제대로 처리 못하는 듯.
• Databricks는 각기 다른 Solution이 연결된 플랫폼으로 보여짐, 체계적으로 개발된 엔진은 아닌 것으로 보여짐.
• 아직 많은 정보를 확인하지 못한 사견에 불과.

※ Resources

• www.databricks.com
• www.datagrom.com

■ 스노우플레이크 소개

스노우플레이크는 2014년 기업이 가진 데이타를 잘 정리해주는 데이타 웨어하우스, 데이타 창고로 시작했고, 2019년에는 데이타 웨어하우스를 이용하는 사용자들이 쉽게 만나고 연결해 줄 수 있는 클라우드 데이타 플랫폼으로 발전했으며, 2020년이후에는 이를 데이타를 클라우드에서 공유할 수 있도록 만들어 시간적, 공간적, 물리적 제한없이 언제든 자유롭게 데이타를 공유하고, 판매할 수 있는 기업으로 성장.

• 2014년, 기업의 데이타를 잘 정리해주는 데이타 웨어하우스로 시작
• 2019년, 데이타 웨어하우스 사용자들을 연결, 공유, 판매할 수 있는 클라우드 데이타 플랫폼으로 발전
• 2020년, 클라우드에서 데이타를 공유, 판매할 수 있는 데이타 클라우드로 발전

■ 데이터 파이프라인 변화

빅데이터 환경에서 다양한 유형의 데이터 저장 및 처리를 위한 데이터 엔지니어링 비용 절감의 필요성과 데이터 이해가 높은 데이터 분석가들이 데이터를 빠르고 손쉽게 추출할 수 있는 환경이 필요함에 따라 ELT 전환이 요구됨

www.snowflake.com

■ ELT(Extractioin - Loading - Transformatio)의 필요성

dbt and the Analytics Engineer — what’s the hype about? (validio.io)

■ Snowflake 아키텍처

• 중앙집권식 스토리지(Centralized Storage)는 정형/비정형의 모든 데이타가 저장되고 일관성이 유지되는 곳
• 다중 클러스터 컴퓨팅(Multi-Cluster compute)은 중앙 집권식 스토리지에서 이용하는 데이타 단일 복사본에 액세스해서 여러 사용 사례를 개발
• 클라우드 서비스(Cloud Services)는 고객들이 스노우플레이크 플랫폼을 쉽고, 친화적인 사용자 경험을 제공

■ Modern data pipeline with Snowflake technology

1. 데이터 웨어하우스(Data Warehouse)
   . 최신 클라우드 데이터 웨어하우스를 지원하기 위해 구축된 데이터 플랫폼에서 데이터 분석을 가속화
   . 모든 유저들이 쉽게 데이터 접근 가능
   . SQL 기반으로 포괄적 데이터 분석
   
   
2. 데이터 레이크(Data Lake, Raw Data)
   . 최신 데이터 레이크 전략을 통해 데이터 액세스, 성능 및 보안 향상
   . 스노우플레이크 플랫폼에 데이터 레이크(Raw data) 구축
   . 중앙 데이터 저장소 역할 + 강력한 보안
   . 모든 데이터를 안전하게 저장
   
   
3. 데이터 엔지니어링(Data Engineering)
   . 고객이 선택한 언어로 간단하고 안정적인 데이터 파이프라인 구축
   . 다양한 부서에서 SQL을 이용해 데이터 파이프라인을 손쉽고 효율적으로 구축·관리
   . Raw data를 사용 가능한 데이터로 변환
   . 실시간 데이터 변환을 통한 빠른 의사 결정 지원
   
   
4. 데이터 과학(Data Science)
   . 선택한 프레임워크를 사용하여 모델링을 위한 간단한 데이터 준비
   . 통계 분석 툴, 머신러닝 기술 등을 이용해 방대한 양의 데이터를 분석
   . 대규모 Raw data를 변환해 고급 데이터 분석 제공
   . 다양한 프로그래밍 언어 지원(Python, Java, Scala, R 등)
   
   
5. 데이터 어플리케이션(Data Applications)
   . 비용 효율적 확장 및 빠른 분석 기능을 일관되게 제공하는 데이터 집약적인 앱개발을 간소화
   . 분석용 애플리케이셔 개발 및 제공
   . 스노우플레이크를 기존 비즈니스 앱으로 연결
   
   
6. 데이터 교환(Data Exchange)
   . 비즈니스 생태계에서 실시간 데이터 공유 및 협업
   . 데이터를 공유하고 서로 연결하고 협업할 수 있도록 해주는 솔루션
   . 데이터 허브를 통해 여러 사용자가 쉽게 정보 교환
   . 서로 다른 협력 기업들끼리도 빠른 데이터 교환

■ Snowflake Data Marketplace

• 세계 유수 기업의 다양한 데이터 및 데이터 서비스, 애플리케이션을 제공
• Snowflake Data Cloud의 기능을 활용하여 타사 제공업체의 데이터 및 서비스, 애플리케이션을 안전하게 액세스
• 셀프 서비스 평가판과 데이터, 앱에 대한 직접 액세스로 빠르게 참고 구매

※ Resources

• https://www.altexsoft.com/blog/snowflake-data-warehouse-pros-cons/
• https://happist.com/583463/%EC%8A%A4%EB%85%B8%EC%9A%B0%ED%9...
• https://www.snowflake.com/en/

■ 주요 차이점

■ 별자리 스키마(galaxy schema)
    • 차원 테이블을 공유하는 두 개(이상?)의 팩트 테이블 존재
    • 별자리 스키마에서 차원을 Conformed Dimensions라고도 함
    • 더 나은 이해를 위해 팩트 테이블을 집계하는데 유용

■ 스타 클러스터 스키마(star cluster schema)
    • 스타 스키마의 계층과 눈송이 스키마의 계층의 중간 형태

■ 차원 모델링 주요 요소
    • 팩트 : 비즈니스 측정값. 측정 가능한 숫자값.
    • 차원 : 치수나 컨텍스트라고도 함. 비즈니스 관점이나 분석 대상.


■ 차원 모델링 프로세스
    1. 비즈니스 프로세스 선택
        - 비즈니스 요구사항 수집
        - ex. 주문처리, 출하, 자재 구매, GL 등

    2. Grain 선택
        - 팩트 테이블의 레코드가 나타내는 것을 정확히 설명
        - 팩트 테이블의 세부 수준 표현 및 결정
        - 최소 Grain은 Dim이 될 수 없다?

    3. 차원 선택
        - 단일값이 취할 수 있는 모든 가능한 설명을 나타내는 차원 추가
        - ex. 날짜, 시간, 제품, 고객, 상점 등

    4. 팩트 확인
        - 팩트 테이블에 로드할 숫자값 선택
        - 비즈니스 프로세스의 KPI나 측정 대상 선별

    5. 스키마 작성
        - 다차원 모델링 구현
        - 스타(star) 스키마 vs. 눈송이(snowflake) 스키마

■ 차원 모델링 규칙
    • 단일 팩트 테이블의 모든 팩트가 동일한 수준(Grain)에 있는지 확인
    • 차원 테이블은 가능한 속성이 많고 Row가 적게 유지(차원의 속성은 분석시 필터링의 대상)
    • 팩트 테이블은 가능한 필드가 작고 Row가 많게 운영
    • 성능을 위해 차원 테이블에 대리키(Surrogate Key)를 사용하고 팩트에 FK로 반영
    • 또한, 성능을 위해 최소한의 Join 유도
  

■ 차원 모델링 이점
    • 비즈니스를 쉽게 이해할 수 있는 구조
    • 쉬운 이해 및 분석에 도움되는 일관된 차원의 그룹화
    • 쿼리 성능 향상, 비정규화 발생 허용
    • 확장이 용이
      - 팩트 테이블에 혼란을 주지 않으면서 새로운 차원 도입 용이
      - 응용 프로그램에 영향없이 필드 추가 가능

■ 차원테이블에서의 대리키
    • 데이터 소스 시스템에서 추출한 키가 아닌 데이터웨어 하우스에서 생성되고 관리되는 키

■ 대리키(Surrogate Key) 이점
    • 성능 : 차원테이블과 팩트테이블간의 조인 처리 효과적
    • 통합 : 데이터 획득시 대리키와 일치하는 소스키가 없어도 여러 데이터 소스 통합 가능
    • 데이터 버전 관리 : 차원테이블에서 필드 값 변경 추적 가능

■ Slowly Changing Dimension(SCD)
    차원 속성이 변경될 경우 '천천히 변화하는 유형'을 효과적으로 관리하는 대응 기술
    (아래 이미지는 구글링으로 추가)

    • Type 1
        - 이력이 필요하지 않은 경우 덮어 씀(overwritten).
        - 기록 다시 시작.

    • Type 2
        - 새로운 Row를 추가하여 관리함.
        - 계속된 이력을 보존.

    • Type 3
        - 새로운 속성값을 기존 Row에 추가하고 기존 값을 보관
        - 이전 값과 새로운 값을 사용하여 변경 전/후만 기록

■ OLAP 유형

■ MOLAP vs. ROLAP

• Reference : http://i-bada.blogspot.kr/2014/01/dw.html

요건정의 (DW Requirement Definition)
-.사용자 요구사항을 정의하고, 사용자 요구사항에 맞도록 시스템을 설계,구축
-.프로젝트의 추진 방향과 전략을 결정하고 현행 시스템을 분석하여 데이터모델을 정의. DB생성에 대한 준비를 하며, 그 결과를 확인.


데이터 추출 (Data Acquisition)
기존 시스템으로부터 데이터를 추출하고 로딩하기 위한 요건을 분석하고, 설계 및 프로그래밍
Tool을 활용할 경우에는 Tool선정 및 기능검토, 추가개발에 대한 요건 정의.
ETL에 필요한 제반 내용을 정의하고,구현
이 과정은 데이터의 품질에 대한 고려가 필요하며, 부정확한 데이터에 대한 처리과정도 고려


기술환경 (Technical Architecture)
시스템을 구축하기 위해 필요한 기술적 아키텍쳐 정의
시스템 구축 시 상당히 다양한 시스템이나 툴들이 사용될 수 있으며, 현 시스템 기술환경의 확장성 여부 등도 고려


데이터 품질 (Data Quality)
데이터의 품질을 확보할 수 있는 방안을 수립하고, 데이터 정제, 통합규칙, 오류, 예외처리 규칙을 정의
품질검사 및 관리를 위한 모듈을 구현


메타데이터 관리 (Metadata Management)
전사 데이터표준 및 사전을 기반으로 하여 메타 데이터 정의
메타데이터의 요건을 분석, 시스템에서 효율적으로 사용할 수 있도록 구현하며, 메타데이터의 관리방법 정의


데이터베이스 설계 및 구축 (Database Design and Build)
통합 데이터 시스템을 구축하기 위해 필요한 관계형 또는 다차원 데이터베이스에 대한 논리적인 모델을 작성하고, 물리적 구조를 설계
정의된 논리/물리 모델을 바탕으로 DB생성 스크립트를 작성하고, 이를 이용하여 DB를 구축


데이터 액세스 (Data Access)
구축된 시스템을 최종 사용자가 효율적으로 사용할 수 있도록 요건을 정의하고, 설계
데이터 액세스를 위한 Tool을 사용할 경우 이에 대한 화면설계
툴의 기능으로 구현될 수 없는 경우에는 개발여부를 확정하고, 이에 대한 구현작업을 수행


테스트 (Testing)
테스트 환경 준비 (테스트 요구사항, 테스트 일정, 주체, 시나리오 및 관련 환경) , 통합테스트 및 고객 Acceptance Test 등을 시행


적용 (Adoption and Learning)
구축된 시스템을 실제 사용하는 조직에 적용하고 정착시키기 위한 작업을 정의
프로젝트 초반에 운영 및 적용에 필요한 계획을 수립, 시스템 관리 및 운영 절차도 포함하여 정의