[견고한 데이터 엔지니어링] 02장. 데이터 엔지니어링 수명 주기

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

• 데이터 엔지니어링 수명 주기
  • 수명 주기 단계들과 드러나지 않는 요소로 나뉨

 

[1] 데이터 수명주기 vs 데이터 엔지니어링 수명 주기

• 데이터 엔지니어링 수명 주기는 데이터 수명 주기의 하위집합

• 데이터 수명 주기: 데이터 전체의 수명을 포괄
• 데이터 엔지니어링 수명 주기: 데이터 엔지니어가 제어하는 단계에 초점

 

[2] 데이터 생성

• 원천 시스템(source system)은 데이터 엔지니어링 수명 주기에 사용하는 데이터 원본
  • 데이터 소비에 사용되지만 시스템 자체를 소유하거나 제어하진 않음
• DE는 원천 시스템에 대해 실무적 이해가 필요
  • 원천으로부터 데이터 생성하는 방법을 이해
  • 상호 작용하는 원천 시스템의 한계를 이해
  • 데이터 파이프라인 변경 사항에 대해 원천 시스템 소유자와 소통 라인 유지 필요
  • 원천 시스템의 방대한 배열을 이해하고 작업해야함
• 데이터 엔지니어가 고려할 원천 시스템 평가 질문 스타터킷

---

•  데이터 원천의 본질적인 특징은 무엇인가? 데이터 원천은 애플리케이션인가? loT 장치의 스웜인가?

• 원천 시스템에서 데이터는 어떻게 유지돠는가? 데이터는 장기간 보존돠는가? 아니면 일시적이고 빠르게 삭제되는가?

• 데이터는 어느 정도의 속도로 생성되는가? 초당 몇 개의 이벤트가 발생할까? 시간당 몇 기가바이트 인가?

• 데이터 엔지니어는 출력 데이터에서 어느 정도의 일관성을 기대할 수 있는가? 출력 데이터에 대해 데이터 품질 검사를 실행할 때, 예상치 못한 출력값（예를 들면 n니II 값）이나 잘못된 데이터 포맷과 같은 데이터 불일치 사례는 얼마나 자주 발생할까?

• 에러는 얼마나 자주 발생하는가?

• 데이터에 중복이 포함되지는 않는가?

• 일부 데이터값이 동시에 생성되는 다른 메시지보다 훨씬 늦게 도착할수 있는가?

• 수집된 데이터의 스키마는 무엇인가? 데이터 엔지니어가 데이터를 완전히 파악하려면 여러 테이블 또는 여러 시스템에 걸쳐 조인을 수행해야 하는가?

• 스키마가 변경되면（예를 들어 새로운 열이 추가되었을 때） 어떻게 대처하고 다운스트림 이해관계자에게 전달할 수 있는가? • 원천 시스템에서 데이터를 얼마나 자주 가져와야 하는가?

• （고객 계정 정보를 추적하는 데이터베이스 등） 상태가 있는 시스템stateful system의 경우, 데이터는 정기적인 스냅숏으로 제공되는가? 아니면 변경 데이터 캡처change data capture（CDC）로부터의 갱신 이벤트로 제공되는가? 변경은 어떻게 수행되며, 원천 데이터베이스에서 이러한 변경을 어떻게 추적하는가?

• 다운스트림 사용을 위한 데이터를 전송하는 데이터 제공업체는 누구（무엇）인가?

• 데이터 원천에서의 데이터 조회가 성능에 영향을 미치는가?

• 원천 시스템에 업스트림 데이터 의존 관계가 있는가? 이러한 업스트림 시스템의 특징은 무엇인가?

• 늦거나 누락된 데이터 확인용으로 데이터 품질 검사가 실시되고 있는가?

---

• 스키마(schema): 데이터 계층 구성을 정의하며, 원천 시스템이 제공하는 데이터 스키마는 스키마리스 또는 고정스키마 방식으로 처리된다.
  • 스키마리스(schemaless) 방식: 도큐먼트 데이터베이스에 데이터가 기록될 때 스키마를 정의
  • 고정 스키마(fixed schema) 방식: RDB에서 스토리지 기반으로 구축된 전통적 모델로 애플리케이션 쓰기는 고정 스키마를 준수
  • 스키마는 시간이 지나며 변화함
  • DE는 원천 시스템 스키마에서 원시 데이터를 입력받고 분석에 유용한 출력으로 변환하는 것이 업무

 

[3] 데이터 저장

• 데이터 저장이 수명 주기에서 가장 복잡한 단계인 이유

1. 클라우드 데이터 아키텍처는 여러 스토리지 솔루션을 활용하는 경우가 많음
2. 많은 스토리지 솔루션이 복잡한 쿼리를 지원하며, 스토리지 자체로만 작동하는 경우가 거의 없음
3. 데이터 저장이 수명 주기 한 부분이지만 수집, 변환 및 서비스 제공 등 다른 단계에도 영향을 미침
   • 저장은 데이터 파이프라인 여러 위치에서 발생 → 전체 데이터 엔지니어링 수명 주기에서 발생됨

 

• 데이터 엔지니어가 스토리지 시스템 선택 시 확인할 사항

---

• 이 스토리지 설루션은 아키텍처에서 요구하는 쓰기 및 읽기 속도와 잘 맞는가?

• 스토리지가 다운스트림 프로세스의 병목 현상을 초래하자는 않는가? • 이 스토리지 기술이 작동하는 방식을 인지하고 있는가? 스토리지 시스템을 최적으로 활용하는가? 아니면 부자연스러운 행동을 하는가? 예를 들어 객체 스토리지 시스템에 높은 비율의 임의 접근random access 갱신을 적용하고 있자는 않은가?（이것은 성능 오버헤드가 큰 안티패턴anti-pattern이다）.

• 이 스토리지 시스템은 향후 예상되는 확장을 처리할 수 있는가? 사용 가능한 총 스토리지, 읽기 작업 속도, 쓰기 볼륨 등 스토리지 시스템의 모든 용량 제한을 고려해야 한다.

• 다운스트림 사용자와 프로세스가 필요한 서비스 수준 협약service-lewl agreement （SLA）에 따라 데이터를 취득할 수 있는가? • 스키마 진화, 데이터 흐름, 데이터 계보 등에 대한 메타데이터metadata를 캡처하고 있는가? 메타데이터는 데이터 활용성에 큰 영향을 미친다. 메타데이터는 미래에 대한 투자로. 검색 가능성과 제도적 지식을 획기적으로 향상시켜 미래의 프로젝트 및 아키텍처 변경을 간소화한다.

• 순수 스토리지 설루션（객체 스토리지）인가? 아니면 복잡한 쿼리 패턴（예: 클라우드 데이터 웨어하우스）을지원하는가?

•  스토리지 시스템이 스키마에 구애받지는 않는가（객체 스토리지）? 유연한 스키마（카산드라）인가? 강제 적용된 스키마（클라우드 데이터 웨어하우스）인가?

• 데이터 거버넌스data governance를 위해 마스터 데이터, 골든 레코드 데이터 품질 및 데이터 계보를 어떻게 추적하고 있는가?（더 자세한 내용은 2.2.2절에서 살펴볼 것이다）.

• 법령 준수 및 데이터 주권에 어떻게 대처하고 있는가? 예를 들어 특정 지리적 위치에는 데이터를 저장 하고 다른 위치에는 저장하지 않을 수 있는가?

---

 

• 데이터 접근 빈도 이해
  • 데이터 온도: 접근 빈도에 따라 많이 접근되면 뜨겁다, 적게 되면 차갑다로 표현
  • 핫 데이터(hot data): 가장 자주 액세스 되는 데이터
    • 하루에 여러번 검색
    • 빠른 검색용으로 저장
  • 미온적 데이터(lukewarm data): 가끔 액세스되는 데이터
    • 매주 or 매월
  • 콜드 데이터(cold data): 거의 쿼리안되며, 아카이브 시스템 저장에 적합
    • 규정 준수 or 타시스템 장애 대비용 데이터
• 스토리지 시스템 선택
  • Best solution은 없다 → 모든 스토리지는 장단점이 존재

 

[4] 데이터 수집

• 데이터 수집은 데이터 원천과 원천 시스템의 특징, 저장 방법을 이해한 뒤 수집을 해야함
• 원천 시스템의 한계
  • 직접 관리가 어려우며 응답이 끊기거나 품질이 변화될 수 있다.
  • 데이터 흐름이 중단되거나 저장, 처리 또는 서비스에 적합하지 않은 데이터가 제공될 수 있다.
  • 따라서 데이터 엔지니어링 수명 주기에서 가장 병목이 큰 단계다.

 

• 데이터 엔지니어가 수집 단계에서 고려해야 할 사항

---

• 수집 중인 데이터의 사용 사례는 무엇인가? 같은 데이터셋의 여러 버전을 생성하는 대신 이 데이터를 재사용할 수 있는가?

• 시스템이 이 데이터를 안정적으로 생성하고 수집하고 있는가? 필요할 때 해당 데이터를 사용할 수 있는가?

• 수집 후 데이터 목적지destinatton는 어디인가?

• 데이터에 얼마나 자주 접근해야 하는가?

• 데이터는 보통 어느 정도의 용량으로 도착하는가?

• 데이터 형식은 무엇인가? 다운스트림 스토리지 및 변환 시스템에서 이 형식을 처리할수 있는가?

• 원천 데이터는 다운스트림에서 즉시 사용할 수 있는 양호한 상태인가? 그렇다면 얼마나 오래 사용할 수있으며, 사용할 수 없게 되는 요인은 무엇인가?

• 데이터가 스트리밍 소스에서 전송된 경우, 목적지에 도달하기 전에 데이터를 변환해야 하는가? 데이터가 스트림 자체 내에서 변환되는 형태의 변환이 적절할까?

---

 

• 배치 vs 스트리밍
  • 스트리밍(streaming): 데이터의 본질적 특징으로 원천(source)에서 지속적으로 생성됨
    • 스트리밍 방식으로 수집하면 다른 애플리케이션이나 DB 또는 분석 시스템 등 다운스트림 시스템에 데이터를 실시간으로 전달 가능
    • 배치 수집에 비해 추가비용과 방법의 복잡성 등 고려해야 할 많은 트레이드 오프가 있다.
  • 수집(batch ingestion): 스트림을 큰 청크(chunk) 단위로 간편하게 처리
    • 미리 설정된 시간이나 데이터가 지정한 크기에 다다르면 수집
    • 분석 or 머신러닝(ML) 같은 다운스트림에서 보편적으로 데이터를 수집하는 방법
  • 아래 이유들 덕분에 데이터 스트림의 처리에 대한 인기가 높아지는 중
    • 시스템에서 스토리지와 컴퓨팅 자원이 분리
    • 이벤트 스트리밍과 처리 플랫폼이 보편화

 

• 스트리밍 수집이 배치 수집보다 적절한지 판단하는 질문
  • 배치 사용에 대한 트레이드 오프를 상쇄할만큼 비지니스 사용 사례가 있는지 파악할 필요

 

---

• 스트리밍 수집의 사용 사례로는 무엇이 있을까? 스트리밍을 구현하면 구체적= 어떤 이점을 얻을 수있을까? 데이터를 실시간으로 가져올 수 있다면, 배치 방식에 비해 개선될 수 있는 데이터에 대해 어떤 조치를 취할 수 있을까?

• 스트리밍 우선 접근 방식은 단순 배치 방식보다 시간, 비용, 유지 보수, 다운타임 및 기회비용 측면에서더 많은 비용을 소비할까?

• 인프라에 장애가 발생했을 때 스트리밍 파이프라인과 시스템이 안정적이고 다중화되어 있는가?

• 사용 사례에 가장 적합한 도구는 무엇인가? 관리형 서비스(아마존 키네시스#=n Kines.s, 구글 클라우드 Pub/Sdb, 구글 클라우드 데이터플로 =* Cloud Datatow)를 사용해야 하는가? 아니면 카프카, 플링크스 파크, 펄사 등의 인스턴스를 구축해야 할까? 후자를 선택핸다면 누가 관리의 역할을 맡을 것인가? 비용과 트레이드오프는 무엇일까?

• ML 모델을 배포했을 때 온라인 예측 및 지속적인 훈련으로 얻을 수 있는 이점은 무엇일까?

• 실제 운영 인스턴스에서 데이터를 가져오는가? 그렇다면 이 원천 시스템에 대한 수집 프로세스의 영향 도는 얼마나 될까?

---

 

• 푸시 vs 풀
  • 푸시(push) 모델: 원천 시스템은 타깃에 데이터를 씀
  • 풀(pull) 모델: 원천 시스템에서 데이터를 검색함
  • 데이터는 파이프라인 여러 단계를 거치면서 푸시 또는 풀링됨
  • ex 1> 추출-변환-적재(ETL, Extract-Transform-Load) 프로세스
  • ex 2> 연속적인 CDC

 

[5] 데이터 변환

• 변환(transform): 데이터를 원형태에서 다운스트림에 유용한 형태로 변환하는 단계
  • 다운스트림 사용자 데이터 소비를 위해 데이터가 가치 있어지는 단계
  • 적절히 변환되지 않으면 데이터는 비활성 상태로 유지 → 보고서나 ML에 유용하지 않은 형식

 

• 변환 시 고려할 사항

---

• 변환에 드는 비용과 투자수익률(ROI)은 얼마인가? 관련된 비즈니스 가치는 무엇인가?

• 변환은 가능한 한 단순하고 독립적인가?

• 변환이 지원하는 비즈니스 규칙은 무엇인가?

---

• 변환 시기
  • 데이터는 배치 또는 스트리밍 중에 변환이 일어남
  • 아직 배치 변환이 대세이나 스트리밍 변환의 인기가 점점 높아지는 추세
  • 원천 시스템에서 바로 변환되거나 수집 중에 변환
• 비지니스 로직과 데이터 변환
  • 비지니스 로직으로 요구하는 사항은 변환의 주요 원인
  • 비지니스 프로세스를 명확하고 최신화된 상태로 파악하는게 중요
  • 변환 과정은 비지니스 로직을 구현하는 표준 접근 방식을 보장해야 함
• ML의 데이터 특성화(data featurization)
  • 특성화는 ML에 유용한 데이터 특성을 추출하고 강화하는 것
  • 데이터 변환 프로세스로 DS가 데이터 특성화 방법을 결정하면 파이프라인 변환 단계에서 DE가 프로세스를 자동화할 수 있다.

 

[6] 데이터 서빙

• 데이터 가치 창출
  • 데이터는 실용적 목적으로 사용될 때 가치(value)가 있다.
    • 소비나 쿼리되지 않는 데이터는 의미없는 비활성 상태
    • 데이터 허영(data vanity) 프로젝트는 기업의 주요 리스크
    • 빅데이터 시대에 많은 기업들은 유용하지 않은 정보들을 데이터 레이크에서 대규모로 수집
  • 데이터 프로젝트는 수명 주기 전반에서 다분히 의도적이어야 함
• 분석
  • 대부분 데이터 작업에서 핵심적 부분
  • 데이터 저장 및 변환 → 보고서 또는 대시보드 생성 → 데이터 임시 분석 수행 가능
  • 분석 유형은 아래 3가지로 나뉨

 

1. 비지니스 인텔리전스(BI)

• 과거와 현재 상태의 기업 경영을 설명하기 위해 데이터를 수집
  • 비지니스 로직을 사용해 원시 데이터 처리
  • 읽기 로직 (logic-on-read) 접근법이 보편화되면서 데이터는 깔끔하지만 원시적 형태로 저장 → 비지니스 로직 최소화
  • 비지니스 로직은 보고서와 대시보드가 비지니스 정의와 일치하도록 데이터 웨어하우스 쿼리에 사용
• 애드훅(ad-hoc) 데이터 분석 → 셀프서비스 분석으로의 전환
  • 기업의 데이터 성숙도가 높아짐에 따라 비지니스 사용자가 데이터 접근이 가능해짐
  • 조직 전체 인원이 직접 접근하고 원하는 방식의 분석과 통찰력을 파악할 수 있게 됨
  • 실제로는 데이터 품질 저하, 조직 사일로(silos) 현상, 데이터 기술 부족 등으로 많은 기업들에서는 실현이 어려움

 

2. 운영 분석

• 운영 사항에 중점을 두고 사용자가 즉시 필요한 정보에 도움을 주는 분석
  • 재고 물품에 대한 실시간 뷰
  • 웹사이트, 애플리케이션 상태에 대한 실시간 대시보드
• 데이터는 원천 시스템에서 직접 소비되거나 스트리밍 데이터 파이프라인에서 실시간 소비
• BI와 달리 현재에 중점을 두고 과거 동향과는 관계 X

 

3. 임베디드 분석

• 임베디드 분석은 보고서 요청 비율과 분석 시스템 부담을 키우고 접근 제어 역시 복잡해지고 중요하게 만듦
  • 기업은 수천명 이상의 고객에게 별도 데이터 및 분석을 제공
  • 각 고객은 자기 데이터만 확인 가능해야 함 → 고객간 데이터 유출은 절대 막아야 함
• 데이터 유출 및 보안 취약성 관련 피해 범위를 최소화 해야 함
• 데이터 유출 가능성이 있는 모든 곳에서 테넌트 또는 데이터 수준 보안이 필요
  • cf> 멀티테넌시(multitenancy): 공통 테이블에 많은 고객 데이터를 저장 → 내부 분석 및 ML을 위한 통합된 뷰 제공 가능
    • DE는 완벽한 보안과 분리를 보장할 수 있어야 함

 

4. 머신러닝

• 특성 저장소(feature store): DE와 ML 엔지니어링을 결합한 최신 개발 도구
  • DE는 팀에 대한 지운영 지식을 유지할 필요 (기본 ML기술, 데이터 처리 요구 사항, 회사의 모델 사용 사례 등)
• 특성 저장소 뿐만 아니라 DE는 다른 팀과 협력을 잘해야됨
• ML 관련 데이터 서빙 고려사항

 

---

• 신뢰할 수 있는 특성 엔지니어링을 수행하기에 충분한 품질의 데이터인가? 품질 요구 사항 및 평가는 데이터를 사용하는 팀과 긴밀히 협력해 개발된다.

• 데이터를 검색할 수 있는가? 데이터 과학자와 ML 엔지니어는 가치 있는 데이터를 쉽게 찾을 수 있는가?

• 데이터 엔지니어링과 ML 엔지니어링 간의 기술적 및 조직적 경계는 어디인가? 이러한 조직 차원의 질문은 아키텍처에 큰 영향을 미친다.

• 데이터셋이 실제 상황을 제대로 나타내고 있는가? 불공평하게 편향되어 있지는 않은

---

• ML 사업 이전에 기업들은 견고한 데이터 기반을 구축할 필요가 있음
  • DE와 ML 수명주기 전체에 거쳐 최적의 시스템 아키텍처를 구성할 필요
  • ML 전환 전 분석 역량 개발이 우선적으로 필요

 

5. 역 ETL

• 데이터 엔지니어 수명주기 출력에서 처리한 데이터를 다시 가져와 원천 시스템에 공급하는 구조
  • 오래동안 실질적으로 존재했으나 안티 패턴으로 간주됨
  • 실제유용하며 종종 필요한 과정임
  • cf> 분석, 평가 모델 등을 가져와 운영 시스템 또는 SaaS 플랫폼에 제공
• 기업이 SaaS와 외부 플랫폼에 더많이 의존하면서 점점 더 중요해짐

 

---

 

2. 수명 주기의 드러나지 않는 주요 요소

• 드러나지 않는 요소(undercurrent) → DE 수명주기의 모든 측면을 지원

 

[1] 보안

• 보안의 중요성
  • 데이터 엔지니어가 최우선으로 생각할 요소
    • DE는 데이터와 접근 보안을 모두 이해하고 최소 권한 원칙 (principle of least priviledge)을 실행해야 함 → 우발적 피해 방지
    • cf> 최소 권한 원칙: 사용자나 시스템이 의도된 기능을 수행하는데 필수적인 데이터와 자원에만 접근하게 하는 것
    • 보통 초짜 DE들은 모든 사용자에게 관리 권한을 부여 → 대재앙(!)
  • 데이터에 접근할 수 있는 개인들은 회사 기밀 데이터와 고객을 보호할 책임이 있음을 이해해야 함
    • DE의 역할이라기 보다 데이터를 사용하는 모두에게 하는 말!
• 보안의 방법
  • 정확하게 데이터 접근을 제공하되, 해당 작업 수행에 필요한 기간동안만 허용
  • 이동 중인 데이터와 저장된 데이터에 보안을 적용 필요
    • 암호화, 토큰화, 데이터 마스킹, 난독화, 접근 제어 등

 

[2] 데이터 관리

• 데이터 관리의 보편화
  • 데이터 도구 단순화로 DE가 관리할 복잡성이 감소
    • 데이터 관리에 대한 대기업의 데이터 모범사례가 모든 기업으로 보편화됨
    • 관리의 예> 데이터 거버넌스, 마스터 데이터 관리, 데이터 품질 관리, 메타 데이터 관리 등
• 데이터 관리의 측면
  • 발견 가능성(discoverability) 및 책임(accountability)을 포함한 데이터 거버넌스
  • 데이터모델링 및 설계
  • 데이터 계보
  • 저장 및 운영
  • 데이터 통합 및 상호운용성
  • 데이터 수명 주기 관리
  • 고급 분석 및 ML을 위한 데이터 시스템
  • 윤리 및 개인정보 보호

 

1. 데이터 거버넌스
   • 조직이 수집한 데이터 품질, 무결성, 보안 및 사용성 보장을 위한 데이터 관리 기능
   • 적절한 보안 제어로 데이터를 보호하며 조직 전체 데이터 가치 극대화를 위해 프로세스 및 기술을 활용할 수 있어야 함
   • 데이터 거버넌스가 무계획적으로 일어날 시 신뢰할 수 없는 데이터가 생성되거나 보안 침해가 발생할 수 있음
     • 분석 시 데이터 신뢰도가 떨어져 결과를 신뢰할 수 없음
   • 데이터 거버넌스가 잘 실행되면 데이터 문제 발생에도 신속히 처리가 가능
   • 핵심 범주: 발견 가능성, 보안, 책임
     • 발견 가능성: 데이터를 사용하고 검색할 수 있어야 함
     • 메타데이터(metadata): 데이터 검색 및 제어에 필요한 데이터 (데이터에 대한 설명도 개념)
       • 수명 주기 전체의 파이프 라인 설계와 데이터 관리를 위한 기반 데이터
       • 생성 방법
       1. 인간 생성 데이터
          • 수작업인 경우 오류가 발생하기 쉬움
          • 기술을 통해 오류 발생이 쉬운 작업을 상당히 제거가능
       2. 자동 생성 데이터
          • 인간으로 인한 관리를 완전히 배제해서는 안됨
       • 네가지 주요 범주
       1. 비지니스 메타데이터
       2. 기술 메타데이터
          • 파이프라인 메타데이터 (주로 오케스트레이션 시스템 내에서 생성)
          • 데이터 계보
          • 스키마
       3. 운영 메타데이터
       4. 참조 메타데이터
     • 데이터 책임(data accountability): 데이터 일부를 관리할 개인을 지정
       • 책임자는 다른 이해관계자의 거버넌스 활동을 조정
       • 책임자는 DE포함 데이터를 다루는 사람들과 협력
       • 책임자가 없으면 데이터 품질 관리가 어렵다.
       • DE가 데이터 책임자일 필요는 없다.
     • 데이터 품질(data quailty): 데이터를 원하는 상태로 최적화
       • 데이터는 비지니스 메타데이터 기대치에 부합해야 함
       • DE는 데이터 엔지니어링 수명 주기 전체에서 데이터 품질을 보장 (품질 테스트, 스키마 기대치, 데이터 완전성 및 정밀도에 대한 데이터 준수 보장)
       • DE는 품질에 대한 사용자 피드백을 수집하고 다운스트림 사용자가 품질 문제를 발견하기 전 미리 감지하는 기술 도구를 갖춰야 함
       • 품질의 3가지 주요 특징
       1. 정확도
       2. 완전성
       3. 적시성
     • 데이터 모델링 및 설계(data modeling and desing)
       • 데이터를 사용 가능한 형태로 변환하는 프로세스
       • DE는 모델링 모범 사례를 이해하고 데이터 원천과 사용 사례에 적절한 모델링을 적용할 수 있는 유연성을 갖춰야 함
       • 엄격한 정규화가 필요한가? → 이벤트 데이터에서는 잘작동하지 않을 수 있음
     • 데이터 계보(data lineage)
       • 데이터 처리 시스템과 데이터의 업스트림 데이터를 모두 추적해 수명 주기 전체에 걸친 데이터의 변모를 기록하는 것
       • 장점
       1. 데이터 처리 시스템이나 상위 데이터로부터의 오류 추적, 데이터에 대한 설명, 디버깅에 도움이 됨
       2. 데이터 수명 주기에 대한 감사 추적 제공
       3. 컴플라이언스(규정준수)
     • 데이터 통합과 상호 운용성
       • 여러 도구와 프로세스 전반에서 데이터를 통합하는 프로세스
       • 기존 맞춤형 DB연결에서 범용 API를 통해 이뤄지는 경우가 늘어나는 중 ← 데이터 시스템과 통신하는 간단한 파이썬 코드
       • 데이터 시스템과 상호작용으로의 복잡성 감소 → 맞춤형 스크립트 필요성 감소
       • 시스템 수와 파이프라인 복잡성은 증가 → 오케스트레이션의 필요성 증대
     • 데이터 수명 주기 관리
       • 아래 이유들로 여전히 필요함
       1. 클라우드에 많은 데이터가 적재 → 비용 증대
       2. 개인정보보호 및 데이터 보존법에 따른 ‘잊혀질 권리’ 존중 → 데이터 파기를 지속적으로 관리 필요
     • 윤리와 개인정보 보호
       • 언젠가 모니터링으로 인해 데이터 처리 실태가 밝혀질거기에 올바른 데이터 윤리와 개인정보 보호 문화를 장려해야 함
       • 데이터셋이 개인식별정보보호 및 기타 중요 정보 마스킹이 잘돼있는지 확인

 

[3] 데이터 옵스

• 데이터옵스(DataOps)
  • 데이터는 사용자 의사결정이나 모델 구축에 필요한 비지니스 로직, 측정 지표에 기반해 구축됨
  • 목표: 데이터의 릴리즈와 품질은 개선하는 것
  • DE는 소프트웨어 제품 구축의 기술 측면과 우수한 데이터를 만드는 비지니스 로직, 품질 및 측정을 모두 이해해야 함

 

• 데이터옵스의 핵심 기술 요소

1. 자동화
2. 모니터링 및 관찰 가능성
3. 사고 대응
4. 자동화

• 데이터옵스 프로세스 신뢰성과 일관성 보장
• 변경 관리(환경, 코드 및 데이터 버전 제어), 지속적 통합 및 배포(CI/CD), 코드 단위의 프레임워크와 워크플로
• 데이터 품질, 데이터/모델 드리프트, 메타데이터 무결성 확인 과정도 필요
  • 기술과 시스템 (데이터 파이프라인, 오케스트레이션 등)의 신뢰성을 모니터링, 유지함으로써 보장
• ex> 크론 잡(cron job)과 에어플로우

 

1. 관찰 가능성과 모니터링

• 데이터 신뢰성을 보장하기 위해 매우 중요함
  • 보고서의 부정확한 데이터, 오류 발생으로 인한 생성 지연 발생 가능
  • 신뢰를 잃는다면 다양한 팀에서의 사일로 발생, 일관성 없는 보고서, 불안정한 시스템이 유지될 것.
• 모든 단계에서 변경 사항을 식별할 수 있게 해 데이터 문제를 해결하거나 예방해야 함

 

2. 사고 대응

• 자동화 및 관찰 가능성 기능을 사용해 사고 근본 원인을 시속히 특정하고 빠르게 해결할 수 있어야 함
  • DE는 항상 재해에 대비하고 신속하고 효율적으로 대응할 준비
  • 기업이 문제 보고 전 문제를 미리 발견해야 함
  • 이해 관계자나 최종 사용자가 문제를 발견하면 발견한 문제를 제시할 수 있어야함

 

[4] 데이터 아키텍처

• 데이터 아키텍처는 조직의 장기적 데이터 요건과 전략을 지원하는 데이터 시스템 현재와 미래 상태를 반영
• DE는 적절한 데이터 아키텍처를 이해해야 함
  • 비지니스 요구사항 이해 및 새로운 사용 사례에 대한 요구사항 수집
  • 비용과 운영 간소화를 균형있게 유지하며 데이터를 가져오고 제공하는 방법을 설계
  • 데이터 엔지니어링 수명 주기 단계에 있어 설계 패턴, 기술 및 도구의 트레이드오프 악

 

[5] 오케스트레이션

• 오케스트레이션 개념
  • 각 작업들이 예약된 순서와 관계대로 최대한 빠르고 효율적으로 실행되도록 조정하는 프로세스
  • 일반적으로 유향 비순환 그래프 (DAG) 형태로 작업 종속성에 따라 실행
  • 사용자 개입 없이도 작업을 감지, 모니터링 하며 새로운 작업 배포 시 정해진 일정에 실행 가능
  • 순수한 실행 시간만 인식하는 스케줄러와는 차이가 있음

 

• 배치 vs 스트리밍
  • 오케스트레이션은 배치 개념
  • 스트리밍 DAG으로 스트리밍 작업을 처리하려는 시도가 일어나는중

 

[6] 소프트웨어 엔지니어링

• DE과정의 추상화에도 아직까지 DE에겐 아래 이유들로 소프트웨어 엔지니어링 기술이 필요하다.
• 코어 데이터 처리 코드
• 오픈 소스 프레임워크 개발
• 스트리밍
• 코드형 인프라
• 코드형 파이프라인
• 범용 문제 해결