메인 콘텐츠로 건너뛰기

데이터 타입

수치형

ClickHouse와 Snowflake 간에 데이터를 옮기는 사용자는 ClickHouse가 수치형 선언에서 더 세밀한 정밀도를 제공한다는 점을 바로 알 수 있습니다. 예를 들어, Snowflake는 수치형에 Number 유형을 제공합니다. 이 경우 사용자는 precision(전체 자릿수)과 scale(소수점 이하 자릿수)을 최대 38자리까지 지정해야 합니다. Integer 선언은 Number와 같은 의미이며, 단지 동일한 범위 내에서 고정된 precision과 scale을 정의할 뿐입니다. 이러한 편의성은 precision을 변경해도(정수의 경우 scale은 0) Snowflake에서 디스크에 저장되는 데이터 크기에 영향을 주지 않기 때문에 가능합니다. 즉, 쓰기 시점에 마이크로 파티션 수준에서 해당 수치 범위에 필요한 최소 바이트만 사용됩니다. 다만 scale은 저장 공간에 영향을 미치며 compression으로 이를 어느 정도 상쇄할 수 있습니다. Float64 유형은 정밀도가 일부 희생되는 대신 더 넓은 값 범위를 제공합니다. 반면 ClickHouse는 float와 integer에 대해 다양한 signed 및 unsigned 정밀도를 제공합니다. 이를 통해 정수에 필요한 precision을 명시적으로 지정하여 스토리지와 메모리 오버헤드를 최적화할 수 있습니다. 또한 Snowflake의 Number 유형에 해당하는 Decimal 유형은 최대 76자리까지 지원하므로 precision과 scale 측면에서 두 배의 범위를 제공합니다. 이와 함께 Float64 외에도, ClickHouse는 정밀도가 덜 중요하고 compression이 특히 중요한 경우를 위해 Float32도 제공합니다.

문자열

ClickHouse와 Snowflake는 문자열 데이터를 저장하는 방식에서 서로 다른 접근법을 취합니다. Snowflake의 VARCHAR는 UTF-8 유니코드 문자를 저장하며, 사용자가 최대 길이를 지정할 수 있습니다. 이 길이는 저장 공간이나 성능에 영향을 주지 않으며, 문자열은 항상 필요한 최소 바이트 수로 저장되고, 오히려 후속 도구에서 활용할 수 있는 제약 조건만 제공합니다. TextNChar와 같은 다른 유형은 단지 이 유형의 별칭일 뿐입니다. 반면 ClickHouse는 모든 문자열 데이터를 원시 바이트String 유형에 저장하며(길이 지정 불필요), 인코딩은 사용자에게 맡기고, 다양한 인코딩을 처리할 수 있는 쿼리 시점 함수를 제공합니다. 그 배경에 대해서는 “Opaque data argument”를 참조하십시오. 따라서 ClickHouse의 String은 구현 측면에서 Snowflake의 Binary 유형에 더 가깝습니다. SnowflakeClickHouse는 모두 “collation”을 지원하므로, 사용자가 문자열의 정렬 및 비교 방식을 재정의할 수 있습니다.

반정형 유형

Snowflake는 반정형 데이터를 위해 VARIANT, OBJECT, ARRAY 유형을 지원합니다. ClickHouse는 이에 대응하는 Variant, Object(현재는 네이티브 JSON 유형으로 대체되어 더 이상 권장되지 않음)와 Array 유형을 제공합니다. 또한 ClickHouse에는 JSON 유형이 있으며, 이 유형은 현재 더 이상 권장되지 않는 Object('json') 유형을 대체하고 다른 네이티브 JSON 유형과 비교했을 때도 특히 높은 성능과 뛰어난 저장 효율을 제공합니다. ClickHouse는 또한 이름이 있는 Tuples와 Tuples의 배열을 Nested 유형으로 지원하여, 중첩 구조를 명시적으로 매핑할 수 있게 합니다. 이를 통해 Snowflake와 달리 계층 전체에 걸쳐 코덱과 유형 최적화를 적용할 수 있습니다. Snowflake는 외부 객체에 OBJECT, VARIANT, ARRAY 유형을 사용해야 하며, 명시적인 내부 타이핑을 허용하지 않습니다. 이러한 내부 타이핑은 또한 ClickHouse에서 중첩된 숫자형에 대한 쿼리를 단순화하며, CAST가 필요 없고 인덱스 정의에도 사용할 수 있습니다. ClickHouse에서는 코덱과 최적화된 유형을 하위 구조에도 적용할 수 있습니다. 그에 따라 중첩 구조를 사용하더라도 압축 효율이 평탄화된 데이터와 비교해도 매우 우수한 수준으로 유지된다는 추가 이점이 있습니다. 반면, 하위 구조에 특정 유형을 적용할 수 없기 때문에 Snowflake는 최적의 압축을 위해 데이터를 평탄화할 것을 권장합니다. 또한 Snowflake는 이러한 데이터 유형에 대해 크기 제한도 적용합니다.

자료형 참고

SnowflakeClickHouse비고
NUMBERDecimalClickHouse는 Snowflake보다 2배 더 높은 정밀도와 scale을 지원합니다. 즉, 76자리 대 38자리입니다.
FLOAT, FLOAT4, FLOAT8Float32, Float64Snowflake의 모든 부동소수점 타입은 64비트입니다.
VARCHARString
BINARYString
BOOLEANBool
DATEDate, Date32Snowflake의 DATE는 ClickHouse보다 더 넓은 날짜 범위를 제공합니다. 예를 들어 Date32의 최소값은 1900-01-01이고 Date의 최소값은 1970-01-01입니다. ClickHouse의 Date는 더 비용 효율적인 2바이트 저장 공간을 제공합니다.
TIME(N)직접적으로 대응되는 타입은 없으며 DateTimeDateTime64(N)로 표현할 수 있습니다.DateTime64에도 동일한 정밀도 개념이 적용됩니다.
TIMESTAMP - TIMESTAMP_LTZ, TIMESTAMP_NTZ, TIMESTAMP_TZDateTimeDateTime64DateTimeDateTime64에서는 컬럼에 TZ 매개변수를 선택적으로 지정할 수 있습니다. 지정하지 않으면 서버의 시간대가 사용됩니다. 또한 클라이언트에서는 --use_client_time_zone 매개변수도 사용할 수 있습니다.
VARIANTJSON, Tuple, NestedClickHouse에서 JSON 타입은 실험적입니다. 이 타입은 삽입 시점에 컬럼 타입을 추론합니다. 대안으로 Tuple, Nested, Array를 사용해 타입을 명시한 구조를 만들 수도 있습니다.
OBJECTTuple, Map, JSONOBJECTMap은 모두 키가 String인 ClickHouse의 JSON 유형과 유사합니다. ClickHouse에서는 값의 유형이 일관되고 엄격하게 지정되어야 하지만, Snowflake는 VARIANT를 사용합니다. 즉, 서로 다른 키의 값이 서로 다른 유형일 수 있습니다. ClickHouse에서 이것이 필요하다면 Tuple을 사용해 계층 구조를 명시적으로 정의하거나 JSON 유형을 사용하십시오.
ARRAYArray, NestedSnowflake의 ARRAY는 요소에 상위 타입인 VARIANT를 사용합니다. 반면 ClickHouse에서는 이들이 강한 타입으로 지정됩니다.
GEOGRAPHYPoint, Ring, Polygon, MultiPolygonSnowflake는 좌표계(WGS 84)를 강제하지만, ClickHouse는 쿼리 시점에 이를 적용합니다.
GEOMETRYPoint, Ring, Polygon, MultiPolygon
ClickHouse 유형설명
IPv4IPv6IP 전용 유형으로, Snowflake보다 더 효율적으로 저장할 수 있습니다.
FixedString고정 길이 바이트를 사용할 수 있어 해시에 유용합니다.
LowCardinality모든 유형에 딕셔너리 인코딩을 적용할 수 있습니다. 카디널리티가 100k 미만일 것으로 예상될 때 유용합니다.
Enum이름이 지정된 값을 8비트 또는 16비트 범위에서 효율적으로 인코딩할 수 있습니다.
UUIDUUID를 효율적으로 저장할 수 있습니다.
Array(Float32)벡터는 지원되는 거리 함수와 함께 Float32의 배열로 표현할 수 있습니다.
마지막으로, ClickHouse는 집계 함수의 중간 상태를 저장할 수 있는 고유한 기능을 제공합니다. 이 상태는 구현별로 다르지만, 집계 결과를 저장해 두었다가 나중에 조회할 수 있게 해줍니다(해당 머지 함수 사용). 일반적으로 이 기능은 materialized view를 통해 사용되며, 아래 예시와 같이 삽입된 데이터에 대한 쿼리의 증분 결과를 저장하여 적은 저장 비용으로 특정 쿼리의 성능을 개선할 수 있습니다 (자세한 내용은 여기 참조).
마지막 수정일 2026년 6월 10일