반응형 dataengineering3 ClickHouse vs Apache Doris: 왜 우리는 Doris를 선택했는가? 1. Apache Doris 기술이란?왜 필요한가 — 기존 방식의 한계실무에서 분석 파이프라인을 굴려 본 사람이라면 다음 패턴을 익숙하게 마주합니다.ClickHouse의 분산 JOIN 한계 — 단일 노드 성능은 무시무시하지만, 큰 팩트 테이블끼리 분산 JOIN을 던지면 Distributed 테이블의 GLOBAL JOIN이 폭주하거나, Colocate 키를 미리 못 맞춰서 데이터 셔플로 무너짐Hive/Trino 스택의 분 단위 지연 — Hive Metastore + Trino + S3 조합은 강력하지만, 데이터가 "지금 막 들어왔는데 1초 안에 보고 싶다"는 요구를 만족시키기 어려움Snowflake/BigQuery의 단가 — 잘 만들어진 SaaS지만, 대시보드 한 장이 분당 수백 번 갱신되는 운영 환경에서.. 2026. 7. 17. 실시간 업데이트가 가능한 데이터 레이크하우스의 표준, Apache Hudi 분석 Ⅰ. Apache Hudi 기술이란? 전통적인 데이터 레이크(HDFS, S3 등 객체 스토리지)는 Parquet, ORC와 같은 컬럼형 파일을 단순히 쌓아두는 구조로 설계되었습니다.이러한 구조는 대규모 배치 분석에는 강하지만, 다음과 같은 명확한 한계를 가지고 있습니다. ⅰ. Update / Delete 의 어려움 → 한 건의 행을 수정하려면 파일 전체를 다시 써야 함 (Immutable File System) ⅱ. 실시간성 부재 → 변경 데이터(CDC)를 반영하려면 매번 전체 테이블을 재작성해야 함 ⅲ. 트랜잭션 부재 → 동시에 쓰기/읽기가 일어나면 데이터 정합성을 보장할 수 없음 ⅳ. 작은 파일 문제(Small File Problem) → 스트리밍 적재 시 수많은 작은 파일이 생성되어 쿼리 성능 저하.. 2026. 5. 13. Apache Iceberg 성능 최적화와 데이터 관리 전략 데이터 레이크의 고질병인 작은 파일 문제와 데이터 단편화를 Iceberg 자체 관리 기능으로 해결하는 실전 운영 가이드입니다. 쿼리 성능을 10배 끌어올리고 스토리지 비용을 절반으로 줄이는 방법을 단계별로 정리했습니다.Ⅰ. Apache Iceberg 최적화 기술이란?단순한 저장 포맷을 넘어, 데이터 레이크의 두 가지 고질적 문제를 자체적으로 해결합니다. ① 작은 파일 문제 : 스트리밍/배치가 생성하는 수천 개의 작은 파일이 쿼리 플래닝 비용을 폭발적으로 키웁니다. ② 데이터 단편화 : 업데이트·삭제가 반복될수록 파일이 단편화되고, 불필요한 메타데이터가 쌓여 성능이 저하됩니다. Iceberg의 자체 관리 기능은 수천 개의 작은 파일을 하나로 병합하고 불필요한 메타데이터를 정리하여 쿼리 성능을 비약적으로.. 2026. 4. 27. 이전 1 다음 반응형