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% 포괄적이거나 대부분의 사람들에게 최선의 출발점이 되지는 않을 것이라는 점을 인정함.

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