다음을 통해 공유


반구조화된 데이터 모델링

이 문서에서는 조직에서 데이터를 사용하는 방법에 따라 반구조화된 데이터를 저장하는 패턴을 권장합니다. Azure Databricks는 반구조화, 중첩 및 복합 데이터 작업을 위한 함수, 네이티브 데이터 형식 및 쿼리 구문을 제공합니다.

다음 고려 사항은 사용해야 하는 패턴에 영향을 줍니다.

  • 데이터 원본의 필드 또는 형식이 자주 변경되는가요?
  • 데이터 원본에 포함된 총 고유 필드는 몇 개입니까?
  • 쓰기 또는 읽기를 위해 워크로드를 최적화해야 하나요?

Databricks는 다운스트림 쿼리를 위해 데이터를 델타 테이블로 저장하는 것이 좋습니다.

변형 사용

Databricks Runtime 15.3 이상에서는 이 형식을 사용하여 VARIANT 읽기 및 쓰기에 대해 JSON 문자열보다 뛰어난 최적화된 인코딩을 사용하여 반구조화된 JSON 데이터를 저장할 수 있습니다.

형식에는 VARIANT JSON 문자열과 유사한 애플리케이션이 있습니다. 일부 워크로드는 여전히 구조체, 맵 및 배열을 사용하는 이점을 누릴 수 있으며, 특히 최적화된 데이터 레이아웃 및 통계 수집의 이점을 누릴 수 있는 잘 알려진 스키마가 있는 데이터의 경우 특히 유용합니다.

자세한 내용은 다음 문서를 참조하세요.

JSON 문자열 사용

표준 JSON 서식을 사용하여 단일 문자열 열에 데이터를 저장한 다음, : 표기법을 사용하여 JSON의 필드를 쿼리할 수 있습니다.

많은 시스템에서 문자열 또는 바이트 인코딩 JSON 레코드로 레코드를 출력합니다. 이러한 레코드를 문자열로 수집하고 저장하면 처리 오버헤드가 매우 낮습니다. 이 함수를 to_json 사용하여 모든 데이터 구조체를 JSON 문자열로 변환할 수도 있습니다.

데이터를 JSON 문자열로 저장하도록 선택할 때 다음과 같은 장점과 약점을 고려합니다.

  • 모든 값은 형식 정보 없이 문자열로 저장됩니다.
  • JSON은 텍스트를 사용하여 나타낼 수 있는 모든 데이터 형식을 지원합니다.
  • JSON은 임의의 길이의 문자열을 지원합니다.
  • 단일 JSON 데이터 열에 나타낼 수 있는 필드 수에는 제한이 없습니다.
  • 데이터에는 테이블에 쓰기 전에 사전 처리가 필요하지 않습니다.
  • 다운스트림 워크로드의 데이터에 있는 형식 문제를 해결할 수 있습니다.
  • JSON은 모든 쿼리에 대해 전체 문자열을 구문 분석해야 하므로 읽기에서 최악의 성능을 제공합니다.

JSON 문자열은 레이크하우스 테이블로 원시 데이터를 가져오기 위한 뛰어난 유연성과 구현하기 쉬운 솔루션을 제공합니다. 많은 애플리케이션에 JSON 문자열을 사용하도록 선택할 수 있지만 워크로드의 가장 중요한 결과가 다운스트림 처리를 위해 데이터 원본의 완전하고 정확한 표현을 저장하는 경우에 특히 유용합니다. 일부 사용 사례에는 다음이 포함될 수 있습니다.

  • Kafka와 같은 큐 서비스에서 스트리밍 데이터를 수집합니다.
  • 응답 REST API 쿼리 기록
  • 팀에서 제어하지 않는 업스트림 데이터 원본의 원시 레코드를 저장합니다.

수집 논리가 유연하다고 가정하면 새 필드, 데이터 구조의 변경 또는 데이터 원본의 형식 변경이 발생하더라도 데이터를 JSON 문자열로 저장하는 것은 복원력이 있어야 합니다. 이러한 변경으로 인해 다운스트림 워크로드가 실패할 수 있지만 테이블에는 원본 데이터의 전체 기록이 포함되어 있으므로 데이터 원본으로 돌아가지 않고도 문제를 해결할 수 있습니다.

구조체 사용

구조체를 사용하여 반구조화된 데이터를 저장하고 데이터 원본의 중첩된 구조를 유지하면서 열의 모든 네이티브 기능을 사용하도록 설정할 수 있습니다.

Delta Lake는 다른 열과 동일한 구조체로 저장된 데이터를 처리합니다. 즉, 구조체와 열의 기능적 차이가 없습니다. Delta Lake에서 사용하는 Parquet 데이터 파일은 구조체의 각 필드에 대한 열을 만듭니다. 구조체 필드를 클러스터링 열 또는 분할 열로 사용할 수 있으며 데이터 건너뛰기 구조체에 대한 통계를 수집할 수 있습니다.

구조체는 일반적으로 모든 데이터 건너뛰기 최적화를 지원하고 개별 필드를 열로 저장하므로 읽기에서 최상의 성능을 제공합니다. 존재하는 열 수가 수백 개에 달하면 성능이 저하되기 시작할 수 있습니다.

구조체의 각 필드에는 열과 동일한 쓰기에 적용되는 데이터 형식이 있습니다. 따라서 구조체에는 데이터의 전체 사전 처리가 필요합니다. 이는 유효성이 검사된 데이터만 테이블에 커밋하려는 경우 도움이 될 수 있지만 업스트림 시스템에서 잘못된 형식의 레코드를 처리할 때 데이터가 삭제되거나 작업이 실패할 수 있습니다.

구조체는 데이터 형식을 발전시키는 것이든 새 필드를 추가하든 스키마 진화를 위한 JSON 스트림보다 덜 유연합니다.

맵 및 배열 사용

맵과 배열의 조합을 사용하여 Delta Lake에서 기본적으로 반구조화된 데이터 형식을 복제할 수 있습니다. 이러한 형식으로 정의된 필드에는 통계를 수집할 수 없지만 약 500개의 필드가 있는 반구조적 데이터 세트에 대해 읽기 및 쓰기 모두에서 균형 잡힌 성능을 제공합니다.

맵의 키와 값이 모두 입력되므로 데이터가 미리 처리되고 스키마가 쓰기에 적용됩니다.

쿼리를 가속화하기 위해 Databricks는 데이터를 별도의 열로 필터링하는 데 자주 사용되는 필드를 저장하는 것이 좋습니다.

데이터를 평면화해야 하나요?

JSON 또는 맵을 사용하여 데이터를 저장하는 경우 쿼리를 열로 필터링하는 데 자주 사용되는 필드를 저장하는 것이 좋습니다. JSON 문자열 또는 맵 내의 필드에는 통계 컬렉션, 분할 및 클러스터링을 사용할 수 없습니다. 구조체로 저장된 데이터에 대해서는 이 작업을 수행할 필요가 없습니다.

중첩된 데이터 작업에 대한 구문

중첩 데이터 작업에 대한 자세한 내용은 다음 리소스를 검토합니다.