9:23

먼저 공격을 해보도록 하겠습니다. 여기서 목차는 다음과 같고요. 먼저 데이터 웨어하우스의 정의, 그리고 이게 왜 필요한지에 대해서 공부를 하고 그 다음에 이것을 모델링하는 방법에 대해서 공부를 해볼 거고요. 그리고 데이터 웨어하우스에서 데이터에 대한 다차원적인 분석을 진행하는 OLAP 오퍼레이션에 대해서 공부를 하겠습니다.

그리고 마지막으로 우리가 간단히 개념적으로만 배웠던 데이터 큐브의 계산과정과 방법들에 대해서 추가적으로 공부를 해보도록 하겠습니다. 먼저 데이터 웨어하우스가 무엇인지 그리고 이것이 왜 필요한지 그리고 데이터 웨어하우스의 아키텍처가 어떻게 되어 있는지를 공부해볼 거고요. 그리고 데이터 웨어하우스 말고 데이터 레이크라는 개념도 있는데 어떤 특성을 각각 가지고 있고 어떤 차이점이 있는지까지 한번 공부해보도록 하겠습니다.

먼저 데이터 웨어스가 무엇인지에 대해서 설명을 드리도록 하겠습니다. 우리가 일반적으로 업무에 사용하는 데이터베이스들이 있습니다. 이것을'Operational Database'라고 일반적으로 말을 하고 있고요. 이 Operational Database는 실제 어떤 업무를 처리하기 위해서 사용이 됩니다.

예를 들어서 어떤 어플리케이션을 우리가 운영을 한다고 하면은 그 어플리케이션에서 어떤 거래가 진행될 수도 있고요. 그리고 어떤 예를 들어서 판매, 그리고 구매, 아니면 어떤 물품을 판다고 했을 때 장바구니 같은 기능, 이런 기능들을 구현하려면 그에 대한 데이터를 저장하고 그 데이터를 불러올 수 있는 그런 시스템이 필요하죠. 그렇게 일상적으로 사용되는 그런 데이터베이스 시스템을 오퍼레이션을 데이터베이스라고 하고요.

그런데 데이터 웨어하우스는 이런 일반적인 DB와 다른 목적을 가지고 있습니다. 그래서 이런 일상적인 업무 처리가 아니고 어떤 중요한 의사결정을 지원하고요. 그리고 데이터를 통계적으로 분석하기 위해서 이런 기존의 데이터베이스와 분리돼서 운영되는 그런 특징을 가지고 있습니다. 왜 분리되서 운영되어야 하냐 라고 하면은

이 웨어하우스가 다루는 데이터의 특징이 일반적인 DB와 차이가 있기 때문인데요. 예를 들어서 데이터 웨어하우스는 어떠한 어플리케이션 단위, 어떠한 업무 단위의 데이터만 필요한게 아니라 여러 데이터베이스에 있는 데이터들을 모두 모아서 분석을 할 필요가 있겠죠. 그래서 통합된 데이터가 필요하다는 특징을 가지고 있고요. 그리고 두 번째로 어떤 분석을 하기 위해서는 실시간으로 들어오는 데이터뿐만 아니라

그 데이터를 시간축으로 누적해서 우리가 가지고 있어야지 조금 더 체계적인 분석이 가능합니다. 그래서 히스토리컬 데이터가 필요하다 라는 이러한 차이점을 가지고 있습니다. 그래서 데이터 웨어하우스의 특징을 간단히 정리하자면 다음과 같은 4가지의 특성으로 요약할 수 있는데요. 첫번째로 이제 서브젝트 오리엔티드 즉 어떤 대상 중심의 데이터를 가지고 그 데이터를 처리한다는 특성을 가지고 있고요.

두 번째로 통합되어 있다는 특징을 가지고 있고 세 번째로 시간에 따라 변화한다는 특징을 가지고 있고 마지막으로 비휘발성이다. 이러한 네 가지 특징을 가지고 있습니다. 이 각가지 특징에 대해서는 뒤에서 하나씩 조금 더 구체적으로 설명을 드리도록 하겠습니다. 그래서 결국에 이 목적은 어떤 결정을 하는 과정에 의사결정 과정을 도와주기 위해서 사용이 되는 그런 데이터들을 의미한다 라고 생각할 수 있습니다.

그리고 데이터 웨어하우징 이라는 말이 있는데요. 이것은 이러한 데이터 웨어하우스를 구성하는 그러한 프로세스를 의미합니다. 그러면 일반적인 Operational Database와 구별되는 이러한 데이터 웨어워스의 특징을 하나씩 설명드리도록 하겠습니다. 먼저 Subject Oriented라는 특징입니다. 기존 일반적인 데이터베이스 같은 경우에는 아까 말씀드렸던 것처럼 어떤 업무 단위로 구성이 되어 있거나 혹은 특정한 어플리케이션 단위로 구성이 되어 있습니다.

그런데 데이터 웨어워스에서는 데이터가 이런 업무 단위가 아니고 어떤 분석의 대상 단위로 구성되어 있다. 그렇게 조직화되어 있다는 특징을 가지고 있습니다. 예를 들어서 우리가 고객에 대한 분석을 수행하고 싶다 라고 하면 데이터들이 그 고객을 중심으로 조직화가 되어 있고요. 우리가 프로덕트에 대해서 분석을 하고 싶다 라고 하면 어떤 상품을 기준으로 이 데이터가 저장되어 있다.

구조화 되어 있습니다. 예를 들어서 상품을 기준으로 집계함수가 구성이 되어 있거나 이러한 식으로 결국에는 이제 서브젝트를 기준으로 데이터가 구성되어 있다는 특징이 첫 번째입니다. 그래서 이제 두 번째 줄에 나와 있는 것처럼 데이터 웨어워스는 일상적인 어떤 업무 처리나 이런 거래를 다루는 것이 아니고요. 디시저 메이커 결정을 하는 사람이 데이터를 잘 분석할 수 있도록 모델리게 해주는 것을 목표로 하기 때문에 이런 식으로 구성이 되어 있습니다.

그리고 또한 우리가 저장된 많은 데이터 중에 특정한 분석을 할 때 별로 필요 없는 이러한 데이터들도 많이 있겠죠. 그럼 여기서는 이제 우리가 분석이 되는 서브젝트를 기준으로 데이터를 조직하기 때문에 그 분석이 필요 없는 데이터들은 사용자에게 보여주지 않습니다. 그래서 이렇게 별로 이 주제와 관련 없는 데이터들은 제외 되거나 할 수 있습니다.

두 번째 특징은 integrated 인데요. 특정한 하나의 데이터 소스로부터 온 데이터만 활용하는게 아니고요. 여러 데이터 소스에서 온 그런 데이터를 통합해서 활용한다는 특징을 가지고 있습니다. 기존에 우리가 일상적으로 사용하는 여러 데이터베이스에서 데이터를 가져올 수도 있고요. 아니면 별도로 된 추가적인 파일에서 데이터를 얻어올 수도 있고 아니면은 온라인 트랜잭션 레코드 실시간 레코드로부터 데이터를 수집을 할 수도 있습니다.

여기서는 우리가 앞에서 배웠던 것처럼 결국엔 데이터 통합을 위해서는 데이터 클렌징과 데이터 통합과정이 함께 적용이 됩니다. 그래서 서로 다른 데이터 소스에서 데이터를 가져오게 되면 데이터의 형식이 일반적으로 일치하지 않는 경우가 많이 생깁니다. 그래서 네이밍 컨벤션 혹은 어떤 인코딩 구조 그리고 아니면 어떤 특정 지표 등을 통일을 시켜줘야 됩니다.

예를 들어서 다양한 데이터 소스에서 호텔 가격이라는 동일한 데이터를 가져온다 라고 했을 때 데이터 소스마다 어떤 통화를 사용할지 세금이 포함되어 있는지 아니면 아침 식사가 포함되어 있는지 등등 이러한 정보들이 다 다를 수 있겠죠. 하나의 형태로 통일해서 데이터를 저장을 해줘야 됩니다. 다음은 Time Variant 인데요. 일반적인 Operational Database 같은 경우에는 실시간 데이터를 처리하는 것에 중점을 둡니다.

최근 데이터를 어떻게 처리를 하고 어떻게 다뤄야 할지 예를 들어서 거래가 발생했으면 그래서 일반적인 데이터베이스는 실시간 데이터만 일반적으로 저장을 많이 하고요. 그래서 최근에 데이터만 저장을 하고 있다가 그 데이터가 갱신이 되면은 새로 업데이트를 하는 이러한 방식을 주로 많이 사용을 합니다. 하지만 데이터 웨어워스 같은 경우에는 분석이 주 목표이기 때문에 이전의 데이터도 우리가 분석을 위해서는 충분히 많이 활용을 해줄 수 있습니다.

그래서 더 긴 기간의 데이터를 저장한다는 특성을 가지고 있습니다. 예를 들어서 5년, 10년 지난 이런 데이터들은 사실 일반적인 DB에서는 잘 저장을 하지 않는데 데이터 웨어하우스에서는 이런 데이터도 유용하게 활용될 수 있습니다. 이렇다 보니까 데이터 웨어하우스에서는 어떤 시기에 데이터가 들어왔느냐, 데이터가 언제 데이터냐는 시간에 대한 정보가 굉장히 중요한 정보에 해당이 됩니다.

그렇기 때문에 명시적으로든 혹은 감시적으로든 어떠한 방식으로든 이런 시간 데이터가 항상 같이 데이터에 표현이 되어 있어야 합니다. 하지만 일반적인 데이터베이스 같은 경우에는 사실 이러한 누적된 시간이라는 정보가 크게 중요하지 않습니다. 그래서 일반적으로 이러한 시간에 대한 킷값을 가지고 있지 않는 경우가 많이 있습니다.

그래서 이게 좀 중요한 차이점 중의 하나다 라고 생각을 해 줄 수 있습니다. 다음에는 run-verutal 이라는 특징이 있구요. 이것은 이제 어떠한 데이터가 앞서 설명드렸던 것과 유사한 개념일수도 있는데 누적되어서 저장이 된다는 것을 의미합니다. 즉 비휘발성이니까 휘발성이라는 것은 어떠한 데이터가 빨리빨리

사라진다는 것을 의미하죠. 그래서 데이터가 사라지지 않고 계속 축적되서 저장된다는 의미입니다. 그래서 일반적으로 이 데이터 웨어하우스는 우리가 실제로 이걸 사용하는 어떤 운영환경과 독립적으로 구성이 되어 있습니다. 그래서 실제 운영환경에서는 예를 들어서 어떠한 주문이 들어왔을 때 주문이 취소되거나 주문이 변경되거나 하게 되면 그에 따른 데이터가 바로바로 제거되거나 업데이트 되거나 변경되거나 하는 데이터의 변경이 굉장히 많이 발생이 됩니다.

하지만 데이터 웨어하우스는 이러한 시스템에서 독립적으로 구성이 되어 있고요. 그래서 실제 운영 환경에서 발생한 데이터를 데이터 웨어수으로 그냥 옮기는 작업을 수행하게 됩니다. 그렇기 때문에 이런 실제 주문 취소, 주문 변경과 같은 이러한 변경이 발생을 하더라도 데이터 웨어수에 있는 데이터는 변경되거나 아니면 제거되거나 하지 않습니다.

계속 그 상태를 누적해서 저장을 한다는 특징을 가지고 있습니다. 그래서 이러한 데이터 웨어하우스의 데이터는 잘 업데이트 되지 않는다는 특징을 가지고 있기 때문에 아래와 같이 데이터를 실제로 웨어하우스에 있는 데이터를 업데이트하거나 변경할 일이 없으니까 동시에 이러한 업데이트가 진행될 확률이 굉장히 적습니다.

그래서 이후에 조금 더 자세하게 배우겠지만 어떤 업데이트를 동시에 만약에 진행을 했을 때 우선권을 누구에게 줄 건지 아니면 동시에 업데이트가 돼서 충돌이 발생할 경우에는 이것을 어떻게 해결해야 될지 이러한 문제가 사실 일반적인 데이터를 위해서 굉장히 중요하게 다뤄야 할 그런 문제인데 웨어하우스에서는 그러한 것들을 거의 고려할 필요가 없습니다. 어차피 데이터를 업데이트 하는 경우는 거의 없고

데이터를 저장하거나 읽거나 하는 경우만 거의 있기 때문에 이러한 트랜잭션 처리 그리고 어떤 충돌이 발생했을 때 이것을 회복을 어떻게 할 건지 그리고 이러한 동시성을 어떻게 통제를 할 건지 이에 대한 것들은 이제 거의 많이 고려되지 않는다 라는 특징을 가지고 있습니다. 그래서 사실 대부분 두 가지의 오퍼레이션만 주로 활용이 되는데요. 첫번째는 이제 로딩 데이터를 저장하는 오퍼레이션

두번째는 데이터에 접근해서 데이터를 가져오는 오퍼레이션 거의 두 가지만 수행이 된다 라고 생각을 해 줄 수 있습니다. 구체적으로 OLTP랑 OLH라는 개념을 통해서 조금 더 이런 과정을 비교해서 알아보도록 하겠습니다. 먼저 OLTP라는 것은 일상적인 업무 처리를 하는 것을 의미합니다.

데이터베이스를 사용해서 주문, 결제와 같은 일반적인 업무를 처리하는 과정을 의미하고요. 이때는 데이터 웨어워스가 일반적으로 사용되지 않고요. 일반적인 데이터베이스가 사용됩니다. 여기서 나온 DBMS라는 것은 데이터베이스를 관리하고 운영하는 시스템을 의미합니다. 데이터베이스 매니지먼트 시스템이라는 것이 DBMS고요.

그래서 그 DBMS에서 제공하는 여러가지 오퍼레이션 등, 예를 들어서 데이터를 저장하고 변경하고 데이터를 불러오고 하는 그런 오퍼레이션을 주로 사용을 하고 있습니다. 그래서 이때 사용하는 게 쿼리입니다. 예를 들어서 사용자가 이 데이터를 변경해줘 라는 쿼리를 데이터베이스에 전달하게 되면 이러한 쿼리를 처리하는 과정을 진행하고요.

그리고 아까 말씀드렸던 것처럼 이러한 업데이트가 굉장히 빈번하게 발생하기 때문에 동시에 이런 업데이트를 처리하는 경우도 많이 생깁니다. 혹은 그런 업데이트가 중간에 진행되다가 중간에 어떤 충돌이 발생되거나 해서 완료되지 못하는 이러한 경우가 생길 수도 있죠. 그래서 이러한 것들을 어떻게 처리할지 이러한 트랜잭션 처리 그리고 충돌이 발생했을 때 어떻게 이것을 회복시킬지 이러한 것들을 중점적으로 다루고 있습니다.

OLAP 같은 경우에는 이런 일상적인 업무 처리가 아니고 데이터 분석을 하는 그런 과정을 의미합니다. 그래서 데이터 분석을 수행을 하니까 데이터 웨어하우스를 활용을 하게 되고요. 여기서 제공하는 우리가 뒤에서 공부할 다양한 오퍼레이션을 사용을 해서 이런 데이터 분석을 진행을 해주게 됩니다. 그래서 뭐 드릴링, 슬라이싱과 같은 이러한 뭐 오퍼레이션들이 있는데

이것을 뒤에서 한번 공부해볼 예정입니다. 그래서 이 두 가지를 좀 더 디테일하게 오른쪽 표를 통해서 한번 비교해보도록 하겠습니다. OLTP 같은 경우에는 일상적인 업무를 처리하는 거니까 일반적인 사원이나 아니면 데이터베이스를 관리하는 이런 IT 전문가가 일반적으로 활용을 하고 있고요. 그래서 일상적인 오퍼레이션, 일상적인 업무를 처리하기 위한 그러한 기능을 많이 활용을 합니다.

그리고 이런 업무 처리를 해야 되니까 이 데이터베이스가 이런 실제 업무를 처리하기 위한 어플리케이션을 기반으로 많이 구성이 되어 있습니다. 그래서 예를 들어서 어떤 판매 업무라고 하면 그 판매와 관련된 그런 데이터베이스가 구성이 되어 있고요. 고객 관리라고 하면은 그런 고객 관리를 위한 데이터베이스가 구성이 되어 있고 특정한 업무나 어플리케이션을 기준으로 데이터베이스가 일반적으로 구성이 되어 있습니다.

그리고 데이터는 일반적으로 최근 데이터를 많이 활용하겠죠. 실제 업무를 처리하기 위한 데이터는 최근 데이터니까 최근 데이터들을 많이 활용을 하고 있습니다. 반면에 OLAP는 이제 어떠한 의사결정 혹은 데이터 분석을 수행을 하는 그런 과정이기 때문에 일반적으로 이제 knowledge walker 많이 사용을 하고요

그래서 의사결정을 서포트하는 기능을 가지고 있습니다. 데이터베이스가 아까 설명드렸던 것처럼 어떤 특정한 업무나 어플리케이션을 기반으로 구성되어 있는 게 아니고 우리가 분석해야 될 대상을 기준으로 설정이 되어 있습니다. 그리고 분석을 위해서는 이러한 현재 데이터가 필요한 게 아니라 누적된 히스토리컬 데이터가 필요하고요. 그리고 요약된 데이터 혹은 다차원적으로 분석이 가능한 이러한 데이터들을

포함을 하고 있습니다. 그리고 사용 측면에서 보면은 이 OLTP 같은 경우에는 결국에는 짧고 쉽게 처리할 수 있는 이러한 반복적인 업무를 주로 많이 수행합니다. 사실 예를 들어서 주문 아니면 환불과 같은 이렇게 이미 정의되어 있는 그런 단순한 업무를 반복적으로 동일한 업무를 주로 수행하는 경향이 있다는 특징을 가지고 있고요.

그리고 이러한 업무를 수행하기 위해서는 반복적으로 데이터를 읽고 또 쓰고 하는 과정이 진행이 되어야 됩니다. 반면에 OLAP 같은 경우에는 어떤 특정한 짧은 과정이 반복적으로 진행되는 것은 아니고요. 데이터 분석을 하기 위해서는 굉장히 복잡한 커리를 처리해야 되는 그러한 과정이 필요하게 됩니다.

그렇기 때문에 반복적으로 미리 정해진 업무를 처리하는게 아니라 add home 이라고 해서 특정한 쿼리가 들어왔을 때 그 쿼리를 하나하나씩 처리하는 특징을 가지고 있습니다. 그래서 미리 어떤 업무를 정의해서 그걸 가져와서 반복적으로 수행하는 게 아니라 항상 쿼리가 어떠한 분석을 할지 나타내는 그런 쿼리가 달라지기 때문에 그 쿼리에 맞춰서 항상 그 쿼리를 처리를 한다 라는 특징을 가지고 있습니다.

그리고 데이터 분석을 수행을 할 때는 사실 읽고 쓰고 하는 과정을 반복적으로 수행을 하는 것이 아니고요. 많은 데이터를 한 번에 스캔해서 가져와서 그 많은 데이터에 대한 분석을 한 번에 진행을 하게 되죠. 그래서 많은 스캔이 진행이 됩니다. 그리고 마지막으로 OLTP 같은 경우에는 어떤 짧고 이런 간단한 트랜잭션을 주로 수행을 하기 때문에

레코드에 접근하는게 일반적으로 비교적 더 적습니다. 적은 레코드에 접근을 해서 빨리빨리 데이터를 처리하는 것을 주 목적으로 가지고 있고요. 반면에 OLAP 같은 경우에는 데이터 분석을 수행해야 되니까 많은 레코드에 접근을 해서 그 데이터들을 모두 가져와야겠죠. 그래서 데이터에 대한 접근이 굉장히 많이 발생하게 됩니다.

사용하는 유저 같은 경우에는 OLTP 같은 경우에는 일상적인 업무를 처리를 해야 되니까 그런 시스템을 사용하는 유저가 굉장히 비교적 많겠죠. 그래서 사용하는 유저의 수가 더 많고요. 이 분석을 사실 실제로 수행하는 유저의 수는 상대적으로 적기 때문에 더 적은 유저 수를 일반적으로 가지고 있습니다. 그리고 데이터베이스 사이즈 같은 경우에도

OLTP 같은 경우에는 데이터 사이즈가 비교적 적어도 되겠죠. 실시간 처리를 목적으로 하고 있기 때문에 적은 데이터만 있어도 일반적인 업무는 모두 처리가 가능한데 비해서 OLAP 같은 경우에는 일단 데이터도 누적해서 가지고 있고요. 분석을 위해서는 데이터가 많을수록 유리하기 때문에 저장된 데이터가 굉장히 크다는 차이점을 가지고 있습니다. 그리고 마지막, 평가 매트릭에서도 차이가 있는데요.

OLTP 같은 경우에는 결국은 처리량이 중요합니다. 단위시간당 얼마나 많은 거래, 업무를 처리할 수 있는지 그러한 처리량이 중요한데 반해서 OLAP 같은 경우에는 우리가 쿼리를 굉장히 복잡하게 주죠. 그래서 그 복잡한 쿼리를 얼마나 빨리 처리할 수 있느냐를 중점으로 평가를 진행을 합니다. 또한 어떤 리스폰스가 왔을 때 그런 분석이 얼만큼 잘 진행되었는지 그 분석의 정확도, 분석의 퀄리티 등을 기반으로 이제 평가를 진행을 하게 됩니다.

- Okay. 일반적으로 이러한 OLTP 그리고 OLAP 업무는 서로 다른 특징을 가지고 있기 때문에 서로 독립적으로 최적화되는 것이 더욱 유리합니다. 그래서 일반적으로

이 OLTP는 우리가 많이 사용하는 DBMS를 통해서 처리가 됩니다. 그래서 DBMS는 일반적으로 이러한 OLTP 업무에 특화되어서 최적화됩니다. 그래서 여기서 주로 필요한 기능은 데이터에 대한 접근 그리고 데이터를 빨리 처리하기 위한 인덱시 그리고 아까 말씀드렸던 것처럼 동시에 어떤 업데이트 혹은 데이터에 대한 처리가 발생을 했을 때

그 동시성을 어떻게 처리하고 어떻게 충돌이 발생할 때 회복할지에 대한 그런 것에 최적화하고 반면에 웨어하우스 같은 경우에는 OLAP라는 분석에 최적화되서 서로 독립적으로 구성이 됩니다. 그래서 웨어하우스는 복잡한 쿼리를 처리하고요. 다차원적인 분석을 수행하고 어떤 분석을 위한 집계를 수행하는 업무에 최적화되어서 구성이 됩니다.

그리고 또한 웨어하우스가 다루는 데이터는 차별화된 특징을 가지고 있기 때문에 역시 이러한 데이터를 다루기 위해서 이 웨어하우스가 서로 독립적으로 이렇게 구성이 되어야 됩니다. 그래서 아래의 특징은 사실 계속 반복적으로 설명을 해드렸던 거기 때문에 조금 생략을 하고요. 여기서 데이터 컨솔리데이션이라는 것은 일반적으로 데이터를 분석을 하기 위해

그 전 단계로 어떤 데이터에 대한 집계를 수행을 하거나 데이터의 정보를 요약하는 그런 과정을 의미합니다. 그래서 웨어워스 같은 경우에는 데이터 분석을 위해서 이러한 집계 과정을 미리 수행을 해준다 라는 특징을 가지고 있고요. 그리고 마지막 데이터 퀄리티 같은 경우에는 데이터 웨어하우스는 여러 데이터 소스로부터 데이터를 가져오기 때문에

어떤 특징 정보나 아니면 그 형식이 다를 수 있죠. 그래서 그 형식을 일관되게 맞춰주는 것을 의미합니다. 그래서 데이터를 통일화해서 데이터 퀄리티를 일정하게 유지한다는 특성을 가지고 있습니다. 그래서 일반적으로 이러한 DBMS는 OLTP를 처리하기 위해 사용이 많이 전통적으로 됐고요. 그리고 전통적으로 웨어하우스는 OLAP를 처리하기 위해 몇 개의 구성이 됐는데

사실 최근에는 이 경계가 많이 허물어지고 있습니다. 그래서 DBMS도 어떤 데이터 분석을 위한 그런 기능들을 많이 제공을 해주고 있고요. 웨어하우스도 이런 동시성 처리나 트랜잭션 처리에 대한 원래 기존에 없던 이러한 기능을 많이 추가를 해서 실제 업무 처리에서도 활용할 수 있게 이렇게 서로 확장이 되고 있습니다. 최근에는 DBMS를 통해서 일상적인 업무 처리와 데이터 분석을 함께 진행하기도 합니다.

그래서 전통적으로는 이런 식으로 구분이 되어 있다 정도로 알아두시면 좋을 것 같습니다. 다음은 이 웨어하우스 모델을 세 가지로 한번 구분을 해 보도록 하겠습니다. 첫 번째 웨어하우스 모델은 엔터프라이즈 웨어하우스입니다. 엔터프라이즈 웨어하우스는 전사적으로 구성된 웨어하우스를 의미합니다.

그래서 조직 전체와 관련된 다양한 주제와 분석 대상이 있겠죠. 그런 분석, 모든 분석 대상에 대한 데이터를 한 번에 다 저장해 놓은 그러한 웨어하우스를 의미합니다. 그래서 일반적으로 어떤 전사적인 의사결정을 지원하기 위해서 이런 엔터프라이즈 웨어하우스를 많이 활용을 하고 있습니다. 두 번째 데이터 마트 같은 경우에는 특정한 구석 혹은 특정한 그룹에 따로 구성이 되어 있는 이러한 웨어하우스를 의미를 합니다.

그래서 일반적으로 조금 더 구체적이고 어떤 그룹에 해당 어떤 특정한 그룹에만 해당되는 그러한 주제에 대한 데이터만을 저장하고 있다는 그런 것입니다. 특성을 가지고 있습니다. 예를 들어서 마케팅 부서다 라고 하면은 마케팅에 필요한 그런 데이터 마트를 구성할 수 있습니다. 그래서 마케팅에 필요한 정보는 거래 내역이 있을 수도 있고요.

고객의 개인 정보들이 있을 수도 있겠죠. 그래서 그러한 데이터들만 모아서 마케팅 데이터 마트를 따로 구성을 할 수 있습니다. 이러한 데이터마트 같은 경우에는 크게 두 가지로 구분을 할 수 있는데요. 첫 번째로 이 데이터마트에 포함되어 있는 데이터가 엔터프라이즈 웨어하우스에서 모두 가져온 데이터로만 구성이 되어 있다고 하면은

즉 데이터마트가 엔터프라이즈 웨어하우스의 부분집합이라고 할 수 있겠죠. 이러한 경우에 이제 independent 데이터마트라고 하고요. 이러한 데이터마트가 부서마다 어떤 독립적인 데이터로 구성이 된다 라고 했을 때는 independent 데이터마트 라고 할 수 있습니다. 그래서 결국에는 이 데이터를 독립적으로 수집을 해서 자체적으로 가지고 있는지

아니면 엔터프라이즈 웨어하우스에서 그냥 가져온 데이터로 구성이 되어 있는지에 따라서 이 두 가지로 구분을 할 수 있습니다. 마지막으로 버추얼 웨어하우스가 있습니다. 버추얼 웨어하우스는 어떤 물리적으로 웨어하우스를 구성을 하는 것은 아니고요. 우리가 일상적으로 활용하는 오퍼레이션을 데이터베이스를 기반으로 가상의 웨어하우스를 만든 것을 의미합니다.

데이터베이스에는 뷰라는 기능이 있는데요. 뷰는 실제 물리적으로 저장되어 있는 데이터를 기반으로 해서요. 우리가 필요한 정보들을 모아서 가상의 테이블을 만들어서 우리에게 보여주는 것을 의미합니다. 즉,'View'는 가상의 테이블을 의미하기 때문에 이'View'에 저장되어 있는 데이터 구조는 실제 데이터가 저장되어 있는 구조와는 다를 수 있습니다.

하지만 마치 우리는 데이터가 그러한 형식으로 저장되어 있는 것처럼 뷰를 통해서 그러한 데이터를 보고 접근할 수 있습니다. 그래서 결국에 이 뷰라는 기능을 활용을 해서 우리가 실제 데이터 웨어하우스를 구성한 것처럼 우리가 만들어줄 수 있겠죠. 이러한 방식을 Virtual Warehouse 라고 하고요. 그리고 만약에 우리가 어떤 뷰를 통해서

데이터를 집계하거나 뭐 이렇게 구성을 했는데 어 그러한 구성이 굉장히 유의미하다 라고 했을 때는 그 뷰를 실제로 물리적으로 반영해서 저장을 할 수도 있습니다. 즉, 원래 우리가 보는 뷰는 가상의 어떤 테이블이지만 이것을 실제 저장된 테이블이 되도록 저장하는 이러한 과정을 수행을 할 수 있구요 그것을 Materializing 이라고 일반적으로 부르고 있습니다.

다음은 데이터 웨어워스의 구조를 살펴볼 건데요. 일반적으로 오른쪽처럼 여러 계층으로 구성이 되어 있습니다. 먼저 가장 아래쪽부터 살펴보면 가장 아래쪽에서는 우리가 사용하는 여러 개의 데이터베이스 그리고 혹은 외부 소스로부터 데이터를 수집하는 이러한 단계에 해당이 됩니다. 그래서 이 수집된 데이터를 이 위에 나와 있는 것처럼

Extract, Clean, Transform, Load, Refresh라는 이러한 과정을 거쳐서 이렇게 데이터 웨어하우스에 저장을 해주게 됩니다. 이 다섯 개의 과정을 이 뒤에서 조금 더 구체적으로 알아보도록 하겠습니다. 그 다음에 데이터 웨어하우스의 가장 아래에 있는 계층은 데이터 웨어하우스 서버에 해당합니다. 그래서 어떤 데이터를 저장하고

관리하는 그러한 기능을 여기서 수행합니다. 그래서 이 계층에 데이터 웨어하우스가 존재하고요. 그리고 실제 데이터 마트 등도 여기에 위치하게 됩니다. 또한 우리가 저장된 데이터의 저장 구조 혹은 저장 형식 등을 보관하고 있는 메타 데이터 리포지터리 도 여기에 저장이 되어 있습니다. 그래서 이러한 데이터 웨어하우스를 통해서 데이터를 관리하는 과정을

가장 하위 계층에서 수행을 하게 됩니다. 그 다음 중간 계층에는 OLAP 서버가 위치합니다. 그래서 실제로 데이터, 우리가 데이터 웨어하우스에 있는 데이터를 가져와서 다차원적인 분석을 수행하고요. 그리고 유저의 커리를 여기서 처리하는 작업을 수행합니다. 그래서 여기서 실제 분석 과정이 수행된다고 생각을 해 줄 수 있습니다.

그 다음 가장 상위 티어는 프론트엔드 툴이 있습니다. 즉 유저와 직접 소통을 하는 인터페이스가 여기에 구축이 되어 있습니다. 그래서 유저에게 직접 커리를 받고요. 분석 결과를 리포트하는 그러한 과정이 여기에 해당이 됩니다. 그래서 실제 분석 결과를 시각화해서 보여주는 이러한 기능이 가장 상위 계층에 포함될 수도 있습니다.

그럼 가장 아래에서 여러개의 데이터 소수로부터 데이터를 수집해서 데이터 웨어하우스에 저장하는 과정에 대해서 조금 더 구체적으로 알아보도록 하겠습니다. 첫번째 과정은 이 과정을 요약해서 ETL이라고 일반적으로 많이 표현을 합니다. 그래서 ETL이라고 하면은 이렇게 여러 개의 소스로부터 데이터를 가져와서

데이터 웨어워스에 저장하는 과정을 의미하는구나 라고 알아두시면 됩니다. 첫 번째 과정은 데이터 익스트랙션인데요. 실제로 여러 개의 데이터 소스로부터 데이터를 가져오는 그러한 과정을 의미합니다. 그 다음에는 데이터를 그냥 가져오면 안되고 데이터 클리닝 과정을 수행을 하겠죠. 이 과정에서는 오류나 결칙지들을 수정을 하는 그런 과정에 해당이 되고요.

그 다음에는 트랜스포메이션 과정을 수행을 합니다. 그래서 데이터를 어떤 통일로 그리고 우리가 분석을 수행하기 위한 일관된 형식으로 변형하는 과정에 해당이 됩니다. 이 부분은 지난 시간에 배웠던 과정들과 동일합니다. 그 다음에 로드 같은 경우에는 실제 데이터를 저장하는 과정을 의미합니다. 여기서 실제 데이터를 저장을 할 때 그냥 저장하는 게 아니고요.

그 데이터에 정렬이 필요하다면 이 데이터에 정렬을 해서 저장을 하게 되고요. 그리고 요약을 하거나 집계함수를 수행을 하거나 어떤 뷰들을 미리 계산을 하거나 이런 과정을 미리 시행을 해두게 됩니다. 그리고 또한 어떤 무결성 혹은 제약 조건 등을 여기서 체크를 하게 되는데요. 예를 들어서 우리가 데이터베이스를 공부를 할 때

여러가지 무결성 제약 조건들이 있습니다. 프라이머리 키는 중복되서는 안된다. 유일한 값을 가져야 된다. 이러한 제약 조건이 있을 때 이러한 제약 조건을 실제로 데이터들이 만족하는지 여기서 최종적으로 확인하는 과정이 진행이 됩니다. 그리고 마지막으로 데이터에 빠르게 접근하기 위해서

이제 인덱스 등을 우리가 미리 만들어 줄 수 있고요 어떤 효율적인 파티션을 여기서 정의하는 이러한 종합적인 과정을 수행을 하게 됩니다 그래서 앞으로 데이터 분석이 원활하게 수행되기 위한 최종적인 전처리 작업들을 이 로드 과정에서 수행을 하고 최종적인 확인을 한다고 생각을 해줄 수 있습니다. 그래서 이 부분이 사실 데이터 웨어하우스의 특징이라고 생각할 수 있는데요.

우리가 이후에 공부해볼 데이터 웨어하우스는 데이터 레이크 같은 경우에는 이러한 전처리 작업을 데이터를 저장하기 전에 미리 수행하지 않습니다. 일단 데이터를 다 저장해놓고 실제 데이터의 분석을 수행할 때 그때 이런 전처리 작업을 수행을 하는데 비해서 이러한 데이터 웨어하우스는 미리 데이터를 저장하는 과정에서

이러한 전처리 작업, 데이터의 통합 작업 등을 미리 다 수행을 해 본다 라는 특징을 가지고 있습니다. 그리고 마지막 과정을 리프레쉬 인데요. 우리가 실제로 업무에 사용하는 그러한 Operational database, 혹은 원본 데이터 소스 같은 경우에는 주기적으로 그 데이터가 업데이트가 됩니다. 그러면 그 업데이트 된 데이터를 다시 웨어하우스에 반영하는 작업을 수행을 해야겠죠.

그래서 그 원본 데이터 소스에서 발생한 업데이트를 데이터 웨어하우스에 반영하는 작업을 리프레쉬라고 합니다. 다음으로 공부해볼 개념은 메타데이터 리포지털인데요.

이게 어디 있었냐면 앞에 그림에서 데이터 웨어워스, 데이터 마트와 같이 가장 하위 단계에 함께 저장되어 있습니다. 메타 데이터란 실제 우리가 사용하는 데이터 값을 의미하는게 아니고 그 데이터가 어떠한 형식으로 구성되어 있는지에 대한 정보를 의미합니다.

그래서 데이터 웨어하우스의 구조를 정의하는 데이터라고 생각을 해줄 수 있습니다. 그래서 대표적으로 어떤 것들이 저장이 되어 있냐 라고 하면은 이 메타 데이터에는 스키마 즉 표 형태로 데이터가 저장되어 있을 때 그 표 각각의 열의 이름이죠. 속성의 이름 그리고 속성이 어떤 형태인지

예를 들어서 수치형 데이터인지 카테고리컬 데이터인지 그 데이터의 형식을 나타내는 그러한 스키마 정보가 여기에 해당이 되고요. 그리고 우리가 아까 말했던 어떤 뷰를 사용을 하게 되면 그 뷰에 대한 정보도 여기에 포함이 되고 어떠한 데이터의 차원수가 어떻게 되는지 이 차원이 몇 차원, 10차원인지 100차원인지 이런 차원수에 대한 정보 그리고 어떤 계층이 존재할 때 어떻게 이런 계층 정보가 구성이 되어 있는지

이러한 정보도 저장이 되어 있습니다. 또한 어떤 파생된 데이터가 있을 수 있겠죠. 예를 들어서 어떤 생년월일이라는 정보에서 생일 정보를 우리가 얻어낼 수 있습니다. 그러면 그 파생된 데이터는 어떠한 식으로 계산이 됐는지 이러한 정보도 여기 포함이 될 수 있습니다. 그리고 또한 우리가 데이터 마트를 사용을 하면은 그 데이터 마트가 어디에 위치되어 있고 그 데이터 마트에는 각각 어떤 정보가 저장이 되어 있는지에 대한

이러한 모든 데이터 웨어하우스의 구조와 관련된 이러한 정보를 명시해주고 있습니다. 그리고 두 번째로 실제로 운영에 필요한 운영과정에서 발생하는 이러한 정보도 여기에 포함이 되어 있습니다. 첫 번째 데이터 리니지는 실제 이 데이터가 어떤 소스로부터 온 데이터인지 그리고 어떠한 변형이 진행되었는지 그런 히스토리를 모두 저장해서 보여주게 되고요.

그 다음에 데이터 상태가 어떤지 그리고 사용통계가 어떻게 되는지 이 데이터가 얼만큼 자주 사용되는지에 대한 정보 그리고 에러가 발생했으면 에러에 대한 리포트 그리고 실제 어떤 데이터의 사용 권한은 어떻게 되는지에 대한 이러한 정보들도 다 저장을 해서 가지고 있게 됩니다. 그 밖에도 어떤 요약이나 집계를 진행을 했으면

그 과정에서 어떤 알고리즘이 사용되는지에 대한 정보 그리고 데이터 웨어하우스와 실제 운영 환경이 어떤 식으로 매핑이 되어 있는지에 대한 정보 그리고 시스템 퍼포먼스가 어떤지에 대한 데이터와 관련된 시스템 퍼포먼스가 좋은지 아니면 낮의 퍼포먼스를 보이는지에 대한 정보 이러한 것들을 포함하고 있고요. 그리고 마지막으로 비즈니스에 대한 데이터도 포함을 하고 있습니다.

그래서 이 데이터 웨어워스에 사용되는 속성명이라든지 어떤 용어들의 이러한 비즈니스 텀이 용어들이 사용될 수 있겠죠. 그러한 정의들도 여기에 함께 저장을 해주고요. 이 데이터의 소유권이 누구에게 있는지 그리고 어떤 정책들이 어떻게 되는지에 대한 이러한 정보들도 모두 이러한 메타 데이터에 포함이 되어서 함께 저장이 됩니다. 그래서 여기까지 데이터 웨어하우스의 기본적인 특성에 대해서 공부해봤고요.

데이터 웨어하우스와 함께 데이터 분석에 또 많이 활용되는 형태가 데이터 레이크라는 형태가 있습니다. 그래서 데이터 레이크라는 시스템에 대해서도 한번 공부를 해보도록 하겠습니다. 일반적으로 아까 설명드렸던 것처럼 데이터 웨어워스는 데이터를 저장하기 전에 이미 그 데이터의 어떤 스키마를 여러 소스에서 데이터 스키마를 통일해서 저장을 하는

그러한 특징을 가지고 있습니다. 그래서 일반적으로는 정형 데이터 형태로 데이터를 저장해서 가지고 있게 됩니다. 그런데 데이터 레이크는 이러한 정형 데이터뿐만 아니라 반정형 데이터 비정형 데이터 모두 저장을 하게 됩니다. 그래서 이 데이터 레이크는 이러한 다양한 데이터를

그리고 더 많은 수의 데이터를 쉽게 저장하기 위해서 저장 단계에서 이러한 전처리 과정을 거치지 않습니다. 그래서 저장할 때는 로우 데이터 형태로 다일당 저장을 해놓자 그러한 전략을 취하게 됩니다. 그러면 실제 데이터 분석을 진행할 때는 이러한 전처리 과정을 거쳐야겠죠. 그리고 통일된 데이터 스키마를 만들어줘야지 우리가 쉽게 분석 작업을 진행할 수 있습니다.

그래서 여기서는 실제 데이터 분석이 진행될 때 이런 통일된 데이터 스키마를 만드는 데이터입니다. 그러한 작업을 수행을 해주게 됩니다. 그래서 이러한 방식을 Schema All Read 우리가 실제 그 데이터를 읽어올 때 즉 우리가 실제 그 데이터가 필요할 때 스키마를 실시간으로 만들어서 처리를 해준다 라는 이러한 전략을 사용을 하고 있습니다. 그래서 이러한 데이터 레이크는 다양한 분석

과정에 활용이 될 수 있구요. 그래서 시각화, 빅데이터 처리, 실시간 분석, 머신러닝 등 다양한 데이터 분석 과정에서 유용하게 활용되고 있습니다. 이런 데이터 레이크의 저장 계층을 살펴볼건데요. 왼쪽에 5개의 계층으로 일반적으로 구성이 되어 있습니다.

여기서 실선으로 표현이 된 것은 일반적으로 꼭 들어가야 되는 이런 점선으로 표현되는 계층 같은 경우에는 어떤 목적에 따라서 혹은 데이터의 특성에 따라서 포함될 수도 있고 포함되지 않을 수도 있습니다. 가장 아래에 있는 계층 같은 경우에는 실제로 로우 데이터를 저장하는 계층입니다.

여기서는 로우 데이터를 계속해서 가지고 있다가 위의 단계에서 데이터를 가공하는 과정에서 예를 들어서 어떤 오류가 발생되었다고 했을 때 이 저장된 데이터를 다시 가져와서 다른 방법으로 처리를 한다든지 아니면 그 오류가 발생한 데이터와 비교 분석을 한다든지 하는 그 과정에서 활용될 수 있습니다. 그래서 원본 데이터를 항상 가장 하위층에 가지고 있다가 나중에 비상 상황이 발생했을 때 다시 원본 데이터를 활용한다고 알고 있으면 될 것 같습니다.

그 다음에는 Standardized Data Layer인데요. 이 과정에서는 기본적인 표준화를 진행을 해주게 됩니다. 그래서 여러 소스로부터 데이터가 들어왔을 때 그 데이터의 형식이나 단위가 다를 수 있겠죠. 그러한 것들을 여기서 통일하는 역할을 수행합니다. 그런데 이 과정은 사실 필요가 없을 수도 있겠죠.

예를 들어서 이미 단위가 일치한다던가 이런 표준화 과정이 필요 없을 때는 이 레이어는 생략이 될 수 있습니다. 그 다음은 Cleansed Data Layer 입니다. 세 번째 계층이고요. 이 계층은 본격적으로 데이터 정제 그리고 데이터 변환을 수행을 하게 됩니다. 그래서 이 레이어를 거치게 되면은 우리가 분석에 필요한 모든 준비 단계가 완료됐다는 것을 의미합니다.

그래서 분석에 필요한 형태로 이 데이터를 가공하는 그러한 과정을 이 세 번째 레이어에서 진행을 해주게 됩니다. 그 다음에는 어플리케이션 데이터 레벨 인데요. 이 과정에서는 우리가 실제로 어떤 업무를 처리하거나 아니면 분석을 수행할 때 사용되는 비즈니스 로직들을 적용하는 것을 의미합니다.

그래서 우리가 실제로 어떤 분석하고 싶은 그런 어플리케이션에 따라서 다른 비즈니스 로직을 적용해서 이 데이터를 다시 한번 그 형태로 가공을 해주게 됩니다. 그래서 이 Cleanshed Data Layer, 어플리케이션 데이터 레벨 같은 경우에는 항상 포함이 되는 그런 단계에 해당이 되고요.

마지막, 샌드박스 데이터 레이어 입니다. 이 샌드박스라는 것은 실제 환경과 분리된 어떤 가상의 환경을 의미합니다. 그래서 이 데이터 레이어에서는 데이터 사이언티스트나 아니면 데이터 분석가들이 실제로 이제 원본 데이터를 가지고 새로운 어떤 변수를 만들어 보거나 아니면 어떤 분석과정을 가상으로 수행을 해보거나 여러가지 실험을 해보거나 이러한 과정을 여기서 수행을 해주게 됩니다.

그래서 실제 실험 결과가 실제 데이터에 영향을 미치면 안되겠죠. 그리고 어떤 변수를 한번 만들어봤는데 그것 때문에 원본 데이터가 바뀌면 안되기 때문에 여기서는 이 샌드박스의 형태로 실제 환경에는 영향을 주지 않도록 설계를 해주게 됩니다. 그리고 이러한 레이어는 필수적으로 있어야 되는 건 아니겠죠. 이러한 추가적인 분석 과정이 필요할 때만 이 레이어를 수행하면 되기 때문에

이것도 필수적인 레이어는 아닙니다. 전체적인 아키텍처를 한번 같이 알아보도록 하겠습니다. 가장 하위를 보면 데이터베이스, 다큐멘트, 웹크롤링, 소셜미디어, 이미지 등등 다양한 데이터 소스로부터 여러가지 형태의 데이터를 가져올 수 있습니다.

그래서 각각의 커넥터라는 것을 통해서 각각의 데이터 소스에서 데이터를 수집을 하게 됩니다. 이 커넥터는 각각의 데이터 소스에 알맞은 I/O라고 생각을 하면 됩니다. 그래서 이 커넥터를 통해서 각각의 데이터 소스로부터 데이터를 가져오고요. 그 다음에 이 데이터들을 데이터 레이크에 저장을 해두게 됩니다. 그런데 우리가 실제로 데이터 레이크에는 무수히 많은 데이터가 저장이 되어 있는데

그럼 우리가 필요한 데이터를 찾아서 사용하기 위해서는 이러한 서치 엔진이 필요하겠죠. 그래서 이 서치 엔진을 통해서 데이터 레이크에서 우리가 필요한 정보들을 찾게 됩니다. 이 서치 엔진에서는 이제 두 가지가 활용이 되는데요. 첫 번째로 데이터 모델. 데이터가 어떠한 식으로 구성이 되어 있는지를 알아야지 효과적으로 그 데이터를 찾을 수 있겠죠.

그래서 데이터 모델 정보가 활용이 되고요. 또한 이제 비즈니스로 우리가 실제 업무를 처리할 때 사용하는 이 규칙들을 반영을 해서 어떤 데이터가 우리가 필요로 하는지를 찾게 됩니다. 그래서 이 서치 엔진을 통해서 우리가 필요한 데이터들을 찾으면은 이 api를 통해서 어떤 다른 시스템으로 연결을 해서 이 데이터를 전달해 줄 수도 있고요.

아니면 이 데이터를 바로 우리가 분석을 할 수 있습니다. 그래서 분석을 해서 사용자에게 바로 리포팅 해줄 수도 있고 아니면 이 데이터를 다른 api를 통해서 다른 시스템으로 전달을 해줄 수도 있다 입니다. 그래서 결국 데이터 레이크라는 것은 데이터를 수집을 해서 실제 분석을 해서 리포트를 해주는 것까지 이 전 단계를 의미를 해주고 있습니다. 그래서 이 데이터 레이크의 사실 중요한 특징은 이 데이터를 저장할 때는 원본 데이터 그대로 저장을 하고요.

실제로 데이터를 활용할 때 스키마를 구성해준다는 그런 특징을 가지고 있습니다. 그래서 각각의 여러 가지 데이터 형식에 따라서 어떤 식으로 스키마를 만들 수 있는지에 대해서 그 과정을 간략하게 설명을 드리도록 하겠습니다. 그래서 이 데이터 레이크에서는 세 가지 서로 다른 형식의 데이터를 모두 사용할 수 있습니다. 첫 번째, 정형 데이터인데요.

정형 데이터 같은 경우에는 이미 테이블 형태로 저장되어 있기 때문에 그 스키마가 이미 다 정의가 되어 있습니다. 그래서 단순히 우리가 알고 있는 스키마를 import해서 그 최종적인 스키마로 사용을 해 줄 수 있습니다. 조금 어려운 부분은 비정형 데이터 혹은 방정형 데이터인데요. 비정형 데이터 같은 경우에는 예를 들어서 이미지 같은 데이터를 의미하죠. 이미지 같은 경우에는 특정한 정의되어 있는 스키마가 없습니다.

그래서 우리가 그런 스키마를 만들어 주는 작업을 수행을 해 줘야 됩니다. 그런데 먼저 첫 번째 단계에서 바로 스키마를 만드는 건 아니고요. 이 데이터에서 우리가 필요로 하는 정보나 특징들을 먼저 얻어내는 작업을 진행을 해야 됩니다. 그것을 Extraction 이라고 합니다. 그래서 예시를 들기 위해서 오른쪽 영수증 데이터를 가져왔는데요. 이 영수증은 이미지죠. 이 이미지에서 예를 들어서 우리가 필요한 데이터들을 가져오는 작업을 진행을 해야 됩니다.

예를 들어서 OCR 같은 것을 활용을 해서 여기에 있는 글자들을 읽어 볼 수 있겠죠. 그래서 예를 들어서 우리가 산 지점이 어떤 지점인지 그리고 우리가 어떤 물품들을 샀는지 각각 몇 개씩 샀는지, 물품을 구매는 금액은 어떻게 되는지, 총 금액은 어떻게 되는지, 이러한 정보들을 우리가 가져올 수 있겠죠. 이러한 것들을 Extraction 이라고 합니다.

그 다음 단계로서 이렇게 가져온 각각의 값들이 있는데 그 값들이 어떤 것을 의미하는지를 우리가 정의를 해줘야겠죠. 그래서 이러한 우리가 가져온 다양한 정보들을 구조화하는 작업이 필요합니다. 이러한 구조화하는 작업을 이렇게 Schema Inference라고 합니다. 그래서 이러한 여러 개의 우리가 가져온 값들을 구조화해서 그 스키마들을 따로 정의를 해주게 됩니다. 예를 들어서 이러한 영수증 데이터를 우리가 처리를 해서 이 값들을 추천했다 하면은

예를 들어서 스키마가 상풍명, 가격, 갯수, 이러한 스키마를 우리가 만들어서 이 데이터를 정의해 줄 수 있겠죠. 이러한 스키마를 만드는 작업을 진행을 해주게 됩니다. 마지막 반정형 같은 경우에는 예를 들어서 대표적으로 웹페이지 등이 여기에 해당이 됩니다. 그래서 반정형 데이터는 일정한 스트럭처를 가지고 있기 때문에 그 정보를 우리가 활용을 해주면 됩니다.

그래서 이런 특징 정보를 추출해 줄 필요는 없고요. 일반적으로 간단한 파싱을 통해서 데이터를 가져올 수 있습니다. 예를 들어서 웹페이지 같은 경우에는 어떤 특정한 필드가 있고요. 그 필드에 대한 값이 있습니다. 그래서 필드와 값을 파싱해서 우리가 유용한 정보를 가져오면 됩니다. 그 다음에 우리가 이 필드 값을 가져왔는데 예를 들어서 페이지마다

이런 어떤 필드가 있을 수도 있고 없을 수도 있겠죠. 그래서 서로 다른 필드가 있고 또한 이제 값이라고 해도 그 값이 어떤 데에서는 정수 형태로 저장되어 있고 다른 곳에서는 카테고리컬하게 정의되어 있고 이렇게 데이터의 형식도 다를 수 있습니다. 그래서 이런 것을 역시 통일해주는 과정이 필요하게 됩니다. 그래서 이런 것들을 한 대 통일을 해서 스키마를 구성을 해주게 됩니다. 그래서 이제 여러가지 형태의 데이터에 따라서 다른 형태로 결국에 이 데이터를 활용할 때 스키마를 구성을 해주게 되고요.

그 스키마를 이용해서 최종적으로 데이터 분석을 수행을 해줄 수 있습니다. 그래서 이제 두가지 환경을 좀 정리를 해보자면 첫번째 데이터 웨어하우스 같은 경우에는 주로 어떤 데이터에 대한 복잡한 의사결정을 지원하기 위해 분석적인 목적으로 활용이 많이 됩니다.

그리고 그 데이터를 저장할 때 구조화해서 저장을 하기 때문에 정형 데이터만을 일반적으로 활용을 하고요. SQL이나 파이썬 등의 언어를 통해서 주로 처리를 해주게 됩니다. 데이터 레이크 같은 경우에는 다양한 데이터를 저장을 해서 여러가지 업무를 처리하는 데 도움을 주는 것에

목적을 두고 있습니다. 그래서 다양한 데이터를 저장을 해두고요. 그걸 통해서 의사결정 과정에 활용을 할 수도 있고요. 아니면 데이터 분석 과정에 활용을 할 수도 있고 그 밖의 다양한 목적으로 활용이 될 수 있습니다. 그래서 가장 큰 특징은 로우 데이터의 형태로 데이터를 저장을 한다는 그런 특징을 가지고 있고요. 그래서 이러한 다양한 형태의 데이터를 처리하기 위해서 뭐 Java, Python, R, SQL 등

더 다양한 형태의 언어들이 활용될 수 있습니다. 하지만 최근에는 이러한 데이터 웨어하우스와 데이터 레이크가 명확히 구분되기보다는 서로 장단점을 공유하는 형태로 발전이 되어가고 있습니다. 그래서 이러한 데이터 웨어하우스와 데이터 레이크가 통합되는 추세를 많이 보이고 있습니다. 그래서 그러한 대표적인 형태가 이러한 데이터 레이크 하우스인데요.

이 데이터 레이크 하우스는 데이터 레이크와 웨어하우스의 장점을 가져온 그러한 시스템이라고 할 수 있습니다. 그래서 데이터 레이크 하우스의 장점은 어떤 유연하다는 장점이 있죠. 그래서 다양한 데이터를 가져올 수 있고요. 그리고 비용 효율적이고 그리고 확장성이 좋다. 이러한 데이터 레이크의 장점을 가져오고요. 그리고 데이터 웨어하우스의 장점은

데이터를 체계적으로 더 관리할 수 있다. 그리고 어떤 트랜잭션 처리에 대한 이러한 기능을 제공한다 라는 장점을 가지고 있는데 이러한 장점을 또 가져오게 됩니다. 그래서 이제 두 개의 시스템의 장점만을 취합해서 사용하는 이러한 시스템이라고 생각을 할 수 있습니다. 여기서 일단 이 트랜잭션 이라는 용어가 나오는데요. 이걸 한번 정리를 하고 넘어가도록 하겠습니다.

트랜잭션은 논리적으로 하나로 구성된 어떤 연산의 집합이라고 그래서 논리적으로 하나의 목적을 가져야 된다는 특성을 가지고 있고요. 여러 연산으로 구성이 될 수 있습니다. 논리적으로 하나의 목적을 가져야 된다는게 예를 들어서 계좌이체라는 어떤 테스크가 있다고 가져버려보도록 하겠습니다.

계좌이체를 수행하기 위해서는 A라는 계좌에서 B라는 계좌로 돈을 입금한다. 계좌이체를 한다고 했을 때는 여러가지 오퍼레이션으로 수행이 됩니다. 예를 들어서 A라는 계좌에서 돈을 일단 빼야겠죠. 그 다음에 B라는 계좌에 돈을 입금한다. 입금을 해야 됩니다. 이 두 개의 오퍼레이션으로 진행이 되죠. 그런데 이 두 개의 오퍼레이션은 독립된게 아니고 계좌이체라는 논리적인 하나의 목적으로 연결되어 있습니다.

이러한 하나의 테스트를 우리는 트랜젝션이라고 부르고 있습니다. 그리고 이러한 트랜젝션이 꼭 만족해야 되는 네 가지 특성이 있는데요. 그것을 ACID 특성이라고 일반적으로 부르고 있습니다. 첫 번째 특성은 원자성입니다. 원자성이라는 것은 이러한 전체 트랜잭션이 수행이 될 거면 끝까지 다 수행이 되거나 수행이 되지 않을 거면은 아예 실패해야 된다라는 것을 의미합니다.

예를 들어서 아까 계좌이체를 예로 들었는데 계좌이체가 진행이 되는데 A 계좌에서 돈이 출금이 됐는데 B 계좌에는 입금이 안되면 안되겠죠. 아예 계좌이체 자체가 성공이 되거나 아예 성공이 되거나 아예 실패가 되거나 이러한 것을 보장을 해야 된다를 의미합니다. 두 번째는 일관성인데요. 어떤 데이터가 만족해야 되는 규칙이나 제약 조건이 그런 거래, 트랜잭션이 수행된 이후에도

동일하게 만족을 해야 된다라는 것을 의미합니다. 어떤 트랜잭션이 수행됐다고 갑자기 규칙이 바뀌면 안 된다라는 것을 의미합니다. 세번째는 고립인데요. 여러 트랜잭션이 동시에 수행될 때 서로 영향을 주고받으면 안되고요. 한 개씩 독립적으로 수행한 것과 같이 동일하게 처리되어야 된다는 의미를 합니다. 네번째는 지속성인데요.

어떠한 트랜잭션이 커밋되었을 때 즉 승인되었을 때 승인된 이후에는 그 트랜잭션이 취소되면 안된다. 그 트랜잭션이 반영된 그 상태가 계속 유지되어야 된다라는 것을 의미합니다. 즉 어떤 트랜잭션이 이미 승인이 되서 데이터의 변경이 발생이 되었습니다. 그런데 갑자기 재부팅을 하니까 다시 이전 상태로 돌아간다거나 하면 되지 않는다 라는 것을 의미합니다.

그래서 데이터 웨어하우스 같은 경우에는 이러한 ACID를 만족하는 트랜잭션을 처리하기 위한 여러가지 기능을 제공합니다. 그래서 데이터 레이크하우스도 이러한 것들을 그대로 가져와서 사용을 하고 있다 라는 것을 의미하고 있습니다. 그래서 데이터 레이크하우스는 비즈니스 인텔리전스, 즉 어떤 업무를 처리하는데 활용될 수 있는 보고서 작성이나 아니면은 대시보드 같은 그런 형태에 활용될 수도 있고요.

아니면은 이제 모든 데이터에 대한 머신러닝을 수행하기 위해서 활용될 수도 있습니다. 즉 굉장히 다방면으로 응용되어서 활용될 수 있다는 것을 나타내고 있습니다. 그래서 레이크하우스는 다음과 같이 굉장히 많은 기능들을 제공하고 있습니다. 먼저 첫 번째로 트랜잭션을 지원하는 이런 기능을 가지고 있고요.

그 밖에 여러가지 기능들을 제공해주고 있는데 이 부분은 조금 설명하는데 시간이 걸릴 것 같아서 이 부분부터 다음 시간에 이어서 진행하도록 하겠습니다.