- Зачем: - ODS должен показывать сущность заказа, а не способ её доставки слепком. - Что: - физические таблицы и представление переведены на имена `order_*`. - SQL загрузки, DAG и документация приведены к тому же словарю. - Проверка: - `make config-test`, `make lint`. - `make clean && make up`, `make smoke`, `make check-clickhouse`, `make check-services`.
2.9 KiB
2.9 KiB
Что хранит опись
Резолюции развилок «Расхождения A–D и опоздания: механика, доли и что обещано» и «Места заказов в стартовом мире». Словарь описи — растяжка-хеш против опоры-счётчика — задан «Чем меряется генератор» в спеке генератора и термином «Опись мира» в CONTEXT.md.
Опись хранит только то, чего движение мира не меняет. Хеш кладём всегда, счётчик — только когда назван его читатель.
- У каждого отправленного слепка — своя строка с хешем байтов. Байты слепка не покрыты хешами дней ни при каком раскладе подпотоков — это второй артефакт мира. Побайтовое обещание («слепок переснимается и даёт те же байты») опись начинает сторожить.
- Счётчики классов расхождений — наблюдаемых, после приоритета, по итоговой судьбе заказов дня; единица счёта — заказ, и опись называет её словом. Сойтись с запросом менти они могут только на днях с закрытым окном: при N сыгранных днях таких N − 7 (день d закрывается слепком d + 6, а последний отправленный слепок несёт день N − 2). Читатель у них придёт этапом 4 — проверка сверки; не окажется читателя — та же бритва режет и их.
- Контрольные числа идентичности не заводятся вовсе: uniq известных пользователей и число двухкуковых пар растут, пока мир едет, — опоры из них не выходит; генератор сторожит хеш, транспорт — счёт событий.
- Опись описывает мир, а не доставку. Работа генератора кончается на
Kafka: дошли ли байты до
ods.order— вопрос стенда и его проверок. Поэтому счёта строк у слепка в описи нет; понадобится проверка приёма заказов — число заведётся вместе с ней.