팀 내에서 데이터 엔지니어링 관련 스터디를 시작했습니다. 책은 Fundamentals of Data Engineering입니다. DataOps와 MLOps작업을 팀 내 데이터 엔지니어분들과 함께 수행하면서 데이터 엔지니어링의 기반에 대해 항상 궁금했습니다.. 책을 정독하고 팀원들과 의견을 공유하면서 CRM 및 추천 태스크에 적용중인 ML기반 의사 결정 시스템의 원천인 데이터 파이프라인에 대해 치열하게 숙고하고 토론한 과정을 공유할 예정입니다. 무엇보다 데이터 파이프라인을 고도화할 수 있는 좋은 기회일 것 같습니다. 이번 포스트는 데이터 엔지니어링에 관한 정의.에 관하여 살펴보겠습니다.
데이터 엔지니어링이란?
저자는 데이터 엔지니어링과 데이터 엔지니어의 역할을 다음과 같이 정의합니다.
데이터 엔지니어링은 raw data를 가져와 분석 및 머신러닝과 같은 다운스트림 사용 사례를 지원하는, 고품질의 일관된 정보를 생성하는 시스템과 프로세스의 개발, 구현 및 유지 관리이다. 데이터 엔지니어링은 보안, 데이터 관리, 데이터 운영, 데이터 아키텍처, 오케스트레이션, 소프트웨어 엔지니어링의 교차점이다. 데이터 엔지니어링은 데이터 과학의 업스트림에 위치한다. 데이터 엔지니어는 데이터 과학자가 사용할 입력값을 제공하며, 데이터 과학자는 이렇게 입력된 값들을 유용한 결과로 변환한다.
데이터 엔지니어는 원천 시스템에서 데이터를 가져오는 것부터 시작해 분석 또는 머신러닝과 같은 사용 사례에 데이터를 제공하는 것으로 끝나는 데이터 엔지니어링 수명 주기를 관리한다.
데이터 엔지니어링 수명 주기
데이터 엔지니어링 수명 주기는 raw data와 데이터의 최종 목표에 관한 것입니다. 데이터 엔지니어링 수명 주기의 단계는 다음과 같습니다.
- Data generation
- Data storage
- Data ingestion
- Data transformation
- Data serving
위의 수명 주기에 드러나지 않는 요소(보안, 데이터 관리, 데이터옵스, 데이터 아키텍처, 오케스트레이션, 소프트웨어 엔지니어링)라는 개념을 포함합니다. 데이터 엔지니어링은 비즈니스 목표를 달성하기 위해 다양한 기술들을 레코 블록처럼 연결하고 상호 운용하는 분야가 되고 있습니다. 데이터 엔지니어는 데이터 수명 주기 엔지니어(Data lifecycle engineer)로 표현할 수 있습니다. 데이터 엔지니어는 저수준의 데이터 프로그래밍 기술을 유지하고 필요에 따라 이를 사용합니다. 하지만 데이터 관리, 데이터옵스, 데이터 아키텍처, 오케스트레이션 및 일반 데이터 수명 수기 관리와 같은 가치 사슬의 상위 영역에 자신의 역할이 점점 집중되고 있음을 발견합니다.
Data generation
원천 시스템은 데이터 엔지니어링 수명 주기에서 사용되는 데이터의 원본입니다. 중요한 점은 데이터 파이프라인이 중단될 수 있는 변경 사항에 대해 원천 시스템 소유자와 지속적인 소통 라인을 유지해야 합니다. 데이터 엔지니어링의 가장 큰 과제는 엔지니어가 작업하고 이해해야 하는 데이터 원천 시스템의 방대한 배열입니다. 데이터 엔지니어는 개별적인 원천으로부터 데이터를 생성하는 방법을 알아야 합니다.
원천 시스템 평가 : 주요 고려 사항
다음은 원천 시스템의 평가 질문 스타터킷(Starter Kit)입니다.
- 데이터 원천의 본질적인 특징은 무엇인가? 데이터 원천은 애플리케이션인가? IoT 장치의 swarm인가?
- 원천 시스템에서 데이터는 어떻게 유지되는가? 데이터는 장기간 보존되는가? 아니면 일시적이고 빠르게 삭제되는가?
- 데이터는 어느 정도의 속도로 생성되는가? 초당 몇 개의 이벤트가 발생할까? 시간당 몇 기가바이트인가?
- 데이터 엔지니어는 출력 데이터에서 어느 정도의 일관성을 기대할 수 있는가? 출력 데이터에 대해 데이터 품질 검사를 실행할 때, 예상치 못한 출력값이나 잘못된 데이터 포맷과 같은 데이터 불일치 사례는 얼마나 자주 발생할까?
- 에러는 얼마나 자주 발생하는가?
- 데이터에 중복이 포함되지는 않는가?
- 일부 데이터값이 동시에 생성되는 다른 메시지보다 훨씬 늦게 도착할 수 있는가?
- 수집된 데이터의 스키마는 무엇인가? 데이터 엔지니어가 데이터를 완전히 파악하려면 여러 테이블 또는 여러 시스템에 걸쳐 조인을 수행해야 하는가?
- 스키마가 변경되면 어떻게 대처하고 다운스트림 이해관계자에게 전달할 수 있는가?
- Schemaless vs Fixed schema
- 원천 시스템에서 데이터를 얼마나 자주 가져와야 하는가?
- Stateful system의 경우, 데이터는 정기적인 스냅샷으로 제공하는가? 아니면 CDC로부터의 갱신 이벤트로 제공되는가? 변경은 어떻게 수행되며, 원천 데이터베이스에서 이러한 변경을 어떻게 추적하는가?
- 다운스트림 사용을 위한 데이터를 전송하는 데이터 제공업체는 누구인가?
- 데이터 원천에서의 데이터 조회가 성능에 영향을 미치는가?
- 원천 시스템에 업스트림 데이터 의존 관계가 있는가? 이러한 업스트림 시스템의 특징은 무엇인가?
- 늦거나 누락된 데이터 확인용으로 데이터 품질 검사가 실시되고 있는가?
Data storage
데이터를 저장할 공간이 필요합니다. 데이터 저장은 원천 시스템, 수집, 변환 및 서빙과 교차하는 스토리지 시스템을 통해 전체 데이터 엔지니어링 수명 주기에 걸쳐 실행됩니다. 언제나 두루 적용될 수 있는 범용 스토리지 권장 사항은 없습니다. 모든 스토리지 기술에는 장단점, 즉 트레이드오프(Trade-off)가 있습니다.
스토리지 시스템 평가 : 주요 고려 사항
다음은 데이터 웨어하우스, 데이터 레이크하우스, 데이터베이스 또는 객체 스토리지를 위한 스토리지 시스템을 선택할 때 확인할 사항들입니다.
- 해당 스토리지 솔루션은 아키텍처에서 요구하는 쓰기 및 읽기 속도와 잘 맞는가?
- 스토리지가 다운스트림 프로세스의 병목 현상을 초래하지는 않는가?
- 스토리지 기술이 작동하는 방식을 인지하고 있는가? 스토리지 시스템을 최적으로 활용하는가? 아니면 부자연스러운 행동을 하는가?
- 스토리지 시스템은 향후 예상되는 확장을 처리할 수 있는가? 사용 가능한 총 스토리지, 읽기 작업 속도, 쓰기 볼륨 등 스토리지 시스템의 모든 용량 제한을 고려해야 한다.
- 스키마 진화, 데이터 흐름, 데이터 계보 등에 대한 메타데이터를 캡처하고 있는가? 메타데이터는 데이터 활용성에 큰 영향을 미친다. 메타 데이터는 미래에 대한 투자로, 검색 가능성과 제도적 지식을 획기적으로 향상시켜 미래의 프로젝트 및 아키텍처 변경을 간소화한다.
- 순수 스토리지 솔루션(객체 스토리지)인가? 아니면 복잡한 쿼리 패턴(Ex : 클라우드 데이터 웨어하우스)을 지원하는가?
- 스토리지 시스템이 스키마에 구애받지 않는가? 유연한 스키마(카산드라)인가? 강제 적용된 스키마(클라우드 데이터 웨어하우스)인가?
Data ingestion
데이터 엔지니어링 수명 주기의 다음 단계는 원천 시스템에서 데이터를 수집하는 것입니다. 데이터 수집 전에 데이터 원천과 사용 중인 원천 시스템의 특징 및 데이터 저장 방법을 이해해야 합니다.
수집 단계에서의 주요 엔지니어링 고려 사항
다음은 수집 단계에서의 질문 스타터킷(Starter Kit)입니다.
- 수집 중인 데이터 사용 사례는 무엇인가? 같은 데이터셋의 여러 버전을 생성하는 대신 이 데이터를 재사용할 수 있는가?
- 시스템이 데이터를 안정적으로 생성하고 수집하고 있는가? 필요할 때 해당 데이터를 사용할 수 있는가?
- 수집 후 데이터 목적지는 어디인가?
- 데이터에 얼마나 자주 접근해야 하는가?
- 데이터는 보통 어느 정도의 용량으로 도착하는가?
- 데이터 형식은 무엇인가? 다운스트림 스토리지 및 변환 시스템에서 이 형식을 처리할 수 있는가?
- 원천 데이터는 다운스트림에서 즉시 사용할 수 있는 양호한 상태인가? 그렇다면 얼마나 오래 사용할 수 있으며, 사용할 수 없게 되는 요인은 무엇인가?
- 데이터가 스티리밍 소스에서 전송된 경우, 목적지에 도달하기 전에 데이터를 변환해야 하는가? 데이터가 스트림 자체 내에서 변환되는 형태의 변환이 적절할까?
Batch vs Stream
스트리밍 수집을 사용하면 다른 어플리케이션이나 데이터베이스 또는 분석 시스템 등의 다운 스트림 시스템에 데이터를 실시간으로 연속해서 제공할 수 있습니다. 여기서 실시간이란 데이터가 생성된 지 얼마 지나지 않은 짧은 시간에 다운스트림 시스템에서 데이터를 사용할 수 있음을 의미합니다. 스트리밍 수집이 배치 수집보다 적절한 선택인지 여부를 판달할 때 체크리스트는 다음과 같습니다.
- 데이터를 실시간으로 수집하면 다운스트림 스토리지 시스템이 데이터 흐름 속도를 처리할 수 있는가?
- 밀리초 단위의 실시간 데이터 수집이 필요할까? 아니면 매분마다 데이터를 축적하고 수집하는 마이크로 배치 접근 방식이 효과가 있을까?
- 스트리밍 수집의 사용 사례로는 무엇이 있을까? 스트리밍을 구현하면 구체적으로 어떤 이점을 얻을 수 있을까? 데이터를 실시간으로 가져올 수 있다면, 배치 방식에 비해 개선될 수 있는 데이터에 대해 어떤 조치를 취할 수 있을까?
- 인프라에 장애가 발생했을 때 스트리밍 파이프라인과 시스템이 안정적이고 다중화되어 있는가?
- 사용 사례에 가장 적합한 도구는 무엇인가? 관리형 서비스를 사용해야 하는가? 아니면 카프카, 플링크, 스파크, 펄사 등의 인스턴스를 구축해야 할까? 후자를 선택한다면 누가 관리의 역할을 맡을 것인가? 비용과 트레이드오프는 무엇일까?
- ML 모델을 배포했을 때 온라인 예측 및 지속적인 훈련으로 얻을 수 있는 이점은 무엇일까?
- 실제 운영 인스턴스에서 데이터를 가져오는가? 그렇다면 이 원천 시스템에 대한 수집 프로세스의 영향도는 얼마나 될까?
데이터 엔지니어링 관련 활동
위에서 수명 주기에 드러나지 않는 요소를 활용하려면 데이터 분석가와 데이터 과학자가 어떻게 데이터를 소비하고 가치를 창출할지 파악하는 것이 중요합니다. 데이터 엔지니어는 모놀리식한 기술을 사용하는 방법을 이해해야 했습니다. 하지만 최근에 데이터 도구 환경이 간편해지면서 가장 단순하고 비용 효율적인 데이터 처리 작업에 집중하고 있습니다. 오늘날 데이터 도구 환경은 관리 및 구현하기에 훨씬 간편해졌습니다. 최신 데이터 도구를 워크플로를 상당히 추상화하고 단순화합니다. 그 결과 데이터 엔지니어는 비즈니스에 가치를 제공하는, 가장 단순하고 비용 효율적인 업계 최고 수준의 서비스 간 균형을 맞추는 데 주력하고 있습니다.
Reference
- Fundamentals of Data Engineering
[Data Observability Driven Development The perfect analogy for beginners](https://www.kensu.io/blog/a-guide-to-understanding-data-observability-driven-development)