1) 빅데이터 플랫폼 아키텍처에 대하여.. 데이터 스토리지 관점에서의 흐름

최근 몇 년동안 AI, ML, DL이 뜨면서 BDP라는 용어의 사용이 뜸해졌다. 그렇다고하여 빅데이터라는 영역이 많이 시들해졌다고 생각하는 것은 큰 오판이다. 오히려 더 발전하고 견고해지면서 당연 시 여기는 현재라고 보는게 맞다. 당연히 데이터 작업을 하기 위해서는 그 것들을 커버할 시스템이 필요하기 때문이다. 

너무나도 당연시 여겨지지만 일부 혹은 단순히 운영해본 사람은 많겠지만 설계부터 설치, 운영까지 모두 해보기는 쉽지 않다. 많지는 않지만 스터디나 세미나를 하면서 BDP나 DE에 대해 설명하고 인터뷰를 하면서 깊게 설명하긴 어려웠으나 적어도 DE를 처음 접하고 이 쪽으로 커리어를 쌓으려는 사람들에게 최소한의 것들은 공유하며 도움이 되기를 바라는 마음에 포스팅을 시작한다.

이론적인 부분이 깊게 필요할 경우 시간과 의지가 된다면 문서화하여 Slideshare에 공유할 생각이며 100% 개인적인 의견으로 작성하는 내용이니 최근 동향보다는 이미 견고하게 자리잡은 내용을 중심으로 서술하고자 한다.

- 데이터 스토리지 관점에서의 흐름

데이터가 부각되기 전 시대의 가장 간단한 서비스의 구조를 생각해보자.

클라이언트 - 서버 - DB 구조이다. 여기서 데이터는 모두 DB에 저장되어있고 DB의 경우 물리적 한계가 명확하기 때문에 서비스용 데이터와 일부 로그성 데이터만이 저장할 수 있을 것이다. 서비스용 DB는 안정성이 증명되고 운영 노하우가 많이 축적된 SMP 구조 RDB를 사용하기 때문이다.

그럼 SMP말고 다른 아키텍처인 MPP는 무엇일까?

SMP, MPP 구조. 출처 - softline

만약 운영 DB를 가지고 Group by 등의 분석을 한다고 생각해보자. 이러한 환경을 OLTP라고 하며(실시간으로 트랜잭션이 발생) 이는 분명히 서비스에 지장을 줄 것이고 결국에는 OLAP(배치성 트랜잭션 발생)를 위한 별도 분석용 DB를 한벌 더 마련하고 그 곳에 데이터를 부어 분석용 쿼리를 수행할 수 있을 것이다. 하지만 SMP 구조는 구조상 scale up을 해야하고 이는 한계점에 다다를 수록 비싸진다.

이에 따라 분석용 DB로 사용할 수 있는 MPP구조의 DB가 수면위로 올라오게 되었다. MPP 구조의 DB 특성상 리소스가 부족할 경우 scale out을 할 수 있기 때문에 node를 추가하는 방식으로 확장하기 편하다. 

가령 1억건의 데이터를 SMP DB를 사용하여 count 연산한다면 아무리 슈퍼맨(노드)이라 할지라도 1억번을 세는데 시간이 오래걸린다. 하지만 100명의 운동선수(노드)가 각자 100만건씩 각자 세서 마지막에 갯수를 합산한다면? -> 당연히 훨씬 빠를 뿐만아니라 운동선수 1명 섭외비가 훨씬 쌀 것이다. 또한 슈퍼맨의 경우 더 센 슈퍼맨을 구하려면 섭외하기 힘들지만 운동선수의 경우 여러명을 더 섭외해서 하던 작업을 똑같이 하면 된다는 장점이 있다.

이런 시나리오가 가능하게 하기 위해서는 데이터가 각각의 운동선수(노드)에 똑같이 분산되야하고 연산에 따라 다르지만 pk가 없다면 효율을 극대화시킬 수 있다. 하지만 데이터를 유입시킬 때 앞 단에서 잘 쌓아주기만 하면 pk가 없다는 것은 위기보다는 기회일 수 있다.

데이터를 잘 분산시킨다는 것은 일부 노드에 데이터가 몰빵되어 일하지 않는 노드가 발생하면 안된다는 것과 같다. 따라서 적절한 분산키를 활용하여 데이터가 잘 분산되게 해야한다.

그렇다면 이런 질문이 존재할 수도 있다. 만약 작업중에 A운동선수에게 있는 자료가 B운동선수에게도 필요하면 전달하는데 더 큰 리소스가 발생할 수 있지 않을까? 슈퍼맨의 경우 모든 자료를 혼자 다 들고 있기 때문에 전달하는 리소스가 필요 없을텐데... -> 맞는 말이다. 이러한 현상을 shuffle이라고 하며 분산 프레임워크를 사용할 경우 shuffle을 최소화하는 것도 중요한 개념이다. 애초에 필요한 데이터는 작업 지시자가 broadcast를 해주던지 혹은 모든 운동선수에게 복제본을 전달해주던지 하는 최적화가 필요하다.

여기까지 SMP와 MPP에 대해 큰 그림에서 설명한 것이고 데이터의 저장을 어떻게 해야 읽을 때 잘 읽을 수 있을지.. 샤딩 혹은 RDB와는 조금 다른 DB인 nosql이라는 개념도 있다. 이 부분은 추후에 넘어가면서 기술하도록 하자. 이후 각광받은 것이 하둡이다. HDFS로 저장하며 말 그대로 파일시스템으로 저장하는 방식이다. 하둡은 결과적으로 mpp구조와 비슷하기는 하지만 저장소 자체를 의미하며 데이터를 처리하기 위한 엔진은 별도 선택을 해야한다. 

데이터를 다룬다는 것은 결과적으로 저장 및 처리 자체가 핵심이며 당연히 DB를 잘 이해하면 좋다. 본론에 들어가기 전에 빅데이터 아키텍처를 먼저 훑고 하둡에 대해서 설명하는 것이 좋겠다. 이번 포스팅은 여기서 마친다!

전통적 Data WareHouse(데이터 웨어하우스) 아키텍처 및 고찰

이번 포스팅에서는 전통적 데이터 웨어하우스 아키텍처 및 고찰을 해보고자 한다.

개인적인 생각으로는 이미 DW는 수십년 전에 기술적, 논리적인 발전이 정점에 올랐기 때문에 아키텍처라던지 데이터 설계면에서 새로운 이론이 나올 가능성은 적어보인다. 또한 클라우드라는 기술이 새로 나타나긴 했지만 큰 틀에 변화를 주기에는 기존의 구성이 너무 잘 되어있어 큰 틀에 영향을 주기에는 미미해보인다.

그래도 DW 자체만 보면 얼마 전 빅데이터의 유행과 더불어 갈 수록 커지는 데이터의 잠재력(AI, ML/DL)으로 인해 DW는 필수가 되어가고 있다.

전통적인 아키텍처를 설계하기 전 OLAP과 OLTP에 대해서 간단하게 짚고 넘어가도록 하자.

OLTP는 Online transaction processing의 약자로 실제 운영중인 환경이다. 실제 운영중이라 함은 SELECT, INSERT, DELETE, UPDATE 등의 트랜잭션이 계속해서 발생한다는 뜻이다. 과연 이렇게 트랜잭션이 몰리는 환경에서 전체 데이터에 대한 GROUP BY 쿼리를 수행할 수 있을까? 아마 불가능할 것이다.

OLAP는 Online Analytical Processing의 약자로 데이터 분석용 환경이다. 가령 "어떤 물품은 어느 요일에 어디서 누구에게 팔아야 매출이 오를 것이다"라는 가설을 세워보자. 그럼 의사결정권자는 분명히 "언제, 누가, 어디서, 무엇을 많이 주문했는가?"라는 질문을 떠올릴 것이다. 이러한 질문을 쿼리로 보면 ( GROUP BY 언제, 누가, 어디서, 무엇 )이 될 것이고 이러한 쿼리는 OLTP에서는 상상도 못할 무지막지한 쿼리가 될 것이기 때문에 별도의 환경, 즉 OLAP 환경이 필요한 것이라고 할 수 있다. 그리고 OLAP을 위해 DW가 필요하다.

DW 아키텍처

위의 그림은 전통적인 DW 아키텍처이다.
간단하게 도색했지만 대부분의 설계에서 큰 틀은 비슷하다.



먼저 운영계(기간계) 설명을 하면 여러 곳에 퍼져있는 데이터 소스들의 집합이라고 볼 수 있다. 이는 오라클, mssql, mysql, postgrel 등의 RDBMS로 되어있을 수도 있고, HADOOP 같은 파일 시스템으로 존재할 수도 있고, CSV/TXT 등의 파일형식, JSON/XML 등 웹 형식으로 존재할 수 있다. 다시 말하면 이 영역은 원천 데이터 소스 영역이다.



다음은 운영계 데이터를 DW영역으로 가져가기 위한 ETL 작업이다. ETL은 Extract, Transform, Load의 합성어이며 말 그대로 추출, 변형, 로드가 가능하지만 큰 의미에서는 소스에서 타겟으로 데이터를 옮기는 작업이라고 생각하면 쉽다. ETL을 위한 Tool이 따로 존재하며 Informatica, SSIS,  DataStage 등이 있다. 또한 오픈소스로는 하둡의 Sqoop이 존재한다.
추가로 ETL 용으로 사용할 수 있는 기술인 CDC(change data capture)라는 것도 있으며 소스 데이터베이스의 LOG를 읽어서 타겟에 동기화를 시켜주는게 있다. 이는 실시간 처리가 가능하다는 장점이 있지만 좋은 솔루션은 가격이 부담스럽다. 솔루션으로는 Oracle GoldenGate 등이 존재한다.



다음은 실제 DW영역이라고 할 수 있는 STG->ODS->DW->DM 영역이다.
STG는 임시 데이터 영역이며, ODS는 원천(소스)과 일치하는(가공안한) 데이터 영역, 그리고 DW는 ODS를 가공해서 만들어내는 데이터 영역, DM도 마찬가지로 ODS나 DW를 가공해서 만들어내는 데이터 영역이다. 사실 DW와 DM은 큰 구분이 없으며 DW가 모든 것을 수용하고 있다면 DM은 뒤에서 서비스용도로 사용하기 위해 미리 계산된, 즉 집계해놓은 데이터라고 생각하자.
이 부분은 일반적인 SMP 구조의 DB 보다는 MPP 구조의 DB가 좋은 성능을 발휘할 수 있다. 예를 들어서 PDW(Parallel Data Warehouse), Teradata, Greenplum 등이 존재하는데 MPP구조의 경우 SMP보다 성능, 확장성이 좋으며 노드(용량)를 추가할 때 마다 성능이 선형으로 증가되기 때문이다. (하둡의 데이터 노드와 비슷하다고 생각하면 좋겠다.)



마지막으로 BI 및 서비스 영역이다.
여기서는 DW에서 미리 집계해놓은 데이터를 바탕으로 화면에서 차트 및 그리드 형식으로  화면에 보여줄 수 있을 뿐만 아니라 DW에서 계산된 데이터를 바탕으로 고객에게 상품을 추천한다던지 등의 활용을 하는 영역이다.
BI 솔루션으로는 Power BI, Spotfire 등이 있으며 오픈소스나 highchart, highmap 등을 통해 직접 구현해도 충분히 좋은 그림을 만들어낼 수 있다.




여기까지가 전통적인 DW 아키텍처에 대해서 이야기를 적어봤다.
100% 그런 것만은 아니지만 정형 데이터(관계형 데이터) 기준으로 현재 DW를 구축했다고 볼 수 있다.

하지만 앞으로는 DataLake, 즉 데이터 호수의 개념으로 확장 될 것이다. DataLake라 함은 모든 데이터를 대상으로 하는 곳이며 DW보다 더 큰 의미이자, 빅데이터 웨어 하우스(?)라고 이해해도 좋을 것 같다.

또한 수년 전부터 데이터 저장을 하둡으로 하여 하둡으로 DW를 구축한 곳이 늘어나고 있다. 물론 하둡으로 RDBMS를 100% 대체하는 것은 불가능하지만 분명히 하둡의 특성상 RDBMS의 상호 보완재로는 적합해보인다. 또한 하둡+스파크 조합은 싸고 확장성이 좋다.

클라우드 역시 요즘 엄청난 기세로 뜨고 있지만 비용이 만만치않아서 도입하기가 어려운 단점이 있다. 하지만 뛰어난 성능을 자랑하고 only 클라우드가 아닌 On-premise와 함께 하이브리드로 구축할 수도 있다. 예를 들어 대용량 집계만 클라우드에서 하고 쿼리는 On-premise에서 하는 구조가 있겠다.


마무리 글
원래는 ROLAP, MOLAP, Fact/Dimension 개념에 대해서도 설명하려고 했는데 글이 너무 길어져서 다음 포스팅으로 넘기려고 한다.
개인적인 생각이지만 앞으로 데이터의 발생량 및 수집량, 중요도가 커지면 커질수록 DW, DataLake, Bigdata의 가치도 커질 것이고 각각의 고유한 영역이 허물어져 어느 순간 OverLap되어 하나의 덩어리(?)가 될 것 같다.
그때를 위해서 각각의 영역을 모두 경험하면 더 좋은 설계를 할 수 있지 않을까 생각해본다.