catstyle1101 / datafort

50 Top cities in the world weather parser

Тестовое задание DataFort.

https://docs.google.com/document/d/1JEkSYpoR43cNAt3sYsmh8OHSL11YHJSKRaR9HWUMhFY/edit

Реализовать коллектор погоды в 50 крупнейших городах для управления нагрузкой Дата-центров Под крупнейшими городами считались города, сортированные по количеству населения.

Запуск проекта

0. Скачать и установить Docker, docker compose https://www.docker.com/get-started/
1. Получить API ключ на сайте https://openweathermap.org/
2. Склонировать репозиторий себе на компьютер git clone [email protected]:catstyle1101/datafort.git
3. Выполнить команды

cd datafort
cp .env.example .env

4. Установить необходимые переменные окружения в файле .env

OPENWEATHER_API_KEY=<some_key_here>
PGUSER=<your_username>
POSTGRES_PASSWORD=<your_password>
POSTGRES_DB=<your_datbase_name>
DB_HOST=db
DB_PORT=5432

5. Запустить проект

docker compose up --build

6. Через одну минуту система соберет данные с 50 гордов мира и запишет их в базу данных Postgres

Использование и возможности

• Система 1 раз в час опрашивает сервер openweathermap и сохраняет погоду в БД. Первый запуск через 1 минуту после старта контейнеров
• Города также записаны в БД, система выбирает до 50 самых густонаселенных городов
• В случае, если городов в БД нет, то система заливает их из файла csv/cities.csv
• Запросы в БД и в API реализованы синхронно.

Использованный стек

• Python
• Pydantic
• SQLAlchemy
• Docker
• Celery
• PostgreSQL

Какие данные еще можно использовать при парсинге сайта:

1. Время заката/восхода (без солнца нагрузка на кондиционирование снижается)
2. Минимальная и максимальная температура (позволит спрогнозировать пиковую/минимальную мощность)
3. Давление (в динамике давление позволяет спрогнозировать ближайшую погоду)
4. Влажность (влияет на эффективность систем кондиционирования)

Дополнительные вопросы:

Описать почему выбрана такая структура БД?

В БД 2 сущности City и Weather c отношнением один-ко-многим. Таким образом можно легко получать данные по погоде по определенному городу Добавлять города в БД и затем делать запросы только в ТОП 50.

Почему выбрана та или иная технология?

SQLAlchemy - выбрана так как это очень популярная ORM, легко сменить БД, практически не меняя код самого модуля.

Какие технологические ограничения есть на данном этапе?

Запросы делаются синхронно, как в БД так и в API, можно увеличить скорость переписав запросы на асинхронном движке БД и Асинхронном движке HTTP запросов (например aiohttp) ограничения со стороны API (в частности - Calls per minute: 60 и 1,000,000 calls/month, а значит, когда городов станет больше 1388 (или мы будем опрашивать более 60 городов в минуту), нужно будет в любом случае покупать подписку иначе мы упремся в ограничения со стороны API).

datafort's Issues

Фидбэк

Привет!
Если не против, напишу сюда, так как разметка работает :)

Хорошо:

1. Есть логи
2. Есть обработка исключений
3. Неплохое ридми
4. ООП, с абстрактными классами (хоть и выглядит оверхедом для задачи).
5. Используешь паттерн репозиторий
6. Докстринги
7. Пайдентик
8. Используешь валидные классы исключений

Плохо:

1. Не обрабатываешь невалидные ответы API (4хх, 5хх ошибки)
2. Записываешь города поштучно, а значит держись сессию открытой дольше положенного (используй загрузку чанками)
3. Города в пайтон файле, изменение этого списка потребует пересборки контейнера, что не всегда удобно. В целом, нормально для первичного наполнения, но это было бы лучше сделать через API или через файл (csv, sql).

Можно лучше:

1. Использовать актуальную версию постгрес. SQLite не подходит для прода и с неё не всегда так просто перейти.
2. В качестве технологических ограничений и проблем можно было бы указать ограничения со стороны API (в частности - Calls per minute: 60 и 1,000,000 calls/month, а значит, когда городов станет больше 1388, нужно будет в любом случае покупать подписку иначе мы упремся в ограничения со стороны API).
3. Было бы неплохо добавить ретраи, загляни сюда
4. Селери, на мой взгляд тяжеловат для этой задачи. Можно было бы использовать APScheduler. Он полегче, и более прост в настройке.

Общее впечатление и рекомендации:

В проде у подобных коллекторов мы используем ABC, но по той причине, что у нас коллекторов много, а структуру нужно повторять для каждого. Поэтому в нашем случае использование этой штуки рационально. Когда мы говорим об одном коллекторе, но это выглядит как стрельба по воробьям из пушки).

Насколько я вижу по твоему репозиторию, с этим API ты уже работал, поэтому хотелось бы здесь увидеть именно работу с "узкими" местами (статус, коды, try/except), а также возможности развития сервиса.

К сожалению, я не готов пригласить тебя на интервью, надеюсь, что этот фидбэк поможет тебе с развитием и получением оффера :)