PostHog, 데이터 웨어하우스를 DuckDB에서 이전

PostHog가 예상보다 커지고 복잡해진 고객 워크로드를 처리하기 위해 DuckDB 기반 웨어하우스에서 이전함. ClickHouse에서 DuckDB로 전환한 지 5개월 만이며, 최근 3개월간 아키텍처를 다시 설계함 단일 노드 실행 구조에서는 쿼리가 도착하기 전에 워커 크기를 정해야 했지만, 필요한 CPU와 메모리를 예측하기 어려웠음 DuckLake의 카탈로그 호환성 요구가 최적화 선택지를 제한함. 커밋마다 전체 카탈로그 통계를 다시 읽어 단일 테이블 쓰기에 3분 이상 걸릴 수 있었음 내부 검증용 DuckLake는 약 2PB, 1조 행 규모에 이르렀으며, 필요한 변경을 충분히 빠르게 반영하지 못해 포크에서 패치를 유지하게 됨 새 웨어하우스는 자체 변형한 Trino와 개방형 테이블 포맷 HogLake를 기반으로 구축함. PostHog의 페타바이트 규모 데이터로 먼저 검증했으며, 기술 자체보다 사용자 경험에 초점을 맞춤 ClickHouse에서 DuckDB로 옮겼던 이유 5개월 전 웨어하우스를 DuckDB로 재구축한 이유는 공유 ClickHouse 클러스터가 수 시간씩 걸리는 모델링 쿼리를 감당하지 못했고, 비용 기반 쿼리 옵티마이저도 없었기 때문임 DuckDB에서는 고객마다 별도 인스턴스를 제공하고, dbt 같은 도구가 Postgres를 통해 접속할 수 있었음 고객 워크로드의 규모와 복잡성을 과소평가했으며, 규모와 관계없이 합리적인 가격으로 좋은 관리형 웨어하우스 경험을 제공하기 위해 최근 3개월간 재설계를 진행함 단일 머신의 장점이 클라우드에서는 제약이 됨 DuckDB는 노트북을 포함한 단일 노드에서 대량 데이터를 분석하는 데 강점이 있으며, 안정적으로 쿼리를 완료하고 메모리가 부족하면 디스크로 데이터를 내려 처리함 예상보다 복잡한 고객 쿼리 때문에 대형 인스턴스를 추가해야 했음 디스크를 추가할 수도 있었지만, 쿼리가 너무 느리고 비싸져 현실적인 선택지가 아니었음 클라우드에서 단일 노드 엔진을 안전하게 운영하려면 쿼리 도착 전에 워커 크기를 정해야 함 고객에게 필요한 리소스를 안내할 좋은 방법을 찾지 못했으며, 특정 쿼리의 CPU와 메모리 요구량을 예측하기는 더욱 어려웠음 사용자가 리소스 문제를 고민하지 않고 필요한 쿼리를 실행하도록 하고, 서비스가 나머지를 최대한 예측 가능하게 처리하는 것이 목표임 S3에서 많은 데이터를 가져올 때 비동기 가져오기 부재도 병목이었으며, DuckDB는 이 기능을 최근에야 추가함 D...