ETL, 가상화 또는 Write-Back: 어떤 데이터 배치 처리 방법이 귀하의 요구에 맞습니까?

수년에 걸쳐 비즈니스 프로세스와 의사 결정을 지원하는 데이터를 이동하고 병합하는 다양한 접근 방식이 만들어졌습니다. 각각 고유한 가상 기능과 이점이 있습니다. 이러한 기능과 데이터 전략에서 바라는 결과와 어떻게 관련이 있는지 이해하는 것은 최적의 시스템을 설계하는 데 필수적입니다.

모든 데이터를 최적화하고, 액세스 가능하게 하고, 통합하기 위한 전략을 수립할 때는 다음을 포함하여 여러 변수와 요구 사항을 고려해야 합니다.

• 얼마나 긴급하게 최신 데이터가 필요합니까?
• 대역폭과 저장 공간의 제약은 무엇입니까?
• 어떤 종류의 기술 리소스를 이용할 수 있나요?
• 동일한 데이터의 사본을 몇 개나 유지해야 합니까?
• 데이터 세트의 크기는 얼마인가요?

일괄 처리

일괄 처리에서는 데이터를 정기적으로 또는 일괄적으로 전송합니다. 이러한 패턴에는 ETL(Extract Transform Load), ELT(Extract Load Transform), Reverse ETL, Mirroring 또는 Replication, Write-back 도구가 포함됩니다.

ETL 및 ELT

ETL은 데이터를 이동하는 전통적인 방식입니다. 데이터는 데이터 소스에서 추출되고, 비즈니스 규칙에 따라 변환되고, 대상 데이터베이스에 로드됩니다. 이 방식은 매우 안전하지만 유연하지 않을 수도 있습니다. 이러한 경직성으로 인해 데이터 세트는 매우 구조화되고 문서화되어야 하며, 이는 복잡한 변환을 더 쉽게 만듭니다. 레거시 시스템 데이터베이스는 일반적으로 매우 구조화되고 경직되어 있으므로 ETL은 이러한 시스템에 적합합니다. 이러한 프로세스를 구축하려면 개발자는 데이터 구조와 프로그래밍 언어에 대한 심층적인 지식이 있어야 합니다.

ELT는 ETL과 비슷하지만 변환은 대상 데이터베이스에 로드한 후에 발생합니다. 이러한 보다 현대적인 접근 방식은 원시 데이터가 변환된 후에도 대상 데이터베이스에 남아 있기 때문에 더 많은 유연성을 제공합니다. 결과적으로 변환은 원본 데이터 소스에서 데이터를 가져오지 않고도 반복적으로 또는 소급적으로 실행할 수 있어 새로운 데이터 세트를 추출하는 데 필요한 리소스가 줄어듭니다. ELT는 데이터 정리 및 변환을 최종 사용자에게 더 가깝게 실행할 수 있는 보다 광범위하고 덜 구조화된 데이터 세트에 더 적합합니다.

역 ETL

역방향 ETL은 또 다른 일괄 처리 프로세스이지만, 데이터는 ETL 파이프라인과 반대 방향으로 흐릅니다. 데이터는 운영 타사 애플리케이션에서 추출되어 중앙 데이터베이스에 로드됩니다. 이 접근 방식을 통해 조직은 중앙 웨어하우스에서 데이터 세트의 한 버전을 통합하고 운영 애플리케이션은 다른 애플리케이션이나 분석에서 사용하는 것과 동일한 데이터를 사용할 수 있습니다. 역방향 ETL은 조직에 "단일 진실 소스"를 지원합니다.

문제는 역방향 ETL이 배치로 작동한다는 것입니다. 데이터가 끊임없이 변화하는 동적 조직에서 서로 다른 그룹은 서로 다른 업데이트 일정으로 인해 동일한 데이터의 다른 버전을 사용할 수 있습니다. 역방향 ETL 동기화 전략은 또한 여러 소스에서 운영 시스템에 대량의 데이터가 로드되므로 운영 시스템을 압도할 수 있습니다. 이는 동일한 데이터의 충돌 및 데이터 버전으로 이어질 수 있습니다.

미러링 및 복제

미러링과 복제는 변환 없이 별도의 데이터베이스에 데이터를 저장하며, 종종 데이터 손실 시 데이터 세트를 백업하기 위해 구현됩니다. 또한 데이터 관리를 최적화하고 데이터가 이동 중일 때 영구적인 데이터 세트를 만드는 데 유용할 수 있습니다. 미러링은 데이터뿐만 아니라 전체 데이터베이스 구조와 관리 시스템도 복제합니다.

복제는 데이터베이스 관리 시스템을 복사하지 않고 데이터만 복사하기 때문에 미러링과 약간 다릅니다. 복제를 사용하면 다양한 시스템에서 데이터에 액세스하는 것이 훨씬 쉬워지는데, 데이터베이스 관리 시스템이 이를 정의하지 않기 때문입니다.

미러링은 로드 밸런싱에 더 나은 옵션입니다. 소스 및 복사된 데이터베이스는 동일하므로 두 소스에서 모두 데이터에 쉽게 액세스할 수 있습니다. 재해 복구 및 리소스 사용 최적화는 미러링의 일반적인 사용 사례입니다. 또한 동작 중인 데이터의 스냅샷을 캡처하는 데 적합합니다. 예를 들어, 정기적으로 사용되는 가상화된 데이터는 영구 데이터 저장소에 미러링할 수 있습니다.

실시간

실시간으로 데이터를 통합하고 관리하면 특히 다양한 데이터 세트를 병합할 때 많은 복잡성이 발생합니다. 서로 다른 데이터 세트가 끊임없이 변경되므로 소스 데이터와 병합된 데이터 간에 불일치가 항상 존재합니다. 실시간 데이터는 센서 또는 재무 데이터를 추적하는 운영 시스템에 더 적합합니다.

변경 데이터 캡처(CDC)

CDC는 정의된 이벤트가 발생할 때 한 데이터베이스의 변경 사항이 다른 데이터베이스에 자동으로 반영되는 이벤트 기반 패턴입니다. 이 패턴은 양방향 데이터 흐름을 지원하므로 소스 및 대상 데이터베이스가 데이터를 교환하여 동기화를 보장할 수 있습니다. CDC는 ETL보다 데이터를 이동하는 훨씬 효율적인 방법으로, 변경된 데이터만 대상 데이터베이스로 전송되고 전체 데이터 세트는 전송되지 않습니다.

CDC는 통합할 수 없는 데이터베이스나 애플리케이션과 잘 작동합니다. CDC 프로세스는 별도의 데이터베이스에 데이터를 스테이징할 수 있으며, 스테이징된 데이터에서 변경 사항을 대상 데이터베이스로 공유할 수 있습니다. 이 방법은 별도의 동적 데이터 소스를 유지 관리해야 하므로 과도한 복잡성이 발생하고 오류 가능성이 커집니다.

스트리밍 데이터

스트리밍 데이터는 데이터를 목적지로 끊임없이 수집, 처리, 이동하는 것을 포함합니다. 일반적으로 이는 금융 서비스 데이터의 센서 데이터를 의미합니다. 많은 경우 스트리밍은 대상 데이터베이스로 가는 도중에 변환됩니다.

스트리밍 데이터는 빠르지만 몇 가지 단점이 있습니다. 스트리밍 데이터는 끊임없이 이동하고 인터넷을 통해 다른 경로를 거치므로 데이터가 올바른 순서로 처리된다는 보장이 없습니다. 일부 데이터는 최신 데이터 이후에 처리되도록 도착하여 가장 정확한 데이터에 대한 혼란을 일으킬 수 있습니다. 데이터가 적절한 순서로 처리되도록 하려면 적절한 오케스트레이션을 구현해야 합니다.

스트리밍 데이터는 또한 데이터 소스의 데이터 모델을 다운스트림 사용자에게 노출합니다. 다운스트림 애플리케이션이 소스 데이터 모델에 직접 연결된 경우 이 모델에 대한 변경은 다운스트림에 대혼란을 일으킵니다.

스트리밍 데이터가 데이터 제품 내에 패키징된 경우 내부 소스 데이터 모델을 데이터 제품의 데이터 모델에 매핑할 수 있습니다. 이 구조는 외부 그룹과 데이터를 공유하기가 더 쉬워집니다.

Write-back 기능

프런트엔드 BI 도구의 Write-back 기능은 소스 데이터베이스를 변경하는 또 다른 방법입니다. 이 새로운 패턴을 통해 BI 도구를 사용하는 분석가는 BI 도구에서 직접 소스 데이터베이스에 대한 변경 사항을 포함할 수 있습니다. 이러한 변경 사항은 데이터 소스와 분석가의 작업에 즉시 반영됩니다. 이를 통해 데이터를 가장 잘 이해하는 분석가는 원본 데이터 소스를 조정하거나 수정할 수 있습니다.

또한 Write-back 기능을 통해 데이터 분석가가 Excel 스프레드시트에 의존하는 정도가 줄어들어, Excel을 사용하는 것만큼 빠르게 데이터베이스를 업데이트할 수 있게 되었습니다.

애플리케이션 통합

SaaS 애플리케이션은 일반적으로 REST API를 통해 데이터를 공유합니다. 이는 애플리케이션 데이터베이스에서 데이터를 가져오는 간단한 프로세스입니다. API 자체로는 데이터를 변환할 수 없지만 iPaaS 플랫폼을 통해 실행하면 대상 애플리케이션으로 전송하기 전에 데이터에 자동화된 변환 프로세스를 수행할 수 있습니다.

REST API는 하나 또는 두 개의 애플리케이션 간의 간단한 데이터 교환에는 잘 작동하지만, 이러한 유형의 접근 방식은 잘 확장되지 않습니다. 앱이 API를 변경하면 다운스트림 애플리케이션이 중단될 수 있습니다.

데이터 가상화

데이터 가상화는 연결된 데이터베이스에서 가져온 데이터의 새로운 가상화된 데이터 세트를 만드는 코드를 실행하는 관행입니다. 이 새로운 데이터 세트는 코드를 실행할 때마다 생성되지만 데이터는 필요한 기간 동안만 보관됩니다. 이는 Avrio 플랫폼이 분석을 위한 데이터 세트를 생성하는 데 사용하는 패턴입니다. 데이터 통합을 위해 이 기술을 사용하는 데는 여러 가지 이점이 있습니다.

첫째, 데이터 가상화는 기본 데이터베이스와 구조를 데이터 자체에서 분리합니다. 이를 통해 데이터 가상화가 훨씬 더 확장 가능하고 유연해집니다.

둘째, 데이터 가상화는 데이터베이스의 영구 사본을 생성하지 않습니다. 매번 새로운 데이터 세트가 생성되므로 코드가 실행되고 가장 최신의 데이터가 소스 데이터베이스에서 가져옵니다. 이 접근 방식은 동일한 데이터의 여러 버전 간의 충돌을 방지합니다. 저장 비용도 최소화할 수 있습니다.

셋째, 정교한 커넥터, 페더레이션 쿼리 엔진, 가상화는 여러 데이터베이스의 데이터를 한 번에 쿼리, 변환, 병합할 수 있습니다. 통합된 메타데이터 저장소와 그 위에 계층화된 통합 데이터 모델을 통해 이 접근 방식을 통해 데이터 분석가는 마치 단일 데이터베이스인 것처럼 다양한 데이터 저장소에서 데이터를 가져올 수 있습니다.

마지막으로, 데이터 가상화는 데이터에 대한 더 많은 제어를 가능하게 합니다. 데이터가 이 가상화 계층을 통과하기 때문에 데이터 품질 검사를 실행하고 세부적인 액세스 제어를 구현할 수 있습니다.

Avrio 및 데이터 통합 패턴

각 통합 및 동기화 접근 방식에는 장단점이 있습니다. 접근 방식에 관계없이 데이터 거버넌스, 보안 및 품질에 대한 주의는 건강한 데이터 아키텍처에 가장 중요합니다. 통합 플랫폼에서 적합한 접근 방식을 함께 사용하면 강력하고 유연한 솔루션이 될 수 있습니다.

Avrio의 핵심 기능은 데이터 가상화로, 이는 분석할 데이터를 통합하여 코드가 실행될 때마다 새 데이터 세트를 만드는 데 사용됩니다. 지속적인 데이터가 필요하지만 정기적인 변경이 있는 경우 Avrio는 소스 데이터베이스의 변경 사항만 미러링된 환경으로 미러링하는 CDC 기능도 제공합니다.

또한 Avrio는 가상화된 데이터 세트에서 영구 데이터 세트를 만드는 미러링 기능을 갖추고 있습니다. 데이터가 자주 변경되지 않지만 정기적으로 사용되는 경우 미러링은 대역폭 리소스 사용을 줄일 수 있습니다.

Avrio 플랫폼은 API를 통해 타사가 데이터 제품에 액세스할 수 있도록 합니다. Avrio의 이 프런트엔드 계층은 또한 Avrio 플랫폼에 연결된 백엔드 데이터베이스에서 BI 도구에서 변경한 내용을 통합하는 쓰기 백 기능을 제공합니다.

여러 통합 및 동기화 패턴을 결합하여 비즈니스 성과를 달성하는 것은 전략적으로 타당합니다. 각 상황은 다르며 고유한 역량이 필요합니다. Avrio 플랫폼은 여러 데이터 사일로에서 데이터에 액세스할 수 있도록 하는 올바른 기술과 패턴을 AI 시대, 빠른 분석 및 더 나은 의사 결정을 위해 설계된 기본 제공 거버넌스와 보안이 있는 셀프 서비스 데이터 제품과 결합합니다.

Avrio는 기존 통합 도구 및 인프라와도 잘 맞습니다. 데이터 레이크로 데이터를 스트리밍하는 경우 Avrio는 스트리밍 데이터의 스냅샷을 캡처하여 분석할 수 있는 데이터 제품을 만들 수 있습니다. 잘 확립되어 있고 크게 변경되지 않는 ETL 파이프라인을 구축한 경우 Avrio는 이 데이터를 데이터 제품에 통합하여 더 쉽게 액세스할 수 있도록 하고 다른 시스템의 데이터 세트를 통합할 수 있습니다.