에이핀아이앤씨 로고
비즈니스 문의문의 페이지로 이동
HamburgerIcon
MySQL HeatWave Lakehouse로 ETL 없이 Object Storage 데이터를 분석하는 방법
2026년 4월 14일

MySQL HeatWave Lakehouse로 ETL 없이 Object Storage 데이터를 분석하는 방법

#MySQL#HeatWave#Lakehouse#데이터레이크#ETL

MySQL HeatWave Lakehouse로 ETL 없이 Object Storage 데이터를 분석하는 방법

핵심 요약: HeatWave Lakehouse로 S3·Object Storage 데이터를 ETL 없이 SQL로 분석하는 구조를 설명해요. External Table, 하이브리드 조인, Super Chunking을 통해 운영 복잡도와 데이터 이동을 줄이는 방법을 다뤄요.

이전 글에서 MySQL HeatWave의 기본 아키텍처와 OLTP+OLAP 통합 처리 방식을 다뤘어요. 이번에는 한 발짝 더 나아가서, Object Storage에 쌓여 있는 대용량 데이터를 ETL 파이프라인 없이 직접 SQL로 분석하는 HeatWave Lakehouse 아키텍처를 살펴볼게요.

저희가 컨설팅한 고객사 중 상당수가 이런 상황이었어요. MySQL에서 OLTP를 처리하면서, 과거 데이터는 비용 절감을 위해 S3나 OCI Object Storage에 Parquet/CSV로 내려놓은 상태. 이 데이터를 분석하려면 Athena, Redshift, Snowflake 같은 별도 서비스를 붙여야 했고, 그 사이를 연결하는 ETL 파이프라인이 또 하나의 운영 부담이 됐어요.

HeatWave Lakehouse는 이 구조를 근본적으로 바꿔요. MySQL 하나로 InnoDB 테이블과 Object Storage 데이터를 동시에 쿼리할 수 있어요.

Lakehouse 아키텍처는 어떻게 동작하나요?

HeatWave Lakehouse는 Object Storage에 저장된 파일을 HeatWave 클러스터의 인메모리에 로드해서 분석하는 구조예요. 데이터를 MySQL DB로 복사하거나 변환할 필요가 없어요.

전체 흐름을 정리하면 이래요.

사용자는 기존 MySQL 클라이언트로 접속해서 표준 SQL을 실행해요. HeatWave 옵티마이저가 쿼리를 분석해서, InnoDB 테이블이든 Object Storage 데이터든 자동으로 최적 경로를 선택해요. 애플리케이션 코드를 바꿀 필요가 없다는 점이 핵심이에요.

오래된 건물을 리모델링하려다 벽 안에 배선이 얼마나 복잡한지 뒤늦게 발견하는 것처럼, 기존 분석 아키텍처도 열어보면 ETL 파이프라인, 스키마 동기화, 데이터 정합성 체크 로직이 복잡하게 얽혀 있어요. Lakehouse는 이 복잡성을 제거하는 접근이에요.

External Table로 Object Storage 데이터를 SQL로 접근하기

Lakehouse에서 Object Storage 데이터를 쿼리하려면 External Table을 정의해요. 이건 Object Storage의 파일 위치와 스키마를 MySQL에 알려주는 메타데이터 정의예요. 실제 데이터는 Object Storage에 그대로 있어요.

Parquet 파일 기반 External Table 생성

-- Object Storage의 Parquet 파일을 참조하는 External Table 정의
CREATE TABLE sensor_readings (
    sensor_id       INT,
    temperature     DECIMAL(5,2),
    humidity        DECIMAL(5,2),
    co2_level       INT,
    measured_at     DATETIME
) ENGINE=LAKEHOUSE
SECONDARY_LOAD
TABLE_FORMAT='PARQUET'
CONNECTION='oci://farm-data-bucket@namespace/sensor-data/2024/';

CSV 파일 기반 External Table 생성

CREATE TABLE historical_sales (
    order_id        INT,
    product_name    VARCHAR(255),
    quantity        INT,
    price           DECIMAL(10,2),
    order_date      DATE
) ENGINE=LAKEHOUSE
SECONDARY_LOAD
TABLE_FORMAT='CSV'
CONNECTION='oci://analytics-bucket@namespace/sales-history/';

데이터 로드 및 쿼리 실행

-- HeatWave 클러스터 메모리에 데이터 로드
ALTER TABLE sensor_readings SECONDARY_LOAD;
ALTER TABLE historical_sales SECONDARY_LOAD;

-- 이후 일반 SQL과 동일하게 쿼리 실행
SELECT
    DATE_FORMAT(measured_at, '%Y-%m-%d') AS date,
    AVG(temperature) AS avg_temp,
    MAX(humidity) AS max_humidity
FROM sensor_readings
WHERE measured_at >= '2024-06-01'
GROUP BY date
ORDER BY date;

여기서 주의할 점이 있어요. ENGINE=LAKEHOUSE와 SECONDARY_LOAD를 지정하면 HeatWave가 Object Storage에서 데이터를 읽어 인메모리에 적재해요. 한 번 로드하면 이후 쿼리는 인메모리에서 처리되기 때문에 Object Storage I/O 비용이 반복 발생하지 않아요.

하이브리드 쿼리로 InnoDB와 Lakehouse 테이블 조인하기

Lakehouse의 진짜 강점은 InnoDB 테이블(실시간 OLTP 데이터)과 Lakehouse 테이블(Object Storage 히스토리컬 데이터)을 하나의 SQL 쿼리로 조인할 수 있다는 거예요.

-- InnoDB 테이블 (실시간 고객 정보)
-- + Lakehouse 테이블 (Object Storage의 과거 분석 데이터)
-- = 단일 쿼리로 조인
SELECT
    c.customer_name,
    c.tier,
    ca.segment,
    ca.lifetime_value
FROM customers c                    -- InnoDB (실시간)
JOIN customer_analytics ca          -- Lakehouse (Object Storage)
    ON c.customer_id = ca.customer_id
WHERE ca.lifetime_value > 10000
ORDER BY ca.lifetime_value DESC;

기존에는 이런 쿼리를 실행하려면 Object Storage 데이터를 별도 분석 DB에 로드하고, MySQL의 고객 정보도 ETL로 복사한 뒤, 분석 DB에서 조인해야 했어요. Lakehouse에서는 MySQL 하나에서 끝나요.

Super Chunking으로 대용량 데이터를 빠르게 처리하는 원리

Object Storage에 수백 GB, 수 TB 규모의 파일이 있을 때 어떻게 빠르게 처리할 수 있을까요? HeatWave Lakehouse는 Super Chunking이라는 데이터 분산 기술을 사용해요.

동작 방식은 이래요.

  1. Object Storage의 대용량 파일을 논리적 "Super Chunk" 단위로 분할
  2. 각 청크를 HeatWave 클러스터의 서로 다른 노드에 할당
  3. 쿼리 실행 시 모든 노드가 동시에 자신의 청크를 병렬 처리
  4. 결과를 병합해서 반환

놀이공원에서 하나의 긴 줄 대신 여러 개의 짧은 줄로 나눠서 동시에 입장시키는 것과 비슷해요. 노드가 64개면 64개의 줄이 동시에 처리되는 거예요.

항목설명
분할 단위파일을 논리적 청크로 자동 분할
분산 방식클러스터 노드에 균등 배분
처리 방식각 노드가 자신의 청크를 독립 병렬 처리
확장성노드 수에 비례하여 선형 성능 향상
메모리 효율각 노드가 전체 데이터의 일부만 보유

실제로 저희가 PoC를 진행한 고객사에서 1.08TB Parquet 데이터(비압축 시 4.7TB, 148억 행)를 64노드 클러스터에 로드했을 때, 노드당 약 73GB씩 분산되어 전체 로드가 25분 만에 완료됐어요.

Incremental Load로 변경분만 감지해서 로드하기

Object Storage에 매일 새로운 파일이 추가되는 환경에서 매번 전체 데이터를 다시 로드하면 비효율적이에요. Incremental Load는 변경된 파일만 감지해서 추가 로드하는 기능이에요.

동작 원리는 이래요.

HeatWave가 Object Storage의 파일 목록과 메타데이터(수정 시간, 파일 크기)를 추적해요. ALTER TABLE ... SECONDARY_LOAD를 다시 실행하면, 이전 로드 이후 추가되거나 변경된 파일만 감지해서 해당 부분만 로드해요.

-- 최초 로드 (전체 데이터)
ALTER TABLE sensor_readings SECONDARY_LOAD;

-- 다음 날: 새 파일이 Object Storage에 추가된 후
-- 변경분만 자동 감지하여 증분 로드
ALTER TABLE sensor_readings SECONDARY_LOAD;
-- → 새로 추가된 파일만 로드 (기존 데이터는 유지)

전체 재로드 대비 시간과 리소스를 절약할 수 있어요. 수 TB 규모 데이터셋에서 매일 수 GB만 추가되는 패턴이라면, Incremental Load로 로드 시간을 수십 분에서 수 분으로 줄일 수 있어요.

지원 파일 포맷과 Object Storage

HeatWave Lakehouse가 지원하는 파일 포맷과 Object Storage를 정리했어요.

파일 포맷특징적합한 용도
Parquet컬럼 기반, 압축 효율 높음대규모 분석 쿼리, 집계 연산
CSV범용, 호환성 높음레거시 데이터, 간단한 데이터셋
Avro스키마 내장, 행 기반스트리밍 데이터, 스키마 진화 필요 시
JSON반정형 데이터로그 데이터, API 응답 저장
MySQL Exportmysqldump 호환MySQL 백업 데이터 직접 분석

Object Storage는 OCI Object Storage, AWS S3, Azure Blob Storage를 모두 지원해요. 기존 클라우드 환경을 바꾸지 않고 현재 사용 중인 Object Storage에서 바로 분석을 시작할 수 있어요.

Parquet 포맷을 사용하면 Auto Schema Inference도 활용할 수 있어요. 파일에 내장된 스키마 정보를 HeatWave가 자동으로 읽어서 테이블 컬럼을 추론해줘요.

-- Parquet 파일에서 자동 스키마 추론 (dry-run으로 확인)
CALL sys.heatwave_load(
    JSON_ARRAY('analytics_db'),
    JSON_OBJECT('mode', 'dryrun')
);

농업 데이터 분석 스타트업의 Lakehouse 도입 사례

저희가 컨설팅한 농업 데이터 분석 스타트업의 사례를 공유할게요. 이 고객사는 IoT 센서 기반 스마트팜 플랫폼을 운영하면서, 수억 건의 시계열 센서 데이터(온도, 습도, CO2, 조도, 토양 수분)를 분석해야 했어요.

도입 전 상황

기존에는 MySQL에서 OLTP를 처리하고, 과거 센서 데이터는 Object Storage에 CSV/Parquet로 보관했어요. 이 데이터를 분석하려면 별도 분석 DB에 ETL로 복사해야 했고, 파이프라인 지연으로 실시간 분석이 어려웠어요.

항목도입 전Lakehouse 도입 후
분석 쿼리 성능수십 분 – 수 시간수 초 – 수십 초
아키텍처MySQL + ETL + 별도 분석 DBMySQL + HeatWave Lakehouse
데이터 이동ETL로 분석 DB에 복사 필요Object Storage 직접 쿼리
데이터 신선도ETL 지연으로 실시간성 부족최신 데이터 즉시 분석 가능
운영 비용분석 인프라 별도 운영MySQL 하나로 통합

실제 SQL 활용 예시

-- Object Storage의 센서 데이터를 Lakehouse 테이블로 정의
CREATE TABLE sensor_history (
    sensor_id       INT,
    farm_id         INT,
    temperature     DECIMAL(5,2),
    humidity        DECIMAL(5,2),
    co2_level       INT,
    soil_moisture   DECIMAL(5,2),
    measured_at     DATETIME
) ENGINE=LAKEHOUSE
SECONDARY_LOAD
TABLE_FORMAT='PARQUET'
CONNECTION='oci://smartfarm-bucket@namespace/sensor-archive/';

-- 데이터 로드
ALTER TABLE sensor_history SECONDARY_LOAD;

-- InnoDB의 실시간 센서 데이터 + Object Storage의 과거 데이터 통합 분석
SELECT
    f.farm_name,
    DATE_FORMAT(sh.measured_at, '%Y-%m') AS month,
    AVG(sh.temperature) AS avg_temp,
    AVG(sh.humidity) AS avg_humidity,
    COUNT(*) AS reading_count
FROM sensor_history sh              -- Lakehouse (Object Storage)
JOIN farms f ON sh.farm_id = f.id   -- InnoDB (실시간)
WHERE sh.measured_at >= '2024-01-01'
GROUP BY f.farm_name, month
ORDER BY f.farm_name, month;

도입 효과

CSV 10GB(800개 파일) 로딩이 85분에서 3.2분으로 줄었어요(27배). OLAP 쿼리는 142분에서 4.7분으로(30배), ML 학습은 320분에서 18분으로(18배) 개선됐어요.

처음에는 별도 분석 DB를 유지하면서 병행 운영할 계획이었어요. 하지만 Lakehouse 도입 후 ETL 파이프라인 자체가 불필요해지면서, 분석 인프라를 완전히 제거할 수 있었어요. 엔지니어링 리소스도 파이프라인 유지보수에서 해방됐어요.

대규모 데이터에서의 성능 벤치마크 실측 결과

저희가 진행한 PoC에서 148억 행(1.08TB Parquet, 비압축 4.7TB) 규모의 데이터를 64노드 HeatWave 클러스터에 로드하고 분석 쿼리를 실행한 결과예요.

데이터 로드 성능

항목수치
데이터 규모1.08TB (Parquet 압축), 4.7TB (비압축)
총 행 수148억 행 (4개 테이블)
클러스터 구성64노드 (HeatWave.512GB)
전체 로드 시간약 25분
노드당 데이터약 73GB

쿼리 실행 성능

쿼리 유형데이터 규모실행 시간
단순 포인트 조회23억 행 테이블1초 미만
집계 쿼리 (GROUP BY)23억 행3.2초
4테이블 복합 조인148억 행5.8초
전체 스캔 집계 (AVG, MAX, MIN)2.3억 행1.5초

148억 행에 대한 복합 분석 쿼리가 수 초 내에 완료된다는 건, 기존 Athena나 Redshift에서 동일 쿼리를 실행했을 때와 비교하면 상당한 차이예요.

Lakehouse는 언제 경제적인가요?

Lakehouse 도입이 항상 비용 절감을 의미하지는 않아요. 워크로드 패턴에 따라 경제성이 달라져요.

HeatWave Lakehouse 비용 구조

구성 요소시간당 비용비고
MySQL DB System$2.79/hr메타데이터 관리, SQL 인터페이스
HeatWave 노드 (1개)$0.65/hr인메모리 분석 처리
64노드 클러스터$41.60/hr대규모 데이터 분석용

비용 최적화 포인트

Auto Start/Stop 기능이 핵심이에요. 분석 쿼리를 실행하지 않는 시간에는 HeatWave 클러스터를 자동으로 중지할 수 있어요. 하루 8시간만 사용하면 24/7 운영 대비 비용이 1/3로 줄어요.

운영 패턴월간 비용 (64노드 기준)
24/7 상시 운영약 $31,960/월
8시간/일 운영 (Auto Start/Stop)약 $10,650/월

언제 Lakehouse가 경제적인가

Lakehouse가 유리한 경우는 이래요. 반복적으로 동일 데이터셋에 분석 쿼리를 실행하는 패턴, Object Storage에 이미 데이터가 있어서 별도 스토리지 비용이 불필요한 경우, ETL 파이프라인 구축/운영 비용을 제거할 수 있는 경우예요.

반면 Athena처럼 쿼리당 과금 모델이 유리한 경우도 있어요. 분석 빈도가 매우 낮고(월 수 회), 데이터 규모가 작다면 Athena가 더 경제적일 수 있어요. 대량 반복 쿼리 환경에서는 Athena 비용이 급증하기 때문에 Lakehouse가 유리해요.

도입 시 고려사항

실무에서 Lakehouse를 도입할 때 반드시 검토해야 할 항목들이에요.

메모리 요구량을 먼저 확인해야 해요. Lakehouse도 인메모리 처리 방식이라, Object Storage 데이터를 HeatWave 노드 메모리에 로드해야 해요. 데이터 규모에 비례하는 노드 수가 필요해요. Autopilot의 Auto Provisioning으로 사전에 필요한 노드 수를 예측할 수 있어요.

파일 포맷 선택도 중요해요. Parquet이 압축률과 쿼리 성능 면에서 가장 유리해요. CSV는 호환성은 좋지만 압축 효율이 낮고 스키마 추론이 안 돼요. 기존 데이터가 CSV라면 Parquet으로 변환하는 일회성 작업을 고려해볼 만해요.

Object Storage 파일 구조도 성능에 영향을 줘요. 날짜별 파티셔닝(/year=2024/month=06/)으로 파일을 정리하면, 특정 기간 쿼리 시 불필요한 파일 스캔을 줄일 수 있어요.

보안 설정도 빠뜨리면 안 돼요. Object Storage 접근을 위해 Resource Principal 또는 PAR(Pre-Authenticated Request) 설정이 필요해요. OCI의 경우 IAM 정책으로 세밀한 접근 제어가 가능하고, 통신은 TLS로 암호화돼요.

핵심 요약

  • HeatWave Lakehouse는 Object Storage(OCI, AWS S3, Azure Blob)의 데이터를 ETL 없이 MySQL SQL로 직접 분석하는 아키텍처예요.
  • External Table을 정의하면 Object Storage 파일을 HeatWave 인메모리에 로드해서 수 초 내에 쿼리할 수 있어요. InnoDB 테이블과의 조인도 단일 쿼리로 가능해요.
  • Super Chunking으로 대용량 데이터를 클러스터 노드에 분산 병렬 처리하고, Incremental Load로 변경분만 효율적으로 갱신해요.
  • 실측 결과, 148억 행(1.08TB) 데이터 로드에 25분, 복합 조인 쿼리가 5.8초 내에 완료됐어요.
  • Auto Start/Stop으로 비용을 최적화할 수 있지만, 워크로드 패턴에 따라 Athena 등 쿼리당 과금 모델이 더 경제적인 경우도 있어요.

FAQ

Q. HeatWave Lakehouse를 사용하려면 데이터를 OCI Object Storage로 옮겨야 하나요?

아니요. AWS S3, Azure Blob Storage도 지원해요. 기존 클라우드 환경의 Object Storage를 그대로 사용할 수 있어요. HeatWave on AWS를 사용하면 S3 데이터를 이동 없이 바로 분석할 수 있어요.

Q. Lakehouse 테이블과 InnoDB 테이블을 조인할 때 성능 저하가 있나요?

HeatWave 옵티마이저가 두 테이블 모두 인메모리에서 처리하기 때문에, 조인 성능은 일반 HeatWave 쿼리와 동일한 수준이에요. 다만 Lakehouse 테이블이 아직 로드되지 않은 상태에서 쿼리하면 로드 시간이 추가돼요. 사전에 SECONDARY_LOAD로 로드해두는 게 좋아요.

Q. Object Storage에 새 파일이 추가되면 자동으로 반영되나요?

자동 반영은 아니에요. ALTER TABLE ... SECONDARY_LOAD를 다시 실행해야 해요. 다만 Incremental Load가 동작해서 변경분만 로드하기 때문에 전체 재로드보다 훨씬 빨라요. 스케줄러로 주기적 로드를 설정하는 패턴이 일반적이에요.

Q. Parquet과 CSV 중 어떤 포맷을 사용해야 하나요?

분석 워크로드라면 Parquet을 권장해요. 컬럼 기반 압축으로 저장 공간이 줄고, 특정 컬럼만 읽는 쿼리에서 I/O가 크게 감소해요. Auto Schema Inference도 Parquet에서만 지원돼요. CSV는 기존 레거시 데이터를 빠르게 연동할 때 유용하지만, 장기적으로는 Parquet 변환을 고려해보세요.

Q. HeatWave Lakehouse와 Amazon Athena의 차이점은 무엇인가요?

Athena는 쿼리당 과금(스캔한 데이터 양 기준)이고, Lakehouse는 클러스터 시간당 과금이에요. 분석 빈도가 높고 반복 쿼리가 많으면 Lakehouse가 경제적이에요. 성능 면에서도 Lakehouse는 인메모리 처리라 동일 쿼리를 반복 실행할 때 훨씬 빨라요. 또한 Lakehouse는 InnoDB 테이블과의 조인이 가능하지만, Athena는 MySQL 데이터와 직접 조인할 수 없어요.

운영하면서 계속 느낀 건, Lakehouse의 가장 큰 가치는 "분석을 위한 별도 시스템"이라는 개념 자체를 없앤다는 거예요. MySQL 하나로 OLTP, OLAP, Object Storage 분석을 모두 처리하면서 ETL 파이프라인이 사라지고, 데이터 정합성 문제도 함께 사라졌어요.

다음 글에서는 HeatWave 운영 모니터링 구성 방법을 다룰게요. Lakehouse 도입이나 기존 분석 아키텍처 통합에 대해 구체적인 검토가 필요하다면, 저희 팀에 문의해주세요.

Object Storage 데이터 분석, ETL 없이 시작할 수 있습니다.

에이핀의 OCI 전문가가 HeatWave Lakehouse 도입과 기존 분석 아키텍처 통합을 도와드립니다.

Lakehouse 도입 문의
에이핀주식회사 에이핀아이앤씨
대표이사
한우영
사업자등록번호
569-88-03028
전화번호
02-6956-4202
팩스
02-6956-4208
주소
서울특별시 용산구 효창원로16길 11 (신창동)