Quick Overview 방대한 양의 데이터를 활용하기 위해서는 데이터 이동이 필수적입니다. 데이터 이동이란 적절한 위치와 시점에 데이터를 가져오는 작업을 의미합니다. 데이터를 이동하는 방법은 비즈니스 요구사항과 데이터베이스 성능 개선에 보조를 맞춰 발전해왔습니다. 여기서는 데이터 이동의 기본 개념을 살펴봅니다. |
기업이 사용 및 생산하는 방대한 데이터 볼륨의 가치는 갈수록 높아지고 있습니다. 그러나 데이터를 실행할 수 있는 정보로 전환하는 과정에서 중요한 문제에 직면합니다. 가장 큰 비중을 차지하는 문제는 데이터가 적절한 시점에 적절한 위치에 있도록 하는 것입니다. 이를 위해서는 데이터 이동이 필요한 경우가 많습니다.
데이터 이동이란 무엇인가?
데이터 이동은 데이터를 현재 위치에서 다른 위치로 옮기는 것입니다. 적절한 데이터가 적절한 시점에, 적절한 위치에 있도록 하는 것이 주된 목표입니다. 말로는 간단하지만, 회사의 데이터 크기와 가치가 특히 커지고 있는 상황에서는 실제로 그렇게 간단하지 않습니다. IT 전문가는 수익으로 연결되는 인사이트를 위해 의사 결정자가 데이터를 사용할 수 있도록 데이터를 옮기는 작업에 갈수록 많은 시간을 소비하고 있습니다.
데이터 이동이 중요한 이유
데이터 이동이 한 위치 또는 데이터 저장소에 있는 데이터를 가져와 해당 데이터와 똑같은 복사본을 만들어 다른 곳에서 사용할 수 있도록 하는 것이라면, 전제 조건은 첫 번째 위치의 데이터에 문제가 발생할 때 두 번째 위치에서 데이터를 사용할 수 있어야 한다는 것입니다.
데이터 이동이 새로운 개념은 아닙니다. 하지만 데이터를 이동해야 하는 이유는 그동안 빠르게 발전했습니다. 대부분 기업은 느리지만 중대한 사용례에 대처하기 위해 데이터 이동을 선택합니다. 구체적으로 다음과 같은 상황입니다.
가치 – 새로운 분석 툴과 실행 방식을 통해 기업은 전례 없는 방식으로 데이터에서 더 많은 가치를 얻을 수 있게 되었습니다. 이런 툴을 사용해 고객을 찾고, 고객이 무엇을 하고 있는지 확인하고, 더 효과적으로 고객과 접촉하고 지출을 최적화할 수 있습니다. 기업은 새로운 유형의 사용자에게 성능 저하 없이 데이터를 제공해야 하므로 데이터 이동을 선택하게 됩니다.
데이터 이동 방법
데이터 이동 방법은 변화하는 비즈니스 요구사항과 데이터베이스 성능의 개선에 보조를 맞춰 발전해 왔습니다.
ETL(Extract, Transform, Load)
가장 오래된 방법인 ETL은 영구 데이터 스토리지의 소스에서 시작합니다. 프로그램 또는 스크립트가 소스에서 데이터를 추출한 다음 변환합니다. 예를 들어 Gender(성별) 필드의 M 및 F를 0과 1로, 또는 그 반대로 변환합니다. 그런 다음 프로그램은 변환된 데이터를 특정 용도를 위해 다른 곳의 다른 데이터 저장소로 로드합니다.
ELT(Extract, Load, Transform)
ETL의 문제는 데이터를 여러 번 건드리고, 그럴 때마다 시간과 처리 성능이 소비된다는 점입니다. 예를 들어, 고객 관계 관리(CRM) 또는 POS 시스템과 같이 프로덕션 애플리케이션에 사용되는 하드웨어에서 ETL이 실행되는 경우 귀중한 리소스를 소비하게 됩니다.
ELT는 이런 단점을 고려한 방법입니다. 데이터를 복사하기 전에 변환하지 않고, 소스에서 추출해서 다른 데이터 저장소로 로드한 이후에 변환합니다. 왜 그렇게 할까요? 추출 규모가 크고 이를 효율적으로 검색할 방법이 없는 경우 ELT는 메모리, 네트워크와 같은 넉넉하지 않은 컴퓨팅 리소스에 미치는 영향을 줄여줄 수 있기 때문입니다.
리버스 ETL(Reverse ETL)
리버스 ETL(Reverse ETL)은 반대 방향, 즉 타깃 시스템에서 시작해 소스를 향합니다. 이 방법은 데이터를 추출해서 일부를 추가, 편집 또는 삭제하거나 새로운 인사이트를 위해 데이터를 결합하는 경우 유용합니다. 변환 이후 변경된 데이터를 주 데이터 저장소로 다시 로드합니다.
CDC(Changed Data Capture)
기업에서 오라클, 포스트그레SQL과 같은 여러 소스의 운영 데이터를 비즈니스 인텔리전스 플랫폼에서 사용하기 위해 하나의 중앙 위치로 이동해야 한다고 가정해 봅시다. 데이터가 스토리지 버킷에 들어올 때까지 기다렸다가 검색해서 원하는 데이터만 추출할 수 있습니다. 혹은 변경 데이터 캡처(Change Data Capture, CDC)를 사용해 필요한 변경만 캡처해도 됩니다. 결과적으로 더 높은 성능을 얻게 돼 실시간 처리에 훨씬 근접할 수 있습니다.
CDC는 지속적으로 실행되면서 타깃 데이터 저장소를 최신 상태로 유지합니다. 반면 ETL과 ELT는 간헐적으로, 예를 들어 8시간 또는 24시간마다 실행하는 방식에 더 유용합니다. CDC는 학생 등록 시스템, 항공편 예약 및 주식 거래와 같이 트랜잭션이 가용성에 직접적으로 영향을 미칠 때 적합합니다. 이런 시스템이 하루에 한두 번만 업데이트된다면 인벤토리에 대한 시야가 왜곡되고 부정확할 수 있습니다.
동기화
동기화는 변경 데이터 캡처 이상의 단계입니다. 동기화는 모든 변경이 최대한 실시간에 가깝게 이뤄지도록 하므로 소스와 타깃 시스템의 추가, 편집, 삭제가 최대한 동시에 실행됩니다.
집에서 멀리 떨어진 곳을 여행 중인 쇼핑객을 생각해 봅시다. 신용카드로 구매를 시도하지만 카드사가 이 쇼핑객이 여행 중임을 알지 못하거나 비일상적인 구매라는 이유로 결제를 거부합니다. 카드사가 상황을 파악하는 데 몇 초 이상의 시간이 걸린다면 정보는 쓸모없어집니다. 대부분 쇼핑객이 그사이 거래를 포기할 것이기 때문입니다.
그러나 카드사의 승인 시스템이 예를 들어 CRM과 동기화된다면, 즉각 “프라하에서 귀하의 신용카드를 사용한 구매 시도가 탐지되었습니다. 귀하가 맞습니까?”라는 문제 메시지를 보낼 수 있습니다. 쇼핑객이 본인임을 확인하면 거래가 진행됩니다. ETL은 물론 ELT라 해도 이런 수준의 빠른 응답성을 확보하기는 어렵습니다.
데이터 이동의 하위 시장 2가지
IDC는 데이터 이동을 다음과 같은 두 개의 하위 시장으로 정의합니다.
동적 데이터 이동은 주로 상이한 유형 및 구조 간의 이동을 다룹니다. 데이터의 양이 증가하고 새롭고 더 광범위한 용도가 식별되면서 동적 데이터 이동이 전통적인 데이터베이스 복제를 침식하고 있습니다. 기업은 오픈소스 및 NoSQL 데이터베이스, 그리고 카프카(Kafka)와 같은 데이터 스트리밍 기술을 채택할 수 있습니다. 이를 위해서는 대부분 경우 다양한 플랫폼 간의 선별적인 실시간 데이터 이동이 필요합니다(예를 들어, 오라클에서 포스트그레SQL 또는 마리아DB로).
지금까지 데이터 이동의 기본 개념과 대표적인 방법을 살펴보았습니다. 2부에서는 동적 데이터 이동을 방해하는 장애물을 살펴보고, 데이터 모델링이 어떻게 도움이 되는지 살펴봅니다. 데이터베이스 관리에 어려움을 겪고 계시거나 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다.
Quick Overview
방대한 양의 데이터를 활용하기 위해서는 데이터 이동이 필수적입니다. 데이터 이동이란 적절한 위치와 시점에 데이터를 가져오는 작업을 의미합니다. 데이터를 이동하는 방법은 비즈니스 요구사항과 데이터베이스 성능 개선에 보조를 맞춰 발전해왔습니다. 여기서는 데이터 이동의 기본 개념을 살펴봅니다.
기업이 사용 및 생산하는 방대한 데이터 볼륨의 가치는 갈수록 높아지고 있습니다. 그러나 데이터를 실행할 수 있는 정보로 전환하는 과정에서 중요한 문제에 직면합니다. 가장 큰 비중을 차지하는 문제는 데이터가 적절한 시점에 적절한 위치에 있도록 하는 것입니다. 이를 위해서는 데이터 이동이 필요한 경우가 많습니다.
데이터 이동이란 무엇인가?
데이터 이동은 데이터를 현재 위치에서 다른 위치로 옮기는 것입니다. 적절한 데이터가 적절한 시점에, 적절한 위치에 있도록 하는 것이 주된 목표입니다. 말로는 간단하지만, 회사의 데이터 크기와 가치가 특히 커지고 있는 상황에서는 실제로 그렇게 간단하지 않습니다. IT 전문가는 수익으로 연결되는 인사이트를 위해 의사 결정자가 데이터를 사용할 수 있도록 데이터를 옮기는 작업에 갈수록 많은 시간을 소비하고 있습니다.
데이터 이동이 중요한 이유
데이터 이동이 한 위치 또는 데이터 저장소에 있는 데이터를 가져와 해당 데이터와 똑같은 복사본을 만들어 다른 곳에서 사용할 수 있도록 하는 것이라면, 전제 조건은 첫 번째 위치의 데이터에 문제가 발생할 때 두 번째 위치에서 데이터를 사용할 수 있어야 한다는 것입니다.
데이터 이동이 새로운 개념은 아닙니다. 하지만 데이터를 이동해야 하는 이유는 그동안 빠르게 발전했습니다. 대부분 기업은 느리지만 중대한 사용례에 대처하기 위해 데이터 이동을 선택합니다. 구체적으로 다음과 같은 상황입니다.
IT 인프라 – 기업에서 소프트웨어 애플리케이션 또는 하드웨어 인프라의 유효 수명이 끝나가는 상황을 인지합니다. 그곳에 데이터를 영원히 둘 수 없으므로 현대화를 결정하게 되며, 새로운 자산으로 마이그레이션이 최우선 과제가 됩니다.
볼륨 – 유입되는 데이터와 이를 저장 및 처리하기 위한 용량이 현재 용량을 초과할 수 있습니다. 더 용량이 큰 다른 스토리지로의 이동이 필요하게 됩니다.
가치 – 새로운 분석 툴과 실행 방식을 통해 기업은 전례 없는 방식으로 데이터에서 더 많은 가치를 얻을 수 있게 되었습니다. 이런 툴을 사용해 고객을 찾고, 고객이 무엇을 하고 있는지 확인하고, 더 효과적으로 고객과 접촉하고 지출을 최적화할 수 있습니다. 기업은 새로운 유형의 사용자에게 성능 저하 없이 데이터를 제공해야 하므로 데이터 이동을 선택하게 됩니다.
데이터 이동 방법
데이터 이동 방법은 변화하는 비즈니스 요구사항과 데이터베이스 성능의 개선에 보조를 맞춰 발전해 왔습니다.
ETL(Extract, Transform, Load)
가장 오래된 방법인 ETL은 영구 데이터 스토리지의 소스에서 시작합니다. 프로그램 또는 스크립트가 소스에서 데이터를 추출한 다음 변환합니다. 예를 들어 Gender(성별) 필드의 M 및 F를 0과 1로, 또는 그 반대로 변환합니다. 그런 다음 프로그램은 변환된 데이터를 특정 용도를 위해 다른 곳의 다른 데이터 저장소로 로드합니다.
ELT(Extract, Load, Transform)
ETL의 문제는 데이터를 여러 번 건드리고, 그럴 때마다 시간과 처리 성능이 소비된다는 점입니다. 예를 들어, 고객 관계 관리(CRM) 또는 POS 시스템과 같이 프로덕션 애플리케이션에 사용되는 하드웨어에서 ETL이 실행되는 경우 귀중한 리소스를 소비하게 됩니다.
ELT는 이런 단점을 고려한 방법입니다. 데이터를 복사하기 전에 변환하지 않고, 소스에서 추출해서 다른 데이터 저장소로 로드한 이후에 변환합니다. 왜 그렇게 할까요? 추출 규모가 크고 이를 효율적으로 검색할 방법이 없는 경우 ELT는 메모리, 네트워크와 같은 넉넉하지 않은 컴퓨팅 리소스에 미치는 영향을 줄여줄 수 있기 때문입니다.
리버스 ETL(Reverse ETL)
리버스 ETL(Reverse ETL)은 반대 방향, 즉 타깃 시스템에서 시작해 소스를 향합니다. 이 방법은 데이터를 추출해서 일부를 추가, 편집 또는 삭제하거나 새로운 인사이트를 위해 데이터를 결합하는 경우 유용합니다. 변환 이후 변경된 데이터를 주 데이터 저장소로 다시 로드합니다.
CDC(Changed Data Capture)
기업에서 오라클, 포스트그레SQL과 같은 여러 소스의 운영 데이터를 비즈니스 인텔리전스 플랫폼에서 사용하기 위해 하나의 중앙 위치로 이동해야 한다고 가정해 봅시다. 데이터가 스토리지 버킷에 들어올 때까지 기다렸다가 검색해서 원하는 데이터만 추출할 수 있습니다. 혹은 변경 데이터 캡처(Change Data Capture, CDC)를 사용해 필요한 변경만 캡처해도 됩니다. 결과적으로 더 높은 성능을 얻게 돼 실시간 처리에 훨씬 근접할 수 있습니다.
CDC는 지속적으로 실행되면서 타깃 데이터 저장소를 최신 상태로 유지합니다. 반면 ETL과 ELT는 간헐적으로, 예를 들어 8시간 또는 24시간마다 실행하는 방식에 더 유용합니다. CDC는 학생 등록 시스템, 항공편 예약 및 주식 거래와 같이 트랜잭션이 가용성에 직접적으로 영향을 미칠 때 적합합니다. 이런 시스템이 하루에 한두 번만 업데이트된다면 인벤토리에 대한 시야가 왜곡되고 부정확할 수 있습니다.
동기화
동기화는 변경 데이터 캡처 이상의 단계입니다. 동기화는 모든 변경이 최대한 실시간에 가깝게 이뤄지도록 하므로 소스와 타깃 시스템의 추가, 편집, 삭제가 최대한 동시에 실행됩니다.
집에서 멀리 떨어진 곳을 여행 중인 쇼핑객을 생각해 봅시다. 신용카드로 구매를 시도하지만 카드사가 이 쇼핑객이 여행 중임을 알지 못하거나 비일상적인 구매라는 이유로 결제를 거부합니다. 카드사가 상황을 파악하는 데 몇 초 이상의 시간이 걸린다면 정보는 쓸모없어집니다. 대부분 쇼핑객이 그사이 거래를 포기할 것이기 때문입니다.
그러나 카드사의 승인 시스템이 예를 들어 CRM과 동기화된다면, 즉각 “프라하에서 귀하의 신용카드를 사용한 구매 시도가 탐지되었습니다. 귀하가 맞습니까?”라는 문제 메시지를 보낼 수 있습니다. 쇼핑객이 본인임을 확인하면 거래가 진행됩니다. ETL은 물론 ELT라 해도 이런 수준의 빠른 응답성을 확보하기는 어렵습니다.
데이터 이동의 하위 시장 2가지
IDC는 데이터 이동을 다음과 같은 두 개의 하위 시장으로 정의합니다.
데이터베이스 복제는 전통적으로 백업/복구, 재해 복구 또는 고가용성을 위해 데이터베이스의 전체 복사본을 만드는 데 사용됐습니다. 소스 및 타깃 데이터베이스의 유형과 구조가 일반적으로 동일했으므로 데이터 이동도 비교적 쉬웠습니다. 그러나 데이터에 대한 광범위한 인사이트를 위한 요구가 발전하면서 복제는 작은 일부가 되었습니다.
동적 데이터 이동은 주로 상이한 유형 및 구조 간의 이동을 다룹니다. 데이터의 양이 증가하고 새롭고 더 광범위한 용도가 식별되면서 동적 데이터 이동이 전통적인 데이터베이스 복제를 침식하고 있습니다. 기업은 오픈소스 및 NoSQL 데이터베이스, 그리고 카프카(Kafka)와 같은 데이터 스트리밍 기술을 채택할 수 있습니다. 이를 위해서는 대부분 경우 다양한 플랫폼 간의 선별적인 실시간 데이터 이동이 필요합니다(예를 들어, 오라클에서 포스트그레SQL 또는 마리아DB로).
지금까지 데이터 이동의 기본 개념과 대표적인 방법을 살펴보았습니다. 2부에서는 동적 데이터 이동을 방해하는 장애물을 살펴보고, 데이터 모델링이 어떻게 도움이 되는지 살펴봅니다. 데이터베이스 관리에 어려움을 겪고 계시거나 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다.