[견고한 데이터엔지니어링] 5장. 원천 시스템에서의 데이터 생성 | LIM

데이터 원천 시스템

데이터 원천 시스템에는 파일과 비정형 데이터, 애플리케이션에서 수집되는 데이터 등이 있다. 

 

애플리케이션 데이터베이스(OLTP 시스템)

일반적으로 애플리케이션 데이터베이스는 개별 데이터 레코드를 높은 속도로 읽고 쓰는 온라인 트랜잭션 처리 시스템이다.

OLTP 시스템은 종종 트랜잭션 데이터베이스라고 불리지만, 해당 시스템이 반드시 atomic transaction 을 지원한다는 의미는 아니다. 

 

OLTP 데이터베이스는 보통 짧은 지연시간과 높은 동시성을 지원한다. 도큐먼트 기반 데이터베이스 클러스트는 잠재적인 불일치를 감수하고라도 훨씬 더 높은 도큐먼트 커밋률을 관리할 수 있다. 

 

OLTP 데이터베이스는 동시성 처리가 뛰어나 애플리케이션 백엔드로 잘 작동하는 반면, 단일 쿼리로 방대한 양의 데이터를 검색해야 하는 대규모 분석 기반 사용 사례에는 적합하지 않다.

 

위에서 말한 atomic transaction 에 좀 더 알아보자.

 

ACID

원자적 트랜잭션(atomic transaction) 지원은 ACID로 알려진 데이터베이스의 중요한 특성 중 하나다. 

이 부분에 대해서는 여기에 정리해두었다. 

https://amazelimi.tistory.com/entry/MySQL-Transaction%EC%9D%98-%EB%AA%A8%EB%93%A0-%EA%B2%83

[MySQL] Transaction의 모든 것 | LIM

 

🤔 그렇다면, OLTP 에서는 데이터를 분석할 수 없나?

아니다. 소규모 기업에서는 OLTP 에 직접 분석을 실행하는 경우가 많다. 이 패턴은 단기적으로는 효과적이지만 궁극적으로는 확장성이 떨어진다. 데이터 엔지니어는 운영 애플리케이션 성능을 저하하지 않으면서 분석 시스템과의 적절한 통합을 설정하기 위해 OLTP와 애플리케이션 백엔드의 내부 작동 방식을 이해해야 한다.

 

온라인 분석 처리 시스템(OLAP)

OLTP시스템과 달리 OLAP는 대규모 분석 쿼리를 실행하도록 구축되었으며 일반적으로 개별 레코드의 조회 처리에는 비효율적이다. OLAP의 온라인 부분은 시스템이 들어오는 쿼리를 지속해 수신 대기한다는 뜻으로, OLAP 시스템이 대화형 분석에 적합하다는 것을 의미한다. 데이터 웨어하우스는 ML 모델을 훈련하는데 사용되는 데이터를 제공할 수 있으며, 분석 시스템에서 파생된 데이터를 CRM, SaaS 플랫폼 또는 트랜잭션 애플리케이션과 같은 원천 시스템으로 다시 전송되는 역방향 ETL 워크플로를 OLAP 시스템이 제공할 수도 있다. 

 

 

입력전용

입력 전용 패턴은 데이터를 포함하는 테이블에서 이력을 직접 유지한다. 레코드를 갱신하는 대신, 새로운 레코드가 생성된 시점을 나타내는 타임스탬프와 함께 입력된다. 

 

🤔 이 패턴은 언제 사용되면 좋을까?

입력 전용 패턴은 데이터베이스 로그를 테이블 자체에 직접 유지하므로 애플리케이션 이력에 접근해야 할 때 특히 유용하다.

예를 들어 이 패턴은 고객 주소 이력을 제공하도록 설계된 뱅킹 애플리케이션에 적합하다.

 

하지만 단점으로는 각 변경 사항이 테이블에 입력되기 때문에 데이터가 자주 변경되는 경우에는 테이블이 상당히 커질 수 있기 때문에 테이블 크기를 적정하게 유지하기 위해 레코드 만료 일자 또는 레코드 버전의 최대 수에 따라 레코드를 삭제하면서 유지하는 방법이 있다. 

두 번째로는 현재 상태를 조회할 때 MAX(created_timestamp)를 실행하기 때문에 레코드 조회 시 추가 오버헤드가 발생한다는 점이다. 

만약 하나의 ID에 수백 또는 수천 개의 레코드가 있다면 이러한 조회 작업을 실행하는데 큰 비용이 들 수 있다. 

 

 

원천 시스템의 실질적인 세부 사항

이 장에서는 데이터베이스, API에 대해 좀 더 자세히 알아본다. 

 

데이터베이스

이 장을 읽을때는 다음과 같은 아이디어를 고려해서 읽으면 좋다.

 

💡 데이터베이스는 어떻게 데이터를 발견하고 검색을 수행할까?

💡 쿼리 옵티마이저를 사용하는가? 그 특징은 무엇인가?

💡수요에 따라 데이터베이스를 확장할 수 있는가? 수평확장인가 수직확장인가?

💡 데이터베이스에 가장 적합한 모델링 패턴(ex. 데이터 정규화 또는 와이드 테이블)은 무엇인가?

💡 데이터베이스에서 데이터를 쿼리, 생성, 갱신 및 삭제하는 방법은 무엇인가?

💡 데이터베이스가 완전한 일관성을 갖추고 있는가 아니면 완화된 일관성을 지원하는가?

 

 

관계형 데이터베이스 vs 도큐먼트 저장소

둘의 중요한 차이점 중 하나는 도큐먼트 저장소는 조인을 지원하지 않는다는 것이다.

즉, 데이터를 쉽게 정규화할 수 없으며 여러 테이블로 분할 할 수 없다. 따라서 대부분의 경우 동일한 데이터를 여러 컬렉션에 분산해 여러 도큐먼트에 저장해야 한다.

RDBMS	도큐먼트 데이터베이스
테이블	컬렉션
행	도큐먼트, 항목, 엔티티

도큐먼트 데이터베이스는 일반적으로 JSON 의 모든 유연성을 수용하며 스키마나 유형을 강제하지 않는데, 이는 축복이자 저주로 작용할 수 있다는 사실을 인지하자. 

개발자가 스키마의 진화를 관리하는데 주의를 기울이지 않으면 시간이 지남에 따라 데이터가 일관성 없이 비대해질 수 있다. 

 

도큐먼트 저장소에서 분석을 실행하려면 일반적으로 엔지니어가 풀 스캔을 실행해 컬렉션에서 모든 데이터를 추출하거나 CDC 전략을 사용해 이벤트를 대상 스트림으로 보내야 한다. 따라서 쿼리 속도를 높이기 위해 인덱스를 생성하는 것은 종종 유용하게 작용한다. 

 

NoSQL DB들

[와이드-컬럼]

와이드 컬럼 데이터베이스는 빠른 트랜잭션 속도와 매우 짧은 지연 시간으로 대량의 데이터를 저장하는데 최적화되어 있다. 

매우 빠른 쓰기 속도와 방대한 양의 데이터로 확장될 수 있다. 이러한 특성은 전자 상거래, 핀테크, 애드테크, IoT, 실시간 개인화 애플리케이션 등에서 높은 인기를 끄는데 일조했다. 

 

대표적으로 Cassandra가 있다. Cassandra는 분산형이기 때문에 고가용성을 지원한다.

 

[그래프 데이터베이스]

수학적 그래프 구조(노드와 에지의 집합)로 데이터를 명시적으로 저장한다. 그래프 데이터베이스는 소셜 네트워크 작업 등에 최적화되어있다. 사용자들 간의 어떻게 연결이 되어 있는 지를 그래프 데이터베이스로 쉽게 확인이 가능하다. 따라서 요소 간의 복잡한 순회를 이해해야 할 때 그래프 데이터베이스가 적합하다고 할 수 있다. 

 

그 외에도 검색 데이터베이스로 유명한 엘라스틱서치, 아파치 솔라, 아파치 루씬 등이 있고, 시계열 데이터베이스로 유명한 아파치 드루이드가 있다. 시계열 데이터베이스는 데이터가 고속으로 빠르게 증가하는 분야에서 자주 사용된다. IoT, 이벤트 및 애플리케이션 로그, 애드테크, 핀테크 등 다양한 사용 사례에서 고소으로 증가하는 데이터 용량의 요구 사항을 해결한다. 이러한 워크로드는 쓰기 작업이 많은 편이며, 그 결과 시계열 데이터베이스는 메모리 버퍼링을 사용해 빠른 쓰기와 읽기를 지원하는 경우가 많다.

https://amazelimi.tistory.com/entry/Apache-Druid-%EC%A0%95%EC%9D%98%EC%99%80-%EC%9E%A5%EB%8B%A8%EC%A0%90-%EB%B0%8F-ES-%EC%99%80%EC%9D%98-%EB%B9%84%EA%B5%90-LIM

Apache Druid 정의와 장단점 및 ES 와의 비교 | LIM

 

API

[REST]

REST의 주요 아이디어 중 하나는 상호 작용이 무상태성(stateless)이라는 것이다. 리눅스 터미널 세션과 달리 작업 디렉터리와 같은 관련 상태 변수를 가진 세션의 개념이 없으며, 각 REST 호출은 독립적이다. 

 

[GraphQL]

REST API 의 대안으로 페이스북에서 만들었다. 애플리케이션 데이터의 쿼리 언어라고 보면 된다. 

일반적으로 REST API는 쿼리를 특정 데이터 모델로 제한하지만, GraphQL은 단일 요청으로 여러 데이터 모델을 검색할 수 있는 가능성을 열어준다. 따라서 REST 보다 유연하고 표현력이 풍부한 쿼리를 수행할 수 있다. 

 

[웹훅]

단순한 이벤트 기반 데이터 전송 패턴. 일반적인 API 와는 반대로, 원천 시스템에서 데이터 싱크로 연결이 된다

 

[RPC와 gRPC]

원격 프로시저 호출(RPC)은 분산 컴퓨팅에서 일반적으로 사용된다. gRPC는 2015년 구글에서 내부적으로 개발한 원격 프로시저 호출 라이브러리이다. 구글 애즈 및 GCP와 같은 많은 구글 서비스는 gRPC API를 제공한다. gRPC는 HTTP/2를 통한 효율적인 양방향 데이터 교환을 강조한다.  

 

 

드러나지 않는 요소가 원천 시스템에 미치는 영향

데이터 관리

데이터 엔지니어에게 원천 시스템의 데이터 관리는 어려운 과제다. 원천 시스템에서 데이터를 관리하는 방식은 데이터를 수집, 저장 및 변환하는 방법에 직접적인 영향을 미치므로 최대한 이해해야 한다.

 

고려해야 할 몇 가지 사항이 있다.

 

데이터 거버넌스

업스트림 데이터와 시스템은 신뢰성이 높고 이해하기 쉬운 방식으로 관리되고 있는가? 누가 관리하고 있는가?

 

데이터 품질

업스트림 시스템에서 데이터 품질과 무결성을 어떻게 보장하는가?

 

스키마

업스트림 스키마가 변경되리라 예상하자. 가능한 경우 원천 시스템 팀과 협력해 스키마 변경에 대한 알림을 받자

 

마스터 데이터 관리

업스트림 레코드의 생성은 마스터 데이터 관리 관행 또는 시스템에 의해 제어되고 있는가?

 

개인정보보호와 윤리

원시 데이터에 접근할 수 있는가? 아니면 데이터가 난독화되는가? 소스 데이터의 의미는 무엇인가? 얼마나 오래 보존되는가? 보전 정책에 따라 위치가 변경되는가?

 

규정

규정에 따라 데이터에 접근해야 하는가?

 

그 외에도 데이터 옵스, 데이터 아키텍처가 고려해야 하는 사항에 대해 간단히 살펴보자

데이터 옵스

데이터 옵스는 자동화, 관찰 가능성, 사고 대응 등을 고려해야 한다.

 

데이터 아키텍처

데이터 아키텍처와 관련해서는 신뢰성, 내구성, 가용성, 사람(SLA)를 고려해야 한다. 

 

 

---

원천 시스템과 그 데이터는 데이터 엔지니어링 수명 주기에서 매우 중요하다. 원천 시스템을 남용하는 데이터 엔지니어는 운영 환경이 멈추서면 다른 일자리를 찾아야 할 수도 있다. 원천 시스템 팀과의 협업을 개선하면 데이터 품질 향상, 결과 달성 및 데이터 제품 개선으로 이어진다. 데이터 요구 사항을 사전에 전달해 데이터 엔지니어링 프로세스에서 애플리케이션 팀을 지원해야 한다. 

 

데이터 엔지니어와 원천 시스템 팀 간의 통합이 증가하고 있다. 한 예로 오랫동안 음지에 있었지만 최근 두각을 나타내고 있는 역 ETL을 들 수 있다.