Open Tables, Shared Truth: 멀티 엔진 레이크하우스 아키텍처 설계

Source: Dev.to

문제

• 동일한 데이터셋이 여러 번 복사됩니다.
• 동일한 메트릭이 서로 다른 결과를 생성합니다.
• 거버넌스 로직이 시스템 전반에 걸쳐 재구현됩니다.

그럼에도 불구하고 조직들은 자신 있게 주장합니다:

“우리는 단일 진실의 원천을 가지고 있습니다.”

실제로 존재하는 것은 별개의 복사본들입니다:

• 웨어하우스 복사본
• 레이크 복사본
• 서빙 복사본

각각은 약간씩 다르며 자신의 맥락에서만 “올바른” 것으로 간주됩니다.

우리가 여기까지 온 이유

역사적으로:

1. 컴퓨팅 엔진들이 포맷에 합의하지 못했습니다.
2. 스토리지 시스템에 트랜잭션 보장이 없었습니다.
3. 거버넌스가 특정 플랫폼에 얽혀 있었습니다.

엔지니어들은 파이프라인을 조각난 진실을 연결하는 접착제로 만들었습니다—하지만 파이프라인은 진실을 확장하기보다 복제시킵니다.

오픈 테이블 포맷으로의 전환

데이터 레이크는 “모든 것을 한 곳에 저장한다”는 약속으로 도입되었으며, 다음과 같은 이점을 제공했습니다:

• 더 빠른 접근
• ETL 작업 감소
• 유연한 분석

하지만 소유권은 변하지 않았습니다; 레이크는 접근 가능해졌지만 권위 있는 저장소는 아니었습니다.

새로운 소유권 단위

테이블이 엔진이 아니라 소유권의 단위입니다.

과거에는 엔진이 데이터를 소유하고 파이프라인이 엔진 간에 데이터를 이동시켰습니다. 이제 테이블이 공유되고, 거버넌스가 적용되며, 권위 있는 자산이 됩니다.

Apache Iceberg, Delta Lake, Apache Hudi와 같은 오픈 테이블 포맷은 객체 스토리지에 데이터베이스와 같은 보장을 제공합니다:

• ACID 트랜잭션
• 스키마 진화
• 타임 트래블
• 스냅샷 격리
• 동시 읽기 및 쓰기

다중 엔진 호환성

여러 엔진이 동일한 테이블을 안정적으로 읽고 쓸 수 있습니다, 예를 들어:

• Apache Spark
• Trino
• Amazon Athena
• Snowflake

중복 없이, 변환 레이어 없이.

현대적인 레이크하우스 아키텍처

전통적 접근 방식 vs. 현대적 접근 방식

계층형 아키텍처

1. 스토리지 레이어 – 객체 스토리지(예: Amazon S3)
2. 테이블 레이어 – 오픈 테이블 포맷(Iceberg / Delta / Hudi)
3. 컴퓨트 레이어 – 다중 엔진(Spark, Trino, Athena 등)
4. 거버넌스 레이어 – 중앙 집중식 정책 시행(예: AWS Lake Formation)
5. 소비 레이어 – BI, ML, API

설계 규율

오픈 테이블을 사용하더라도, 팀은 다음과 같은 함정에 빠질 수 있습니다:

• 테이블을 CSV 파일처럼 다루는 것
• 소유권 모델이 없는 경우
• 모든 엔진에서 무제한 쓰기를 허용하는 것
• 비용 및 압축 전략을 무시하는 것

주요 고려 사항

• Concurrent writers – 충돌 해결 전략
• Compaction ownership – 누가 테이블 성능을 유지합니까?
• Performance tuning – 파티셔닝, 인덱싱
• Failure domains – 무엇이 언제, 어디서 깨지는가?

이는 엔지니어링 결정뿐만 아니라 플랫폼 결정입니다.

조직 변화

변화는 기술보다 더 큽니다; 이는 조직적 변혁입니다.

• 데이터 복사를 중단하세요.
• 진실을 공유하기 시작하세요.
• 테이블을 제품처럼 설계하세요.
• 엔진을 교체 가능하게 하세요.

“가장 확장 가능한 분석 플랫폼은 도구가 아니라 합의를 중심으로 구축됩니다.”

Conclusion

우리는 데이터를 처리하는 속도를 최적화하는 데 수년을 투자했습니다. 이제 중요한 질문은 다음과 같습니다:

진실은 어디에 존재하며, 누가 그것을 소유하고 있는가?

이 문제가 해결되지 않으면, 아무리 많은 컴퓨팅 파워를 투입해도 데이터 플랫폼을 고칠 수 없습니다.