OLTP와 OLAP, 그리고 Data Warehouse

데이터 엔지니어 채용을 보았을 때, 몇몇 기업들은 OLAP와 OLTP에 대한 경험을 우대사항으로 표기했었다. 데이터베이스 관련 지식이 부족한 본인은 이번 기회에 이 용어가 궁금해 알아보기로 했다!

 

OLTP, Online Transaction Processing

- 온라인 트랜잭션 처리

 

먼저 트랜잭션 처리에 대한 의미를 살펴볼 필요가 있다. 트랜잭션(Transaction) 처리는 주기적으로 수행되는 일관 작업과 달리 클라이언트가 지연 시간이 낮은 읽기와 쓰기를 가능하게 하는 것을 의미한다. (네트워크에서 HTTP 프로토콜을 공부했을 때 GET이나 POST 방식으로 서버와 클라이언트가 정보를 주고받는 한번의 행위를 트랜잭션이라고 배웠는데, 동일한 개념으로 받아들여도 될 것 같다.)  

 

현재 DB는 많은 여러 종류의 데이터(블로그 글의 댓글, 게임 액션, 주소록의 연락처 등)를 사용하지만 기본적인 접근 패턴은 비즈니스 트랜잭션 처리와 유사하다. 보통 애플리케이션은 색인을 사용해 일부 키에 대한 적은 수의 레코드를 찾는다. 레코드는 사용자 입력을 기반으로 삽입되거나 갱신되는데, 이런 애플리케이션의 경우 대화식이기 때문에 이 접근 패턴을 온라인 트랜잭션, OLTP라고 부른다.

 

그러나 DB를 데이터베이스에서도 점점 더 많이 사용하게 되면서, 트랜잭션과 다른 접근 패턴이 등장하게 되는데, 이것이 OLAP이다.

 

OLAP, Online Analytics Processing

- 온라인 분석 처리

 

"최근 프로모션 기간 동안 평소보다 얼마나 더 많은 바나나를 판매했는가?" 와 같은 비즈니스적 질의는 회사 경영진이 더 나은 의사결정을 하게끔 돕는 보고서, BI(Business Intelligence)에 제공된다. 이럴 때 사용하는 DB 접근 패턴이 OLAP라고 할 수 있다.

 

OLTP와 OLAP의 차이점을 크게 구분할 수 없지만, 표로 정리하면 다음과 같다.

특성	OLTP	OLAP
주요 읽기 패턴	질의당 적은 수의 레코드, 키 기준으로 가져옴	많은 레코드에 대한 집계
주요 쓰기 패턴	임의 접근, 사용자 입력은 낮은 지연 시간으로 기록	대규모 불러오기 또는 이벤트 스트림
주요 사용처	웹 애플리케이션을 통한 최종 사용자/소비자	의사결정 지원을 위한 내부 분석가
데이터 표현	데이터의 최신 상태(현재 시점)	시간이 지나며 일어난 이벤트 이력
데이터셋 크기	GB~TB	TB~PB

처음에는 트랜잭션 처리와 분석 질의를 위해 동일한 데이터베이스를 사용했다. 이와 관련해 SQL이 두 부분 매우 유연한 모습을 보이지만, 1980년대 말~ 1990년대 초반 회사들은 OLTP 시스템을 분석 목적으로 사용하지 않고 개별 데이터베이스에서 분석을 수행하는 경향을 보였는데, 이 개별 데이터베이스를 데이터 웨어하우스(Data Warehouse)라고 한다.

 

Data Warehouse

- 분석가들이 OLTP 작업에 영향을 주지 않고 마음껏 질의할 수 있는 개별 데이터베이스

- 회사 내의 모든 다양한 OLTP 시스템에 있는 데이터의 읽기 전용 복사본

 

대개 기업은 수십 가지의 트랜잭션 처리 시스템을 갖춘다.

Ex. 고객 대면 웹 사이트 강화, 실제 매장의 판매 관리 시스템 관리, 창고의 재고 이력 조사, 운송 수단을 위한 경로 계획 ...

이런 시스템들은 복잡하여 유지보수를 위한 팀이 필요하기 때문에, 각 시스템은 보통 서로 독자적으로 운영된다.

 

OLTP 시스템은 대개 사업 운영에 대단히 중요하여(Ex. 항공사의 경우 ETA) 일반적으로 높은 가용성과 낮은 지연시간에 트랜잭션 처리를 기대한다. 그래서 DBA가 OLTP 데이터베이스를 철저하게 보호하고, 비즈니스 분석가가 OLTP 데이터베이스에 즉석 분석 질의(ad hoc analytic query)를 실행하는 것을 꺼려한다. (비싼 즉석 분석 질의) 또한 분석 질의가 데이터셋의 많은 부분을 스캔하기 때문에 한정된 자원 안에서 동시에 실행되는 트랜잭션의 성능을 저하시킬 가능성도 존재한다.

이를 해결하기 위해 데이터 웨어하우스 개념을 도입하였다.

 

데이터는 OLTP 데이터베이스에서 주기적인 데이터 덤프나 지속적인 갱신 스트림을 사용해 추출(Extract)하고, 분석 친화적인 스키마로 변환(Transform) 및 정리 후 데이터 웨어하우스에 적재(Load)한다. 데이터 웨어하우스로 데이터를 가져오는 일련의 과정을 ETL이라고 한다.

 

ETL의 한 예시

분석을 위해 OLTP 시스템에 직접 질의하지 않고 개별 데이터 웨어하우스를 사용하는 큰 장점은 분석 접근 패턴에 맞게 최적화가 가능하다는 점이다. B 트리나 LSM 같은 색인 알고리즘은 OLTP에서 잘 동작하나 분석 질의의 응답에서는 별로 좋지 않은 편이다.

 

OLTP 데이터베이스와 데이터 웨어하우스의 차이점

SQL은 일반적으로 분석 질의에 적합하기 때문에, 데이터 웨어하우스의 데이터 모델은 가장 일반적인 관계형 모델을 사용한다. SQL 질의를 생성하고 결과를 시각화하고 분석가가 드릴 다운, 슬라이싱, 다이싱과 같은 작업을 통해 데이터를 탐색할 수 있게 해주는 여러 그래픽 분석 도구가 있다.

 

표면적으로 데이터 웨어하우스와 관계형 OLTP 데이터베이스는 둘 다 SQL 질의 인터페이스를 지원한다. 하지만 각각 매우 다른 질의 패턴에 맞게 최적화되어 있다. 다수의 데이터베이스 벤더는 트랜잭션 처리와 분석 작업부하 양쪽 모두 지원하기보다는 둘 중 하나를 지원하는 데 중점을 둔다.

 

마이크로소프트 SQL 서버와 SQP HANA 같은 일부 데이터베이스는 동일한 제품에서 트랜잭션 처리와 데이터 웨어하우징을 지원한다. (하지만, 점점 공통 SQL 인터페이스로 접근할 수 있는 저장소와 질의 엔진으로 점점 분리되고 있다)

 

Teradata, Vertica, SAP HANA, ParAccel 같은 데이터 웨어하우스 벤더는 고가의 상용 라이선스로 시스템을 판매한다. 최근 들이 다수의 오픈소스 SQL-on-Hadoop 프로젝트가 생겨났다. Apache Hive, Spark SQL, Cloudera Impala, Facebook Presto, Apache Tajo 등이 해당한다.

 

현재 모든 대기업에는 데이터 웨어하우스가 존재하나 소규모 기업은 그렇지 않다. 적은 양의 데이터는 일반적인 SQL 데이터베이스에 질의를 하거나 스프레드시트에서도 분석이 가능하기에, 소규모 기업은 필요가 없다.

 

 

* 드릴 다운 : 요약된 정보에서 상세 정보까지 계층을 나눠 구체적으로 분석

* 슬라이싱 / 다이싱 : 상세한 분석을 위해 주어진 큰 규모의 데이터를 작은 단위로 나누고 원하는 세부 분석 결과를 얻을 때까지 반복