객체 스토리지 내보내기

1. 이 기능이 채우는 공백

지금까지 MousePlayer에서 데이터 웨어하우스로 가는 길은 Google로 향하는 하나뿐이었습니다. Snowflake, Redshift 또는 ClickHouse를 사용한다면 방법이 없었습니다. 세 도구 모두 객체 스토리지에서 문제없이 읽을 수 있는데도 말입니다.

따라서 브리지는 각 웨어하우스에 개별적으로 쓰는 대신 객체 스토리지에 씁니다. Snowflake, Redshift 및 ClickHouse는 S3에서 수집하고, BigQuery는 Google Cloud Storage에서 수집합니다. 한 번 내보내면 모두에게 전달할 수 있습니다.

대상	접근 방식
Amazon S3	Signature Version 4, 호스트에 버킷 포함
Cloudflare R2	계정 엔드포인트에 Signature Version 4 사용
Google Cloud Storage	HMAC 키로 S3 호환 API 사용
MinIO, Wasabi, Backblaze B2 등	지정한 엔드포인트에 Signature Version 4 사용
Azure Blob Storage	컨테이너 SAS 링크 사용. 당사 측에서 서명하지 않음

2. Azure가 다른 이유와 그 장점

Azure Blob은 Signature Version 4가 아닌 SharedKey로 서명합니다. 두 번째 서명 체계를 만들 수도 있었지만, 브리지는 대신 컨테이너 SAS 링크 를 받습니다. 자체 스토리지 계정에서 생성하며 서명이 이미 포함된 URL입니다.

당사는 코드가 줄어들고, 사용자는 당사에 맡겨야 할 신뢰가 줄어듭니다. 당사는 계정 키를 전혀 보지 않습니다. 전달하는 것은 직접 범위를 지정한 권한입니다. 컨테이너 하나로 제한되고, 선택한 만료일이 적용되며, 다른 항목을 건드리지 않고 언제든지 취소할 수 있습니다.

3. 목표당 객체 하나, 키는 날짜

객체 스토리지는 덧붙이기를 지원하지 않습니다. 일별 파일을 사용하면 매번 전체를 다시 써야 하며, 목표 두 개가 동시에 도착하면 서로 덮어쓰게 됩니다. 따라서 달성된 목표마다 별도의 객체를 만듭니다.

작은 객체가 많이 생기는 것이 대가입니다. 이를 관리할 수 있게 하는 것은 키 구조입니다.

prefix/YYYY/MM/DD/channel/session-goal.json

웨어하우스는 하루를 하나의 파티션으로 읽으며, 과거 데이터를 채울 때는 쿼리 대신 접두사를 스캔합니다. 날짜 대신 프로젝트별로 파티션을 나누려면 접두사에 채널 ID를 넣으세요.

각 객체는 JSON 한 줄입니다

의도적으로 들여쓰기를 하지 않으므로, 객체를 하나씩 열지 않고 접두사 전체를 NDJSON으로 읽을 수 있습니다. 타임스탬프, 프로젝트, 세션, 고객 ID, 목표, 가치, 통화 및 녹화를 재생하는 링크가 포함됩니다.

빈 값은 0이 아닌 null입니다

금전적 가치가 없는 목표는 다음 값을 기록합니다. null. 웨어하우스에서 0을 사용하면 실제로 존재하지 않았던 합계에 더해집니다. 내보내기에서도 “합의된 금액이 없음”과 “금액이 0임”의 차이를 유지합니다.

4. 403 응답이 나오면 먼저 읽어 보세요

거부된 S3 요청은 거의 아무것도 알려 주지 않습니다. 당사 로그의 오류 메시지가 S3보다 자세한 데는 이유가 있습니다. 리전이 서명에 포함되기 때문입니다. 리전이 틀려도 키가 틀려도 같은 403이 발생하므로, 가장 먼저 의심하는 키가 원인인 경우는 절반뿐입니다.

다음 세 가지를 순서대로 확인하세요.

• 리전은 버킷에 표시된 것과 정확히 같아야 합니다. R2와 Google Cloud Storage는 auto 를 받아들이고 검사하지 않지만, 다른 서비스는 검사합니다.
• 접두사 권한. 키의 범위가 mouseplayer/ 이면 mouseplayer-goals/ 에는 쓸 수 없습니다. 리소스 ARN에서는 끝의 슬래시가 중요합니다.
• 엔드포인트는 R2 및 S3 호환 스토리지에서 확인합니다. 호스트에서 https://를 제외하여 붙여 넣으세요. 어느 쪽이든 제거해 드리지만, 뒤에 경로가 붙으면 다른 버킷을 가리키게 됩니다.