2017.10.26

ETL 시대의 종말

Daniel Mintz | InfoWorld
추출(Extract), 변환(Transform), 그리고 적재(Load). 이렇게 보면 ETL(Extraction, Transformation, Loading)은 참 단순한 개념 같다. 그러나 데이터 파이프라인 관리 경험이 있는 사람은 이 단순해 보이는 이름 뒤에 얼마나 복잡한 과정이 숨겨져 있는지 알고 있다.

특히 엔지니어들의 머리를 쥐어 뜯게 만드는 것은 바로 '변환(transform)' 단계다. 여기서 변환이란 미변환 상태의 로우 데이터(raw data)를 정리, 필터링, 정형(reshaping)하고, 요약해 분석에 적합한 상태로 바꾸어놓는 과정을 일컫는다. ETL 과정에서 바로 이 단계가 가장 많은 시간과 에너지가 들어가며 대부분 실수가 발생하는 부분도 이 단계다.

ETL이 어렵다면 왜 이런 식으로 변환하는 것인가
간단히 말하자면 다른 방법이 없기 때문이다. 데이터웨어하우스는 소스 시스템에서 추출된 상태 그대로의 로우 데이터를 처리하지 못한다. 따라서 이런 데이터를 적재해 분석의 대상으로 삼기 위해서는 반드시 변환 단계가 필요하다.

하지만 여기에 들어가는 비용은 다양한 형태로 변환될 수 있는 로우 데이터를 유지하는 대신, 변환 과정을 거침으로써 데이터는 어느 정도의 유동성을 상실한 중간 단계 형태로 변화한다. 이를 통해 데이터 레솔루션(resolution)의 일부가 사라지고, 데이터에 현재 비즈니스 메트릭스를 적용하게 되며, 쓸모없는 데이터를 버리는 과정이 선행된다.

그리고 만일 이런 과정들 가운데 어느 하나라도 빠지거나 바뀌었다면, 예를 들어 이전까지는 하루 단위로 처리하던 데이터를 이제 시간 단위로 필요로 하게 되었거나, 메트릭 데피니션이 바뀌거나, '쓸모 없다'고 생각했던 데이터 중 일부가 필요한 것으로 변경된다면 데이터 변환 로직을 이에 맞춰 변화시키고, 데이터를 다시 프로세싱한 후 재적재해야 한다.

수일에서 수주일까지 걸릴 수 있는 과거 데이터 정제 과정
기존 ETL 시스템이 더할 나위 없이 훌륭한 시스템이라고는 아무도 말하지 않는다. 단지 우리에게 주어진 방법이 그것뿐이었다.

기술이 변화하고 이전에 우리를 제약하던 요소들이 사라짐에 따라 이상적인 상황에서, 즉 데이터웨어하우스가 거의 무제한적으로 빠르고, 데이터 사이즈나 형태를 막론하고 모든 데이터를 처리할 수 있다고 가정했을 때 어떻게 할 것인가를 생각해 볼 필요가 생겼다. 이렇게 이상적인 상황에서라면 데이터를 적재하기 전에 굳이 변환할 필요가 없을 것이다. 그저 데이터 추출 후 로우 데이터 상태 그대로 이를 적재하면 그만이다.

물론 이 경우에도 데이터 변환을 아예 안 할 수는 없을 것이다. 왜냐하면 정제되지 않은 저품질 데이터의 쿼리는 크게 비즈니스 가치가 있는 결과물을 내기 어렵기 때문이다. 그러나 데이터웨어하우스의 속도가 매우 빠르기 때문에 쿼리와 거의 동시에 데이터 변환이 이뤄질 것이다. 사실상 데이터 변환과 쿼리가 하나의 단계로 통합되는 것이다. 그리고 바로 이런 맥락에서 등장한 것이 ELT이다.

이런 상상 속 시스템이 갖는 장점은 분명하다. 어떤 데이터를 버릴 지, 어떤 메트릭 데피니션 버전을 사용할 지를 미리 결정해 리스크를 질 필요가 없다는 것이다. 언제나 가장 새로운 버전의 변환 로직을 이용할 수 있을 것이고 ELT는 완벽한 유연성과 애질리티를 보장받게 될 것이다.

ELT로의 전환이 필요한가
현실은 얼마나 이상에 가까운가? 과연 ELT로의 전환이 필요한가? 사실 현실은 이상과 완벽히 부합한다고 하기는 어렵다. 물론 과거에 비하면 데이터웨어하우스가 훨씬 더 빠르고 싸진 것은 확실하다. 한 번 데이터를 변환하려면 몇 시간의 시간이 걸리고 수천 달러의 비용이 들어가던 것이 이제는 수초 만에, 불과 몇 센트의 비용으로 가능해졌기 때문이다. 그렇다고 해도 여전히 불량 데이터나 처리량 과다로 인해 시스템이 느려지는 일은 발생한다.

따라서 아직도 웨어하우스 외부에서 처리해야만 하는 변환 단계가 존재한다는 사실은 부정할 수 없을 것 같다. 관계없는 불순물 데이터를 제거하고, 대략적인 정형을 거치는 과정은 여전히 전적재(preloading) 과정에 해당한다. 그러나 이런 초기 변환 단계는 비교적 규모가 작은 단계에 속하며 따라서 추후 업데이트가 필요할 일도 훨씬 적다.

전반적인 대규모 변환(T)에서 소규모의 빠른 변환(t)으로
초기 변환 단계가 끝나면, 나머지 변환 과정은 쿼리 타임으로 이전시키는 것이 이상적일 것이다. 그러나 데이터 용량이 클 경우 기존의 데이터웨어하우스 속도로는 데이터 변환과 쿼리를 동시에 진행하는 것이 무리다(게다가 비즈니스 로직을 관리하고 이를 피플 쿼리로 부과할 수 있는 방법을 필요로 하기도 하고 말이다).

이로 인해 점점 더 많은 기업이 변환 단계 전체를 쿼리 타임으로 이전시키는 대신, 대부분의 변환을 적재 단계 바로 직후에 하는 방식을 택하고 있다. 이런 방식은 예전 시스템보다 훨씬 큰 민첩성을 허용하면서도 괜찮은 결과물을 내어 놓고 있기 때문이다. 적어도 현재로써는 이런 식으로 변환이 이뤄지고 있으며 이러한 변환 단계를 가리켜 대문자 T를 사용해 표현했다.

한편 가벼운 변환 작업들, 웨어하우스에서 바로 처리할 수 있는 변환은 쿼리 타임과 동시에 진행되고 있다. 이런 가벼운 변환 단계를 소문자 t를 써서 표현한 것이다. 그러나 이는 전적재 과정의 't(변환)'와는 전혀 다른 곳에 초점을 맞추고 있다. 왜냐하면 이 변환 단계에서는 새로운 메트릭스 프로토타입이나 즉흥적인 탐색이 이뤄지므로 쿼리 타임 가공이 제공하는 완전한 유연성이 요구되기 때문이다.

다시 말해, 우리는 현재 애널리틱스를 더욱 유연하고, 반응적이며, 효율적으로 만들 수 있는 새로운 기술을 이용한 거대한 변화를 목격하고 있다. 그 결과 그 전까지 느리고, 액세스할 수 없으며, 최악의 경우 오류가 있었던 데이터를 이용해 더 나은 판단을 내릴 수 있게 되었다. 또한 이런 변화를 수용한 기업들은 아직도 옛날 방식에 사로잡혀 있는 경쟁 기업들보다 앞서 나가기 시작했다. 우리가 알던 그 ETL은 죽었다. 하지만 EtLTt(?)는 영원할 것이다. editor@itworld.co.kr  


ETL
2017.10.26

ETL 시대의 종말

Daniel Mintz | InfoWorld
추출(Extract), 변환(Transform), 그리고 적재(Load). 이렇게 보면 ETL(Extraction, Transformation, Loading)은 참 단순한 개념 같다. 그러나 데이터 파이프라인 관리 경험이 있는 사람은 이 단순해 보이는 이름 뒤에 얼마나 복잡한 과정이 숨겨져 있는지 알고 있다.

특히 엔지니어들의 머리를 쥐어 뜯게 만드는 것은 바로 '변환(transform)' 단계다. 여기서 변환이란 미변환 상태의 로우 데이터(raw data)를 정리, 필터링, 정형(reshaping)하고, 요약해 분석에 적합한 상태로 바꾸어놓는 과정을 일컫는다. ETL 과정에서 바로 이 단계가 가장 많은 시간과 에너지가 들어가며 대부분 실수가 발생하는 부분도 이 단계다.

ETL이 어렵다면 왜 이런 식으로 변환하는 것인가
간단히 말하자면 다른 방법이 없기 때문이다. 데이터웨어하우스는 소스 시스템에서 추출된 상태 그대로의 로우 데이터를 처리하지 못한다. 따라서 이런 데이터를 적재해 분석의 대상으로 삼기 위해서는 반드시 변환 단계가 필요하다.

하지만 여기에 들어가는 비용은 다양한 형태로 변환될 수 있는 로우 데이터를 유지하는 대신, 변환 과정을 거침으로써 데이터는 어느 정도의 유동성을 상실한 중간 단계 형태로 변화한다. 이를 통해 데이터 레솔루션(resolution)의 일부가 사라지고, 데이터에 현재 비즈니스 메트릭스를 적용하게 되며, 쓸모없는 데이터를 버리는 과정이 선행된다.

그리고 만일 이런 과정들 가운데 어느 하나라도 빠지거나 바뀌었다면, 예를 들어 이전까지는 하루 단위로 처리하던 데이터를 이제 시간 단위로 필요로 하게 되었거나, 메트릭 데피니션이 바뀌거나, '쓸모 없다'고 생각했던 데이터 중 일부가 필요한 것으로 변경된다면 데이터 변환 로직을 이에 맞춰 변화시키고, 데이터를 다시 프로세싱한 후 재적재해야 한다.

수일에서 수주일까지 걸릴 수 있는 과거 데이터 정제 과정
기존 ETL 시스템이 더할 나위 없이 훌륭한 시스템이라고는 아무도 말하지 않는다. 단지 우리에게 주어진 방법이 그것뿐이었다.

기술이 변화하고 이전에 우리를 제약하던 요소들이 사라짐에 따라 이상적인 상황에서, 즉 데이터웨어하우스가 거의 무제한적으로 빠르고, 데이터 사이즈나 형태를 막론하고 모든 데이터를 처리할 수 있다고 가정했을 때 어떻게 할 것인가를 생각해 볼 필요가 생겼다. 이렇게 이상적인 상황에서라면 데이터를 적재하기 전에 굳이 변환할 필요가 없을 것이다. 그저 데이터 추출 후 로우 데이터 상태 그대로 이를 적재하면 그만이다.

물론 이 경우에도 데이터 변환을 아예 안 할 수는 없을 것이다. 왜냐하면 정제되지 않은 저품질 데이터의 쿼리는 크게 비즈니스 가치가 있는 결과물을 내기 어렵기 때문이다. 그러나 데이터웨어하우스의 속도가 매우 빠르기 때문에 쿼리와 거의 동시에 데이터 변환이 이뤄질 것이다. 사실상 데이터 변환과 쿼리가 하나의 단계로 통합되는 것이다. 그리고 바로 이런 맥락에서 등장한 것이 ELT이다.

이런 상상 속 시스템이 갖는 장점은 분명하다. 어떤 데이터를 버릴 지, 어떤 메트릭 데피니션 버전을 사용할 지를 미리 결정해 리스크를 질 필요가 없다는 것이다. 언제나 가장 새로운 버전의 변환 로직을 이용할 수 있을 것이고 ELT는 완벽한 유연성과 애질리티를 보장받게 될 것이다.

ELT로의 전환이 필요한가
현실은 얼마나 이상에 가까운가? 과연 ELT로의 전환이 필요한가? 사실 현실은 이상과 완벽히 부합한다고 하기는 어렵다. 물론 과거에 비하면 데이터웨어하우스가 훨씬 더 빠르고 싸진 것은 확실하다. 한 번 데이터를 변환하려면 몇 시간의 시간이 걸리고 수천 달러의 비용이 들어가던 것이 이제는 수초 만에, 불과 몇 센트의 비용으로 가능해졌기 때문이다. 그렇다고 해도 여전히 불량 데이터나 처리량 과다로 인해 시스템이 느려지는 일은 발생한다.

따라서 아직도 웨어하우스 외부에서 처리해야만 하는 변환 단계가 존재한다는 사실은 부정할 수 없을 것 같다. 관계없는 불순물 데이터를 제거하고, 대략적인 정형을 거치는 과정은 여전히 전적재(preloading) 과정에 해당한다. 그러나 이런 초기 변환 단계는 비교적 규모가 작은 단계에 속하며 따라서 추후 업데이트가 필요할 일도 훨씬 적다.

전반적인 대규모 변환(T)에서 소규모의 빠른 변환(t)으로
초기 변환 단계가 끝나면, 나머지 변환 과정은 쿼리 타임으로 이전시키는 것이 이상적일 것이다. 그러나 데이터 용량이 클 경우 기존의 데이터웨어하우스 속도로는 데이터 변환과 쿼리를 동시에 진행하는 것이 무리다(게다가 비즈니스 로직을 관리하고 이를 피플 쿼리로 부과할 수 있는 방법을 필요로 하기도 하고 말이다).

이로 인해 점점 더 많은 기업이 변환 단계 전체를 쿼리 타임으로 이전시키는 대신, 대부분의 변환을 적재 단계 바로 직후에 하는 방식을 택하고 있다. 이런 방식은 예전 시스템보다 훨씬 큰 민첩성을 허용하면서도 괜찮은 결과물을 내어 놓고 있기 때문이다. 적어도 현재로써는 이런 식으로 변환이 이뤄지고 있으며 이러한 변환 단계를 가리켜 대문자 T를 사용해 표현했다.

한편 가벼운 변환 작업들, 웨어하우스에서 바로 처리할 수 있는 변환은 쿼리 타임과 동시에 진행되고 있다. 이런 가벼운 변환 단계를 소문자 t를 써서 표현한 것이다. 그러나 이는 전적재 과정의 't(변환)'와는 전혀 다른 곳에 초점을 맞추고 있다. 왜냐하면 이 변환 단계에서는 새로운 메트릭스 프로토타입이나 즉흥적인 탐색이 이뤄지므로 쿼리 타임 가공이 제공하는 완전한 유연성이 요구되기 때문이다.

다시 말해, 우리는 현재 애널리틱스를 더욱 유연하고, 반응적이며, 효율적으로 만들 수 있는 새로운 기술을 이용한 거대한 변화를 목격하고 있다. 그 결과 그 전까지 느리고, 액세스할 수 없으며, 최악의 경우 오류가 있었던 데이터를 이용해 더 나은 판단을 내릴 수 있게 되었다. 또한 이런 변화를 수용한 기업들은 아직도 옛날 방식에 사로잡혀 있는 경쟁 기업들보다 앞서 나가기 시작했다. 우리가 알던 그 ETL은 죽었다. 하지만 EtLTt(?)는 영원할 것이다. editor@itworld.co.kr  


ETL
X