간단하게 살펴보는 빅데이터 분석과 관련 개념들
0. 글을 시작하며
올해 2월 현재 회사에 서버개발자로 입사했지만 부가적인 업무로 빅데이터 분석을 통한 BI(Business Intelligence)를 지원하는 업무를 병행하게 되었습니다. 입사 초반에 모르는 기술 용어와 개념으로 가득한 회의에 들어가면서 어려움을 겪었던 기억이 있습니다. 물론 이 분야를 전문으로 하지 않는 상황에서 빅데이터 분석에 대한 전문적인 개념들을 모두 이해하고 업무를 하는 것은 불가능하지만 "해당 분야에 대한 큰 그림을 이해하고 접근하자"라는 관점이 업무를 진행하는 데 굉장히 큰 도움이 되었습니다.
이 글에서는 빅데이터 분석에서 사용하는 어떤 특정 기술에 대한 전문적인 내용을 다루는 것이 아니라 빅데이터 분석 분야에 대한 대략적인 큰 그림을 정리해보고자 합니다. 혹시 저처럼 본인의 주력분야가 아니지만 BI 지원과 같은 명목으로 빅데이터 분석일을 하셔야하는 경우 이 글이 도움이 될 수 있으면 좋겠습니다.
1. BI(Business Intelligence)
현재 우리는 거의 모든 것들이 "전산화"되어 있는 세상에서 살아가고 있습니다. 그만큼 일상 속에서 많은 전산화된 서비스를 인지하지 못할정도로 많이 사용하고 있다는 것이고, 이러한 사용 정보 or 기록은 해당 서비스 기업이 관리하는 서버에 로그의 형태로 저장됩니다. 로그로 남길 수 있는 정보의 종류는 굉장히 많겠지만 대략적으로 다음과 같은 정보들을 로그로 관리할 수 있을 겁니다.
1. 언제, 어떤 사용자가, 어떤 페이지에 접속을 했다.
2. 언제, 어떤 사용자가, 어떤 페이지에서 어떤 컴포넌트를 클릭했다.
3. 언제, 어떤 사용자가, 무엇을 검색했다.
4. 언제, 어떤 사용자가, 어떤 플랫폼(웹 or 앱)을 통해 접속했다.
5. 언제, 어떤 사용자가, 어떤 기기(안드로이드 or iOS)를 사용해 접속했다.
기업 입장에서 이러한 정보들을 잘 가공한다면 비즈니스(ex. 현재 런칭한 서비스)가 어떻게 사용되고 있는 지, 사용자 비율은 어떤 지, 어떤 서비스가 반응이 좋은지 등과 같은 중요한 정보를 얻을 수 있으며, 추가로 알고리즘화된 통계연산이나 머신러닝 기술을 활용하여 미래에 대한 정보도 예측할 수 있습니다. 이러한 정보들을 기반으로 비즈니스를 향후 어떤 방향으로 개척해야할지, 현재 비즈니스의 약점과 강점이 무엇이고 약점을 어떻게 보완할지와 같은 중요한 비즈니스적 의사결정에 활용할 수 있게 됩니다.
이러한 모델을 구축하기 위해서는 많은 기술들이 필요합니다. 매일 수만, 수십만건씩 발생할 비즈니스 데이터들을 어떻게 수집하고 저장할 것인지, 비즈니스를 구성하는 각 도메인별로 필요한 데이터들을 어떻게 추출할 것인지, 추출한 데이터를 어떻게 시각적으로 표출하여 사용자에게 보여줄 것인지 등과 같은 기술적 문제를 해결하는 많은 기술들이 존재하며 실제로 많은 기업들이 이러한 기술들을 적절히 조합한 시스템을 구축하여 비즈니스적 의사결정에 활용할 수 있는 시각화된 데이터를 표출하는 파이프라인을 구축하게 됩니다.
이와 같이 "기업의 비즈니스와 관련된 데이터를 수집 및 가공하여 비즈니스적 의사결정을 지원하는 시스템 및 기술"을 가리켜 비즈니스 인텔리전스(BI, Business Intelligence)라고 합니다.
2. OLTP vs OLAP
데이터베이스를 바라보는 관점을 크게 두 가지로 나눠볼 수 있습니다. 가장 먼저 관계형과 비관계형DB가 바로 떠오를 수 있지만 이번에는 OLTP와 OLAP의 관점으로 구분해서 보고자합니다. 우선 각각의 용어가 의미하는 바와 그 특징은 다음과 같습니다.
OLTP (= Online Transaction Processing)
실시간 트렌젝션을 관리하고 처리하는 데 집중하는 데이터 베이스
1. 보통 많은 수의 작은 Transaction이 처리된다 (INSERT, UPDATE, DELETE).
2. 대부분의 쿼리들이 소량의 데이터를 다루는 경우가 많다.
3. 이미 INSERT된 데이터에 대한 UPDATE 작업이 빈번하게 발생한다.
4. 여러 사용자 또는 요청이 발생하는 환경에서도 동시성 문제를 해결하며 빠르게 쿼리를 처리하는 데 집중하는 경향이 있다.
5. ex. MySQL, Oracle, etc...
OLAP (= Online Analytical Processing)
대량의 데이터를 분석하는 데 집중하는 데이터 베이스
1. 대부분의 쿼리들이 매우 복잡하고 Aggregation의 수가 많다.
2. 하나의 Query가 다루는 데이터의 양이 OLTP에 비해 압도적으로 많다.
3. UPDATE는 거의 발생하지 않고 대부분이 READ의 성격을 가진다.
4. 사용자가 요청한 결과를 얼마나 빨리 받아볼 수 있는 가에 집중하는 경향이 있다.
5. ex. Google BigQuery, etc...
기존 Database의 역사는 뒤에서 설명할 OLTP 계열의 데이터 베이스에 초점이 맞춰져 있었습니다. 즉 현재도 많이 사용하는 MySQL, Oracle과 같은 성격의 데이터베이스를 말하는 것입니다. 이 데이터베이스들의 주된 목적은 "관리하는 데이터들을 저장 및 업데이트하는 일련의 작업들을 처리하는 것" 이었고, 이 작업들의 단위인 Transaction을 관리하는 것이 가장 큰 핵심이었습니다. 그래서 OLAP와 같이 분석작업에 특화된 데이터베이스가 나오기 이전에는 분석을 위한 데이터도 모두 OLTP에서 관리하였습니다.
하지만 대용량 데이터 분석의 경우 보통 다음과 같은 특징을 가지고 있습니다.
1. 데이터를 한번 INSERT 하고나면 INSERT한 데이터에 대해서는 UPDATE가 빈번하게 발생하지 않는다.
2. 대부분 READ 성격의 요청이 많다.
3. 사용되는 쿼리의 길이가 복잡하며 길다.
대용량의 데이터를 분석하는 작업이 가지는 위와 같은 특징들은 이러한 데이터들을 OLTP 데이터 베이스에 관리하는 것이 그렇게 효율적이지 못하다는 결론에 도달하게 됩니다. 그래서 기존의 OLTP 데이터베이스는 그대로 두고, 여기에 추가로 데이터 분석작업에 특화된 데이터베이스를 만들자는 의견이 나오게 되며 이것이 OLAP 라는 개념으로 이어지게 됩니다.
그래서 OLAP 데이터베이스는 이름에서 알 수 있듯이 분석작업에 특화된 데이터베이스이며, 대량의 데이터를 다루는 통계쿼리에 대한 결과를 빠르게 사용자에게 제공하는 것이 핵심이기 때문에 Query Evaluation Algorithm, Query Optimization과 같은 기술이 굉장히 중요한 핵심이 됩니다. 또한 OLTP 데이터베이스들이 중요하게 다루는 ACID 속성의 경우 OLAP 데이터베이스들은 이를 조금 지키지 못한다고 하더라도 처리 속도를 향상시키는 데 더 집중하는 경향이 있습니다.
그렇다면 OLTP, OLAP 개념 둘을 한번에 커버할 수 있는 그런 아주 좋은 단일 솔루션을 만들 수는 없는 것일까요? 그럴 수 없는 몇 가지 이유가 존재합니다.
1. 리소스 사용정책 관점에서 OLTP, OLAP를 하나의 시스템에 두는 것이 어려움
2. 두 시스템이 데이터를 모델링하는 방식이 서로 다름
3. 두 시스템이 데이터를 처리하는 방식이 서로 다름
우선 리소스 사용정책 관점에서 OLTP와 OLAP를 하나의 시스템에 두면 두 정책이 충돌하게 되는 문제점이 발생하게 됩니다. OLTP의 경우 개별 작업(Transaction)이 놀고 있는 리소스를 활용하여 최대한 빠르게 처리되도록 하려고 합니다. 하지만 OLAP는 쿼리의 빠른 처리도 중요하지만 그보다 시스템의 Utilization 즉, 최대한 많은 하드웨어 리소스를 확보하려는 경향이 강합니다. 그렇기 때문에 이러한 정책의 차이로 OLTP와 OLAP가 서로 손해를 보는 상황이 발생하게 됩니다.
다음으로 두 시스템이 데이터를 모델링하는 방식이 다릅니다. OLTP의 경우 빠른 Transaction 처리와 불필요한 중복 데이터를 줄이기 위해서 데이터를 최대한 정규화(Normalization) 하려는 성격이 강합니다. 그렇다보니 table의 수가 많고 이 table 사이에 여러 연관관계가 형성되며 데이터 모델이 복잡해지게 됩니다. 하지만 OLAP의 경우 의도적으로 비정규화(Demormalization)를 수행하는 경향이 강합니다. 왜냐하면 분석의 경우 READ가 많기 때문에 매번 JOIN을 빈번하게 수행하는 것이 오히려 비효율적이기 때문입니다. 실제로 OLAP로 데이터를 끌어오는 과정에서 비정규화를 수행하는 경향이 강합니다.
마지막으로 두 시스템이 데이터를 처리하는 방식이 다릅니다. OLTP의 경우 사용하는 자원의 극대화보다는 현재 요청된 Transaction을 최대한 빠르게 처리하는 것(시스템의 반응성을 향상하는 것)에 관심을 두고 있습니다. 하지만 OLAP의 경우 현재 시스템의 리소스 사용률을 극대화하는 관점으로 접근하게 됩니다. 시스템의 리소스를 최대한 많이 확보해야 대량의 데이터를 처리 및 분석하는 데 유리하기 때문입니다.
즉, 이와 같은 이유들로 인해 보통 OLTP와 OLAP는 서로 다른 시스템에 구성하고 이 둘을 서로 연동하여 사용하게 됩니다.
정리하면 기존 OLTP 데이터 베이스 시스템 상에서 빅데이터 분석작업을 수행함에 있어 비효율적인 부분들이 많아 분석작업에 특화된 데이터베이스를 만들자는 의견이 나오며 OLAP의 개념이 탄생하였고, 그렇다 보니 이 둘의 성격은 많이 다릅니다. 그렇다보니 보통 이 둘을 하나의 시스템에 두지 않고 서로 다른 시스템에 구성하고 연동해서 사용한다고 이해하시면 됩니다.
3. ETL / ELT Process
그래서 기존 OLTP에 더해 분석 작업에 특화된 OLAP 데이터 베이스의 개념과 이를 지원하는 솔루션들이 나오게 됩니다. 하지만 여기서 해결하고 넘어가야하는 중요한 문제가 한가지 있는 데, 그것은 바로 OLTP에서 OLAP로의 데이터 마이그레이션 문제 입니다. 보통 원본 데이터들은 서비스에서 오는 경우가 대부분이기 때문에 OLTP에서 관리되고, 이를 분석하기 위해서는 OLTP에서 관리되는 비즈니스 데이터들을 OLAP로 마이그레이션 해야 합니다. 물론 각 솔루션 별로 마이그레이션 방법은 모두 다를 수 있습니다. 하지만 이 마이그레이션 절차를 정형화해서 표현한 개념이 있는 데, 그것이 ETL / ELT 프로세스 입니다.
ETL (Extract - Transform - Load)
데이터를 추출하고 적절히 변환한 뒤 적재하는 방식
ELT (Extract - Load - Transform)
데이터를 추출하고 먼저 적재한 뒤 변환하는 방식
각 단계들을 정리해보면 다음과 같습니다.
- Extract : 원본 데이터에서 필요한 데이터를 추출하는 단계. 여러 데이터소스(DB, 파일, API 등)로부터 필요한 데이터들을 가져온다.
- Transform : 데이터를 비즈니스 규칙에 따라 변환, 정제, 조작하는 단계. 데이터에 대한 집계, 정규화, 필터링 작업을 수행한다.
- Load : 데이터를 목적지에 적재하는 단계.
두 용어 모두 데이터를 추출한 뒤 가공하여 적재할 지, 적재한 뒤 가공할 지에 대한 순서만 다를 뿐 모두 같은 개념입니다. 다만 둘의 차이점은 "데이터에 대한 변환(Transfrom)작업이 언제 이뤄지는 가?" 라는 부분입니다. ETL의 경우 변환작업이 데이터 추출 후 적재가 이뤄지기 전에 발생하고, ELT의 경우 목적지에 저장한 뒤 변환작업이 이뤄지게 됩니다. 보통 ETL의 경우 대규모의 데이터나 복잡한 변환과정이 필요한 경우, ELT의 경우 작은 규모의 데이터나 비교적 간단한 처리과정인 경우 적용합니다.
물론 이 과정은 하나의 거대한 프로세스이기 때문에 이를 별도로 관리하는 기술이 필요하며, 이러한 프로세스를 지원하기 위해서 Kafka, Airflow, Oozie와 같은 다양한 기술들이 사용됩니다 (그냥 이런 기술들이 해당 과정에서 필요한 기술들을 지원하는 솔루션 이라고 이해하고 넘어가시면 됩니다).
정리하면 데이터가 발생하는 다양한 원천으로부터 OLAP로 데이터를 입수하는 프로세스를 가리켜서 ETL, ELT 프로세스라고 부른다고 이해하시면 됩니다.
4. Data Warehouse
이렇게 ETL 또는 ELT 프로세스를 통해 의미있는 데이터를 구성하였다면, 이를 분석에 사용하기 위해서 어딘가에 저장해두고 사용할 수 있어야 합니다. 즉, 분산되어 관리되는 여러 데이터들을 분석하기 좋은 형태로 가공 후 한 곳에 모아서 관리하는 큰 규모의 데이터베이스 시스템이 필요하며, 이를 가리켜 데이터 웨어하우스(Data Warehouse)라고 합니다(줄여서 DW라고 표현하기도 합니다). 그리고 이 데이터 웨어하우스를 구성하는 과정을 가리켜 데이터 웨어하우징(Data Warehousing)이라고 표현합니다.
데이터 웨어하우스에서 관리되는 데이터들은 다목적 데이터 분석 용도로서 활용됩니다. 즉, 데이터 웨어하우스 관점에서 각 관리되는 데이터들은 그 사용목적이 특정화되어 있지 않으며, 분석 데이터로서 유의미하게 활용될 가능성이 높은 데이터들을 포괄적으로 포함하고 있습니다. 하지만 비즈니스 내에서도 여러 도메인이 존재하고, 각 도메인별로 다른 도메인과 구분되는 특정 데이터가 필요할 수 있으며, 각 도메인별로 지표를 집계하는 방식이나 데이터를 구성하는 방식이 다를 수 있습니다. 따라서 데이터 웨어하우스를 통으로 하나로만 관리하는 것은 데이터 웨어하우스에 접근하는 여러 조직의 요구사항을 만족하기 어려울 가능성이 존재합니다.
그래서 데이터 웨어하우스를 전체적인 큰 그림으로 보면 하나의 데이터 웨어하우스가 다시 여러 개의 서브 컴포넌트로 구성되는 경우가 있는 데 이때 각각의 서브 컴포넌트들을 가리켜 데이터 마트(Data Mart)라고 표현합니다. 데이터 웨어하우스를 구성하는 서브 컴포넌트 개념인만큼 데이터 마트는 특정 비즈니스 도메인을 위해 설계 및 구성되는 경우가 많습니다.
정리하자면, 앞서 살펴본 ETL or ELT 프로세스를 통해 처리된 데이터들을 저장해두고 분석에 사용하기 위해서 한 곳에 모아두는 중앙 데이터 베이스 시스템을 가리켜 데이터 웨어하우스라고 하고, 이 때 데이터 웨어하우스는 여러 서브 컴포넌트 즉, 여러 개의 데이터 마트로 구성될 수 있습니다.
5. Data Lake
추가로 데이터 웨어하우스와 유사해 보이지만 조금 다른 개념인 데이터 레이크(Data Lake)라는 개념이 있습니다.
앞서 OLAP의 개념에 대해 간략히 설명하면서 OLTP에서 관리되고 있는 원본 데이터를 다음과 같이 ETL or ELT 프로세를 거쳐 OLAP로 마이그레이션 한다고 설명했었습니다.
OLTP Database -> ETL or ELT Process -> OLAP Database
하지만 시간이 지나면서 다음과 같은 질문이 이어지게 됩니다.
비즈니스에서 발생하는 다양한 데이터들을 OLTP 데이터베이스에서 관리하는 것이 효율적인가?
물론 OLTP 데이터베이스에서 정의된 구조에 따라 엄격하게 관리하는 것이 더 효율적인 데이터들도 있겠지만 이 질문처럼 그렇지 않은 성격의 데이터들도 많습니다. 이러한 데이터들을 "구조가 정의되지 않았다"라고 하여 비정형 데이터 또는 애매하게 섞여있는 경우 반정형 데이터 라고 표현합니다. 그래서 이러한 데이터들을 다음과 같이 처리하자는 관점이 나오게 됩니다.
데이터의 구조, 형식에 구애받지 말고 일단 덤프(Dump)하는 방식으로 저장하고 가공해서 활용하자!
이와 같이 "다양한 형식과 소스에서 대규모의 원시 데이터를 수집하는 중앙 저장소"를 가리켜 데이터 레이크(Data Lake)라고 합니다. 데이터 레이크는 구조화된 데이터, 비구조화된 데이터, 반정형 데이터 등을 모두 저장할 수 있습니다. 즉, 형식이나 스키마에 대한 제약이 적습니다. 데이터 웨어하우스가 프로세스를 통해 처리된 구조화된 데이터를 관리한다면, 데이터 레이크는 구조화되지 않은 비정형 or 반정형 데이터들을 저장하는 저장소의 개념입니다.
최근 많이 사용하는 MongoDB와 같은 NoSQL 기반 데이터 베이스도 이러한 컨셉을 따릅니다.
6. Data Cube
데이터 큐브(Data Cube)는 비즈니스 인텔리전스와 데이터 웨어하우징에서 사용되는 개념입니다. 이는 다차원으로 정렬된 데이터 구조로, 여러 가지 차원에서 데이터를 조직화하여 분석하기 쉽게 만듭니다. 데이터가 가지는 여러 차원을 마치 큐브의 형태로 관리함으로서 원하는 차원의 분석들을 빠르게 수행할 수 있는 방법입니다.
어떤 차원을 가지는 데이터가 있다고 할 때, 데이터 큐브는 데이터를 다음과 같은 형태로 유지합니다.
일반적으로 데이터 큐브는 세 개 이상의 차원(예: 시간, 제품, 지역 등)을 가지며, 각 차원은 해당 데이터의 특성을 나타냅니다. 이러한 다차원 구조는 여러 데이터 요약 수준을 가질 수 있으며, 예를 들어 날짜별, 월별, 분기별로 데이터를 요약하거나 다양한 조합으로 데이터를 분석할 수 있습니다. 이를 통해 사용자는 복잡한 데이터 집합에서 패턴, 트렌드, 상관 관계 등을 쉽게 식별하고 이해할 수 있습니다. 예를 들어, 매출 데이터를 데이터 큐브로 구성한다면 시간, 지역, 제품 등의 차원을 가지게 됩니다. 이를 통해 특정 지역에서 특정 제품의 매출 추이를 분석하거나, 시간에 따른 제품별 매출 비교 등 다양한 분석이 가능해집니다.
중요한 점은 데이터 큐브를 생성할 때 각 차원의 조합에 대한 합계, 평균, 최댓값, 최솟값 등의 계산된 지표들을 미리 계산해둔다는 점입니다. 이렇게 미리 계산해 둔 집계값들은 사용자가 데이터를 조회할 때 실시간으로 계산하는 것보다 훨씬 빠르게 결과를 제공할 수 있다는 강력한 장점이 있으며, 실제로 데이터 시각화 툴과 함께 묶어서 많이 사용됩니다.
데이터 큐브가 지원하는 연산은 다음과 같으며, 이 개념을 지원하는 데이터 베이스의 경우 다음 연산과 거의 동일한 이름의 연산 함수를 지원합니다. 참고 목적으로만 남기며 각 연산에 대한 설명은 생략하겠습니다.
1. Pivoting
2. Slicing(dicing)
3. Rollup
4. Drill Down
실제로 이 개념을 구현한 솔루션들이 존재하면 대표적으로 Apache Druid가 있습니다.
7. 분산파일 시스템 (Distributed File Systems)
이렇게 데이터 분석을 목적으로 기업들이 많은 양의 데이터를 저장하게 되면서 시스템이 저장해야 하는 데이터의 양은 적게는 TB에서 많게는 PB 규모까지 상상을 초월하는 수준이 됩니다. 이렇게 매우 많은 양의 데이터를 저장해야하는 수요가 발생하게 되면서 이 모든 데이터들을 하나의 시스템에서 커버하는 것은 무리가 있음을 발견하게 됩니다 (처리 성능과 데이터 보존 신뢰성 측면).
그래서 이 데이터들을 하나의 시스템에서 관리하지 말고, 분산하여 여러 개의 시스템에서 관리하자는 아이디어가 나오게 되었으며, 이 개념을 구현한 시스템을 가리켜 "분산파일 시스템(Distributed File System)" 이라고 합니다. 이 개념을 구현한 대표적인 제품군으로는 GFS(Google File System), HDFS(Hadoop File System)가 있습니다 (HDFS에서 Node, Block 키워드를 중심으로 그 구조를 공부해보시는 것도 좋습니다).
그런데 이렇게 데이터를 물리적으로 분산되게 관리하게 되면 한 가지 문제가 있습니다. 결국 우리가 수집한 데이터를 모아서 집계해야하는 데 데이터들이 여러 조각으로 분산되어 서로 다른 곳에 저장되어 있다는 것입니다. 이 경우 분산되어 있는 각 데이터들에 대해서 먼저 연산을 수행하고(쿼리를 수행하고) 이 결과들을 모두 합쳐서 최종 결과를 도출하자는 아이디어가 나오게 되는 데 이것이 바로 Map-Reduce 연산 입니다. 위의 예시에서 분산되어 있는 각 데이터들에 대해서 먼저 쿼리를 실행하는 것을 Map, 각 결과들을 모두 합쳐서 최종 결과를 도출하는 것을 Reduce 연산이라고 이해하시면 됩니다.
물론 내부적으로 이를 수행하는 것을 직접 구현하려면 매우 복잡하고 어려운 일이겠지만 분산 파일 시스템을 지원하는 솔루션의 경우 대부분 이러한 문제들을 추상화하여 개발자들에게 map(), reduce() 형태로 function을 제공하여 편리하게 이용할 수 있습니다. 이를 가리켜 Map-Reduce Paradigm 이라고 부릅니다. 이 개념을 통해서 사용자는 신뢰할 수 있고, 확장 가능한 병렬 컴퓨팅 환경을 제공받고 사용할 수 있습니다.
10. Batch Processing
우리가 분석을 위해 대량의 데이터를 처리한다고 할 때, 이를 처리하는 방식을 다음 두 가지 관점으로 구분해서 바라볼 수 있습니다.
- 실시간으로 데이터를 처리
- 특정 시간에 일괄적으로 처리
보통 대량의 데이터를 처리하는 작업은 많은 리소스를 필요로하기 때문에 시스템에 상당한 부하를 줍니다. 그렇기 때문에 시스템이 일반적으로 많이 사용되는 주간에 대량의 데이터를 처리하는 프로세스가 실행된다고 한다면 리소스 부족으로 일반 사용자들과 연결되어 있는 중요한 기능이 빠르게 제공 또는 처리되지 못하거나, 심각할 경우 시스템 과부하로 장애를 일으킬수도 있습니다. 그래서 이러한 문제를 피하기 위해 대량의 데이터 처리 작업을 시스템 리소스 사용률이 낮은 시간대에 일괄적으로 처리될 수 있도록 구성하자는 아이디어가 나오게 됩니다.
이와 같이 실시간으로 데이터를 처리하지 않고 특정 시간을 정해두고 그 시간에 일괄적으로 작업을 처리하는 방식을 가리켜 배치(Batch Processing)라고 표현합니다. 어떤 데이터 처리가 매번 실시간으로 제공되어야 하는 성격이 아니라면 시스템 과부하가 발생할 수 있는 상황을 예방하거나 그 빈도를 줄이기 위한 목적으로써 배치 방식으로 처리하는 것을 고려해볼 수 있습니다. 배치 작업을 시스템 리소스 사용률이 낮은 시간대 (주로 새벽)에 할당하면 불필요한 시스템 과부하 상황을 예방하면서도 시스템 전체의 Utilization을 향상시킬 수 있다는 장점이 있습니다.
11. ILM (Information Lifecycle Management)
보통 분석을 위한 데이터를 적재할 때에는 이력에 대한 정보도 보고 싶어하는 경우가 많기 때문에 과거의 데이터를 지속적으로 유지하면서 새로운 데이터를 적재하게 되므로 시간이 지남에 따라 시스템이 저장해야하는 데이터량은 점점 많아지게 됩니다. 하지만 저장소는 유한하고, 불필요하게 많은 과거이력 데이터들 때문에 쿼리 실행속도가 느려지게 됩니다. 저장소의 공간과 쿼리실행비용은 모두 비용입니다.
시간이 점점 지날수록 과거의 데이터들의 분석대상으로서의 가치는 점점 떨어지게 됩니다. 즉, 데이터도 생명주기를 가지고 있어 생성된 초기에는 많이 사용되지만 시간이 지날수록 점차 사용빈도가 줄어들게 되다가 더 이상 사용되지 않게 됩니다. 따라서 데이터 수명 주기에 따라 데이터를 보관하는 방식을 달리하여 운영비용을 절감하는 데이터 관리 개념을 가리켜 ILM(Information Lifecycle Management)라고 합니다.
조직별로, 데이터의 성격에 따라 설정하는 기간이 다르겠지만 ILM이 적용된다는 것은 기간이 많이 지나 생명주기가 다한 데이터들을 폐기하거나 보관방식을 달리하여 접근방법이 달라질 수 있다는 정도의 의미로만 이해하시면 됩니다.
12. 글을 마무리하며
이 글은 빅데이터 분석에 대한 전문적인 내용을 다룬 글은 아닙니다. 다만 저처럼 빅데이터 분석에 대한 배경지식이 거의 없는 상황에서 해당 업무를 시작하셔야하거나 간략한 큰 그림을 그려보고 싶으신 분들에게 알고 있어야하는 용어들, 필요한 개념들을 최대한 간략하게 설명함으로써 도움을 드리고자 작성한 글입니다.
이 짧은 글로 빅데이터 분석이라는 거대한 분야를 설명하는 것은 불가능하지만 제가 실무에서 관련 업무를 받아 진행하면서 꼭 알아야했던 개념들, 또는 흐름을 이해하기에 좋았던 개념들을 모아서 정리하였습니다. 짧은 글이지만 조금이나마 도움이 되셨으면 좋겠습니다.
혹시 글의 내용에 대해서 잘못된 내용이나 개선점에 대한 피드백은 언제나 환영합니다.
감사합니다!
'Computer Science > 데이터 베이스' 카테고리의 다른 글
| JSON_CONTAINS(), IN 절의 검색 대상을 여러 개로 확장하는 전략 (1) | 2024.04.14 |
|---|---|
| [Google BigQuery] WITH문, 성능에 문제없을까? (0) | 2023.04.04 |
| [Google BigQuery] 1라인 쿼리에서 변수를 사용하고 싶을 때 (0) | 2023.04.03 |