2.1 데이터 엔지니어링 수명 주기

1. 데이터 생성

원천시스템 (source system)

데이터 엔지니어링 수명 주기에서 사용되는 데이터 원본이다.
예시) IoT 장치, 메시지 대기열, 트랜잭션 데이터베이스 등

원천 시스템의 평가: 주요 고려사항

• 데이터 원천데이터의 본질적인 특징 (애플리케이션? IoT 장치의 스웜?)
• 원천 데이터의 유지 기간
• 데이터의 생성 속도
• 출력 데이터의 일관성
• 에러 발생 / 중복포함 / 동시 출발, 늦게 도착 / 스키마 / 얼마나 자주 가져와야하는지
• 상태가 있는 시스템의 경우 변경 관리
• 다운스트림 사용 위한 데이터 제공업체 누구? 데이터 원천에서 데이터 조회하면 성능 영향 있는지?
• 업스트림, 원천 의존관계
• 늦거나 누락된 데이터 품질 검사

스키마

• 데이터의 계층 구성 정의

1. 스키마리스 : 스키마 없다는 거 아님. 도큐먼트 EB에 데이터 기록될 때
2. 고정스키마 : 관계형 데이터베이스 스토리지

어느쪽이 됐든 스키마는 변한다! 스키마의 진화는 애자일 접근 방식에서 장려됨!

데이터 엔지니어의 핵심은 원천 시스템 스키마에서 → 원시데이터 입력받고 → 유용한 출력으로 변환!!!!

스키마 진화하고 있어서 어려워지고 있지만 중요함…

2. 데이터 저장

데이터 저장은 복잡한 단계의 하나이기도 하다.

1. 클라우드의 데이터 아키텍처는 여러 스토리지 솔루션 활용함
2. 복잡한 변환 쿼리 지원하는 데이터 스토리지 솔루션은 순수하게 스토리지로서만 작동하는 경우가 거의 없고 많은 솔루션이 복잡한 변환쿼리를 지원한다. (Amazon S3 Select등)
3. 저장은 데이터 엔지니어링 수명 주기의 한 단계이지만 수집, 변환, 서비스 제공과 같은 다른 단계에도 자주 관여한다.

• 저장은 여러 파이프라인 위치에서 발생
• 전체 수명 주기에 걸쳐서 실행되고 영향을 미친다.

ex) 아파치 카프카, 펄사

스토리지 시스템 평가: 주요 엔지니어링 고려 사항

• 아키텍처의 요구 속도와 잘 맞는지
• 병목 현상
• 부자연스러운 행동
• 높은 random access 비율
• 향후 예상되는 확장을 처리하는지
• 용량 제한
• 메타데이터
• SLA에 따라 데이터 취득?
• 순수 스토리지? 쿼리 패턴 요구?
• 스키마 구애? 유연 스키마(카산드라)? 강제 적용 스키마?
• 데이터 거버넌스를 위해 품질, 계보 어떻게 추적?
• 법령 준수?

데이터 접근 빈도 이해

1. 핫데이터

   가장 자주 엑세스 되는 데이터

2. 미온적 데이터

   가끔 (ex. 매주/매월) 액세스되는 데이터

3. 콜드데이터

   거의 쿼리되지 않으며 아카이브 시스템에 저장하는 데 적합

   • 벤더가 월 스토리지 비용은 매우 저렴 but 데이터 검색 비용은 높은 특화된 스토리지 계층을 제공

스토리지 시스템 선택

범용 스토리지 권장 사항 없음. 모든 스토리지는 장단점, 트레이드 오프가 있다!

따라서 질문 목록들을 잘 따져서 고려하는게 중

3. 데이터 수집

수집 단계에서의 주요 고려사항

• 수집 중 데이터 사용 사례? 여러 버전 생성 대신 데이터 재사용 가능한가?
• 데이터 안정적으로 생성하고 수집? 필요시 해당 데이터 사용할 수 있는가?
• 수집 후 데이터 목적지는?
• 데이터에 얼마나 자주 접근?
• 데이터는 보통 어느 정도의 용량으로 도착?
• 데이터 형식은?
• 다운스트림 스토리지 및 변환 시스템에서 형식 처리 가능?
• 원천 데이터 다운스트림에서 즉시 사용할 수 있는 양호한 상태? 얼마나 오래 사용? 사용 할 수 없는 이유는?
• 데이터가 스트리밍 소스에서 전송된 경우 목적지에 도달하기 전에 데이터 변환해야 하는가? 데이터가 스트림 자체 내에서 변환되는 형태의 변환이 적절한가?

배치 vs 스트리밍

스트리밍: 우리가 다루는 대부분의 데이터는 본질적으로 스트리밍! 원천에서 지속해서 생성되고 갱신됨

• 다운스트림 시스템에 데이터를 실시간으로 연속해 제공할 수 있음

배치 수집:스트림을 큰 청크로! 처리하는 전문적이고 편리한 방법!!!

• 미리 설정된 시간 간격에 따라 or 데이터가 미리 설정된 크기 임곗값에 도달하면 수집됨
• 수집이 한 방향으로 이뤄짐!
• 배치로 분할되면 다운스트림 소비자의 지연 시간이 본질적으로 제한됨

동향

이벤트 스트리밍과 처리 플랫폼이 보편화됨에 따라, 데이터 스트림의 지속적 처리에 대한 접근성과 인기가 높아지고 있음.

배치 스트림 주요 고려 사항

스트리밍 굉장히 매력적이지만, 배치 수집보다 적절한지 자문해보아야함.

• 데이터를 실시간으로 수집하면 다운스트림 스토리지 시스팀이 데이터 흐름 속도를 처리할 수 있는가?
• 밀리초 단위의 실시간 데이터? or 매분마다 데이터 축적하고 수집하는 마이크로 배치 접근이 효과적?
• 스트리밍 수집 사례는? 어떤 이점? 데이터 실시간 → 개선된 데이터에 어떤 조치 취하지?
• 시간, 비용, 유지보수, 다운타임, 기회비용
• 인프라 장애 발생 시 스트리밍 파이프라인과 시스템이 안정적이고 다중화되어 있는지
• 사용 사례에 가장 적합한 도구는? 관리형 서비스(Kinesis, GCD) ? or 인스턴스 구축?(Kafka, spark 등) 후자라면 관리는 누가? 비용? 트레이드오프?
• ML 모델 배포 시 온라인 예측 및 지속적 훈련으로 얻는 이점은?
• 실제 운영 인스턴스에서 데이터를 가져오는가? 수집 프로세스의 영향도는?

푸시 vs 풀

푸시 : 데이터베이스, 객체 저장소, 파일 시스템과 관계 없이 원천시스템은 타깃에 데이터를 씀

ex) CDC(change data capture)

데이터베이스에서 행이 변경될 때마다 메시지 트리거 ! 메시지는 큐에 푸시되고 수집 시스템이 해당 메시지를 가져감

풀 : 원천시스템에서 데이터를 검색함.

ex) ETL 프로세스 (추출, 변환, 적재)

• 추출(extract) 부분은 풀 수집 모델을 다룸! 정해진 일정에 따라 현재 소스 테이블의 스냅숏을 쿼리
  

4. 데이터 변환

데이터 수집했으면 다운스트림 사용 사례에 유용한 형태로 변경해야겠지?

적절히 변환을 안해주면.. ML에 유용하지가 않음!

변환 단계의 주요 고려사항

• 변환에 드는 비용과 투자수익률(ROI)는 얼마? 관련 비지니스 가치는?
• 변환은 단순하고 독립적인지!
• 비지니스 규칙은?

• 변환은 수명주기의 다른단계와 얽히는 경우가 많음
• 수집중에 변환되거나 원천시스템에서 변환됨. ex. 수집 프로세스에 전송하기 전에 이벤트 타임스탬프를 레코드에 추가
  
• 데이터 정제와 같은 변환 작업은 최종 소비자에게 가치를 더해줌
• 비지니스 로직은 모델링에서 데이터 변환의 주요 원인이 됨.
  • ex 판매의 의미 = 12개의 사진 프레임을 30달러, 총 360달러에 구입했다는 의미
  • 회계 규칙의 논리를 추가해야함.

5. 데이터 서빙

이제 데이터로부터 가치를 창출해보자!

가치 : 데이터가 실용적으로 사용될 때 가치가 있다! 소비되지 않거나 쿼리되지 않는 데이터는 걍 단순 비활성 상태일 뿐…. 데이터 허영은 기업의 주요 리스크임.

1. 분석

   

   1. 운영분석

      운영의 상세 사항에 중점두고 보고서 사용자가 즉시 수행할 수 있는 작업을 촉진

      ex. 재고 물품에 대한 실시간 뷰, 앱 상태에 대한 실시간 대시보드

      현재에 중점 두기 때문에 BI처럼 과거 동향과는 관련 없음

   2. BI & 애드혹

      기업의 과거와 현재 상태 설명 위해 데이터 수집! 비지니스 로직과 정의에 대한 레포 유지함.

      기업의 데이터 성숙도 높아짐에 따라 애드혹 데이터 분석에서 셀프 서비스 분석으로 전환해 IT 부서의 개입 없이도 비지니스 사용자가 데이터 접근 가능해질 수 있음.

   3. 임베디드 분석 (고객 대면 분석)

      기업은 수천 명 이상의 고객에게 별도의 분석 및 데이터를 제공할 수 잇고, 고객은 이때 다른 고객이 아닌 자기자신의 데이터만 확인할 수 있어야함!!!!

      데이터 유출, 취약성과 관련해 피해 범위 최소화해야함

      모든 장소에서 테넌트 or 데이터 수준의 보안을 적용한다.

      멀티 테넌시

      ✅ 멀티테넌시(Multi-tenancy)는 소프트웨어 아키텍처에서 여러 개의 사용자가 하나의 소프트웨어 애플리케이션 또는 시스템을 공유하지만, 각 사용자는 자신의 데이터와 구성을 가지고 있는 방식을 의미합니다. 이 개념은 특히 클라우드 컴퓨팅 환경과 SaaS(Software as a Service) 모델에서 중요합니다.
      라고 지피티가 알려줌!
      

2. 머신러닝

   데이터 엔지니어가 ML에 능숙하면 좋다..!

   ML서빙 단계에 고려해야할 사항이 있다.

   • 신뢰할 수 있는 특성 엔지니어링을 수행하기에 충분한 품질의 데이터? 품질 요구사항 및 평가는 팀이 개발
   • 데이터 검색 가능? 가치 데이터 쉽게 찾을 수 있음?
   • 조직적 경계는 어떻게 되지?
   • 데이터셋이 편향되지 않았는지, 실제 상황 반영하는지

3. 역ETL

   수명주기의 출력 측에서 처리한 데이터를 다시 가져와서 원천 시스템에 공급하는 것.

   ex. 마케팅 분석가는 데이터 이용해서 입찰가 계산한 다음에 다시 구글 애즈에 업로드할 수 있음

   역ETL은 아직 초기 단계지만 앞으로 더 발전할 것임. 점점 중요해지고 있음.

2.2 수명주기의 드러나지 않는 요소들

1. 보안

보안을 최우선으로 생각해야하며, 위험을 이해해야함!!!!

• 최소 권한 원칙 실행해야한다. (필수적인 데이터와 자원에만 접근할 수 있도록)
• 접근 타이밍과 관련이 있다. 해당 작업을 수행하는데 필요한 기간동안만 허용한다.

2. 데이터 관리

1. 데이터 거버넌스

   • 데이터 품질, 무결성, 보안 및 사용성 보장하기 위한 관리 기능
   • 핵심 범주는 발견가능성(쉽게 찾아 쓸 수 있어야), 보안, 책임!
     • 하위범주 : 메타데이터, 개인정보보호 등

   1. 발견가능성 : 데이터 중심 기업에선 데이터를 사용할 수 있고 검색할 수 있어야함. 안정적으로 접근할 수 있어야하고 데이터 출처와 다른 데이터와의 관계, 데이터 의미를 알아야한다.

      1. 메타데이터 : 데이터에 관한 데이터. 데이터 검색하고 제어하는 데 필요한 데이터
         1. 비지니스 메타데이터 : ex. ‘고객’에 대한 정의
         2. 기술 메타데이터 : 파이프라인 메타데이터, 데이터 계보, 스키마
         3. 데이터 계보 메타데이터: 원본과 변경하상, 종속성을 시간에 따라 추적
         4. 스키마 메타데이터: DB, 데이터 웨어하우스, 데이터 레이크 or 파일 시스템 같은 시스템에 저장된 데이터 구조 설명
         5. 운영 메타데이터: 다양한 시스템의 운영 결과를 설명. 작업 id, 앱 런타임 로그, 프로세스 사용되는 데이터 및 오류 로그에 대한 통계 포함
         6. 참조 메타데이터: 다른 데이터를 분류하는 데 필요한 데이터로, 조회 데이터라고도 한다. 내부 코드, 지리적 코드, 측정 단위 및 내부 달력 표준 등이 표준 사례.

   2. 데이터 책임

      데이터의 일부를 관리할 개인을 지정하는 것을 의미함. 문제가 있는 데이터에 대해 책임지는 사람이 없으면 품질 관리 어렵기 때문이당.

      데이터 책임의 수준 : 다양할 수 있음. 테이블, 로그 스트림 혹은 여러 테이블에 걸쳐 발생하는 단일 필드 엔티티처럼 세분화될 수도

   3. 데이터 품질

      데이터를 원하는 상태로 최적화하는 것으로 ‘기대하는 것과 비교해 어떤 결과를 얻을 수 있을까? 라는 질문을 중심으로 한다.

      1. 정확도: 실제로 정확한가? 중복된 값 있는가? 수치가 정확한가?
      2. 완전성: 기록은 완전한가? 모든 필수 필드에 유횻값이 포함되는가?
      3. 적시성: 기록 시기 적절하게 이용할 수 있는가?

      ✅ 마스터 데이터 : 직원, 고객, 제품 및 위치와 같은 비지니스 엔티티에 대한 데이터임. 마스트 데이터도 잘 관리해야되고… MDM(마스터 데이터 관리)는 골든 레코드로 알려진 일관된 엔티티 정의 구축하는 관행임.

2. 데이터 모델링 및 설계

   • 데이터 분석과 과학을 통해 비지니스 통찰 얻어야한당! 데이터를 사용 가능한 형태로 변환하는 프로세스를 데이터 모델링 및 설계라고 한다.
   • 데이터 모델링은 API 호출, MySQL 테이블 스키마에 대한 JSON 응답 설계도 다 포괄하는 개념임.
   • 원천 데이터 다양해지면서 모델링 어려워짐.

3. 데이터 계보

   데이터가 수명 주기 거치면서 어떤 시스템이 데이터에 영향 줬는지, 데이터가 전달 변환될 때 어떤 데이터가 구성됐는지를 데이터 계보를 통해 알 수 있음

   • 데이터 계보 : 데이터 처리하는 시스템과 의존하는 업스트림 데이터 모두 축적해서 수명 주기 전체에 걸쳐 데이터의 감사 추적을 기록함
   • DDOD (data observability driven development) : 계보를 통해 데이터 관찰. 개발, 테스트, 최종 생산 과정에 적용돼 기대에 부응하는 품질과 적합성 제공함.

4. 저장 및 운영

5. 데이터 통합 및 상호 운용성

   여러 도구와 프로세스 전반에 걸쳐 데이터를 통합하는 프로세스임.

   • 맞춤형 DB 연결이 아닌 범용 API를 통해 이뤄지는 경우가 늘고 있음
     • ex. 데이터 파이프라인은 세일즈포스의 API에서 데이터 가져와 S3에 저장하고 Snowflake의 API를 호출해 테이블 적재 → API 다시 호출 쿼리 실행 → S3로 결과 이송 → 스파크가 데이터 소비
   • 데이터 시스템과의 상호 작용의 복잡성은 감소했지만, 시스템 수와 파이프라인의 복잡성은 극적으로 증가했다! 따라서 오케스트레이션 필요

6. 데이터 수명 주기 관리

   데이터 레이크 등장으로 데이터 보관 및 파기를 무시하게 됨. 스토리지 무한대로 추가할 수 있는데 왜 굳이 데이터 폐기해야할까?

   • 클라우드에 점점 더 많은 데이터가 저장되고 있음
   • GPR과 CCPA같은 개인정보보호 및 데이터 보존법에 따라 ‘잊혀질 권리’ 존중 위해 적극적으로 파기 해야함.
   • WORM(write once read many)가 기본 스토리지 패턴인 데이터 레이크에서 데이터 파기가 어려워졌음. 메타데이터, 데이터 계보 등으로 마지막 단계 간소화해야

7. 고급 분석 및 ML을 위한 데이터 시스템

8. 윤리 및 개인정보 보호

   윤리와 개인정보보호는 데이터 엔지니어링 수명 주기에 영향 미침.

   ex. 개인식별정보 및 중요한 ㅈ어보 마스킹 처리

   규제요건과 컴플라이언스에 대한 처벌 점점 더 엄격해지고 있음. 잘 이해해야

3. 데이터옵스

1. 자동화
- 변경관리(환경, 코드 및 데이터 버전 제어), CICD, 코드로 구성된 데브옵스와 유사한 프레임워크 및 워크플로 가짐
- Airflow Dagster와 같은 오케스트레이션 프레임워크
- 워크로드를 줄이고 비지니스에 제공하는 가치 높일 수 있는 자동화를 지속해서 구현하려고 해야함.
2. 모니터링 및 관찰 가능성
- 중요한 결정 내리고 한참 뒤에 오류 발견하면 안되니까 데이터와 생성 시스템을 감시하고 관찰해야한다.
3. 사고 대응
- 실수는 필연적으로 발생한다.
- 사고 대응은 기술과 도구에만 국한하지 않는다.
- AWS의 최고 기술 책임자(CTO)인 베르너르 포헐스 - ‘모든 것은 항상 망가진다’ (ㅜㅜ)
- 재해에 대비하고 가능한 신속 효율적으로 대응할 준비 해야함
- 보고 하기 전에 미리 문제 발견해야됨
- 선제 대처와 사후 대응 다 중요

4. 데이터 아키텍처

1. 비지니스 요구 사항 이해하고 새로운 요구사항 수집
2. 1의 요건 변환해 비용과 운영 간소화를 균형 있게 유지하며 데이터 캡처하고 제공하는 새로운 방법 설계
3. 기술 및 도구의 트레이드오프 파악

5. 오케스트레이션

오케스트레이션: 많은 작업이 예약된 순서대로 최대한 빠르고 효율적으로 실행되도록 조정하는 프로세스(Airflow 등)

• DAG(directed acyclic graph)의 형태로 작업 종속성에 따라 메타데이터를 구축
• DAG는 한번만 실행되거나 매주, 매일, 매시간, 5분 등 일정한 간격으로 실행되도록 스케줄링 가능
• 감지 및 모니터링 가능
• 특정 조건 벗어나거나 데이터가 제시간에 도착 안하면 경고 보내기도
• 작업 기록 기능, 시각화 및 경고 기능 구축
• 오케스트레이션은 엄밀히 말해 ‘배치 개념’임
  • 대안은 스트리밍 DAG. BUT 여전히 유지 구축 보수 어려움 그치만 펄사(Pulsar)와 같은 차세대 스트리밍 플랫폼은 운영 부담 줄이는 거 목표로하고 있음!!!

6. 소프트웨어 엔지니어링

2000-2010: 저수준 프레임워크 C, C++, Java에서 맵리듀스 잡 작성

2010 중반: 추상화한 프레임워크 사용 시작

소프트 엔지니어링의 공통 영역

1. 코어 데이터 처리 코드 : 더 추상적/관리쉬워짐. 그치만 처리 코드 여전히 작성해야됨.
   • 언어: Spark, SQL, Beam 등의 프레임워크와 언어에 능숙하고 생산성 뛰어나야 함
   • 코드 테스트 방법론: 단위, 회귀, 통합, 앤드투엔드, 스모크 등의 적절한 코드 테스트 방법론을 이해하는 것이 중요함
2. 오픈 소스 프레임워크 개발
   • 빅데이터 시대엔 하둡 생태계에서 프레임워크 폭발적 증가.
   • 새로운 내부 도구를 엔지니어링 하기 전에 사용할 수 있는 도구의 환경 조사하는 게 좋음! (TCO)총 소유 비용과 기회비용에 주목하자..
   • 해결해야 할 문제 해결하는 오픈 소스는 이미 있을 것이당!!!
3. 스트리밍
   • 다양한 윈도잉 방법론을 적용할 코드를 작성해야함
   • 윈도잉을 사용하면 실시간 시스템에서 추적 통계와 같은 중요한 측정 지표 계산할 수 있음!
   • 개별 이벤트 처리하는 다양한 함수 플랫폼 (OpenFaaS, AWS람다, GCF) 또는 스트림을 분석해 보고 및 실시간 작업을 지원하는 전용 스트림 프로세서(Spark, Beam, Pulsar) 등 다양한 프레임워크 중 선택할 수 있다.
4. 코드형 인프라
   • 인프라 관리 부담은 기업들이 데이터브릭스나 아마존(EMR)같은 관리형 빅데이터 시스템과 클라우드 데이터 웨어하우스로 이전함에 따라 감소하고 있다.
   • 클라우드 환경에서 인프라 관리하는 경우, IaC 프레임워크로 대응하는 사례 늘고 있음.
   • 헬름 등의 도구 써서 컨테이너와 쿠버네티스 사용하는 IaC의 개념도 있다!
   • 버전 제어와 배포 반복성 실현
5. 코드형 파이프라인
   • 오케스트레이션 시스템의 핵심 개념
   • 일반적으로 python사용해서 데이터 작업과 데이터 간의 족속성 선언
6. 범용 문제 해결
   • 파이브트랜, 에어바이트, 마틸리언과 같은 프레임워크 사용할 때 기존 커넥터가 없는 데이터 원천에 직면. 사용자 정의 코드 작성해야됨
   • API 이해, 데이터 풀링 및 변환 수행, 예외 처리하는 등 소프트웨어 엔지니어링에 익숙해야함.