반응형

[ EDW와 빅데이터 아키텍처 ]

 

앞선 포스팅에서 적은 것 처럼 EDW는 Enterprise Data Warehouse 의 약자입니다.

 

그럼, 요즘 핫한 빅데이터 아케텍처와 EDW와는 어떤 관계가 있을까요?

 

자~ 같이 생각해 보시죠..~ ^^

 

....

 

EDW 구축 방법중 하나, 빅데이터

 

결론부터 말씀 드리면 EDW를 구축하는 방법중의하나가 빅데이터 아키텍처라고 할 수 있습니다.

 

즉, 분석계에서 빅데이터를 구축하려면 EDW라는 개념을 이용할 수 밖에 없다는 말입니다.

 

 

EDW를 구축하는 방법에는

과거 (지금도 대부분의 기업에서) 많이 사용하는 DBMS방법과

빅데이터 기술을 적용한 방법이 있습니다.

DBMS로 구축한 EDW는 훌륭했었었습니다.

 

예전에 데이터가 작을(?) 때에는 좋은 성능의 (UNIX) 서버에 DBMS라는 미들웨어를 놓고 데이터 관리를 하면 대부분이 해결되었습니다.

즉, 전사 데이터의 수집, 저장, 처리, 분석, 활용에 문제가 없었습니다.

개별 시스템 뿐만아니라 기업에서 주요 데이터를 모두 모아 놓아도

 이러한 DBMS 시스템 구성으로 구현이 가능했습니다.

성능도 좋았고 관리하기 편했으며 문제가 생기면 솔루션 제공 벤더에서 해결해주었습니다.

 

그런데 문제가 생기기 시작했습니다.

빅데이터 시대가 되면서

(즉, 스마트폰이나오고 페이스북, 트위터 등 엄청난 데이터가 쏱아져나오면서)

이러한 시스템 구성으로는 문제가 생기게 되었지요.

DBMS로 구성하면 엄청난 비용이 들 뿐만 아니라

실제 구축을 해도 성능이 만족스럽지 못하게 되었습니다.

즉, 전사의 운영시스템에 흩어져 있는데이터를 모두 모아서

적재하고 필요한 데이터로 가공하고 만들어 내는데에 하루로도 부족하게 된 것이지요.

그러니 실적리포트, 대시보드 등의 정보가 2~3일 늦게 나오게되는.....

영~ 서비스를 할 수 없게 되는 것이지요.

그저께 데이터를 처리도 못했는데 또 어제 데이터가 밀고 들어오는 상황인 것이지요

 

그래서 빅데이터라는 기술을 이용하여 EDW를 구성하게 되었습니다.

빅데이터 기술의 EDW를 구성하게 되면 앞서말한 문제점들을 해결 할 수 있습니다.

비용이 싸고

(UNIX보다 훨씬 저렴한 x86 서버에, 오픈소스 솔루션사용으로 솔루션 비용은 공짜)

분산 병렬 처리로 인해 처리할 수 있는 데이터의 량이 거의 무한대에 가깝게 되었습니다.

즉, 대량의 데이터를 싸고 효율적으로 관리할 수 있게 된거지요..

우와~ 여러모로 좋은 방법인것 같지요???!!!

 

 

그러나 모든 것이 그렇틋 장점이 있으면 단점도 있습니다.

무조건 빅데이터 기술이 좋은 것은 아닙니다.

하드웨어, 솔루션의 비용이 대폭 줄어들었지만 대신에 관리의 불편함이 발생하게 됩니다.

장애 발생시 과거에는 DBMS솔루션 벤더에 문의하고 확인해서 버그 픽스하고 패치하면 해결이 됬는데...

(그리고 이런 것을 알아서 벤더에서 해 주었는데...)

빅데이터 기술(오픈소스)를 쓰게 되면서 이런 것들을 직접해야만 하는 수고가 생겼습니다.

그리고 이렇게 직접 하려면 기술적으로 매우 자세한 내용까지 알고 있는 전문가가 회사내에 필요하게 되었지요.

장애나고 문제가 생기면 이제 벤더 탓을 할 수 없게 되었습니다. ㅎ

 

그리고 빅데이터 기술들은 기존의 마트나 분석 툴에 사용되던 DBMS, 상용 툴과의 인테그레이션이 쉽게 되어있지 않아서 어려움이 생기게 되었지요.

 

이러한 장단점을 적적히 섞어서 빅데이터기술과 DBMS기술을 섞어서 구성하는 하이브리드 아키텍처도 많이 사용되고 있습니다.

즉, Raw Data의 저장, 처리는 빅데이터 아키텍처에서 해결하고

기존의 분석 툴이나 서비스에서 활용하기 위해서 DBMS를 이용하는 방법입니다.

 

최근에는 빅데이터 기술의 발전 속도가 빨라지면서 DBMS의 기능을 지원하는 것이 확장되고 있습니다.

그래서 나중에는 빅데이터 기술 만으로도 EDW를 구축할 수 있을 것 같은데...

앞서 말한 여러가지 이유로 아직은 시기 상조인 것 같습니다.

그러나 빅데이터 관련 주요 업체중 하나인 클라우데라는 오라클(ORACLE)과 연계 강화를 통해 기능 강화를 진행하고 있고

호튼웍스도 하이브(HiVE)에 기능을 강화하면서

빠르게 진화/발전하고 있습니다.

 

결국에는 빅데이터 기술이 EDW를 지배하는 시대가 곧 올것 같습니다

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

반응형
반응형

Enterprise Data Warehouse (EDW) 개념 아키텍처


 

Enterprise Data Architecture는 크게 3가지 레이어로 나누어 집니다.

Data Source, Data Storage, Front-End Tools 가 그것 입니다.

 

Data Source

소스는 말 그대로 원천입니다. 데이터가 만들어지는 것(시스템)을 말합니다.

일반적으로 운용 어플리케이션(응용) 시스템이라고 불리우는 시스템에서 데이터가 생성됩니다.

운영계 시스템이라고도 하며 예를 들면 고객관리 시스템, 자산관리 시스템, 재무관리 시스템, 직원 관리 시스템 등이 되겠습니다.

즉, 경영을 하면서 필요한 오퍼레이션(운영/관리)를 위해 필요한 시스템들을 말합니다. 그래서 운영계라는 말을 사용합니다. 은행업계에서는 계정계라고 합니다.

 

Data Storage

이와 달리 EDW는 분석계에 해당합니다. 운영계 처럼 업무처리니 관리를 위한 시스템이 아니라 말그대로 분석을 위한 시스템입니다. 전에는 주로 통계나 리포트 작성을 위한 데이터 생성이 목적이었습니다. 왜냐하면 운영계에서는 업무/서비스를 위해서 24시간 운영되는 경우도 있는데 이런경우 통계/리포트를 만들기 위해서 데이터 처리를 위한 시스템 구조/용량을 확보할 수 없거나 그렇게 하는 것이 비효율적이었기 때문입니다. 그러다가 Direct Marketing, CRM(customer Relation Marketing) 등의 바람이 불면서 분석계의 인기(중요성)이 부각 되었었지요. 단순히 통계 숫자 뽑고 필요한 리포트 만들어주는 시스템이 아니라 돈버는데 필요한 시스템이 되엇던 것입니다. 그런데 너무 앞서 갔던 걸까요?! 매출신장에 혁신적이라고 생각해서 인프라/시스템적인 투자를 엄청나게(?) 했는데 효과는 기대했던것에 미치지 못했습니다. 이유를 생각해보면 3가지가 될 것 같은데요. 첫째 데이터가 없었습니다. 둘째, 좋은 알고리즘, 그리고 이를 잘 활용할 만한 인력이 없었습니다. 그리고 마지막으로 세번째는 분석계 시스템/인프라 도입에 많은 비용이 들었습니다. (이 세가지 이야기는 할 말이 많으니 나중에 더 하겠습니다.) 하여간 이러한 이유로 투자 대비 효과가 별로라는 평가로 투자와 관리/발전이 소흘해 졌습니다.

그러다가 드디어 짜쨘~ 스티브 잡스께서 스마트폰을 세상에 내놓으셨지요. 갑자기 스티브잡스와 스마트폰이 무슨 말인지 연계가 안되시나요? (아 되시는 분도 계시군요) 바로 첫번째 문제 였던 데이터 부족을 해결하게 됩니다.

- 너무 할말이 많아서 중략 ^^ -

요즘은 빅데이터가 발전하면서 Data Storage에 대한 여러종류의 아키텍처가 발전하고 있습니다. 많이 들어보셨을 하둡( Hadoop), HDFS(하둡 File System) 등이 그것 입니다.

 

Front-End Tools

이렇게 데이터 스토리지에서 열심히 분석해서 만들어놓은 데이터를 활용하는 레이어 입니다. 가장 기본적인 것은 SQL(Structured Query Language: DB의 데이터를 입력/조회/수정/삭제 할 수 있는 명령어 모음), 리포트(쉽게 말하면 엑셀 표/자료), OLAP Tool(On Line Analytical Processing) 입니다. 이쪽의 아키텍처도 실시간과 시각화 관점에서 다양한 아키텍처가 새롭게 나오고 있습니다.

 

하여간 오늘날에는 4차 산업혁명이라는 주제아래 빅데이터, 인공지능/기계학습(AI/ML) 등의 이야기가 나오면서 분석계의 중요성은 나날이 높아지고 있는 상황입니다. 그 기본이 되는 아키텍처가 바로 상기의 EDW개념 아키텍처 입니다.

 

이후부터 차근차근 관련된 아키텍처와 기술, 서비스에 대해서 이야기해보겠습니다.

 

 

 

반응형

+ Recent posts