BA & SA | 10000 Interview questions

Скидка 20% на Pampers Выберите в Любимой категории Купить #реклама market.yandex.ru О рекламодателе

☀Объяснение: Это типичный кейс, когда OLTP-таблица (оперативная) используется для OLAP-запросов (аналитика). Даже с правильными индексами агрегация сотен миллионов строк будет медленной. 1. Почему другие варианты не решают проблему? A (ещё один индекс) — индексы ускоряют фильтрацию и сортировку, но не агрегацию по огромному объёму данных. Агрегатный запрос всё равно будет читать все строки за месяц (~15 млн), даже по индексу. C (партиционирование) — улучшит удаление старых данных и может помочь с прунингом партиций, но сам агрегатный запрос всё равно будет читать все партиции за месяц. Ускорение будет, но не кардинальное. D (больше ресурсов) — временное решение, не решает проблему архитектурно. При росте данных проблема вернётся. 2. Что такое материализованное представление (MV)? Материализованное представление — это физическая таблица, которая хранит предварительно вычисленные результаты запроса. В отличие от обычного представления (VIEW), MV занимает место на диске и требует обновления. Создание MV для нашего отчёта: ```sql CREATE MATERIALIZED VIEW daily_events_report AS SELECT DATE(event_time) as event_date, event_type, COUNT(*) as events_count FROM events WHERE event_time >= CURRENT_DATE - INTERVAL '1 year' -- ограничим глубину GROUP BY event_date, event_type; ``` -- Добавляем индекс для быстрых выборок по дате CREATE INDEX idx_daily_events_date ON daily_events_report(event_date); 3. Как это ускоряет запрос? Вместо чтения и агрегации 500 млн строк, отчёт теперь читает из MV всего несколько тысяч строк (по одному на день × количество типов). Время выполнения падает с 40 секунд до миллисекунд. 4. Как поддерживать MV в актуальном состоянии? Есть два подхода: Полное обновление (REFRESH MATERIALIZED VIEW) — блокирует таблицу, но просто в реализации. Инкрементальное обновление (REFRESH MATERIALIZED VIEW CONCURRENTLY) — добавляет только новые данные, но требует уникального индекса. Пример автоматического обновления через планировщик: ```sql -- В PostgreSQL REFRESH MATERIALIZED VIEW CONCURRENTLY daily_events_report; -- В Oracle: автоматическое обновление по расписанию DBMS_SCHEDULER.create_job(...); ``` 5. Реальный кейс В финтех-компании дашборд с агрегацией транзакций за последний месяц выполнялся 35 секунд. После внедрения материализованного представления с ежечасным обновлением время отклика снизилось до 0.2 секунды. Бизнес смог использовать дашборд в реальном времени. 6. Что должен сделать аналитик? Выявить самые тяжёлые и частые аналитические запросы. Согласовать с бизнесом допустимую задержку данных (например, данные обновляются раз в час — это приемлемо для отчётов?). Зафиксировать в требованиях использование MV или других механизмов предрасчёта (витрины данных). Спроектировать структуру MV вместе с DBA/разработчиками, чтобы она покрывала основные сценарии. 7. Альтернативы, когда MV не подходит Витрины данных (Data Mart) — отдельные таблицы, обновляемые ETL-процессами. Колоночные СУБД (ClickHouse) — если данных много и нужна аналитика в реальном времени. Кэширование — если отчёт рендерится редко, можно кэшировать результат. Вывод: Для аналитических запросов на больших оперативных таблицах материализованные представления — промышленный стандарт. Аналитик должен предлагать такие решения на этапе проектирования, чтобы избежать падения производительности после накопления данных. 🎯

Отель Jumeirah Guangzhou 5* Вдохновленный богатым художественным наследием династии Тан, отель Jumeirah Guangzhou предлагает уникальную перспективу с видом на город Гуанчжоу. Изысканная элегантность, жизнь в стиле лофт и инновационные рестораны. Бронируйте выгодно на официальном сайте Jumeirah. Забронировать #реклама jumeirah.com О рекламодателе

№4752 категория вопросов: #DBMS

28 млн конверсий результат медийной рекламы за 2025 год Медийная реклама давно вышла за рамки имиджевых задач. Новое исследование Яндекса показало: в 2025 году она принесла бизнесу 28 млн конверсий. Вот что ещё важно: 📊 Всё больше компаний пробуют медийную рекламу: в прошлом году больше половины рекламодателей запустили её впервые; 📊 Алгоритмы становятся эффективнее по сравнению с 2024 годом: +29% к поисковому интересу, +13% к посещаемости и +19% к целевым действиям. 📊 Растёт интерес к новым форматам: число кампаний на Connected TV выросло в 4 раза, а рекламодателей — в 6 раз. Кроме того, постоянно появляются разные возможности размещения: от ТВ-билбордов до брендирования в Картах. Подробнее — в исследовании Яндекса Узнать больше #реклама 16+ yandex.ru О рекламодателе

Уходящий поезд: УСПЕВАЙ ЗАСКОЧИТЬ В ПОСЛЕДНИЙ ВАГОН ! Вчера — картинки. Сегодня — AI-агенты, которые анализируют данные и выдают инсайты, пока ты спишь. Если не хочешь махать рукой вслед уходящему AI-поезду нейросетевых технологий, залетай 👉 в ПАПКУ сейчас. Здесь тренды, которые уже меняют рынок 🔥 ВСЁ самое нужное - в одном месте ⚡️ Будь в курсе ➡️ https://t.me/addlist/mV3eY2ykKQY4Njlk

⚡️ Здравствуйте, Дорогие подписчики! Представляем вашему вниманию подборку полезных каналов в сфере «Наука и образование» 🔥 Будем очень рады, если вы найдете для себя, что-нибудь полезное. ❗️Ссылка на папку: https://t.me/addlist/_1iCoei8Dvo5OWQy

ХОЧЕШЬ ИДТИ В НОГУ С ТЕХНОЛОГИЯМИ ?! … или наблюдать, как другие зарабатывают на ИИ? - РЕШАТЬ ТЕБЕ ! ! ! ИИ станет твоим главным инструментом, а не загадкой 🗝 Нейросети стали не просто модным словом — они меняют бизнес, творчество и повседневную жизнь. А мы создаём для тебя пространство взаимного пиара и роста вокруг нейросетей: Что ты получишь в этой ПОДБОРКЕ: - еженедельные разборы real-life применений нейросетей; - чёткие инструкции: от идеи до реализации и монетизации; - крутые кейсы подписчиков и экспертов; - обратную связь по твоим постам и проектам; - новые коллаборации, за которые стоит проснуться утром. Делимся знаниями и аудиторией - растём вместе ⚡️ Забирай бесплатно ПАПКУ с ТОП ИИ Каналами Твой доступ к подборке и бонусам: ➡️ Просто добавь Папку - никаких смс или регистраций. Отписаться можно в любой момент. Остаться — тоже ✔️ * Ссылка - https://t.me/addlist/mV3eY2ykKQY4Njlk

☀Объяснение: Это классический пример того, как отсутствие критериев приемки приводит к тому, что разработчик реализует только счастливый путь (happy path), а бизнес-ожидания оказываются шире. 1. Что такое критерии приемки? Критерии приемки — это проверяемые условия, которые должны выполняться, чтобы пользовательская история считалась завершённой. Они описывают не только успешный сценарий, но и альтернативные потоки, граничные условия, обработку ошибок. 2. Как должна была выглядеть правильная история? User Story: Как покупатель, я хочу оплатить заказ банковской картой, чтобы завершить покупку. Критерии приемки: AC1: При успешной оплате заказ переходит в статус «Оплачен», пользователь видит подтверждение. AC2: При недостатке средств система показывает сообщение «Недостаточно средств. Пожалуйста, используйте другую карту». Заказ остаётся в статусе «Ожидает оплаты». AC3: При ошибке платёжного шлюза система показывает сообщение «Ошибка оплаты. Попробуйте позже». 3. Почему это критически важно? Без критериев приемки: Разработчик реализует только успешный сценарий. Тестировщик проверяет только happy path. На проде пользователи сталкиваются с ошибками и не понимают, что делать. Бизнес теряет продажи и репутацию. С критериями приемки: Разработчик знает все сценарии. Тестировщик пишет тест-кейсы на каждый AC. Приёмка проходит прозрачно. Пользователь получает понятные подсказки при любом исходе. 4. Реальный кейс В крупном интернет-магазине 15% заказов «зависали» в статусе «ожидает оплаты» из-за того, что при ошибке платежа система не возвращала пользователя к выбору способа оплаты. В требованиях не было критериев приемки для сценария ошибки. После добавления AC проблема ушла. 5. Форматы критериев приемки Gherkin: ```text Scenario: Недостаточно средств Given на карте недостаточно средств When пользователь вводит данные карты и нажимает "Оплатить" Then заказ остаётся в статусе "Ожидает оплаты" And пользователь видит сообщение "Недостаточно средств" ``` 6. Вывод Каждая пользовательская история должна содержать проверяемые критерии приемки, охватывающие счастливый путь, альтернативные сценарии, обработку ошибок и граничные условия. Их отсутствие — главная причина недопонимания и дефектов. 🎯

Смена карьеры после выгорания: психология Выгорание часто становится точкой переосмысления карьеры. Если вы когда-то думали о психологии как о более осмысленной профессии, начните с диагностики. Онлайн-тест помогает понять, готовы ли вы к работе психологом-консультантом. Заполните тест и получите персональную диагностическую карту Узнать больше #реклама 16+ test.talentsy.ru О рекламодателе

№4751 категория вопросов: #REQUIREMENTS

Не начинайте внедрять ИИ, пока не сделаете диагностику У 90% компаний ИИ-проекты не взлетают. Не потому что технология сырая, а потому что бизнес к ней не готов: ⚡ CRM забита мусором. ⚡ Данные не синхронизируются. ⚡ Сотрудники саботируют. ⚡ Безопасность хромает. Нейросеть не починит это волшебным образом. Она просто масштабирует хаос. 📊 Как провести диагностику и не слить бюджет на эксперименты — читайте в новой статье блога Школы Генерального директора. Спойлер: эксперт Школы Гендира – Рустам Боровик из Сбера создал инструмент диагностики готовности компании к внедрению ИИ. Начать #реклама 16+ gd.ru О рекламодателе

☀️Объяснение: Это классический пример некачественного требования, которое невозможно проверить. Слова «быстро», «удобно», «надёжно», «большие объёмы» субъективны. Для одного заказчика «быстро» — это 1 секунда, для другого — 5 секунд. «Большие объёмы» могут означать 100 записей или 10 миллионов. 1. Что такое проверяемое требование? Качественное требование должно быть SMART: Specific (конкретное) Measurable (измеримое) Achievable (достижимое) Relevant (релевантное) Time-bound (ограниченное по времени) Для нефункциональных требований (NFR) это особенно важно. 2. Как должна была выглядеть правильная формулировка? Вместо «быстро обрабатывать большие объёмы» аналитик должен был задать уточняющие вопросы и зафиксировать: Требование к производительности: Система должна обрабатывать 100 000 записей за не более 30 секунд (время пакетной обработки) Время отклика интерфейса при запросе отчёта — не более 2 секунд для 95% запросов Система должна выдерживать 50 одновременных пользователей без деградации производительности 3. Почему это важно? Для разработчиков: появляется целевой показатель, к которому нужно стремиться. Можно выбирать алгоритмы и архитектуру. Для тестировщиков: можно написать нагрузочные тесты и объективно проверить, укладывается ли система в заданные рамки. Для заказчика: появляется чёткий критерий приёмки. Нет места спорам «быстро/медленно». 4. Реальный кейс В одном проекте требование «система должна быстро работать» привело к судебному разбирательству. Заказчик утверждал, что отчёт формируется 10 секунд — это медленно. Исполнитель — что 10 секунд — это быстро. В спецификации не было цифр. Суд встал на сторону заказчика, потому что трактовка «быстро» по умолчанию — в пределах разумного, а 10 секунд для пользователя — это уже дискомфорт. 5. Какие вопросы должен задать аналитик? Услышав «быстро», «много», «надёжно», аналитик обязан уточнить: «Какое максимальное время отклика допустимо для пользователя?» «Какое количество одновременных пользователей ожидается в пик?» «Какой объём данных (в записях, ГБ) будет обрабатываться?» «Какое время восстановления после сбоя допустимо?» «Какой процент времени система должна быть доступна (SLA)?» 6. Роль аналитика в предотвращении конфликтов Аналитик — это переводчик между бизнесом и технической командой. Его задача — перевести расплывчатые бизнес-пожелания в однозначные, измеримые, проверяемые требования. Если этого не сделать, споры на приёмке неизбежны. Исход всегда один: либо переделка, либо судебные разбирательства. Вывод: Качественное требование — это требование, которое можно проверить. Если нельзя написать тест-кейс, значит, требование не готово. 🎯

Тренды налоговых изменений 2026 Даже самые прорывные финтех-решения требуют глубокого понимания налоговой среды. Вместе с ведущими экспертами СберУниверситет запускает новый поток программы «Налоговая функция: новые горизонты» — для тех, кто хочет системно выстроить налоговую функцию и улучшить налоговую эффективность. Что вас ждёт на программе: - Практические кейсы – разбор актуальных ИТ-льгот и возможностей их применения, а также современных трендов в части цифровых активов и валюты. - Нетворкинг – обмен опытом с коллегами из индустрии. - Диалог с экспертами – представители Минфина и ФНС России расскажут о грядущих изменениях в законодательстве. Программа подойдет финансовым и налоговым директорам, главным бухгалтерам и собственникам бизнеса 📅 Старт обучения 12 мая Узнать больше Номер реестровой записи: С502024004938. #реклама 16+ sberuniversity.ru О рекламодателе

№4750 категория вопросов: #REQUIREMENTS

Реклама для бизнеса любого уровня в Яндекс Директе Создайте эффективную рекламную кампанию с алгоритмами Яндекс Директа 👌 Начните прямо сейчас ⚡ Зарегистрироваться #реклама direct.yandex.ru О рекламодателе

🧑‍🎓Объяснение: Это классическая задача распределённых транзакций в микросервисной архитектуре. В монолите всё просто: одна база, одна транзакция. В микросервисах — у каждого сервиса своя база, и ACID-транзакция между ними невозможна без катастрофических последствий для производительности. 1. Почему другие варианты не работают? ❌ A (двухфазная фиксация / 2PC): Требует распределённого менеджера транзакций, который блокирует ресурсы во всех сервисах на время выполнения. В высоконагруженных системах это убивает производительность. Многие современные СУБД и NoSQL не поддерживают 2PC. Создаёт единую точку отказа и проблемы с масштабированием. ❌ C (общая база данных): Это возврат к монолиту, отрицающий все преимущества микросервисов. Сервисы становятся жёстко связаны через схему данных. Невозможно масштабировать сервисы независимо. Изменение схемы одной командой ломает другие сервисы. ❌ D (синхронные API с ручным откатом): При сбое после части операций невозможно гарантированно откатить изменения. Например: деньги списались, а товар не зарезервировался. Как вернуть деньги? Ручной откат — это не автоматизированное решение, чреватое ошибками. 2. Что такое паттерн Saga? Saga (сага) — это последовательность локальных транзакций, каждая из которых обновляет данные в одном сервисе. Если одна транзакция провалилась, запускаются компенсирующие транзакции, которые откатывают изменения предыдущих шагов. Варианты реализации: Хореография (Choreography): сервисы обмениваются событиями без центрального координатора. ```text 1. Сервис заказов: создаёт заказ со статусом PENDING, публикует событие "OrderCreated" 2. Сервис платежей: слушает событие, списывает деньги, публикует "PaymentProcessed" или "PaymentFailed" 3. Сервис склада: слушает "PaymentProcessed", резервирует товар, публикует "StockReserved" или "StockFailed" 4. Если "StockFailed" — сервис платежей компенсирует (возвращает деньги) Оркестрация (Orchestration): центральный координатор (оркестратор) управляет шагами и компенсациями. ``` ```text Оркестратор: - Запустить списание денег - Если успех → запустить резервирование товара - Если ошибка → запустить возврат денег ``` 3. Реальный кейс Крупный маркетплейс внедрил Saga после перехода на микросервисы. Раньше при сбое после списания денег, но до резервирования товара, заказ "зависал" в статусе "оплачен, но не отгружен". Клиенты жаловались, деньги не возвращались сутками. После внедрения Saga с хореографией через Kafka: При ошибке резервирования товара сервис платежей автоматически получал событие StockReservationFailed и возвращал деньги в течение 30 секунд. Клиент видел понятное сообщение "Товар закончился, деньги вернутся". Процент потерянных заказов снизился до нуля. 4. Что должен заложить аналитик в требования? Идентификация бизнес-процессов, требующих согласованности. Определение компенсирующих действий для каждого шага (что делать при отказе). Выбор модели (хореография или оркестрация) на основе сложности процесса. Требования к идемпотентности: сообщения могут приходить повторно, операции не должны дублироваться. Таймауты и мониторинг: "зависшие" саги должны отслеживаться и завершаться принудительно. 5. Важные нюансы Конечная согласованность (eventual consistency): в микросервисах данные не будут согласованы мгновенно. Это нормально для многих бизнес-процессов, но нужно согласовать с бизнесом допустимое окно. Компенсации vs откаты: в распределённых системах нет атомарного отката, есть компенсации (делаем обратное действие). Это сложнее, но единственный масштабируемый способ. Мониторинг: каждая сага должна логироваться, чтобы можно было отследить "зависшие" процессы.