Data Lake

데이터 레이크는 데이터베이스 내보내기 파일과 JSON 로그부터 이미지, 동영상, 오디오, 문서까지 데이터를 원시 상태의 형식 그대로 저장하는 중앙 저장소입니다. 일반적으로 저비용 클라우드 객체 스토리지를 사용하며, 데이터는 읽을 때만 구조가 적용됩니다. 당시 Pentaho의 최고기술책임자였던 James Dixon은 2010년에 이 용어를 만들었습니다. 그는 데이터 마트를 정제해 포장한 생수에 비유하고, 많은 사용자가 활용할 수 있는 자연 상태의 방대한 데이터와 대비했습니다. 사전에 모델링할 필요가 없으므로 레이크에는 조직이 수집하는 모든 데이터를 보관할 수 있어 머신러닝에 적합합니다. 내일의 모델을 위한 학습 데이터는 저장 당시에는 누구도 용도를 알지 못했던 원시 데이터인 경우가 많습니다.

데이터 레이크의 작동 방식#

레이크는 스토리지와 컴퓨팅을 분리합니다. 파일은 Amazon S3, Google Cloud Storage, Azure Data Lake Storage와 같은 객체 스토리지에 저장되고, Spark, Trino, Python 프로세스와 같은 엔진이 파일을 직접 읽으므로 각 팀은 데이터를 복사하지 않고 자체 컴퓨팅 리소스를 확장할 수 있습니다. 표 형식 데이터는 보통 Apache Parquet와 같은 개방형 컬럼 형식으로 저장하고, 이미지와 동영상은 일반 파일로 유지합니다. 이러한 파일 옆에는 메타데이터와 레이블을 담은 JSON 또는 Parquet 매니페스트를 두는 경우가 많습니다.

대부분의 레이크는 정제 수준에 따라 영역별로 구성되며, Databricks는 이를 메달리온 아키텍처라고 부릅니다. 원시(브론즈) 영역에는 수신된 그대로의 데이터가 저장되고, 정제된(실버) 영역에는 검증 및 중복 제거를 거친 데이터가 저장되며, 큐레이션된(골드) 영역에는 보고나 학습에 바로 사용할 수 있는 테이블과 데이터셋이 저장됩니다. AWS Glue Data Catalog, Hive Metastore, Unity Catalog와 같은 메타데이터 카탈로그는 각 데이터셋의 내용, 소유자, 읽기 권한이 있는 사용자를 기록합니다. 카탈로그와 데이터 정제 기능이 없는 레이크는 파일을 찾거나 신뢰하거나 안전하게 삭제할 수 없는 '데이터 늪'으로 전락합니다.

읽기 시 스키마 적용#

레이크는 데이터를 읽을 때 스키마를 적용하며, 이를 읽기 시 스키마 적용이라고 합니다. 작성자는 데이터가 생성되는 즉시 저장할 수 있으며, 두 데이터 소스의 필드가 서로 달라도 문제가 없습니다. 각 독자는 필요한 열과 자료형을 결정합니다. 다음 예제는 필드가 서로 다른 원시 JSON 파일 두 개를 작성한 후, 하나의 스키마로 모두 읽습니다. 이때 Polars를 사용합니다.

import json
from pathlib import Path

import polars as pl

# 원시 영역: 카메라 두 대가 각기 다른 필드가 포함된 탐지 이벤트를 JSON Lines 형식으로 기록합니다
Path("lake/raw").mkdir(parents=True, exist_ok=True)
Path("lake/raw/dock-1.jsonl").write_text(json.dumps({"label": "forklift", "conf": 0.91}))
Path("lake/raw/dock-2.jsonl").write_text(json.dumps({"label": "person", "conf": 0.62, "lux": 120}))

# 읽기 시 스키마 적용: 이 독자는 파일을 쿼리할 때 열과 자료형을 선택합니다
schema = {"label": pl.String, "conf": pl.Float32, "lux": pl.Int32}
events = pl.scan_ndjson("lake/raw/*.jsonl", schema=schema, include_file_paths="source")
print(events.collect())

결과에는 label, conf, lux, source 열이 있는 행 두 개가 포함됩니다. 첫 번째 카메라는 lux를 기록하지 않았으므로 해당 값은 null로 반환되고, source에는 각 행이 어느 원시 파일에서 왔는지 기록됩니다. 두 번째 작업에서는 같은 파일을 다시 작성하지 않고도 다른 스키마로 읽을 수 있습니다.

데이터 레이크, 데이터 웨어하우스, 레이크하우스 비교#

• 데이터 웨어하우스: 정해진 스키마에 맞는 정제된 구조화 테이블을 저장하며, 데이터를 적재할 때 스키마를 적용합니다(쓰기 시 스키마 적용). 보통 추출, 변환, 적재(ETL) 단계를 거친 후 데이터를 저장합니다. Snowflake, BigQuery, Redshift와 같은 웨어하우스는 SQL 및 비즈니스 인텔리전스 쿼리에 빠르게 응답하지만 이미지, 텍스트 및 기타 비정형 데이터를 다루는 유연성은 낮습니다.
• 데이터 레이크: 데이터를 저렴하게 어떤 형식으로든 저장하고 적재 후에 변환(ELT)하므로 탐색, 데이터 마이닝, 머신러닝에 적합합니다. 일반적인 레이크 파일에는 트랜잭션 기능이 없어 여러 작성자가 동시에 쓰면 독자에게 쓰기가 완료되지 않은 결과가 표시될 수 있습니다.
• 레이크하우스: Apache Iceberg, Delta Lake, Apache Hudi와 같은 개방형 테이블 형식을 통해 레이크 스토리지에 웨어하우스 기능을 추가합니다. 이러한 형식은 ACID 트랜잭션, 스키마 적용, 테이블의 이전 버전으로 되돌아가는 타임 트래블 기능을 제공합니다. Databricks 연구진은 2021년 논문에서 이 아키텍처를 설명했습니다.

머신러닝에서의 데이터 레이크#

컴퓨터 비전 팀은 레이크에 모든 카메라 프레임과 캡처 메타데이터, 주석, 그리고 배포된 모델이 해당 프레임에 대해 생성한 예측을 저장합니다. 자율주행차 프로그램은 차량에서 주행 로그를 업로드하고, 로그를 마이닝해 비 오는 밤의 보행자처럼 드문 장면을 찾아 레이블을 지정한 다음 학습 세트에 추가합니다. 헬스케어 분야에서는 하나의 레이크에 수집된 비식별 스캔 이미지와 보고서가 의료 영상 분석 모델의 데이터로 활용됩니다. 검토와 재라벨링을 위해 프로덕션 예측을 레이크에 다시 저장하면 데이터 플라이휠이 완성됩니다. 테이블 스냅샷이나 DVC와 같은 도구를 사용하면 각 모델의 학습에 사용된 정확한 데이터 버전을 고정할 수 있습니다. 피처 스토어와 벡터 데이터베이스는 레이크를 기반으로 구축되는 경우가 많으며, 원시 파일에서 얻은 피처나 임베딩을 제공합니다.

Ultralytics Platform은 Amazon S3, Google Cloud Storage, Azure Blob Storage의 폴더를 복사본을 업로드하지 않고도 학습 데이터셋으로 변환할 수 있습니다. 읽기 전용 자격 증명으로 가져오기당 최대 500,000개의 객체를 원위치에서 인덱싱하고, 이미지 옆에 있는 YOLO .txt 레이블 파일을 파싱하며, 폴더 이름을 기준으로 학습, 검증, 테스트 분할을 지정합니다. 인덱싱된 각 이미지는 객체 버전에 고정되므로, 레이크에서 파일을 덮어쓴 이미지가 있으면 Platform은 해당 이미지를 사용하지 않습니다.