Financial warehouse и lakehouse¶

Раздел 05 · Редакционный стандарт

Тип материала — референсная архитектура. HYPOTHETICAL — схемы и операции. INFERENCE — инженерные рекомендации и критерии выбора. Внешние контракты ограничены источниками ниже.

Бизнес-задача¶

Объединить исторические финансовые факты с контролем lineage и исправлений.

Требования¶

Хранить immutable inputs, schemas, cut, transformation version и права. Изолировать тяжёлые backfills.

Поток данных и владение состоянием¶

flowchart LR
 A["OLTP and PSP"] --> B["Versioned landing"]
 B --> C["Validated facts"]
 C --> D["Warehouse marts"]
 D --> E["Consumers"]

Source owns original facts. Published dataset generation определяет воспроизводимую версию отчёта.

Транзакционные границы¶

Data files пишутся в staging. Manifest/pointer публикуется после validation, с compare-and-set или транзакционным каталожным commit.

Порядок и идемпотентность¶

Событие и revision устойчивы. Schema change и late corrections дают новую generation.

Нормальная последовательность¶

sequenceDiagram
 participant A as OLTP and PSP
 participant B as Versioned landing
 participant C as Validated facts
 participant D as Warehouse marts
 A->>B: Freeze source extracts
 B->>C: Validate staged facts
 C-->>B: Return validated data manifest
 B->>D: Publish warehouse generation

Отказ и восстановление¶

sequenceDiagram
 participant B as Versioned landing
 participant C as Validated facts
 participant E as Recovery operator
 B->>C: Only part of input lands
 Note over B,C: Outcome becomes uncertain
 E->>C: Repair staging partitions and verify all file hashes
 E->>B: Resume from verified boundary

Partial load не публиковать. Повторить детерминированные partitions, сверить hashes и восстановить pointer по audit.

Сверка¶

Проверять source keysets, totals по currency и attribution до journal.

Контракт lineage. Publication manifest связывает source snapshot IDs, object hashes, schema IDs, transformation commit, business policy и результаты сверки. Readers выбирают одну generation целиком. Для cut по нескольким системам зафиксируйте независимые watermarks и допущения о взаимной согласованности. Backfill в staging расходует отдельный ресурсный бюджет. При обнаружении плохой публикации смените указатель с сохранением прежнего evidence.

Наблюдаемость¶

Manifest coverage, scan cost, late input age и stale views.

Безопасность и применимость требований¶

Разделить raw PII и curated roles. Управлять удалением и копиями по policy.

Альтернативы и trade-offs¶

Warehouse снижает интеграционную сложность. Lakehouse позволяет хранить raw и менять compute при дополнительном governance.

Вопросы на собеседовании¶

Что доказывает table snapshot? Согласованный срез таблицы в её области. Cross-source cut согласуется отдельно.