견고한 데이터 엔지니어링 Chapter.2 후기
Chapter1은 데이터 엔지니어링이 무엇인지 파악하는 단원이였다면 Chapter2에서는 1에서 수차례 강조되었던 데이터 엔지니어링 수명 주기에 대해 설명한다. 이 책을 읽으며 가장 마음에 들었던 점은 화려한 최신 기술들을 설명해주는 것이 아닌 데이터 엔지니어링의 숲을 파악할 수 있도록 집필되었다는 점이다. 이 분야에 조금이라도 관심있는 사람이라면 알 것이다. 이 직무는 굉장히 다양한 기술의 집합이라는 것을.. 그러나 기술의 집합이라고 보는 관점에서 벗어나도록 장려하는 것이 이 책의 주요 목표라고 한다. 따라서 이 후기도 단순한 책의 요약이 아닌, 데이터 엔지니어로 성장하고 생각하기 위해 주관적으로 되새기고 싶은 내용들의 메모 정도로 생각하길 바란다.
Chapter.2 데이터 엔지니어링 수명 주기
- 데이터 생성
- 데이터 저장
- 데이터 수집
- 데이터 변환
- 데이터 서빙
사실 위 5단계는 다른 책에서도 많이 접할 수 있는 부분이다. 데이터 엔지니어가 하는 일이 무엇이냐고 질문을 받는다면 위 5개를 말하는 게 보편적일 것이다. 그러나 이 책에는 드러나지 않는 요소 또한 강조하고 있다. 이는 그림에서 볼 수 있듯이 전반적인 수명 주기에 기반이 되고 있고 여러 단계에 걸쳐져 있다. 이러한 요소 없이는 데이터 엔지니어링 수명 주기의 어떤 부분도 적절하게 작동할 수 없다.
1단계 - 데이터 생성
- 원천 시스템의 작동 방식, 데이터 생성 방식, 데이터의 빈도 및 속도, 생성되는 데이터의 다양성을 실무적으로 이해해야 한다.
- 데이터 파이프라인과 분석을 중단할 수 있는 변경 사항에 대해 원천 시스템 소유자와 개방적인 소통 라인을 유지해야 한다.
- 원천으로부터 데이터를 생성하는 방법(관련 분제나 미묘한 차이점 포함)을 알아야 한다.
- 상호 작용하는 원천 시스템의 한계를 이해해야 한다.
* 스키마리스 방식: 데이터베이스 테이블의 스키마를 사전에 정의하지 않고 유연하게 데이터를 저장하는 방식 (ex. NoSQL)
* 고정스키마 방식: 데이터베이스 테이블의 스키마가 사전에 정의되어 고정된 형태
2단계 - 데이터 저장
- 종종 여러 개의 스토리지 솔루션을 활용한다. (1개만 이용할 거라고 생각했다..)
- 복잡한 변환 쿼리를 지원하는 데이터 스토리지 솔루션은 순수 스토리지가 아닌 복잡한 변환 쿼리를 지원한다.
- 모든 스토리지 기술에는 트레이드오프가 있기 대문에 데이터 아키텍처에 가장 적합한 옵션을 결정할 때 압도당하기 쉽다.
* Hot data: 가장 자주 액세스되는 데이터
* Lukewarm data: 가끔(매주 또는 매월) 액세스 되는 데이터
* Cold data: 거의 쿼리되지 않는 데이터
3단계 - 데이터 수집
- 신뢰할 수 없는 원천 및 수집 시스템은 수명 주기 전반에 걸쳐 파급 효과를 가져올 수 있다. → 병목 현상
- 품질이 낮은 데이터
- 응답하지 않는 시스템
서울대병원은 supreme이라는 CDW가 존재했는데 문제가 많았다. 품질이 낮은 데이터가 종종 존재했고 시스템이 다운되는 일이 비일비재했다. 내 야근의 8할은 supreme 때문이였다.. 후.. 이 오류를 발견할 때 마다 담당 팀에게 버그 리포트를 문의하면서 점차 고쳐지고 발전됐다. 2년이 지났을 무렵 거의 모든 오류들이 수정되며 신뢰성 높은 CDW가 완성(?)되었다. 그 무렵에 난.. 퇴사했다:)
* 배치: 미리 설정된 시간 간격에 따라, 또는 데이터가 미리 설정된 크기 임곗값에 도달하면 수집된다.
* 스트리밍: 다운 스트림 시스템에 데이터를 실시간으로 연속해 제공할 수 있다.
이 둘에 대한 선택은 주로 사용 사례와 데이터 적시성에 대한 기대치에 따라 달라진다.
4단계 - 데이터 변환
- 변환에 드는 비용과 ROI는 얼마인가? 관련된 비즈니스 가치는 무엇인가?
- 변환은 가능한 한 단순하고 독립적인가?
- 변환이 지원하는 비즈니스 규칙은 무엇인가?
5단계 - 데이터 서빙
- 데이터로부터 가치를 창출 해야 한다.
- 데이터는 실용적인 목적으로 사용될 때 가치가 있다.
- 데이터 프로젝트는 수명 주기 전반에 걸쳐 다분히 의도적이여야 한다.
드러나지 않는 요소 1. 보안
- 데이터와 접근 보안을 모두 이해하고 최소 권한 원칙을 실행해야 한다.
- 역할이 낮은 테이블을 쿼리할 때는 데이터베이스에서 슈퍼유저 역할을 사용하지 않는다.
- 유능한 보안 관리자여야 한다.
- 클라우드와 온프레미스 환경 모두에 대한 보안 모범 사례를 이해해야 한다.
* 최소 권한 원칙: 사용자 또는 시스템이 의도된 기능을 수행하는 데 필수적인 데이터와 자원에만 접근할 수 있는 것
실제로 나는 2년동안 병원에서 엔지니어로 일하면서 보안 요소에 굉장히 많은 시간을 할애했다. 환자의 개인정보를 다루다보니 모든 단계에서 자꾸 발목을 잡혔다. 범위도 다 다르고 자칫 방심했다가 유출이라도 된다면 온전히 책임을 져야했기 때문에 보안 관리자가 된 거 같았다. 그 땐 병원이여서 보안에 신경쓴다고 생각했는데 이 책을 읽어보니 엔지니어여서 생각해야 하는 요소였나보다.
드러나지 않는 요소 2. 데이터 관리
- 조직 전체의 데이터 활용에 대한 폭 넓은 관점이 필요하다.
- 가치를 얻고 적절히 처리할 수 있도록 모든 사람이 채택할 수 있는 일관된 프레임워크를 형성한다.
드러나지 않는 요소 3. 데이터 거버넌스
- 데이터 중심 기업에서는 데이터를 사용할 수 있고 검색할 수 있어야 한다.
- 데이터가 사용가능한 형태로 제공되어야 한다.
- 모델링의 모범 사례를 이해하고, 데이터 원천과 사용 사례에 적절한 수준과 유형의 모델링을 적용할 수 있는 유연성을 개발해야 한다.
- 사용자의 '잊혀질 권리'를 존중하기 위해 데이터 파기를 적극적으로 관리해야 한다.
드러나지 않는 요소 4. 데이터옵스
- 소프트웨어 제품 구축의 기술적 측면과, 우수한 데이터 제품을 만드는 비즈니스 로직, 품질 및 측정 지표를 모두 이해해야 한다.
- 워크로드를 줄이고 비즈니스에 제공하는 가치를 높일 수 있는 자동화를 지속해서 구현해야 한다.
- 사고는 필연적으로 발생하기 때문에 기업이 문제를 보고하기 전, 미리 해당 문제를 발견해야 한다.
드러나지 않는 요소 5. 데이터 아키텍처
- 데이터 아키텍트의 설계를 이행하고 아키텍처 피드백을 제공할 수 있어야 한다.
드러나지 않는 요소 6. 오케스트레이션
* 오케스트레이션: 많은 작업이 예약된 순서대로 최대한 빠르고 효율적으로 실행되도록 조정하는 프로세스
- 엄밀히 말하면 '배치 개념'이다.
드러나지 않는 요소 7. 소프트웨어 엔지니어링
- unit, regression, 통합, end-to-end, smoke 등의 적절한 코드 테스트 방법론을 이해해야 한다.
- 프레임워크를 사용할 때 기존 커넥트가 없는 데이터 원천에 직면하게 되고 사용자 정의 코드를 작성해야 한다.
- API를 이해하고, 데이터 풀링 및 변환을 수행하고, 예외를 처리하는 등 필요한 소프트웨어 엔지니어링에 능숙해야 한다.
데이터 엔지니어는 데이터 수명 주기 전반에 걸쳐 ROI를 최적화하고 비용(재무 및 기회)을 절감하며 리스크(보안, 데이터 품질)를 줄이고 데이터 가치와 효용을 극대화하는 몇몇 최상위 목표를 가진다.