• 데이터 민주화

  • 기술적 지식이 부족한 사용자도 데이터 조직의 지원 없이 데이터에 액세스하고 활용

  • 누구나 사용할 수 있어야 함

  • 많은 사람들이 쓰더라도 규칙적으로 사용되며, 데이터 조직이 전체적으로 관리를 할 수 있어야 함

• 하이퍼 커넥트의 데이터 인프라

  • (~2019) S3 => Redshift + Spark

    • 관리 포인트가 증가

  • (2019 ~ 2023) BigQuery

    • Composer + BigQuery

    • 사용하기 편리했지만 점점 문제가 발생

      • 가공되지 않은 데이터를 사용하고 싶은 경우 이슈 발생. S3에 가공되지 않은 데이터가 존재했음(Raw 데이터인가?)

      • Airflow가 익숙하지 않은 사람들은 스케줄 쿼리. 마이그레이션을 진행했으나 어려웠음

  • (2023 ~) Databricks

    • Databricks의 Raw 영역을 저장해 활용

    • 스케줄 쿼리를 만드는 내부 도구 생성

• 데이터브릭스 도입할 때 고민

  • 셀프 서비스를 염두에 둠

  • 데이터를 어디에 저장하고 활용해야 하는가?

  • 어떤 클러스터를 쓰는가?

  • Workflow 생성은 어떻게 하고 코드 관리를 어떻게 할까?

  • 권한 관리 및 리소스 비용은 어떻게 추적해야 할까?

• 데이터브릭스 도입 전에 정해야 하는 정책들

  • Compute Cluster : 사용자에게 어떻게 Compute Cluster를 전달할까?

    • 직접 만들게 할 수 있지만, 어려울 수 있음. 미리 모든 클러스터를 생성해서 선택해서 쓸 수 있도록 함

    • 사용하지 않을 때 과금이 되지 않아 껍데기를 만든 것

    • 클러스터엔 기본 conf를 저장하고, 팀별 구분

    • 여기서도 이슈가 존재

      • 공용으로 만들면 single user로 사용이 불가능

      • GPU 인스턴스를 사용하고 싶은 경우, 고성능이 필요한 경우 불가능

    • Purpose Cluster

      • 사용자가 원하는 스펙을 직접 작성해 tf 파일 수정, PR 생성

  • Git Folder Structure

    • 데이터 파이프라인 Git, CI/CD Git

    • 데이터 파이프라인 Git

      • prod/dev

      • Source : 외부에서 데이터를 가지고 올 때. 카프카 / 빅쿼리

      • Sink : 데이터브릭스의 데이터가 외부로 나갈 때

      • Transform : 델타레이크에 있는 데이터가 가공하여 델타레이크에 저장되는 코드

      • manifest : 파이프라인 메타데이터 정리

    • CI/CD 자동화

      • prod/dev

      • product, 팀별, workflow별

  • Workspace Folder Structure

    • 대시보드, 쿼리는 Git을 사용하기 애매했음

    • Databricks 내부에 파일을 저장해야 하는 경우

    • 자유롭게 제작

  • SQL Warehouse

    • SQL Cluster는 어떻게 세팅할까?

    • 처음엔 팀별로 클러스터를 생성했으나, 파편화가 되어서 전사 제공해서 공유

    • 오토스케일링 적용

  • Permission

    • 팀과 멤버들을 Group으로 정의. 한번 추상화를 해서 관리

    • 회사의 조직 개편, 개발 조직 내부 구조를 분리해서 코드 업데이트가 자주 일어나지 않도록 진행

  • Tag

    • 어떻게 Tag를 달아야 추적이 쉬울까?

      • General Tag Policy

        • role : 어떤 클러스터

        • dbxrole : 클러스터 사용하는 팀

        • stack : prod/dev

        • infrarole : 클러스터 생성 및 관리하는 팀

        • product : 회사 제품명

      • Job Tag Policy

        • source : job에서 활용되는 데이터 source

        • sink : job에서 최종적으로 저장하는 곳

        • transform : 어떤 작업이 진행되는지 설명

  • Unity Catalog

    • 구조만으로 데이터 사용처를 빠르게 이해할 수 있어야 함

    • 메달리안 방식을 사용

    • raw, bronze, silver, gold

      • bronze에서 speed, app 레이어도 존재

    • raw : 데이터 소스에서 싱크되는 영역. ELT을 위한 raw. s3, 카프카에 있는 데이터, 빅쿼리

      • 카프카의 데베지움이면 before, after가 그대로 저장

    • bronze : raw에 있는 데이터를 가공.

      • 카프카의 데베지움 데이터 기반으로 merge => Table과 동일하게 구성

    • silver : bronze에 있는 데이터를 도메인 단위로 테이블 생성.

      • speed : 도메인 단위로 정의하기 애매하지만 빠르게 집계하고 싶을 때 사용. 앞으로 사용하게 되면 정리해서 실버로 정리. 임시적인 영역

      • app : 데이터 분석이 아닌 어플리케이션에서 사용해야 하는 경우

    • gold : 실버를 집계해 join을 줄이고 비정규화 => 보고/대시보드 데이터 저장

• 데이터 민주화를 위한 자동화

  • 사내의 모든 데이터를 데이터브릭스로 저장할 수 있어야 하고

  • 적재한 데이터를 누구나 활용할 수 있어야 함

• 이벤트 드리븐 : 카프카에 집중

  • 모든 사내 데이터가 카프카로 스트리밍 되도록 설정

  • DB 데이터는 cdc를 사용하고, Object Storage는 vector 사용

  • Kafka to Databricks

    • 4가지 조건

    • 준실시간으로 카프카 데이터를 데이터브릭스로 싱크

    • 자동으로 데이터브릭스 테이블 및 스키마를 생성, 업데이트

    • highly scalable

    • easy to automate

    • => 카프카 커넥터 사용

    • S3 Sink connector + databricks auto loader 조합

  • S3 Sink connector : Hourly partitioner

https://vimeo.com/946845877