Приём заказов: нужен ли слепку слой сырья #70
Assignees
ddmitry (Dmitry Dementiev)
Clear assignees
ddmitry (Dmitry Dementiev)
No Assignees
ddmitry
ddmitry
Notifications
Due Date
No due date set.
Blocks
#74 Место заказов в стартовом мире
ddmitry/clickstream-data-platform
Reference: ddmitry/clickstream-data-platform#70
Reference in New Issue
Block a user
Part of #69.
Вопрос
Как заказы попадают из топика
ordersв хранилище: через слой сырья, как события, или сразу вods.order_snapshot?Развилку мастер-спека называет нерешённой прямо (раздел 7): «Как принимаются заказы — развилка этапа 3, и она не решена». Событиям выбран приём байтами с разбором функциями (ADR 0005); заказам тот же способ идёт только вместе с ответом, нужен ли им слой сырья вообще — у них слепок, а не поток.
Что стоит на кону: нужен — и получаем двух чтецов на один топик, схему, которую ADR 0005 отверг; не нужен — и слои перестают быть единообразными, а вместе с этим уходит место, где видно «какая нода читала топик».
Учебная сторона: сравнение двух способов приёма записано в опорные точки раздела 12 мастер-спеки.
Резолюция обязана лечь так, чтобы читалась рядом с ADR 0005 — новым ADR или дополнением к нему: иначе выбор для заказов окажется в другом жанре документа, чем выбор для событий, и сравнить их будет негде.
Резолюция
Заказы принимаются пакетным забором: чтец топика байтовый (
RawBLOB), каку событий, но матвью к нему не привязана — сырьё забирает шаг, которым
управляет Airflow. Он вставляет прочитанное в
stg.orders_raw, разбирает втипизированный слепок и заменяет партицию дня в
ods.order_snapshot. Тот жедаг проигрывает модельный день генератором, поэтому переливается ровно то, что
он положил в топик.
Слой сырья заказам нужен. Без него
ods.order_snapshotповторил бы егороль — «как приехало», без дедупа, — а обещание идемпотентности из раздела 2
мастер-спеки повисло бы ни на чём: матвью партиций не заменяет, и удвоение
слепка при повторной заливке жило бы вечно, потому что у ODS, в отличие от
сырья, срока жизни нет. При пакетном шаге каждый слой отрабатывает своё.
Топик
orders— одна партиция, чтец — только наclickhouse-01, безON CLUSTER: у пулла один тянущий по определению, а у Airflow одноподключение, и оно к ноде 1.
Постановка тикета говорила про «двух чтецов на один топик» — этого выбора не
было ни в одной ветке: чтец на
ordersв любом случае один. Настоящаяразвилка оказалась о другом — о режиме приёма, поток против слепка.
Решение целиком, с доводами и отвергнутыми вариантами (типизированный чтец
прямо в ODS, матвью из сырья как у событий, типизированный чтец при пулле,
Distributedповерх Kafka, две партиции, сенсор дневного батча) —ADR 0008,
docs/adr/0008-order-ingestion.md.Что это поменяло за пределами тикета
топик» противопоставляла байтового чтеца типизированному — две формы одного
приёма. Теперь она про поток против слепка, push против pull: чтец в обоих
случаях байтовый, различает их режим. Пункт «Форма учебного сравнения двух
способов приёма» уходит из «Ещё не сформулировано» карты — он решён, а не
отложен.
сенсор ловил бы момент, которого не существует; раз генератор и переливка в
одном даге, ждать нечего по построению.
существует.
etl_pipelineостаётся за этапом 5.CONTEXT.mdзаведены«слепок», «окно изменяемости», «пакетный забор».
Сверено по документации
MCP Context7, 12 августа 2026: прямое чтение из Kafka-движка запрещено с 21.12
и открывается
stream_like_engine_allow_direct_select; при привязанной матвьюостаётся запрещённым — значит два способа приёма взаимоисключающи по
построению; офсеты прямое чтение по умолчанию не коммитит, нужна
kafka_commit_on_select; проDistributedповерх Kafka документация неговорит ничего. Что осталось замерить на стенде — в конце ADR 0008.