1. 빅데이터와 분산 컴퓨팅

- IT 산업 현장에는 일반적인 서버 환경에서는 다루기 어려운 정도로 대량의 데이터를 처리해야 하는 경우가 있다. 이처럼 대량의 데이터를 처리하는 방법으로서 먼저 컴퓨터 시스템의 사양을 업그레이드 하는 것(scale up)을 생각할 수 있는데, 첫째로 이는 비용이 많이 소모되고 둘째로 이는 대량의 데이터를 처리하는 문제에서는 효용이 크지 않다. 대량의 데이터를 처리하는 문제에서는 CPU의 속도가 아무리 빨라져도 이에 비해 저장장치에서 대량의 데이터를 읽고 쓰는 속도가 크게 느려 결국 가용 자원을 모두 사용할 수 없기 때문이다. 따라서 대량의 데이터를 처리하는 환경에서는 이를 처리하는 서버의 컴퓨터 수를 한 대가 아니라 여러 대로 늘려서 처리하는 방식(scale out)이 더 널리 사용된다. 이처럼 처리하는 데 있어 일반적인 서버 컴퓨터 한 대로 처리할 수 없을 정도의 대량의 데이터를 흔히 빅데이터라 하며(2012년 아마존의 John Rauser의 정의), 이러한 빅데이터를 다루는 데는 분산 컴퓨팅, 분산 파일 시스템 같은 기술이 필수적이다.

  • 분산 파일 시스템(distributed file system): 거대한 크기의 파일이 물리적으로 여러 개의 디스크로 나뉘어 있어도 하나의 디스크에서 하나의 파일을 다루듯 다루는 파일 시스템을 분산 파일 시스템.

  • 분산 컴퓨팅(distributed computing): 여러 대로 나뉜 서버의 하드웨어 자원을 하나의 서버를 사용하는 것처럼 사용하는 기술. 분산 컴퓨팅 환경에서는 시스템의 일부 서버가 제대로 동작하지 않더라도 전체 시스템은 동작해야 한다는 문제(fault tolerance), 그리고 시스템을 활용하면서 서버 대수가 늘어나는 환경을 지원해야 한다는 문제가 중요한 문제가 된다.

2. Hadoop

- 2000년대 초반 구글은 서버 한 대로 처리할 수 없는 규모의 웹페이지를 처리하는 방법론에 관한 논문(2003년 ‘The Google File System’, 2004년 ‘MapReduce’)을 발표해 이 논문을 토대로 빅데이터를 처리하는 기술이 여럿 논의되기 시작했다. 여기서 영향을 받은 Doug Cutting이 Nutch라는 오픈소스 검색엔진을 개발하며 하부 프로젝트로 분산 파일 시스템(HDFS), 분산 컴퓨팅(MapReduce) 기술을 지원하는 오픈소스 프로젝트 Hadoop을 제시했는데, Hadoop은 이후 아파치 재단의 top-level 프로젝트가 되는 등 크게 주목을 받았으며 이후 이를 토대로 빅데이터 처리 기술이 보편화되게 되었다.

  • Hadoop 애플리케이션과 HDFS(Hadoop distributed file system): Hadoop에서는 애플리케이션이 HDFS에 접근하려면 원칙적으로 MapReduce를 사용해야 하나, Hadoop 2.0 이후 HDFS를 관리하는 프레임워크로서 YARN이라는 프레임워크가 제시돼 이 이후 Hadoop의 애플리케이션은 MapReduce가 아니더라도 이를 통해 HDFS에 접근할 수 있다. (Hadoop 2.0 발표 전에는 YARN이 없었기 때문에 HDFS에 접근하려면 바로 MapReduce를 이용해야 했다.)

- Hadoop은 fault tolerance 문제 해결을 위해 하나의 데이터를 반드시 3개의 서버에 따로 저장(replication)한다. 따라서 만약 아무리 서버가 많더라도 한 파일이 저장돼 있는 서버 3개가 모두 고장나면 그 파일은 손실될 수밖에 없다. 다만 그 확률은 매우 낮으므로, Hadoop은 이러한 방식으로 fault tolerance 문제를 어느 정도 극복했다고 할 수 있다.

3. 데이터 웨어하우스

1) 개요

- 기존의 DBMS는 서버 한 대로 처리할 수 있는 규모의 데이터만을 목적으로 만들어져, 분산 컴퓨팅을 지원하지 않아 서버 한 대로 처리할 수 없는 규모의 데이터를 다루는 데는 부적합하다. 따라서 Hadoop과 같은 분산 컴퓨팅 환경에서는 이러한 처리를 지원하는 특수 목적 DBMS가 따로 필요하며, 이러한 DBMS를 기존 DBMS와 구분하여 데이터 웨어하우스(data warehouse)라 한다. 반대로 기존 DBMS를 프로덕션 DB라 하며, 오라클, MySQL 등이 프로덕션 DB라면 Redshift, Snowflake, BigQuery, Hive 등이 데이터 웨어하우스에 해당한다.

- 데이터 웨어하우스는 보통 bulk update를 지원하고, primary key uniqueness가 보장되지 않는 등 프로덕션 DB와는 제공하는 기능에 차이가 있다.

2) 데이터 웨어하우스와 SQL

- 2000년대 중반 Hadoop과 MapReduce가 등장했을 당시에는 SQL이 빅데이터를 지원하지 않았던 반면 MapReduce는 그 자체만으로 성능이 뛰어났으므로 ‘SQL은 소형 데이터를 다루기에만 적합하고 빅데이터에는 적합하지 않다’라는 인식이 생겼었으나, 얼마 지나지 않아 MapReduce의 어려운 난이도로 인해(낮은 생산성) SQL에 대한 주목도가 높아져 빅데이터를 다루는 데에도 SQL이 유용하다는 인식이 생기면서 현재 널리 쓰이는 데이터 웨어하우스들 다수가 SQL을 지원한다. (Hadoop에서는 컴퓨터 한 대에서 DB를 사용하듯 SQL 쿼리를 쓰면 Hive가 이를 MapReduce에서 이해할 수 있는 언어로 컴파일해 작동한다.)

- SQL은 구조화된 데이터를 다루는 데는 유용하나 구조화되지 않은 데이터를 다루는 건 어렵다는 점, JSON처럼 field 안에 field가 들어가는 형태가 불가능하고 flat한 데이터 구조만 갖는다는 점 등의 단점이 있어 구조화되지 않고 복잡도가 높은 대량의 데이터를 다루는 데 어려운 점이 있다. 데이터 웨어하우스에서는 이러한 단점을 고려하여 여러 기능을 지원한다.

3) 데이터 웨어하우스와 denormalized schema

- 일반적인 프로덕션 DB의 경우 하나의 DB에 여러 테이블이 있어 데이터 엔티티 하나를 여러 스키마로 나누어 각 테이블에 저장하는 스키마 구조를 갖는데, 이는 온라인 상에서 동시에 여러 트랜잭션이 수행되더라도 update anomaly 문제가 일어나는 것을 막기 위해 정규형 상태로 릴레이션 스키마를 구축했기 때문이다. (이러한 형태의 스키마를 star schema라 하며, 이처럼 온라인 상에서 동시에 여러 트랜잭션을 수행하기 적합하게 스키마를 구축한 데이터베이스를 online transaction processing database, OLTP DB라고도 한다.) 다만 이러한 형태의 DB의 경우 데이터 하나의 완전한 전체 내용을 가져오려면 여러 테이블끼리 join 연산을 수행해야 하며, 따라서 프로덕션 DB에서 데이터 분석을 위해 대량의 데이터를 한꺼번에 가져오는 쿼리를 실행하면 연산량이 그만큼 매우 크게 증가한다. 이는 데이터 분석에 매우 불리하다.

- 따라서 온라인 사용자의 데이터 분석을 위해 대량의 데이터를 한꺼번에 가져오는 쿼리를 자주 실행하는 데이터 웨어하우스의 경우 star schema보다는 역정규화된 스키마(denormalized schema)를 사용한다. (이처럼 온라인 상에서의 데이터 분석을 위해 적절히 역정규화된 스키마를 구축한 데이터베이스를 online analytical processing database, OLAP DB라고도 한다.) 이 경우 그만큼 테이블에 중복되는 내용이 많이 늘어나게 돼 어느 정도 저장공간 낭비가 발생하지만, 대신 데이터 하나의 전체 내용을 가져올 때 join 연산을 하지 않으므로 대량의 데이터를 한꺼번에 가져올 때 그만큼 시간적인 이익이 있다.

4) Redshift

- AWS에서 제공하는 데이터 웨어하우스다. 공식적으로 2PB까지 지원한다고는 하나 용량이 늘어날수록 성능 지원에 한계가 있다는 평이 있다.

- 다음과 같은 특징이 있다.

  • 컬럼별 압축이 가능하여, 컬럼을 추가하거나 삭제하는 속도가 매우 빠르다.

  • 고정된 비용을 지불하여 고정된 용량을 받는 식으로 서비스가 제공된다.

  • PostgreSQL 8.x와 호환되나(따라서 PostgreSQL 8.x를 지원하는 툴, 예를 들면 SQL Workbench, Looker, Tableau, Power BI, Superset 등의 툴로 Redshift에 접근할 수 있다), PostgreSQL 8.x의 모든 기능을 지원하지는 않는다.

- 다음과 같은 schema들로 구성된다.

  • raw data

  • analytics: raw data를 가공하여 얻은 테이블들을 저장하는 schema. 데이터 애널리스트들은 분석한 내용을 이 schema에 저장하여 이 내용을 토대로 dashboard를 구성하는 등의 작업을 수행한다.

  • ad hoc: 개발자 등이 테스트 등의 잡다한 업무를 할 때 사용하는 schema. 단지 테스트용이기 때문에 별로 중요한 schema는 아니다.

4. Hadoop과 Spark

- Spark는 2013년 미 버클리대 AMPLab에서 아파치 오픈소스 프로젝트로 시작된 Hadoop의 애플리케이션으로서, 대량의 데이터를 처리하는 일종의 툴이다. 사용하기 어렵다는 MapReduce의 단점을 대폭 개선하였다. (Python의 라이브러리인 pandas와 사용 방식이 유사하다.) Spark는 내부적으로는 scala로 작성되었지만 Java, Python으로도 사용이 가능하다.

- Spark에서 사용하는 기본적인 데이터형은 RDD(resilient distributed dataset)으로 low-level programming API(map, filter 등)를 통해 제어할 수 있다. (RDD는 변수형 자체가 속성명이라는 개념을 지원하지 않아 비구조적인 데이터도 담을 수 있는 변수형이다.) 한편 Spark에서 지원하는 또 다른 데이터형인 Dataframe, Dataset형은 high-level programming API를 통해 제어한다. (Dataframe, Dataset은 RDD와 달리 속성명 개념을 지원하는 변수형으로서 담겨있는 데이터들은 속성명 단위로 구조화 되어 있다. Dataframe은 각 속성값이 반드시 특정 변수형을 가져야 하는 것은 아니지만 Dataset은 각 속성값이 특정 변수형만 담을 수 있다는 차이가 있다.)

- Spark를 이용하여 Redshift에 접속해 데이터를 가져올 수도 있다.

5. ETL와 Airflow

- 어떤 기업이 통상적인 업무에서 사용하는 데이터는 보통 프로덕션 DB에 담겨있는데, 통상적인 업무가 아니라 기업의 차후 의사결정을 위하여 데이터 분석을 수행하기 위하여 기업이 축적한 데이터를 가져와 연구를 할 때 매번 프로덕션 DB에 접근해 데이터를 가져오게 하면 이러한 DB 접근이 프로덕션 DB의 성능 전체에 영향을 줄 수 있다. 프로덕션 DB는 보통 데이터 분석에서 하는 것과 같이 대량의 데이터를 한꺼번에 가져오는 등의 작업을 수행하기에는 적합하지 않기 때문이다.

- 따라서 데이터 분석을 중요시하는 기업에서는 프로덕션 DB의 내용을 그대로 가져오되 이를 대량의 데이터를 다루는 데 더 적합한 데이터 웨어하우스에 담아 데이터 분석 업무를 하며, 이처럼 대량의 데이터를 프로덕션 DB에서 데이터 웨어하우스로 그대로 가져오는 작업을 ETL(extract, transform, load) 또는 data pipeline이라 한다. ETL 또한 분산 컴퓨팅 시스템, 데이터 웨어하우스와 함께 데이터 인프라의 구성요소가 된다.

- ETL을 관리하는 주요 프레임워크로 2014년 Airbnb의 데이터 엔지니어 Maxime Beauchemin가 처음 제시한 Airflow가 있다. 이는 오픈소스 파이썬 프레임워크로, 현재는 Hadoop과 마찬가지로 아파치 오픈소스 프로젝트이다. 현재 데이터 엔지니어링 업계에서는 필수적으로 사용되는 프레임워크 중 하나로 여겨진다.