--- title: レイク description: 同期したデータの構成、行の更新方法、削除されたデータが黙って消えない理由を確認します。 species: concept --- # レイク Supernova が同期するデータは、すべて組織のレイクに集まります。Stripe、HubSpot、本番の Postgres など、接続したすべてのソースを 1 つのインターフェースでクエリできます。データはオープンな列指向形式で保存されるため、3 つの SaaS ツールを結合するクエリも、1 つのテーブルに対するクエリと同様に扱えます。このページでは、レイクの基本となる少数のルールを説明します。他のすべてのページが前提とする内容なので、10 分ほどかけて確認してください。 ## テーブルと名前 各ソースは、ソース名を付けた独自のスキーマに同期されます。テーブルの完全な名前は、`titan..` です。 ```sql fragment select * from titan.stripe.charges select * from titan.hubspot.deals select * from titan.postgres.orders ``` 固定スキーマのソース（Stripe、Zendesk、Shopify）は、常に同じテーブルを生成します。スキーマを検出するソース（Postgres、Salesforce、Airtable）は、アカウント内にあるものを生成します。たとえば Airtable は、各ベースを `airtable_` という名前の独自のスキーマに同期します。ソース API での呼び方にかかわらず、列名はすべて小文字の `snake_case` です。 ## システム列 同期されたすべてのテーブルに、Supernova が管理する 2 つの列があります。 | 列 | 型 | 意味 | |---|---|---| | `_synced_at` | timestamp | この行がレイク内で最後に変更された日時 | | `_deleted` | boolean | 行がソースに存在しなくなったことを示す | 特に理解しておきたいのは `_deleted` です。Stripe で決済が削除されたり、HubSpot で取引がマージによってなくなったりしても、レイクは行を削除せず、印を付けます。履歴は保たれ、クエリで明示的に除外します。 ```sql fragment select count(*) from titan.hubspot.deals where not _deleted ``` 現在の状態を集計、合計、結合する場合は、`not _deleted` で絞り込んでください。意図的に履歴を見る場合は、このフィルターを省略します。そのために履歴を保持しています。 ## 行の変更方法 同期は増分方式です。各実行で前回以降の変更を取得し、主キーでマージして、各行の最新バージョンを保持します。これにより、次の 2 つの性質があります。 - **同期が途中で中断されても問題はありません。** 次の実行は、最後の チェックポイントから再開します。キーでマージするため、行が重複することはありません。 - **削除の検出方法はソースによって異なります。** 削除を増分で通知する API もあれば、 全件取得したときにしか削除がわからない API もあります。後者のコネクターは、なくなったレコードを見つけるため、定期的にすべてを読み直します。各コネクターのページには、ソースの制約により必要となる方法を記載しています。 ## スナップショット 同期はアトミックにコミットされます。クエリは常に、テーブルの一貫した 1 つのスナップショットを読み取ります。クエリと同期が同時に動作していても、書き込み途中の同期を読むことはありません。新しいデータは、同期のコミット時に一斉に参照可能になります。 レイクは現在の状態だけでなく、最近のスナップショットも保持します（デフォルトは 30 日）。これにより、低いコストでアトミック性を実現し、中断された処理を安全に破棄できます。 ## できること - パイプラインを構築せずに、**ソースをまたいで結合**できます。取引段階別の売上は、 `titan.stripe.charges` と `titan.hubspot.deals` を 1 回結合するだけで得られます。 - **スキーマの変更は、処理を壊すのではなく、見える形で現れます。** ソースに列が追加されると、 レイクにも追加されます。**スキーマの変更** フィードには、何がいつ変わったかが表示されます。 - **オープンな形式。** データは、標準的な列指向ファイルと、標準的な テーブルのメタデータとして保存されます。Supernova に依存した独自のバイナリ形式ではありません。 次の[モデルの作成](/docs/models/authoring)では、これらのテーブルに対するクエリを、自分のテーブルに変換します。