ЛСА | Лайфстайл айтишника

В ответ на пост Как правильный вопрос может уменьшить объём работы? Постановка задачи наталкивает нас, что должен быть некий UI для управления тасками. Мы можем пойти начать описывать свой интерфейс, свой back для него, авторизацию и множество чего ещё. При этом в задаче ничего не говорится про то, кто пользователь этого UI. Поэтому, задав вопрос: «Кто пользователь UI, кто будет запускать парсеры?», мы получаем ответ, что это администраторы продукта. Соответственно, им мы можем предложить какой-нибудь стандартный интерфейс, например Airflow закрывает большинство наших требований. Таким образом, мы только что сэкономили несколько месяцев работы команды с компетенциями: front dev, back dev, test, design. Как может выглядеть наш стек для данной задачи: airflow-scheduler — Планировщик отслеживает все задачи и DAG, а затем запускает экземпляры задач после выполнения их зависимостей. airflow-webserver — Веб-сервер с UI. UI ограничемся этим. airflow-worker — Воркер выполняет задачи, заданные планировщиком. Запускает парсеры. airflow-triggerer — Инициатор запускает цикл событий для отложенных задач. postgres — База метаданных для работы Airflow. redis — Выступает в качестве брокера для пересылки сообщений из планировщика в воркер. S3/minio — Для хранения сырых данных. docker — Каждый парсер заворачиваем в docker образ для возможности запуска из воркера airflow. В целевой картине воркеры могут через API kubernetes запускать поды с парсерами. Prometheus, Grafana — Для работы с метриками. OpenSearch, Fluentd и Kibana — Для работы с логами. Будем продолжать раскапывать этот кейс? Следующим шагом было бы разумно рассмотреть процесс поставки новых парсеров и отключение старых. ЛСА | Лайфстайл айтишника

В ответ на пост Парсерам быть или не быть? Давайте сегодня вместе разберём данный кейс. Начнём с общей HLD схемы. Основные внутренние компоненты: — Пользовательский интерфейс (UI): Предоставляет интерфейс для настройки и управления парсерами. — Планировщик задач (Scheduler): Отвечает за расписание и запуск парсеров. — Система выполнения парсеров (Executor): Запускает парсеры в контейнерах. — Хранилище данных (Data Storage): Сохраняет собранные текстовые данные. — Мониторинг и логирование (Monitoring & Logging): Отслеживает работу системы и парсеров. Внешние компоненты: — ML dev: Получают доступ к данным для дальнейшего анализа. — Администраторы: Через UI управляют работой парсеров — Web: ресурсы для парсинга Есть идеи, как можно улучшить схему на этом этапе? Какой стек будем выбирать для каждого из узлов? 🤔 ЛСА | Лайфстайл айтишника

Все мы писали парсеры.. Приступим к system design  Нужно спроектировать систему, которая будет периодически запускать парсеры на разных языках и сохранять данные, которые в дальнейшем будет забирать ML команда для дальнейшей обработки. Управление парсерами должно быть гибким, с возможностью настройки периодичности и ручного запуска. Обсуждаем решение в комментариях к посту, а рисовать можно в draw.io https://drive.google.com/file/d/1NXkfZltpnxNJprKgSPPhiw36lAMg5ioM/view?usp=sharing  (если возникнут трудности с подключением, пишите). Допущения: * Используемые языки для парсеров: Python, R, JS, PHP. * Один парсер может запускаться одновременно во множестве инстансов, чтобы обрабатывать в параллель множество страниц конкретного сайта. * Парсеры могут работать продолжительное время, вплоть до нескольких часов. * Общее количество парсеров не превышает 1000. * Парсеры собирают только текстовые данные. * Объём ежедневно собираемых данных — до 10Gb. * Данные хранятся в течение 3 лет. Какие технологии и подходы вы бы выбрали для реализации такой системы? Как вы организуете хранение данных, управление нагрузкой и мониторинг работы парсеров? Как обеспечить гибкость в настройке периодичности и ручного запуска? ЛСА | Лайфстайл айтишника

Секция system design Хотите прокачать свой навык прохождения system design или посмотреть, как это делают другие? Тогда читаем дальше😉 Если вы будете проходить собеседование на позицию senior dev и выше в какую-нибудь BigTech компанию, то с большой вероятностью у вас будет секция system design. Что такое system design? Это процесс проектирования системы, который включает в себя анализ требований, определение компонентов, их взаимодействие и выбор технологий для реализации. Саму секцию можно разделить на несколько этапов: сбор и анализ требований, разработка высокоуровневой архитектуры, детализация компонентов и взаимодействий, а также оценка рисков и возможностей масштабирования. Проходили подобные секции? Сегодня предлагаю потренировать свой скилл или даже научиться в прохождении данного части собеседования. Но формат будет у нас нестандартный, и вот как предлагаю провести его: 1. В 15:00 я выложу задачу отдельным постом. 2. В комментариях к посту я буду модерировать процесс и выступать стейкхолдером, а также направлять и помогать двигаться в нужном направлении. 3. Чем больше разных предложений и вопросов будет, тем интереснее будет получаться :) Поставьте реакцию, если готовы поучаствовать. От количества заинтересованных подберу более интересную или более простую задачу. ЛСА | Лайфстайл айтишника

Идемпотентность — любимый вопрос на собеседованиях В продолжение вчерашнего кейса, как в итоге решили проблему: Когда клиент нажимает "Оплатить", он отправляет уникальный код (например, ABC123 или UUID) вместе с запросом на сервер. 1. Первый запрос: Сервер видит новый код ABC123, выполняет оплату, сохраняет результат вместе с кодом. 2. Повторный запрос: Сервер видит тот же код ABC123, возвращает сохраненный результат, не проводя оплату повторно. Что получили: - Отсутствие двойных списаний: запросы с одним кодом обрабатываются только один раз. - Экономия ресурсов: сервер не дублирует операции и не стучится во внешние интеграции. - Удовлетворённость клиента: защита от случайных повторных оплат. Как часто вы или у вас спрашивают на собеседовании про идемпотентность? ЛСА | Лайфстайл айтишника