Snowflake는 Databricks와 비슷한 가격/성능을 주장하지만 그렇게 빠르지는 않습니다!

2021년 11월 2일, NVIDIA는 Databricks SQL 레이크하우스 플랫폼을 통해 가장 빠른
데이터 웨어하우스에 대한 공식 세계 기록을 세웠다 고 발표했습니다.
이러한 결과는 공식 TPC(Transaction Processing Performance Council)의 감사 및
보고를 통해 tpc.org 에서 온라인으로 제공되는 37페이지 분량의 문서로 보고되었습니다.
또한 Databricks SQL이 Snowflake보다 훨씬 빠르고 비용 효율적이라는
Barcelona Supercomputing Center(BSC)의 타사 벤치마크도 공유했습니다.

그 이후로 많은 축하, 몇 가지 질문, 그리고 신 포도 등 많은 일이 일어났습니다.
이 기회를 빌어 Databricks SQL은 데이터 웨어하우징 워크로드(TPC-DS)에서도
Snowflake보다 뛰어난 성능과 가격 대비 성능을 제공한다는 점을 다시 한 번 강조합니다.

Snowflake의 답변: "무결성 부족"?

Snowflake는 발표 후 10일 후(지난 금요일) 우리의 결과가 "무결성이 부족하다"고
주장하는 답변을 보냈습니다. 그런 다음 자체 벤치마크를 제시하여 자사의 제품이
267달러의 Databricks SQL과 242달러의 성능과 가격이 거의 같다고 주장했습니다.
액면 그대로, 이것은 그들이 가장 저렴한 제품의 가격을 가장 비싼 SQL 제품의 가격과
비교하고 있다는 사실을 무시합니다. (Snowflake의 《Business Critical》 계층은
가장 저렴한 계층 비용의 2배입니다.) 또한 Databricks가 대부분의 고객이 사용하는
스팟 인스턴스를 사용하여 가격을 146달러로 낮출 수 있다는 사실도 간과합니다.
그러나 이 중 어느 것도 이 게시물의 초점이 아닙니다.

Snowflake의 주장의 요지는 BSC와 동일한 벤치마크를 실행했으며 BSC가 측정한
8,397초에 비해 전체 벤치마크를 3,760초 만에 실행할 수 있다는 것입니다.
그들은 심지어 독자들에게 계정에 가입하고 직접 사용해 볼 것을 촉구했습니다.
결국, TPC-DS 데이터 세트는 Snowflake와 함께 즉시 제공되며 실행 방법에 대한
자습서도 있습니다. 따라서 결과를 쉽게 확인할 수 있어야 합니다.
우리는 정확히 그렇게했습니다. 먼저, 우리의 선례를 따라 경쟁업체가 플랫폼을
벤치마킹하는 것을 금지했던 DeWitt 조항을 제거한 Snowflake를 칭찬하고 싶습니다.
덕분에 우리는 재판 계정을 얻을 수 있었고 "무결성이 부족하다"는 주장의 근거를
확인할 수 있었습니다.

Snowflake에서 TPC-DS 재현하기

Snowflake에 로그인하고 TPC-DS용 자습서 4를 실행했습니다.
실제로 결과는 4,025초로 BSC 벤치마크의 8,397초보다 훨씬 빨랐습니다.
그러나 그 다음에 펼쳐진 일은 훨씬 더 흥미롭습니다.

벤치마크를 수행하는 동안 벤치마크 결과가 발표된 지 이틀 후에
Snowflake의 사전 베이킹된 TPC-DS 데이터 세트가 다시 생성되었음을
알게 되었습니다. 공식 벤치마크의 중요한 부분은 데이터 세트 생성을 확인하는 것입니다.
따라서 Snowflake의 미리 베이킹된 데이터 세트를 사용하는 대신 공식 TPC-DS
데이터 세트를 업로드하고 Snowflake가 미리 베이킹된 데이터 세트
(동일한 clusters 열 세트 포함)에서 동일한 clusters 크기(4XL)에서 사용하는 것과
동일한 스키마를 사용했습니다. 그런 다음 POWER 테스트를 세 번 실행하고 시간을 측정했습니다. 첫 번째 콜드 런은 10,085초가 걸렸고, 세 번의 런 중 가장 빠른 런은 7,276초가 걸렸습니다. 요약하자면, 공식 TPC-DS 데이터 세트를 Snowflake에 로드하고 전력 테스트를 실행하는데 걸리는 시간을 측정한 결과, Snowflake가 블로그에 보고한 것보다 1.9배 더 오래 걸렸습니다(3전 3선승제).

이러한 결과는 누구나 쉽게 확인할 수 있습니다. Snowflake 계정을 만들고 공식
TPC-DS 스크립트를 사용하여 100TB 데이터 웨어하우스를 생성하십시오.
해당 파일을 Snowflake로 수집합니다. 그런 다음 몇 번의 POWER 실행을
실행하고 시간을 측정하십시오. 결과는 7000초에 가까우며, clusters 열을
사용하지 않는 경우 더 높은 숫자가 될 것입니다(다음 섹션 참조).

Snowflake와 함께 제공되는 데이터 세트에서 POWER 테스트를 실행할 수도 있습니다.
이러한 결과는 블로그에 보고한 시간에 더 가까울 것입니다.

왜 공식 TPC-DS인가?

Snowflake의 미리 베이킹된 데이터 세트에서 TPC-DS를 실행하는 것과 공식 데이터 세트를
Snowflake에 로드하는 것 사이에 큰 차이가 있는 이유는 무엇입니까?
우리는 정확히 알지 못합니다. 그러나 데이터를 배치하는 방법은 TPC-DS,
그리고 일반적으로 모든 워크로드에 큰 영향을 미칩니다.

대부분의 시스템에서 특정 워크로드에 대한 데이터를 clusters 하거나 분할하면
(예: query사용된 필드 조합으로 정렬) 해당 워크로드의 성능을 향상시킬 수 있지만
이러한 최적화에는 추가 비용이 수반됩니다. 이 시간과 비용은 벤치마크 결과에 포함되어야 합니다.

이러한 이유로 공식 벤치마크에서는 시스템이 레이아웃을 최적화하는 데 걸리는 시간과 비용을
올바르게 설명할 수 있도록 데이터를 데이터 웨어하우스에 로드 하는 데 걸리는 시간을
보고해야 합니다. 이 시간은 일부 스토리지 체계에 대한 POWER 테스트 query 보다 훨씬 더
길어질 수 있습니다.

공식 벤치마크에는 실제 데이터 세트 및 워크로드와 마찬가지로 데이터
업데이트 및 유지 관리도 포함됩니다(변경되지 않는 데이터 세트를 얼마나 자주 query 합니까?).
이 모든 것은 시스템이 변경할 수 없는 정확한 워크로드 집합에 대해 오프라인에서 정적 데이터
세트를 최적화하는 데 막대한 리소스를 소비한 다음 해당 워크로드를 매우 빠르게 실행할 수 있는
시나리오를 방지하기 위해 수행됩니다. 또한 공식 벤치마크에는 재현성이 필요합니다.
그렇기 때문에 제출에서 기록을 재현하기 위한 모든 코드를 찾을 수 있습니다.

이것은 우리를 마지막 요점으로 이끕니다.
우리는 벤치마크가 "벤치마크를 개선할 수 있는 구성 노브, 특수 설정 및 매우 구체적인
최적화를 추가하는" 산업 플레이어로 빠르게 전환될 수 있다는 Snowflake의
의견에 동의합니다. 모든 사람은 자신의 벤치 마크에서 정말 좋아 보입니다.
따라서 어느 한 공급업체의 말에 귀를 기울이는 대신, Snowflake가
공식 TPC 벤치마크에 참여하도록 도전합니다.

고객 중심의 벤치마킹

이 벤치마크에 참여하기로 결정했을 때, 우리는 엔지니어링 팀이 과거 항목과 달리
거의 모든 고객이 수행한 공통적으로 적용된 최적화만 사용해야 한다는 제약 조건을
설정했습니다. 데이터 세트 또는 query 에 대한 깊은 이해가 필요한 최적화를
적용할 수 없었습니다 (Snowflake 미리 베이킹된 데이터 세트에서 수행된 것처럼,
추가 clusters 열이 있음). 이는 실제 워크로드 및 대부분의 고객이 보고 싶어하는 것
(튜닝 없이 뛰어난 성능을 달성하는 시스템)과 일치합니다.

제출된 내용을 자세히 읽어보면 일반적인 고객이 원하는 데이터 관리 방식과 일치하는
재현 가능한 단계를 찾을 수 있습니다. 새로운 데이터 세트로 생산성을 높이기 위한
노력을 최소화하는 것이 Databricks SQL의 최우선 설계 목표 중 하나였습니다.

결론

Databricks의 마지막 한마디입니다. 공동 창립자로서 우리는 고객에게
최고의 가치를 제공하고 고객의 비즈니스 요구 사항을 해결하기 위해 구축하는
소프트웨어에 깊은 관심을 가지고 있습니다. 세상에 대한 우리의 이해와
일치하지 않는 벤치마크 결과는 감정적이거나 본능적인 반응으로
이어질 수 있습니다. 우리는 그것이 우리를 최대한 활용하지 못하게 하려고 노력합니다.

우리는 진실을 추구하고 검증 가능한 결과를 발표할 것입니다.
따라서 우리는 Snowflake가 블로그에 게시한 결과의 무결성이 부족하다고
비난하지 않을 것입니다. 공식 TPC 위원회를 통해 결과를 확인하도록 요청합니다.

공식 TPC 데이터 웨어하우징 벤치마크에 참여한 주된 동기는 어떤 데이터 웨어하우스가
더 빠르거나 더 저렴한지 증명하기 위한 것이 아니었습니다. 오히려, 우리는 모든 기업이
FAANG 회사처럼 데이터 기반이 될 수 있어야 한다고 믿습니다.
이러한 회사는 데이터 웨어하우스를 기반으로 구축하지 않습니다.

대신 모든 데이터(정형, 텍스트, 비디오, 오디오)를 개방형 형식으로 저장하고 Data Science,
머신 러닝, 실시간 분석 또는 고전적인 비즈니스 인텔리전스 및 데이터 웨어하우징 등
모든 종류의 분석에 단일 복사본을 사용하는 훨씬 더 간단한 데이터 전략을 사용합니다.

SQL만으로 모든 작업을 수행하지는 않습니다. 그러나 오히려 SQL은 Python, R 및 데이터를 활용하는 오픈 소스 생태계의 다른 많은 도구와 함께 무기고의 핵심 도구 중 하나입니다. 우리는 이 패러다임을 데이터 레이크하우스라고 부릅니다. 데이터 레이크하우스는 데이터 웨어하우스와 달리 Data Science, 기계 학습 및 실시간 스트리밍을 기본적으로 지원합니다. 그러나 SQL 및 BI에 대한 기본 지원도 있습니다. 우리의 목표는 데이터 레이크하우스가 동급 최고의 가격과 성능을 제공할 수 없다는 신화를 깨는 것이었습니다. 우리는 스스로 벤치마킹을 하기보다는 진실을 추구하고 공식 TPC 벤치마크에 참여했습니다. 따라서 데이터 레이크하우스 패러다임이 기존 데이터 웨어하우징 워크로드(TPC-DS) 에서도 데이터 웨어하우스보다 우수한 성능과 가격을 제공한다 는 사실에 매우 만족합니다. 이는 모든 데이터를 관리하기 위해 더 이상 여러 데이터 레이크, 데이터 웨어하우스 및 스트리밍 시스템을 유지 관리할 필요가 없는 기업에 도움이 될 것입니다. 이 간단한 아키텍처를 통해 매일 직면하는 비즈니스 요구 사항과 문제를 해결하는 데 리소스를 재배치할 수 있습니다.