빅데이터 플랫폼 개발이 하둡없이 가능한가요?

1. 서론

• Lakehouse: Databricks에서 제시한 개념 (warehouse + lake)

• Data Warehouse → Data Lake → Lakehouse 로 발전해야 한다는 관점

• Lakehouse는 이전 아키텍처와 무슨 차이가 있을까?
• 직접 접근 가능한 열 기준 저장 포맷
• Dataframe API 개발로 인한 ML/DS 특화
• 메타데이터 관리를 위한 레이어 추가
• SQL 성능

2. Data Warehouse (a)

• 일반적으로 컴퓨팅 리소스와 스토리지를 on-premise에 구축하기 때문에 데이터가 많아질수록 관리에 드는 비용이 증가

• 최근 데이터 생산량이 빠르게 증가했으며, 특히 비디오, 오디오 및 텍스트 문서와 같은 비정형 데이터가 늘어남

3. Data Warehouse + Data Lake (b)

개요

• HDFS를 사용하는 Apache Hadoop에서 시작 (Data lake 1.0)

• 데이터 레이크에 모든 데이터를 저장하고, API를 통해 데이터를 가져오는 방법

• 비정형, 반정형 데이터를 다룰 수 있게 됨으로써 데이터의 질 문제 해결

• S3, ADLS 및 GCS와 같은 클라우드 데이터 레이크가 HDFS를 대체하기 시작
• 클라우드의 장점: 싸고, 자동으로 아카이빙되고, 데이터 복제해두고, 내구성 좋음

• 2계층 데이터 레이크 + 웨어하우스 아키텍처
• Redshift 또는 Snowflake가 대표적인 2 계층 구조

문제점

• 어려움 (조인 → 맵리듀스)

• 레이크에서는 ELT만 하면 되는 줄 알았지만..
• 현실에서는 데이터가 데이터 레이크로 ETL된 후 다시 데이터 웨어하우스로 ELT되어 더 복잡한 구조 (ETL/ELT 작업 수가 증가 → 오류 가능성)
• 데이터가 레이크와 웨어하우스에 서로 다른 스키마로 저장된다는 부가적인 문제

• ML/DS에서 사용하기 불편한 구조임
• Reliability - 웨어하우스와 레이크 모두를 동시에 업데이트해야 하기 때문에, 정합성 불일치 시 데이터 분석 등에는 치명적
• Data staleness - 레이크 → 웨어하우스로 이관되는 시간이 생겼기 때문에, 새로운 데이터가 생겨도 웨어하우스에서 바로 쿼리할 수 없음
• Limited support for advanced analytic - ML/DS할 때, 웨어하우스에 직접 접근이 안됨(웨어하우스에서 사용하는 저장포맷을 PyTorch나 Tensorflow가 바로 사용할 수 없음)
• 이게 안되니까 하둡 + spark를 사용했던 것
• 이미지, 시계열, 텍스트 데이터 등을 저장하고 관리하기 위한 API가 웨어하우스로부터 제공되지 않음. 그 대안으로 아래와 같은 방법을 쓰고 있었는데..
• ODBC/JDBC로 데이터 읽어오기: 데이터가 클수록 점점 더 시간이 오래 걸리고 비효율적
• 별도의 파일로 떨궈주기: 3번째 ETL

• Total Opportunity cost of ownership (TOCO): 실제로는 저렴하지 않은 클라우드
• 지속적인 ETL에 대한 비용
• Replicated data에 대한 두 배의 스토리지 비용
• 웨어하우스는 기본적으로 독점적인 데이터 형식 사용 → 마이그레이션 시 비용

• 메타데이터를 잘 처리하지 못했음 → 하이닉스가 중요하게 본 부분
• hive, pig가 메타데이터 관리 측면을 커버함으로써 거버넌스 문제 해결하는 것처럼 보였지만, 이들의 성능 한계를 넘어가려면 너무 많은 튜닝이 필요
• 데이터 늪(data swamp)이라는 용어가 생긴 원인

4. Data Lakehouse (c)

개요

• 웨어하우스의 데이터 제어, 관리 등을 레이크에 포함시킨 아키텍처

• 주로 플랫폼 형태로 제공됨 (AWS, Azure, GCP, Snowflake, Databricks)

• 컴퓨팅과 스토리지가 분리된 클라우드 환경에 적합

• 서로 다른 컴퓨팅 어플리케이션을 완전히 분리된 컴퓨팅 노드(예를 들어, ML용 GPU 클러스터)에서 온디맨드로 실행하면서 동일한 스토리지 데이터에 직접 액세스 가능

이전 아키텍처에 비해 개선된 점

• 직접 접근 가능한 열 기준 저장 포맷
• 관계형 DBMS의 데이터 독립성의 일부 측면을 포기하고 직접 접근을 허용
• Apache Parquet, Optimized Row Columnar (ORC)
• TensorFlow, Pytorch, Spark는 이미 Parquet를 읽어올 수 있음 (ORC는 아직인듯)

• Dataframe API 개발로 인한 ML/DS 특화
• ML/DS 분야에서는 정형 데이터를 다룰 때 dataframe 형식이 지배적 → DataFrame API
• API를 통해 메타데이터를 쿼리하여 추출 대상 Parquet 파일을 파악한 다음 ML 라이브러리에 전달하면 바로 Dataframe으로 떨어짐

• 메타데이터 관리를 위한 레이어 추가
• Object Storage에 저장되는 모든 파일에 대해 ACID(원자성, 일관성, 독립성, 내구성) 트랜잭션 지원 (이전 아키텍처에서는 Hive가 담당하던 역할) → 메타데이터 계층에도 적용
• 넷플릭스는 Apache Iceberg, 우버는 Apache Hudi, Databricks는 Delta Lake를 사용해 구현

• SQL 성능 개선
• Caching - 기존의 데이터 웨어하우스 엔진에서 사용되었던 독점적인 최적화 방식을 캐시로 구현. Delta Lake의 경우, 트랜잭션 실행 시 처리 노드의 SSD 및 RAM에 Object Storage 파일을 캐시함.
• Auxiliary data - DB에서 인덱스 만드는 것과 비슷한 역할. 보조 데이터를 사용해 인덱스, 통계치를 관리하여 쿼리 최적화
• Data layout - 어떤 레코드가 클러스터링되어 함께 읽기가 가장 쉬운지 계산해 데이터 레이아웃 지정(데이터 파일 내에서 서로 다른 순서로 열을 배치하거나, 여러 레코드 그룹에 대해 압축을 다르게 하거나)

향후 해결해야 하는 것

• Delta Lake의 경우, 트랜잭션 로그를 실행하는 메타데이터를 동일한 Object Storage에 저장하도록 설계 → 다른 Object Storage에 저장할 경우 트랜잭션 속도가 빨라질 수 있음

• Delta Lake, Iceberg, Hudi의 경우 한 번에 하나의 테이블에서만 트랜잭션 지원 → 테이블 간 트랜잭션 지원하도록 개선 필요

• 트랜잭션 로그의 형식, 관리되는 개체의 크기 최적화 필요