레이크#

Supernova가 동기화하는 모든 데이터는 조직의 레이크라는 한곳에 모입니다. Stripe, HubSpot, 운영 Postgres 등 연결된 모든 소스를 하나의 쿼리 인터페이스로 제공합니다. 데이터는 개방형 열 지향 형식으로 저장되므로 SaaS 도구 3개의 데이터를 조인하는 쿼리도 테이블 1개를 조회하는 쿼리와 다르지 않습니다. 이 페이지는 레이크의 몇 가지 기본 규칙을 설명합니다. 다른 모든 페이지가 이 규칙을 전제로 하므로 10분을 들여 읽을 만합니다.

테이블과 이름#

각 소스는 소스 이름을 딴 자체 스키마에 동기화됩니다. 모든 테이블의 전체 이름은 titan.<schema>.<table>입니다.

select * from titan.stripe.charges
select * from titan.hubspot.deals
select * from titan.postgres.orders

고정 스키마를 사용하는 소스(Stripe, Zendesk, Shopify)는 항상 같은 테이블을 생성합니다. 스키마를 검색하는 소스(Postgres, Salesforce, Airtable)는 계정에 있는 항목에 따라 테이블을 생성합니다. 예를 들어 Airtable은 각 베이스를 airtable_<base>라는 자체 스키마에 동기화합니다. 소스 API의 이름 규칙과 관계없이 열 이름은 항상 소문자 snake_case를 사용합니다.

시스템 열#

동기화된 모든 테이블에는 Supernova가 관리하는 열 2개가 있습니다.

_deleted의 의미는 꼭 이해해야 합니다. Stripe에서 결제가 삭제되거나 HubSpot에서 거래가 병합되어 사라져도 레이크는 행을 제거하지 않고 표시만 합니다. 이력이 그대로 유지되며, 쿼리에서 명시적으로 제외할 수 있습니다.

select count(*) from titan.hubspot.deals where not _deleted

현재 상태의 개수, 합계, 조인을 구하는 모든 쿼리에 not _deleted 필터를 사용하세요. 의도적으로 이력을 조회할 때는 필터를 생략합니다. 이력을 보관하는 이유가 바로 그것입니다.

행 변경 방식#

동기화는 증분 방식입니다. 매번 이전 실행 이후 바뀐 내용을 가져와 기본 키로 병합하여 각 행의 최신 버전을 유지합니다. 이에 따라 다음 2가지 특성이 생깁니다.

• 동기화가 중간에 중단되어도 문제없습니다. 다음 실행은 마지막 체크포인트에서 이어서 진행합니다. 키로 병합하므로 중복 행이 생기지 않습니다.

• 삭제 감지는 소스마다 다릅니다. 일부 API는 삭제를 증분으로 보고하지만, 전체 데이터를 가져와야 삭제를 알 수 있는 API도 있습니다. 그런 커넥터는 사라진 항목을 찾기 위해 주기적으로 전체 데이터를 다시 읽습니다. 각 커넥터 페이지는 소스가 요구하는 전략을 명시합니다.

스냅샷#

모든 동기화는 원자적으로 커밋됩니다. 쿼리는 항상 테이블의 일관된 스냅샷 1개를 읽습니다. 쿼리 실행 중에 동기화가 진행되어도 절반만 기록된 상태를 읽지 않습니다. 새 데이터는 동기화가 커밋될 때 한꺼번에 표시됩니다.

레이크는 현재 상태만 보관하지 않고 최근 스냅샷도 유지합니다. 기본 보존 기간은 30일입니다. 이를 통해 적은 비용으로 원자성을 보장하고 중단된 작업을 안전하게 폐기할 수 있습니다.

얻을 수 있는 이점#

• 별도의 파이프라인을 만들 필요 없이 소스 간 조인을 수행합니다. 거래 단계별 매출은 titan.stripe.charges와 titan.hubspot.deals를 한 번 조인하면 구할 수 있습니다.

• 스키마 변경은 오류 대신 알림으로 드러납니다. 소스에 열이 추가되면 레이크에도 나타납니다. 스키마 변경 피드에서 무엇이 언제 바뀌었는지 확인할 수 있습니다.

• 개방형 형식을 사용합니다. 데이터는 Supernova에 종속된 독점 바이너리 덩어리가 아니라 표준 테이블 메타데이터를 갖춘 표준 열 지향 파일로 저장됩니다.

다음 단계: 모델 작성에서 이 테이블을 조회하는 쿼리를 자신만의 테이블로 만들어 봅니다.