이 글은 스터디 활동에서 진행하는 견고한 데이터 엔지니어링 정리입니다.
Fundamentals of Data Engineering
Data engineering has grown rapidly in the past decade, leaving many software engineers, data scientists, and analysts looking for a comprehensive view of this practice. With this practical book, you'll … - Selection from Fundamentals of Data Engineering
www.oreilly.com
이 글에서는 데이터를 수집하는 방식과 함께 작업하는 이해관계자, 데이터 수집에 있어서 드러나지 않는 요소를 작성하였습니다.
7.5 데이터 수집 방법
7.5.1 직접 데이터베이스 연결
직접 데이터베이스 연결을 통해 데이터베이스에서 데이터를 쿼리하고 읽어서 수집할 수 있다. 일반적으로 이러한 연결은 ODBC 또는 JDBC를 사용하여 이루어진다. ODBC와 JDBC는 데이터베이스에 연결해 데이터를 수집하는 데 널리 사용되는 표준 인터페이스다. ODBC는 클라이언트가 데이터베이스에 접근할 수 있도록 드라이버를 통해 명령을 전달하며, JDBC는 Java 환경에서 데이터베이스와 통신한다.
ODBC와 JDBC는 모두 관계형 데이터베이스와의 직접 연결을 지원하며, 병렬 연결을 통해 수집 속도를 높일 수 있다. 그러나 이러한 병렬 연결은 원천 데이터베이스에 부하를 줄 수 있기 때문에 주의가 필요하다.
7.5.2 변경 데이터 캡쳐
변경 데이터 캡처(CDC)는 원천 데이터베이스 시스템에서 변경 사항을 수집하는 프로세스이다. 예를 들어, 원천 PostgreSQL 시스템에서 애플리케이션을 지원하거나 분석을 위해 테이블 변경 사항을 주기적으로 또는 지속적으로 수집할 수 있다.
배치 지향 CDC
배치 지향 CDC는 특정 시간 간격마다 데이터베이스에서 변경된 행을 조회해 대상 시스템에 반영하는 방식이다. updated_at 필드를 사용해 변경된 데이터를 수집할 수 있지만, 모든 변동 내역을 추적하기는 어렵다. 예를 들어, 은행 계좌 잔액이 여러 번 변경되어도 최종 잔액만 기록된다. 이를 완화하기 위해 삽입 전용 스키마를 사용하여 각 거래를 새 레코드로 기록하는 방식이 필요하다.
연속 CDC
연속 CDC는 거의 실시간으로 데이터 변경을 추적해 데이터베이스 복제와 실시간 스트리밍 분석을 지원한다. 데이터베이스의 쓰기 작업을 이벤트로 처리하며, PostgreSQL의 로그 기반 CDC가 대표적이다. 이 방식은 데이터베이스 로그를 읽어 Kafka 등의 플랫폼에 전송한다. 또한 클라우드 데이터베이스는 변경 시 서버리스 함수를 트리거하거나 이벤트 스트림에 쓰도록 설정할 수 있어 관리 부담을 줄인다.
CDC 및 데이터베이스 복제
CDC는 비동기적으로 이벤트를 버퍼링하여 데이터베이스 간 복제에 활용될 수 있다. 동기 복제는 기본 데이터베이스와 복제본을 밀접하게 결합해 동기화하며 - 이때 같은 유형이어야함-, 복제본이 읽기 작업을 처리해 성능을 분산시킬 수 있다. 읽기 복제본은 대규모 스캔에 유용하며, 장애 발생 시에도 데이터 손실 없이 자동 전환할 수 있다. 반면 비동기 복제는 다양한 대상에 이벤트를 전송할 수 있는 유연한 구조를 제공하여 분석 목적에 적합하다.
CDC 고려 사항
CDC는 메모리, 디스크, CPU, 네트워크 대역폭 등 데이터베이스 자원을 소모하기 때문에 비용이 발생한다. 프로덕션 시스템에서 CDC를 적용하기 전, 충분한 테스트와 협력이 필요하다. 배치 CDC는 큰 쿼리로 인해 과부하가 발생할 수 있어, 업무 시간 외나 읽기 복제본을 활용해 기본 데이터베이스의 부담을 줄이는 것이 바람직하다.
7.5.3 API
API는 데이터 엔지니어링에서 중요한 외부 데이터 원천이지만, 통합 작업에 많은 시간이 소요될 수 있다. 이를 간소화하는 주요 트렌드는 API 클라이언트 라이브러리, 데이터 커넥터 플랫폼, 데이터 공유 플랫폼의 등장이다.
특히, 관리형 API 서비스는 비용이 들 수 있지만 커넥터 개발과 유지 관리를 줄여 더 중요한 작업에 집중할 수 있게 해 준다. API 연결이 필요할 경우 기존 프레임워크를 최대한 활용하고, DevOps 모범 사례와 오케스트레이션 프레임워크를 통해 관리 효율성을 높이는 것이 권장된다.
7.5.4메시지 큐 및 이벤트 스트리밍 플랫폼
메시지 큐와 이벤트 스트리밍 플랫폼은 웹 애플리케이션과 IoT 기기에서 실시간 데이터를 수집하는 핵심 방식이다. 메시지는 개별 이벤트로 처리되고 일시적이며, 소비 후 큐에서 제거된다. 반면 스트림은 정렬된 로그로 이벤트를 수집해 다양한 소비자에게 장기적으로 제공할 수 있다.
실시간 데이터 파이프라인의 경우 짧은 지연 시간을 위해 파티션, 메모리, CPU 등의 자원 관리가 중요하며, 자동 확장 기능을 통해 효율적인 운영이 필요하다. 관리형 서비스를 활용해 스트리밍 플랫폼의 운영 부담을 줄일 수 있다.
7.5.5 관리형 데이터 커넥터
관리형 데이터 커넥터(ex - AWS Glue)는 데이터베이스나 API에 데이터를 연결하기 위해 복잡한 코드를 작성할 필요 없이, 사전 구축된 표준 커넥터를 제공하는 서비스이다. 사용자는 원천과 대상을 설정하고, 수집 방식을 지정하며, 권한과 동기화 빈도를 구성할 수 있다.
데이터 동기화는 서비스 공급자가 관리하고, 문제가 발생하면 오류 정보를 포함한 알림을 받게 된다. 관리형 커넥터 플랫폼은 수백 개의 커넥터를 제공하며, 사용자 정의 커넥터도 쉽게 생성 가능해 데이터 통합 작업을 효율적으로 아웃소싱할 수 있다.
7.5.6 개체 스토리지를 사용한 데이터 이동
개체 스토리지는 퍼블릭 클라우드에서 대용량 데이터를 저장하고 전송하기 위한 멀티테넌트 시스템으로, 데이터 레이크 이동, 팀 간 및 조직 간 데이터 공유에 적합하다. 서명된 URL을 통해 제한된 시간 동안 접근 권한을 제공할 수 있어 보안이 강화된다. 최신 보안 표준을 따르고, 확장성과 안정성이 뛰어나며, 다양한 유형과 크기의 파일 전송을 지원해 데이터 교환의 최적화된 방법으로 활용된다.
7.5.7 EDI - 전자 문서 교환
전자 데이터 교환(EDI)은 전통적 데이터 전송 방식을 지칭하며, 이메일이나 플래시 드라이브 등으로 데이터를 주고받는 방식을 포함한다. 일부 구형 IT 시스템과 절차의 한계로 인해 최신 데이터 전송 방식을 지원하지 못하는 경우가 많다.
이를 개선하기 위해, 예를 들어 클라우드 기반 이메일 서버로 수신된 파일을 자동으로 회사의 개체 스토리지에 저장하고, 조정 프로세스를 통해 데이터 수집과 처리를 자동화할 수 있다. 이는 수동 다운로드와 업로드보다 효율적이고 안정적인 접근이다.
7.5.8 데이터베이스와 파일 익스포트
엔지니어는 원천 데이터베이스에서 파일을 내보낼 때 발생하는 대규모 데이터 스캔이 시스템 성능에 미칠 영향을 이해해야 한다. 내보내기 쿼리는 키 범위나 파티션별로 나누어 실행해 부하를 줄이거나, 읽기 복제본을 사용해 성능을 보장할 수 있다. 특히, 내보내기 빈도가 높고 원천 시스템에 부하가 큰 경우, 읽기 복제본 활용이 효과적이다.
7.5.9 공통파일 형식의 실질적 문제
엔지니어는 파일 내보내기 형식을 선택할 때 CSV의 한계를 인지해야 한다. CSV는 구분 기호 (delimiter)와 스키마 정보가 없으며, 중첩 구조를 직접 지원하지 않아 오류 발생이 잦다. 대신 Parquet, Avro, Arrow, ORC, JSON 같은 형식은 스키마 정보가 포함되고 중첩된 구조를 처리할 수 있어 데이터의 정확성과 성능 면에서 더 유리하다.
7.5.10 셸
셸은 데이터 수집을 위한 명령을 실행할 수 있는 인터페이스로, 다양한 소프트웨어 도구의 워크플로를 스크립팅하는 데 활용된다. 셸 스크립트는 데이터베이스에서 데이터를 읽고, 다른 형식으로 변환해 개체 스토리지에 업로드하거나, 대상 데이터베이스의 수집 프로세스를 트리거하는 등 광범위하게 사용된다. 클라우드 환경에서는 AWS CLI 같은 강력한 CLI 도구를 통해 복잡한 수집 작업을 자동화할 수 있다.
7.5.11 SSH
SSH는 데이터 수집에 직접 사용되는 전략이 아닌, 다른 수집 전략과 함께 사용하는 프로토콜이다. SSH는 SCP와 함께 파일 전송에 쓰이며, SSH 터널을 통해 데이터베이스와 안전하게 격리된 연결을 설정하는 데도 활용된다. 애플리케이션 데이터베이스는 인터넷에 직접 노출되어서는 안 되며, 대신 중간 호스트 통해 접근할 수 있다. 이 호스트는 제한된 IP와 포트에서만 접근 가능하며, 원격 머신은 SSH 터널로 호스트에 연결해 데이터베이스에 접근할 수 있다.
7.5.12 SFTP와 SCP
데이터 엔지니어는 보안 파일 전송에 익숙해져야 하며, SFTP(시큐어 FTP)와 SCP(시큐어 카피) 같은 프로토콜이 대표적이다. SFTP는 많은 기업이 데이터를 교환할 때 여전히 사용하는 현실적인 방식으로, 파트너 기업 간 협력 시에도 사용된다. 보안을 위해 철저한 분석이 필요하다. SCP는 SSH 연결을 통해 파일을 안전하게 전송하는 프로토콜로, 추가적인 네트워크 액세스 제어(심층 방어)를 통해 보안을 강화할 수 있다.
7.5.13 웹훅 - webhook
웹훅은 "역 API"로 불리며, 데이터 제공자가 요청하는 방식으로 API 호출을 수신하는 방식이다. 웹훅에서는 데이터 소비자가 API 엔드포인트를 제공하며, 제공자가 이 엔드포인트로 데이터를 전송한다. 웹훅 아키텍처는 종종 취약하고 관리하기 어렵지만, AWS와 같은 기성 도구를 통해 보다 견고한 구조를 만들 수 있다.
예를 들어, 서버리스 함수 프레임워크 - Lambda로 이벤트를 수신하고 이벤트 스트리밍 플렛폼 - Kinesis로 메시지를 버퍼링하며, 스트림 처리 프레임워크 - Flink로 실시간 분석, 객체 스토리지 - S3에 장기 저장을 구현하는 방식이다. 이 구조는 수집뿐만 아니라 저장 및 처리와도 밀접하게 연관된 데이터 엔지니어링 라이프사이클 전반을 고려해야 한다는 점을 강조한다.
7.5.14 웹 인터페이스
웹 인터페이스를 통한 데이터 액세스는 여전히 데이터 엔지니어링에서 현실적으로 사용되는 방법이다. 많은 SaaS 플랫폼은 모든 데이터를 API나 파일 드롭 같은 자동화된 인터페이스로 제공하지 않기 때문에, 수동으로 웹 인터페이스에 접속해 보고서를 생성하고 로컬에 파일을 다운로드해야 하는 경우가 많다. 이 방식은 사람이 보고서 실행을 잊거나 기기가 꺼지는 등의 문제가 발생할 수 있다. 가능하다면 자동화된 데이터 접근이 가능한 도구와 워크플로를 사용하는 것이 효율적이다.
7.5.15 웹 스크레이핑
웹 스크래핑은 웹 페이지의 HTML 요소에서 데이터를 추출하는 작업으로, 전자상거래의 가격 정보 수집이나 뉴스 수집에 활용된다. 웹 스크래핑은 데이터 엔지니어링에서 접할 수 있는 중요한 기술이지만, 윤리적·법적 고려사항이 중요하다. 먼저 타사 데이터를 활용할 수 있는지 검토하고, 웹 크롤링으로 서비스에 과부하를 주지 않도록 주의해야 한다.
7.5.16 데이터 마이그레이션 전송 어플라이언스
대규모 데이터(100TB 이상)를 인터넷을 통해 전송하는 것은 시간과 비용이 많이 들기 때문에, 물리적 장치를 활용한 전송이 더 효율적일 수 있다. 클라우드 공급업체들은 전송 어플라이언스(Snowball, Snowmobile 등)를 제공하여 대용량 데이터를 하드 드라이브 형태로 이동시킬 수 있다.
예를 들어, AWS의 Snowmobile은 페타바이트 이상의 데이터도 물리적으로 전송할 수 있는 트럭 기반 솔루션이다. 이 방식은 클라우드 간 또는 하이브리드 클라우드 설정에서도 비용을 절감하는 대안이 될 수 있으며, 특히 데이터 이탈 수수료가 높은 경우 유리하다. 단, 전송 어플라이언스는 일회성 데이터 이동에 적합하며, 지속적인 데이터 이동은 주기적 일괄 처리나 스트리밍 방식이 더 적합하다.
7.5.17 데이터 공유
데이터 공유는 데이터 소비를 위한 일반적인 옵션으로, 데이터 제공자가 타사 구독자에게 읽기 전용으로 데이터 세트를 제공하여 유료 또는 무료로 사용할 수 있게 한다. 이 방식은 데이터 세트를 물리적으로 소유하지 않으며, 제공자가 액세스 권한을 제거하면 사용할 수 없다. 주요 클라우드 플랫폼은 데이터 공유 기능을 통해 다양한 공급자의 데이터를 공유·소비할 수 있도록 하며, 일부는 데이터를 판매할 수 있는 데이터 마켓플레이스를 제공해 조직 간 데이터 거래를 촉진한다.
7.6 함께일할 담당자
데이터 수집은 여러 조직 경계에 걸쳐 있으며, 데이터 엔지니어는 이를 개발하고 관리할 때 업스트림의 데이터 생산자와 다운스트림의 데이터 소비자 모두와 협력해야 한다.
7.6.1 업스트림 이해관계자
데이터 생성자(주로 소프트웨어 엔지니어)와 데이터를 처리 및 준비하는 데이터 엔지니어 사이에는 조직적 단절이 자주 발생한다. 소프트웨어 엔지니어는 보통 데이터 엔지니어에 대해 일반적으로 이해 관계자가 아니라 애플리케이션에서 배출되는 데이터의 하위 소비자로 여긴다.
데이터 품질 향상을 위해서는 이들을 데이터 엔지니어링의 이해 관계자로 초대하는 것이 중요하다. 두 팀 간의 커뮤니케이션을 강화하여 소프트웨어 엔지니어가 다운스트림에 유용한 데이터를 파악하고 데이터 변경 사항을 공유할 수 있도록 한다.
7.6.2 다운스트림 관계자
데이터 수집의 궁극적인 고객은 데이터 과학자나 분석가뿐 아니라 마케팅 디렉터, 공급망 부사장, CEO 같은 더 광범위한 비즈니스 이해 관계자다. 데이터 엔지니어가 고도화된 기술 프로젝트에 집중하는 동안, 기본 수집 자동화가 마케팅 부서 등 회사 핵심 부서에 큰 가치를 제공할 수 있다. 이를 통해 더 많은 예산과 장기적 기회를 확보할 수 있다.
또한, 데이터 엔지니어는 임원과의 협업을 통해 데이터 생산자와 데이터 엔지니어 간 장벽을 낮추고 통합된 데이터 중심 문화를 구축하는 데 기여할 수 있다. 주기적이고 솔직한 소통을 통해 데이터 수집의 가치를 비즈니스에 전달하는 것이 중요하다.
7.7 드러나지 않는 요소
거의 모든 드러나지 않는 요소가 수집 단계에 영향을 미치지만 여기서는 중요한 부분만을 강조함.
7.7.1 보안
데이터 전송은 보안 취약성을 초래할 수 있으며, 이를 방지하려면 데이터의 위치와 전송 경로를 고려해야 한다. VPC 내에서 이동하는 데이터는 보안 엔드포인트를 통해 전송하고 VPC 경계를 벗어나지 않도록 한다. 클라우드와 온프레미스 간 전송 시에는 VPN이나 전용 비공개 연결을 사용하는 것이 좋으며, 특히 공용 인터넷을 통과하는 경우 전송 암호화를 통해 데이터를 보호하는 것이 필수적이다.
7.7.2 데이터 관리
데이터 관리는 데이터 수집에서 시작되며, 이는 계보와 데이터 카탈로그 구축의 기초가 된다. 이 초기 단계에서 데이터 엔지니어는 스키마 변경, 데이터 윤리, 개인정보 보호, 규정 준수와 같은 중요한 요소들을 고려해야 한다.
스키마 변경
스키마 변경은 데이터 관리에서 여전히 해결하기 어려운 문제로, 전통적 접근 방식은 신중한 검토 절차를 거쳐 민첩성을 저해할 수 있다. 반면, 자동화된 방식으로 소스 스키마 변경이 발생할 때 대상 테이블을 즉시 새 스키마로 갱신하는 방법도 있지만, 이는 다운스트림 파이프라인에 예기치 않은 충격을 줄 수 있다.
데이터 윤리, 개인정보 보호, 컴플라이언스
데이터 엔지니어는 민감한 데이터를 암호화하기 전에 실제로 해당 데이터가 필요한지부터 고민해야 한다. 민감한 데이터가 불필요하면 수집하지 않거나, 저장 전 삭제하는 것이 더 안전하다. 민감한 데이터를 다루어야 한다면, 신원을 추적하지 않고 분석 가능하도록 토큰화나 해싱을 고려할 수 있다.
암호화와 토큰화는 종종 개인정보 보호에 대해 만능처럼 여겨지지만, 실제 문제는 데이터 접근 권한 관리다. 데이터 액세스 시나리오를 평가하고 무분별한 해싱이 실제로 개인정보 보호에 도움이 되는지 신중히 판단해야 한다.
7.7.3 데이터옵스
신뢰할 수 있는 데이터 파이프라인은 데이터 엔지니어링의 핵심이다. 장애 발생 시 데이터 웨어하우스와 데이터 레이크의 데이터 업데이트가 중단되며, 데이터 과학자와 분석가는 최신 데이터를 사용하지 못해 기업에 심각한 영향을 미친다. 이를 방지하기 위해서는 파이프라인 모니터링이 필수적이며, 특히 데이터 수집 단계에서 모니터링을 강화해야 한다.
서드파티(타사) 서비스의 중단 대비 계획도 필요하며, 장애 발생 시 다른 서버나 지역으로 장애조치 설정을 고려한다. 내부 데이터 수집 프로세스에는 테스트와 자동화된 배포가 필수적이며, 문제 발생 시 롤백 가능한 시스템도 갖추어야 한다.
데이터 품질 테스트
잘못된 데이터는 기업에 치명적일 수 있으며, 잘못된 데이터로 인한 의사 결정은 데이터가 없는 것보다 더 해롭다 (데이터 재앙). 데이터는 예고 없이 변화하는 특성이 있어 데이터 회귀 문제를 일으키기 쉽다. 이는 DevOps와 달리 DataOps에서 더 미묘한 통계적 왜곡으로 나타나며, 기업의 지표를 왜곡해 의사 결정에 부정적 영향을 줄 수 있다.
데이터 품질을 보장하려면, 소프트웨어 엔지니어와 협력해 데이터 소스에서 발생할 수 있는 품질 문제를 예방하는 것이 중요하다. 로그, null 체크, 예외 처리와 같은 기본 소프트웨어 엔지니어링 원칙을 적용해 데이터 문제를 사전에 처리할 수 있다.
7.7.4 오케스트레이션
복잡한 데이터 파이프라인을 위해서는 개별 작업을 넘어 전체 작업 그래프를 스케줄링하는 진정한 조정 - 오케스트레이션이 필요하다. 오케스트레이션은 각 수집 작업의 시점을 관리하고, 수집 완료 후 자동으로 다운스트림 처리 및 변환 단계가 진행될 수 있도록 조정한다. 이를 통해 전체 파이프라인이 순차적으로 이어지며 안정적으로 운영될 수 있다.
7.7.5 소프트웨어 엔지니어링
데이터 엔지니어링 라이프사이클의 수집 단계는 외부 시스템과의 상호작용이 많고 엔지니어링 요구가 높아 맞춤형 배관 작업이 필요하다. 복잡한 수집 작업은 종종 Kafka나 Pulsar와 같은 오픈 소스 프레임워크를 활용하며, 대규모 기술 기업은 자체 수집 솔루션을 운영하기도 한다. 최근에는 여러 관리형 데이터 커넥터가 수집 프로세스를 크게 단순화했다.
문제
다음 중 데이터 보안을 위해 권장되지 않는 방법은?
a) 데이터 전송 시 암호화
b) 공용 인터넷을 통한 암호화되지 않은 데이터 전송
c) VPN이나 전용 연결 사용
d) VPC 내 보안 엔드포인트 사용
답 : b
데이터 수집 단계에서 관리형 데이터 커넥터의 주요 이점으로 옳지 않은 것은 무엇인가요?
a) 수집 프로세스를 간소화함
b) 복잡한 코드를 작성할 필요를 줄임
c) 데이터 품질을 완전히 보장함
d) 다양한 데이터 소스와의 연결을 지원함
답 : c
'기술 도서 리뷰' 카테고리의 다른 글
| 견고한 데이터 엔지니어링 Chapter 9.5~ (0) | 2024.11.25 |
|---|---|
| 견고한 데이터 엔지니어링 Chapter 5.2 원천 시스템의 실절적인 세부 사항 (4) | 2024.10.28 |
| 견고한 데이터 엔지니어링 Chapter 5.1 - 원천 시스템에서의 데이터 생성 (0) | 2024.10.27 |
| 견고한 데이터 엔지니어링 Chapter 2.2 - 데이터 엔지니어링 수명주기 (2) | 2024.09.30 |
| 견고한 데이터 엔지니어링 Chapter 2.1 - 데이터 엔지니어링 수명주기 (0) | 2024.09.23 |
