데이터 소비자의 사용 사례를 충족하려면 데이터 메시에서 데이터 제품을 신중하게 설계하고 빌드해야 합니다. 데이터 제품의 설계를 시작하면서 데이터 소비자가 제품을 사용하는 방법과 해당 제품이 소비자에게 노출되는 방식을 정의합니다. 데이터 메시의 데이터 제품은 데이터 스토어 (예: 도메인 데이터 웨어하우스 또는 데이터 레이크) 위에 구축됩니다. 데이터 메시에서 데이터 제품을 만들 때는 프로세스 전반에서 몇 가지 요소를 고려하는 것이 좋습니다. 이 문서에서는 이러한 고려사항을 설명합니다.
이 문서는 Google Cloud에서 데이터 메시를 구현하는 방법을 설명하는 시리즈의 일부입니다. 여기에서는 사용자가 데이터 메시의 아키텍처 및 함수 및 Google Cloud를 사용하여 최신 분산 데이터 메시 빌드에 설명된 개념을 읽고 이에 익숙하다고 가정합니다.
이 시리즈에 포함된 내용은 다음과 같습니다.
- 데이터 메시의 아키텍처 및 함수
- 데이터 메시에 대한 셀프 서비스 데이터 플랫폼 디자인
- 데이터 메시에서 데이터 제품 빌드(이 문서)
- 데이터 메시에서 데이터 제품 탐색 및 사용
도메인 데이터 웨어하우스에서 데이터 제품을 만들 때 데이터 제작자는 이러한 제품에 대한 분석(소비) 인터페이스를 신중하게 설계하는 것이 좋습니다. 이러한 소비 인터페이스는 제품 지원 모델 및 제품 문서와 함께 데이터 품질 및 운영 매개변수에 대한 보증 집합입니다. 데이터 제작자와 여러 잠재적 데이터 소비자가 소비 프로세스와 애플리케이션을 변경해야 하기 때문에 소비 인터페이스를 변경하는 비용이 일반적으로 높습니다. 데이터 소비자가 데이터 제작자의 조직 단위와 분리되어 있을 가능성이 높기 때문에 변경사항을 조정하는 것이 어려울 수 있습니다.
다음 섹션에서는 도메인 웨어하우스를 만들고, 소비 인터페이스를 정의하고, 이러한 인터페이스를 데이터 소비자에게 노출할 때 고려해야 할 항목에 대한 배경 정보를 제공합니다.
도메인 데이터 웨어하우스 만들기
독립형 데이터 웨어하우스를 빌드하는 것과 데이터 제작자팀이 데이터 제품을 만드는 도메인 데이터 웨어하우스를 빌드하는 것은 근본적인 차이가 없습니다. 둘 사이의 유일한 실질적 차이는 후자가 소비 인터페이스를 통해 데이터 하위 집합을 노출한다는 것입니다.
많은 데이터 웨어하우스에서 운영 데이터 소스에서 수집된 원시 데이터는 보강 및 데이터 품질 확인(선별) 프로세스를 거칩니다. Dataplex 관리 데이터 레이크에서 선별된 데이터는 일반적으로 지정된 선별 영역에 저장됩니다. 선별이 완료되면 여러 유형의 인터페이스를 통해 데이터의 하위 집합을 도메인 외부에서 사용할 수 있도록 준비해야 합니다. 이러한 소비 인터페이스를 정의하기 위해 조직은 데이터 메시 접근 방식 채택이 비교적 새로운 도메인 팀에 일련의 도구를 제공해야 합니다. 이러한 도구를 사용해서 데이터 제작자가 셀프 서비스 방식으로 새로운 데이터 제품을 만들 수 있습니다. 권장사항은 셀프서비스 데이터 플랫폼 설계를 참조하세요.
또한 데이터 제품은 중앙에서 정의된 데이터 거버넌스 요구사항을 충족해야 합니다. 이러한 요구사항은 데이터 품질, 데이터 가용성, 수명 주기 관리에 영향을 줍니다. 이러한 요구사항은 데이터 제품에 대한 데이터 소비자의 신뢰를 구축하고 데이터 제품 사용을 장려하므로, 이러한 요구사항을 구현할 때 얻는 이점은 이를 지원하기 위해 노력할 가치가 있습니다.
소비 인터페이스 정의
데이터 제작자는 인터페이스를 한 두 개만 정의하는 대신 여러 유형의 인터페이스를 사용하는 것이 좋습니다. 데이터 분석의 각 인터페이스 유형에는 장단점이 있으며, 모든 면에서 뛰어난 단일 인터페이스 유형은 없습니다. 데이터 제작자는 각 인터페이스 유형의 적합성을 평가할 때 다음을 고려해야 합니다.
- 필요한 데이터 처리를 수행할 수 있는 역량
- 현재 및 이후의 데이터 소비자 사용 사례를 지원할 수 있는 확장성
- 데이터 소비자가 요구하는 성능
- 개발 및 유지보수 비용
- 인터페이스 실행 비용
- 조직에 사용되는 언어 및 도구 지원
- 스토리지와 컴퓨팅 구분 지원
예를 들어 비즈니스 요구사항에서 페타바이트 규모의 데이터 세트에 대한 분석 쿼리를 실행할 수 있어야 하는 경우, 유일한 실용적인 인터페이스는 BigQuery 뷰입니다. 하지만 요구사항에 따라 거의 실시간의 스트리밍 데이터를 제공해야 할 경우에는 Pub/Sub 기반 인터페이스가 더 적합합니다.
이러한 많은 인터페이스에서는 사용자가 기존 데이터를 복사 또는 복제할 필요가 없습니다. 또한 대부분의 경우 Google Cloud 분석 도구의 핵심 기능인 스토리지와 컴퓨팅을 분리할 수 있습니다. 이러한 인터페이스를 통해 노출되는 데이터의 소비자는 사용할 수 있는 컴퓨팅 리소스를 사용해서 데이터를 처리합니다. 데이터 제작자가 추가적인 인프라 프로비저닝을 수행할 필요가 없습니다.
소비 인터페이스는 다양하게 존재합니다. 다음 인터페이스는 데이터 메시에서 가장 일반적으로 사용되며 다음 섹션에서 설명합니다.
이 문서에 표시된 인터페이스 목록은 일부일 뿐입니다. 소비 인터페이스에 사용할 수 있는 다른 옵션도 있습니다(예: Analytics Hub). 하지만 이러한 기타 인터페이스는 이 문서에서 다루지 않습니다.
승인된 뷰 및 함수
가능한 한 데이터 제품은 승인된 뷰 및 승인된 함수(테이블 값 함수 포함)를 통해 노출되어야 합니다. 승인된 데이터 세트는 여러 뷰를 자동으로 승인하는 편리한 방법을 제공합니다. 승인된 뷰를 사용하면 기본 테이블에 직접 액세스할 수 없으며 이러한 뷰를 사용하는 소비자에게 영향을 주지 않고 기본 테이블과 쿼리를 최적화할 수 있습니다. 이 인터페이스의 소비자는 SQL을 사용해서 데이터를 쿼리합니다. 다음 다이어그램은 승인된 데이터 세트를 소비 인터페이스로 사용하는 방법을 보여줍니다.
승인된 데이터 세트 및 뷰를 사용하면 인터페이스 버전을 쉽게 관리할 수 있습니다. 다음 다이어그램에 표시된 것처럼 데이터 제작자가 사용할 수 있는 기본적인 버전 관리 방법은 두 가지입니다.
이러한 방법을 요약하면 다음과 같습니다.
- 데이터 세트 버전 관리: 이 방법에서는 데이터 세트 이름을 버전으로 관리합니다.
데이터 세트 내부에서 뷰와 함수를 버전 관리하지 않습니다. 뷰와 함수는 버전에 관계없이 이름을 동일하게 유지합니다. 예를 들어 영업 데이터 세트의 첫 번째 버전은 두 개의 뷰
catalog및orders를 사용하여sales_v1이라는 데이터 세트에 정의됩니다. 두 번째 버전에서 영업 데이터 세트는 이름이sales_v2로 바뀌었고 데이터 세트의 모든 이전 뷰는 이전 이름으로 유지되었지만 새 스키마를 포함합니다. 두 번째 버전의 데이터 세트에 새 뷰가 추가되거나 이전 뷰가 삭제될 수 있습니다. - 뷰 버전 관리: 이 방식에서는 데이터 세트 자체 대신 데이터 세트 내의 뷰 버전을 관리합니다. 예를 들어 영업 데이터 세트는 버전에 관계없이
sales이름이 유지됩니다. 하지만 데이터 세트 내의 뷰 이름은 각 새 버전의 뷰를 반영하도록 변경됩니다(예:catalog_v1,catalog_v2,orders_v1,orders_v2,orders_v3).
조직에 가장 적합한 버전 관리 방법은 조직 정책에 따라 그리고 기본 데이터가 업데이트될 때 얼마나 많은 뷰가 구식으로 전환되는지에 따라 달라집니다. 데이터 세트의 버전 관리는 주요 제품에 업데이트가 필요하고 대부분의 뷰를 변경해야 하는 경우에 가장 적합합니다. 뷰 버전 관리를 사용하면 서로 다른 데이터 세트에서 이름이 동일한 이름의 뷰가 더 적어지지만 데이터 세트 간에 조인이 올바르게 작동하는지 확인하는 방법과 같은 모호성을 초래할 수 있습니다. 하이브리드 접근 방법은 좋은 해결책일 수 있습니다. 하이브리드 방식에서는 단일 데이터 세트 내에서 호환 가능한 스키마 변경이 허용되고, 호환되지 않는 변경사항에는 새로운 데이터 세트가 필요합니다.
BigLake 테이블 고려사항
승인된 뷰는 BigQuery 테이블은 물론 BigLake 테이블에서도 만들 수 있습니다. 소비자는 BigLake 테이블을 통해 BigQuery SQL 인터페이스를 사용해서 Cloud Storage에 저장된 데이터를 쿼리할 수 있습니다. BigLake 테이블은 데이터 소비자에게 기본 Cloud Storage 버킷에 대한 읽기 권한을 제공할 필요 없이 미세 조정된 액세스 제어를 지원합니다.
데이터 제작자는 BigLake 테이블에 대해 다음을 고려해야 합니다.
- 파일 형식 및 데이터 레이아웃의 설계는 쿼리 성능에 영향을 줍니다. Parquet 또는 ORC와 같은 열 기반 형식은 일반적으로 JSON 또는 CSV 형식보다 분석 쿼리에 대해 훨씬 더 효과적입니다.
- Hive 파티션을 나눈 레이아웃을 사용하면 파티션을 프루닝하고 파티션 나누기 열을 사용하는 쿼리 속도를 높일 수 있습니다.
- 파일 수와 파일 크기에 대해 선호되는 쿼리 성능도 설계 단계에서 고려해야 합니다.
BigLake 테이블을 사용하는 쿼리가 인터페이스의 서비스수준계약(SLA) 요구사항을 충족하지 않고 조정할 수 없는 경우 다음 작업을 수행하는 것이 좋습니다.
- 데이터 소비자에게 노출되어야 하는 데이터의 경우 BigQuery 스토리지로 해당 데이터를 변환합니다.
- BigQuery 테이블을 사용하도록 승인된 뷰를 재정의합니다.
일반적으로 이 방법은 데이터 소비자 중단을 일으키거나 쿼리 변경이 요구되지 않습니다. BigQuery 스토리지의 쿼리는 BigLake 테이블에서 불가능한 기법을 사용하여 최적화할 수 있습니다. 예를 들어 BigQuery 스토리지에서 소비자는 기본 테이블과 파티셔닝 및 클러스터링이 다른 구체화된 뷰를 쿼리할 수 있으며 BigQuery BI Engine을 사용할 수 있습니다.
Direct Read API
일반적으로는 데이터 제작자가 데이터 소비자에게 기본 테이블에 대해 직접 읽기 액세스 권한을 부여하지 않는 것이 좋지만, 경우에 따라 성능 및 비용과 같은 이유로 그러한 액세스를 허용하는 것이 실용적일 수 있습니다. 이러한 경우에는 테이블 스키마가 안정적이 되도록 추가적인 주의가 필요합니다.
일반적인 웨어하우스의 데이터에 직접 액세스하는 방법에는 두 가지가 있습니다. 데이터 제작자는 BigQuery Storage Read API 또는 Cloud Storage JSON이나 XML API를 사용할 수 있습니다. 다음 다이어그램은 이러한 API를 사용하는 두 가지 소비자 예시를 보여줍니다. 하나는 머신러닝(ML) 사용 사례이고 다른 하나는 데이터 처리 작업입니다.
직접 읽기 인터페이스의 버전 관리는 복잡합니다. 일반적으로 데이터 제작자는 서로 다른 스키마를 사용하여 다른 테이블을 만들어야 합니다. 또한 지원 중단된 버전의 모든 데이터 소비자가 새 버전으로 마이그레이션할 때까지 두 가지 버전의 테이블을 유지해야 합니다. 소비자가 테이블을 다시 빌드하고 새 스키마로 전환할 때 생기는 중단을 용인할 수 있다면 데이터 중복을 피할 수 있습니다. 스키마 변경사항이 이전 버전과 호환되는 경우에는 기본 테이블 마이그레이션을 피할 수 있습니다. 예를 들어 새 열이 추가되고 이러한 열의 데이터가 모든 행에 대해 백필되는 경우에만 기본 테이블을 마이그레이션할 필요가 없습니다.
다음은 Storage Read API 및 Cloud Storage API 사이의 차이점을 요약해서 보여줍니다. 일반적으로 가능한 경우에는 데이터 제작자가 분석 애플리케이션을 위해 BigQuery API를 사용하는 것이 좋습니다.
Storage Read API: Storage Read API를 사용하여 BigQuery 테이블의 데이터를 읽고 BigLake 테이블을 읽을 수 있습니다. 이 API는 필터링 및 미세 조정된 액세스 제어를 지원하며, 안정적인 데이터 분석 또는 ML 소비자를 위한 올바른 옵션일 수 있습니다.
Cloud Storage API: 데이터 제작자가 특정 Cloud Storage 버킷을 데이터 소비자와 직접 공유해야 할 수 있습니다. 예를 들어 데이터 제작자는 어떤 이유로든 데이터 소비자가 SQL 인터페이스를 사용할 수 없거나 버킷에 Storage Read API가 지원하지 않는 데이터 형식이 있는 경우 버킷을 공유할 수 있습니다.
일반적으로는 직접 액세스의 경우 필터링 및 미세 조정된 액세스 제어를 허용하지 않기 때문에 데이터 제작자가 스토리지 API를 통해 직접 액세스를 허용하지 않는 것이 좋습니다. 그러나 안정적인 소형(기가바이트) 데이터 세트에는 직접 액세스 방식도 실행 가능한 선택일수 있습니다.
버킷에 대해 Pub/Sub 액세스를 허용하면 데이터 소비자가 자신의 프로젝트에 데이터를 복사하고 여기에서 데이터를 쉽게 처리할 수 있습니다. 가능하면 데이터 복사를 사용하지 않는 것이 좋습니다. 데이터 복사본이 여러 개 있으면 스토리지 비용이 늘어나고 유지보수 및 계보 추적 오버헤드가 추가됩니다.
스트림 데이터
도메인은 스트리밍 데이터를 Pub/Sub 주제에 게시하여 데이터를 노출할 수 있습니다. 데이터를 사용하려는 구독자는 이 주제에 게시된 메시지를 소비하는 구독을 만듭니다. 각 구독자는 데이터를 독립적으로 수신하고 소비합니다. 다음 다이어그램은 이러한 데이터 스트림의 예시를 보여줍니다.
다이어그램에서 수집 파이프라인은 원시 이벤트를 읽고 보강 (선별)한 후 이 선별된 데이터를 분석 데이터 스토어(BigQuery 기본 테이블)에 저장합니다. 동시에 파이프라인이 보강된 이벤트를 전용 주제에 게시합니다. 이 주제는 여러 구독자가 사용하며, 각 구독자는 관련된 이벤트만 가져오기 위해 이러한 이벤트를 필터링할 수 있습니다. 또한 파이프라인은 다른 데이터 소비자가 처리할 자체 주제에 대한 이벤트 통계를 집계하고 게시합니다.
다음은 Pub/Sub 구독의 사용 사례 예시입니다.
- 특정 고객 주문의 데이터와 함께 전체 고객 프로필 정보를 제공하는 것과 같은 보강된 이벤트
- 이전 15분 동안 총 주문 통계와 같은 실시간에 가까운 집계 알림
- 이전 일자의 비슷한 기간과 비교해서 주문 볼륨이 20% 하락한 경우의 알림 생성과 같은 비즈니스 수준 알림
- 특정 주문 변경 상태와 같은 데이터 변경 알림 (변경 데이터 캡처 알림과 개념 유사)
데이터 제작자가 Pub/Sub 메시지에 사용하는 데이터 형식은 이러한 메시지가 처리되는 방식 및 비용에 영향을 줍니다. 데이터 메시 아키텍처에서 스트림 볼륨이 많을 때는 Avro 또는 Protobuf 형식이 적합한 옵션입니다. 데이터 제작자가 이러한 형식을 사용할 경우 Pub/Sub 주제에 스키마를 할당할 수 있습니다. 스키마를 사용하면 소비자가 올바르게 구성된 메시지를 수신하는 데 도움이 됩니다.
스트리밍 데이터 구조는 계속해서 변경될 수 있기 때문에 이러한 인터페이스의 버전 관리를 위해서는 데이터 제작자와 데이터 소비자 간의 조정이 필요합니다. 데이터 제작자가 선택할 수 있는 몇 가지 일반적인 방법은 다음과 같습니다.
- 메시지 구조가 변경될 때마다 새 주제가 생성됩니다. 이 주제에는 명시적인 Pub/Sub 스키마가 포함된 경우가 많습니다. 새 인터페이스가 필요한 데이터 소비자는 새 데이터를 사용할 수 있습니다. 메시지 버전은 주제 이름으로 암시됩니다(예:
click_events_v1). 메시지 형식이 강력하게 유형화됩니다. 동일한 주제에 속한 메시지 간에는 메시지 형식 차이가 없습니다. 이 방법의 단점은 새 구독으로 전환할 수 없는 데이터 소비자가 있을 수 있다는 것입니다. 이 경우 데이터 제작자는 일정 기간 동안 모든 활성 주제에 이벤트를 계속 게시해야 하며, 주제를 구독하는 데이터 소비자는 메시지 흐름의 격차를 처리하거나 중복된 메시지를 삭제해야 합니다. - 데이터는 항상 동일한 주제에 게시됩니다. 하지만 메시지 구조는 변경될 수 있습니다. Pub/Sub 메시지 속성(페이로드와 별개)은 메시지 버전을 정의합니다. 예를 들면
v=1.0입니다. 이 접근 방법은 간격 또는 복제본을 처리할 필요가 없습니다. 하지만 모든 데이터 소비자가 새 유형의 메시지를 수신할 수 있도록 준비되어 있어야 합니다. 또한 데이터 제작자는 이 접근 방식에 대해 Pub/Sub 주제 스키마를 사용할 수 없습니다. - 하이브리드 방식. 메시지 스키마에 새 테이블에 사용할 수 있는 임의의 데이터 섹션이 포함될 수 있습니다. 이 접근 방식은 강력하게 유형화된 데이터와 빈번하고 복잡한 버전 변경 간에 적절한 균형을 제공할 수 있습니다.
Data Access API
데이터 제작자는 커스텀 API를 빌드하여 데이터 웨어하우스의 기본 테이블에 직접 액세스할 수 있습니다. 일반적으로 이러한 제작자는 이 커스텀 API를 REST 또는 gRPC API로 노출하고 Cloud Run 또는 Kubernetes 클러스터에 배포합니다. Apigee와 같은 API 게이트웨이는 트래픽 제한 또는 캐싱 레이어와 같은 다른 추가적인 기능을 제공할 수 있습니다. 이러한 기능은 Google Cloud 조직 외부의 소비자에게 데이터 액세스 API를 노출할 때 유용합니다. 데이터 액세스 API에 사용할 수 있는 후보는 단일 API에서 비교적 작은 결과를 반환하고 효과적으로 캐시될 수 있는 지연 시간에 민감하고 동시성이 높은 쿼리입니다.
데이터 액세스를 위한 이러한 커스텀 API 예시는 다음과 같을 수 있습니다.
- 테이블 또는 제품의 SLA 측정항목에 대한 조합된 뷰
- 특정 테이블의 상위 10개(잠재적으로 캐시된) 레코드
- 테이블 통계의 데이터 세트(총 행 수 또는 키 열 내의 데이터 분포)
애플리케이션 API 빌드와 관련해서 조직에 있는 모든 가이드라인 및 거버넌스는 데이터 제작자가 만든 커스텀 API에도 적용될 수 있습니다. 조직의 가이드라인 및 거버넌스에는 호스팅, 모니터링, 액세스 제어, 버전 관리와 같은 문제가 포함됩니다.
커스텀 API의 단점은 데이터 제작자가 커스텀 API 코딩 및 유지보수는 물론 이 인터페이스를 호스팅하는 데 필요한 추가 인프라도 책임져야 한다는 것입니다. 커스텀 데이터 액세스 API를 만들도록 결정하기 전에 데이터 제작자가 다른 옵션들을 조사하는 것이 좋습니다. 예를 들어 데이터 제작자는 BigQuery BI Engine을 사용해서 응답 지연 시간을 줄이고 동시성을 늘릴 수 있습니다.
Looker 블록
비즈니스 인텔리전스(BI) 도구에 널리 사용되는 Looker와 같은 제품의 경우 BI 도구별 위젯을 유지하는 것이 유용할 수 있습니다. 데이터 제작자팀은 도메인에 사용되는 기본 데이터 모델을 알고 있기 때문에 사전 빌드된 시각화 집합을 만들고 유지보수하기에 가장 이상적입니다.
Looker의 경우 이 시각화는 Looker 블록(사전 빌드된 LookML 데이터 모델) 집합일 수 있습니다. Looker 블록은 소비자가 호스팅하는 대시보드에 쉽게 사용될 수 있습니다.
ML 모델
데이터 도메인에서 작동하는 팀은 자신의 데이터에 대한 깊은 이해와 지식을 갖고 있기 때문에 도메인 데이터로 학습되는 ML 모델을 빌드하고 유지보수하는 데 가장 적합한 팀인 경우가 많습니다. 이러한 ML 모델은 다음을 포함하여 여러 다른 인터페이스를 통해 노출될 수 있습니다.
- BigQuery ML 모델은 전용 데이터 세트에 배포하고 BigQuery 일괄 예측을 위해 데이터 소비자와 공유할 수 있습니다.
- BigQuery ML 모델은 Vertex AI로 내보내 온라인 예측에 사용할 수 있습니다.
소비 인터페이스에 대한 데이터 위치 고려사항
데이터 제작자가 데이터 제품의 소비 인터페이스를 정의할 때 중요한 고려사항은 데이터 위치입니다. 일반적으로 비용을 최소화하기 위해서는 데이터가 저장된 곳과 동일한 리전에서 데이터를 처리해야 합니다. 이렇게 하면 리전 간 데이터 이그레스 요금이 방지됩니다. 이 접근 방식이 데이터 소비 지연 시간도 가장 짧습니다. 따라서 멀티 리전 BigQuery 위치에 저장된 데이터가 일반적으로 데이터 제품으로 노출하기에 가장 좋습니다.
그러나 성능상의 이유로 Cloud Storage에 저장되고 BigLake 테이블 또는 Direct Read API를 통해 노출된 데이터는 리전 버킷에 저장해야 합니다.
하나의 제품에 노출된 데이터가 하나의 리전에 있고 이를 다른 리전의 다른 도메인에 있는 데이터와 조인해야 하는 경우에는 데이터 소비자가 다음과 같은 제한사항을 고려해야 합니다.
- BigQuery SQL을 사용하는 리전 간 쿼리는 지원되지 않습니다. 데이터의 기본 소비 방법이 BigQuery SQL이면 쿼리의 모든 테이블이 동일한 위치에 있어야 합니다.
- BigQuery 정액제 약속은 리전별로 적용됩니다. 프로젝트가 한 리전에 있는 정액제 약정만 사용하지만 다른 리전의 데이터 제품을 쿼리하는 경우에는 주문형 가격 책정이 적용됩니다.
- 데이터 소비자는 Direct Read API를 사용하여 다른 리전에서 데이터를 읽을 수 있습니다. 하지만 리전 간 네트워크 이그레스 요금이 적용되고 큰 데이터를 전송할 때 데이터 소비자에게 지연 시간이 발생할 수 있습니다.
여러 리전에서 자주 액세스되는 데이터를 해당 리전에 복제하여 제품 소비자에게 발생하는 쿼리 비용과 지연 시간을 줄일 수 있습니다. 예를 들어 BigQuery 데이터 세트를 다른 리전으로 복사할 수 있습니다. 하지만 필요할 때만 데이터를 복사해야 합니다. 데이터를 복사할 때 데이터 제작자는 여러 리전에서 사용 가능한 제품 데이터의 하위 집합만 사용할 수 있도록 하는 것이 좋습니다. 이 방법은 복제 지연 시간 및 비용을 최소화하는 데 도움이 됩니다. 그러나 이렇게 하면 데이터 위치 리전을 명시적으로 호출하여 소비 인터페이스의 여러 버전을 제공해야 할 수 있습니다. 예를 들어 BigQuery 승인 뷰는 sales_eu_v1 및 sales_us_v1과 같은 이름을 통해 노출될 수 있습니다.
Pub/Sub 주제를 사용하는 데이터 스트림 인터페이스는 메시지가 저장된 곳과 동일한 리전이 아닌 다른 리전의 메시지를 소비하는 데 추가 복제 논리가 필요하지 않습니다. 하지만 이 경우에는 추가적인 리전 간 이그레스 요금이 적용됩니다.
데이터 소비자에게 소비 인터페이스 노출
이 섹션에서는 잠재 소비자가 소비 인터페이스를 검색할 수 있도록 하는 방법에 대해 설명합니다. Data Catalog는 조직이 데이터 탐색 및 메타데이터 관리 서비스를 제공하기 위해 사용할 수 있는 완전 관리형 서비스입니다. 데이터 제작자는 데이터 제품의 소비 인터페이스를 검색 가능하도록 만들고 제품 소비자가 셀프 서비스 방식으로 액세스할 수 있도록 적합한 메타데이터를 사용해서 주석을 추가해야 합니다.
다음 섹션에서는 각 인터페이스 유형이 Data Catalog 항목으로 정의되는 방법을 설명합니다.
BigQuery 기반 SQL 인터페이스
정규화된 테이블 이름 또는 테이블 스키마와 같은 기술적 메타데이터는 Storage Read API를 통해 제공되는 승인된 뷰, BigLake 뷰, BigQuery 테이블에 대해 자동으로 등록됩니다. 또한 데이터 제작자가 데이터 제품 문서에 데이터 소비자에게 도움이 되는 추가 정보를 제공하는 것이 좋습니다. 예를 들어 사용자가 항목에 대한 제품 문서를 찾을 수 있도록 데이터 제작자가 해당 항목에 적용된 태그 중 하나에 대한 URL을 추가할 수 있습니다. 제작자는 또한 다음을 제공할 수 있습니다.
- 쿼리 필터에서 사용해야 하는 클러스터링된 열 집합
- 유형이 필드 설명의 일부로 제공되지 않는 경우, 논리적 열거형 유형이 있는 필드의 열거형 값
- 지원되는 다른 테이블과의 조인
데이터 스트림
Pub/Sub 주제는 Data Catalog에 자동으로 등록됩니다. 하지만 데이터 제작자는 데이터 제품 문서에서 스키마를 설명해야 합니다.
Cloud Storage API
Data Catalog는 Cloud Storage 파일 항목과 해당 스키마의 정의를 지원합니다. 데이터 레이크 파일 세트가 Dataplex로 관리되는 경우 파일 세트가 Data Catalog에 자동으로 등록됩니다. Dataplex와 연결되지 않은 파일 세트는 다른 접근 방법을 사용해서 추가됩니다.
기타 인터페이스
커스텀 항목을 만들어서 Data Catalog의 기본 제공 지원이 없는 다른 인터페이스를 추가할 수 있습니다.
다음 단계
- 데이터 메시 아키텍처의 참조 구현 살펴보기
- BigQuery 자세히 알아보기
- Dataplex 자세히 알아보기
- 클라우드 아키텍처 센터에서 참조 아키텍처, 다이어그램, 권장사항 자세히 살펴보기