- Зачем:
- STG-слой использовал legacy-имена (batch_id, load_dttm, src_created_at_ts),
тогда как ODS/DDS/DM уже работали с каноном (_load_id, _load_ts, event_ts).
Студент видел разные имена для одного понятия — это убрано.
- Что:
- переименованы колонки в 9 STG DDL: batch_id→_load_id, load_dttm→_load_ts,
src_created_at_ts→event_ts; добавлен NOT NULL для _load_id во всех таблицах.
- обновлены 9 STG Load, 9 STG DQ, 9 ODS Load, 9 ODS DQ (INSERT/SELECT/WHERE).
- обновлены DAG-файлы bookings_to_gp_stage.py и bookings_to_gp_ods.py
(встроенный SQL резолвера, комментарии; Python-идентификаторы не тронуты).
- обновлены тесты и ~15 документов (naming_conventions, PRD, db_schema,
design-docs, qa-plan, README, TESTING и др.).
- Проверка:
- grep -rn 'load_dttm\|src_created_at_ts' sql/ airflow/ tests/ — 0 совпадений.
- make test — 4 passed.
- e2e-etl: day1 прошёл полностью, day2 стартовал без ошибок.
39 lines
1.9 KiB
SQL
39 lines
1.9 KiB
SQL
-- DDL для слоя STG по таблице tickets.
|
|
-- Используется как из общего скрипта ddl_gp.sql (через \i),
|
|
-- так и может выполняться отдельно при изменении схемы.
|
|
|
|
-- Схема stg для сырого слоя DWH.
|
|
CREATE SCHEMA IF NOT EXISTS stg;
|
|
|
|
-- Внешняя таблица в схеме stg для чтения данных из bookings.tickets через PXF.
|
|
DROP EXTERNAL TABLE IF EXISTS stg.tickets_ext;
|
|
CREATE EXTERNAL TABLE stg.tickets_ext (
|
|
ticket_no TEXT,
|
|
book_ref TEXT,
|
|
passenger_id TEXT,
|
|
passenger_name TEXT,
|
|
outbound TEXT
|
|
)
|
|
LOCATION ('pxf://bookings.tickets?PROFILE=JDBC&SERVER=bookings-db')
|
|
FORMAT 'CUSTOM' (formatter='pxfwritable_import');
|
|
|
|
-- Внутренняя таблица stg.tickets — сырой слой, все бизнес-колонки как TEXT.
|
|
CREATE TABLE IF NOT EXISTS stg.tickets (
|
|
ticket_no TEXT NOT NULL,
|
|
book_ref TEXT NOT NULL,
|
|
passenger_id TEXT,
|
|
passenger_name TEXT,
|
|
outbound TEXT,
|
|
event_ts TIMESTAMP,
|
|
_load_ts TIMESTAMP NOT NULL DEFAULT now(),
|
|
_load_id TEXT NOT NULL
|
|
)
|
|
WITH (appendonly=true, orientation=row, compresstype=zstd, compresslevel=1)
|
|
-- Ключ распределения: book_ref
|
|
-- Обоснование: book_ref — это основной бизнес-ключ для бронирований.
|
|
-- Использование book_ref обеспечивает:
|
|
-- 1. Коллокацию данных tickets и bookings при JOIN по book_ref
|
|
-- 2. Равномерное распределение данных по сегментам (book_ref имеет высокую кардинальность)
|
|
-- 3. Оптимизацию запросов, которые фильтруют или группируют по book_ref
|
|
DISTRIBUTED BY (book_ref);
|