6P by neo 2달전 | favorite | 댓글 2개

이해하기: Parquet, Iceberg 그리고 BroadIn의 데이터 레이크하우스

  • 데이터 저장 방식(파일 및 메모리 내)

    • 데이터 액세스 및 저장을 위한 다양한 파일 형식 존재
    • 일부 시스템은 폐쇄적인 데이터 형식을 주로 사용하지만, 대부분의 시스템은 오픈 데이터 형식을 지원
    • 주요 오픈 소스 파일 형식에는 Apache Avro, Parquet, ORC, Arrow, Feather, Protobuf 등이 있음
    • 이러한 형식들은 데이터를 실제 이진 레이아웃에 어떻게 배열할지에 대한 사양을 제공
    • Parquet는 압축을 잘 지원하고, Avro는 특정 행 블록을 읽는 데 적합
    • 스키마 진화와 파일 분할을 지원하여 병렬 처리에 필수적임
    • 다양한 프로그래밍 언어와 도구에서 이러한 형식으로 작업 가능
  • 대규모 데이터 관리 - Iceberg와 Delta Lake

    • 다양한 테이블을 저장하고 개별 스키마를 진화시키며, 효율적으로 데이터를 파티셔닝하고 외부 도구가 스키마를 쉽게 읽을 수 있도록 하는 방법 필요
    • Hive, Iceberg, Delta Lake는 모두 스키마 레지스트리 또는 메타스토어를 지원
    • Iceberg와 Delta Lake는 Parquet을 개별 파일 형식으로 사용
    • Iceberg와 Delta Lake는 쿼리 또는 스토리지 엔진이 아니라 쿼리 엔진이 작업을 수행할 수 있도록 하는 오픈 사양
    • 파티셔닝 진화, 스키마 진화, 데이터 압축, ACID 트랜잭션, 효율적인 쿼리 최적화, 시간 여행 등의 기능을 가능하게 함
  • 데이터 레이크와 데이터 레이크하우스는 무엇인가?

    • 데이터 레이크는 회사들이 OCR, Parquet 또는 CSV 파일과 같은 원시 형식으로 대량의 데이터를 저장하는 곳
    • 데이터 레이크하우스는 데이터 레이크 위에 SQL 쿼리 실행, 배치 작업 설정, 데이터 거버넌스 구성 등을 가능하게 하는 기능의 결합
    • 데이터 레이크하우스는 개방형 데이터 웨어하우스의 버전으로 볼 수 있음
    • Snowflake와 BigQuery와 같은 데이터 웨어하우스가 Iceberg와 같은 오픈 데이터 형식을 지원함에 따라 데이터 웨어하우스와 데이터 레이크하우스 간의 경계가 모호해지고 있음

GN⁺의 의견

  • Iceberg와 Delta Lake는 대규모 데이터 세트를 관리하기 위한 메타데이터 레이어로서 중요한 역할을 함. 이들은 데이터의 효율적인 관리와 쿼리 최적화를 가능하게 하여 데이터 과학자와 엔지니어에게 유용함.
  • 데이터 레이크하우스는 데이터 레이크와 데이터 웨어하우스의 장점을 결합하여, 데이터 관리와 분석을 위한 새로운 패러다임을 제시함. 이는 데이터 기반 의사결정을 더욱 강화할 수 있는 기회를 제공함.
  • Iceberg의 지원이 증가함에 따라, 데이터 관리 및 분석 시스템은 점차 표준화되고 상호 운용 가능해질 것으로 예상됨. 이는 데이터 플랫폼의 선택과 사용에 있어서 더 많은 유연성과 효율성을 가져올 것임.

아이스버그와 델타레이크 비교 하고 있었는데 이렇게 정리 깔끔하게 됐군요.
제가 보고있던 견해와 의견이 거의 비슷합니다.
온라인에서 실행된 벤치마크는 Spark 를 사용한것이고 벤치마크는 참고할만 하지만, 큰 의미는 없다고 Tabular 의 Head DevRel 이 글을 썼습니다.
오픈소스로서 선택하려면 iceberg 가 유일해 보입니다
요약은 좋으나 참고한 링크도 있다면 좋겠습니다

Hacker News 의견
  • Apache Iceberg과 Delta Lake은 종종 오픈 테이블 포맷으로 언급되지만, 실제로는 차이가 있음.

    • Apache Iceberg 테이블 포맷 사양은 데이터베이스 시스템에 익숙한 사람이라면 Iceberg 테이블을 구축하고 질의하는 데 큰 어려움이 없을 정도로 명확함.
    • 반면, Delta Lake 사양은 현재 사양을 완전히 구현하거나 지속적으로 업데이트하는 데 필요한 노력을 파악하기 어려움.
    • Delta Lake 사양은 Databricks가 Hadoop에 실망한 Fortune 1000 기업을 대상으로 레이크하우스를 구축하기 위해 내부적으로 결정한 구현 방식을 역설계한 것처럼 보임.
    • Delta Lake가 진정으로 개방된 생태계로서의 가치가 있는지에 대한 확신이 서지 않음.
  • 데이터베이스 세계에서는 Delta, Iceberg, Hudi가 S3 같은 스토리지에 오픈 소스 포맷으로 데이터를 저장하는 것이 큰 변화를 의미함.

    • 이는 스토리지와 처리의 많은 부분이 표준화되어 데이터베이스 간의 이동이 용이해지고, 대부분의 도구들이 트랜잭션적으로 안정적인 방식으로 동일한 파일 세트와 작업할 수 있게 됨.
    • 예를 들어, Snowflake가 파일에 쓰는 동안 데이터 과학자가 Jupyter 노트북에서 실시간으로 데이터를 질의하고, ClickHouse가 동일한 데이터에 대해 사용자 중심의 분석을 제공할 수 있음.
    • 비즈니스가 Snowflake에서 Databricks로 전환하기로 결정하더라도 큰 문제가 되지 않음.
    • 현재 S3에서 이러한 포맷을 질의하는 속도는 네이티브 수집만큼 빠르지는 않지만, 시장의 압력으로 모든 데이터베이스 벤더가 성능을 최적화하게 될 것임.
    • 오픈 소스와 개방성에 대한 큰 승리이며, 비즈니스가 데이터를 개방적이고 이동 가능한 포맷으로 가질 수 있게 됨.
    • 레이크하우스도 비슷한 영향을 미침. 많은 회사들이 데이터 레이크와 데이터 웨어하우스를 가지고 있으며, 두 시스템 간에 데이터를 복사해야 함. 동일한 데이터 세트를 질의하고 하나의 시스템만 관리하는 것은 마찬가지로 중요함.
  • Parquet 파일을 S3에서 수년간 작업해왔지만, Iceberg가 무엇인지 정확히 이해하지 못했음. 하지만 해당 기사가 Iceberg를 잘 설명함.

    • Iceberg는 기본 데이터 세트에 대한 데이터베이스 메타데이터 포맷으로, 스키마, 파티셔닝 등을 설명함.
    • 전통적인 DBMS에서는 스키마, 질의 엔진, 스토리지 포맷이 하나의 패키지로 제공됨.
    • 하지만 빅데이터에서는 데이터베이스 구성 요소를 처음부터 구축하고, 혼합 및 매치할 수 있음. Iceberg를 메타데이터 포맷으로, DuckDB를 질의 엔진으로, Parquet를 스토리지 포맷으로, S3를 스토리지 매체로 사용할 수 있음.
  • Apache Arrow 데이터프레임을 디스크에 파일로 저장하는 최선의 방법은 Feather를 사용하는 것이지만, Apache Parquet 포맷으로 변환하는 것도 가능함.

    • 자신만의 비-JVM 레이크하우스를 구축하려면 Iceberg를 메타데이터로, Parquet를 데이터로 사용하고, Arrow 테이블을 사용하여 DuckDB로 질의하며, Arrow->Pandas 또는 Polars를 통해 데이터를 처리할 수 있음.
    • Feather를 혼합하면 현재 Python 레이크하우스 스택이 작동하지 않음.
  • 데이터 레이크에 대해 들어봤지만, "데이터 레이크하우스"는 상류층 데이터가 여름에 데이터 보트로 데이터 낚시를 가는 곳처럼 들림.

  • GCP에서 약 100TB 데이터를 다루고 있으며, BigQuery를 질의 엔진으로 사용하고 간단한 Hive 파티셔닝을 사용함. 모든 질의를 실행할 수 있고 비용이 매우 저렴함에 만족하지만, 대기 시간이 상당히 높아짐(회사에 큰 문제는 아님).

    • Iceberg를 구현하면 이를 개선할 수 있는지 궁금함. Iceberg를 사용해본 경험이 있는지 물음.
  • Iceberg에 대해 매우 흥분되지만, 마지막으로 조사했을 때 Spark 라이브러리만이 구현체였고, Trino의 Iceberg 커넥터는 Hive에 강한 의존성이 있었음.

    • 전체 산업이 MapReduce, Hive, Spark와 같은 레거시 기술과 이혼하는 데 어려움을 겪고 있음.
    • Iceberg에 대해 다시 조사할 계획이며, 이 분야가 발전하기를 기대함. 오늘날 우리는 레거시 기술 없이 데이터를 처리할 수 있는 도구와 컴퓨팅 파워를 가지고 있으며, 모든 데이터가 빅데이터는 아님.
    • 결과적으로 "데이터 엔지니어링"은 점점 더 일반적인 백엔드 개발과 유사해지고 있으며, 일반적인 개발 관행이 적용되고 있음.
    • 순수 Python Iceberg 라이브러리가 매우 곧 나오길 바라는 마음.
  • 이 모든 것을 더 구체적인 아이디어로 설명할 수 있는 사람이 없는 이유에 대해 의문을 제기함. 데이터를 저장하는 방법, 연결 및 질의하는 방법, 그리고 질의 속도(트랜잭션 속도 대비 "분석" 속도)에 대해 설명해야 함.

  • 온라인에서 본 모든 벤치마크에서 Delta Lake 포맷이 Iceberg보다 훨씬 더 나은 성능을 보임.

    • 이것이 사양에 근본적인 것인지, 아니면 Iceberg가 격차를 좁힐 수 있는 가능성이 있는지에 대한 질문.
  • 블로그 포스트가 100% 포괄적이거나 대부분의 사람들에게 최선의 출발점이 되지는 않을 것이라는 점을 인정함.

    • 새로운 것을 배우는 가장 좋은 방법은 다른 사람들에게 다시 설명하는 것이라는 태도를 좋아하고, 자신도 웹사이트의 노트에 적용하기 시작함.