견고한 데이터 엔지니어링
이 글은 “견고한 데이터 엔니지어링”의 2장 “데이터 엔지니어링 수명 주기” 챕터를 읽고 쓰는 글입니다.
데이터 엔지니어링 수명 주기란?
위 그림은 저자가 데이터 엔지니어링 수명 주기를 5단계로 나누어 놓은 그림입니다. 다음의 5가지 단계에 대해서 주의 깊게 알아보는 과정이 이번 포스팅의 주요 목적이 될 것 같습니다.
그리고 추가적으로 드러나지 않는 요소이지만, 데이터 엔지니어링 과정에서 매우 주의깊게 생각해야 하는 부분 또한 알아 볼 예정입니다.
1. 데이터 생성
데이터의 생성 단계에서 우리가 중요하게 생각해야 하는 키워드는 원천 데이터입니다.
원천 데이터란 데이터 엔지니어링 수명 주기에서 사용되는 데이터의 원본입니다. 예를 들면 IOT장치, 애플리케이션 메시지 대기열 또는 트랜잭션 데이터베이스일 수 있습니다.
데이터 엔지니어는 원천 데이터를 소비하지만 원천 데이터 자체를 소유하거나 제어하지 않으며, 원천 시스템의 작동 방식과 데이터 생성 방식 및 빈도와 속도, 다양성 등을 실무적으로 이해해야 한다고 합니다.
저는 이 부분을 읽고 생각이 든 점은 Fluentd를 사용하여 사용자 기기에서 발송 된 이벤트를 읽는 프로젝트를 했을 때, 원천 데이터를 직접 수집하면서 느꼈 던 경험이였습니다.
그 당시 저는 초당 입력되는 로그의 평균 값에 여유롭게 부합하는 서비스 부하 분산, 원천 데이터 자체를 변환하지 않고 특정 프로세스의 Input으로 입력하면서 작업 했던 점, 실제 전송 로직을 담당 팀과 이야기 했던 점 등 원천 데이터를 다루면서 이 책에 쓰인 과정을 거쳤다는 점에서 만족스러웠습니다.
이 경험을 바탕으로 고려사항을 적어보겠습니다.
원천 시스템 평가 : 주요 엔지니어링 고려 사항
- 데이터 원천의 본직적인 특징은 무엇인가? 애플리케이션인가? IOT 스웜인가?
- 애플리케이션
- 원천 시스템에서 데이터는 어떻게 유지되는가? 데이터는 장기간 보존되는가? 아니면 일시적이고 빠르게 삭제 되는가?
- 원천 데이터는 약 10일간 서버에 파일로 보존
- 데이터는 어느 정도의 속도로 생성되는가? 초당 몇 개의 이벤트가 발생하는가? 시간 당 몇 기가바이트인가?
- 초당 약 2000개, 많은 시간대 기준 약 2300개
- 가장 많은 이벤트 발생 기준 시간 당 약 6기가바이트
- 출력 데이터에서 어느 정도의 일관성을 기대 할 수 있는가? 출력 데이터에 대한 품질 검사를 실행 할 때 예상치 못한 출력값이나 잘못 된 데이터 포맷 등 불일치가 얼마나 자주 발생하는가?
- 데이터 웨어하우스의 사용으로 일관적인 형식으로 변환
- 명확히 포맷이 다른 데이터의 경우 변환 중 무시
- 도메인 범위를 벗어난 데이터의 경우 일부 수집과정에 포함 ( 힌두력 기준 날짜, 데이터 구분 기준이 되는 ID에 NULL이 포함 된 경우 )
- 에러는 얼마나 자주 발생하는가?
- 직접적으로 알 수 없음
- 프로세스 자체의 에러보다 서버 안전성에 가까운 이슈
- 데이터에 중복이 포함되지 않는가?
- tsv 파일을 임시 테이블에 두고 본 테이블로 마이그레이션하는 방식을 사용함으로써 중복을 완전제거
- 일부 데이터 값이 동시에 생성되는 다른 메시지보다 훨씬 늦게 도착 할 수 있는가?
- 메시지 브로커를 활용하지 않았으며, 분석 과정에서 이벤트의 순서가 중요 포인트가 아니였음
- 수집된 데이터의 스키마는 무엇인가? 데이터 엔지니어가 데이터를 완전히 파악하려면 여러 테이블 또는 여러 시스템에 거쳐 조인을 수행해야하나?
- 스키마는 비공개
- 컬럼 명을 여러 정보를 받을 수 있는 임시 명으로 구축하여 조인이 불필요
- Impala와 hue로 이어지는 쿼리 과정을 사용했기 때문에 데이터 파악에 용이
- 스키마가 변경되면 어떻게 대처하고 다운스트림 이해관계자에게 전달 할 수 있는가?
- 스키마 변경 전 별도 회의 및 공지를 통해 전달
- 원천 시스템에서 데이터를 얼마나 자주 가져와야 하는가?
- 데이터 이해관계자의 니즈는 1일/1시간 단위의 배치를 원했기 때문에 1시간 단위로 동작
- 상태가 있는 시스템, 정기적인 스냅숏이 지원되었는가?
- 해당 프로젝트에서는 불필요, 대신 유저의 상태를 파악하는 데이터 마트는 1일 단위로 배치처리
- 다운스트림 사용을 위한 데이터를 전송하는 매체는?
- RDB
- 데이터 원천에서의 데이터 조회가 성능에 영향을 미치는가?
- 별도의 서버로 구축되어 있었으므로, 시스템 상의 성능에 영향을 미치지 않음
- 원천 시스템에 업스트림 데이터 의존 관계
- nginx의 access.log를 사용, 즉 사용자 기기에서의 GET Request 정보를 사용했으므로 웹서버가 의존관계
- 데이터 품질 검사가 실시되는가?
- 되지 않음
2. 데이터 저장
데이터는 활용하기 위해 저장 할 공간이 필요합니다.
이 부분에서는 어떤 데이터를 저장하는지와 사용하는 용도에 따라 적절한 스토리지에 저장하는지가 중요 할 것 같습니다.
대부분의 경우 원천 데이터를 그대로 저장하지 않고, 원천 데이터를 수집하여 용도에 맞도록 변환 한 뒤에 저장합니다. 즉 어떤 목적을 위해 수집하는지에 따라 저장되는 데이터가 달라지고, 그 과정에서 변환 과정과 원천 데이터가 달라집니다.
추가적으로 사용하는 용도에 따라 적절한 스토리지가 다를 수 있습니다. 예를 들면 로그인 서비스에 사용되는 데이터의 경우에는 트랜잭션이 완벽하게 지원되는 데이터베이스를 사용하는게 옳을 수 있고, 유연한 스키마를 원하면 NoSQL을 사용 할 수 있습니다. 대량의 데이터를 저장하는데 고정적인 스키마가 자주 사용된다면 데이터 웨어하우스를 사용 할 수 있고, 가능한 원천 데이터와 유사한 형식을 통째로 저장하려면 데이터 레이크를 사용 할 수 있습니다.
저는 아직 이러한 저장 스토리지 및 서비스 기준에서의 확장을 경험하지 못했지만, 제가 활용했던 HDFS 환경과 Impala를 이용한 데이터 웨어하우스를 이용하여 이전 항목과 같이 고려사항을 정리해보겠습니다.
스토리지 시스템 평가 : 주요 엔지니어링 고려 사항
다음은 데이터 웨어하우스, 데이터 레이크하우스, 데이터베이스 또는 객체 스토리지 등 스토리지 시스템을 선택 할 때 확인 할 핵심 엔지니어링 질문이라고 합니다.
- 이 스토리지 솔류션은 아키텍처에서 요구하는 쓰기 및 읽기 속도와 잘 맞는가?
- N 개의 데이터 서버를 구축하여 분석을 위한 충분한 쿼리 분산 처리 성능을 보유
- HDFS 또한 여유로운 크기로 구축 및 파티션 단위로 쪼개어 WebHDFS로 입력하면서 쓰기 속도도 안정적
- 스토리지 기술 방식을 인지하는가? 최적으로 활용하는가? 부자연스러운 행동을 하는가?
- HDFS에 대한 기술적인 부분은 정확히 인지, 하지만 Impala의 경우 쿼리 플랜등에 대해 명확한 지식은 부족
- 병렬처리를 위해 파일 전송 전 버퍼를 쪼개어서 설정 된 블록의 크기보다 작을 가능성이 높았으며, 입력 시간이 1시간이라 더 작게 쪼개어질 가능성이 높았으나 파티션을 모아서 본 테이블에 일괄 이전하는 배치를 활용하여 데이터 블록의 최적화하는 방향으로 해결
- 스토리지 시스템은 향후 예상되는 확장을 처리할 수 있는가? 총 스토리지 속도 및 볼륨 등 모든 용량 제한을 포함
- 분산 시스템으로 IDC내 서버의 증설로 문제 해결 가능
- 필요 시 클라우드 서비스 중 장기간 접근이 적고 저렴한 스토리지에 저장하는 방식으로도 활용 가능
- 다운스트림 사용자가 프로세스가 필요한 서비스 수준 협약에 따라 데이터를 취득 할 수 있는가?
- 사내 의사결정자 및 분석가의 니즈에 충족
- 스키마 진화, 데이터 흐름, 데이터 계보 등 메타데이터를 캡처하는가?
- 하지 않음, 데이터 카탈로그의 경우 datahub을 활용하고자 했지만, 제대로 사용하지 못함
- 순수 스토리지 솔루션인가? 아니면 클라우드와 같은 서비스인가
- IDC의 서버를 활용하여 직접 구축한 순수 스토리지 솔루션
- 스키마에 구애받지 않는가? 유연한 스키마인가? 강제성이 있는 스키마를 적용하는가?
- Impala 데이터 웨어하우스의 특성 상 테이블의 데이터와 형식이 정해져있기 때문에 스키마에 강제성이 있다고 판단
- 데이터 거버넌스를 위해 마스터 데이터, 골든 레코드 데이터 품질 및 데이터 계보를 어떻게 추적하는가?
- 적극적으로 추적하지 않음, 계정에 따라 동작을 확인하는 정도
- 법령 준수 및 데이터 주권에 어떻게 대처하는가? 특정 지리적 위치에는 데이터를 저장하고 다른 위치에는 저장하지 않을 수 있는가?
- 개인 정보에 관련하여 데이터를 수집하는 원천 데이터 수집 단계에서 처리되어 있음
데이터 접근 빈도 이해
모든 데이터가 자주 액세스되지 않고, 데이터에 따라 다릅니다. 온도 개념을 넣어서 자주 접근하는 데이터의 경우 핫 데이터라고 부르고 자주 접근하지 않는 데이터는 콜드 데이터라고 부르며, 서로 특징에 맞는 스토리지에 적재하는 것이 중요합니다.
예를 들면 콜드 데이터의 경우에는 자주 접근하지 않는, 스토리지 비용은 저렴하지만 접근 비용이 큰 스토리지에 저장하면 좋을 수 있고, 핫 데이터는 스토리지 비용은 비싸지만 접근 비용이 저렴한 스토리지가 좋을 수 있습니다.
3. 데이터 수집
저자의 경험 상 원천 시스템과 데이터 수집은 데이터 엔지니어링 수명 주기에서 가장 큰 병목 현상 을 나타낸다고 합니다. 원천 시스템은 보통 직접 관리 할 수 없으며, 임의로 응답 하지 않거나, 품질이 낮은 데이터를 제공 할 수 있습니다. 또는 데이터 수집 서비스가 동작하지 않을 수 있습니다.
수집 단계에서의 주요 엔지니어링 고려 사항
- 수집 중인 데이터의 사용 사례는 무엇인가? 같은 데이터셋의 여러 버전을 생성하는 대신 이 데이터를 재사용 할 수 있는가?
- 대외비 가능성이 있음
- 시스템이 이 데이터를 안정적으로 생성하고 수집하고 있는가? 필요 할 때 해당 데이터를 사용 할 수 있는가?
- 로드 밸런싱을 활용하여 안전성 확보
- 필요할 때의 기준에 따라 다를 수 있지만, 실시간성이 아닌 1시간 단위의 배치이므로 이전의 데이터는 활용 가능
- 수집 후 데이터 목적지는 어디인가?
- HDFS Cluster 내 Impala의 적절한 파티션 위치
- 데이터에 얼마나 자주 접근해야 하는가?
- 업무 시간 내 분석을 위한 접근 및 업무 시간 외 배치 파이프라인에 활용
- 데이터는 보통 어느 정도의 용량으로 도착하는가?
- 파티션 마다 다르지만, 블록 크기에 비해서는 적은 편
- 데이터 형식은 무엇인가? 다운스트림 스토리지 및 변환 시스템에서 이 형식을 처리 할 수 있는가?
- 수집 자체는 tsv, 이후 parquet으로 마이그레이션
- 원천 데이터는 다운스트림에서 즉시 사용 할 수 있는 양호한 상태인가? 그렇다면 얼마나 오래 사용 할 수 있으며, 사용 할 수 없게 되는 요인은?
- 이론 상 스토리지 내 파일에 대한 별도의 작업이 없으면 사용 가능
- 데이터가 스트리밍 소스에서 전송 된 경우, 목적지에 도달하기 전에 데이터를 변환해야 하는가? 데이터 스트림 자체 내에서 변환되는 형태의 변환이 적절할까?
- 원천 데이터를 파싱하여 스키마에 맞도록 변화하는 작업을 수행하기 때문에 변환이 필요
배치와 스트림 수집의 주요 고려 사항
배치 처리와 스트리밍 처리의 경우에는 어느정도 트레이드 오프관계를 가지기 때문에 적절한 선택이 필요합니다.
- 데이터를 실시간으로 수집하면 다운스트림 스토리지 시스템이 데이터 흐름 속도를 처리 할 수 있는가?
- 밀리초 단위의 실시간 데이터 수집이 필요한가? 아니면 매분마다 데이터를 축적하고 수집하는 마이크로 배치 접근이 효과적일까?
- 스트림 수집의 사례로는 무엇이 있을까? 어떤 이점이 있는가? 어떤점이 배치 방식에 비해 개선 될 수 있는가?
- 스트림 수집이 배치처리보다 더 많은 비용을 소비하는가?
- 스트림 서비스가 안정적이고 다중화 되어 있나?
- 사용 사례에 적합한 도구가 무엇인가? 누가 관리의 역할을 맡는가? 비용과 트레이드오프는 무엇인가?
- ML 모델을 배포했을 때 온라인 예측 및 지속적인 훈련으로 얻을 수 있는 이점은 무엇인가?
- 실제 운영 인스턴스에서 데이터를 가져오는가? 그러면 원천 시스템에 대한 수집 프로세스의 영향은 얼마나 되는가?