데이터 웨어하우스는 ‘하우스’를 필요로 하지 않는다 — 그래서 더 빠른 이유

Source: Dev.to

번역할 텍스트를 제공해 주시면, 요청하신 대로 한국어로 번역해 드리겠습니다.

개요

우리는 초기 데이터베이스가 TP(트랜잭션 처리)와 AP(분석 처리)를 구분하지 않으며 모든 작업을 단일 데이터베이스에서 처리한다는 것을 알고 있습니다.

TP 비즈니스를 다룰 때는 데이터 일관성을 보장하는 것이 중요합니다. 일관성은 데이터가 특정 범위에 제한될 때만 의미가 있으며, 이는 “베이스(base)” 개념을 낳습니다.

• 데이터베이스에 로드되는 데이터는 일정한 제약 조건을 만족해야 하며, 그렇지 않으면 로드될 수 없습니다.
• 데이터베이스 내부와 외부를 명확히 구분합니다—이 특성을 **폐쇄성(closedness)**이라고 합니다.

일관성을 보장하는 것 외에도, 폐쇄성은 데이터베이스 관리 시스템(DBMS) 사용 시 데이터 보안을 보장할 수 있습니다.

데이터베이스에서 데이터 웨어하우스로

데이터 웨어하우스는 데이터베이스를 기반으로 개발됩니다. 단일 데이터베이스가 OLTP와 OLAP 워크로드를 동시에 처리할 수 없게 되면, AP 워크로드를 별도의 데이터베이스로 분리하여 data warehouse가 탄생합니다.

따라서 데이터 웨어하우스는 closedness를 포함한 데이터베이스의 많은 특성을 물려받습니다. 폐쇄성을 물려받는다는 것은 다음과 같은 규칙을 따르는 것을 의미합니다:

• “데이터는 데이터베이스에 로드된 후에만 사용할 수 있습니다.”
• “로드되는 데이터는 특정 기준을 충족해야 합니다.”

그 결과, 데이터 웨어하우스의 “house” 개념이 자연스럽게 형성됩니다.

폐쇄형 스토리지는 필요할까?

• TP 비즈니스 – 예, 폐쇄형 스토리지는 필요합니다.
• 데이터‑웨어하우스 (AP) 비즈니스 – 반드시 그렇지는 않습니다.

용어 data warehouse에 “house”(집)라는 단어가 들어 있지만, 그 주요 기능은 연산입니다. 창고가 “집”처럼 데이터를 저장할 수 있더라도, 그 가치가 그 데이터를 계산하는 데서 비롯됩니다.

현대 데이터 웨어하우스 간의 경쟁은 거의 전적으로 다음 두 가지에 초점을 맞춥니다:

1. 연산 능력 (성능, 기능 완전성, 풍부한 특징).
2. 스토리지 – 연산을 지원하기 위한 수단일 뿐.

따라서 데이터 웨어하우스의 핵심 포인트는 스토리지가 아니라 연산입니다.

Source: …

스토리지를 바인딩하지 않고 강력한 컴퓨팅 엔진을 제공할 수 있을까?

대부분의 SQL‑based (relational‑algebra) data warehouses에 대해 답은 아니오입니다. 스토리지와 컴퓨팅의 결합은 이러한 웨어하우스가 데이터베이스에서 파생된 특성으로, 이를 변경할 수 없습니다.

하지만 새로운 유형의 “no‑house” 데이터 웨어하우스가 esProc SPL 형태로 존재합니다!

esProc이란?

• AP 처리에 특화된 오픈 컴퓨팅 엔진입니다.
• 다양한 데이터 소스에 연결하여 혼합 계산을 수행합니다.
• 컴퓨팅 성능을 보장하기 위해 자체 고성능 파일 스토리지를 제공합니다.
• 전통적인 SQL 대신 **SPL (Structured Process Language)**을 사용하여 기존 SQL보다 여러 장점을 제공합니다.

이 글에서 말하는 **“no house”**는 전통적인 데이터 웨어하우스와 같이 폐쇄된 사설 스토리지가 없다는 의미입니다.

Source:

데이터는 어디에 저장되나요?

아래에서 이 질문과 관련된 질문에 답하고 “노하우스(no‑house)” 접근 방식의 장점(즉, 극복되는 문제들)을 살펴봅니다.

다양한 데이터 소스의 실시간 연산

데이터가 생성되면 어느 곳에선가—데이터베이스, 파일, 웹—저장됩니다. 넓은 의미에서 데이터는 이미 저장된 것입니다. 데이터가 위치한 곳에서 직접 데이터를 처리할 수 있다면 얼마나 편리할까요?

오늘날 기업은 다양한 데이터 소스와 유형에 직면해 있습니다. 이를 직접 처리할 수 있다면 큰 편리함을 제공합니다.

esProc의 기능

• 오픈 포맷, 다중 소스 처리 – 데이터가 어디에 있든(RDBMS, NoSQL, 파일, Hadoop, RESTful API 등) esProc은 직접 읽고 계산할 수 있습니다.
• 혼합 연산 – esProc은 서로 다른 소스에 연결하고, 그 사이를 아우르는 계산을 수행할 수 있습니다.

다양한 데이터 소스(혼합 계산)를 지원하는 능력이 제공되면, “하우스”의 제한이 깨지고 여러 장점이 생깁니다:

1. ETL 오버헤드 제거 – 계산 전에 데이터를 데이터베이스에 로드할 필요가 없습니다.
2. 실시간 계산 – 여러 소스에 걸쳐 최신 결과를 보장합니다.
3. 스토리지 비용 및 DB 부하 감소 – 데이터베이스가 무차별적인 데이터 로드에 부담을 갖지 않으며, 특히 데이터 웨어하우스와 esProc이 공존하는 초기 도입 단계에서 가치가 큽니다.

각 소스의 강점 활용

이러한 이점은 개방성에서 비롯됩니다. 반면 폐쇄형 데이터 웨어하우스는 자체 저장소 외부의 데이터를 계산할 수 없습니다. 데이터를 먼저 **수입(ETL)**해야 하는데, 이는:

• 프로그래머의 작업량 증가
• 데이터베이스 부하 증가

와 같은 문제를 초래합니다.

요약

• 전통적인 데이터베이스는 일관성과 보안을 보장하기 위해 폐쇄성을 강제합니다.
• 데이터 웨어하우스도 이 폐쇄성을 물려받지만, AP 워크로드에서는 주요 가치가 저장이 아니라 연산에 있습니다.
• “노하우스” 아키텍처—esProc SPL이 대표적으로 보여주듯—는 연산을 저장소와 분리하여 ETL 비용 없이 실시간, 다중 소스 처리를 가능하게 합니다.

개방성을 수용함으로써 조직은 비용을 절감하고 개발 속도를 가속화하며 각 데이터 소스의 강점을 최대한 활용할 수 있습니다.

실시간 데이터 과제

데이터의 실시간 특성이 종종 사라집니다. 외부 데이터는 보통 불규칙한 형식으로 제공되어, 엄격한 제약이 있는 데이터베이스에 직접 적재하기 어렵습니다. ETL 프로세스를 사용하더라도 원시 데이터를 데이터베이스에 먼저 적재해야 그 연산 능력을 활용할 수 있습니다. 결과적으로 ETL은 종종 ELT로 전환되어 데이터베이스에 추가 부담을 줍니다.

데이터가 어디에 있든 연산을 수행할 수 있습니다—이는 esProc이 제공하는 “노하우스” 접근 방식의 주요 장점 중 하나입니다.

Source:

고성능

esProc이 다양한 데이터 소스에서 읽을 때 논리적 상태는 동일할 수 있지만, 각 소스 인터페이스의 효율성 차이로 인해 읽기 성능(따라서 전체 계산 시간)이 달라질 수 있습니다. 일부 인터페이스(예: JDBC를 통한 RDBMS)의 경우 읽기 성능이 매우 낮습니다.

많은 데이터 소스에 직접 접근할 수 있는 것은 편리하지만, 계산 성능이 저하될 수 있습니다. 높은 성능을 보장하기 위해 esProc은 특수 바이너리 파일 저장 형식과 여러 최적화 메커니즘을 제공합니다:

• 압축
• 컬럼형 저장
• 정렬
• 병렬 세분화

Note: esProc의 파일 저장은 열려 있습니다—파일은 텍스트 파일, Excel 시트 등과 동일한 일반 파일 시스템에 존재합니다. esProc은 이 파일들을 소유하지 않으며, 파일 접근을 보다 효율적으로 만들기 위한 최적화 전략만 제공합니다.

반면 전통적인 데이터‑웨어하우스 저장(“하우스”)은 폐쇄적이고 사유입니다. 성능은 기반 엔진의 옵티마이저에 의존합니다. 좋은 데이터베이스는 단순 SQL에 대해 효율적인 실행 계획을 선택할 수 있지만, SQL이 다소 복잡해지면 옵티마이저가 실패하고 문자 그대로의 실행 경로로 돌아가 급격한 성능 저하가 발생합니다. 저장이 폐쇄되어 있기 때문에(예: 기본 키로 데이터 정렬) 성능을 개선하기 위해 개입할 수 없습니다.

esProc의 열린 파일 저장은 매우 유연합니다: 어떤 알고리즘을 기반으로 저장 레이아웃을 설계하고, 데이터에 맞게 조정함으로써 뛰어난 성능을 달성할 수 있습니다.

보안 및 신뢰성

오픈 컴퓨팅 및 파일‑기반 스토리지는 자연스러운 질문을 제기합니다: 전통적인 데이터 웨어하우스는 폐쇄형 구조를 통해 보안과 신뢰성을 보장합니다—스토리지를 바인딩하지 않는 esProc은 어떻게 동일한 보장을 할 수 있을까요?

답은 간단합니다: esProc은 데이터 보안을 관리하지 않으며, 기본 데이터 소스의 보안 메커니즘에 의존합니다.

• 데이터베이스는 인증, 권한 부여, 감사 등을 제공합니다.
• 파일 시스템 / 가상 머신은 접근 제어, 신원 확인 및 전송 암호화를 제공합니다.
• 객체 스토리지 서비스(예: Amazon S3)를 사용해 계산 전에 데이터를 가져올 수 있으며, 내장된 보안 기능을 활용합니다. 클라우드 스토리지는 종종 많은 온‑프레미스 데이터베이스보다 더 강력한 보안 및 신뢰성을 제공합니다.

애플리케이션 접근을 위해 독립적인 esProc 서비스는 표준 TCP/IP 및 HTTP를 통해 통신합니다. 네트워크 보안 제품은 이 트래픽을 모니터링하고 보호할 수 있으며, 해당 보안 조치에 대한 책임은 제품 자체에 있습니다.

“노‑하우스”(비내부) 방식이 더 안전할 수 있는 이유

전통적인 “내부” 데이터베이스는 종종 편의성을 위해 모든 애플리케이션 사용자에게 높은 권한을 부여하는 거친 권한 관리 방식을 가지고 있습니다. 여기에는 저장 프로시저 컴파일과 같은 위험한 권한도 포함되어 전체 보안을 약화시킵니다.

esProc은 오직 계산에만 집중합니다:

• 다른 시스템이 안전하게 저장한 데이터 위에서 동작합니다.
• 스토리지 계층을 변경하거나 방해하지 않습니다.

신뢰성도 보안과 마찬가지로 투자 비례합니다. 비싼 “두 사이트, 세 센터” 아키텍처를 갖추어도 전문 스토리지 기술(예: 클라우드 객체 스토리지)이 이미 제공하는 수준에 미치지 못할 수 있습니다.

HTAP 요구사항 구현

최근 몇 년간 HTAP은 데이터베이스 분야의 또 다른 핫스팟이 되었습니다. 대부분의 데이터베이스는 TP 데이터베이스에 특정 AP 기능을 붙이거나 두 기술을 결합함으로써 HTAP을 구현합니다. 어떤 방식을 쓰든 데이터베이스 마이그레이션은 불가피하며, 이는 원래 데이터 웨어하우스의 폐쇄성 및 성능 문제를 초래합니다.

HTAP 요구사항은 본질적으로 데이터베이스를 분리한 뒤 실시간으로 데이터를 조회하는 것입니다. 이 능력이 있다면 원래 TP 데이터베이스를 수정하지 않고(마이그레이션 위험 없이) 요구사항을 구현할 수 있습니다.

우리는 기존의 독립적인 TP와 AP 시스템을 기반으로 esProc을 도입하고, esProc의 다음 기능을 활용하여 이 요구사항을 구현할 수 있습니다.

• 오픈형 크로스‑소스 컴퓨팅 능력
• 고성능 저장 및 컴퓨팅 능력
• 민첩한 개발 능력

esProc은 기존 시스템과 협업하는 방식으로 HTAP을 구현합니다. 기존 아키텍처에 약간의 수정만 하면 되며, TP 데이터베이스를 거의 수정할 필요가 없습니다. 기존 AP 데이터 소스도 그대로 사용할 수 있어, esProc이 점진적으로 AP 비즈니스를 인수하도록 할 수 있습니다.

• 부분적으로 혹은 완전히 인수하게 되면, 과거 콜드 데이터는 esProc의 고성능 파일에 저장됩니다.
• 비즈니스 데이터베이스에서 데이터 웨어하우스로 데이터를 이동하던 기존 ETL 프로세스는 esProc으로 직접 마이그레이션할 수 있습니다.

콜드 데이터가 양이 많고 더 이상 변경되지 않을 때, 이를 esProc의 고성능 파일로 저장하면 컴퓨팅 성능이 크게 향상됩니다. 핫 데이터 양이 적을 경우, 원래 TP 데이터 소스에 그대로 두면 esProc이 직접 읽고 계산할 수 있습니다. 핫 데이터 양이 제한적이기 때문에 TP 소스에 대한 직접 조회는 영향이 최소이며 허용 가능한 지연 시간을 가집니다.

esProc의 혼합형 핫‑콜드 데이터 컴퓨팅 능력을 활용함으로써 전체 데이터셋에 대한 실시간 조회를 달성합니다. 운영 측면에서 수행해야 할 작업은 주기적으로 다음 두 가지뿐입니다.

1. 콜드 데이터를 esProc의 고성능 파일로 저장한다.
2. 새로 생성된 핫 데이터를 원래 데이터 소스에 유지한다.

이렇게 하면 HTAP이 구현될 뿐만 아니라 높은 성능을 유지하면서 애플리케이션 프레임워크에 미치는 영향도 최소화됩니다.

True Lakehouse 구현

폐쇄형 데이터 웨어하우스는 진정한 Lakehouse를 구축할 수 없습니다. 데이터 레이크는 종종 쓰레기장처럼 취급됩니다: 미래에 어떤 데이터가 유용할지 예측할 수 없기 때문에 모든 유형의 원시 데이터를 저장합니다. 데이터의 가치는 계산을 통해 실현되며, 이는 데이터 웨어하우스의 컴퓨팅 능력을 필요로 합니다. 그러나 전통적인 데이터 웨어하우스는 폐쇄형이며, 데이터를 로드하기 전에 깊이 조직해야 하고, 레이크에 있는 원시 “쓰레기 데이터”는 직접 계산할 수 없습니다. 데이터를 조직하면 원본 정보가 손실되고 앞서 언급한 다양한 소스 문제를 초래합니다. 그 결과 실시간 접근이 보장되지 않고, ETL 비용이 높아져 시의성이 떨어집니다.

전통적인 데이터 웨어하우스 위에 구축된 가짜 Lakehouse와 비교할 때, esProc은 진정한 Lakehouse를 구현할 수 있습니다. 그 이유는 다음과 같습니다:

• 조직되지 않은 데이터를 직접 계산할 수 있는 충분한 개방성.
• 높은 성능 메커니즘을 유지하면서 다양한 데이터 소스에 걸친 혼합 연산 능력.

주요 장점

• 원시 레이크 데이터 직접 계산 – 제약이 없으며, 데이터를 데이터베이스에 로드할 필요가 없습니다.
• 다양한 소스에 대한 혼합 연산 – 레이크가 통합 파일 시스템 위에 구축되었든, 이기종 소스(RDB, NoSQL, 로컬 파일, 웹 서비스) 위에 구축되었든, esProc은 즉시 그들을 가로질러 계산할 수 있습니다.
• 고성능 파일 스토리지 – esProc의 스토리지(데이터 웨어하우스 기능)는 계산하면서 데이터를 질서 있게 조직할 수 있습니다. 원시 데이터를 esProc 스토리지로 변환하면 성능이 향상됩니다. 데이터는 파일 시스템에 남아 레이크와 함께 저장될 수 있어 진정한 Lakehouse 아키텍처를 구현합니다.

esProc의 컴퓨팅 능력을 활용하면 조직과 계산을 동시에 수행할 수 있어, 데이터 레이크를 단계적으로 그리고 질서 있게 구축할 수 있습니다. 레이크가 구축되는 동안 데이터 웨어하우스가 정제되어 레이크에 강력한 컴퓨팅 능력을 부여하고, 이를 통해 진정한 Lakehouse가 실현됩니다.

폐쇄에서 개방으로, 이것이 지속적인 진보의 구현입니다.

esProc와 “No‑House” 데이터 웨어하우스

기술의 진보는 모든 산업을 앞으로 나아가게 합니다. 데이터 웨어하우스도 마찬가지로, “with‑house”(전통적인 온‑프레미스) 모델에서 “no‑house”(클라우드‑네이티브, 서버리스) 모델로 진화하는 것은 현대 데이터 웨어하우징에 있어 불가피한 단계입니다. 따라서 데이터 웨어하우스는 곧 “no‑house” 시대에 진입하게 됩니다.

esProc가 완벽하지는 않지만, “no‑house” 데이터 웨어하우스의 역량을 구현하는 데 큰 한 걸음이며, 충분히 시도해 볼 가치가 있습니다.

오픈‑소스 제공

SPL은 이제 오픈‑소스입니다. 공식 저장소에서 소스 코드를 받을 수 있습니다:

GitHub – SPLWare/esProc

무료로 사용해 보기

최신 버전을 다운로드하고 직접 실험해 보세요:

Download esProc (free)