Szybki start#

Po ukończeniu tej strony będziesz mieć źródło synchronizowane z jeziorem, zapytanie do bieżących danych i model przebudowywany co cztery godziny. Przykłady korzystają ze Skycrane, fikcyjnej firmy tworzącej oprogramowanie dla przewozów, która używa Stripe i HubSpot. Podczas pracy zastąp przykładowe wartości własnymi.

1. Połącz źródło#

Otwórz Aplikacje i wybierz Połącz aplikację. Wybierz potrzebne źródło — dla Skycrane jest to Stripe. Każde źródło prosi wyłącznie o niezbędne dane. Stripe potrzebuje jednego ograniczonego klucza API, który można utworzyć jako klucz tylko do odczytu w dashboardzie Stripe w ciągu minuty, więc jego wyciek nie pozwoli niczego zmienić na koncie. Strona każdego źródła opisuje wymagane dane uwierzytelniające; ten przewodnik korzysta ze Stripe.

Zapisz klucz, a pierwsza synchronizacja rozpocznie się automatycznie.

2. Obserwuj napływ danych#

Karta Historia synchronizacji pokazuje synchronizację podczas działania, tabela po tabeli. Po zakończeniu każda tabela znajduje się w jeziorze w schemacie nazwanym od źródła:

text

titan.stripe.charges
titan.stripe.customers
titan.stripe.subscriptions
titan.stripe.invoices
…

Od tej chwili źródło synchronizuje się ponownie co 4 godziny. Pobierane są tylko zmiany, a wiersze usunięte w źródle są oznaczane, a nie po cichu kasowane — służy do tego kolumna _deleted, którą zaraz zobaczysz. Karta Tabele kontroluje dokładnie, które tabele i kolumny są synchronizowane; domyślnie włączone jest wszystko.

3. Wykonaj pierwsze zapytanie#

Otwórz Zapytania i zadaj pierwsze pytanie obecne w każdym dashboardzie finansowym:

sql

select
  date_trunc('month', created_at) as month,
  round(sum(amount) / 100.0, 2) as gross_volume
from titan.stripe.charges
where not _deleted
group by month
order by month desc
limit 4

output

month       gross_volume
2026-08-01     291441.00
2026-07-01     338129.50
2026-06-01     331624.00
2026-05-01     319887.25

Zwróć uwagę na dwie rzeczy, które dotyczą każdej tabeli w jeziorze:

Stripe przechowuje amount w jednostkach podrzędnych — centach — dlatego dzielimy przez 100. Strona każdego konektora opisuje takie właściwości.
where not _deleted wyklucza wiersze usunięte w Stripe. Jezioro zachowuje je z oznaczeniem, aby historia nigdy nie kurczyła się po cichu. Kolumny systemowe opisuje strona Twoje jezioro.

Zapytania łączą źródła równie łatwo jak tabele w jednym źródle — otwarty lejek Skycrane i jego rozliczenia dzieli tylko jedno join:

sql

select
  property_dealstage as stage,
  count(*) as deals,
  round(sum(property_amount)) as pipeline_value
from titan.hubspot.deals
where not _deleted and not property_hs_is_closed
group by stage
order by pipeline_value desc

output

stage                    deals  pipeline_value
contractsent                 7        412000.0
decisionmakerboughtin       11        280500.0
qualifiedtobuy              19        224000.0
presentationscheduled        9        118750.0

4. Utwórz model#

Zapytanie, którego będziesz potrzebować jutro, powinno stać się modelem: instrukcją select w pliku, którą Supernova materializuje jako tabelę. Otwórz Pliki (albo sklonuj repozytorium danych przez Git) i utwórz models/monthly_revenue.sql:

sql

-- name: Monthly revenue
select
  date_trunc('month', created_at) as month,
  round(sum(amount) / 100.0, 2) as gross_volume,
  round(sum(amount_refunded) / 100.0, 2) as refunded
from titan.stripe.charges
where not _deleted
group by month

To wszystko. Podstawowa nazwa pliku jest nazwą tabeli, a modele są przebudowywane co 4 godziny w kolejności zależności — model może wykonywać select from innego modelu, a Supernova wyznacza kolejność z samego SQL. Odpytuj go jak każdą inną tabelę:

sql

select * from titan.models.monthly_revenue order by month desc

Strona Pisanie modeli opisuje dyrektywy nagłówka: schematy wyjściowe, aktualizacje przyrostowe według klucza, ręczną częstotliwość i kontrolę typów.

Co dalej#

Twoje jezioro — działanie tabel, usunięć i migawek. Dziesięć minut, dzięki którym reszta staje się zrozumiała.
Adnotacje typów — dodawanie typów dokładnie tam, gdzie SQL ich potrzebuje; moduł sprawdzający wykrywa zmianę przed dashboardami.
Limity — wszystkie ograniczenia w jednej szczerej tabeli.