스키마와 테이블 형태

스키마와 테이블 형태 (Schema and Table Shape)

Pinot 스키마 설계, 테이블 형태, null 처리, 그리고 쿼리와 수집 동작을 구동하는 스키마 필드를 이해하는 페이지예요.

출처: Schema and Table Shape

본문

Pinot 스키마는 테이블에 존재하는 칼럼과 Pinot가 그 칼럼을 어떻게 다뤄야 하는지 정의해요. 중요한 것은 칼럼 목록뿐 아니라 테이블의 형태예요: 어떤 필드가 dimension, metric, 시간 필드인지, null이 어떻게 동작하는지, 테이블이 오프라인/실시간/하이브리드 수집 중 어느 것에 맞춰 빌드되었는지.

Pinot는 스키마와 테이블 메타데이터를 별도로 저장하지만, 둘은 함께 설계해야 해요. 스키마를 실제로 쿼리하는 데이터와 일치할 만큼 좁게 유지하고, 테이블 설정은 이 서술적 개요보다 레퍼런스 페이지에맡길 만큼 밀도 있게 유지하세요.

무엇을 설계할까요? (What to design)

스키마는 네 가지 실용적인 질문에 답해요:

어떤 칼럼이 존재하는가?
각 칼럼은 어떤 데이터 타입을 사용하는가?
어떤 칼럼이 dimension, metric, date-time 필드인가?
Pinot가 누락 값과 시간 의미를 어떻게 처리해야 하는가?

좋은 기본값 (Good defaults)

안정적이고 비즈니스 지향적인 칼럼 이름을 사용하세요. 소스 데이터와 일치하는 단순한 타입을 선호하세요. 스키마 변경은 추가적(additive)이고 의도적이어야 하므로, 쿼리 시점에 필요한 필드만 추가하세요.

시간 칼럼의 경우 보존과 하이브리드 테이블 경계 동작을 위해 기본 시간 필드 하나를 염두에 두세요. null 처리의 경우 테이블이 칼럼 기반 또는 테이블 기반 의미가 필요한지 일찍 결정하세요.

새 스키마에서는 시간 칼럼을 dateTimeFieldSpecs로만 모델링하세요. Pinot의 REST 스키마 제출 경로는 이제 deprecated TimeFieldSpec(fieldType=TIME)을 거부하고 DateTimeFieldSpec을 요구해요. 이미 클러스터에 저장된 레거시 스키마는 하위 호환을 위해 내부적으로 계속 로드될 수 있어요.

예시 스키마 (Example schema)

{
  "schemaName": "orders",
  "enableColumnBasedNullHandling": true,
  "dimensionFieldSpecs": [
    { "name": "orderId", "dataType": "STRING" },
    { "name": "customerId", "dataType": "STRING" },
    { "name": "region", "dataType": "STRING" }
  ],
  "metricFieldSpecs": [
    { "name": "amount", "dataType": "DOUBLE", "defaultNullValue": 0 }
  ],
  "dateTimeFieldSpecs": [
    {
      "name": "eventTime",
      "dataType": "LONG",
      "format": "EPOCH",
      "granularity": "1:DAYS"
    }
  ]
}

레퍼런스 페이지를 언제 사용하나요? (When to use the reference pages)

정확한 JSON 필드, 검증 규칙, 또는 date-time 필드 형식이 필요할 때는 스키마 레퍼런스를 사용하세요. 인덱싱, 보존, 또는 라우팅 설정이 필요할 때는 테이블 레퍼런스를 사용하세요.

이 페이지에서 다룬 내용 (What this page covered)

이 페이지는 수집과 쿼리 동작을 형성하는 Pinot 스키마 설계 부분을 다뤘어요.

다음 단계 (Next step)

하나의 쿼리 이름이 여러 물리 테이블로 라우팅되어야 한다면 논리 테이블을 읽으세요.

스키마와 테이블 형태