견고한 데이터 엔지니어링 - 원천 시스템에서의 데이터 생성

아래 내용은 견고한 데이터 엔지니어링(조 라이스, 맷 하우슬리 지음)의 5장의 내용을 정리한 것이다.

5.1 데이터 원천: 데이터는 어떻게 생성될까?

여러가지 방법 중 두가지 주요한 방법을 소개한다.

• 아날로그 데이터: 실제 세계에서 생성되는 데이터로, 일시적으로 생성되는 경우가 많다.
• 디지털 데이터: 아날로그 데이터를 디지털 형식으로 변환 하거나, 디지털 시스템의 산물이다.

5.2 원천시스템: 주요 아이디어

원천시스템을 사용 할때 접하게 되는 주요 아이디어들을 설명한다.

5.2.1 파일과 비정형 데이터

파일은 바이트 시퀀스로서, 디스크에 저장된다. 파일은 보편적으로 데이터 교환에 사용되는 매개체이므로, 데이터 엔지니어들은 여러가지 파일 형식의 파일을 정형/비정형 데이터 소스로서 접하게 된다.

5.2.2 API

API(어플리케이션 프로그래밍 인터페이스)는 시스템 간에 데이터를 교환하는 표준 방식이다. API 수집 자동화를 위한 다양한 서비스가 등장했으나, 여전히 API 연결을 유지하는데는 상당한 에너지가 투입된다.

5.2.3 어플리케이션 데이터베이스(OLTP)

어플리케이션 데이터베이스는 어플리케이션의 상태를 저장하는 시스템이다. 자주 읽고 쓰이는 만큼 보통 짧은 지연시간과 높은 동시성을 지원한다. 방대한 양을 하나의 쿼리에서 처리해야 하는 대규모 분석에는 적합하지 않다.

ACID

ACID는 원자성, 일관성, 독립성, 내구성을 의미한다. 데이터 엔지니어는 ACID이 유무에 따른 데이터 베이스 작동방식을 이해하여 장애상황에 예방/대응해야 한다.

• 원자성: 하나의 단위로 커밋되는 여러 변경사항 집합인 원자성 트랜잭션의 변경사항들이 모두 성공하거나 모두 실패하여 변경하지 않도록 함
• 일관성: 데이터베이스를 읽을때 마지막으로 기록된 버전이 반환되는 것
• 독립성: 다수의 갱신작업이 실행될때 순차적으로 실행되는 것과 결과가 일치해야함
• 내구성: 외부의 장애요인(정전)에도 데이터가 손실되지 않아야 함

5.2.4 온라인 분석 처리 시스템 (OLAP)

OLAP는 대규모 분석 쿼리를 실행하도록 구축되어 있으며, 개별 레코드 조회 처리에는 비효율 적이다. OLAP의 온라인은 시스템이 들어오는 쿼리를 지속해 수신 대기한다는 뜻으로, 대화형 분석에 적합하는 것을 의미한다. OLAP를 원천시스템에서 언급하는 이유는, 실제 사용사례에서 ML 분석이나 역 ETL 워크플로 등 OLAP를 데이터 원천으로 이용하는 경우가 있기 때문이다.

5.2.5 변경 데이터 캡처 (CDC)

변경 데이터 캡처(Change Data Capture)는 데이터베이스에서 발생하는 각 변경 이벤트를 추출하는 방법이다.

5.2.6 로그

로그는 시스템에서 발생하는 이벤트에 대한 정보를 수집하며, 모든 로그는 이벤트와 이벤트 메타데이터를 추척한다. 따라서 최소한 누가, 무슨일이, 언제 발생했는지에 대한 정보를 수집해야한다.

• 로그 인코딩: 인코딩 방법에 대한 분류로 바이너리 인코딩 로그(데이터베이스 로그), 반정형 로그(JSON 등), 일반 텍스트 로그 있다.
• 로그 해상도: 로그에 캡처된 이벤트 데이터의 양으로, 예를들어 로그레벨 조정과 같이 특정 유형의 로그만 기록하여 조절한다.
• 로그 지연시간: 배치 또는 실시간으로 기록된다.

5.2.7 데이터베이스 로그

데이터베이스 로그는 로그 선행 기록을 통해 데이터베이스 보장과 복구에 중요한 역할을 수행한다. 특히 CDC는 데이터 엔지니어에게 데이터베이스 변경에대한 이벤트 스트림을 생성하는데에 유용하게 쓰인다.

5.2.8 CRUD

생성, 조회, 갱신, 삭제를 의미하는 CRUD는 프로그래밍에서 일반적으로 사용되는 트랜잭션 패턴으로, 기본적인 연산작업을 나타낸다. 보통 API와 데이터베이스에서 널리 사용된다.

5.2.9 입력 전용

입력 전용 패턴은 테이블에서 이력을 직접 유지한다. 이는 레코드를 갱신하는 대신 새로운 레코드가 생성된 타임스탬프와 함께 추가되어 입력된다. 데이터베이스 변경로그를 테이블에서 관리하므로 이력관리에 유리하나, 테이블이 많이 커질 수 있고 레코드 조회에 추가 오버헤드가 발생 할 수 있는 점을 고려해야한다.

5.2.10 메시지와 스트림

• 메시지: 둘 이상의 시스템 간에 전달되는 원시 데이터로, 소비자가 메시지를 수신하고 작업이 실행되면 메시지는 큐에서 삭제된다.
• 스트림: 이벤트가 발생하면 순서대로 누적되어 쌓이는 로그이며, 타임스탬프나 ID로 정렬 할 수 있다.

스트림을 처리하는 시스템은 메시지를 처리 할 수 있으며, 스트리밍 플랫폼은 메시지 전달에 자주 사용된다.

5.2.11 시간 유형

• 이벤트 시간: 원본 이벤트가 원천시스템에서 생성된 시점
• 수집 시간: 원천 시스템으로 부터 이벤트가 수집된 시점
• Process time: 데이터가 처리된 시간
• Processing time: 데이터를 처리하는데 걸린 시간

5.3 원천시스템의 실질적인 세부 사항

자주 접하게 되는 원천 시스템의 세부사항에 대해서 자세히 알아본다.

5.3.1 데이터베이스

• 데이터베이스 기술을 이해하기 위한 주요 고려사항
  • 데이터베이스 관리 시스템(DBMS): 데이터를 저장하고 제공하는데 사용 되는 데이터베이스 시스템
  • 조회: 데이터를 발견하고 검색을 수행하는 것으로, 인덱스를 이용해서 조회 속도를 높일 수 있다.
  • 쿼리 옵티마이저: 데이터베이스의 쿼리 옵티마이저 사용여부를 체크한다.
  • 확장과 분산: 데이터베이스 확장 가능성, 수직/수평 확장여부를 확인한다.
  • 모델링 패턴: 데이터베이스에 적합한 모델링 패턴(데이터 정규화 등)을 확인한다.
  • CRUD: 데이터베이스마다 CRUD작업은 다르게 처리된다.
  • 일관성: 데이터베이스가 어떤 일관성 모델을 지원하는지 확인한다.
• 관계형 데이터 베이스(RDBMS)
  • 데이터는 관계(Relation)테이블에 저장되며, 각 관계에는 여러 필드(열)가 포함되며 동일한 스키마를 가진다.
  • 테이블은 일반적으로 고유 필드인 Primary key에 의해 인덱싱 되고, 다른 테이블의 Primary키와 연결된 값이 있는 외래키(Foreign Key)를 가질 수 있다.
  • 일반적으로 ACID를 준수하며, 빠르게 변하는 어플리케이션의 상태를 저장하는 용도로 적합하다.
• 비관계형 데이터베이스(NoSQL, Not only SQL)
  • 관계형 패러다임을 포기한 모든 데이터베이스를 나타내다.
  • 데이터 및 쿼리 요건이 변화함에 따라 RDBMS에 부하가 걸리는 특정 워크로드에는 NoSQL이 필요하다.
  • 관계형 제약조건을 포기함으로써 성능, 확장성, 스키마 유연성을 높였으나, 트레이드오프로 강력한 일관성, 조인 또는 고정스키마등의 특성은 포기한다.
  • NoSQL 데이터 베이스 주요 유형
    • 키-값 저장소
      • 각 레코드를 고유하게 식별하는 키를 사용해 레코드를 검색
    • 도큐먼트 저장소
      • 테이블과 동일한 역할을 하는 컬렉션에 JSON 객체(도큐먼트)가 저장되고 Key로 검색된다.
      • 스키마가 매우 유연한 장점이 있으나, 이 때문에 스키마를 관리하지 않으면 데이터가 일관성 없이 비대해 질 수 있음을 주의해야 한다.
      • 많은 도큐먼트 저장소가 결과적으로 일관성을 유지하지만, 분산 클러스터 구성 시에는 주의해야 한다.
    • 와이드 컬럼 데이터베이스
      • 빠른 트랜잭션 속도와 매우 짧은 지연시간으로 대량의 데이터를 저장하는데 최적화 되어있다.
      • 복잡한 쿼리를 지원하지 않는다.
    • 그래프 데이터베이스
      • 수학적 그래프 구조로 데이터를 명시적으로 저장한다.
      • 요소간 연결성을 분석할 때 적합하며, 연결을 기반으로 쿼리를 수행 할 수 있다.
    • 검색 데이터베이스
      • 데이터 의미과 구조적 특성을 검색하는데 사용 되는 데이터 베이스이다.
      • 키워드나 구문을 검색하는 텍스트 검색과 운영 분석에 사용되는 로그 분석 등의 사용 사례가 있다.
    • 시계열 데이터베이스
      • 시간별로 정리된 일련의 값으로 데이터를 저장하는 데이터베이스이다.
      • 고속으로 증가하는 데이터 용량의 요구사항에 적합하며, 쓰기 작업이 많은 워크로드에 맞게 메모리 버퍼링을 사용해 빠른 쓰기와 읽기를 지원한다.
      • 타임 스탬프에 따라 정렬되며 조인이 일반적이지 않아, BI에는 적합하지 않다.

5.3.2 API

데이터를 교환하는 표준적이고 보편적인 방법이다.

• REST
  • 상호작용이 무상태성(stateless)라는 것이 주요 아이디어
  • 다양한 클라이언트 라이브러리와 API를 위한 커넥터들이 개발되면서 API에서 데이터를 수집하는 것이 많이 단순해 졌지만, 여전히 많은 리소스가 소비되는 항목이다.
• GraphQL
  • 어플리케이션 데이터의 쿼리 언어로, REST API의 대안으로 페이스북에서 만들었다.
  • 유연하고 풍부한 쿼리를 수행 할 수 있어, 단일 요청으로 여러 데이터 모델을 검색할 수 있다.
• 웹훅
  • 단순한 이벤트 기반 데이터 전송 패턴
• RPC와 gRPC
  • RPC(원격 프로시저 호출)은 분산 컴퓨팅에서 일반적으로 사용되며, 원격 시스템에서 프로시저를 실행 할 수 있도록 해준다.

5.3.3 데이터 공유

멀티테넌트 시스템에서 테넌트 간의 데이터 공유로, 클라우드에서 이를 위한 보안 정책을 지원한다.

5.3.4 서드파티 데이터원천

기술 기업에서 자사의 서비스의 데이터를 판매하거나 제공한다.

5.3.5 메시지 큐와 이벤트 스트리밍 플랫폼

클라우드환경에서의 손쉬운 설정과 실시간 분석 어플리케이션의 증가로 이벤트 기반 아키텍처가 점점 증가하고 있다. 스트리밍 플랫폼은 원천시스템 뿐 아니라 데이터 엔지니어링 수명주기 전반에서 등장 할 수 있다.

• 메세지 큐
  • 게시 및 구독 모델을 사용해 개별 시스템 간에 데이터를 비동기적으로 전송하는 메커니즘이다.
  • 종종 모호한 순서와 FIFO(선입선출)개념을 적용하며, 일반적으로는 순서가 잘못된 메시지 전달을 대비하여 설계해야 한다.
  • 정확히 한번 전송하거나 적어도 한번 전송할 수 있으므로, 이상적으로는 시스템이 멱등석 상태이어야 한다.
  • 일반적으로는 수평적으로 확장이 가능하며, 클러스터 구성으로 내구성을 높일 수 있으나 이런경우에는 전달 순서 지정 등 다양한 복잡성이 야기된다.
• 이벤트 스트리밍 플랫폼
  • 메시지큐의 연장선으로 정렬된 레코드 로그에서 데이터를 수집하고 처리하는 데 사용된다.
  • 관련된 이벤트 모음인 토픽에 이벤트를 스트리밍하고 소비한다.
  • 스트림 파티션을 이용해 스트림을 여러 스트림으로 분할 해서 병렬화 할 수 있는데, 이때 파티션 키를 잘 결정해서 핫스포팅을 생성하지 않도록 해야한다.
  • 일반적으로 여러 노드를 사용하는 분산형 시스템이므로 내결함성, 복원성이 높아 이벤트 데이터를 안정적으로 처리할 수 있다.

5.4 함께 작업할 대상

• 시스템 이해관계자: 원천시스템을 구축 및 유지 관리하는 SW엔지니어, 어플리케이션 개발자, 서드파티 등
• 데이터 이해관계자: 데이터에 대한 접근을 소유하고 제어하는 IT, 데이터 거버넌스 그룹
• 업스트림 소스 데이터에 문제가 발생하면 데이터엔지니어링 시스템에 영향을 미치게 되므로, 이를 인식할 수 있도록 데이터 계약이나 보증 관련 기대치를 설정하면 좋다.

5.5 드러나지 않는 요소가 원천 시스템에 미치는 영향

5.5.1 보안

데이터 전송 암호화, 네트워크, 키/비밀번호 관리, 합법성 여부 등을 잘 고려해야 한다.

5.5.2 데이터 관리

원천시스템의 데이터 거버넌스, 데이터 품질, 스키마, 마스터 데이터 관리, 개인전보보호, 규정을 잘 이해하고 있어야 한다.

5.5.3 데이터 옵스

원천시스템의 가동시간과 사용률을 관찰 및 모니터링하고 사고에 대응할 수 있어야 한다. 원천시스템을 관리하는 팀과 명확한 커뮤니케이션 체인을 구축해서 오류를 줄이고, 원천시스템 이해관계자의 데브옵스 관행에 참여해야 한다. 데이터 옵스에서는 자동화, 모니터링, 사고 대응을 고려해야 한다.

5.5.4 데이터 아키텍처

업스트림 아키텍처의 설계 방법과 장단점을 잘 이해하여, 다운스트림 데이터파이프라인 설계에 반영한다. 신뢰성, 내구성, 가용성, 담당자를 고려해야 한다.

5.5.5 오케스트레이션

원천시스템의 오케스트레이션과 관련해서는 데이터 제공 주기와 빈도, 오케스트레이션 프레임워크 통합 장단점을 고려해야 한다.

5.5.6 소프트웨어 엔지니어링

원천시스템에 접근하는 코드를 작성 할 때, 네트워크, 인증/인가, 접근 패턴, 오케스트레이션 , 병렬화, 배포방식을 고려해야 한다.

5.6 결론

원천시스템은 데이터 엔지니어가 직접적으로 관리하지 않아 중요하게 생각하지 않을 수 있지만, 데이터 품질향상과 개선을 위한다면 잘 이해하고 소통해야 한다. 이전과 달리 데이터 엔지니어와 원천시스템 팀 간의 통합이 증가하고 있으므로, 적절한 양방향의 공유 시스템을 구축해야 한다.