レイク#

Supernova が同期するデータは、すべて組織のレイクに集まります。Stripe、HubSpot、本番の Postgres など、接続したすべてのソースを 1 つのインターフェースでクエリできます。データはオープンな列指向形式で保存されるため、3 つの SaaS ツールを結合するクエリも、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 を 1 回結合するだけで得られます。

• スキーマの変更は、処理を壊すのではなく、見える形で現れます。 ソースに列が追加されると、

レイクにも追加されます。スキーマの変更 フィードには、何がいつ変わったかが表示されます。

• オープンな形式。 データは、標準的な列指向ファイルと、標準的な

テーブルのメタデータとして保存されます。Supernova に依存した独自のバイナリ形式ではありません。

次のモデルの作成では、これらのテーブルに対するクエリを、自分のテーブルに変換します。