▲GN⁺ 2023-12-31 | parent | ★ favorite | on: 파케, 아이스버그 및 데이터 레이크하우스 이해(davidgomes.com)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% 포괄적이거나 대부분의 사람들에게 최선의 출발점이 되지는 않을 것이라는 점을 인정함. 새로운 것을 배우는 가장 좋은 방법은 다른 사람들에게 다시 설명하는 것이라는 태도를 좋아하고, 자신도 웹사이트의 노트에 적용하기 시작함.
Hacker News 의견
Apache Iceberg과 Delta Lake은 종종 오픈 테이블 포맷으로 언급되지만, 실제로는 차이가 있음.
데이터베이스 세계에서는 Delta, Iceberg, Hudi가 S3 같은 스토리지에 오픈 소스 포맷으로 데이터를 저장하는 것이 큰 변화를 의미함.
Parquet 파일을 S3에서 수년간 작업해왔지만, Iceberg가 무엇인지 정확히 이해하지 못했음. 하지만 해당 기사가 Iceberg를 잘 설명함.
Apache Arrow 데이터프레임을 디스크에 파일로 저장하는 최선의 방법은 Feather를 사용하는 것이지만, Apache Parquet 포맷으로 변환하는 것도 가능함.
데이터 레이크에 대해 들어봤지만, "데이터 레이크하우스"는 상류층 데이터가 여름에 데이터 보트로 데이터 낚시를 가는 곳처럼 들림.
GCP에서 약 100TB 데이터를 다루고 있으며, BigQuery를 질의 엔진으로 사용하고 간단한 Hive 파티셔닝을 사용함. 모든 질의를 실행할 수 있고 비용이 매우 저렴함에 만족하지만, 대기 시간이 상당히 높아짐(회사에 큰 문제는 아님).
Iceberg에 대해 매우 흥분되지만, 마지막으로 조사했을 때 Spark 라이브러리만이 구현체였고, Trino의 Iceberg 커넥터는 Hive에 강한 의존성이 있었음.
이 모든 것을 더 구체적인 아이디어로 설명할 수 있는 사람이 없는 이유에 대해 의문을 제기함. 데이터를 저장하는 방법, 연결 및 질의하는 방법, 그리고 질의 속도(트랜잭션 속도 대비 "분석" 속도)에 대해 설명해야 함.
온라인에서 본 모든 벤치마크에서 Delta Lake 포맷이 Iceberg보다 훨씬 더 나은 성능을 보임.
블로그 포스트가 100% 포괄적이거나 대부분의 사람들에게 최선의 출발점이 되지는 않을 것이라는 점을 인정함.