데이터 엔지니어를 위한 97가지 조언.md

• 
• 이 책은 데이터 엔지니어로서 필요한 지식과 실무적 통찰을 제공하는 97가지 조언을 담고 있습니다. 책에는 데이터 전문가들이 다양하고 구체적인 문제를 극복하면서 얻은 경험과 교훈을 담고 있어서 가볍게 읽기 좋았습니다.
• 주요 내용으로는 일관성과 최종 일관성에 대한 개념, 스토리지 계층의 효율적인 사용, 데이터 파이프라인의 설계 패턴, 그리고 변경 데이터 캡처(CDC)와 메시징 시스템의 중요성입니다. 또한, 데이터 레이크와 데이터 사일로, 데이터 계보 추적 및 관측 가능성의 필요성도 다루고 있으며 실용적이고 확장 가능한 데이터 시스템 구축을 위한 다양한 접근법을 제시하고 있습니다.
• 데이터 엔지니어링의 이론적 기반부터 실무적 적용까지 폭넓게 다루며, 새로운 기술 트렌드를 가볍게 소개하는 동시에 효율적인 설계 방법을 제안하고 있어서 유익하였습니다.
  • 쿼리 엔진은 데이터를 메모리에 올리기 전에 필요한 부분만 처리하여 I/O와 CPU 비용을 절감하려고 합니다. 이를 위해 인코딩과 압축을 활용해 데이터를 효율적으로 저장하고, 읽을 때는 푸시다운 기법을 사용하여 스토리지에서 필요한 데이터만 로드합니다.
  • 프로젝션 푸시다운으로는 필요한 열만, 조건자 푸시다운으로는 조건에 맞지 않는 행을 제외합니다. 예를 들어, 아파치 파케이 같은 열 기반 포맷은 이 과정에서 효율을 높이며, 아파치 아이스버그는 데이터를 정렬하고 파티셔닝하여 압축과 검색 성능을 개선합니다.
  • 예를 들어, 아파치 파케이 같은 열 기반 포맷은 프로젝션 푸시다운을 사용하여 필요한 열만 읽을 수 있고, 인코딩과 압축도 효율적으로 처리할 수 있습니다. 최솟값이나 최대값 같은 통계를 활용하면 조건자 푸시다운을 적용할 수 있으며, 필터 조건에 맞지 않는 행 그룹을 아예 읽지 않아도 됩니다. 데이터 정렬과 파티셔닝을 통해 압축 효율을 높이고, 조건자 푸시다운의 성능도 향상됩니다. 이를 통해 데이터의 읽기 범위를 더 정확하게 좁힐 수 있습니다.
• 데이터 엔지니어는 데이터를 분석하고, 머신 러닝, 비즈니스 인텔리전스 등에 사용할 수 있도록 만들어주는 사람
• 데이터 팀에서 일하기 위한 노하우, 도구를 선택할 때 필요한 팁, 분산 시스템에 대한 기본 원리를 알 수 있음

01_서고 재고관리 시스템으로 알아보는 최종 일관성

• 강한 일관성 : 점포의 재고 장부 읽기 요청이 순차적으로 치리되며, 다음에도 재고 관리 시스템을 통해 읽는 상태가 동일하다는 의미
• 모든 트랜잭션이 최종 일관성(eventual consistency)을 갖도록 계획함. 점포 재고에 대한 각각의 접근은 병렬적으로 처리되어 책 재고 관리 시스템으 갱신함
• 읽기 복구(read reapair) - 불일치가 발견됐을 경우에만 원장 전체의 상태를 고쳐 쓰는 부담스러운 작업을 시작함
• 클라이언트-서버 스타일 아키텍처로 확장하는 강한 일관성, 대용량 트랜잭션을 처리하고 상태가 비일관적임을 발견햇을 때 해결하는 최종 일관성을 갖음

03_스토리지 계층에 대하여

• 단순한 쿼리 엔진은 데이터를 메모리에 로드한 다음, 필터 및 표현식을 적용함. 나중에 쿼리 프로세싱 과정에서 버려질 것은 로드하지 않으려 함. 로드하지 않으면 역직렬화도 하지 않으므로 I/O 비용뿐만 아니라 CPU 비요까지 절약됨
• 데이터가 차지하는 공간을 줄여서 저장 비용을 줄이고 데이터를 찾아 가져오는 속도도 높여야 함. 인코딩과 압축을 조합하며 I/O 비용 감소와 CPU 비용 증가 사이에서 균형을 찾을 수 있음.
• 스토리지의 처리량이 CPU 사용량을 결정하기 때문에 저렴한 디코딩 기법이 매우 중요함
• 푸시 다운은 쿼리 연산을 스토리지 계층으로 밀어내려서 데이터 로드 비용을 최소화함
• 프로젝션 푸시다운은 요청된 열만 읽음
• 조건자 푸시다운은 필터가 제외시킬 행을 역직렬화하지 않음
• 부분 집계 및 함수/표현식 평가를 푸시다운해서 중간 형태 데이터를 구체화되지 않게 함
• 열 기반 레이아웃(예, 아파치 파케이)을 사용하면 프로젝션 푸시다운이 가능해지고 인코딩과 압축을 더 잘할 수 있음. 최솟값이나 최대값 같은 다양한 세부 수준 통계가 있다면 조건자 푸시다운을 사용할 수 있음. 이를테면 행 그룹의 최대값이 항상 필터 조건을 만족하는 값보다 작다면, 행 그룹을 읽거나 역직렬화할 필요가 전혀 없음.
• 데이터 정렬과 파티셔닝, 아파치 아이스버그가 가능하게 만든, 서로 다른 열 기준의 정렬과 파티셔닝을 통해 압축과 조건자 푸시다운의 효율성이 올라감. 통계를 적용하여 데이터에서 읽을 범위를 더 정확하게 좁힐 수 있기 때문

12_변경 데이터 캡처

• 변경 로그는 데이터베이스의 테이블마다 테이블 안의 행/셀 변경 사항 하나하나를 캡처하며, 생산 데이터베이스의 복제본을 만들기 위해 사용될 수 있음. CDC를 진행할 때는 도구가 미리 쓰기 로그를 읽어서 변경 사항을 데이터 웨어하우스에 반영시킴
• CDC 커넥터 수명 주기의 여러 측면 고려
  • 규모
  • 복제 지연
  • 스키마 변경
  • 마스킹
  • 기록 동기화 (테이블의 초기 기록을 동기화)

16_데이터 엔지니어링은 스파크와 같지 않다

• 데이터 엔지니어링 = 계산 + 스토리지 + 메시징 + 코드 + 아키텍처 + 도메인 지식 + 사용 사례
• 계산 컴포넌트
  • 계산이란 데이터가 처리되는 방식. 계산 프레임워크가 알고리즘 및 대부분의 코드 실행을 담당하고, 빅데이터는 리소스 할당 및 코드 분산 실행, 결과 저장을 담당함
• 메시징 컴포넌트
  • 메시징은 지식이나 이벤트가 실시간으로 전달되는 방식
  • 실시간 시스템이 필요할 때 메시징을 사용하기 시작함. 이러한 메시징 프레임워크는 대량의 데이터를 수집하고 전파하는 데 사용됨
  • 실시간 시스템에서 데이터 수집과 전파가 중요한 이유는 시스템의 시작부터 중간, 혹은 시스템의 중간부터 끝 사이에서 발생하는 문제를 해결하기 위함

17_자율성 및 신속한 혁신을 돕는 데이터 엔지니어링

• 데이터 파이프라인은 일반적으로 비즈니스 혹은 알고리즘 로직(측정치 계산, 모델 훈련, 특징화 등) 및 데이터 흐름 로직(복잡한 조인, 데이터 랭글링, 세션화 등)으로 나뉨

19_재사용 및 확장 가능한 코드를 만드는 데이터 파이프라인 디자인 패턴

• 데이터 엔지니어링에서는 데이터 소스, 수집, 유효성 검사, 프로세싱, 보안, 로깅, 모니터링 등 여러 계층에 걸친 지속적인 변화를 처리해야 함
• 생성과 구조 패턴
  • 로깅 및 모니터링 같은 크로스커팅 관심사를 DAG 특정 영역에서 분리하여 생성하고 구조화할 수 있음
  • 팩토리와 추상 팩토리 패턴은 DAG 코드로부터 로거와 모니터리를 추상화하고 분리하여 DAG 코드 베이스가 로그 기록 및 모니터링 코드 베이스에 대한 의존성 없이 발전하도록 도와줌
• 행동 패턴
  • DRY와 SOLID 원칙을 어기지 않으면서 구체적인 동작을 지시할 수 있음
  • 데코레이터 패턴은 기존 함수의 동작을 수정하거나 추가하는 데 널리 사용되며, 로깅 및 모니터링에 즉시 적용할 수 있음
• 파시드 패턴
  • 클라이언트나 소비자가 원래보다 적은 수의 API나 특정 API만을 필요로 할 때 유용함. 이를테면 다양한 로거와 모니터가 노출하는 방대한 API와 메서드는 DAG 계층에 노출될 필요가 없음. 이때 파샤드 패턴은 로깅 및 모니터링 계층에 대한 인터페이스를 정의하는 데 도움이 됨

24_로그 중심 아키텍처에서의 메시지 정의 및 관리 방식

• 메시지 설계 및 관리는 로그 중심 아키텍처에서 중요한 구성 요소
  • 메시지 정의의 기초가 되는 잘 정의된 시맨틱(semantic) 데이터 모델
  • 토픽을 쉽게 만들고 삭제할 수 있도록 버전 관리를 지원하는 잘 정의된 전략, 이름에 버전 식별자를 직접 인코딩하는 것이 좋음

28_데이터 레이크 아티켁처를 받아들여라

• 직접 데이터에 접근하면 파이프라인 전반에 걸친 표준화(표준 타임스탬프나 키 필드 등)가 이뤄지지 않으며, 스키마 및 데이터 계약이 없기 때문에 데이터의 손상 위험이 커짐
• 구현
  • 변경 감지 시스템을 사용하거나 자바 데이터베이스 연결 혹은 JDBC를 사용하는 등 어떤 방식이든 데이터 최신성을 개선하면서도 데이터베이스의 부하를 줄여주는 증분 방식의 데이터베이스 수집을 고려하세요
  • 애플리케이션의 이벤트 스트림과 앞서 언급한 데이터베이스 변경 스트림을 단일 이벤트 버스(아파치 카프카, 아파치 펄사 등)로 표준화하세요
  • 데이터베이스 변경 사항을 스냅숏으로 압축하기 위한 업서트 연산을 지원하는 기술(아파치 쿠두, 아파치 후디, 아파치 하이브 ACID 등)을 사용해서 이벤트 버스로부터 미가공 데이터셋을 수집하세요
  • 데이터를 파티셔닝(아파치 하이브 메타스토어 활용 등)하거나 변경 스트림을 지원하는 시스템(아파치 후디 등)을 사용하여 변경 감지와 비슷한 방식으로 새 레코드를 효율적으로 가져올 수 있도록 미가공 데이터셋을 설계하세요

29_데이터 사일로를 받아들여라

• 오케스트레이션 시스템은 컴퓨팅 프레임워크와 스토리지 시스템 사이에 위치함
• 데이터 오케스트레이션 시스템은 스토리지 시스템 전반에 걸쳐 데이터 액세스를 추상화하고, 모든 데이터를 가상화하며 글로벌 네임스페이스가 있는 표준화된 API를 통해 데이터를 제공하는 계층

33_동료에게 이중 기록을 권하지 마라

• 변경 이벤트를 아파치 카프카 등의 분산 커밋 로그를 통해 전파시키면 가용성 문제까지 해결됨. 다운스트림 시스템을 잠시 사용할 수 없는 상황이라면 나중에 그저 마지막으로 읽은 지점부터 변경된 데이터 토픽을 읽어가면 됨
• CDC 프로세스도 비동기적이므로 동기적으로 사용해야 하는 리소스는 데이터베이스 자체뿐임
• 분산 커밋 로그로 변경 이벤트를 전파했을 때의 또 다른 장점은 변경 이벤트 토픽을 처음부터 다시 읽기만 하면 다른 소비자나 사용 사례에도 사용할 수 있다는 점. 그렇게 하면 이중 쓰기에 의존하지 않고, 이해관계작 있는 다른 서비스로 데이터를 전달할 수 있음

40_관리하는 데이터의 바이트당 가격을 파악하라

• 바이트당 가격 메트릭은 계산하기 쉬움. 데이터셋의 전체 크기를 총 비용으로 나누면 바이트당 가격 메트릭이 나옴

49_데이터 레이크는 ACID를 제공하지 않으므로 조심하라

• 요구 사항이나 데이터 레이크의 데이터를 사용할 소비자와 맺은 계약에 따라 보장받을 사항을 정리해야 함
• 하이브 메타스토어 등의 중앙 집중식 메타스토어는 컬렉션 전반의 원자성과 일관성이 충족되지 않아 생기는 문제를 완화할 수 있으며, 후디와 같은 버전이 있는 데이터 형식은 쓰기 연산(작업)에서 읽기를 분리하고 고립시키는 부담을 줄여줌
• lakeFS와 같은 프레임워크를 통해 하이브와 후디 사용을 지원하면서 원자성과 일관성, 격리, 영속성을 보장하는 안전한 데이터 레이크 관리 환경을 제공할 수 있음

53_데이터 엔지니어를 위한 관측 가능성

• 데이터 관측 가능성 도입
  • 신선도 : 데이터가 최신인가요? 마지막 생성 시점은 언제인가요? 포함되거나 생략된 업스트림 데이터는 무엇인가요?
  • 분포 : 데이터가 허용 범위 내에 있나요? 올바른 형식을 따르나요? 완전한 가요?
  • 볼륨 : 수집해야 할 모든 데이터가 도착했나요?
  • 스키마 : 스키마가 어떻게 변경되었나요? 누가 어떤 이유로 변경했나요?
  • 계통 : 주어진 데이터 자산에 영향을 받는 업스트림 자산과 다운스트림 자산은 무엇인가요? 데이터를 생성하는 사람은 누구이며, 의사결정을 하기 위해 데이터를 사용하는 사람은 누구인가요?

74_데이터 계보의 중요성

• 운영 중인 계보
  • 사용된 입력 버전
  • 읽어 들인 데이터 부분 집합
  • 변환을 수행한 코드 버전
  • 출력 정의 및 각 열이 입력에서 파생된 방법
  • 완료까지 걸린 시간 및 성공 여부
  • 생성된 출력 버전
  • 출력 데이터 형태(스키마, 행 개수, 분포 등)