최근 데이터 플랫폼 분야에서 많이 언급되는 단어가 '데이터레이크'다. 이와 함께 '데이터레이크하우스'도 자주 거론된다.
데이터레이크와 데이터레이크하우스는 모두 데이터를 저장하는 형태를 가리키는 말이다. 데이터의 유형이 정형에서 비정형으로 늘어나면서 다양한 DB 계층을 얹기 위한 스토리지 계층으로 나왔다.
조직에서 데이터를 활용하려면 많은 준비가 필요하다. 여러 곳의 데이터 생성 위치에서 분석이나 AI 시스템에 이르기까지 잘 정비된 데이터 흐름을 만들어야 원활한 활용이 가능해진다. ETL, 데이터 표준화, 비식별화 등 많은 절차를 거치게 된다. 만약 데이터 유형마다 각기 다른 데이터베이스와 저장소를 운영하면 각종 밑작업의 양이 DB와 저장소의 수만큼 늘어난다.
데이터레이크는 DW로 수용하기 힘든 비정형 데이터 활용에 초점을 둔 아키텍처다. 초기의 데이터레이크는 DW와 병존했는데, 데이터레이크와 DW을 단일 플랫폼으로 통합하자는 아이디어로 데이터레이크하우스가 고안됐다. 관리 부담을 줄이면서, 활용 수준을 높이는 게 주요 목표다.
최근 마이크로소프트는 애저 시냅스 블로그에서 데이터레이크, 데이터레이크하우스, 델타레이크 등의 개념과 각 차이점을 설명했다. 다소 비슷해보이는 용어 때문에 데이터레이크, 데이터레이크하우수가 혼란스러울 수 있다. 데이터레이크하우스가 데이터레이크의 진화 버전으로 언급되기도 하는데, 그를 도와주는 오픈소스 프로젝트로 '델타레이크'가 있다.
■ 데이터레이크
데이터레이크는 모든 규모의 정형 및 비정형 데이터를 저장하는 중앙집중형 저장소를 가리킨다. 정형 데이터만 다루는 데이터웨어하우스(DW)와 달리, 데이터레이크는 사전 정의된 스키마 없이 일단 저장하고 데이터 처리할 때 스키마를 사용한다.
단일 저장소에 데이터를 쌓아뒀다가 활용하는 측에서 입맛에 맞게 뽑아 사용하는 것이다. 데이터레이크는 저장 시 스키마를 사용하지 않으므로 데이터 정의에 소요되는 시간을 줄일 수 있다. 단일 스토리지에 여러 종류의 데이터베이스를 연결하기도 용이하다.
주의할 점은 데이터레이크가 원자성(Atomicity)을 제공하지 않는다는 점이다. 손상된 데이터의 증가 가능성을 내포한다. 스키마 적용이 없으므로 상당한 양의 근거없는 데이터를 쓸 수 있다. 스토리지 계층에 불과하므로 DML과 ACID(원자성, 일관성, 격리성, 내구성) 트랜잭션은 지원하지 않는다.
데이터 로드에 대한 품질 검증도 없다. 여러 유형의 데이터를 저장할 수 있지만, 잠재적인 데이터 불일치가 발생할 수 있다. 일관성이나 격리도 없다. 업데이트 진행중에 읽기나 추가가 불가능하다는 뜻이다.
데이터레이크에서 폴더 파티셔닝은 데이터 조회 시 파티션 가지치기/제거를 통해 특정 데이터 엔티티의 검색속도를 높여준다. 파티션 폴더 구조에 데이터를 저장하면, 데이터 관리성과 조회 성능을 높일 수 있다. 예를 들어 판매 데이터를 저장하고, 날짜(년, 월, 일)로 분할한 경우 이 데이터는 날짜값을 기준으로 분할된다.
이같은 폴더 파티셔닝은 조회 성능을 높이는데 도움을 주지만, 파일 수가 적거나 작은 파일로 너무 많은 파티션을 생성하면 사용가능한 자원과 병렬처리를 활용하지 못할 수 있다. 파티션을 세분화하는 수준과 각 파티션의 파일 수 사이에서 균형을 유지해야 한다. 이상적 파일크기는 100MB~1GB이고, 사용가능한 코어 파일의 수는 3~4배여야 한다.
■ 데이터레이크하우스
조직 내에서 데이터 활용 수요가 늘어나고 다양해지면서, 관계형 형식으로 여러 컴퓨팅 노드에서 병렬로 방대한 양의 데이터를 처리할 수 있는 최신 데이터웨어하우스 아키텍처를 채택하기 시작했다. 동시에 데이터레이크를 사용해 반정형, 또는 비정형의 데이터를 수집하고 관리하게 됐다.
서로 다르지만 관련있는 두 시스템은 사일로에서 실행되므로 개발 시간, 운영 부담, 총소유비용(TCO) 등이 증가하게 된다. 비즈니스 요구사항을 충족하기 위해 두 시스템의 데이터에 접근해야 하는 경우 최종 사용자가 데이터를 통합하는 불편을 초래한다.
데이터레이크하우스 아키텍처는 단일 데이터 플랫폼에서 DW와 데이터레이크의 장점을 결합하고, 초기 데이터 플랫폼 아키텍처의 기능을 단일한 통합 데이터 플랫폼(메달리온 아키텍처)으로 제공, 결합한다. 데이터레이크하우스는 모든 데이터와 분석, AI 및 머신러닝 워크로드를 통합하는 플랫폼이다.
일반적으로 데이터레이크하우스는 데이터 수명주기를 기준으로 데이터를 여러 영역으로 분할하는 패턴을 갖는다. 데이터 수명주기는 '원시(Raw)'에서 '농축(Enriched)', '선별(Curated)'로 전환된다. 이 단계는 프로세스 중 발생하는 데이터의 가치 변화를 나타내고, 데이터 품질 향상을 뜻한다.
원시 데이터 영역은 여러 다양한 소스에서 가져오며, 이상적 형식이 아닐 수 있다. 원시 데이터 파일의 덤프나 초기 저장소로 활용된다. 데이터가 원래 형식으로 처음 캡처되는 곳이다.
농축 데이터 영역은 중간 데이터를 포함한다. 데이터는 빠른 쿼리나 디버깅 목적으로 쉽게 쿼리될 수 있게 정리된다. 쿼리하기 쉬운 정규화된 원시 데이터로 구성되도록 데이터에 처리를 적용할 수 있다.
선별 데이터 영역은 다른 서비스에서 사용할 수 있게 준비된 정리된 데이터를 포함한다. 여기 저장된 데이터는 일반적으로 자주 쿼리할 수 있는 집계된 주요 비즈니스 메트릭을 포함할 수 있다.
팀 구성원이 정기적 데이터 수집이나 변환 프로세스 외의 일부 추가 데이터를 가져오거나, 혹은 일부 데이터를 데이터레이크에 임시 저장하려는 경우가 있다. 워크스페이스 영역을 사용해 이 같은 수요에 대응할 수 있다. 이 영역은 특정 팀에 더 큰 가치를 제공하기 위해 각 개별 팀과 데이터 소비자에서 수집한 데이터(Bring Your Own)를 포함하는 영역이다.
데이터레이크하우스는 4단계로 데이터 수명 주기 영역을 포함하는데, 데이터를 더 선별된 형식으로 진행하면서 사용준비 정도에 따라 중간에 여러 영역을 포함하는 것도 가능하다. 데이터사이언스 영역, 스테이징 영역 등이 포함될 수 있다.
■ 델타레이크
델타레이크는 데이터레이크 위에 레이크하우스 아키텍처를 구축할 수 있는 오픈소스 프로젝트다. 데이터레이크에서 지원하지 않는 ACID 트랜잭션과 확장 가능한 메타데이터 처리를 제공한다. S3, ADLS, GCS, HDFS 등 기존 데이터레이크 위에 스트리밍 및 배치 데이터 처리를 통합한다.
델타레이크의 ACID 지원은 몇가지 작업을 수행해 이뤄진다.
트랜잭션 로그에서 델타레이크 데이블 생성 사 모든 트랜잭션의 순서 기록을 추적하고, 원자적 트랜잭션을 허용하는 읽기 및 쓰기 작업 전에 이를 확인한다. 직렬화 가능한 스냅샷 격리 수준은 리더가 일관성 없는 데이터를 보지 못하도록 보장하고, 라이터가 데이터를 동시에 쓰는 동안 데이터를 계속 읽을 수 있도록 한다. 테이블의 데이터 로드 진행중에도 일관된 데이터를 읽을 수 있다는 것이다. 실패한 쓰기 작업으로 인한 데이터 손실을 방지하기 위해 '전부 아니면 전무' ACID 트랜잭션 접근 방식을 사용한다.
델타레이크의 확장 가능한 메타데이터 처리는 스파크 분산처리 능력을 활용하고, 수십억개 파일을 포함한 페타바이트 규모의 테이블의 모든 메타데이터를 쉽게 처리한다.
스트리밍과 배치 처리를 통합하므로 델타레이크의 테이블은 배치 테이블이자 스트리밍 소스 및 싱크다. 스트리밍은 실시간으로 데이터를 수집하고, 배치 로드는 기록 데이터를 처리하며, 대화형 쿼리는 데이터를 대화형으로 조회한다. 모든 작업은 즉시 사용가능하다.
스키마 적용과 진화 기능은 데이터 수집 중 잘못된 레코드 삽입을 방지하기 위해 스키마 변형을 자동으로 처리한다.
타임트래블을 사용해 모든 작업은 자동으로 버전화된다. 데이터 버전 관리를 통해 롤백, 전체 기록 감사 추적, 재현 가능한 머신러닝 실험 등이 가능하다.
업서트(Upserts) 및 삭제 시나리오의 경우 병합, 업데이트, 삭제 등의 작업을 지원해 변경데이터캡처(CDC), 느린 변경 차원(SCD), 업서트 스트리밍 등 복잡한 사용 사례를 활성화한다.
델타레이크는 아파치 스파크로 구동된다. 기존 스파크 작업, 배치 또는 스트리밍의 경우 해당 프로그램을 처음부터 다시 작성할 필요없이 쉽게 변환해 델타레이크로 활용할 수 있다.
델타레이크의 핵심은 트랜잭션 로그다. 트랜잭션 로그는 ACID 트랜잭션, 확장 가능한 메타데이터 처리, 타임트래블 등 델타레이크의 주요 기능으로 실행되는 공통 쓰레드다.
델타레이크 트랜잭션 로그는 생성 후 델타레이크 테이블에서 수행된 모든 트랜잭션의 정렬된 기록이다. 각 커밋은 JSON 파일에 저장된다. 이는 진실의 단일 소스 역할을 하며 사용자가 테이블에 수행할 수 있는 모든 변경사항을 추적하는 중앙 저장소 역할을 한다.
관련기사
- 데이터 홍수 시대, 적합한 데이터 관리 방법은?2022.12.09
- AWS "기업의 데이터 전략 구축을 위한 3요소"2022.12.01
- 클라우드의 데이터 전쟁은 어떻게 흘러갈까2023.01.03
- "실시간 흐르는 데이터, 오늘날 기업의 생명줄"2022.11.09
델타레이크 테이블을 처음 검토하는 모든 사용자의 경우 스파크가 테이블에 게시된 트랜잭션을 살피기 위해 트랜잭션 로그를 확인한다. 그런 다음 최종사용자 테이블이 이런 변경사항으로 업데이트돼 사용자 뷰 테이블 버전을 마스터 레코드와 동기화하고, 변경사항 충돌을 막는다.
체크포인트 파일은 커밋 10회마다 자동으로 생성된다. 기본 파케이 형식을 사용하는 체크포인트 파일은 해당 시점의 전체 테이블 상태를 저장한다. 체크포인트 파일을 테이블의 주어진 상태를 완전히 재생산하는 단축키로 생각하면, 스파크에서 많은 양의 비효율적 JSON 파일을 재처리하는 것을 방지할 수 있다.