docs(docs): актуализировано ТЗ и потоки ingest
- Зачем: - убрать рассинхрон между кратким ТЗ, архитектурой и планом генератора - Что: - сокращен docs/DE-task.md до формата краткого ТЗ проекта - обновлены docs/ARCHITECTURE.md и README.md: bootstrap через kafka_load и steady-stream через generator-service - обновлен plans/generator_demo_stream_plan.md: режим steady-stream и тик-публикация - Проверка: - просмотрен git diff по измененным файлам - в коммит включены только мои документационные изменения
This commit is contained in:
Dmitry Dementiev
+30
-42
@@ -1,55 +1,43 @@
|
||||
**Дашборд для e-commerce кликстрима**
|
||||
# DE-task: краткое ТЗ проекта
|
||||
|
||||
Представьте, что вы работаете в e-commerce проекте. Бизнес-юнит в процессе обсуждения, закупать ли вам кликстрим логов посещения некоторого портала другого магазина. Для первичного анализа вам предоставили данные, чтобы оценить применимость и выводы, которые можно сделать из них.
|
||||
Дата актуализации: 14 февраля 2026.
|
||||
|
||||
Вам нужно подготовить данные для первичного анализа и собрать несколько графиков в дашборд. Финальный результат вашей работы — развернутая инфраструктура и дашборд с графиками на которых "бизнес" может сделать выводы о данных. Вам дали полный карт-бланш на тему того, как эти данные можно обработать.
|
||||
## Цель
|
||||
|
||||
## Вам нужно:
|
||||
Собрать учебный DE-стенд, который показывает полный путь данных:
|
||||
`Kafka -> ClickHouse (STG/ODS/DDS/DM) -> BI`, с устойчивой обработкой "грязных" данных и понятной наблюдаемостью.
|
||||
|
||||
* спроектировать хранилище в /PostgreSQL/Clickhouse/ со слоями и объектами, которые вы посчитаете нужными
|
||||
* написать все нужные расчёты и алгоритмы для создания витрин
|
||||
* реализовать расчёт с помощью какого-то регулярного процесса
|
||||
* сделать на основе этих данных дашборд который можно будет посмотреть в браузере
|
||||
## Что нужно сделать
|
||||
|
||||
### Какие инструменты выбрать
|
||||
- Развернуть стек в `docker compose`: Kafka, ClickHouse, Airflow, Superset, Prometheus, Grafana.
|
||||
- Организовать ingest в Kafka в двух режимах:
|
||||
- `bootstrap`: загрузка JSONL через Airflow DAG `kafka_load`;
|
||||
- `steady-stream`: автономный генератор, работающий независимо от потребителей.
|
||||
- Построить слои хранилища `STG -> ODS -> DDS -> DM` в ClickHouse.
|
||||
- Настроить регулярные трансформации в Airflow (`ddl_init`, `etl_pipeline`).
|
||||
- Подготовить витрины и дашборд для первичного анализа.
|
||||
|
||||
Пара вариантов:
|
||||
## Ключевые требования
|
||||
|
||||
* **Kafka + Clickhouse + Airflow + Superset/Power BI**
|
||||
* Postgresql + dagster + Grafana
|
||||
* dlt + duckdb + Airflow + [Panel](https://panel.holoviz.org/)
|
||||
* Clickhouse + Airflow + Redis + [Streamlit](https://streamlit.io/)
|
||||
* sqlitedb + скрипты питона + Flask + d3.js
|
||||
- "Грязные" записи не должны валить пайплайн: ошибки фиксируются в ODS/DQ-слое.
|
||||
- Генератор работает отдельно от потребителей и Airflow-триггеров.
|
||||
- Решение должно быть воспроизводимым и пригодным для учебной демонстрации.
|
||||
|
||||
Начните с маленького среза данных, чтобы ознакомиться, что за данные вам предоставляют:
|
||||
## Границы MVP
|
||||
|
||||
* browser_events.jsonl — данные с информацией о просмотрах браузера
|
||||
* device_events.jsonl — данные об устройствах, с которых пользователи пользовались сайтом
|
||||
* geo_events.jsonl — данные о локации пользователя
|
||||
* location_events.jsonl — вопреки названию, это данные не о локации пользователя, а непосредственно о положении пользователя на сайте и информации о том, откуда пользователь попал на страницу
|
||||
- Один простой режим генератора (`steady-stream`) без сложных сценариев.
|
||||
- Без production-гарантий уровня exactly-once.
|
||||
- Фокус на рабочем end-to-end контуре, а не на полной симуляции реального продакшена.
|
||||
|
||||
Смысл задачи на **своей ВМ** развернуть инструменты и загрузить данные в Kafka и из нее прогнать их в Clickhouse /другая DB по слоям.
|
||||
## Критерии готовности
|
||||
|
||||
В Airflow взять данные из таблиц и преобразовать, потом выгрузить в Clickhouse / другая DB в агрегированном формате под дашборд.
|
||||
1. Стенд стабильно запускается и работает несколько часов.
|
||||
2. Данные корректно проходят путь Kafka -> STG -> ODS -> DDS -> DM.
|
||||
3. Поток событий в Kafka идёт постепенно малыми порциями, без искусственного минутного burst.
|
||||
4. Есть базовый дашборд и метрики для разбора работы стенда.
|
||||
|
||||
Дашборд не оценивается, но будет плюсом, если получиться собрать удобный визуал.
|
||||
## Где детали реализации
|
||||
|
||||
Записать можно на видео и отправить контактному лицу или продемонстрировать на собеседовании
|
||||
|
||||
Можно использовать любые инструменты.
|
||||
|
||||
Данные могут быть(скорее всего) с ошибками и компания которая их предоставляем заранее об этом сообщила т.к. они не хотят делиться 100% качественными данными полноценно с продакшена.
|
||||
|
||||
### ИНФРАСТРУКТУРА
|
||||
|
||||
* инфраструктура клевая и работает = 18 баллов
|
||||
* инфраструктура работает, но есть баги = 12 баллов
|
||||
* инфраструктура почти есть, но не совсем = 6 баллов
|
||||
* инфраструктуры нет = 0 баллов
|
||||
|
||||
### ДАШБОРДЫ
|
||||
|
||||
* дашборды есть и удобные и работают = 12 баллов
|
||||
* дашборды работают, но неудобные = 8 баллов
|
||||
* дашборды почти работают = 4 балла
|
||||
* дашбордов нет = 0 баллов
|
||||
- Техническая архитектура: `docs/ARCHITECTURE.md`
|
||||
- План по генератору: `plans/generator_demo_stream_plan.md`
|
||||
- Эксплуатация и запуск: `docs/OPERATIONS.md`
|
||||
|
||||
Reference in New Issue
Block a user